Доступность (надежность) и аварийное восстановление (аварийное восстановление) в Azure Cosmos DB для виртуального ядра MongoDB: за кулисами
Область применения: 
Виртуальные ядра MongoDB
В этой статье рассматриваются внутренние компоненты высокого уровня доступности и аварийного восстановления между регионами для Azure Cosmos DB для виртуальных ядер MongoDB, которые описывают проектирование и возможности этих функций. Она предоставляет аналитические сведения для эффективного планирования стратегий в регионе и между регионами, чтобы обеспечить надежность и непрерывность бизнес-процессов.
Анатомия кластера виртуальных ядер в Azure Cosmos DB для MongoDB
Кластер виртуальных ядер Azure Cosmos DB для MongoDB состоит из одного или нескольких физических сегментов (узлов). Каждый физический сегмент включает выделенный вычислительный узел и удаленное хранилище SSD класса Premium. Вычислительные ресурсы и ресурсы хранилища физического сегмента являются эксклюзивными для одной базы данных и не совместно используются в кластерах или базах данных.
В кластерах с несколькими сегментами каждый сегмент имеет одинаковую конфигурацию вычислений и хранилища. Независимо от количества сегментов, все ресурсы кластера размещаются в одном регионе Azure.
Azure Cosmos DB для виртуальных ядер MongoDB использует локально избыточное хранилище (LRS), гарантируя, что все данные синхронно реплицируются в физическом расположении кластера. служба хранилища Azure прозрачно управляет этими репликами, проверяет целостность данных с помощью циклических проверок избыточности (CRCs) и восстанавливает обнаруженные повреждения с помощью избыточных данных. Кроме того, контрольные суммы применяются к сетевому трафику, чтобы предотвратить повреждение данных во время хранения и извлечения.
Рис. 1. Компоненты кластера виртуальных ядер Azure Cosmos DB для MongoDB.
Независимо от того, подключается ли приложение к одному сегменту или кластеру с несколькими сегментами, оно использует одну строка подключения и конечную точку. Эта абстракция упрощает распределенные операции базы данных, что упрощает подключение к конфигурации с несколькими сегментами как к автономной базе данных MongoDB.
Высокий уровень доступности в регионе (ВЫСОКИЙ уровень доступности)
Для рабочих нагрузок настоятельно рекомендуется обеспечить высокий уровень доступности в регионе для удовлетворения современных стандартов надежности. Хотя высокий уровень доступности может быть отключен для разработки или экспериментальных кластеров для снижения затрат, крайне важно для поддержания доступности базы данных в рабочей среде.
Высокий уровень доступности можно переключать во время подготовки кластера или в любое время после создания кластера. Он доступен во всех регионах Azure, которые поддерживают Azure Cosmos DB для виртуальных ядер MongoDB независимо от конкретных региональных возможностей.
При включении высокой доступности каждый основной физический сегмент в кластере связан с резервным сегментом. Резервный сегмент отражает конфигурацию вычислений и хранилища своего основного аналога. Это приводит к тому, что шесть реплик данных на сегмент — три на основном сегменте и три в резервном режиме. В регионах с зонами доступности (AZs) первичные и резервные сегменты развертываются в отдельных зонах.
Данные синхронно реплицируются между каждым первичным и резервным сегментом. Записи признаются только после успешной фиксации обоих сегментов, обеспечивая надежную согласованность в кластере высокого уровня доступности. Другими словами, резервный физический сегмент — это всегда актуальная полная реплика основного физического сегмента, обеспечивающая надежную согласованность в высокодоступном кластере.
Рис. 2. Кластер виртуальных ядер Azure Cosmos DB для MongoDB с включенным высоким уровнем доступности (HA) и без нее.
В случае сбоя первичного сегмента служба автоматически выполняет отработку отказа на его резервный сегмент. Во время отработки отказа все запросы на чтение и запись перенаправляются в резервный сегмент, который становится новым основным. Операции записи, выполняемые во время отработки отказа, извлекаются из службы, чтобы обеспечить непрерывность. Затем создается сегмент замены для повторной установки синхронной репликации, став новым резервным.
Репликация между регионами: региональное аварийное восстановление (аварийное восстановление)
Хотя редкие региональные сбои могут нарушить доступ к базе данных. Репликация между регионами обеспечивает надежную стратегию аварийного восстановления( аварийного восстановления), обеспечивая доступ к данным даже во время крупномасштабных сбоев.
При репликации между регионами можно создать кластер реплики в другом регионе Azure. Каждый сегмент в кластере реплики асинхронно реплицирует данные из своего аналога в основном кластере. Эта модель репликации обеспечивает конечную согласованность при минимизации влияния производительности на основной кластер.
Асинхронная репликация позволяет избежать необходимости немедленной доставки каждой операции записи и подтверждения реплик перед отправкой подтверждения "запись завершена". Однако это означает, что некоторые записи, завершенные в основном кластере, пока не будут реплицированы в кластер реплик, что приводит к задержке репликации. Степень задержки репликации зависит от интенсивности операций записи в основном кластере и общей нагрузке как на первичные, так и на реплики.
В этой настройке:
- Основной кластер в регионе A обрабатывает все операции чтения и записи.
- Кластер реплики в регионе B поддерживает доступ только для чтения, обеспечивая высокопроизводительные операции чтения ближе к приложениям или пользователям в этом регионе.
Приложения могут выполнять запросы OLTP в основном кластере в регионе A и интенсивные операции чтения, такие как запросы OLAP/reporting, можно указать на кластер реплики в регионе B.
Приложения могут использовать динамическую глобальную строка подключения записи, которая всегда указывает на кластер, открытый для записи. Во время регионального сбоя кластер реплики в регионе B можно повысить, чтобы принять записи. Глобальный строка подключения автоматически обновляется для указания на кластер с повышенным уровеньом, обеспечивая непрерывные операции записи.
Рис. 3. Региональное аварийное восстановление (АВАРИЙНОе восстановление) с кластером виртуальных ядер Azure Cosmos DB для MongoDB с включенной репликацией между регионами. Кластер в регионе B повышен, чтобы стать новым кластером чтения и записи. Кластер в регионе A становится кластером реплики.
Сводка по доступности в регионе и возможности аварийного восстановления между регионами
В следующей таблице приведены основные рекомендации по включению и управлению высокодоступной и межрегионной стратегией аварийного восстановления и управления ими.
| Сценарий | Функция виртуального ядра Azure Cosmos DB для MongoDB | Без потери данных | Защита от сбоев на уровне региона | автоматический переход на другой ресурс | Нет строка подключения изменений |
|---|---|---|---|---|---|
| Сбой физического сегмента | Высокий уровень доступности в регионе (ВЫСОКИЙ уровень доступности) | ✔️ | ❌ | ✔️ | ✔️ |
| Сбой в регионе | Кластер реплики между регионами | ❌ | ✔️ | ❌ | ✔️† |
† При использовании глобального строка подключения чтения и записи.