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