Надежность в хранилище таблиц Azure

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

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

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

Замечание

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

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

Для рабочих сред выполните следующие действия:

  • Включите зонально-избыточное хранилище (ZRS) для учетных записей хранения данных, содержащих ресурсы Table Storage. ZRS обеспечивает более высокую доступность, реплицируя данные синхронно в нескольких зонах доступности в основном регионе. Эта репликация защищает от сбоев зоны доступности.

  • Если вам нужна устойчивость к сбоям в работе региона и основной регион вашей учетной записи хранения образует пару с другим регионом, рассмотрите возможность включения геоизбыточного хранилища (GRS) для асинхронной репликации данных в парный регион. В поддерживаемых регионах можно объединить геоизбыточность с зональной избыточностью, используя геозонально-избыточное хранилище (GZRS).

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

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

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

Локально избыточное хранилище (LRS) реплицирует данные в учетных записях хранения в одну или несколько зон доступности Azure, расположенных в основном регионе вашего выбора. Хотя нет возможности выбрать предпочтительную зону доступности, Azure может перемещать или расширять учетные записи LRS между зонами, чтобы повысить балансировку нагрузки. Нет гарантии, что ваши данные распределены по зонам. Дополнительные сведения о availability zones см. в разделе "Что такое Зоны доступности?"

Схема, показывающая, как данные реплицируются в зонах доступности с помощью LRS.

Хранилище с зональной избыточностью (ZRS), хранилище с геоизбыточностью (GRS) и хранилище с геозональной избыточностью (GZRS) обеспечивают дополнительную защиту. В этой статье подробно описаны эти параметры.

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

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

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

Клиентские библиотеки хранилища таблиц и пакеты SDK включают встроенные политики повторных попыток, которые автоматически обрабатывают распространенные временные сбои, такие как время ожидания сети, недоступность временной службы (HTTP 503), регулирование ответов (HTTP 429) и условия перегрузки сервера секционирования. Когда приложение испытывает эти временные условия, клиентские библиотеки автоматически повторяют операции с помощью экспоненциальных стратегий обратной передачи.

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

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

  • Реализуйте экспоненциальную задержку в политиках повторных попыток, особенно если приложение получает ошибку HTTP 503 (сервер занят) или HTTP 500 (истекло время ожидания операции). Хранилище таблиц может ограничивать скорость обработки запросов, когда отдельные разделы испытывают высокую нагрузку или когда нагрузка приближается к пределам учетной записи хранения.

  • Разработайте логику повторных попыток с учетом секционирования в высоконагруженных приложениях. Логика повторных попыток с учётом секций — это более продвинутый подход, который учитывает секционированную архитектуру в Table Storage и распределяет операции по нескольким разделам, чтобы снизить вероятность применения ограничений на отдельных серверах разделов.

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

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

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

Хранилище таблиц является избыточным по зонам при развертывании с конфигурацией ZRS. В отличие от локально избыточного хранилища (LRS), ZRS гарантирует, что Azure синхронно реплицирует данные таблицы в нескольких зонах доступности. Эта конфигурация гарантирует, что таблицы остаются доступными, даже если вся зона доступности становится недоступной. Все операции записи должны быть подтверждены в нескольких зонах, прежде чем служба завершит запись, которая обеспечивает надежные гарантии согласованности.

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

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

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

Требования

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

  • Типы учетных записей хранения: Для включения ZRS для хранилища таблиц необходимо использовать учетную запись хранения общего назначения уровня "Стандартный" версии 2. Учетные записи хранения класса Premium не поддерживают хранилище таблиц.

Себестоимость

При использовании хранилища с зональной избыточностью (ZRS) вы оплачиваете его по другому тарифу, чем хранилище с локальной избыточностью (LRS), из-за дополнительных накладных расходов на репликацию и хранение.

Подробные сведения о ценах см. в разделе "Цены на хранилище таблиц".

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

  • Создайте учетную запись хранилища с зональной избыточностью и таблицу:

    1. Создание учетной записи хранения. Обязательно выберите ZRS, GZRS или геоизбыточное хранилище с доступом для чтения (RA-GZRS) в качестве варианта избыточности.

    2. Создайте таблицу.

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

  • Отключите избыточность в зоне. Преобразуйте учетные записи ZRS обратно в незональную конфигурацию, например локально избыточное хранилище (LRS), используя тот же процесс изменения конфигурации избыточности.

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

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

  • Маршрутизация трафика между зонами: Служба хранилища Azure с хранилищем с избыточностью между зонами (ZRS) автоматически распределяет запросы между кластерами хранилища в нескольких зонах доступности. Распределение трафика прозрачно для приложений и не требует настройки на стороне клиента.

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

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

Когда зона доступности становится недоступной, Table Storage автоматически выполняет переключение при отказе, демонстрируя следующее поведение:

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

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

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

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

  • Перенаправка трафика: Если зона становится недоступной, Azure выполняет обновления сети, такие как перенаправка системы доменных имен (DNS), чтобы запросы направлялись в оставшиеся здоровые зоны доступности. Сервис сохраняет полную функциональность за счёт использования исправных зон и не требует вмешательства клиента.

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

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

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

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

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

Службы хранилища Azure, включая Хранилище BLOB-объектов Azure, Файлы Azure, Azure Table Storage и Хранилище очередей Azure, предоставляют ряд возможностей геоизбыточности и аварийного переключения для различных требований.

Это важно

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

Георезервное хранилище для парных регионов

Хранилище Azure поддерживает несколько типов GRS в парных регионах. Независимо от используемого типа GRS служба всегда реплицирует данные в дополнительном регионе с помощью локально избыточного хранилища (LRS). Этот подход обеспечивает защиту от сбоев оборудования в дополнительном регионе.

Типы аварийного переключения

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

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

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

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

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

Требования

Соображения

При реализации мультирегионального табличного хранилища следует учитывать следующие важные факторы:

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

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

  • Доступ ко вторичному региону: При использовании геоизбыточного хранилища (GRS) и гео-зонально-избыточного хранилища (GZRS) вторичный регион недоступен для чтения до тех пор, пока не произойдет переключение при отказе.

    Конфигурации геоизбыточного хранилища с доступом на чтение (RA-GRS) и геозонально-избыточного хранилища с доступом на чтение (RA-GZRS) обеспечивают доступ на чтение к вторичному региону во время обычных операций, но из-за задержки асинхронной репликации они могут возвращать несколько устаревшие данные.

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

Себестоимость

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

Подробные сведения о ценах см. в разделе "Цены на хранилище таблиц".

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

  • Создайте учетную запись геоизбыточного хранилища (GRS). Чтобы создать учетную запись GRS, см. раздел «Создание учетной записи хранения» и при создании учетной записи выберите GRS, геоизбыточное хранилище с доступом на чтение (RA-GRS), геозонально-избыточное хранилище (GZRS) или геозонально-избыточное хранилище с доступом на чтение (RA-GZRS).

  • Включите геоизбыточность для существующей учетной записи хранения данных. Сведения о преобразовании существующей учетной записи хранения в геоизбыточное хранилище (GRS) см. в статье "Изменение репликации учетной записи хранения".

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

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

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

  • Отключите геоизбыточность. Преобразуйте учетные записи GRS обратно к однорегиональным конфигурациям, таким как локально-избыточное хранилище (LRS) или хранилище с зональной избыточностью (ZRS), с помощью того же процесса изменения конфигурации избыточности.

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

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

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

    Для конфигураций георезервируемого хранилища с доступом на чтение (RA-GRS) и геозонально-резервируемого хранилища с доступом на чтение (RA-GZRS) приложения при необходимости могут читать данные из вторичного региона через вторичную конечную точку. Этот подход требует явной настройки приложения и не является автоматическим. Кроме того, из-за задержки асинхронной репликации данные в дополнительном регионе могут быть немного устаревшими.

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

    • Локально избыточное хранилище (LRS) для геоизбыточного хранилища (GRS) и RA-GRS
    • Хранилище с избыточностью между зонами (ZRS) для георезервируемого хранилища (GZRS) и RA-GZRS

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

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

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

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

  • Аварийное переключение, управляемое клиентом (незапланированное): Используйте незапланированное аварийное переключение в случае недоступности хранилища в основном регионе.

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

      • Показывает ли Azure Работоспособность ресурсов проблемы с доступом к учетной записи хранилища в основном регионе

      • Советует ли корпорация Майкрософт выполнить аварийное переключение в другой регион

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

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

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

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

    • Ожидаемая потеря данных: Потеря данных возможна при внеплановом переключении при отказе из-за задержки асинхронной репликации, а это означает, что недавние операции записи могут не быть реплицированы. Вы можете посмотреть свойство «Время последней синхронизации», чтобы понять, сколько данных может быть потеряно при незапланированном переключении при отказе. Ожидаемая потеря данных часто называется целевой точкой восстановления (RPO). Обычно можно ожидать, что RPO будет менее 15 минут, но это время не гарантируется.

    • Ожидаемое время простоя: Количество ожидаемого простоя часто называется целевой задачей времени восстановления (RTO). Отказоустойчивость, контролируемая клиентом, обычно занимает до 60 минут в зависимости от размера аккаунта и сложности.

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

    • Конфигурация после аварийного переключения: После завершения незапланированного аварийного переключения ваша учетная запись хранения данных в целевом регионе использует уровень хранилища с локальной избыточностью (LRS). Если необходимо снова выполнить геореплицирование, необходимо повторно включить геоизбыточное хранилище (GRS) и дождаться репликации данных в новый дополнительный регион.

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

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

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

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

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

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

    • Ожидаемое время простоя: Отработка отказа обычно завершается в течение 60 минут, что означает, что ожидаемое время восстановления (RTO) составляет 60 минут в зависимости от размера учетной записи и сложности. Во время отработки отказа конечные точки основной и вторичной учетной записи хранения становятся временно недоступными для операций чтения и записи.

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

    • Конфигурация после отработки отказа: После завершения плановой отработки отказа учетная запись хранилища в целевом регионе продолжает геореплицироваться и остается на уровне GRS (Geo-Redundant Storage).

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

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

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

    Это важно

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

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

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

  • Переключение при отказе, инициируемое клиентом (незапланированное): После незапланированного переключения при отказе учетная запись хранения настраивается на использование локально избыточного хранилища (LRS). Чтобы выполнить обратное переключение, необходимо восстановить связь с геоизбыточным хранилищем (GRS) и дождаться репликации данных.

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

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

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

Вы можете имитировать региональные сбои для тестирования процедур аварийного восстановления.

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

  • Тестирование вторичного конечного узла: Для конфигураций геоизбыточного хранилища с доступом на чтение (RA-GRS) и геозонально-избыточного хранилища с доступом на чтение (RA-GZRS) регулярно проверяйте операции чтения через вторичный конечный узел, чтобы убедиться, что ваше приложение может успешно считывать данные из вторичного региона.

Кастомные многорегиональные решения для повышения отказоустойчивости

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

  • Ваша учетная запись хранения находится в непарализованном регионе.

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

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

  • Для разных регионов требуется активная и активная конфигурация.

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

Замечание

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

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

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

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

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

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

В сценариях, требующих резервного копирования данных из хранилища таблиц, рассмотрим следующие подходы:

  • Экспорт с помощью фабрики данных Azure. Используйте коннектор Фабрика данных Azure для хранилища таблиц, чтобы экспортировать свои сущности в другое место. Например, можно создать резервную копию каждой сущности в JSON-файл, хранящийся в хранилище BLOB-объектов Azure.

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

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

Дополнительные сведения о том, как избыточность и резервное копирование устраняют различные риски, см. в разделе " Избыточность", "Репликация" и "Резервное копирование".

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

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

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

  • Last updated on