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

Требования к добавлению узлов Azure с помощью пакета Microsoft HPC

В этом разделе описываются требования к добавлению узлов Azure в локальный кластер HPC.

Установка поддерживаемой версии пакета Microsoft HPC в кластере

Чтобы развернуть узлы Azure в кластере Windows HPC, необходимо запустить по крайней мере microsoft HPC Pack 2008 R2 с пакетом обновления 1 (SP1) или более поздней версией пакета HPC. Сведения о функциях Azure, поддерживаемых версией пакета HPC, работающего в кластере, см. в статье "Совместимость компонентов Azure с пакетом Microsoft HPC".

Инструкции по установке пакета HPC и пакетов обновления см. в следующих статье:

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

Компьютер головного узла (или компьютеры), на котором установлен пакет HPC, должен быть полностью настроен (т. е. все действия, необходимые в списке действий развертывания). Кластер HPC можно настроить в любой топологии сети кластера (1–5), поддерживаемой пакетом HPC. Головной узел должен иметь возможность подключаться через Интернет к службам Azure. В большинстве случаев это подключение к Интернету обеспечивается подключением головного узла к корпоративной сети. Возможно, вам потребуется обратиться к администратору сети, чтобы настроить это подключение.

Дополнительные сведения о топологиях сети кластера, поддерживаемых пакетом HPC, см. в разделе "Настройка сети кластера HPC".

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

Это важно

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

  • Содержит только буквенно-цифровые символы
  • Не начинается с числового символа

Настройка сетевого брандмауэра

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

Замечание

По умолчанию служба планировщика заданий HPC на головном узле взаимодействует с прокси-узлами в Azure по протоколу Net.TCP через порт 443. Однако в некоторых корпоративных сетях net.TCP через порт 443 запрещено, что позволит предотвратить обмен данными с развертываниями узлов Azure. Если вы используете по крайней мере пакет HPC 2012, вы можете настроить службу планировщика заданий HPC для обмена данными по протоколу HTTPS через порт 443, который обычно разрешен в корпоративной сети. Для этого выполните следующий командлет HPC PowerShell, чтобы изменить значение свойства кластера NettcpOver443 :

Set-HpcClusterProperty -NettcpOver443:$false

Дополнительные сведения см. в разделе Set-HpcClusterProperty.

Помните, что обмен данными HTTPS будет медленнее, чем связь Net.TCP и может повлиять на производительность кластера.

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

Расширенная конфигурация брандмауэра и прокси-клиента (необязательно)

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

Чтобы развернуть и использовать узлы Azure, следующие службы, которые выполняются под системной учетной записью на головном узле пакета HPC, должны иметь возможность взаимодействовать через Интернет со службами для Azure:

  • HPCManagement

  • HPCScheduler

  • HPCBrokerWorker

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

Это важно

  • Обратитесь к администратору сети и поставщику прокси-сервера или сетевого брандмауэра, чтобы узнать, будет ли прокси-сервер или сетевой брандмауэр в корпоративной сети блокировать трафик для hpCManagement, HPCScheduler и служб HPCBrokerWorker для пакета HPC. Если требуется дополнительная конфигурация, определенные действия по настройке будут зависеть от таких факторов, как определенные политики сети и безопасности, прокси-сервер или сетевой брандмауэр, а также от того, какой тип клиентского программного обеспечения брандмауэра выполняется на головном узле.
  • Тест портов брандмауэра Azure может помочь обнаружить эту проблему. Если все порты брандмауэра, необходимые для обмена данными между пакетом HPC и Azure, открыты, но тест диагностики завершается сбоем, это может указать проблему с конфигурацией прокси-сервера или сетевого брандмауэра.

Параметры прокси-сервера можно настроить для этих служб, добавив элемент в <defaultProxy> файл конфигурации приложения (*.exe.config).

  • C:\Program Files\Microsoft HPC Pack 2019\Bin\HpcManagement.exe.config
  • C:\Program Files\Microsoft HPC Pack 2019\Bin\HpcScheduler.exe.config
  • C:\Program Files\Microsoft HPC Pack 2019\Bin\HpcBrokerWorker.exe.config

Чтобы применить измененную конфигурацию, перезапустите службы.

Restart-Service -Name HpcManagement
Restart-Service -Name HpcScheduler
Restart-Service -Name HpcBroker

Если головной узел выполняется на виртуальной машине Azure, необходимо обойти IP-адрес службы метаданных экземпляра Azure (169.254.169.254) с помощью <bypasslist> элемента.

Получение учетной записи подписки Azure

Необходимо получить или получить доступ к учетной записи подписки Azure. Как минимум, облачная служба Azure, учетная запись хранения Azure и сертификат управления должны быть настроены для поддержки развертывания узлов Azure. В зависимости от версии пакета HPC, установленного в кластере и условий подписки, вы можете настроить или использовать другие функции Или службы Azure из подписки в развертывании. Дополнительные сведения см. в статье о совместимости компонентов Azure с пакетом Microsoft HPC.

  • Чтобы создать подписку Azure, перейдите на сайт Azure .

  • Чтобы получить доступ к существующей подписке, перейдите на портал Azure.

  • Общие сведения о подписке, необходимой для настройки шаблона узла Azure, см. в статье Общие сведения о подписке Azure для пакета Microsoft HPC.

Замечание

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

Сертификат управления Azure

Прежде чем развернуть узлы Azure в кластере Windows HPC, необходимо отправить сертификат управления в подписку Azure. Соответствующий сертификат необходимо настроить на головном узле (или на компьютерах головного узла, если головной узел настроен на высокий уровень доступности). Для некоторых сценариев с некоторыми версиями пакета HPC сертификат также должен быть настроен на клиентском компьютере, который используется для управления кластером и требует подключения к Azure. Сертификат управления должен быть допустимым сертификатом X.509 версии 3 с размером ключа не менее 2048 бит и требуется для проверки подлинности доступа из кластера HPC к ресурсам в подписке Azure.

Замечание

Один и тот же сертификат управления можно использовать для нескольких развертываний узлов Azure из подписки.

Если у вас еще нет сертификата управления, настроенного в подписке Azure, у вас есть следующие параметры:

  • В версиях пакета HPC до пакета HPC 2016 используйте сертификат управления Microsoft HPC Azure по умолчанию , который создается автоматически на головном узле при установке пакета HPC. Этот сертификат самозаверяющий и уникальный для установки пакета HPC на головном узле. Этот сертификат предназначен только для тестирования и развертывания проверки концепции. Этот файл сертификата расположен в следующем расположении на головном компьютере узла: %CCP_HOME%\bin\hpccert.cer.

  • Получение сертификата из общедоступного или корпоративного центра сертификации.

  • Создайте самозаверяющий сертификат X.509 версии 3. Общие сведения о сертификатах для облачных служб Azure.

  • Повторно используйте существующий сертификат, настроенный в подписке Azure.

Если вы получаете или используете новый сертификат управления или сертификат управления Microsoft HPC Azure по умолчанию , отправьте .cer файл в подписку Azure с помощью портала Azure.

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

Облачная служба Azure и учетная запись хранения

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

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

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

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

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

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

Рекомендации по ценам

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

  • Каждый раз, когда вы запускаете (подготавливаете) набор узлов Azure с помощью пакета HPC, дополнительные экземпляры прокси-роли автоматически настраиваются в Azure для упрощения взаимодействия между головным узлом и узлами Azure. В зависимости от версии пакета HPC это число либо исправлено (2 прокси-узла для каждого развертывания с пакетом HPC 2008 R2) или настраивается (начиная с пакета HPC 2012). Экземпляры прокси-роли несут плату в Azure вместе с экземплярами узлов Azure, а также используют ядра, выделенные для подписки (и, таким образом, сокращают количество ядер, доступных для развертывания узлов Azure). Дополнительные сведения см. в разделе "Количество узлов прокси-сервера Azure".

См. также

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

  • Last updated on