Поделиться через


Переход с уровней "Базовый", "Стандартный", "Премиум" и "Корпоративный" на Управляемый Azure Redis

В этой статье объясняется, почему и как перенести кэш Azure для Redis (включая уровни "Базовый", "Стандартный", "Премиум" и "Корпоративный") в Управляемый Redis Azure.

Вы узнаете:

  • Преимущества выбора управляемого Redis Azure по сравнению с предыдущими уровнями.
  • Основные различия функций между службами.
  • Стратегии переноса данных кэша.
  • Способы обеспечения плавной миграции.
  • Руководство по выбору подходящего SKU управляемого Redis в Azure и уровня производительности в соответствии с вашими потребностями.
  • Соображения и рекомендации по обновлению клиентских приложений.

Независимо от того, используете ли вы уровни Basic, Standard, Premium илиEnterprise или OSS, это руководство поможет вам спланировать и выполнить миграцию в Управляемый Redis Azure.

Документ делится на два раздела. Один из вопросов касается экземпляров корпоративной системы. Другой — о уровнях "Базовый", "Стандартный" и "Премиум" кэша Azure для Redis.

Преимущества перехода с 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, выполните следующие действия.

  1. Перейдите на портал Azure и выберите "Обзор " в меню ресурсов.
  2. Проверьте поле "Состояние " в обзоре экземпляра Enterprise. В поле "Состояние " отображается размер памяти экземпляра Redis Enterprise.

Рассмотрим возможный сценарий.

Снимок экрана: обзор кэша 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-файла

  • Преимущества. Сохранение моментального снимка данных.
  • Минусы: риск потери данных, если записи производятся после создания снимка.

Ниже приведена базовая процедура экспорта и импорта:

  1. Экспорт RDB из существующего кэша Redis Enterprise в учетную запись хранения Azure.
  2. Импортируйте данные из учетной записи Azure Storage в новый управляемый кэш Redis Azure.
  3. Дополнительные сведения об экспорте и импорте данных см. здесь: импорт и экспорт данных в Управляемом Redis в Azure.

Стратегия двойной записи

  • Плюсы: нулевое время простоя, безопасный переход.
  • Минусы. Требуется временная настройка двойного кэша.

Ниже приведена базовая процедура двойной записи:

  1. Измените ваше приложение, чтобы оно записывало данные как в существующий кэш Azure Cache для Redis Enterprise, так и в новый управляемый кэш Azure Redis.
  2. Продолжить чтение и запись из кэша Redis Enterprise.
  3. После достаточной синхронизации данных переключитесь на Управляемый 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 в качестве вспомогательного кэша для записей базы данных, можно легко перестроить кэш с нуля. Ниже приведены общие действия для реализации этого варианта.

  1. Создайте экземпляр Управляемого Redis в Azure.
  2. Обновите приложение, чтобы использовать новый экземпляр.
  3. Удалите старый экземпляр Кэш Azure для Redis.

Экспорт данных в RDB-файл и импорт его в Управляемый Redis в Azure

Этот параметр применим только к кэшам уровня "Премиум". Redis с открытым исходным кодом определяет стандартный механизм создания моментального снимка набора данных в памяти кэша и его сохранения в файле. Другой кэш Redis может считывать экспортируемый файл RDB. Кэш Azure для Redis уровня "Премиум" поддерживает экспорт данных из экземпляра кэша с помощью файлов RDB. Файл RDB можно использовать для передачи данных из существующего экземпляра Кэш Azure для Redis в экземпляр Управляемого Redis Azure.

Ниже приведены общие действия для реализации этого варианта.

  1. Создайте новый экземпляр Управляемого Redis Azure, который имеет тот же размер (или больше), что и существующий экземпляр Кэш Azure для Redis.
  2. Экспорт файла RDB из существующего экземпляра кэша Azure для Redis с помощью этих инструкций экспорта или командлета экспорта PowerShell
  3. Импорт файла RDB в новый экземпляр Управляемого Redis в Azure с помощью этих инструкций импорта или командлета импорта PowerShell
  4. Обновите приложение, чтобы использовать новый экземпляр Управляемого Redis Azure строка подключения.

Запись в два кэша Redis одновременно в течение периода миграции

Вместо перемещения данных непосредственно между кэшами вы можете использовать приложение для записи данных в существующий кэш и в новый, который вы настраиваете. Приложение по-прежнему считывает данные из существующего кэша изначально. Когда новый кэш будет содержать необходимые данные, переключите приложение на этот кэш и исключите старый кэш. Предположим, например, что вы используете Redis в качестве хранилища сеансов, и сеансы приложения действительны в течение семи дней. После записи в два кэша в течение недели вы будете уверены, что новый кэш содержит все неэкспирированные сведения о сеансе. С этого момента вы можете уверенно использовать его, не беспокоясь о потере данных.

Ниже приведены общие действия для реализации этого варианта.

  1. Создайте новый экземпляр Управляемого Redis Azure, который совпадает с размером (или больше) существующего экземпляра Кэш Azure для Redis.
  2. Измените код приложения, чтобы вести запись как в новую, так и в исходную инстанцию.
  3. Продолжайте считывать данные из исходного экземпляра, пока в новом экземпляре не накопится достаточно данных.
  4. Обновите код приложения, чтобы производить считывание и запись только с использованием нового экземпляра.
  5. Удалите исходный экземпляр.

Миграция программными средствами

Создайте пользовательский процесс миграции, программно считывая данные из существующего экземпляра Кэш Azure для Redis и записывая их в управляемый экземпляр Redis в Azure. Существует два средства открытый код, которые можно попробовать:

  • Redis-copy
    • С помощью этого средства с открытым кодом можно копировать данные из одного экземпляра кэша Azure для Redis в другой. Это средство полезно для переноса данных между экземплярами кэша в разных регионах кэширования Azure. Также доступна скомпилированная версия. Исходный код также можно найти в качестве полезного руководства по написанию собственного средства миграции.
  • RIOT
    • RIOT — это еще один популярный инструмент миграции, проверенный сообществом Redis. Это программа командной строки, предназначенная для получения данных и выхода из Redis.

Note

Это средство официально не поддерживается корпорацией Майкрософт.

Ниже приведены общие действия для реализации этого варианта.

  1. Создайте виртуальную машину в регионе, где находится существующий кэш. Если набор данных большой, выберите относительно мощную виртуальную машину, чтобы сократить время копирования.
  2. Создайте экземпляр Управляемого Redis в Azure.
  3. Очистите новый кэш, чтобы убедиться, что он пуст. Этот шаг является обязательным, поскольку само средство копирования не перезаписывает существующий ключ в целевом кэше. Важно: не сбрасывайте данные из исходного кэша.
  4. Используйте приложение, например инструмент с открытым исходным кодом, упомянутый ранее, для автоматизации копирования данных из исходного кэша в целевой объект. Помните, что процесс копирования может занять некоторое время в зависимости от размера набора данных.

Региональная доступность для Управляемого Redis в Azure

Azure Managed Redis постоянно расширяет своё присутствие в новых регионах. Сведения о доступности по регионам см. в разделе "Продукты", доступные по регионам.