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

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

  • Статья

Область применения: Виртуальные ядра MongoDB

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

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

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

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

Дополнительные сведения о зонах доступности в Azure см. в статье "Что такое зоны доступности?".

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Следующие шаги