Рекомендации по уровням 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 и емкости (то есть горизонтального масштабирования).
В таблицах показано количество виртуальных ЦП, используемых для основных сегментов, а не сегментов реплики. Сегменты не сопоставляют один к одному числу виртуальных ЦП. В таблицах показаны только виртуальные ЦП, а не сегменты. Некоторые конфигурации используют больше сегментов, чем доступные виртуальные ЦП для повышения производительности в некоторых сценариях использования.
E1
| Capacity | Эффективные виртуальные ЦП |
|---|---|
| 2 | 1 (с возможностью ускорения) |
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, чтобы воспользоваться преимуществами нескольких узлов. Недостатком является то, что прокси-сервер одного узла может быть узким местом в использовании вычислений или пропускной способности сети. Политика кластеризации enterprise является единственной, которая может использоваться с модулем RediSearch.
Команды с несколькими ключами
Так как уровни Enterprise используют кластеризованную конфигурацию, могут появиться CROSSSLOT исключения для команд, работающих с несколькими ключами. Поведение зависит от используемой политики кластеризации. Если вы используете политику кластеризации OSS, команды с несколькими ключами необходимо сопоставить все ключи с одним хэш-слотом.
Также могут появиться CROSSSLOT ошибки с политикой кластеризации Enterprise. Только следующие команды с несколькими ключами разрешены в слотах с кластеризации Enterprise: DEL, , EXISTSUNLINKMSETMGETи .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:
- Написание тяжелых рабочих нагрузок.
- Случайные или универсальные шаблоны доступа к данным в большинстве наборов данных.
- Длинные имена ключей с относительно небольшими размерами значений.
Обработка сценариев уменьшения региона с активной георепликацией
Активная георепликация — это мощная функция для повышения доступности при использовании корпоративных уровней Кэш 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 также не поддерживает активную георепликацию.