Масштабирование экземпляра Кэша Azure для Redis

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

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

Существует два способа масштабирования экземпляра Кэш Azure для Redis:

• Увеличение масштаба увеличивает размер виртуальной машины под управлением сервера Redis, добавляя больше памяти, виртуальные ЦП (виртуальные ЦП) и пропускную способность сети. Масштабирование также называется вертикальным масштабированием. Противоположность масштабирования — масштабирование вниз.

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

Область доступности

Уровень	"Базовый" и "Стандартный"	Премия	"Корпоративный" и Enterprise Flash
Увеличение масштаба	Да	Да	Да
Вертикальное уменьшение масштаба	Да	Да	Нет
Горизонтальное увеличение масштаба	Нет	Да	Да
Масштабирование в	Нет	Да	Нет

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

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

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

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

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

Примечание.

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

Предварительные требования и ограничения масштабирования Кэш Azure для Redis

Вы можете увеличить или уменьшить масштаб до другой ценовой категории с помощью следующих ограничений:

• Перейти с более высокой ценовой категории на более низкую нельзя.
  • Вы не можете масштабировать кэш Enterprise или Enterprise Flash до любого другого уровня.
  • Ценовую категорию кэша Премиум нельзя изменить на категорию Стандартный или Базовый.
  • Ценовую категорию кэша Стандартный нельзя изменить на категорию Базовый.
• Вы можете выполнить масштабирование кэша с уровня Базовый до уровня Стандартный, но вам не удастся одновременно с этим изменить размер кэша. Если требуется изменить размер, можно позднее выполнить операцию масштабирования до нужного размера.
• Ценовую категорию кэша Базовый нельзя изменить сразу на уровень Премиум. Сначала перейдите с категории Базовый на категорию Стандартный, а затем — с категории Стандартный на категорию Премиум.
• Невозможно масштабировать с большего размера до размера C0 (250 МБ). Однако вы можете масштабироваться до любого другого размера в пределах той же ценовой категории. Например, можно масштабировать с C5 уровня "Стандартный" до C1 "Стандартный".
• Вы не можете масштабировать кэш Уровня "Премиум", "Стандартный" или "Базовый" до кэша Enterprise или Enterprise Flash.
• Невозможно масштабировать между Enterprise и Enterprise Flash.

Вы можете масштабировать или масштабировать с помощью следующих ограничений:

• Горизонтальное масштабирование поддерживается только на уровнях Premium, Enterprise и Enterprise Flash.
• Масштабирование поддерживается только на уровне "Премиум".
• На уровне "Премиум" кластеризация должна быть включена сначала перед масштабированием или выходом.
• На уровне "Премиум" общедоступна поддержка масштабирования до 10 сегментов. Поддержка до 30 сегментов доступна в предварительной версии. (Для кэшей с двумя репликами ограничение сегментов равно 20. При использовании трех реплик ограничение сегментов равно 15.)
• Только уровни Enterprise и Enterprise Flash могут одновременно масштабироваться и масштабироваться.

Масштабирование уровней "Базовый", "Стандартный" и "Премиум"

Увеличение и уменьшение масштаба с помощью уровня "Базовый", "Стандартный" и "Премиум"

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

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

   

2. Выберите ценовую категорию в рабочей области и нажмите кнопку "Выбрать".

   

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

   

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

Примечание.

При масштабировании кэша вверх или вниз с помощью портала maxmemory-reserved оба параметра maxfragmentationmemory-reserved автоматически масштабируются в пропорции к размеру кэша. Например, если для параметра maxmemory-reserved задано значение 3 ГБ, размер кэша равен 6 ГБ и вы масштабируете увеличивает кэш до 12 ГБ, параметры автоматически обновляются до 6 ГБ во время масштабирования. При масштабировании в сторону уменьшения происходят изменения в обратном направлении.

Увеличение и уменьшение масштаба с помощью PowerShell

Вы можете масштабировать экземпляры Кэш Azure для Redis с помощью PowerShell с помощью командлета Set-AzRedisCache при Sizeизменении или Sku изменения свойств. В следующем примере показано, как масштабировать кэш с именем myCache в 6 ГБ кэша на том же уровне.

   Set-AzRedisCache -ResourceGroupName myGroup -Name myCache -Size 6GB

Дополнительные сведения о масштабировании с помощью PowerShell см. в разделе Масштабирование Кэша Azure для Redis с помощью PowerShell.

Увеличение и уменьшение масштаба с помощью Azure CLI

Чтобы масштабировать экземпляры Кэш Azure для Redis с помощью Azure CLI, вызовите команду az redis update. sku.capacity Используйте свойство для масштабирования на уровне, например из кэша Standard C0 до standard C1:

az redis update --cluster-name myCache --resource-group myGroup --set "sku.capacity"="2"

Используйте свойства "sku.name" и "sku.family", чтобы увеличить масштаб до другого уровня, например из кэша standard C1 в кэш Premium P1:

az redis update --cluster-name myCache --resource-group myGroup --set "sku.name"="Premium" "sku.capacity"="1" "sku.family"="P"

Дополнительные сведения о масштабировании с помощью Azure CLI см. в разделе Изменение параметров существующего кэша Azure для Redis.

Примечание.

При масштабировании кэша вверх или вниз программно (например, с помощью PowerShell или Azure CLI) любой maxmemory-reserved или maxfragmentationmemory-reserved игнорируется в рамках запроса на обновление. Учитывается только изменение масштабирования. Эти параметры памяти можно обновить после завершения операции масштабирования.

Горизонтальное масштабирование и только в категории "Премиум"

Создание кэша, масштабируемого с помощью кластеризации

Кластеризация включена во время создания кэша на рабочей панели при создании нового Кэш Azure для Redis.

1. Используйте краткое руководство по созданию кэша Redis с открытым кодом, чтобы начать создание кэша с помощью портал Azure.

2. На вкладке "Дополнительно " для экземпляра кэша уровня "Премиум" настройте параметры для порта, кластера и сохраняемости данных, отличных от TLS. Для включения кластеризации нажмите Включить.

   

   В кластере может быть до 30 сегментов. После выбора "Включить" ползунок или введите число в диапазоне от 1 до 30 для счетчика сегментов и нажмите кнопку "ОК".

   Каждый сегмент — это пара первичного или репликного кэша, управляемая Azure. Общий размер кэша вычисляется путем умножения числа сегментов на размер кэша, выбранный в ценовой категории.

   

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

3. Завершите создание кэша с помощью руководства по краткому руководству.

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

Примечание.

Существует ряд незначительных отличий, необходимых в клиентском приложении для настройки кластеризации. Дополнительные сведения см. в разделе Нужно ли вносить изменения в клиентское приложение, чтобы использовать кластеризацию?.

Пример кода по работе с кластеризацией клиента StackExchange.Redis см. в разделе clustering.cs примера Hello World.

Масштабирование запущенного кэша Уровня "Премиум" в или вне

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

Чтобы изменить размер кластера, используйте ползунок или введите число от 1 до 30 в текстовом поле счетчика сегментов . а затем нажмите кнопку ОК для сохранения изменений.

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

Горизонтальное масштабирование и использование PowerShell

Вы можете масштабировать экземпляры Кэш Azure для Redis с помощью PowerShell с помощью командлета Set-AzRedisCache при ShardCount изменении свойства. В следующем примере показано, как масштабировать кэш, именованный myCache для использования трех сегментов (т. е. масштабирование на три)

   Set-AzRedisCache -ResourceGroupName myGroup -Name myCache -ShardCount 3

Дополнительные сведения о масштабировании с помощью PowerShell см. в разделе Масштабирование Кэша Azure для Redis с помощью PowerShell.

Горизонтальное масштабирование и использование Azure CLI

Чтобы масштабировать экземпляры Кэш Azure для Redis с помощью Azure CLI, вызовите команду az redis update и используйте shard-count свойство. В следующем примере показано, как масштабировать кэш с именем myCache для использования трех сегментов (то есть масштабирование на три).

az redis update --cluster-name myCache --resource-group myGroup --set shard-count=3

Дополнительные сведения о масштабировании с помощью Azure CLI см. в разделе Изменение параметров существующего кэша Azure для Redis.

Примечание.

При программном масштабировании кэша (например, с помощью PowerShell или Azure CLI) любой maxmemory-reserved или maxfragmentationmemory-reserved игнорируется в рамках запроса на обновление. Учитывается только изменение масштабирования. Эти параметры памяти можно обновить после завершения операции масштабирования.

Примечание.

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

Масштабирование и увеличение масштаба — уровни Enterprise и Enterprise Flash

Уровни Enterprise и Enterprise Flash могут масштабироваться и масштабироваться в одной операции. Другие уровни требуют отдельных операций для каждого действия.

Внимание

Уровни Enterprise и Enterprise Flash еще не поддерживают операции снижения масштаба или уменьшения масштаба.

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

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

   

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

   Внимание

   Вы можете масштабироваться только в настоящее время. Вы не можете уменьшить масштаб.

   

3. Чтобы увеличить масштаб, увеличьте ползунок емкости . Емкость увеличивается на два. Это число отражает, сколько базовых узлов Redis Enterprise добавляются. Это число всегда является несколькими из двух для отображения узлов, добавляемых как для основных, так и для сегментов реплики.

   Внимание

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

   

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

   

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

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

Вы можете масштабировать экземпляры Кэш Azure для Redis с помощью PowerShell с помощью командлета Update-AzRedisEnterpriseCache. Свойство можно изменить Sku , чтобы масштабировать экземпляр вверх. Свойство можно изменить Capacity , чтобы масштабировать экземпляр. В следующем примере показано, как масштабировать кэш с именем myCache экземпляра Enterprise E20 (25 ГБ) с емкостью 4.

   Update-AzRedisEnterpriseCache -ResourceGroupName myGroup -Name myCache -Sku Enterprise_E20 -Capacity 4

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

Чтобы масштабировать экземпляры Кэш Azure для Redis с помощью Azure CLI, вызовите команду az redisenterprise update. Свойство можно изменить sku , чтобы масштабировать экземпляр вверх. Свойство можно изменить capacity , чтобы масштабировать экземпляр. В следующем примере показано, как масштабировать кэш с именем myCache экземпляра Enterprise E20 (25 ГБ) с емкостью 4.

az redisenterprise update --cluster-name "myCache" --resource-group "myGroup" --sku "Enterprise_E20" --capacity 4

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

В приведенном ниже списке представлены ответы на часто задаваемые вопросы о масштабировании кэша Azure для Redis.

• Можно ли выполнять масштабирование кэша до уровня Премиум, с уровня Премиум до другого уровня или в пределах уровня Премиум?
• Нужно ли менять имя кэша и ключи доступа после масштабирования?
• Как работает масштабирование?
• Будут ли утеряны данные кэша при масштабировании?
• Можно ли использовать все функции уровня "Премиум" после масштабирования?
• Что происходит с пользовательским параметром databases при масштабировании?
• Доступен ли кэш во время масштабирования?
• Имеются ли ограничения на масштабирование, связанные с георепликацией?
• Неподдерживаемые операции
• Сколько времени занимает масштабирование?
• Как узнать, когда масштабирование завершено?
• Нужно ли вносить изменения в клиентское приложение, чтобы использовать кластеризацию?
• Распределение ключей в кластере
• Каков максимальный размер кэша, который можно создать?
• Все ли клиенты Redis поддерживают кластеризацию?
• Как подключиться к кэшу, если кластеризация включена?
• Можно ли напрямую подключаться к отдельным сегментам кэша?
• Можно ли настроить кластеризацию для ранее созданного кэша?
• Можно ли настроить кластеризацию для кэша уровней Базовый и Стандартный?
• Можно ли использовать кластеризацию с поставщиками состояний сеансов и кэширования выходных данных ASP.NET Redis?
• Что делать если при использовании StackExchange.Redis и кластеризации порождаются исключения MOVE?
• В чем разница между кластеризациям OSS и корпоративным кластеризациям в кэшах корпоративного уровня?
• Сколько сегментов используют кэши уровня Enterprise?

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

• Ценовую категорию кэша Премиум нельзя изменить на категорию Базовый или Стандартный.
• Вы можете переходить от одной ценовой категории кэша Премиум к другой.
• Ценовую категорию кэша Базовый нельзя изменить сразу на уровень Премиум. Сначала перейдите с категории Базовый на категорию Стандартный, а затем — с категории Стандартный на категорию Премиум.
• Вы не можете масштабировать кэш Уровня "Премиум" до кэша Enterprise или Enterprise Flash.
• Если вы включили кластеризацию при создании кэша Premium , можно изменить размер кластера. Если кэш создан без кластеризации, ее можно будет настроить позже.

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

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

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

• При масштабировании кэша "Базовый " до другого размера кэш завершает работу, а новый кэш подготавливается с помощью нового размера. В течение этого времени кэш недоступен и все данные в кэше теряются.
• При масштабировании кэша уровня Базовый до уровня Стандартный система подготавливает реплику кэша. При этом данные будут скопированы из основного кэша в реплику кэша. Кэш остается доступным в процессе масштабирования.
• При масштабировании кэша Standard, Premium, Enterprise или Enterprise Flash до другого размера одна из реплик завершается и перепроиздается до нового размера и передаваемых данных, а затем другая реплика выполняет отработку отказа до его повторной подготовки, аналогично процессу, возникающего во время сбоя одного из узлов кэша.
• При горизонтальном масштабировании кластеризованного кэша система подготавливает новые сегменты и добавляет их в кластер серверов Redis. Затем она распределяет данные по всем сегментам.
• При уменьшении масштаба в кластеризованном кэше система повторно распределяет данные по сегментам, а затем уменьшает размер кластера до требуемого количества сегментов.
• При масштабировании или переносе кэша в другой кластер базовый IP-адрес кэша может измениться. Запись DNS для кэша изменяется и является прозрачной для большинства приложений. Однако если вы используете IP-адрес для настройки подключения к кэшу или настройки групп безопасности сети или брандмауэров, которые позволяют трафику в кэш, ваше приложение может столкнуться с проблемами при подключении после обновления записи DNS.

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

• При масштабировании кэша уровня Базовый до другого размера все данные будут утеряны. Во время операции масштабирования кэш будет недоступен.
• При масштабировании кэша уровня Базовый до уровня Стандартный данные в кэше обычно сохраняются.
• При масштабировании кэша Standard, Premium, Enterprise или Enterprise Flash до большего размера все данные обычно сохраняются. При масштабировании кэша уровня "Стандартный" или "Премиум" данные могут быть потеряны, если исходный размер данных превышает новый меньший размер. При потере данных во время масштабирования до меньшего размера ключи вытесняются с помощью политики вытеснения allkeys-lru .

Можно ли использовать все функции уровня "Премиум" после масштабирования?

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

Эти функции нельзя добавить после создания кэша Premium:

• Внедрение виртуальных сетей
• Добавление избыточности зоны
• Использование нескольких реплик на основную

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

Что происходит с пользовательским параметром databases при масштабировании?

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

• При масштабировании на ценовую категорию с меньшим databases ограничением, чем текущий уровень:
  • Если вы используете заданное по умолчанию количество databases (16 для всех ценовых категорий), то данные не теряются.
  • Если вы используете настраиваемое количество databases (в пределах ограничений уровня, до которого выполняется масштабирование), значение databases будет сохранено и данные не будут утеряны.
  • Если вы используете настраиваемое количество databases (которое превышает ограничения нового уровня), значение databases будет уменьшено в соответствии с новым уровнем, а все данные в удаленных базах данных будут утеряны.
• При масштабировании до ценовой категории с равным или более высоким значением databases по сравнению с текущим уровнем значение databases будет сохранено, а данные не будут утеряны.

Хотя кэши Standard, Premium, Enterprise и Enterprise Flash имеют соглашение об уровне обслуживания для доступности, соглашение об уровне обслуживания для потери данных отсутствует.

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

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

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

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

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

Неподдерживаемые операции

• Перейти с более высокой ценовой категории на более низкую нельзя.
  • Ценовую категорию кэша Премиум нельзя изменить на категорию Стандартный или Базовый.
  • Ценовую категорию кэша Стандартный нельзя изменить на категорию Базовый.
• Вы можете выполнить масштабирование кэша с уровня Базовый до уровня Стандартный, но вам не удастся одновременно с этим изменить размер кэша. Если требуется изменить размер, можно позднее выполнить операцию масштабирования до нужного размера.
• Ценовую категорию кэша Базовый нельзя изменить сразу на уровень Премиум. Сначала выполните масштабирование с категории Базовый на категорию Стандартный, а затем — с категории Стандартный на категорию Премиум.
• Вы не можете масштабировать кэш Уровня "Премиум" до кэша Enterprise или Enterprise Flash.
• Вам не удастся выполнить масштабирование с большего размера до размера C0 (250 МБ) .

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

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

Время операции масштабирования зависит от нескольких факторов. Следующие факторы могут повлиять на время масштабирования:

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

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

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

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

Нужно ли вносить изменения в клиентское приложение, чтобы использовать кластеризацию?

• Если кластеризация включена, доступна только база данных 0. Если клиентское приложение использует несколько баз данных и пытается считывать или записывать в базу данных, отличной от нуля, возникает следующее исключение: Unhandled Exception: StackExchange.Redis.RedisConnectionException: ProtocolFailure on GET --->StackExchange.Redis.RedisCommandException: Multiple databases are not supported on this server; cannot switch to database: 6

  Дополнительные сведения см. в разделе "Implemented subset" (Реализованное подмножество) статьи Redis Cluster Specification (Спецификация кластера Redis).

• Если вы используете клиент StackExchange.Redis, необходимо установить версию 1.0.481 или более позднюю. Вы можете подключаться к кэшу с помощью тех же конечных точек, портов и ключей, которые используются для подключения к кэшу с отключенной кластеризацией. Единственное отличие заключается в том, что все операции чтения и записи должны выполняться в базе данных 0.

  Другие клиенты могут иметь разные требования. Смотрите Поддерживают ли все клиенты Redis кластеризацию? для получения дополнительной информации.

• Если приложение использует несколько операций с ключом, объединенных в одну команду, все ключи должны быть расположены в одном сегменте. Сведения о поиске ключей в одном сегменте см. в разделе "Как распределяются ключи в кластере?".

• Если вы используете поставщик состояний сеансов ASP.NET Redis, вам необходимо установить версию 2.0.1 или более позднюю версию. Дополнительную информацию см. в разделе "Можно ли использовать кластеризацию с поставщиками ASP.NET для состояния сеанса и кэширования выходных данных Redis?"

Внимание

При использовании уровней FLash enterprise или Enterprise вы можете выбрать режим кластера OSS или корпоративный кластерный режим. Режим кластера OSS совпадает с кластеризации на уровне "Премиум" и соответствует спецификации кластеризации открытый код. Режим корпоративного кластера может быть менее производительным, но использует кластеризацию Redis Enterprise, которая не требует каких-либо изменений клиента для использования. Дополнительные сведения см. в разделе "Кластеризация".

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

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

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

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

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

Пример кода по работе с кластеризацией и поиска ключей в одном сегменте для клиента StackExchange.Redis см. в части clustering.cs примера Hello World.

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

Максимальный размер кэша, который можно использовать, составляет 4,5 ТБ. Этот результат представляет собой кластеризованный кэш F1500 с емкостью 9. Дополнительные сведения см. на странице Цены на Кэш Azure для Redis.

Все ли клиенты Redis поддерживают кластеризацию?

Многие клиентские библиотеки поддерживают кластеризацию Redis, но не все. Проверьте документацию по используемой вами библиотеке и убедитесь, что вы используете библиотеку и версию, которые поддерживают функцию кластеризации. StackExchange.Redis - это одна из библиотек, которая поддерживает кластеризацию в ее новых версиях. Дополнительные сведения о других клиентах см. в разделе Playing with the cluster (Эксперименты с кластером) руководства по кластерам Redis.

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

Примечание.

Если вы используете StackExchange.Redis в качестве клиента, убедитесь, что вы используете последнюю версию StackExchange.Redis 1.0.481 или более поздней для правильной работы кластеризации. Ознакомьтесь с дополнительными сведениями о проблемах с исключениями MOVE.

Как подключиться к кэшу, если кластеризация включена?

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

Можно ли напрямую подключаться к отдельным сегментам кэша?

Для протокола кластеризации требуется, чтобы клиент установил правильные подключения к сегментам, поэтому клиент должен предоставить вам доступ к общим подключениям. Тем не менее каждый сегмент включает пару, которая включает основной кэш и его реплику и называется экземпляром кэша. Вы можете подключиться к этим экземплярам кэша с помощью служебной программы Redis-CLI в нестабильной ветви репозитория Redis на сайте GitHub. Эта версия реализует базовую поддержку при запуске с параметром -c. Дополнительные сведения см. в разделе Игра с кластером на странице https://redis.io в Руководстве по кластерам Redis .

Необходимо использовать переключатель, чтобы указать правильный -p порт для подключения. Используйте команду CLUSTER NODES, чтобы определить точные порты, используемые для основных узлов и реплик. Используются следующие диапазоны портов:

• Для кэшей уровня "Премиум" не TLS порты доступны в диапазоне 130XX .
• Для кэшей уровня "Премиум" с поддержкой TLS порты доступны в диапазоне 150XX
• Для кэшей Enterprise и Enterprise Flash с помощью кластеризации OSS начальное подключение осуществляется через порт 10000. Подключение к отдельным узлам можно сделать с помощью портов в диапазоне 85XX. Порты 85xx будут изменяться со временем и не должны быть жестко закодированы в приложение.

Можно ли настроить кластеризацию для ранее созданного кэша?

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

Внимание

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

Все кэши уровня Enterprise и Enterprise Flash всегда кластеризованы.

Можно ли настроить кластеризацию для кэша уровней Базовый и Стандартный?

Кластеризация доступна только для кэшей Premium, Enterprise и Enterprise Flash.

Можно ли использовать кластеризацию с поставщиками состояний сеансов и кэширования выходных данных ASP.NET Redis?

• Поставщик кэша вывода Redis — изменения не требуются.
• Поставщик состояний сеансов Redis — для кластеризации необходимо использовать RedisSessionStateProvider 2.0.1 или более поздней версии. В противном случае будет порождено исключение, так как это критическое изменение. Дополнительные сведения см. в подробном описании критических изменений версии 2.0.0.

Что делать если при использовании StackExchange.Redis и кластеризации порождаются исключения MOVE?

Если вы применяете StackExchange.Redis и получаете исключения MOVE при кластеризации, убедитесь, что вы используете StackExchange.Redis 1.1.603 или более позднюю версию.

Какова разница между кластеризациям OSS и корпоративным кластеризациям в кэшах уровня Enterprise?

Режим кластера OSS совпадает с кластеризации на уровне "Премиум" и соответствует спецификации кластеризации открытый код. Режим кластера предприятия может быть менее производительным, но использует кластеризацию Redis Enterprise, которая не требует каких-либо изменений клиента для использования. Дополнительные сведения см. в разделе "Кластеризация".

Сколько сегментов используют кэши уровня Enterprise?

В отличие от кэшей уровня "Базовый", "Стандартный" и "Премиум", кэшей Enterprise и Enterprise Flash можно использовать несколько сегментов на одном узле. Дополнительные сведения см. в разделе "Конфигурация сегментирования".

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

• Настройка параметра maxmemory-reserved
• Рекомендации для масштабирования