Поделиться через

Надежность в Azure Cosmos DB для виртуальных ядер MongoDB

ПРИМЕНЯЕТСЯ К: Виртуальные ядра MongoDB

В этой статье содержатся подробные сведения о региональной устойчивости с зонами доступности и аварийного восстановления между регионами и непрерывности бизнес-процессов для Azure Cosmos DB для виртуальных ядер MongoDB.

Общие сведения об архитектуре надежности в Azure см. в статье "Надежность Azure".

Поддержка зоны доступности

Зоны доступности — это физически отдельные группы центров обработки данных в каждом регионе Azure. При сбое одной зоны службы могут переключиться на одну из оставшихся зон.

Чтобы получить поддержку зоны доступности, необходимо включить высокий уровень доступности (HA).

Высокая доступность (HA) позволяет избежать простоя базы данных, сохраняя резервные реплики каждого шарда в кластере. Если сегмент отключается, Azure Cosmos DB для MongoDB vCore перенаправляет входящие подключения от отказавшего сегмента к его резервной реплике.

Если высокий уровень доступности включен в регионе, поддерживающем зоны доступности, сегменты реплики высокой доступности подготавливаются в другой зоне доступности, отличной от основных сегментов. HA-реплики не принимают запросы от клиентов, если основной сегмент не прекращает работу.

Если высокий уровень доступности отключен, каждый сегмент имеет собственное локально избыточное хранилище (LRS) с тремя синхронными репликами, поддерживаемыми службой хранилища Azure. Если произошел сбой одной реплики, служба хранилища Azure обнаруживает это и автоматически воссоздает соответствующие данные. Сведения об устойчивости хранилища LRS см. в разделе "Сводка параметров избыточности". Однако в случае сбоя региона может возникнуть риск обширного простоя и возможной потери данных.

Создание ресурса с включенными зонами доступности

Чтобы включить зоны доступности, необходимо включить высокий уровень доступности при создании кластера или в разделе масштабирования существующего кластера на портале Azure.

Аварийное восстановление между регионами и непрерывность бизнес-процессов

Аварийное восстановление (DR) относится к процедурам, которые организации используют для восстановления после событий значительного воздействия, таких как стихийные бедствия или ошибочные развертывания, которые приводят к простою и потере данных. Независимо от причины, лучшее средство для аварийного восстановления является хорошо определенным и проверенным планом аварийного восстановления и проектом приложения, который активно поддерживает аварийное восстановление. Прежде чем приступить к созданию плана аварийного восстановления, ознакомьтесь с рекомендациями по разработке стратегии аварийного восстановления.

Для восстановления после сбоя компания Microsoft использует модель общей ответственности. В этой модели корпорация Майкрософт гарантирует, что доступны базовые инфраструктуры и службы платформы. Однако многие службы Azure не делают автоматической репликации данных и не обеспечивают возврат из вышедшего из строя региона для перекрестной репликации в другой доступный регион. Для этих сервисов вы отвечаете за настройку плана аварийного восстановления, соответствующего вашей рабочей нагрузке. Большинство служб, работающих на платформе Azure как услуга (PaaS), предоставляют функции и рекомендации для поддержки аварийного восстановления. Вы можете использовать специализированные функции для поддержки быстрого восстановления и разработки плана аварийного восстановления.

Azure Cosmos DB для MongoDB vCore не обеспечивает встроенные автоматическое переключение на случай отказа или аварийное восстановление. Планирование высокого уровня доступности является критически важным шагом по мере масштабирования решения.

Аварийное восстановление в единственном географическом регионе

Чтобы максимально повысить время работы, заранее спланируйте обеспечение непрерывности бизнес-процессов и подготовьтесь к аварийному восстановлению с помощью Azure Cosmos DB для виртуальных ядер MongoDB.

Хотя службы Azure предназначены для повышения времени простоя, могут возникнуть незапланированные сбои служб. План аварийного восстановления гарантирует наличие стратегии для обработки сбоев региональных служб.

Azure Cosmos DB для виртуальных ядер MongoDB автоматически создает резервные копии данных через регулярные интервалы. Автоматическое резервное копирование выполняется без влияния на производительность или доступность операций базы данных. Все резервные копии выполняются автоматически в фоновом режиме и хранятся отдельно от исходных данных в службе хранилища. Эти автоматические резервные копии полезны в сценариях при случайном удалении или изменении ресурсов, а затем требуют исходных версий.

Автоматические резервные копии сохраняются в различных интервалах на основе того, активен ли кластер в настоящее время или недавно удален.

Период хранения
Активные кластеры 35 дней
Удаленные кластеры 7 дней

Проектирование высокого уровня доступности

Высокая доступность (HA) должна быть включена для критически важных кластеров Azure Cosmos DB для MongoDB vCore, работающих с производственными нагрузками. В кластере с поддержкой высокой доступности каждый сегмент служит основным сегментом, а также сегментом горячего ожидания, подготовленным в другой зоне доступности. Репликация между первичным и вторичным сегментом синхронна по умолчанию. Любое изменение базы данных сохраняется как на сегментах-источнике, так и на вторичных (горячих резервных) сегментах перед получением ответа от базы данных.

Служба поддерживает проверки работоспособности и пульса для каждого первичного и вторичного фрагмента кластера. Если первичный шард становится недоступным из-за сбоя в зоне или регионе, вторичный шард автоматически продвигается, становясь новым первичным, а для нового первичного создается новый вторичный шард. Кроме того, если вторичный сегмент становится недоступным, служба автоматически создает новый вторичный сегмент с полной копией данных из первичного.

Если служба активирует переключение на резервный шард с первичного на вторичный, подключения незаметно перенаправляются на новый первичный шард.

Синхронная репликация между основными и вторичными шардами гарантирует отсутствие потери данных в случае отказоустойчивости.

Дальнейшие шаги