Высокий уровень доступности и аварийное восстановление
Как и в случае с любыми облачными системами, внеплановые простои могут привести к неработоспособности экземпляров виртуальных машин, зоны доступности или всего региона Azure. Мы рекомендуем клиентам подготовить план на случай сбоя зоны или региона.
В этой статье приведены сведения о том, как клиенты могут создать план непрерывности бизнес-процессов и аварийного восстановления для своей реализации Кэша Azure для Redis или Кэша Azure для Redis уровня "Корпоративный".
На уровнях "Стандартный", "Премиум" и "Корпоративный" доступны разные варианты обеспечения высокой доступности.
| Параметр | Описание | Доступность | Standard | Premium | Функции корпоративного уровня |
|---|---|---|---|---|---|
| Стандартная репликация | Двухузловая реплицированная конфигурация в одном центре обработки данных с автоматической отработкой отказов | 99,9 % (см. дополнительные сведения) | ✔ | ✔ | ✔ |
| Избыточность зоны | Реплицируемая конфигурация с несколькими узлами в зонах доступности, с автоматическим переходом на другой ресурс | 99,9% на уровне "Премиум"; 99,99% на уровне "Корпоративный" (см. подробности) | - | ✔ | ✔ |
| Георепликация | Связанные экземпляры кэша в двух регионах с управляемой пользователем отработкой отказов | "Премиум"; "Корпоративный" (см. подробности) | - | Пассивный | Активные |
| Импорт и экспорт | Моментальные снимки данных в кэше на определенный момент времени. | 99,9 % (см. дополнительные сведения) | - | ✔ | ✔ |
| Сохраняемость | Периодическое сохранение данных в учетной записи хранения. | 99,9 % (см. дополнительные сведения) | - | ✔ | "Предварительная версия" |
Стандартная репликация для обеспечения высокой доступности.
Применимые уровни: Стандартный, Премиум, Корпоративный, Enterprise Flash.
Рекомендуется: высокий уровень доступности
Кэш Azure для Redis имеет архитектуру высокой доступности, которая гарантирует функционирование управляемого экземпляра, даже если сбои влияют на базовые виртуальные машины (виртуальные машины). Планируется ли сбой или незапланированный сбой, Кэш Azure для Redis обеспечивает более высокую процентную доступность, чем то, что достигается путем размещения Redis на одной виртуальной машине.
По умолчанию Кэш Azure для Redis в применимых уровнях выполняется на паре серверов Redis. Два сервера располагаются на выделенных виртуальных машинах. Redis с открытым исходным кодом позволяет только одному серверу обрабатывать запросы на запись данных.
При использовании Кэша Azure для Redis один сервер является основным узлом, а второй — репликой. После подготовки узлов сервера кэш Azure для Redis назначает им основные роли и роли реплики. Основной узел обычно отвечает за обслуживание запросов на запись и чтение от клиентов. При выполнении операции записи он фиксирует новый ключ и обновление ключа во внутренней памяти и немедленно отправляет ответ клиенту. Он асинхронно перенаправляет операцию в реплику.
Примечание.
Обычно клиент Кэша Azure для Redis обменивается данными с основным узлом в кэше для обработки всех запросов на чтение и запись. Некоторые клиенты можно настроить для чтения с узла реплики.
Если основной узел в кэше недоступен, реплика автоматически способствует тому, чтобы стать новым основным. Этот процесс называется отработкой отказа. Отработка отказа — это всего два узла, первичные или реплика, торговые роли, реплика/основной, с одним из узлов, возможно, в автономном режиме в течение нескольких минут. В большинстве отработок отказа первичные и реплика узлы координирует передачу, чтобы вы имели почти нулевое время без первичного.
Бывший основной источник кратко переходит в автономный режим, чтобы получать обновления от нового первичного. Затем теперь реплика возвращается в сеть и повторно присоединитесь к кэшу полностью синхронизировано. Ключ заключается в том, что если узел недоступен, это временное условие, и он возвращается в режим "в сети".
Типичная последовательность отработки отказа выглядит следующим образом, когда основной объект должен перейти к обслуживанию:
- Основные и реплика узлы согласовывают согласованные роли отработки отказа и торговли.
- Реплика (ранее первичная) переходит в автономный режим для перезагрузки.
- Через несколько секунд или минут реплика возвращается в интернет.
- Реплика синхронизирует данные из основного.
Основной узел может выйти из строя в рамках планового обслуживания, например при обновлении программного обеспечения Redis или операционной системы. Он также может перестать работать вследствие незапланированных событий, например сбоев основного оборудования, программного обеспечения или сети. В статье Отработка отказа и установка исправлений для Кэша Azure для Redis приведено подробное описание типов отработки отказа Redis. На протяжении всего срока службы кэш Azure для Redis выполняет множество отработок отказов. Архитектура высокого уровня доступности предназначена для того, чтобы сделать эти изменения внутри кэша максимально незаметными для клиентов.
Кроме того, кэш Azure для Redis предоставляет дополнительные узлы реплик на уровне "Премиум". Для кэша с несколькими репликами можно настроить до трех узлов реплик. Наличие большего количества реплик обычно повышает отказоустойчивость из-за наличия узлов, являющихся резервными для основного узла. Даже при наличии дополнительных реплика экземпляр Кэш Azure для Redis по-прежнему может серьезно повлиять на сбой центра обработки данных или зоны доступности. Можно увеличить доступность кэша, используя несколько реплик в сочетании с избыточностью между зонами.
Избыточность между зонами
Применимые уровни: Премиум, Корпоративный, Enterprise Flash.
Рекомендуется: высокий уровень доступности, аварийное восстановление — внутри региона
Кэш Azure для Redis поддерживает конфигурации с избыточностью между зонами на уровнях "Премиум" и "Корпоративный". Кэш с избыточностью между зонами может размещать свои узлы в разных зонах доступности Azure в одном регионе. Это устраняет простои центра обработки данных или зоны доступности как единой точки отказа и увеличивает общую доступность кэша. См. эту статью со сведениями о настройке.
Если кэш настроен на использование двух или более зон, как описано ранее в статье, узлы кэша создаются в разных зонах. Когда зона прекращает работу, становятся доступны узлы кэша в других зонах для сохранения нормальной работы кэша.
Кэш Azure для Redis поддерживает конфигурации с избыточностью между зонами на уровнях "Премиум" и "Корпоративный". Кэш с избыточностью между зонами может размещать свои узлы в разных зонах доступности Azure в одном регионе. Это устраняет простои центра обработки данных или зоны доступности как единой точки отказа и увеличивает общую доступность кэша.
Уровень служб "Премиум"
На следующей схеме показана конфигурация с избыточностью между зонами для уровня "Премиум".
Кэш Azure для Redis распределяет узлы в кэше с избыточностью между зонами циклическим перебором по выбранным зонам доступности. Он также определяет узел, который служит первичным изначально.
Уровень "Вниз по зонам" для уровня "Премиум"
Кэш с избыточностью между зонами обеспечивает автоматическую отработку отказа. Если текущий первичный узел недоступен, один из реплика берет на себя. Приложение может столкнуться с более высоким временем отклика кэша, если новый основной узел находится в другой зоне доступности. Зоны доступности разделены географически. При переходе из одной зоны доступности в другую изменяется физическое расстояние между местом расположения приложения и кэша. Это изменение влияет на задержки при обмене данными по сети в обоих направлениях между приложением до кэшем. Ожидается, что увеличение задержки будет в приемлемом диапазоне для большинства приложений. Рекомендуется протестировать приложение, чтобы убедиться, что оно может хорошо работать с кэшем с избыточностью между зонами.
Уровни "Корпоративный" и Enterprise Flash
Кэш на любом уровне "Корпоративный" работает в кластере Redis Enterprise. Для формирования кворума всегда требуется нечетное количество узлов сервера. По умолчанию он состоит из трех узлов, каждый из которых располагается на выделенной виртуальной машине.
- Кэш Enterprise имеет два узла данных одинакового размера и один узел кворума меньшего размера.
- Кэш Enterprise Flash состоит из трех узлов данных одинакового размера.
Кластер Enterprise разделяет данные Кэша Azure для Redis внутри на разделы. Каждый раздел имеет основную версию и, как минимум, одну реплику. Каждый узел данных содержит один или несколько разделов. Кластер Enterprise гарантирует, что основная версия и реплики любого раздела никогда не располагаются в одном узле данных. Разделы асинхронно реплицируют данные из основных версий в соответствующие реплики.
Взаимодействие с зонами вниз для уровней Enterprise
Когда узел данных становится недоступным или происходит разделение сети, выполняется аварийная отработка отказа, аналогичная описанной в статье Стандартная репликация. Кластер Enterprise использует модель на основе кворума, чтобы определить, какие выжившие узлы участвуют в новом кворуме. При необходимости выполняется продвижение разделов реплик в этих узлах до основных.
Доступность по регионам
Кэши уровня "Премиум", избыточные между зонами, доступны в следующих регионах:
| Центральная и Южная Америка | Европа | Ближний Восток | Африка | Азиатско-Тихоокеанский регион |
|---|---|---|---|---|
| Brazil South | Центральная Франция | Центральный Катар | Северная часть ЮАР | Восточная Австралия |
| Центральная Канада | Центрально-Западная Германия | Центральная Индия | ||
| Центральная часть США | Северная Европа | Восточная Япония | ||
| Восточная часть США | Восточная Норвегия; | Республика Корея, центральный регион | ||
| Восточная часть США 2 | Южная часть Соединенного Королевства | Юго-Восточная Азия | ||
| Центрально-южная часть США | Западная Европа | Восточная Азия | ||
| US Gov (Вирджиния) | Центральная Швеция | Северный Китай 3 | ||
| Западная часть США 2 | Северная Швейцария | |||
| Западная часть США 3 |
Кэши уровня Enterprise и Enterprise Flash, избыточные между зонами, доступны в следующих регионах:
| Центральная и Южная Америка | Европа | Ближний Восток | Африка | Азиатско-Тихоокеанский регион |
|---|---|---|---|---|
| Центральная Канада* | Северная Европа | Восточная Австралия | ||
| Центральная часть США* | Южная часть Соединенного Королевства | Центральная Индия | ||
| Восточная часть США | Западная Европа | Southeast Asia | ||
| Восточная часть США 2 | Восточная Япония* | |||
| Центрально-южная часть США | Восточная Азия* | |||
| западная часть США 2 | ||||
| Западная часть США — 3 | ||||
| Южная Бразилия |
* Уровень Корпоративной флэш-памяти недоступен в этом регионе.
Развертывание и миграция зон доступности
В настоящее время единственным способом преобразования кэша из конфигурации, отличной от AZ, в конфигурацию AZ является повторное развертывание кэша. Сведения о повторном развертывании текущего кэша см. в статье "Перенос экземпляра Кэш Azure для Redis в поддержку зоны доступности".
Сохраняемость
Применимые уровни: Премиум, Корпоративный (предварительная версия), Enterprise Flash (предварительная версия).
Рекомендуется: устойчивость данных
Так как данные кэша хранятся в памяти, редкий и внеплановый сбой нескольких узлов может привести к удалению всех данных. Для недопущения полной потери данных сохраняемость Redis позволяет периодически создавать моментальные снимки данных в памяти и сохранять их в учетной записи хранения. При возникновении сбоя на нескольких узлах, что приводит к потере данных, кэш загружает моментальный снимок из учетной записи хранения. Дополнительные сведения см. в статье Настройка сохраняемости для экземпляра Кэша Azure для Redis уровня "Премиум".
Учетная запись хранения для сохраняемости
Рекомендуем выбрать учетную запись геоизбыточного хранилища, чтобы обеспечить высокий уровень доступности сохраняемых данных. Дополнительные сведения см. в статье Репликация службы хранилища Azure.
Импорт и экспорт
Применимые уровни: Премиум, Корпоративный, Enterprise Flash.
Рекомендуется: аварийное восстановление
Кэш Azure для Redis поддерживает возможность импорта и экспорта файлов Redis Database (RDB) для обеспечения переносимости данных. Это позволяет импортировать данные в Кэш Azure для Redis или экспортировать данные из Кэша Azure для Redis с помощью моментальных снимков RDB. Моментальный снимок RDB из кэша уровня "Премиум" экспортируется в BLOB-объект в учетной записи хранения Azure. Вы можете создать скрипт, периодически инициирующий экспорт в учетную запись хранения. Дополнительные сведения см. в статье Импорт и экспорт данных в Кэше Azure для Redis.
Учетная запись хранения для экспорта
Рекомендуем выбрать учетную запись геоизбыточного хранилища, чтобы обеспечить высокий уровень доступности экспортируемых данных. Дополнительные сведения см. в статье Репликация службы хранилища Azure.
Пассивное гео реплика tion
Применимые уровни: Премиум.
Рекомендуется: аварийное восстановление — один регион
Георепликация — это механизм для связывания двух или более экземпляров кэша Azure для Redis, обычно охватывающих два региона Azure. Геоизбыточное реплика предназначено главным образом для аварийного восстановления между регионами. Два экземпляра кэша уровня "Премиум" подключены через георепликацию так, что обеспечивается чтение и запись в основной кэш, а эти данные затем реплицируются в дополнительный кэш.
Дополнительные сведения о ее настройке см. в статье Настройка георепликации для экземпляров Кэша Azure для Redis уровня "Премиум".
Если регион, в котором размещается основной кэш, выходит из строя, необходимо запустить отработку отказа: сначала отмените привязку к дополнительному кэшу, а затем обновите приложение, чтобы оно указывало на дополнительный кэш для операций чтения и записи.
Активная георепликация
Применимые уровни: Корпоративный, Enterprise Flash.
Рекомендуется: высокий уровень доступности, аварийное восстановление в нескольких регионах
Уровни Enterprise поддерживают более расширенную форму гео-реплика tion, называемую активной гео-реплика tion, которая обеспечивает как более высокую доступность, так и аварийное восстановление между регионами в нескольких регионах. ПО Кэша Azure для Redis уровня "Корпоративный" использует реплицируемые типы данных без конфликтов для поддержки операций записи в несколько экземпляров кэша, объединения изменений и разрешения конфликтов. Вы можете объединить до пяти экземпляров кэша уровня "Корпоративный" в разных регионах Azure, чтобы сформировать группу георепликации.
Приложение, использующее такой кэш, может выполнять чтение и запись в любые экземпляры географически распределенного кэша через соответствующие конечные точки. Приложение использует те компоненты, которые располагаются ближе всего к каждому экземпляру приложения, что обеспечивает наименьшую задержку. Дополнительные сведения см. в статье Настройка активной георепликации для экземпляров Кэша Azure для Redis уровня "Корпоративный".
Если регион одного из кэшей в группе репликации выходит из строя, приложению необходимо переключиться на другой доступный регион.
Если кэш в группе репликации недоступен, рекомендуется отслеживать использование памяти для других кэшей в этой же группе репликации. Хотя один из кэшей не работает, все остальные кэши в группе репликации начинают сохранять метаданные, которые не удалось отправить в кэш, который не работает. Если использование памяти для доступных кэшей начинает увеличиваться с высокой скоростью после сбоя одного из кэшей, рекомендуем отменить привязку недоступного кэша к группе репликации.
Дополнительные сведения о принудительной отмене привязки см. в разделе Принудительная отмена привязки в случае сбоя региона.
Удаление и повторное создание кэша
Применимые уровни: Стандартный, Премиум, Корпоративный, Enterprise Flash.
При возникновении регионального сбоя рассмотрите возможность повторного создания кэша в другом регионе и обновления приложения для подключения к новому кэшу. Важно понимать, что данные теряются во время регионального сбоя. Код приложения должен быть устойчивым к потере данных.
После восстановления затронутого региона ваша недоступная Кэш Azure для Redis автоматически восстанавливается и доступна для использования еще раз. Дополнительные стратегии по перемещению кэша в другой регион см. в статье Перемещение экземпляров Кэша Azure для Redis в разные регионы.
Следующие шаги
Дополнительные сведения о настройке кэша Azure для параметров высокого уровня доступности Redis.