Надежность в Azure DocumentDB

Azure DocumentDB — это полностью управляемая служба базы данных NoSQL для современной разработки приложений с совместимостью MongoDB. Azure DocumentDB поддерживает конфигурацию высокой доступности (HA) с синхронной репликацией на резервные реплики горячего ожидания и зональной избыточностью. Она также предоставляет дополнительную реплику для чтения в другом регионе Azure и автоматические резервные копии с возможностью восстановления на определённый момент времени для защиты от случайной потери данных.

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

В этой статье описывается, как обеспечить устойчивость Azure DocumentDB к различным потенциальным сбоям и проблемам, в том числе временным сбоям, сбоям зоны доступности, сбоям регионов и обслуживанию служб. В нем также описываются особенности резервного копирования и приводятся ключевые сведения о высокой доступности и межрегиональной репликации.

Рекомендации по развертыванию в рабочей среде для обеспечения надежности

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

Обзор архитектуры надежности

В этом разделе описываются некоторые важные аспекты работы службы, наиболее релевантные с точки зрения надежности. В этом разделе представлена логическая архитектура, включающая некоторые ресурсы и функции, которые развертываются и используются. Он также обсуждает аппаратную архитектуру, которая содержит сведения о том, как работает служба изнутри.

Логическая архитектура

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

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

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

Физическая архитектура

Azure DocumentDB запускает ваш кластер на шардах, которые представляют собой узлы (виртуальные машины), на которых выполняется служба. Можно развернуть один шард или масштабировать систему до нескольких шардов. Развертывание нескольких шардов повышает масштабируемость, но само по себе не обеспечивает высокую доступность.

При включении HA Azure DocumentDB создает соответствующий набор резервных шардов. Каждый первичный сегмент имеет резервный сегмент. Служба синхронно реплицирует данные в каждой паре «основной — резервный» и назначает резервный сегмент основным, если основной сегмент выходит из строя. Дополнительные сведения о высокой доступности см. в статье Высокая доступность в Azure DocumentDB.

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

Дополнительные сведения см. в разделе "Доступность и аварийное восстановление" в Azure DocumentDB: за кулисами.

Устойчивость к временным сбоям

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

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

Azure DocumentDB совместим с протоколом MongoDB, поэтому приложения обычно подключаются с помощью драйверов MongoDB. Вы отвечаете за настройку параметров повторных попыток драйвера вашего приложения для обработки кратковременных сбоев, особенно прерываний соединения и кратковременных прерываний записи при аварийном переключении. Следуйте приведенным ниже рекомендациям:

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

• Настройте повторные попытки с экспоненциальной задержкой и ограничьте их количество.

• По возможности проектируйте операции записи так, чтобы они были идемпотентными и их можно было безопасно повторять. Общие рекомендации по реализации идемпотентности см. в паттерне Idempotent Consumer.

Устойчивость к сбоям зоны доступности

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

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

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

На схеме показан один кластер Azure DocumentDB в трех зонах доступности. Два основных физических сегмента находятся в зоне доступности 1, а соответствующие резервные физические сегменты находятся в зоне доступности 2. Стрелки между каждым первичным и резервным сегментами показывают синхронную репликацию. В этом примере зона доступности 3 не содержит шардов.

Требования

• Поддержка региона: Чтобы использовать зоны доступности с Azure DocumentDB, выберите регион, поддерживающий как Azure DocumentDB, так и зоны доступности. Проверьте доступность продуктов по регионам и сравнивайте их с регионами, поддерживающими зоны доступности.

• Высокий уровень доступности: Необходимо включить высокий уровень доступности в кластере. Для HA требуется, чтобы кластер использовал уровень M30 (или выше).

Рекомендации

Хотя некоторые API-интерфейсы DocumentDB Azure включают ссылки на режимы развертывания в одной зоне, Azure DocumentDB не поддерживает развертывания высокого уровня доступности в одной зоне. Сервис поддерживает развертывания высокой доступности с резервированием по зонам.

Распределение экземпляров между зонами

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

Cost

Когда включена HA (высокая доступность), Azure DocumentDB создает резервный сегмент для каждого первичного сегмента, что увеличивает стоимость вычислительных ресурсов и хранилища вашего кластера. В регионах, где поддерживаются зоны доступности, HA также делает кластер отказоустойчивым на уровне зон. В некоторых режимах развертывания Azure DocumentDB включает высокий уровень доступности по умолчанию. Для продуктивных рабочих нагрузок не отключайте HA. Для нагрузок разработки и тестирования можно отключить HA (высокую доступность), чтобы снизить затраты. Сведения о ценах см. в разделе «Цены на Azure DocumentDB».

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

• Создайте новый кластер Azure DocumentDB с избыточностью между зонами: при создании кластера в регионе, поддерживающем зоны доступности, включите режим высокой доступности, чтобы обеспечить избыточность кластера между зонами. Подробные инструкции см. в кратком руководстве по созданию кластера DocumentDB Azure с помощью портала Azure.

• Включение зональной избыточности в существующем кластере Azure DocumentDB: Вы можете включить высокую доступность в существующем кластере. Время простоя базы данных отсутствует, если высокий уровень доступности включен или отключен в кластере Azure DocumentDB. Подробные инструкции см. в статье "Масштабирование кластера Azure DocumentDB".

Поведение, когда все зоны работоспособны

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

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

• Репликация данных между зонами: Репликация между основными и резервными сегментами синхронна. Записи сохраняются как на первичных, так и резервных сегментах, прежде чем служба возвращает ответ.

Поведение во время сбоя зоны

В этом разделе описано, чего ожидать при настройке кластера Azure DocumentDB с высокой доступностью (HA) в регионе, поддерживающем зоны доступности, если в одной из зон произойдет сбой.

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

• Уведомление: Microsoft не уведомляет вас автоматически, когда зона отключена. Однако вы можете использовать Работоспособность служб Azure для понимания общего состояния службы, включая любые сбои зоны, и настроить оповещения Service Health для уведомления о проблемах.

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

• Ожидаемая потеря данных: Azure DocumentDB реплицирует данные синхронно между основными и резервными сегментами, поэтому не ожидается потеря данных.

• Ожидаемое время простоя: Для операций чтения не ожидается простоя. Для операций записи может возникнуть кратковременное прерывание, пока завершается переключение при отказе. Если приложение правильно обрабатывает повторные попытки при временных сбоях, это обычно проявляется как кратковременное замедление.

• Распространение: Connection string не изменяется, поэтому клиенты продолжают использовать ту же конечную точку. Служба автоматически перенаправляет трафик на резервные сегменты, переведённые в активный режим, и заново создаёт новые резервные сегменты.

Восстановление зоны

Когда зона доступности восстанавливается, Azure DocumentDB автоматически восстанавливает обычные операции во всех зонах, используемых кластером.

Тестирование на сбои в зоне

Платформа Azure DocumentDB управляет маршрутизацией трафика, аварийным переключением и восстановлением после сбоя в зоне для кластеров с избыточностью между зонами. Не нужно инициировать или проверять процессы сбоя зоны доступности.

Устойчивость к сбоям на уровне региона

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

Репликация между регионами

Azure DocumentDB поддерживает репликацию между регионами через кластер реплики. Кластер реплики отображается как отдельный кластер в группе ресурсов. Этот кластер реплик можно использовать для аварийного восстановления и масштабирования операций чтения. Azure DocumentDB автоматически и асинхронно реплицирует изменения данных из основного кластера в кластер реплики.

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

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

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

В этом разделе приведены рекомендации по надежности репликации между регионами. Дополнительные сведения см. в статье Управление межрегиональной и внутрирегиональной репликацией в кластере Azure DocumentDB и Рекомендации по межрегиональной и внутрирегиональной репликации в Azure DocumentDB.

Переключение на резервный узел между регионами

Azure DocumentDB поддерживает три режима повышения уровня:

• Принудительное повышение: Немедленно переводит кластер реплики в основной, чтобы он начал принимать операции записи, и перенаправляет входящий трафик записи через глобальную строку подключения для чтения и записи. Этот режим сводит к минимуму время простоя, но может привести к потере данных, поскольку при этом теряются любые нереплицированные операции записи.

• Автоматическое переключение при отказе, управляемое службой: Кластер можно настроить для работы с автоматическим переключением при отказе, управляемым службой. Microsoft отслеживает основной кластер и автоматически активирует принудительное повышение, если основной кластер неработоспособен.

• Грациозное продвижение: Предотвращает потерю данных, но требует некоторого простоя во время нереплицированной записи. Для плавного переключения оба кластера должны быть работоспособны, поэтому его нельзя выполнить во время сбоя в регионе.

Дополнительные сведения см. в разделе Режимы отработки отказа между регионами в Azure DocumentDB.

Требования

• Поддержка региона: Репликацию между регионами можно использовать во всех регионах Azure, поддерживающих Azure DocumentDB.

• Уровень вычислений: Для репликации между регионами требуется уровень вычислений M30 или более поздней версии.

Рекомендации

• Сетевой доступ: Кластеры реплик не наследуют сетевые параметры из основного кластера. Настройте правила брандмауэра или частные конечные точки доступа отдельно в кластере-реплике и проверьте подключение перед переключением при отказе. Дополнительные сведения см. в разделе «Непрерывные операции записи, операции чтения на репликах кластера и строки подключения».

• Поддержка функций: Кластеры реплик не поддерживают восстановление на определенный момент времени (PITR) или высокий уровень доступности в регионе.

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

  Дополнительные сведения см. в разделе "Ограничения и квоты службы Azure DocumentDB".

Cost

Репликация между регионами добавляет затраты на вычислительные ресурсы и ресурсы хранилища кластера реплики. Также применяются расходы на передачу данных между регионами. Сведения о ценах см. в разделе цены на Azure DocumentDB и тарифы на пропускную способность.

Настройка поддержки нескольких регионов

• Создайте кластер реплики: Чтобы включить репликацию между регионами, создайте кластер реплики из основного кластера. Вы можете создать кластер реплики при создании основного кластера или позже. Инструкции см. в статье "Управление репликацией между регионами и тем же регионом" в кластере Azure DocumentDB.

• Настройте автоматическую отработку отказа: Если вы хотите, чтобы Azure автоматически повысить уровень реплики во время сбоя основного региона, включите отработку отказа, управляемой службой. Дополнительные сведения см. в разделе Включение автоматического переключения при отказе, управляемого службой.

  Note

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

Поведение, когда все регионы работоспособны

В этом разделе описывается, чего ожидать при настройке кластера Azure DocumentDB для межрегиональной репликации, когда все регионы находятся в рабочем состоянии.

• Операция между регионами: Основной кластер обслуживает весь трафик чтения и записи. Кластер реплик обслуживает трафик только для чтения; его можно использовать для масштабирования нагрузки на чтение или для того, чтобы трафик чтения оставался локальным для определенного региона. Глобальная строка подключения для чтения и записи всегда указывает на текущий кластер, доступный для записи, поэтому клиентам не нужно отслеживать, какой регион является основным.

• Репликация данных между регионами: Репликация между основным кластером и кластером реплики является асинхронной. Записи фиксируются в основном кластере и признаются клиенту перед репликацией в кластер реплики. Этот подход предотвращает задержку в сети между регионами, влияющую на производительность записи. Поскольку репликация является асинхронной, между основным кластером и кластером-репликой ожидается некоторая задержка репликации, и при принудительном переключении при отказе могут быть потеряны любые записи, не успевшие реплицироваться.

Поведение во время сбоя региона

В этом разделе описывается, что следует ожидать при настройке кластера DocumentDB Azure для репликации между регионами и сбоя в регионе основного кластера.

• Обнаружение и реагирование: Ответственность за обнаружение сбоя и реагирование зависит от типа переключения при отказе, используемого в кластере.

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

  Дополнительные сведения см. в разделе Режимы отработки отказа между регионами в Azure DocumentDB.

• Уведомление: Microsoft не уведомляет вас автоматически об отключении региона. Однако вы можете использовать Работоспособность служб Azure, чтобы понять общее состояние службы, включая сбои в любом регионе, и настроить оповещения Service Health для уведомления о проблемах.

• Активные запросы: Все активные запросы к неработоемому основному региону могут завершиться ошибкой. После завершения отработки отказа приложения должны повторно подключиться и повторить попытку в кластере с повышенными возможностями.

• Ожидаемая потеря данных: Переключения при отказе во время сбоев региона происходят незапланированно, поэтому операции записи, не успевшие реплицироваться, могут быть потеряны, так как репликация асинхронна.

• Ожидаемое время простоя: Общее время простоя зависит от времени обнаружения, режима отработки отказа и поведения повторного подключения клиента.

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

  После запуска акции она обычно завершается в течение нескольких минут.

• Переключение: Глобальная строка подключения для чтения и записи автоматически указывает на кластер, назначенный основным, после такого переключения. Для приложений, использующих строки подключения для конкретного кластера, могут потребоваться обновления конфигурации, поэтому они направляют трафик в здоровый кластер.

Восстановление региона

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

Проверка сбоев в регионе

Регулярно тестируйте процесс аварийного восстановления, продвигая кластер реплик в управляемой среде.

• Используйте принудительное повышение роли для имитации поведения системы при сбое. Этот тест может привести к потере данных, поэтому рассмотрите возможность выполнения этого теста в непроизводной среде. Дополнительные сведения см. в разделе Принудительное повышение.

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

Резервное копирование и восстановление

Репликация и поддержка зон доступности помогают сохранить кластер доступным во время сбоев инфраструктуры. Azure DocumentDB автоматически принимает непрерывные резервные копии, которые устраняют другой риск, включив восстановление на определенный момент времени (PITR) после случайного удаления или изменения данных. Azure DocumentDB выполняет резервные копии, не влияя на производительность или доступность операций базы данных. Дополнительные сведения о том, как репликация и резервное копирование устраняют различные риски, см. в разделе "Избыточность", "Репликация" и "Резервное копирование".

Azure DocumentDB сохраняет резервные копии отдельно от исходных данных. В регионах, поддерживающих зоны доступности, служба сохраняет снимки резервных копий в трех зонах доступности. Azure DocumentDB управляет этими резервными копиями, и их нельзя экспортировать. Сервис хранит резервные копии 35 дней для активных кластеров, 7 дней для активных кластеров уровня Burstable (M10, M20, M25) и 7 дней для удаленных кластеров.

Вы можете восстановить резервную копию в новом кластере. После этого необходимо выполнить набор задач после восстановления.

Дополнительные сведения см. в разделе "Восстановление кластера" в Azure DocumentDB.

Устойчивость к обслуживанию служб

Корпорация Майкрософт регулярно применяет обновления служб и выполняет другое обслуживание. Платформа Azure автоматически обрабатывает эти действия, обеспечивая простое и прозрачное обслуживание. Во время мероприятий технического обслуживания простой не ожидается, если только вас не предупредили через Работоспособность служб Azure о плановом обслуживании.

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

Соглашение об уровне обслуживания

Соглашение об уровне обслуживания (SLA) для служб Azure описывает ожидаемую доступность каждой службы и условия, которые должно соответствовать вашему решению для достижения этого ожидания доступности. Дополнительные сведения см. в разделе SLA для онлайн-услуг.

Для Azure DocumentDB соглашения об уровне обслуживания доступности применяются только в том случае, если в кластере включен высокий уровень доступности (HA). Различные соглашения об уровне обслуживания доступности применяются к следующим конфигурациям:

• Кластеры с поддержкой высокой доступности, охватывающие несколько регионов Azure с использованием межрегиональной репликации.

• Кластеры с поддержкой высокой доступности в одном регионе.

Связанные материалы

• Совместимость функций с MongoDB
• Переход с MongoDB на Azure DocumentDB
• Создание кластера Azure DocumentDB
• Надежность в Azure