Лучшие практики для типов Enterprise и Enterprise Flash

Вот лучшие практики использования уровней Enterprise и Enterprise Flash кэша Azure Redis.

Зоневая избыточность

Мы настоятельно рекомендуем развертывать новые кэши в конфигурации с избыточностью зон. Резервирование зоны гарантирует, что узлы Redis Enterprise распределяются между тремя зонами доступности, повышая устойчивость к сбоям на уровне центра обработки данных. Использование зональной избыточности повышает доступность. Дополнительные сведения см. в соглашениях об уровне обслуживания (SLA) для веб-служб.

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

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

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

В уровнях корпоративного и корпоративного флэш-памяти Azure Cache for Redis мы рекомендуем приоритизировать масштабирование вверх над масштабированием наружу. Приоритизация масштабирования вверх потому, что уровни Enterprise построены на Redis Enterprise, который способен использовать больше ядер ЦП в больших виртуальных машинах.

И наоборот, обратная рекомендация относится к уровням "Базовый", "Стандартный" и "Премиум", созданным на основе Redis с открытым исходным кодом. На этих уровнях в большинстве случаев рекомендуется отдавать приоритет масштабированию горизонтальному вместо масштабирования вертикального.

Сегментирование и использование ЦП

В уровнях "Базовый", "Стандартный" и "Премиум" Azure Cache для Redis определение количества используемых виртуальных процессоров ЦП происходит легко. Каждый узел Redis выполняется на выделенной виртуальной машине. Процесс сервера Redis является однопоточным, используя один виртуальный ЦП на каждом первичном и каждом узле реплики. Другие виртуальные ЦП на виртуальной машине по-прежнему используются для других действий, таких как координация рабочих процессов для различных задач, мониторинга работоспособности и загрузки TLS, среди прочего.

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

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

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

E1

E5

E10

E20

E50

E100

E200

E400

F300

F700

F1500

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

Уровни Enterprise и Enterprise Flash изначально кластеризованы в отличие от уровней "Базовый", "Стандартный" и "Премиум". Реализация зависит от выбранной политики кластеризации. Уровни enterprise предлагают два варианта политики кластеризации: OSS и Enterprise. Для большинства приложений рекомендуется использовать политику кластера OSS , так как она поддерживает более высокую максимальную пропускную способность, но есть преимущества и недостатки для каждой версии.

Политика кластеризации OSS реализует такой же API Redis Cluster, как и Redis с открытым исходным кодом. API кластера Redis позволяет клиенту Redis подключаться непосредственно к каждому узлу Redis, минимизируя задержку и оптимизируя пропускную способность сети. В результате при масштабировании кластера с большим числом узлов получается почти линейная масштабируемость. Политика кластеризации OSS обычно обеспечивает лучшую задержку и производительность пропускной способности, но требует, чтобы клиентская библиотека поддерживала кластеризацию Redis. Политика кластеризации OSS также не может использоваться с модулем RediSearch.

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

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

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

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

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

Рекомендации по корпоративной флэш-памяти

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

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

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

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

Рабочие нагрузки, оптимально подходящие для уровня Enterprise Flash

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

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

Рабочие нагрузки, которые не подходят для уровня Enterprise Flash

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

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

Обработка сценариев уменьшения региона с активной георепликацией

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

Например, рассмотрим следующие советы:

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

Кроме того, можно использовать шаблон автоматического выключателя. Используйте шаблон для автоматического перенаправления трафика от кэша, испытывающего сбой в регионе, на резервный кэш в той же группе георепликации. Используйте службы Azure, такие как Диспетчер трафика Azure или Azure Load Balancer, чтобы включить перенаправление.

Сохраняемость данных и резервное копирование данных

Функция сохраняемости данных на уровнях Enterprise и Enterprise Flash предназначена для автоматического предоставления точки быстрого восстановления данных при сходе кэша. Быстрое восстановление возможно путем хранения RDB или AOF-файла на управляемом диске, подключенном к экземпляру кэша. Файлы постоянного хранения на диске недоступны пользователям.

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

Ограничения SKU E1

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

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

• Разработка