Надежность в Хранилище очередей Azure

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

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

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

Замечание

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

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

Для рабочих сред:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • Реализуйте паттерны Circuit Breaker в своем приложении при обработке сообщений из очередей. Шаблоны разбиения цепи предотвращают каскадные сбои при возникновении проблем с подчиненными службами.

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

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

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

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

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

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

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

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

Требования

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

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

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

Подробные сведения о ценах см. в разделе Тарифы на Queue Storage.

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

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

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

    2. Создайте очередь.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Это важно

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

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

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

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

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

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

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

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

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

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

Требования

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

Соображения

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

  • Задержка асинхронной репликации: Репликация данных в дополнительный регион является асинхронной, что означает, что задержка между записью данных в основной регион и когда она становится доступной в дополнительном регионе. Эта задержка может привести к потенциальной потере данных, если происходит сбой основного региона до репликации последних данных. Потеря данных измеряется целевой точкой восстановления (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 выполнить аварийное переключение в другой регион

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    Это важно

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Замечание

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

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

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

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

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

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

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

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

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

  • Last updated on