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

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

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

Уровни "Базовый", "Стандартный" и "Премиум" в Azure Cache для 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 реализует тот же API кластера Redis, что и уровни кэша Azure для 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 ГБ и меньше. Ниже приведены сценарии использования политики кластеризации Non-Clustered (предварительная версия):

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

Ниже приведены рекомендации по использованию политики без кластеризации (предварительная версия):

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

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

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

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

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

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

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

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

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

Замечание

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

Это важно

Все уровни памяти с объемом хранилища более 120 ГБ находятся в общедоступной предварительной версии, включая оптимизированные по памяти M150 и выше; сбалансированные B150 и выше; и оптимизированные по вычислениям X150 и выше. Все эти уровни и выше находятся в общедоступной предварительной версии.

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

Уровни	Оптимизация флэш-памяти (предварительная версия)	Оптимизация памяти	Сбалансированный	Оптимизировано для вычислений
Размер (ГБ)	vCPUs/основные фрагменты	vCPUs/основные фрагменты	vCPUs/основные фрагменты	vCPUs/основные фрагменты
0,5	-	-	2/1	-
1	-	-	2/1	-
3	-	-	2/2	4/2
6	-	-	2/2	4/2
12	-	2/2	4/2	8/6
двадцать четыре	-	4/2	8/6	16.12
шестьдесят	-	8/6	16.12	32/24
120	-	16.12	32/24	64/48
180 *	-	24/24	48/48	96/96
240 *	8/6	32/24	64/48	128/96
360 *	-	48/48	96/96	192/192
480 *	16.12	64/48	128/96	256/192
720 *	24/24	96/96	192/192	384/384
960 *	32/24	128/192	256/192	-
1440 *	48/48	192/192	-	-
1920 *	64/48	256/192	-	-
4500 *	144/96	-	-	-

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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