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

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

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

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

Рекомендации по развертыванию в производственной среде

Платформа Azure Well-Architected Framework предоставляет рекомендации по надежности, безопасности, затратам, операциям и производительности. Чтобы понять, как эти области влияют друг на друга и способствуют надежному решению Azure Cosmos DB, ознакомьтесь с рекомендациями Architecture для Azure Cosmos DB.

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

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

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

Основной ресурс, который вы развертываете, является Azure Cosmos DB account. Каждая учетная запись может содержать несколько баз данных с несколькими контейнерами. Контейнеры служат логическими единицами распределения и масштабируемости. Вы можете создавать контейнеры, такие как коллекции, таблицы и графы, в зависимости от API, используемого для взаимодействия с Azure Cosmos DB. Дополнительные сведения о модели ресурсов см. в разделе Базы данных, контейнеры и элементы в Azure Cosmos DB. Каждый контейнер использует секционирование, которое поддерживает высокую масштабируемую и высокую производительность.

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

Одна учетная запись может охватывать несколько регионов Azure, что улучшает вашу устойчивость к сбоям в регионах. Для чтения можно настроить несколько регионов, а если используется уровень "Критически важный для бизнеса", можно использовать несколько регионов для записи. Azure Cosmos DB автоматически выполняет геореплицирование данных. Поведение георепликации зависит от используемой конфигурации, такой как уровень согласованности, который указывает, как необходимо обеспечить компромисс между согласованностью данных, доступностью, задержкой и пропускной способностью. Различные уровни согласованности оптимизируются для различных проблем, поддерживают разные гарантии и предоставляют различные типы репликации между регионами.

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

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

Внутренне Azure Cosmos DB управляет данными с помощью различных конструкций, включая физичные секции, партийные наборы и replica sets. Дополнительные сведения о том, как работает Azure Cosmos DB, см. в разделе Global data distribution with Azure Cosmos DB - under the hood.

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

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

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

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

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

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

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

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

Диаграмма, на которой показан аккаунт Azure Cosmos DB с репликацией, содержащей три реплики, распределённых по трем отдельным зонам доступности.

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

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

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

Подсказка

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

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

Requirements

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

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

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

Соображения

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

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

Cost

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

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

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

Для бессерверных учетных записей необходимо включить избыточность зоны при создании учетной записи.

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

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

  • Cross-zone operation: Azure Cosmos DB автоматически направляет запросы на реплики между зонами доступности, чтобы любая реплика может обслуживать запрос.

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

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

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

  • Обнаружение и реагирование: Платформа Azure Cosmos DB отвечает за обнаружение сбоя в зоне доступности. Вам не нужно ничего делать, чтобы инициировать переключение зоны.

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

  • Ожидаемая потеря данных: Из-за сбоя зоны не ожидается потеря данных.

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

  • Redistribution: Azure Cosmos DB автоматически перенаправляет входящие запросы на здоровые реплики в других зонах доступности. При сбое зоны доступности платформа автоматически перераспределяет подготовленную пропускную способность для других реплик.

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

Когда зона доступности восстанавливается, Azure Cosmos DB автоматически восстанавливает реплики в зоне доступности и перенаправляет трафик между репликами как обычно.

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

Аварийное переключение и восстановление зоны доступности для Azure Cosmos DB автоматически выполняются Microsoft. Не нужно инициировать или проверять процессы сбоя зоны доступности.

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

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

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

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

Configuration Тип сбоя Влияние на доступность Влияние на устойчивость Что делать
Учетная запись для одного региона Сбой в регионе Доступ на чтение и запись потерян до восстановления службы. Без потери данных, если регион не испытывает невосстановленную катастрофу. Подождите восстановления службы или запросите восстановление учетной записи из резервной копии в другом регионе.
Режим одной записи, учетная запись для нескольких регионов Сбой региона чтения SDK перенаправляется в доступные регионы на основе конфигурации предпочтительных регионов.

Для учетных записей, использующих строжную согласованность только с двумя регионами, или ограниченную избыточной устарелостью за пределами окна устарелости, доступность записи также теряется, если вы не выключите затронутый регион в автономный режим.		 Потери данных нет. Обеспечение достаточной пропускной способности в оставшихся регионах. Для обеспечения строгой или ограниченной согласованности данных, рассмотрите возможность отключения затронутого региона.
Режим одной записи, учетная запись для нескольких регионов Сбой региона записи (с включенной функцией PPAF) Автоматический переход на резервный раздел на уровне разделов; ручное вмешательство не требуется. Если учетная запись использует надежную согласованность, потери данных нет. Если учетная запись не использует строгое согласование, нераспространенные данные могут быть потеряны в маловероятном случае, когда регион испытывает постоянную потерю данных. Действия не требуется. PPAF автоматически управляет резервным переключением.
Режим одной записи, учетная запись для нескольких регионов Сбой области записи (без PPAF) Доступность записи теряется до завершения операции отключения региона или отработки отказа, управляемой службой. Чтение продолжается из здоровых регионов. Если учетная запись использует надежную согласованность, потеря данных не происходит. Если учетная запись не использует строгую согласованность, недублированные данные могут быть потеряны в маловероятном случае, когда регион подвергается постоянной потере данных. Выполните операцию перевода региона в автономный режим. Если отработка отказа, управляемой службой, включена, Azure Cosmos DB запускает отработку отказа автоматически, но это может занять один час или несколько. Не изменяйте область записи во время сбоя.
Учетная запись с возможностью записи в нескольких регионах Сбой в каком-либо регионе Автоматическая маршрутизация в здоровые регионы с помощью конфигурации пакета SDK; не требуется вмешательства вручную. Недавно обновленные данные в регионе сбоя могут быть недоступны в оставшихся регионах. В маловероятном случае постоянной потери данных в регионе, не реплицированные данные могут быть утрачены. Обеспечение достаточной пропускной способности в оставшихся регионах. После восстановления Azure Cosmos DB автоматически восстанавливает нереплицированные данные с помощью настроенного метода разрешения конфликтов.
Любая конфигурация учетной записи Повреждение или случайное удаление данных Нет влияния на доступность. Потенциальная потеря данных в зависимости от обнаружения повреждения или удаления. Восстановление на определенный момент времени (непрерывное резервное копирование) или восстановление из периодической резервной копии.

Замечание

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

Пакеты SDK и устойчивость

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

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

Потенциальная потеря данных в случае сбоев в регионе

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

Уровень согласованности RPO для сбоя региона
Сеанс, согласованный префикс, в конечном итоге Менее 15 минут
Ограниченная устарелость K и T
Сильные 0

K = количество версий (т. е. обновлений) элемента.

T = интервал времени с момента последнего обновления.

Для учетных записей с несколькими регионами минимальное значение K и T составляет 100 000 операций записи или 300 секунд. Это значение определяет минимальный RPO для данных при использовании ограниченной устарелости.

Дополнительные сведения о различиях между уровнями согласованности см. в разделе "Уровни согласованности" в Azure Cosmos DB.

Несколько регионов чтения с одним регионом записи

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

Диаграмма с учетной записью Azure Cosmos DB. Регион A — это регион записи и чтения, а регион B — это регион чтения. Приложение в регионе A выполняет операции чтения и записи для учетной записи Azure Cosmos DB в этом же регионе. Приложение в регионе B выполняет операции чтения с учетной записи в регионе B, но записывает данные в регион A. Внутренне, Azure Cosmos DB реплицирует изменения между регионами.

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

Вы можете настроить пакет SDK Azure Cosmos DB с учетом приоритетного списка регионов для чтения. Пакет SDK подключает приложение к первому доступному региону в списке. Во время сбоя региона чтения пакет SDK обнаруживает сбой региона с помощью кодов ответов серверной части, помечает его как недоступный и направляет будущие операции в следующий доступный регион в списке предпочтений. Убедитесь, что список предпочитаемых регионов установлен правильно и соответствует вашим бизнес-требованиям и требованиям к задержке. Подробные инструкции см. в статье "Устранение неполадок с доступностью пакета SDK Для Azure Cosmos DB".

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

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

Azure Cosmos DB предоставляет несколько типов переключения при отказе:

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

    Замечание

    Автоматический отказоустойчивый переход по разделам доступен в общедоступной предварительной версии. Эта функция предоставляется без соглашения об уровне обслуживания. Для получения дополнительной информации см. Дополнительные условия использования для предварительных версий Microsoft Azure.

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

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

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

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

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

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

    Эта операция требует, чтобы регионы были работоспособными, поэтому его нельзя использовать во время сбоя региона.

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

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

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

Requirements

Region support: Вы можете настроить любой регион Azure в качестве региона чтения для учетной записи Azure Cosmos DB.

Cost

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

Настройка нескольких регионов чтения

Планирование ресурсов и управление ими

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

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

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

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

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

Это важно

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

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

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

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

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

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

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

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

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

  • Ожидаемая потеря данных: Сбой в регионе чтения не приводит к потере данных. Azure Cosmos DB продолжает соблюдать гарантии согласованности чтения.

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

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

    • Принудительное переключение: Время простоя зависит от:

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

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

        Предупреждение

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

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

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

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

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

    Замечание

    Если вы используете частные конечные точки с учетной записью Azure Cosmos DB, убедитесь, что частный DNS правильно выполняет маршрутизацию после операции, связанной с отключением региона. Подробные рекомендации см. в разделе "Аспекты отказоустойчивости частных конечных точек".

Поведение во время сбоя области записи

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

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

    • PPAF: Microsoft автоматически обнаруживает сбой и при необходимости инициирует переключение некоторых разделов. Приложению не нужно предпринимать никаких действий.

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

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

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

    • Service-managed failover: Microsoft автоматически обнаруживает сбой и инициирует переключение на резервный ресурс для вашей учетной записи. Приложению не нужно предпринимать никаких действий.

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

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

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

    • PPAF: Если ppAF включен, ожидается краткое прерывание, которое обычно составляет около 3 минут.

    • Принудительное отработка отказа: Время простоя зависит от:

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

    Предупреждение

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

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

  • Перераспределение: Перераспределение записываемого трафика зависит от типа отказоустойчивости вашей учетной записи.

    • PPAF: Azure Cosmos DB автоматически переключает неработающий раздел на здоровый узел региона.

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

    Замечание

    Если вы используете частные конечные точки с учетной записью Azure Cosmos DB, убедитесь, что частный DNS правильно маршрутизируется после выполнения операции в автономном регионе. Подробные рекомендации см. в разделе "Аспекты отказоустойчивости частных конечных точек".

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

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

Microsoft должен вернуть регион в интернет. Когда регион восстанавливается после сбоя, Microsoft автоматически переносит регион в режим "в сети". Однако этот процесс может занять несколько дней.

Это важно

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

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

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

  • После сбоя региона записи: Когда затронутый регион находится в сети, регион отображается как "онлайн" на портале Azure и становится доступным в виде региона чтения. На этом этапе безопасно изменить регион записи обратно в восстановленный регион.

    Это важно

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

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

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

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

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

Если ваша учетная запись использует PPAF, можно имитировать отказоустойчивость для раздела. Дополнительные сведения см. в разделе "Тестирование настройки PPAF" (имитация сбоя).

Несколько регионов записи

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

Диаграмма, показывающая учетную запись Azure Cosmos DB. Регион A и регион B обладают возможностью записи и чтения. Приложение в регионе A выполняет операции чтения и записи для учетной записи Azure Cosmos DB в соответствующем регионе. Приложение в регионе B выполняет операции чтения и записи в учетной записи Azure Cosmos DB в соответствующем регионе. Azure Cosmos DB асинхронно реплицирует изменения между регионами.

При настройке учетной записи Azure Cosmos DB для нескольких регионов записи строгие согласованности не поддерживаются и могут возникнуть конфликты записи. Регион хаб выполняет функцию арбитра в конфликтах записи. Дополнительные сведения о том, как устранить эти конфликты, см. в разделе "Типы конфликтов" и политики разрешения конфликтов при использовании нескольких регионов записи.

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

Requirements

Region support: Вы можете настроить любой Azure регион в качестве области чтения или записи для учетной записи Azure Cosmos DB.

Cost

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

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

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

Чтобы эффективно использовать несколько регионов записи, приложение также должно быть настроено соответствующим образом. См. Настройка многорегиональных записей в приложениях, использующих Azure Cosmos DB.

Планирование ресурсов и управление ими

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

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

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

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

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

  • Обнаружение и ответ: Приложение обнаруживает потерю региона. SDK Azure Cosmos DB предоставляют возможности автоматического выбора регионов, которые направляют операции чтения и записи в доступные регионы.

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

  • Ожидаемая потеря данных: Недавно обновленные данные могут стать недоступными в других регионах. Сведения о максимальной потере данных, ожидаемой во время сбоя региона, см. в статье "Потенциальные потери данных во время сбоев регионов". В маловероятном случае, если затронутый регион подвергается постоянной потере данных, вы можете потерять нереплицированные данные.

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

    Подсказка

    Для получения наилучших результатов глобально распределенные приложения должны выполняться глобальной службой балансировки нагрузки, например Azure Front Door или Диспетчер трафика Azure. Эти службы могут обнаруживать региональное ухудшение и автоматически перенаправлять трафик в экземпляры приложений в исправном регионе.

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

    Подсказка

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

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

Когда затронутый регион снова находится в сети, регион отображается как "в сети" на портале Azure и снова становится доступным.

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

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

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

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

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

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

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

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

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

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

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

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

  • Предоставленная пропускная способность
  • Учетная запись в одном регионе с поддержкой зоны доступности (зональная избыточность)
  • Учетные записи, использующие несколько регионов чтения
  • Учетные записи, использующие несколько регионов записи (уровень "Критически важный для бизнеса")

Связанный контент

  • Last updated on