Рекомендации по уровням Enterprise и Enterprise Flash
Ниже приведены рекомендации по использованию уровней Enterprise и Enterprise Flash Кэш Azure для Redis.
Избыточность между зонами
Настоятельно рекомендуется развертывать новые кэши в конфигурации, избыточной между зонами. Избыточность зоны гарантирует, что узлы Redis Enterprise распределяются между тремя зонами доступности, повышая избыточность от сбоев на уровне центра обработки данных. Использование избыточности зоны повышает доступность. Дополнительные сведения см. в соглашениях об уровне обслуживания (SLA) для веб-служб.
Избыточность зоны важна на уровне Enterprise, так как экземпляр кэша всегда использует не менее трех узлов. Два узла — это узлы данных, в которых хранятся данные, а также узел кворума. Увеличение емкости масштабирует количество узлов данных в четных числах.
Существует также другой узел, называемый узлом кворума. Этот узел отслеживает узлы данных и автоматически выбирает новый первичный узел, если произошел отработка отказа. Избыточность зоны гарантирует равномерное распределение узлов между тремя зонами доступности, минимизируя вероятность потери кворума. Клиентам не взимается плата за узел кворума, и плата за использование избыточности между зонами не взимается за внутризональную пропускную способность.
Масштабирование
В уровнях корпоративной и корпоративной флэш-памяти Кэш Azure для Redis рекомендуется приоритизировать масштабирование по сравнению с масштабированием. Приоритет масштабирования, так как уровни Enterprise основаны на Redis Enterprise, что позволяет использовать больше ядер ЦП в больших виртуальных машинах.
И наоборот, обратная рекомендация относится к уровням "Базовый", "Стандартный" и "Премиум", созданным на основе Redis с открытым исходным кодом. В этих уровнях приоритет масштабирования по сравнению с масштабированием рекомендуется в большинстве случаев.
Сегментирование и использование ЦП
В уровнях "Базовый", "Стандартный" и "Премиум" Кэш Azure для Redis определение количества используемых виртуальных ЦП является простым. Каждый узел Redis выполняется на выделенной виртуальной машине. Процесс сервера Redis является однопоточным, используя один виртуальный ЦП на каждом первичном и каждом узле реплика. Другие виртуальные ЦП на виртуальной машине по-прежнему используются для других действий, таких как координация рабочих процессов для различных задач, мониторинга работоспособности и загрузки TLS, среди прочего.
При использовании кластеризация эффект заключается в распространении данных по нескольким узлам с одним сегментом на узел. Увеличив количество сегментов, вы линейно увеличиваете количество используемых виртуальных ЦП на основе количества сегментов в кластере.
С другой стороны, Redis Enterprise может использовать несколько виртуальных ЦП для самого экземпляра Redis. Другими словами, все уровни Кэш Azure для Redis могут использовать несколько виртуальных ЦП для фоновых и мониторинговых задач, но только уровни Enterprise и Enterprise Flash могут использовать несколько виртуальных ЦП на каждую виртуальную машину для сегментов Redis. В таблице показано количество эффективных виртуальных ЦП, используемых для каждой конфигурации SKU и емкости (то есть горизонтального масштабирования).
В таблицах показано количество виртуальных ЦП, используемых для основных сегментов, а не реплика сегментов. Сегменты не сопоставляют один к одному числу виртуальных ЦП. В таблицах показаны только виртуальные ЦП, а не сегменты. Некоторые конфигурации используют больше сегментов, чем доступные виртуальные ЦП для повышения производительности в некоторых сценариях использования.
E5
| Capacity | Эффективные виртуальные ЦП |
|---|---|
| 2 | 1 |
| 4 | 2 |
| 6 | 6 |
E10
| Capacity | Эффективные виртуальные ЦП |
|---|---|
| 2 | 2 |
| 4 | 6 |
| 6 | 6 |
| 8 | 16 |
| 10 | 20 |
E20
| Capacity | Эффективные виртуальные ЦП |
|---|---|
| 2 | 2 |
| 4 | 6 |
| 6 | 6 |
| 8 | 16 |
| 10 | 20 |
E50
| Capacity | Эффективные виртуальные ЦП |
|---|---|
| 2 | 6 |
| 4 | 6 |
| 6 | 6 |
| 8 | 30 |
| 10 | 30 |
E100
| Capacity | Эффективные виртуальные ЦП |
|---|---|
| 2 | 6 |
| 4 | 30 |
| 6 | 30 |
| 8 | 30 |
| 10 | 30 |
E200
| Capacity | Эффективные виртуальные ЦП |
|---|---|
| 2 | 30 |
| 4 | 60 |
| 6 | 60 |
| 8 | 120 |
| 10 | 120 |
E400
| Capacity | Эффективные виртуальные ЦП |
|---|---|
| 2 | 60 |
| 4 | 120 |
| 6 | 120 |
| 8 | 240 |
| 10 | 240 |
F300
| Capacity | Эффективные виртуальные ЦП |
|---|---|
| 3 | 6 |
| 9 | 30 |
F700
| Capacity | Эффективные виртуальные ЦП |
|---|---|
| 3 | 30 |
| 9 | 30 |
F1500
| Capacity | Эффективные виртуальные ЦП |
|---|---|
| 3 | 30 |
| 9 | 90 |
Кластеризация в Enterprise
Уровни Enterprise и Enterprise Flash изначально кластеризованы в отличие от уровней "Базовый", "Стандартный" и "Премиум". Реализация зависит от выбранной политики кластеризация. Уровни enterprise предлагают два варианта политики кластеризации: OSS и Enterprise. Для большинства приложений рекомендуется использовать политику кластера OSS , так как она поддерживает более высокую максимальную пропускную способность, но есть преимущества и недостатки для каждой версии.
Политика osS кластеризация реализует тот же API кластера Redis, что и Redis с открытым исходным кодом. API кластера Redis позволяет клиенту Redis подключаться непосредственно к каждому узлу Redis, минимизируя задержку и оптимизируя пропускную способность сети. В результате при масштабировании кластера с большим числом узлов получается почти линейная масштабируемость. Политика OSS кластеризация обычно обеспечивает лучшую задержку и производительность пропускной способности, но требует, чтобы клиентская библиотека поддерживала кластеризацию Redis. Политику кластеризация OSS также нельзя использовать с модулем RediSearch.
Политика корпоративной кластеризация — это более простая конфигурация, которая использует одну конечную точку для всех клиентских подключений. Использование политики Enterprise кластеризация направляет все запросы к одному узлу Redis, который затем используется в качестве прокси-сервера, внутренние запросы маршрутизации на правильный узел в кластере. Преимущество этого подхода заключается в том, что клиентские библиотеки Redis не должны поддерживать кластеризацию Redis, чтобы воспользоваться преимуществами нескольких узлов. Недостатком является то, что прокси-сервер одного узла может быть узким местом в использовании вычислений или пропускной способности сети. Политика корпоративной кластеризация является единственной, которую можно использовать с модулем RediSearch.
Команды с несколькими ключами
Так как уровни Enterprise используют кластеризованную конфигурацию, могут появиться CROSSSLOT исключения для команд, работающих с несколькими ключами. Поведение зависит от используемой политики кластеризация. Если вы используете политику кластеризация OSS, команды с несколькими ключами необходимо сопоставить все ключи с одним хэш-слотом.
Также могут появиться CROSSSLOT ошибки с политикой корпоративного кластеризация. Только следующие команды с несколькими ключами разрешены в слотах с корпоративными кластеризация: DEL, , MSET, MGETEXISTSUNLINKи TOUCH.
В базах данных Active-Active команды записи с несколькими ключами (DEL, MSET, ) UNLINKмогут выполняться только на ключах, которые находятся в одном слоте. Однако следующие команды с несколькими ключами разрешены в слотах в базах данных Active-Active: MGETи TOUCHEXISTS. Дополнительные сведения см. в разделе "База данных кластеризация".
Рекомендации по корпоративной флэш-памяти
Уровень Enterprise Flash использует хранилище флэш-памяти NVMe и ОЗУ. Так как хранилище Флэш-памяти снижает затраты, используя уровень Enterprise Flash, вы можете сключиться на некоторые затраты на производительность.
В экземплярах Enterprise Flash 20 % кэша находится в ОЗУ, а другой — на 80 % — хранилище Флэш-памяти. Все ключи хранятся в ОЗУ, а значения могут храниться в хранилище Флэш-памяти или ОЗУ. Расположение значений определяется интеллектуально программным обеспечением Redis. "Горячие" значения, к которым обращается доступ, хранятся в ОЗУ, в то время как "Холодный" значения, которые реже используются, хранятся в Flash. Прежде чем данные считываются или записываются, его необходимо переместить в ОЗУ, став "горячими" данными.
Так как Redis будет выбирать оптимальную производительность, экземпляр сначала заполнит доступную ОЗУ перед добавлением элементов в хранилище Flash. Это имеет несколько последствий для производительности:
- При тестировании с низким использованием памяти производительность и задержка могут быть значительно лучше, чем с полным экземпляром кэша, так как используется только ОЗУ.
- При записи дополнительных данных в кэш доля данных в ОЗУ по сравнению с хранилищем Флэш-памяти снижается, что обычно приводит к снижению задержки и производительности пропускной способности.
Рабочие нагрузки хорошо подходят для уровня Enterprise Flash
Рабочие нагрузки, которые, скорее всего, будут работать хорошо на уровне Enterprise Flash, часто имеют следующие характеристики:
- Чтение с большим количеством операций чтения с высоким соотношением команд чтения для записи команд.
- Доступ ориентирован на подмножество ключей, которые используются гораздо чаще, чем остальная часть набора данных.
- Относительно большие значения по сравнению с именами ключей. (Так как имена ключей всегда хранятся в ОЗУ, это может стать узким местом для роста памяти.)
Рабочие нагрузки, которые не подходят для уровня Enterprise Flash
Некоторые рабочие нагрузки имеют характеристики доступа, которые менее оптимизированы для проектирования уровня Flash:
- Написание тяжелых рабочих нагрузок.
- Случайный или унифицированный доступ к данным в большинстве наборов данных.
- Длинные имена ключей с относительно небольшими размерами значений.
Обработка сценариев уменьшения региона с активной георепликацией
Активная гео реплика tion — это мощная функция для повышения доступности при использовании уровней enterprise Кэш Azure для Redis. Однако необходимо выполнить действия, чтобы подготовить кэши, если произошел региональный сбой.
Например, рассмотрим следующие советы:
- Заранее определите, на какой другой кэш в группе гео-реплика tion переключится, если регион исчезнет.
- Убедитесь, что брандмауэры установлены таким образом, чтобы все приложения и клиенты могли получить доступ к определенному кэшу резервных копий.
- Каждый кэш в группе гео-реплика tion имеет собственный ключ доступа. Определите, как приложение переключается на разные ключи доступа при выборе кэша резервных копий.
- Если кэш в группе гео-реплика tion завершается, сборка метаданных начинается во всех кэшах в группе гео-реплика tion. Метаданные не могут быть отключены карта до тех пор, пока записи не будут синхронизированы снова со всеми кэшами. Вы можете предотвратить сборку метаданных путем принудительного отмены связывания кэша, который находится вниз. Рассмотрите возможность мониторинга доступной памяти в кэше и отмене связи при нехватке памяти, особенно для рабочих нагрузок с высокой нагрузкой на запись.
Кроме того, можно использовать шаблон разбиения цепи. Используйте шаблон для автоматического перенаправления трафика из кэша, в котором возникает сбой региона, и в сторону кэша резервного копирования в той же гео-реплика группе. Используйте службы Azure, такие как Диспетчер трафика Azure или Azure Load Balancer, чтобы включить перенаправление.
Сохраняемость данных и резервное копирование данных
Функция сохраняемости данных на уровнях Enterprise и Enterprise Flash предназначена для автоматического предоставления точки быстрого восстановления данных при сходе кэша. Быстрое восстановление возможно путем хранения RDB или AOF-файла на управляемом диске, подключенном к экземпляру кэша. Файлы сохраняемости на диске недоступны пользователям.
Многие клиенты хотят использовать сохраняемость для периодического резервного копирования данных в кэше. Мы не рекомендуем использовать сохраняемость данных таким образом. Вместо этого используйте функцию импорта и экспорта . Вы можете экспортировать копии данных кэша в формате RDB непосредственно в выбранную учетную запись хранения и активировать экспорт данных так часто, как требуется. Экспорт можно активировать на портале или с помощью средств КОМАНДНОй строки, PowerShell или ПАКЕТА SDK.