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


Репликация службы хранилища Azure

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

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

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

Примечание.

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

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

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

Избыточность в основном регионе

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

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

Примечание.

Корпорация Майкрософт рекомендует использовать ZRS в основном регионе для рабочих нагрузок Azure Data Lake Storage.

Локально избыточное хранилище

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

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

Запрос на запись в учетную запись хранения, использующую LRS, выполняется синхронно. Операция записи считается успешно выполненной только после записи данных во все три реплики.

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

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

LRS хорошо подходит для следующих сценариев:

  • Если приложение хранит данные, которые можно легко восстановить при потере данных, рассмотрите возможность выбора LRS.
  • Если приложение ограничено репликацией данных только в пределах региона из-за требований к управлению данными, рассмотрите возможность выбора LRS. В некоторых случаях парные регионы, в которых данные геореплицируются, могут находиться в другом регионе. Дополнительные сведения о парных регионах см. на странице Регионы Azure.
  • Если сценарий использует неуправляемые диски Azure, рассмотрите возможность использования LRS. Можно создать учетную запись хранения для неуправляемых дисков Azure с использованием GRS, но это не рекомендуется из-за потенциальных проблем с согласованностью при асинхронной георепликации.

Хранилище с зональной избыточностью

Хранилище с избыточностью по зонам (ZRS) реплицирует данные в учетных записях хранения ваше хранилища в три или более зон доступности Azure, расположенных в избранном вами основном регионе. Каждая зона доступности — это отдельное физическое расположение с независимым питанием, охлаждением и сетью. ZRS обеспечивает устойчивость ресурсов хранилища по крайней мере 99,999999999999 % (12 9s) в течение заданного года. Прочитайте статью "Что такое зоны доступности Azure", чтобы узнать больше о надежности зон доступности.

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

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

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

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

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

Диаграмма, показывающая, как данные реплицируются в основном регионе с помощью ZRS

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

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

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

Избыточность во вторичном регионе

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

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

Служба хранилища Azure предлагает два варианта копирования данных в дополнительный регион.

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

Примечание.

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

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

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

Внимание

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

Геоизбыточное хранилище

Геоизбыточное хранилище (GRS) синхронно копирует ваши данные три раза в одну или более зон доступности в основном регионе с помощью LRS. Затем ваши данные асинхронно копируются в единое физическое расположение во вторичном регионе, который находится в сотнях километров от основного региона. GRS обеспечивает устойчивость ресурсов хранения не менее 99,99999999999999999999 % (16 9s) в течение заданного года.

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

На следующей диаграмме показано, как данные реплицируются с помощью GRS или RA-GRS:

Диаграмма, показывающая, как данные реплицируются с помощью GRS или RA-GRS

Хранилище с геозонально-избыточным хранением

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

С учетной записью GZRS можно продолжать считывать и записывать данные, если зона доступности становится временно недоступной или невосстановимой. Кроме того, данные также остаются устойчивыми во время полного регионального сбоя или аварии, в которой основной регион не может восстановиться. GZRS предназначен для обеспечения по крайней мере 99,999999999999999 % (16 9s) устойчивости объектов в течение заданного года.

На следующей диаграмме показано, как данные реплицируются с помощью GZRS или RA-GZRS:

Диаграмма, показывающая, как данные реплицируются с помощью GZRS или RA-GZRS

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

Доступ на чтение к данным в дополнительном регионе

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

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

Примечание.

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

Создавайте приложения для доступа на чтение к вторичному источнику

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

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

Если доступ на чтение к вторичному объекту включен, приложение можно считывать как из вторичных, так и из основных конечных точек. Вторичная конечная точка добавляет суффикс -secondary к имени учетной записи. Например, если основная конечная точка для хранилища BLOB-объектов — myaccount.blob.core.windows.net, то дополнительной конечной точкой будет myaccount-secondary.blob.core.windows.net. Ключи доступа для учетной записи одинаковы как для основной, так и для дополнительной конечной точки.

Планирование потери данных

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

Сводка по вариантам обеспечения избыточности

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

Параметры устойчивости и доступности

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

Параметр LRS ZRS GRS/RA-GRS GZRS или RA-GZRS
Устойчивость объектов в процентах в течение определенного года по крайней мере 99,999999999 % (11 9s) по крайней мере 99,99999999999 % (12 9s) по крайней мере 99,999999999999999 % (16 9s) по крайней мере 99,999999999999999 % (16 9s)
Доступность для запросов на чтение По крайней мере 99,9% (99% для уровней доступа к прохладному/холодному/архивному) По крайней мере 99,9% (99 % для класса доступности 'Cool'/'Cold') По крайней мере 99,9 % (99 % для уровней доступа к прохладным, холодным и архивным данным) для GRS

По крайней мере 99,99% (99,9% для прохладных/холодных и архивных уровней доступа) для RA-GRS
По крайней мере 99,9% (99 % для уровня прохладного/холодного доступа) для GZRS

По крайней мере 99,99% (99,9% для уровня прохладного/холодного доступа) для RA-GZRS
Доступность для запросов на запись По крайней мере 99,9% (99% для уровней доступа к прохладному/холодному/архивному) По крайней мере 99,9% (99 % для класса доступности 'Cool'/'Cold') По крайней мере 99,9% (99% для уровней доступа к прохладному/холодному/архивному) По крайней мере 99,9% (99 % для класса доступности 'Cool'/'Cold')

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

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

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

Сценарий сбоя LRS ZRS GRS/RA-GRS GZRS или RA-GZRS
Узел в центре обработки данных становится недоступным Да Да Да Да
Весь центр обработки данных (зональный или незональный) становится недоступным Нет Да Да1 Да
Происходит сбой на уровне всего основного региона Нет Нет Да1 Да1
В случае недоступности основного региона можно воспользоваться доступом на чтение в дополнительном регионе Нет Нет Да (с RA-GRS) Да (с RA-GZRS)

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

Поддерживаемые службы хранилища Azure

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

Услуга LRS ZRS GRS RA-GRS GZRS RA-GZRS
Хранилище объектов бинарных данных (BLOB)
(включая Data Lake Storage)
Хранение очередей
Хранилище таблиц
Файлы Azure 1,2 1,2 1 1
Управляемые диски Azure 3
Azure Elastic SAN

1 Стандартные файловые ресурсы (HDD) поддерживаются в LRS и ZRS. Общие файловые ресурсы уровня "Стандарт" поддерживаются для GRS и GZRS, если их размер не превышает 5 ТиБ.
На LRS и ZRS поддерживаются 2 общие папки SSD.
3 Управляемые диски ZRS имеют некоторые ограничения. Подробные сведения см. в разделе Ограничения статьи об избыточных параметрах для управляемых дисков.

Поддерживаемые типы учетных записей хранения

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

Типы учетных записей хранения LRS ZRS GRS/RA-GRS GZRS или RA-GZRS
Рекомендуется Общий стандартный процессор назначения v2 (StorageV2)1

Блочные BLOB-объекты категории "Премиум" (BlockBlobStorage)1

Общие файловые ресурсы SSD (FileStorage)

Премиум класса страничные BLOBы (StorageV2)
Общий стандартный процессор назначения v2 (StorageV2)1

Блочные BLOB-объекты категории "Премиум" (BlockBlobStorage)1

Общие файловые ресурсы SSD (FileStorage)
Общий стандартный процессор назначения v2 (StorageV2)1 Общий стандартный процессор назначения v2 (StorageV2)1
Наследство Общего назначения версии 1 стандартной категории (Storage)

Устаревший объект типа BLOB (BlobStorage)
Н/П Общего назначения версии 1 стандартной категории (Storage)

Устаревший объект типа BLOB (BlobStorage)
Н/П

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

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

Данные во всех уровнях, включая архивный уровень, всегда копируются из первичного в вторичный во время георепликации. Архивный уровень хранения BLOB-объектов в настоящее время поддерживается для аккаунтов LRS, GRS и RA-GRS, но не для аккаунтов ZRS, GZRS или RA-GZRS. Дополнительные сведения о уровнях BLOB-объектов см. в разделе "Уровни доступа" для данных BLOB-объектов.

Неуправляемые диски не поддерживают ZRS и GZRS.

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

Примечание.

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

Целостность данных

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

См. также