Архитектура Управляемого Redis в Azure

Управляемый Redis Azure работает в стеке Redis Enterprise, что обеспечивает значительные преимущества по сравнению с сообществом Redis. Ниже приведены более подробные сведения о архитектуре Управляемого Redis в Azure, включая сведения, которые могут быть полезны для пользователей.

Сравнение с Azure Cache для Redis

Кэш Azure для Redis в тарифных планах "Базовый", "Стандартный" и "Премиум" работает на сообществе Redis. В этом сообществе выпуск Redis имеет несколько значительных ограничений, включая то, что он однопоточный. Это ограничение значительно снижает производительность и делает масштабирование менее эффективным, так как служба не полностью использует виртуальные ЦП. Типичный экземпляр Azure Cache for Redis использует следующую архитектуру:

Обратите внимание, что используются две виртуальные машины — первичная и реплика. Эти виртуальные машины также называются узлами. Основной узел содержит основной процесс Redis и принимает все записи. Репликация выполняется асинхронно на узле реплики, чтобы обеспечить резервную копию во время обслуживания, масштабирования или непредвиденных сбоев. Каждый узел может выполнять только один процесс сервера Redis из-за однопоточной разработки сообщества Redis.

Улучшения архитектуры Управляемого Redis в Azure

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

Существует несколько различий:

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

Эта архитектура обеспечивает как более высокую производительность, так и расширенные функции, такие как активная георепликация.

Кластеризация

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

Политики кластера

Управляемый Redis Azure предлагает три политики кластеризации: OSS, Enterprise и Non-Clustered. Политика кластера OSS хороша для большинства приложений, так как она поддерживает более высокую максимальную пропускную способность, но каждая версия имеет свои собственные преимущества и недостатки.

• Если вы переходите из некластеризованной топологии уровня "Базовый", "Стандартный" или "Премиум", рекомендуется использовать кластеризацию OSS для повышения производительности. Используйте некластеризованные конфигурации, только если приложение не может поддерживать топологии OSS или Enterprise. Политика кластеризации OSS реализует тот же API, что и программное обеспечение Redis с открытым исходным кодом. API кластера Redis позволяет клиенту Redis подключаться непосредственно к сегментам на каждом узле Redis, минимизируя задержку и оптимизируя пропускную способность сети. Пропускная способность масштабируется почти линейно по мере увеличения числа сегментов и виртуальных ЦП. Политика кластеризации OSS обычно обеспечивает наименьшую задержку и лучшую производительность пропускной способности. Однако политика кластера OSS требует, чтобы клиентская библиотека поддерживала API кластера Redis. Сегодня почти все клиенты Redis поддерживают API кластера Redis, но совместимость может быть проблемой для старых версий клиентов или специализированных библиотек.

Нельзя использовать политику кластеризации OSS с модулем RediSearch.

Протокол кластеризации OSS требует от клиента установить правильные подключения шардов. Начальное подключение осуществляется через порт 10000. Подключение к отдельным узлам использует порты в диапазоне 85XX. Порты 85xx могут изменяться со временем, и их не следует жестко закодировать в приложение. Клиенты Redis, поддерживающие кластеризацию, используют команду CLUSTER NODES, чтобы определить точные порты, используемые для первичных и реплик сегментов, и осуществить подключение к сегментам.

Политика кластеризации предприятия — это более простая конфигурация, которая использует одну конечную точку для всех клиентских подключений. При использовании политики кластеризации Enterprise он направляет все запросы на один узел Redis, который выступает в качестве прокси-сервера. Этот узел внутренне направляет запросы на правильный узел в кластере. Преимущество этого подхода заключается в том, что он делает сервис Azure Managed Redis для пользователей некластеризованным. Это означает, что клиентские библиотеки Redis не должны поддерживать кластеризацию Redis, чтобы получить некоторые преимущества производительности Redis Enterprise. Использование одной конечной точки повышает обратную совместимость и упрощает подключение. Недостатком является то, что одноузловой прокси-сервер может быть узким местом в использовании вычислений или пропускной способности сети.

Политика кластеризации Enterprise — это единственная, которую можно использовать с модулем RediSearch. Хотя политика корпоративного кластера делает экземпляр Azure Managed Redis выглядящим некластеризованным для пользователей, он по-прежнему имеет некоторые ограничения на использование команд с несколькими ключами.

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

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

Рекомендации по использованию некластеризованной политики:

• Эта политика применяется только к уровням Управляемого Azure Redis, которые меньше или равны 25 ГБ.
• Это не так же производительно, как и другие политики кластеризации, так как ЦП может выполнять многопоточные операции только с программным обеспечением Redis Enterprise, если кэш сегментирован.
• Если вы хотите увеличить масштаб кэша Redis в Azure, необходимо сначала изменить политику кластера.
• Если вы переходите из некластеризованной топологии уровня "Базовый", "Стандартный" или "Премиум", рекомендуется использовать кластеры OSS для повышения производительности. Используйте некластеризованные конфигурации, только если приложение не может поддерживать топологии OSS или Enterprise.

Масштабирование или добавление узлов

Основное программное обеспечение Redis Enterprise масштабируется с помощью более крупных виртуальных машин или масштабируется путем добавления дополнительных узлов или виртуальных машин. Оба параметра масштабирования добавляют больше памяти, больше виртуальных ЦПУ и больше шардов. Из-за этой избыточности Azure Managed Redis не предоставляет возможность контролировать определенное количество узлов, используемых в каждой конфигурации. Эта информация о реализации абстрагируется, чтобы избежать путаницы, сложности и неоптимальных конфигураций. Вместо этого каждый SKU разработан с конфигурацией узла, которая максимизирует виртуальные процессоры и память. Некоторые SKU управляемого Redis Azure используют два узла, а другие используют больше.

Команды с несколькими ключами

Так как управляемые экземпляры Redis в Azure используют кластерную конфигурацию, вы можете увидеть CROSSSLOT исключения на команды, работающие с несколькими ключами. Поведение зависит от используемой политики кластеризации. Если вы используете политику кластеризации OSS, все ключи в командах multikey должны сопоставляться с тем же хэш-слотом.

При использовании политики кластеризации Enterprise также могут возникнуть ошибки CROSSSLOT. Только следующие команды с несколькими ключами разрешены в слотах с кластеризацией Enterprise: DEL, MSET, MGET, EXISTS, UNLINK, и TOUCH.

В базах данных Active-Active команды записи с несколькими ключами (DEL, MSET, ) UNLINKмогут выполняться только на ключах, которые находятся в одном слоте. Однако в Active-Active базах данных разрешены следующие команды с несколькими ключами: MGET, EXISTS и TOUCH. Дополнительные сведения см. в разделе Кластеризация баз данных.

Конфигурация шардинга

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

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

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

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

Чтобы увеличить количество частей для SKU, используйте более высокий уровень для этой SKU. Вы также можете изменить номера SKU в соответствии с потребностями производительности.

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

Замечание

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

Оптимизированные для памяти, балансированные и оптимизированные для вычислений версии

В этой таблице показан общий пример соотношения размера и виртуальных ЦПУ/основных сегментов.

Уровни	Оптимизация памяти	Сбалансированный	Оптимизировано для вычислений
Размер (ГБ)	vCPUs/основные фрагменты	vCPUs/основные фрагменты	vCPUs/основные фрагменты
24¹	4/2	8/6	16.12
60 сноска 1	8/6	16.12	32/24

¹ Соотношение виртуальных ЦП к основным сегментам на заданном размере уровня не представляет гарантии для SKU или уровня.

Оптимизированная для флэш-памяти версия

В этой таблице показан общий пример соотношения размера и виртуальных ЦПУ/основных сегментов.

Уровни	Оптимизация флэш-памяти (предварительная версия)
Размер (ГБ)	vCPUs/основные фрагменты
480 ¹ ²	16.12
720 ¹ 2	24/24

¹ Эти уровни находятся в общедоступной предварительной версии.

2. Отношение виртуальных ЦП к основным сегментам с заданным размером уровня не представляет гарантии для номера SKU или уровня.

Это важно

Все уровни памяти, использующие более 350 ГБ хранилища, находятся в общедоступной предварительной версии, включая оптимизированные для памяти M500 и выше; сбалансированные B500 и выше; и вычислительно оптимизированные X500 и выше. Все эти уровни и выше находятся в общедоступной предварительной версии.

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

Запуск без включения режима высокой доступности

Режим высокой доступности (HA) можно запускать без включения. Эта конфигурация означает, что экземпляр Redis не включает репликацию и не имеет доступа к SLA доступности. Не выполняйтесь в режиме, отличном от высокого уровня доступности, вне сценариев разработки и тестирования. Вы не можете отключить высокую доступность в уже созданном экземпляре. Вы можете включить высокий уровень доступности в экземпляре, где она отсутствует. Так как экземпляр, работающий без высокой доступности, использует меньше виртуальных машин и узлов, виртуальные ЦП не используются так эффективно, поэтому производительность может быть ниже.

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

Зарезервированная память

В каждом управляемом экземпляре Redis Azure приблизительно 20% доступной памяти зарезервировано в качестве буфера для операций, не связанных с кэшем, таких как репликация во время отработки отказа и буфер активной георепликации. Этот буфер помогает повысить производительность кэша и предотвратить нехватку памяти.

Уменьшение масштаба

Уменьшение масштаба в настоящее время не поддерживается в Azure Управляемой Базе Redis. Дополнительные сведения см. в разделе "Ограничения масштабирования Управляемого Redis Azure".

Класс "Оптимизировано для флэш-памяти"

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

В экземплярах, оптимизированных для флэш-памяти, 20 % кэша находится в ОЗУ, а в других 80% используется хранилище Flash. Все ключи хранятся в ОЗУ, а значения могут храниться в хранилище Флэш-памяти или ОЗУ. Программное обеспечение Redis интеллектуально определяет расположение значений. Горячие значения, к которым часто обращаются, хранятся в ОЗУ, а холодные значения, которые реже используются, хранятся в Flash. Прежде чем данные читаются или записываются, их необходимо переместить в ОЗУ, становясь горячими данными.

Так как Redis оптимизирует оптимальную производительность, экземпляр сначала заполняет доступную ОЗУ перед добавлением элементов в хранилище Flash. Заполнение ОЗУ в первую очередь имеет несколько последствий для производительности:

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

Рабочие нагрузки хорошо подходят для уровня, оптимизированного под флэш-память

Рабочие нагрузки, которые выполняются хорошо на уровне Flash Optimized, часто имеют следующие характеристики:

• Чтение с большим количеством операций чтения с высоким соотношением команд чтения для записи команд.
• Доступ ориентирован на подмножество ключей, которые используются гораздо чаще, чем остальная часть набора данных.
• Относительно большие значения по сравнению с именами ключей. (Так как имена ключей всегда хранятся в ОЗУ, большие значения могут стать узким местом для роста памяти.)

Рабочие нагрузки, которые плохо подходят для уровня "Оптимизированный для флэш-памяти"

Некоторые рабочие нагрузки имеют характеристики доступа, которые менее оптимизированы для проектирования оптимизированного уровня Flash:

• Создание сложных задач.
• Случайные или универсальные шаблоны доступа к данным в большинстве наборов данных.
• Длинные имена ключей с относительно небольшими размерами значений.

Связанный контент

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