Надежность в пакетная служба Azure
В этой статье описывается поддержка надежности в пакетная служба Azure и охватывает как внутрирегиональная устойчивость с зонами доступности, так и ссылки на информацию о восстановлении между регионами и непрерывности бизнес-процессов.
Поддержка зоны доступности
Зоны доступности Azure — это по крайней мере три физически отдельные группы центров обработки данных в каждом регионе Azure. Центры обработки данных в каждой зоне оснащены независимой питанием, охлаждения и сетевой инфраструктурой. В случае сбоя локальной зоны зоны зоны создаются таким образом, чтобы при возникновении влияния одной зоны, региональных служб, емкости и высокой доступности поддерживались остальными двумя зонами.
Сбои могут варьироваться от сбоев программного обеспечения и оборудования до таких событий, как землетрясения, наводнения и пожары. Устойчивость к сбоям достигается с избыточностью и логической изоляцией служб Azure. Дополнительные сведения о зонах доступности в Azure см. в разделе "Регионы и зоны доступности".
Службы с поддержкой зон доступности Azure предназначены для обеспечения правильного уровня надежности и гибкости. Их можно настроить двумя способами. Они могут быть избыточными по зонам с автоматическим реплика tion между зонами или зональными экземплярами, закрепленными в определенной зоне. Эти подходы также можно объединить. Дополнительные сведения об зональной архитектуре, избыточной между зонами, см. в Рекомендации использования зональных зон и регионов.
Пакетная служба поддерживает паритетность с Azure при поддержке зон доступности.
Необходимые компоненты
Для учетных записей пакетной службы в режиме пользовательской подписки проверьте, что в подписке, в которой создается пул, не предусмотрено ограничение на использование зоны для запрещенного номера SKU виртуальной машины. Чтобы узнать, не имеет ли подписка никаких ограничений, вызовите API списка resource Skus и проверка
ResourceSkuRestrictions. Если ограничение для зоны существует, вы можете отправить запрос в службу поддержки, чтобы удалить ограничение зоны.Так как InfiniBand не поддерживает взаимодействие между зонами, невозможно создать пул с зональной политикой, если она включена связь между узлами и использует номер SKU виртуальной машины, поддерживающий InfiniBand.
Пакетная служба поддерживает паритетность с Azure при поддержке зон доступности. Чтобы использовать зональный параметр, пул должен быть создан в регионе Azure с поддержкой зоны доступности.
Чтобы выделить пул пакетной службы в зонах доступности, регион Azure, в котором был создан пул, должен поддерживать запрошенный номер SKU виртуальной машины в нескольких зонах. Чтобы проверить, поддерживает ли регион запрошенный номер SKU виртуальной машины в нескольких зонах, вызовите API списка Resource Skus и проверка
locationInfoполеresourceSku. Убедитесь, что для запрошенного номера SKU виртуальной машины поддерживается несколько зон. Вы также можете использовать Azure CLI для перечисления всех доступных номеров SKU ресурсов с помощью следующей команды:az vm list-skus
Создание пула пакетная служба Azure в зонах доступности
Примеры создания пула пакетной службы в зонах доступности см. в статье "Создание пула пакетная служба Azure в зонах доступности".
Дополнительные сведения см. в статьях Создание учетной записи пакетной службы на портале Azure, Примеры использования Azure CLI для пакетной службы Azure, Управление ресурсами пакетной службы с помощью командлетов PowerShell или Управление учетными записями и квотами пакетной службы с помощью клиентской библиотеки .NET для управления пакетной службой.
Взаимодействие с зонами вниз
Во время простоя зоны узлы в этой зоне становятся недоступными. Все узлы в том же пуле узлов из других зон не влияют и продолжают быть доступны.
пакетная служба Azure учетная запись не перераспределять или создавать новые узлы для компенсации узлов, которые снизились из-за сбоя. Пользователям необходимо добавить дополнительные узлы в пул узлов, которые затем выделяются из других здоровых зон.
Отказоустойчивость
Чтобы подготовиться к возможному сбою зоны доступности, необходимо переоформить емкость службы, чтобы обеспечить, чтобы решение 1/3 не терял пропускную способность и продолжает функционировать без снижения производительности во время сбоев на уровне зоны. Так как платформа распределяет виртуальные машины в трех зонах и необходимо учитывать сбой по крайней мере одной зоны, умножьте число экземпляров рабочей нагрузки на коэффициент зон/(зоны–1) или 3/2. Например, если типичная пиковая рабочая нагрузка требует наличия четырех экземпляров, следует подготовить шесть экземпляров: (2/3 * 6 экземпляров) = 4 экземпляра.
Миграция зоны доступности
Невозможно перенести существующий пул пакетной службы в поддержку зоны доступности. Если вы хотите повторно создать пул пакетной службы в зонах доступности, см. статью "Создание пула пакетная служба Azure в зонах доступности".
Аварийное восстановление между регионами и непрерывность бизнес-процессов
пакетная служба Azure доступна во всех регионах Azure. Однако при создании учетной записи пакетной службы она должна быть связана с одним конкретным регионом. Все последующие операции для этой учетной записи пакетной службы применяются только к тому региону. Например, пулы и связанные виртуальные машины создаются в том же регионе, что и учетная запись пакетной службы.
При разработке приложения, использующего пакетную службу, необходимо учитывать возможность того, что пакетная служба может быть недоступна в регионе. Можно столкнуться с редкой ситуацией, когда возникает проблема с регионом в целом, всей пакетной службой в регионе или конкретной учетной записью пакетной службы.
Если приложение или решение, использующее пакетную службу, всегда должно быть доступно, оно должно быть разработано для отработки отказа в другой регион или всегда разделить рабочую нагрузку между двумя или более регионами. Для обоих подходов требуется как минимум две учетные записи пакетной службы, причем каждая учетная запись расположена в своем регионе.
Вы несете ответственность за настройку аварийного восстановления между регионами с помощью пакетная служба Azure. Если вы запускаете несколько учетных записей пакетной службы в определенных регионах и используете преимущества зон доступности, приложение может соответствовать целям аварийного восстановления, когда одна из учетных записей пакетной службы становится недоступной.
При предоставлении возможности отработки отказа в альтернативный регион необходимо учитывать все компоненты в решении; Недостаточно просто иметь вторую учетную запись пакетной службы. Например, в большинстве пакетных приложений требуется учетная запись хранения Azure. Учетная запись хранения и учетная запись пакетной службы должны находиться в одном регионе для приемлемой производительности.
При разработке решения, способного обеспечить отработку отказа, необходимо учитывать следующее.
Предустановите все необходимые службы в каждом регионе, например учетную запись пакетной службы и учетную запись хранения. Часто плата за создание учетных записей не взимается, а плата взимается только при использовании учетной записи или при хранении данных.
Убедитесь, что соответствующие квоты устанавливаются для всех учетных записей пакетной службы подписки пользователя, чтобы выделить необходимое количество ядер с помощью учетной записи пакетной службы.
Используйте шаблоны и (или) сценарии для автоматизации развертывания приложения в регионе.
Постоянно обновляйте двоичные файлы приложения и эталонные данные во всех регионах. Оставаясь в курсе, регион может быть быстро доставлен в интернет, не ожидая отправки и развертывания файлов. Например, рассмотрим ситуацию, когда настраиваемое приложение для установки на узлах пула хранится и ссылается на нее с помощью пакетов приложений пакетной службы. При выпуске обновления приложения его следует отправить в каждую учетную запись пакетной службы и ссылаться на конфигурацию пула (или сделать последнюю версию версией по умолчанию).
В приложении, вызывающем пакетные службы, хранилище и любых других службах можно легко переключать клиентов или нагрузку на другой регион.
В ходе работы рекомендуется часто переключаться между регионами. Например, если вы используете два развертывания в отдельных регионах, переключайтесь на другой регион каждый месяц.
Длительность восстановления после аварии зависит от выбранной настройки. Сама пакетная служба не зависит от того, используете ли вы несколько учетных записей или одну учетную запись. В конфигурациях active-active, где два экземпляра пакетной службы одновременно получают трафик, аварийное восстановление быстрее, чем для конфигурации с активным пассивным доступом. Какая конфигурация должна быть основана на бизнес-потребностях (различных регионах, требованиях к задержкам) и технических рекомендациях.
Аварийное восстановление в одном регионе
Реализация аварийного восстановления в пакетной службе совпадает с тем, работаете ли вы в одном регионе или в нескольких регионах. Единственное различие заключается в том, какой номер SKU вы используете для хранения и планируете ли вы использовать одну или другую учетную запись хранения во всех регионах.
Тестирование аварийного восстановления
Необходимо выполнить собственное тестирование аварийного восстановления решения с поддержкой пакетной службы. Рекомендуется легко переключаться между клиентом и обслуживанием в разных регионах.
Тестирование плана аварийного восстановления для пакетной службы может быть таким же простым, как чередование учетных записей пакетной службы. Например, можно использовать одну учетную запись пакетной службы в определенном регионе в течение одного рабочего дня. Затем на следующий день можно перейти на вторую учетную запись пакетной службы в другом регионе. Аварийное восстановление в основном управляется на стороне клиента. Этот подход с несколькими учетными записями для аварийного восстановления отвечает ожиданиям RTO и RPO в одном регионе или в нескольких регионах.
Устойчивость емкости и упреждающего аварийного восстановления
Корпорация Майкрософт и ее клиенты работают в рамках модели общей ответственности. Корпорация Майкрософт отвечает за устойчивость платформы и инфраструктуры. Вы несете ответственность за устранение аварийного восстановления для любой конкретной службы, развернутой и управляемой. Чтобы убедиться, что восстановление упреждающее:
Всегда следует предопределить вторичники. Предопределение вторичных файлов необходимо, так как во время воздействия на тех, кто не предраспределил такие ресурсы, не гарантируется.
Предустановите все необходимые службы в каждом регионе, например учетные записи пакетной службы и связанные учетные записи хранения. Плата за создание новых учетных записей не взимается; плата взимается только в том случае, если используется учетная запись или когда данные хранятся.
Убедитесь, что соответствующие квоты устанавливаются во всех подписках заранее, поэтому вы можете выделить необходимое количество ядер с помощью учетной записи пакетной службы. Как и в других службах Azure, существуют ограничения на некоторые ресурсы, связанные с пакетной службой. Многие из этих ограничений являются квотами по умолчанию, которые Azure применяет на уровне подписки или учетной записи. Помните об этих квотах при разработке и увеличении масштаба рабочих нагрузок пакетной службы.
Примечание.
Если планируется выполнять рабочие нагрузки в производственной среде с использованием пакетной службы, имеет смысл увеличить одну или несколько квот по сравнению со значениями по умолчанию. Чтобы увеличить квоту, вы можете запросить увеличение квоты бесплатно. Дополнительные сведения см. в статье "Запрос увеличения квоты".
Хранилище
Необходимо настроить пакетное хранилище, чтобы обеспечить резервное копирование данных между регионами; ответственность клиента — это по умолчанию. В большинстве решений пакетной службы для хранения файлов ресурсов и выходных файлов используется служба хранилища Azure. Например, в задачах пакетной службы (включая стандартные задачи, задачи запуска, задачи подготовки и прекращения заданий) обычно указываются файлы ресурсов, которые находятся в учетных записях хранения. служба хранилища учетные записи также хранят обработанные данные и все созданные выходные данные. Понимание возможной потери данных в регионах операций службы является важным фактором. Кроме того, необходимо убедиться, что данные можно перезаписать или только для чтения.
Пакет поддерживает следующие типы учетной записи хранения Azure:
- Учетные записи Общего назначения версии 2 (GPv2)
- Учетные записи Общего назначения версии 1 (GPv1)
- учетные записи хранения больших двоичных объектов (сейчас поддерживаются для пулов в конфигурации виртуальной машины).
Дополнительные сведения об учетных записях хранения см. в статье Общие сведения об учетной записи хранения.
Вы можете связать учетную запись хранения с учетной записью пакетной службы при создании учетной записи или выполнить этот шаг позже.
Если вы настраиваете отдельную учетную запись хранения для каждого региона, в которую доступна служба, необходимо использовать учетные записи, избыточные между зонами (ZRS). Используйте учетные записи геоизбыточного хранилища (GZRS), если вы используете одну и ту же учетную запись хранения в нескольких парных регионах. Для географических регионов, содержащих один регион, необходимо создать учетную запись хранилища, избыточного между зонами (ZRS), так как GZRS недоступна.
Планирование емкости является еще одним важным аспектом с хранилищем и должно быть упреждающее решение. При выборе учетной записи хранения учитывайте требования к расходам и производительности. Например, параметры учетной записи хранения GPv2 и учетной записи хранения больших двоичных объектов поддерживают большие пороговые значения производительности и масштабируемости по сравнению с GPv1. (Обратитесь в службу поддержки Azure, чтобы запросить увеличение ограничения хранилища.) Эти параметры учетной записи могут повысить производительность решений пакетной службы, содержащих большое количество параллельных задач, которые считываются или записываются в учетную запись хранения.
Если учетная запись хранения связана с учетной записью пакетной службы, она считается учетной записью автоматической записи. Учетная запись автосбора требуется, если планируется использовать возможности пакетов приложений, так как она используется для хранения файлов пакета приложения .zip. Учетная запись автосбора также может использоваться для файлов ресурсов задач. Так как учетная запись автосбора уже связана с учетной записью пакетной службы, это позволяет избежать необходимости в URL-адресах подписанных URL-адресов (SAS) для доступа к файлам ресурсов.