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

Масштабирование экземпляра Redis под управлением Azure (предварительной версии)

  • Статья

Для Redis под управлением Azure (предварительная версия) предусмотрены разные SKU и уровни, что позволяет вам свободно выбирать размер кэша и производительность. У вас есть возможность расширить память или перейти на уровень с более высокой производительностью вычислительной среды. В этой статье показано, как масштабировать кэш на портале Azure и с помощью инструментов, таких как Azure PowerShell и Azure CLI.

Примечание.

Так как функции на всех уровнях Redis под управлением Azure практически одинаковы, масштабирование обычно используется только для изменения характеристик памяти и производительности.

Внимание

В настоящее время поддерживается только масштабирование для увеличения памяти или повышения уровня производительности. Масштабирование для уменьшения памяти или перехода на более низкий уровень производительности пока не поддерживается.

Типы масштабирования

Redis под управлением Azure поддерживает масштабирование по двум параметрам:

  • Память Увеличение памяти увеличивает размер экземпляра Redis, что позволяет хранить больше данных.

  • Виртуальные ЦП Redis под управлением Azure предлагает три уровня (оптимизированный для операций в памяти, сбалансированный и оптимизированный для вычислений), причем на каждом уровне памяти количество виртуальных ЦП увеличивается. При масштабировании до уровня с большим количество виртуальных ЦП производительность экземпляра повышается, и для этого не требуется увеличивать объем памяти. В отличие от выпуска Redis Сommunity, поддерживающего не более одного виртуального ЦП, Redis под управлением Azure использует стек Redis Enterprise, способный задействовать несколько виртуальных ЦП. Это означает, что количество виртуальных ЦП, которые использует экземпляр Redis, напрямую связано с пропускной способностью и задержкой.

Уровни производительности

Существует четыре уровня Redis под управлением Azure с разными параметрами производительности и ценами.

Три уровня предназначены для данных в памяти:

  • Оптимизированный для операций в памяти. Идеально подходит для вариантов использования с большим объемом памяти, требующих высокой производительности ЦП (8:1), но не требуется высокая производительность пропускной способности. Это недорогое решение для ситуаций, где требуется меньшая вычислительная мощность или пропускная способность, благодаря чему оно отлично подойдет для сред разработки и тестирования.
  • Сбалансированный (память+вычислительная среда). Обеспечивает сбалансированное соотношение памяти и виртуального ЦП (4:1), что делает его идеальным для стандартных рабочих нагрузок. Оно предлагает работоспособный баланс между памятью и вычислительными ресурсами.
  • Оптимизированный для вычислений. Предназначен для рабочих нагрузок с высокой производительностью, требующих максимальной пропускной способности, с низким соотношением памяти к VCPU (2:1). Идеально подойдет для приложений, которым требуется максимальная производительность.

Данные в памяти и на диске хранятся на одном уровне:

  • Оптимизированный для флэш-памяти. Позволяет кластерам Redis автоматически перемещать из памяти (ОЗУ) в хранилище NVMe данные, к которым реже обращаются. Это снижает производительность, но позволяет меньше тратить на масштабирование кэшей с крупными наборами данных.

Уровни и номера SKU на первый взгляд

Таблица с разными конфигурациями памяти и виртуальных ЦП для каждого номера SKU и уровня Управляемого Redis в Azure.

Производительность (пропускная способность и задержка)

Подробнее о тестировании и измерении производительность каждого SKU и уровня см. в статье Тестирование производительности с помощью Redis под управлением Azure

Выбор времени масштабирования

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

Можно отслеживать следующие метрики для определения необходимости масштабирования.

  • ЦП
    • При высоком расходе ресурсов ЦП сервер Redis не успевает выполнять запросы, поступающие от всех клиентов. Масштабирование для увеличения количества виртуальных ЦП помогает распределять запросы между несколькими процессами Redis. Масштабирование также помогает распространять шифрование TLS, расшифровку и подключение и отключение, ускоряя экземпляры кэша с помощью TLS.
  • Использование памяти
    • Высокий уровень использования памяти указывает, что размер данных слишком велик для текущего размера кэша. Рассмотрите возможность увеличения масштаба до размера кэша с большим объемом памяти.
  • Клиентские подключения
    • Каждый размер кэша имеет ограничение на количество поддерживаемых клиентских подключений. Если клиентские подключения приблизились к предельному размеру кэша, рассмотрите возможность масштабирования для увеличения объема памяти или уровня производительности.
    • Подробнее об ограничениях подключения по размеру кэша см. в статье Тестирование производительности с помощью Redis под управлением Azure.
  • Сеть Bandwidth
    • Если для сервера Redis превышена доступная пропускная способность, возможно, будет превышено время ожидания для запросов клиентов, так как сервер не будет успевать отправлять данные клиентам. С помощью метрик "Чтение из кэша" и "Запись в кэш" можно узнать, какая часть пропускной способности потребляется на стороне сервера. Если сервер Redis превышает доступную пропускную способность сети, рассмотрите возможность масштабирования для увеличения уровня производительности или размера кэша.
    • Выбор политики кластера влияет на доступную пропускную способность сети. Как правило, политика кластера OSS предполагает более высокую пропускную способность сети, чем политика кластера Enterprise. Дополнительные сведения см. в разделе Политика кластера.
    • Подробнее о доступной пропускной способности сети по размеру кэша см. в статье Тестирование производительности с помощью Redis под управлением Azure.

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

Примечание.

Подробнее о оптимизации процесса масштабирования см. в рекомендациях по масштабированию

Условия и ограничения масштабирования Redis под управлением Azure

  • С уровня Оптимизированный для операций в памяти, Сбалансированный или Оптимизированный для вычислений нельзя выполнить масштабирование до уровня Оптимизированный для флэш-памяти или наоборот.
  • Невозможно уменьшить масштаб с номера SKU с меньшим количеством виртуальных ЦП. (На разных уровнях или на одном уровне.)
  • Вы не можете уменьшить размер памяти до меньшего размера, даже если он имеет одинаковые или несколько виртуальных ЦП.
  • В некоторых случаях при масштабировании меняется базовый IP-адрес экземпляра Redis. Запись DNS для экземпляра изменяется и является прозрачной для большинства приложений. Однако если вы используете IP-адрес для настройки подключения к кэшу, NSG или брандмауэров, разрешающих направлять трафик в кэш, через некоторое время после обновления DNS-записи у вашего приложения могут возникнуть проблемы с подключением.
  • Масштабирование экземпляра в группе георепликации имеет ряд дополнительных ограничений. Подробнее см. в разделе Имеются ли ограничения на масштабирование, связанные с георепликацией?.

Масштабирование

Совет

Вы можете изменить объем памяти и уровень производительности в рамках одной операции.

Масштабирование с помощью портал Azure

  1. Чтобы масштабировать кэш, перейдите к кэшу в портал Azure и выберите "Масштаб" в меню "Ресурс".

    Снимок экрана: масштабирование, выбранное в меню

  2. Чтобы увеличить масштаб, выберите другой тип кэша и нажмите кнопку "Сохранить".

    Внимание

    Если выбрать номер SKU, который нельзя масштабировать, параметр "Сохранить " отключен. Дополнительные сведения о том, какие параметры масштабирования разрешены, см. в разделе "Предварительные требования и ограничения масштабирования Azure Managed Redis".

    Снимок экрана: уровни Enterprise в рабочей области.

  3. Пока как кэш масштабируется до нового уровня, отображается уведомление Масштабирование кэша Redis.

    Снимок экрана: уведомление о масштабировании кэша Enterprise.

  4. После завершения масштабирования состояние меняется с Масштабирование на Работает.

Масштабирование с помощью PowerShell

Экземпляры Redis под управлением Azure можно масштабировать с помощью PowerShell, используя для этого командлет Update-AzRedisEnterpriseCache. Для выбора нужного уровня и SKU можно изменить свойство Sku. В следующем примере демонстрируется масштабирование кэша с именем myCache до оптимизированного для вычислений экземпляра X20 (24 ГБ).

   Update-AzRedisEnterpriseCache -ResourceGroupName myGroup -Name myCache -Sku ComputeOptimized_X20

Масштабирование с помощью интерфейса командной строки Azure

Для масштабирования экземпляров Redis под управлением Azure с помощью Azure CLI, воспользуйтесь командой az redisenterprise update. Для выбора нужного уровня и SKU можно изменить свойство sku. В следующем примере демонстрируется масштабирование кэша с именем myCache до оптимизированного для вычислений экземпляра X20 (24 ГБ).

az redisenterprise update --cluster-name "myCache" --resource-group "myGroup" --sku "ComputeOptimized_X20"

Масштабирование: часто задаваемые вопросы

Следующий список содержит ответы на часто задаваемые вопросы о масштабировании Redis под управлением Azure.

Можно ли выполнить масштабирование в пределах одного уровня или только с переходом на другой уровень?

Вы всегда можете перейти на более высокий уровень производительности при том же объеме памяти или на больший объем памяти в рамках одного уровня производительности. О том, как масштабировать систему для перехода на более низкий уровень или уменьшения объема памяти см. в статье Условия и ограничения масштабирования Redis под управлением Azure.

Нужно ли менять имя кэша и ключи доступа после масштабирования?

Нет, имя кэша и ключи не изменяются во время операции масштабирования.

Как работает масштабирование?

  • При масштабировании экземпляра Redis один из узлов в кластере Redis завершает работу и повторно инициализируется с новым размером. Затем выполняется передача данных, а другой узел выполняет сходное аварийное переключение перед повторной инициализацией. Примерно то же самое выполняется во время установки исправлений или в случае сбоя одного из узлов кэша.
  • При масштабировании экземпляра с дополнительными виртуальными ЦП новые сегменты подготавливаются и добавляются в кластер серверов Redis. Затем она распределяет данные по всем сегментам.

Подробнее о сегментировании в Redis под управлением Azure см. в статье Конфигурация сегментирования.

Будут ли утеряны данные кэша при масштабировании?

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

Будет ли кэш доступен во время масштабирования?

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

Имеются ли ограничения на масштабирование, связанные с георепликацией?

Если настроена активная георепликация, то в одной группе георепликации не должны присутствовать кэши разных размеров. В результате масштабирование кэшей в группе георепликации требует нескольких дополнительных шагов. Инструкции см. в разделе Масштабирование экземпляров в группе георепликации.

Сколько времени занимает масштабирование?

Время операции масштабирования зависит от нескольких факторов. Ниже указан ряд факторов, от которых может зависеть время, затрачиваемое на масштабирование.

  • Объем данных: чем больше объем данных, тем больше времени требуется на репликацию
  • Большое количество запросов на запись: чем больше количество операций записи, тем больше данных нужно реплицировать между узлами или сегментами.
  • Высокая загрузка ЦП: более высокая загрузка ЦП означает, что сервер Redis занят и ограниченные циклы ЦП доступны для завершения распространения данных

Как правило, на масштабирование экземпляра без данных требуется приблизительно 10 минут.

Как узнать, когда масштабирование завершено?

На портале Azure вы увидите, как выполняется операция масштабирования. После завершения масштабирования состояние кэша изменяется на Работает.

Используется ли кластеризация в Redis под управлением Azure?

В отличие от Кэша Azure для Redis, в Redis под управлением Azure кластеризация применяется на всех уровнях и во всех SKU. Кластеризация существенно оптимизирует производительность. В каждом SKU Redis под управлением Azure настроено оптимизированное количество сегментов на количество доступных виртуальных ЦП. Количество сегментов не настраивается пользователем.

Сколько сегментов использует каждый SKU Redis под управлением Azure?

Redis под управлением Azure выполняется на основе ПО Redis Enterprise, поэтому сегменты можно использовать в более плотной конфигурации, чем в версии Redis Community. Количество сегментов в каждом SKU указано в разделе Конфигурация сегментирования.

Распределение ключей в кластере

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

  • Ключи с хэш-тегом. Если любая часть ключа заключена в фигурные скобки — { и }, — для определения хэш-слота ключа хэшируется только эта часть. Например, три ключа — {key}1, {key}2 и {key}3 — будут расположены в одном сегменте, так как хэшируется только часть имени key. Полный список спецификаций для хэш-тегов ключей см. в разделе Keys hash tags (Хэш-теги ключей).
  • Ключи без хэш-тега — для хэширования используется полное имя ключа, что приводит к статистическому равномерному распределению по сегментам кэша.

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

Дополнительные сведения см. в разделах Keys distribution model (Модель распределения ключей), Redis Cluster data sharding (Сегментирование данных в кластере Redis) и Keys hash tags (Хэш-теги ключей).

Каков максимальный размер кэша, который можно создать?

Самый большой размер кэша, который может быть равен 4,5 ТБ, называется оптимизированным для флэш-памяти экземпляром A4500. Цены на Кэш Azure для Redis.

Чем политики кластеров OSS и Enterprise отличаются друг от друга?

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

Следующие шаги