Вопросы и ответы по кэшу Redis для Azure

Проект Redis с открытым исходным кодом изменился на модель двойной лицензии с поддержкой доступной лицензии Redis версии 2 (RSALv2) или общедоступной лицензии на стороне сервера версии 1 (SSPLv1). Дополнительные сведения см. в пресс-релизе Redis. Также см . запись блога Майкрософт об изменении лицензирования Redis.

Нет, Кэш Azure для Redis предлагается клиентам в соответствии с условиями обслуживания Майкрософт. Лицензии RSALv2 и SSPLv1 не применяются к использованию Кэш Azure для Redis.

Да, Кэш Azure для Redis, Кэш Azure для Redis Enterprise и Enterprise Flash будут продолжать получать исправления и исправления ошибок даже после объявления о лицензировании.

Для наших клиентов Azure не требуется никаких действий в отношении объявления о лицензировании.

• Использование управляемой службы кэша Managed Cache service было прекращено 30 ноября 2016 г.

• Использование службы кэша роли In-Role Cache было прекращено 30 ноября 2016 г.

Необходимо перенести все кэши, зависимые от Облачных служб (классическая версия). В августе 2021 года мы объявили, что Облачные службы (классическая версия) прекратят свою работу 31 августа 2024 года. Использование всех экземпляров Кэша Azure для Redis, зависящих от Облачных служб (классическая версия), должно быть прекращено с той же даты.

Следует перенести кэши, зависимые от Облачных служб (классическая версия) до 31 августа 2024 г.

Мы предприняли усилия по переносу максимально прозрачного количества кэшей. Из-за этого затрагивается несколько кэшей и клиентов.

Проверьте Рекомендации помощника по Azure. Если ваш кэш затронут, вы увидите рекомендацию в вашей подписке.

Мы переносили большинство кэшей, созданных на основе Облачные службы (классической) для создания Масштабируемые наборы виртуальных машин Azure. Во время переноса в масштабируемые наборы виртуальных машин зависимость удаляется. Существует три способа инициировать этот процесс для кэшей в виртуальной сети:

• Миграция в новый кэш с помощью Приватный канал.

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

• Миграция в новый кэш в новой подсети виртуальной сети Azure Resource Manager.

  Создание кэша в классической виртуальной сети создает кэш Облачные службы (классической) и не кэш Масштабируемые наборы виртуальных машин Azure. Перенос в новый кэш в новой подсети виртуальной сети Azure Resource Manager устраняет базовую зависимость от Облачные службы при сохранении аналогичного интерфейса виртуальной сети.

  Мы переносили большинство кэшей, созданных на основе Облачные службы (классической) для создания Масштабируемые наборы виртуальных машин Azure. Чтобы выполнить миграцию, удалите существующий кэш и создайте новый кэш в новой подсети виртуальной сети Azure Resource Manager. Настоятельно рекомендуется не использовать старые подсети при переносе кэшей. Рекомендуемые варианты переноса данных в кэше см. в разделе Миграция в Кэш Azure для Redis.

• Автоматическая миграция с потерей данных (рекомендуется).

  Мы можем перенести кэши с использования Облачные службы (классической) на использование Масштабируемые наборы виртуальных машин автоматически с сохранением конфигурации кэша (включая ключи доступа и имя узла). Однако этот метод требует около 30 минут простоя и полной потери данных в кэше. Вы можете использовать функцию импорта и экспорта для сохранения копии данных перед миграцией.

  Чтобы использовать этот параметр, обратитесь azurecachemigration@microsoft.com в службу поддержки или создайте запрос на поддержку, чтобы запросить миграцию.

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

Например:

1. Создайте новую геореплицированную пару премиум кэшей, которые соответствуют той же конфигурации, что и текущая пара кэшей.
2. Отмените связь исходной пары геореплицированных кэшей и экспортируйте RDB-файл из основного кэша.
3. Импортируйте RDB-файл в основной кэш в новой геореплицированной паре.

Новая пара геореплицированных кэшей не будет иметь такую же зависимость от Облачных служб.

Мы начинаем блокировать создание новых кэшей с помощью модели развертывания Облачные службы (классической). Новые кэши по-прежнему можно создавать с помощью этой старой модели развертывания, если они создаются в подсети виртуальной сети, содержащей кэш Облачные службы, или если кэш развертывается в классической виртуальной сети. Если вы видите это сообщение, создайте новую подсеть в виртуальной сети, в которой будет развернут кэш. Создание подсети в виртуальной сети гарантирует, что кэш создается без зависимости Облачные службы.

Чтобы проверка, если в подсети есть один или несколько Облачные службы кэшей на основе Облачные службы, вы можете проверка Помощника по Azure на портале или использовать REST API навигации по ресурсам. Используйте API с идентификатором resource-navigation-links подписки, именем группы ресурсов, именем виртуальной сети и именем подсети, чтобы получить все кэши в этой подсети, которые используют Облачные службы.

Если вы создаете новый кэш с помощью REST API, убедитесь, что вы не передаете конфигурацию {"CacheVmType": "CloudService"} redis вместе с запросом на создание. Эти параметры являются незадокументированных параметров, поэтому вряд ли вы делаете это.

Если вам нужно создать новые кэши с помощью модели развертывания Облачные службы (классическая модель), обратитесь azurecachemigration@microsoft.com в службу поддержки или создайте запрос на поддержку, чтобы запросить исключение.

Эти кэши будут отключены, и вы теряете все данные в кэше.

Выход на пенсию выполняется на трех этапах, чтобы у вас было максимальное время для миграции:

1. Активный этап (с сегодняшнего дня до 30 апреля 2023 г.)

   Кэши поддерживаются без изменений в состоянии с сегодняшнего дня. Этот период позволяет клиентам переходить от облачной службы (классической) с минимальным прерыванием.

2. Этап обслуживания (с 1 мая 2023 г. по 31 декабря 2023 г.)

   Кэши получат критически важные исправления безопасности, стабильности и ошибок, но без новых функций.

3. Неактивный этап (с 1 января 2024 г. по 31 августа 2024 г.)

   Кэши получают только критически важные исправления безопасности. Перед получением поддержки все клиенты с проблемами поддержки должны перенестися в кэш на основе VMSS. Клиенты должны удалить свои кэши до 31 августа 2024 г.

№ Это временная шкала применяется только к кэшам, работающим в Redis 6.0. Redis 4.0 является частью отдельного выхода на пенсию, которая завершается до выхода на пенсию Облачные службы (классическая модель). Все оставшиеся кэши с помощью Redis 4.0 на Облачные службы (классическая версия) будут автоматически перенесены для использования Масштабируемые наборы виртуальных машин и Redis 6.0 после 31 октября 2023 года. Этот метод миграции требует простоя и полной потери данных в кэше, поэтому перед этой датой необходимо выполнить миграцию, если вы хотите избежать простоя или потери данных. Обратитесь azurecachemigration@microsoft.com или создайте запрос на поддержку, чтобы запросить автоматическое обновление до 31 октября 2023 года.

Опубликуйте любые вопросы на странице Q&A для выхода на пенсию Облачные службы (классическая модель). Кроме того, вы можете отправить сообщение электронной почты azurecachemigration@microsoft.com для получения дополнительных сведений.

Если вашего вопроса нет в списке, сообщите нам об этом, и мы поможем найти ответ.

• Чтобы охватить большую аудиторию, можно опубликовать вопрос на странице вопросов и ответов Майкрософт по кэшу Azure и обсудить его с командой разработчиков кэша Azure и другими участниками сообщества.

• Если вы хотите сделать запрос на функцию, то можете отправить свои запросы и предложения на форуме пользователей кэша Azure для Redis.

• Вы также можете отправить нам свой вопрос по адресу azurecache@microsoft.com.