Рекомендации по развертыванию крупных узлов Azure с пакетом Microsoft HPC

Начиная с пакета HPC 2008 R2 с пакетом обновления 1 администраторы кластера Windows HPC и разработчики могут увеличить мощность локального кластера, добавив вычислительные ресурсы по запросу в Azure. Этот сценарий кластера HPC "ускорение" с экземплярами рабочей роли Azure обеспечивает более крупные рабочие нагрузки HPC, иногда требуя тысячи ядер в дополнение к локальным ресурсам кластера или вместо нее. В этом разделе приведены рекомендации и рекомендации по планированию и реализации большого развертывания узлов Azure из локального кластера пакета HPC. Эти рекомендации помогут свести к минимуму время ожидания развертывания Azure, сбои развертывания и потерю динамических экземпляров.

Замечание

• Эти рекомендации включают рекомендации как для среды Azure, так и для конфигурации локального головного узла. Большинство рекомендаций также улучшит поведение небольших развертываний узлов Azure. Исключениями из этих рекомендаций являются тестовые развертывания, на которых производительность и надежность служб головного узла могут не быть критически важными и очень небольшими развертываниями, в которых службы головного узла не будут сильно подчеркнуты.
• Многие из рекомендаций по настройке локального головного узла для большого развертывания Azure также применяются к кластерам, которые содержат сравнительно большое количество локальных вычислительных узлов.
• Эти рекомендации дополняют кластер, сеть и другие требования для добавления узлов Azure в кластер Windows HPC. Дополнительные сведения см. в разделе "Требования к узлам Azure".
• Эти общие рекомендации могут меняться со временем и могут быть скорректированы для рабочих нагрузок HPC.

Применимые версии пакета HPC и azure SDK для .NET

Эти рекомендации обычно основаны на пакете HPC 2012 R2 и пакете HPC 2012, но они также полезны для крупных развертываний, выполняемых с пакетом HPC 2008 R2.

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

Пакет HPC	Azure SDK
Пакет HPC 2012 R2	Пакет SDK Azure для .NET 2.2
Пакет HPC 2012 с пакетом обновления 1 (SP1)	Пакет SDK Azure для .NET 2.0
Пакет HPC 2012	Пакет SDK Azure для .NET 1.8
Пакет HPC 2008 R2 с пакетом обновления 4 (SP4)	Пакет SDK Azure для .NET 1.7
Пакет HPC 2008 R2 с пакетом обновления 3 (SP3)	Пакет SDK Azure для .NET 1.6

Пороговые значения для крупных развертываний узлов Azure

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

Это важно

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

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

Размер экземпляра роли	Количество экземпляров ролей
A9 (поддерживается начиная с пакета HPC 2012 R2)	125
A8 (поддерживается начиная с пакета HPC 2012 R2)	250
A7 (поддерживается начиная с пакета HPC 2012 с пакетом обновления 1 (SP1)	250
A6 (поддерживается начиная с пакета HPC 2012 с пакетом обновления 1 (SP1)	250
Дополнительное большое	250
Крупный	500
Средний	800
Небольшой	1000

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

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

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

Рекомендации по использованию Azure для крупных развертываний

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

Предоставление ранних сигналов группе операций Azure

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

Распространение развертываний в нескольких облачных службах

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

• Чтобы обеспечить гибкость при запуске и остановке групп узлов.

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

• Чтобы упростить поиск доступных узлов в кластерах Azure, особенно при использовании дополнительных крупных экземпляров.

• Чтобы включить использование нескольких центров обработки данных Azure для сценариев аварийного восстановления или непрерывности бизнес-процессов.

Нет фиксированного ограничения на размер облачной службы, но общее руководство составляет менее 500 до 700 экземпляров виртуальных машин или менее 1000 ядер. Более крупные развертывания рискуют временем ожидания развертывания, потерей динамических экземпляров и проблемами с переключением виртуальных IP-адресов.

Максимальное протестированное количество облачных служб для одного кластера HPC составляет 32.

Замечание

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

Гибкость с расположением

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

Гибкость с размером виртуальной машины

Наличие строгих зависимостей от определенного размера виртуальной машины (например, "Большое") может повлиять на успех развертываний в большом масштабе. Гибкость в настройке или даже сопоставлении размеров виртуальных машин с учетом количества экземпляров и ядер может помочь.

Использование нескольких учетных записей хранения Azure для развертываний узлов

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

Замечание

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

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

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

Замечание

• Экземпляры роли прокси-сервера несут расходы в Azure вместе с экземплярами узлов Azure.
• Экземпляры роли прокси-сервера используют ядра, выделенные для подписки, и сокращают количество ядер, доступных для развертывания узлов Azure.

Пакет HPC 2012 представил средства управления HPC для настройки количества прокси-узлов в каждом развертывании узлов Azure (облачная служба). (В пакете HPC 2008 R2 число автоматически устанавливается на 2 прокси-узла для каждого развертывания.) Число экземпляров ролей для прокси-узлов также можно увеличить или уменьшить с помощью средств на портале управления Azure без повторного развертывания узлов. Рекомендуемое максимальное количество прокси-узлов для одного развертывания — 10.

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

Узлы Azure для каждой облачной службы	Количество узлов прокси-сервера
<100	2
100 - 400	3
400 - 800	4
800 - 1000	5

Дополнительные сведения о параметрах конфигурации прокси-узла см. в разделе "Настройка числа узлов прокси-сервера Azure".

Рекомендации по настройке головного узла для крупных развертываний

Крупные развертывания узлов Azure могут поставить значительные требования к головному узлу (или головному узлу) кластера. Головной узел выполняет несколько задач для поддержки развертывания:

• Обращается к экземплярам прокси-узла, созданным в развертывании Azure для упрощения взаимодействия с узлами Azure (см. раздел "Настройка количества экземпляров прокси-узла для поддержки развертывания" в этом разделе).

• Обращается к учетным записям хранения Azure для больших двоичных объектов (таких как пакеты среды выполнения), очереди и табличные данные.

• Управляет интервалом пульса и ответами, числом прокси-серверов (начиная с пакета HPC 2012), числом развертываний и количеством узлов.

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

• Достаточно ОЗУ

• Достаточно места на диске

• Соответствующая размер хорошо поддерживаемая база данных SQL Server для баз данных кластера HPC

Спецификации оборудования головного узла

Ниже приведены минимальные спецификации головного узла для поддержки большого развертывания Azure:

• 8 ядер ЦП

• 2 диска

• 16 ГБ ОЗУ

Настройка удаленных баз данных SQL Server

Для крупных развертываний рекомендуется установить базы данных кластера на удаленном сервере под управлением Microsoft SQL Server, а не устанавливать базы данных кластера на головном узле. Общие рекомендации по выбору и настройке выпуска SQL Server для кластера см. в статье "Планирование емкости базы данных" и настройка пакета Microsoft HPC.

Не настраивайте головной узел для дополнительных ролей кластера

В качестве общей практики для большинства рабочих развертываний рекомендуется не настраивать головные узлы с дополнительной ролью кластера (роль вычислительного узла или роль узла брокера WCF). Если головной узел обслуживает несколько целей, он может предотвратить успешное выполнение основной роли управления. Чтобы изменить роли, выполняемые головным узлом, сначала переключите узел в автономном режиме с помощью действия управления ресурсами (называемого управлением узлами в некоторых версиях пакета HPC) в диспетчере кластеров HPC. Затем щелкните правой кнопкой мыши головной узел и нажмите кнопку "Изменить роль".

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

Использование клиентских программ HPC для удаленного подключения к головному узлу

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

Отключение коллекции счетчиков производительности и пересылки событий

Для крупных развертываний сбор счетчиков производительности и перенаправление событий может поставить большую нагрузку на службу управления HPC и SQL Server. Для этих развертываний может потребоваться отключить эти возможности с помощью средств управления кластерами HPC. Например, задайте для свойства кластера CollectCounters значение false с помощью командлета Set-HpcClusterProperty HPC PowerShell. Возможны компромиссы между улучшенной производительностью и сбором метрик, которые могут помочь вам устранить возникающие проблемы.

Отключение ненужных служб головного узла

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

Не запускайте NAT на головном узле

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

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

• Предоставьте выделенный маршрутизатор NAT, например отдельный сервер под управлением операционной системы Windows Server, который находится в двух сетях и работает RRAS.

Обеспечение разумного периода хранения для завершенных заданий

Свойство TtlCompletedJobs команды cluscfg и командлета Set-HpcClusterProperty HPC определяет, как долго завершенные задания остаются в базе данных SQL Server для кластера HPC. Установка большого значения для этого свойства гарантирует, что сведения о задании хранятся в системе в течение длительного времени, что может быть желательно для создания отчетов. Однако большое количество заданий в системе увеличит требования к хранилищу и памяти системы, так как база данных (и запросы к ней) обычно будут больше.

Настройте разумное число пропущенных пульсов перед маркировкой узлов, недоступных

Пакет HPC использует сигнал пульса для проверки доступности узлов. Отсутствие ответа вычислительного узла на этот периодический зонд работоспособности службой планировщика заданий HPC определяет, будет ли узел помечен как недоступный. При настройке параметров пульса в конфигурации планировщика заданий в диспетчере кластеров HPC или с помощью команды cluscfg или командлета Set-HpcClusterProperty HPC администратор кластера может задать частоту пульса (HeartbeatInterval) и количество пульсов, которые узел может пропустить (InactivityCount), прежде чем он помечается как недоступный. Например, по умолчанию HeartbeatInterval 30 секунд может быть увеличен до 2 минут, когда кластер включает большое развертывание Azure. Значение InactivityCount по умолчанию имеет значение 3, которое подходит для некоторых локальных развертываний, но при развертывании узлов Azure оно должно быть увеличено до 10 или более.

Замечание

Начиная с пакета HPC 2012 с пакетом обновления 1 (SP1) количество пропущенных пульсов настраивается отдельно для локальных узлов и узлов Azure. Свойство кластера InactivityCountAzure настраивает количество пропущенных пульсов после того, как рабочие узлы, развернутые в Azure, считаются недоступными для кластера. Значение по умолчанию InactivityCountAzure имеет значение 10. Начиная с пакета HPC 2012 с пакетом обновления 1 (SP1) свойство InactivityCount применяется исключительно к локальным узлам.

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

Если на узлах Azure выполняются задания архитектуры, ориентированные на обслуживание (SOA), может потребоваться настроить параметры времени ожидания мониторинга в файле регистрации службы для управления большими сеансами. Дополнительные сведения о файле конфигурации службы SOA см. в разделе "Файлы конфигурации службы SOA" в Windows HPC Server 2008 R2.

Настройка раздела реестра для повышения производительности промежуточных операций с файлами

Начиная с пакета HPC 2008 R2 с пакетом обновления 2 (SP2) можно задать раздел реестра на головном компьютере, чтобы повысить производительность диагностических тестов, операций clusrun и служебной программы hpcfile в крупных развертываниях узлов Azure. Для этого добавьте новое значение DWORD с именем FileStagingMaxConcurrentCalls в HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\HPC. Рекомендуется настроить значение от 50% до 100% количества узлов Azure, которые планируется развернуть. Чтобы завершить настройку, после задания значения FileStagingMaxConcurrentCalls необходимо остановить и перезапустить службу планировщика заданий HPC.

Осторожность

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

См. также

Ускорение рабочих экземпляров Azure с помощью пакета Microsoft HPC
Рекомендации по проектированию служб Large-Scale в облачных службах Azure
Техническое руководство по непрерывности бизнес-процессов Windows Azure