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

Надежность в хранилище BLOB-объектов Azure

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

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

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

Замечание

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

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

Сведения о развертывании хранилища BLOB-объектов Azure для поддержки требований к надежности решения и о том, как надежность влияет на другие аспекты архитектуры, см. в статье "Рекомендации по архитектуре для хранилища BLOB-объектов Azure " в Azure Well-Architected Framework.

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

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

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

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

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

Временные сбои

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

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

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

  • Используйте клиентские библиотеки службы хранилища Azure, которые включают встроенные политики повторных попыток с экспоненциальным обратным выходом и jitter. Пакеты SDK для .NET, Java, Python и JavaScript автоматически обрабатывают повторные попытки для временных сбоев. Подробные параметры конфигурации повторных попыток см. в руководстве по политике повторных попыток службы хранилища Azure.

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

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

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

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

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

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

Поддержка регионов

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

Требования

Избыточность зоны доступна как для типов учетных записей хранения BLOB-объектов уровня "Стандартный" версии 2, так и для блочных BLOB-объектов уровня "Премиум". Все типы BLOB-объектов (блочные BLOB-объекты, добавление больших двоичных объектов и страничные BLOB-объекты) поддерживают конфигурации, избыточные между зонами, но тип используемой учетной записи хранения определяет, какие возможности доступны. Дополнительные сведения см. в разделе "Поддерживаемые типы учетных записей хранения".

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

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

Подробные сведения о ценах см. в разделе о ценах на хранилище BLOB-объектов Azure.

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

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

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

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

Нормальная работа

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

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

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

Опыт понижения зоны

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

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

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

  • Уведомление: События сбоя зоны можно отслеживать с помощью службы "Работоспособность служб Azure" и "Работоспособность ресурсов". Настройте оповещения в этих службах для получения уведомлений о проблемах уровня зоны.

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

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

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

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

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

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

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

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

Поддержка нескольких регионов

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

Это важно

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

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

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

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

Типы отработки отказа

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

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

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

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

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

Поддержка регионов

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

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

Требования

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

Соображения

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

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

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

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

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

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

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

Подробные сведения о ценах см. в разделе о ценах на хранилище BLOB-объектов Azure.

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

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

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

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

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

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

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

Нормальная работа

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

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

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

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

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

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

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

Опыт региональной недоступности

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

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

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

      • Отображаются ли проблемы с доступом к учетной записи хранения в основном регионе Azure Resource Health

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

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

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

    • Уведомление: События сбоя региона можно отслеживать с помощью службы "Работоспособность служб Azure" и "Работоспособность ресурсов". Настройте оповещения в этих службах для получения уведомлений о проблемах на уровне региона.

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

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

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

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

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

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

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

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

    • Уведомление: События сбоя региона можно отслеживать с помощью службы "Работоспособность служб Azure" и "Работоспособность ресурсов". Настройте оповещения в этих службах для получения уведомлений о проблемах на уровне региона.

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

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

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

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

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

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

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

    • Уведомление: События сбоя региона можно отслеживать с помощью службы "Работоспособность служб Azure" и "Работоспособность ресурсов". Настройте оповещения в этих службах для получения уведомлений о проблемах на уровне региона.

    Это важно

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

Возврат к исходному состоянию

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

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

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

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

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

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

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

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

Альтернативные подходы с несколькими регионами

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

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

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

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

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

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

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

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

Репликация объектов может быть настроена для репликации всех BLOB-объектов в контейнере или определенных подмножеств на основе префиксов и тегов BLOB-объектов. Репликация асинхронна и происходит в фоновом режиме. Можно настроить несколько политик репликации и даже репликацию цепочки в нескольких учетных записях хранения для создания сложных топологий с несколькими регионами.

Репликация объектов несовместима со всеми учетными записями хранения. Например, репликация объектов не работает с учетными записями хранения, используюющими иерархические пространства имен (также называемые учетными записями Azure Data Lake 2-го поколения).

Подробные рекомендации по реализации см. в разделе "Репликация объектов" для блочных BLOB-объектов и настройка репликации объектов.

Резервные копии

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

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

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

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

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

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

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

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

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