Надежность в службе пакетной обработки Azure

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

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

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

Дополнительные сведения о зонах доступности в Azure см. в статье "Что такое зоны доступности?"

Служба Batch поддерживает равенство с Azure в поддержке зон доступности.

Предварительные условия

• Для учетных записей Batch в режиме пользовательской подписки убедитесь, что в подписке, в которой создается пул, нет ограничений на предложение зоны относительно запрашиваемой конфигурации VM SKU. Чтобы проверить, нет ли у вашей подписки никаких ограничений, вызовите API списка Resource Skus и проверьте ResourceSkuRestrictions. Если ограничение для зоны существует, вы можете отправить запрос в службу поддержки, чтобы удалить ограничение зоны.

• Так как InfiniBand не поддерживает взаимодействие между зонами, невозможно создать пул с зональной политикой, если она включена связь между узлами и использует номер SKU виртуальной машины, поддерживающий InfiniBand.

• Пакетный сервис поддерживает паритет с Azure в плане поддержки зон доступности. Чтобы использовать зональную опцию, пул должен быть создан в регионе Azure с поддержкой зоны доступности.

• Чтобы распределить пул Batch по зонам доступности, регион Azure, в котором был создан пул, должен поддерживать запрашиваемый номер SKU виртуальной машины в более чем одной зоне. Чтобы проверить, поддерживает ли регион запрошенный SKU виртуальной машины в нескольких зонах, вызовите API списка Resource SKUs и проверьте locationInfo поле resourceSku. Убедитесь, что для запрошенного SKU виртуальной машины поддерживаются более одной зоны. Вы также можете использовать Azure CLI для перечисления всех доступных номеров SKU ресурсов с помощью следующей команды:

  
      az vm list-skus
  
  

Создание пула Azure Batch в зонах доступности

Примеры создания пула Azure Batch в зонах доступности см. в статье "Создание пула Azure Batch в зонах доступности".

Узнайте больше о создании учетных записей Batch с помощью портала Azure, Azure CLI, PowerShell или Batch management API.

Опыт расслабления в зоне

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

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

Отказоустойчивость

Чтобы подготовиться к возможному сбою зоны доступности, необходимо перепроектировать емкость службы, чтобы обеспечить возможность решения выдерживать потерю 1/3 емкости и продолжать функционировать без ухудшения производительности во время сбоев на уровне зоны. Поскольку платформа распределяет виртуальные машины по трём зонам, и нужно учитывать сбой по крайней мере одной зоны, умножьте число экземпляров нагрузки на пиковой мощности на коэффициент зон/(зоны–1) или 3/2. Например, если типичная пиковая рабочая нагрузка требует наличия четырех экземпляров, следует подготовить шесть экземпляров: (2/3 * 6 экземпляров) = 4 экземпляра.

Миграция зоны доступности

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

Аварийное восстановление между регионами и непрерывность бизнес-процессов

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

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

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

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

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

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

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

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

• Используйте шаблоны и (или) сценарии для автоматизации развертывания приложения в регионе.

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

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

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

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

Аварийное восстановление в одном регионе

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

Тестирование аварийного восстановления

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

Тестирование плана аварийного восстановления для Batch может быть таким же простым, как чередование учетных записей. Например, можно использовать один аккаунт Batch в определенном регионе на один рабочий день. Затем на следующий день можно переключиться на другую учетную запись Batch в другом регионе. Аварийное восстановление в основном управляется на стороне клиента. Этот подход с несколькими учетными записями для аварийного восстановления отвечает ожиданиям RTO и RPO в одном регионе или в нескольких регионах.

Надежность управления емкостью и проактивного аварийного восстановления

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

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

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

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

Хранилище

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

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

• Учетные записи Общего назначения версии 2 (GPv2)
• Учетные записи Общего назначения версии 1 (GPv1)
• учетные записи Blob-хранилища (сейчас поддерживаются для пулов в конфигурации виртуальной машины)

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

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

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

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

Если учетная запись хранения связана с учетной записью пакетной обработки, ее можно считать автохранением. Учетная запись автосохранения требуется, если вы планируете использовать функцию пакетов приложений, поскольку она используется для хранения файлов пакета приложения .zip. Учетная запись автохранилища также может использоваться для файлов ресурсов задач. Так как учетная запись автохранилища уже связана с учетной записью пакетной службы, это позволяет избежать необходимости в (SAS) URL для доступа к файлам ресурсов.

Следующие шаги

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