Примечание.
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
В этой статье объясняется, почему и как перенести кэш Azure для Redis (включая уровни "Базовый", "Стандартный", "Премиум" и "Корпоративный") в Управляемый Redis Azure.
Вы узнаете:
- Преимущества выбора управляемого Redis Azure по сравнению с предыдущими уровнями.
- Основные различия функций между службами.
- Стратегии переноса данных кэша.
- Способы обеспечения плавной миграции.
- Руководство по выбору подходящего SKU управляемого Redis в Azure и уровня производительности в соответствии с вашими потребностями.
- Соображения и рекомендации по обновлению клиентских приложений.
Независимо от того, используете ли вы уровни Basic, Standard, Premium илиEnterprise или OSS, это руководство поможет вам спланировать и выполнить миграцию в Управляемый Redis Azure.
Документ делится на два раздела. Один из вопросов касается экземпляров корпоративной системы. Другой — о уровнях "Базовый", "Стандартный" и "Премиум" кэша Azure для Redis.
- Преимущества перехода с Enterprise на Управляемый Redis в Azure
- Преимущества перехода с кэшей "Базовый", "Стандартный" или "Премиум" на Управляемый Redis Azure
Преимущества перехода с Enterprise на Управляемый Redis в Azure
Управляемый Redis Azure основан на расширенном программном обеспечении Redis Enterprise. Управляемый Redis Azure — это внутренний продукт Azure, что означает отсутствие отдельного компонента Azure Marketplace, а пользователям не нужно совершать транзакции с Marketplace отдельно. Вы подготавливаете, управляете и оплачиваете Azure Managed Redis так же, как и другие собственные службы или продукты Azure.
Управляемому Redis в Azure не требуется узел кворума, что предотвращает недостаточное использование ресурсов и расширяет количество регионов или облаков, где может быть предложен кэш Azure для Redis Enterprise. Azure Managed Redis теперь доступен в большинстве регионов Azure и планируется внедрить поддержку в других суверенных облаках. Дополнительные сведения о узле кворума см. на уровнях Enterprise и Enterprise Flash. Удаляя неиспользуемый узел кворума, вы получаете повышенную экономичность, так как все узлы можно использовать в качестве узлов данных.
Управляемый Redis на платформе Azure по умолчанию обладает избыточностью между зонами.
Вы можете использовать сервис Azure Redis без высокой отказоустойчивости для сред разработки и тестирования. Использование непроизводственных сред без отказоустойчивости сокращает затраты вашего экземпляра.
Структура SKU для Управляемого Redis для Azure основана на ваших потребностях в памяти и производительности. Вместо управления параметрами масштабирования или емкости в Azure Cache для Redis Enterprise можно выбрать три уровня производительности в Azure Managed Redis. Дополнительные сведения см. в разделе "Выбор нужного уровня".
Наконец, Управляемый Redis Azure предлагает проверку подлинности идентификатора Microsoft Entra при создании кэша для повышения уровня безопасности рабочей нагрузки.
Сравнение функций
| Функция | Кэш Azure для Redis Enterprise | Управляемый Redis в Azure |
|---|---|---|
| Версия Redis | 7.2 | 7.4 |
| Политика кластеризации | Открытое программное обеспечение, предприятие | ОСС, Корпоративный, Некластеризованный |
| Geo-replication | Active | Active |
| SLA | До 99.999% | До 99.999% |
| Избыточность зон | Yes | *Да с высокой доступностью |
| Режим без высокой доступности | No | Да (для разработки и тестирования) |
| Сохраняемость данных | Да (в предварительной версии) | Yes |
| Масштабирование | Yes | Yes |
| Поддержка версий TLS | 1.2,1.3 | 1.2,1.3 |
| Проверка подлинности идентификатора Microsoft Entra | No | Yes |
| Поддержка региона Azure | Ограничено | Обширный |
| Поддержка Azure Sovereign Cloud | No | Да (скоро) |
| Dns-суффикс имени узла | <name>.<region>.redisenterprise.cache.azure.net |
<name>.<region>.redis.azure.net |
* Если включен высокий уровень доступности, Управляемый Redis Azure поддерживает отказоустойчивость между зонами в регионах с несколькими зонами доступности. Дополнительные сведения см. в статье "Надежность" в Управляемом Redis Azure.
Рекомендации при переходе из Enterprise в Управляемый Redis в Azure
Управляемый Redis Azure использует тот же стек программного обеспечения, что и кэш Azure для Redis Enterprise, поэтому существующие приложения, использующие корпоративный уровень, не требуют много изменений. Важное исключение заключается в том, что необходимо изменить учетные данные подключения.
Другое имя узла и суффикс
Хотя ядро программного обеспечения для Azure Cache для Redis Enterprise и Azure Managed Redis похоже, DNS-суффикс для имени узла кластера Redis отличается. При переходе на управляемый Redis от Azure приложение должно изменить имя узла кластера Redis. Если вы используете ключи доступа для подключения к кэшу, необходимо также обновить ключ доступа, используемый для подключения к кэшу.
Это важно
Попробуйте обновить код, который подключается к кэшу. Вместо использования ключей доступа используйте идентификатор Microsoft Entra. Мы рекомендуем использовать идентификатор Microsoft Entra вместо ключей доступа.
Выбор правильного размера Управляемого Redis в Azure и номера SKU
Управляемый Redis Azure предлагает множество размеров памяти и три уровня производительности. Дополнительные сведения о размерах памяти и уровнях производительности см. в разделе "Выбор нужного уровня".
Определение размера памяти существующего экземпляра кэша Azure для Redis Enterprise
Экземпляры Azure Cache для Redis Enterprise можно масштабировать горизонтально, чтобы увеличить объем памяти и вычислительные ресурсы, поэтому важно учитывать фактор горизонтального масштабирования для вашего кэша. Масштабирование также связано с емкостью, что, по сути, является числом виртуальных машин, работающих для кластера.
Чтобы выбрать правильный размер памяти Управляемого Redis для Azure, выполните следующие действия.
- Перейдите на портал Azure и выберите "Обзор " в меню ресурсов.
- Проверьте поле "Состояние " в обзоре экземпляра Enterprise. В поле "Состояние " отображается размер памяти экземпляра Redis Enterprise.
Рассмотрим возможный сценарий.
Статус на панели Обзор показывает Запущено — Корпоративная 8 ГБ (2 x 4 ГБ). Это нотация означает, что кэш в настоящее время использует SKU E5 Enterprise с масштабом 2, что дает кэш размером 8 ГБ. Поэтому следует начать с по крайней мере 10 ГБ кэша в Управляемом Redis в Azure.
В этом случае используйте любой из уровней, которые предлагают 12 ГБ памяти.
| Артикул (SKU) | Тир |
|---|---|
| M10 | Memory Optimized |
| B10 | Balanced |
| X10 | Compute Optimized |
Определение уровня производительности
Кроме того, следует учитывать, является ли рабочая нагрузка интенсивной по памяти или интенсивной по вычислениям. Если в текущем экземпляре Enterprise с большей вероятностью закончится память, нежели ЦП, то рабочая нагрузка является ресурсоемкой по использованию памяти. Рассмотрите возможность выбора уровня оптимизированной для памяти производительности.
Если ваша рабочая нагрузка характеризуется высокой интенсивностью пропускной способности или чрезмерной задержкой, то она является интенсивной по вычислительным ресурсам. Рассмотрите возможность выбора уровня производительности , оптимизированного для вычислений .
Если вы не уверены, вы можете начать с сбалансированного уровня производительности, так как он предлагает здоровое сочетание памяти и производительности.
Если вы в настоящее время используете уровень Redis Enterprise Flash, тогда выберите уровень "Оптимизированный для флэш-памяти".
Создайте новый экземпляр Redis, управляемый в Azure
Выбрав уровень памяти и производительности для нового экземпляра Управляемого Redis в Azure, можно создать новый экземпляр Управляемого Redis в Azure. Дополнительные сведения о создании кэша см. в кратком руководстве по созданию управляемого экземпляра Redis в Azure.
Затем необходимо выбрать стратегию перемещения данных. Наконец, необходимо обновить приложение для использования нового кэша.
Обновление приложения для подключения к экземпляру Redis с управлением в Azure
После создания нового экземпляра Управляемого Redis в Azure необходимо изменить имя конечной точки Или узла Redis и ключ доступа в приложении, чтобы указать новый экземпляр Управляемого Redis в Azure. Рекомендуется публиковать изменения этой конечной точки в нерабочие часы, так как это приводит к небольшому нарушению подключения.
Note
Если вы подключаетесь к существующему экземпляру Redis Enterprise через частную конечную точку, убедитесь, что новый кэш Управляемого Redis Azure также подключен к виртуальной сети приложения. Новый кэш должен иметь аналогичную настройку, как существующий экземпляр Redis Enterprise.
Убедитесь, что приложение работает должным образом, а затем удалите предыдущий экземпляр Redis Enterprise.
Перемещение данных из кэша Enterprise в новый управляемый кэш Redis Azure
При миграции в экземпляр Управляемого Redis в Azure необходимо учитывать лучший способ перемещения данных из существующего экземпляра Redis Enterprise в новый экземпляр Управляемого Redis для Azure. Если приложение может терпеть потерю данных или имеет другие механизмы для повторного восстановления кэша без негативных последствий, то пропустите этот шаг и перейдите к следующим шагам.
Если вам нужно убедиться, что данные также мигрируются в новый управляемый экземпляр Redis в Azure, выберите один из следующих вариантов:
Экспорт и импорт данных с помощью RDB-файла
- Преимущества. Сохранение моментального снимка данных.
- Минусы: риск потери данных, если записи производятся после создания снимка.
Ниже приведена базовая процедура экспорта и импорта:
- Экспорт RDB из существующего кэша Redis Enterprise в учетную запись хранения Azure.
- Импортируйте данные из учетной записи Azure Storage в новый управляемый кэш Redis Azure.
- Дополнительные сведения об экспорте и импорте данных см. здесь: импорт и экспорт данных в Управляемом Redis в Azure.
Стратегия двойной записи
- Плюсы: нулевое время простоя, безопасный переход.
- Минусы. Требуется временная настройка двойного кэша.
Ниже приведена базовая процедура двойной записи:
- Измените ваше приложение, чтобы оно записывало данные как в существующий кэш Azure Cache для Redis Enterprise, так и в новый управляемый кэш Azure Redis.
- Продолжить чтение и запись из кэша Redis Enterprise.
- После достаточной синхронизации данных переключитесь на Управляемый Redis Azure и удалите экземпляр Redis Enterprise
Программная миграция с помощью RIOT-X
RIOT-X предоставляет способ миграции содержимого из систем Enterprise в управляемый Azure Redis. Дополнительные сведения см. в разделе "Миграция данных" с RIOT-X для Управляемого Redis в Azure.
- Преимущества: полный контроль, настраиваемый.
- Минусы: требует усилий по разработке.
Преимущества перехода с кэшей уровней "Базовый", "Стандартный" или "Премиум" на Azure Managed Redis
Если вы используете любой из SKU OSS, Basic, Standard или Premium, переход на Azure Managed Redis предлагает вам дополнительные функции на каждом уровне кэша.
Ниже приведена таблица, которая сравнивает функции из Azure Cache for Redis с функциями в Azure Managed Redis.
| Описание функции | Basic OSS |
Standard OSS |
Premium OSS |
Balanced AMR |
Memory Optimized AMR |
Compute Optimized AMR |
|---|---|---|---|---|---|---|
| Availability | N/A | 99.9% | 99.9% | До 99.999% | До 99.999% | До 99.999% |
| Шифрование данных при передаче | Yes | Yes | Yes | Yes | Yes | Yes |
| Сетевая изоляция | Yes | Yes | Yes | Yes | Yes | Yes |
| Масштабирование вверх/вниз и вширь | Yes | Yes | Yes | Yes | Yes | Yes |
| Уменьшение масштаба/вхождение | Yes | Yes | Yes | No | No | No |
| Кластеризация OSS | No | No | Yes | Yes | Yes | Yes |
| Сохраняемость данных | No | No | Yes | Yes | Yes | Yes |
| Избыточность зон | No | Да (предварительная версия) | Yes | *Да с высокой доступностью | *Да с высокой доступностью | *Да с высокой доступностью |
| Geo-replication | No | No | Да (пассивный) | Да (активный) | Да (активный) | Да (активный) |
| Журналы аудита подключения | No | No | Yes | Yes(Event-based) | Yes(Event-based) | Yes(Event-based) |
| Модули Redis | No | No | No | Yes | Yes | Yes |
| Import/Export | No | No | Yes | Yes | Yes | Yes |
| Reboot | Yes | Yes | Yes | No | No | No |
| Запланированные обновления | Yes | Yes | Yes | No | No | No |
| Проверка подлинности идентификатора Microsoft Entra | Yes | Yes | Yes | Yes | Yes | Yes |
| RBAC идентификатора Microsoft Entra | Yes | Yes | Yes | No | No | No |
| Уведомление о пространстве ключей | Yes | Yes | Yes | No | No | No |
| Без высокой доступности | N/A | No | No | Yes | Yes | Yes |
OSS ссылается на кэш Azure для Redis
AMR относится к Azure Managed Redis
* Если включена Высокая доступность, Управляемый Redis Azure устойчив к отказам между зонами в регионах с несколькими зонами доступности.
Ниже приведены некоторые другие различия, которые следует учитывать при реализации Управляемого Redis в Azure. Рассмотрите следующие изменения клиентского приложения:
| Описание функции | Кэш Azure для Redis | Управляемый Redis в Azure |
|---|---|---|
| DNS-суффикс (только для облака PROD) | .redis.cache.windows.net |
<region>.redis.azure.net |
| ПОРТ TLS | 6380 | 10000 |
| Порт, отличный от TLS | 6379 | Не поддерживается |
| Порты TLS для отдельных узлов | 13XXX | 85xx |
| Отдельный порт, отличный от TLS | 15XXX | Не поддерживается |
| Поддержка кластеризации | Режим кластеризации OSS | Режимы кластера OSS и Enterprise |
| Неподдерживаемые команды | Неподдерживаемые команды | Команды с несколькими ключами |
| Региональная доступность | Все регионы Azure | * См. список регионов после этого раздела. |
| Версия Redis | 6 | 7.4 |
| Поддерживаемые версии протокола TLS | 1.2 и 1.3 | 1.2 и 1.3 |
Переносите ваш кэш уровня "Базовый", "Стандартный" или "Премиум" на управляемый Redis Azure.
На основе таблицы приведены некоторые сопоставления между вариантами SKU для Azure Cache for Redis и опциями кэшей в Azure Managed Redis.
Note
Использование параметра "Высокий уровень доступности" управляемого Redis azure для миграции базовых номеров SKU
| Кэш Azure для Redis | Управляемый Redis в Azure | Дополнительная память (%) |
|---|---|---|
| Базовый или стандартный — C0 | Balanced — B0 | 50 |
| Базовый или стандартный — C1 | Balanced — B1 | 0 |
| Базовый и стандартный — C2 | Balanced — B3 | 17 |
| Базовый или стандартный — C3 | Balanced — B5 | 0 |
| Базовый или стандартный — C4 | Оптимизировано для памяти — M10* | -8 |
| Базовый или стандартный — C4 | Оптимизировано для памяти — M20** | 46 |
| Базовый или стандартный — C5 | Оптимизировано для памяти — M20* | -8 |
| Базовый или стандартный — C5 | Оптимизировано для памяти — M50** | 57 |
| Базовый или стандартный — C6 | Оптимизировано для памяти — M50 | 12 |
| Премиум - P1 | Balanced — B5 | 0 |
| Премиум - P2 | Сбалансированный - B10* | -8 |
| Премиум - P2 | Сбалансированный - B20** | 46 |
| Премиум - P3 | Balanced — B20* | -8 |
| Премиум - P3 | Сбалансированный - B50** | 57 |
| Премиум - P4 | Balanced — B50 | 12 |
| Премиум - P5 | Balanced — B100 | 0 |
- * Этот параметр предназначен для повышения эффективности затрат. Убедитесь, что пик общего объема используемой памяти за прошлый месяц меньше, чем рекомендуемая память Управляемого Redis Azure, чтобы выбрать этот параметр.
- ** Этот параметр предназначен для потребления большого объема памяти.
кластеризованный Кэш Azure для Redis Premium
- Для сегментированного кластера выберите уровень оптимизированной для памяти, имеющий эквивалентную общую память.
- Для кластеров с несколькими репликами чтения выберите уровень "Оптимизировано для вычислений" с эквивалентной общей памятью в качестве основной реплики.
Варианты переноса
Клиентские приложения должны использовать экземпляр Управляемого Redis Azure с различными режимами кластеризации и конечными точками. Кэш Azure для Redis и Управляемый Redis Azure совместимы, поэтому в большинстве сценариев нет необходимости изменять код приложения, за исключением конфигураций подключений.
Узнайте больше здесь:
Параметры миграции Кэш Azure для Redis в Управляемый Redis Azure
| Option | Advantages | Disadvantages |
|---|---|---|
| Создание кэша | Простейший способ реализации. | Необходимо повторно заполнить данные в новом кэше, который может не работать с многими приложениями. |
| Экспорт и импорт данных через файл RDB | Совместимость в целом с любым кэшем Redis. | Некоторые данные могут быть потеряны, если они записаны в существующий кэш после создания файла RDB. |
| Запись данных одновременно в два кэша | Не приводит к потерям данных и простоям. Непрерывные операции с существующим кэшем. Упрощенное тестирование нового кэша. | Требуется два кэша на продолжительный период времени. |
| Программная миграция данных | Полный контроль над перемещением данных. | Требуется специальный код. |
Создание нового управляемого экземпляра Redis в Azure
Этот подход технически не является миграцией. Если потеря данных не является проблемой, проще всего перейти на уровень Managed Redis в Azure, чтобы создать новый экземпляр кэша и подключить его к нему. Например, если использовать Redis в качестве вспомогательного кэша для записей базы данных, можно легко перестроить кэш с нуля. Ниже приведены общие действия для реализации этого варианта.
- Создайте экземпляр Управляемого Redis в Azure.
- Обновите приложение, чтобы использовать новый экземпляр.
- Удалите старый экземпляр Кэш Azure для Redis.
Экспорт данных в RDB-файл и импорт его в Управляемый Redis в Azure
Этот параметр применим только к кэшам уровня "Премиум". Redis с открытым исходным кодом определяет стандартный механизм создания моментального снимка набора данных в памяти кэша и его сохранения в файле. Другой кэш Redis может считывать экспортируемый файл RDB. Кэш Azure для Redis уровня "Премиум" поддерживает экспорт данных из экземпляра кэша с помощью файлов RDB. Файл RDB можно использовать для передачи данных из существующего экземпляра Кэш Azure для Redis в экземпляр Управляемого Redis Azure.
Ниже приведены общие действия для реализации этого варианта.
- Создайте новый экземпляр Управляемого Redis Azure, который имеет тот же размер (или больше), что и существующий экземпляр Кэш Azure для Redis.
- Экспорт файла RDB из существующего экземпляра кэша Azure для Redis с помощью этих инструкций экспорта или командлета экспорта PowerShell
- Импорт файла RDB в новый экземпляр Управляемого Redis в Azure с помощью этих инструкций импорта или командлета импорта PowerShell
- Обновите приложение, чтобы использовать новый экземпляр Управляемого Redis Azure строка подключения.
Запись в два кэша Redis одновременно в течение периода миграции
Вместо перемещения данных непосредственно между кэшами вы можете использовать приложение для записи данных в существующий кэш и в новый, который вы настраиваете. Приложение по-прежнему считывает данные из существующего кэша изначально. Когда новый кэш будет содержать необходимые данные, переключите приложение на этот кэш и исключите старый кэш. Предположим, например, что вы используете Redis в качестве хранилища сеансов, и сеансы приложения действительны в течение семи дней. После записи в два кэша в течение недели вы будете уверены, что новый кэш содержит все неэкспирированные сведения о сеансе. С этого момента вы можете уверенно использовать его, не беспокоясь о потере данных.
Ниже приведены общие действия для реализации этого варианта.
- Создайте новый экземпляр Управляемого Redis Azure, который совпадает с размером (или больше) существующего экземпляра Кэш Azure для Redis.
- Измените код приложения, чтобы вести запись как в новую, так и в исходную инстанцию.
- Продолжайте считывать данные из исходного экземпляра, пока в новом экземпляре не накопится достаточно данных.
- Обновите код приложения, чтобы производить считывание и запись только с использованием нового экземпляра.
- Удалите исходный экземпляр.
Миграция программными средствами
Создайте пользовательский процесс миграции, программно считывая данные из существующего экземпляра Кэш Azure для Redis и записывая их в управляемый экземпляр Redis в Azure. Существует два средства открытый код, которые можно попробовать:
-
Redis-copy
- С помощью этого средства с открытым кодом можно копировать данные из одного экземпляра кэша Azure для Redis в другой. Это средство полезно для переноса данных между экземплярами кэша в разных регионах кэширования Azure. Также доступна скомпилированная версия. Исходный код также можно найти в качестве полезного руководства по написанию собственного средства миграции.
-
RIOT
- RIOT — это еще один популярный инструмент миграции, проверенный сообществом Redis. Это программа командной строки, предназначенная для получения данных и выхода из Redis.
Note
Это средство официально не поддерживается корпорацией Майкрософт.
Ниже приведены общие действия для реализации этого варианта.
- Создайте виртуальную машину в регионе, где находится существующий кэш. Если набор данных большой, выберите относительно мощную виртуальную машину, чтобы сократить время копирования.
- Создайте экземпляр Управляемого Redis в Azure.
- Очистите новый кэш, чтобы убедиться, что он пуст. Этот шаг является обязательным, поскольку само средство копирования не перезаписывает существующий ключ в целевом кэше. Важно: не сбрасывайте данные из исходного кэша.
- Используйте приложение, например инструмент с открытым исходным кодом, упомянутый ранее, для автоматизации копирования данных из исходного кэша в целевой объект. Помните, что процесс копирования может занять некоторое время в зависимости от размера набора данных.
Региональная доступность для Управляемого Redis в Azure
Azure Managed Redis постоянно расширяет своё присутствие в новых регионах. Сведения о доступности по регионам см. в разделе "Продукты", доступные по регионам.