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

Создание и подготовка кластера с помощью Azure CLI

  • Статья

В этой статье описывается, как создать кластер с помощью интерфейса командной строки Azure (AzCLI). В этом документе также показано, как проверить состояние, обновить или удалить кластер.

Необходимые компоненты

  • Убедитесь, что в регионе Azure существует контроллер Network Fabric и кластерный manger
  • Убедитесь, что Network Fabric успешно подготовлена

Руководство по API и метрики

Руководство по API содержит сведения о поставщиках ресурсов и моделях ресурсов и API.

Метрики, созданные из данных ведения журнала, доступны в метриках Azure Monitor.

Ограничения

  • Именование — правила именования можно найти здесь.

Создание кластера

Ресурс кластера инфраструктуры представляет локальное развертывание платформы в диспетчере кластеров. Все остальные ресурсы, относящиеся к платформе, зависят от него в течение своего жизненного цикла.

Перед развертыванием в локальной среде необходимо создать Network Fabric. Каждый локальный экземпляр Оператора Nexus имеет связь "один к одному" с Network Fabric.

Создайте кластер с помощью Azure CLI:

az networkcloud cluster create --name "$CLUSTER_NAME" --location "$LOCATION" \
  --extended-location name="$CL_NAME" type="CustomLocation" \
  --resource-group "$CLUSTER_RG" \
  --analytics-workspace-id "$LAW_ID" \
  --cluster-location "$CLUSTER_LOCATION" \
  --network-rack-id "$AGGR_RACK_RESOURCE_ID" \
  --rack-sku-id "$AGGR_RACK_SKU"\
  --rack-serial-number "$AGGR_RACK_SN" \
  --rack-location "$AGGR_RACK_LOCATION" \
  --bare-metal-machine-configuration-data "["$AGGR_RACK_BMM"]" \
  --storage-appliance-configuration-data '[{"adminCredentials":{"password":"$SA_PASS","username":"$SA_USER"},"rackSlot":1,"serialNumber":"$SA_SN","storageApplianceName":"$SA_NAME"}]' \
  --compute-rack-definitions '[{"networkRackId": "$COMPX_RACK_RESOURCE_ID", "rackSkuId": "$COMPX_RACK_SKU", "rackSerialNumber": "$COMPX_RACK_SN", "rackLocation": "$COMPX_RACK_LOCATION", "storageApplianceConfigurationData": [], "bareMetalMachineConfigurationData":[{"bmcCredentials": {"password":"$COMPX_SVRY_BMC_PASS", "username":"$COMPX_SVRY_BMC_USER"}, "bmcMacAddress":"$COMPX_SVRY_BMC_MAC", "bootMacAddress":"$COMPX_SVRY_BOOT_MAC", "machineDetails":"$COMPX_SVRY_SERVER_DETAILS", "machineName":"$COMPX_SVRY_SERVER_NAME"}]}]'\
  --managed-resource-group-configuration name="$MRG_NAME" location="$MRG_LOCATION" \
  --network fabric-id "$NF_ID" \
  --cluster-service-principal application-id="$SP_APP_ID" \
    password="$SP_PASS" principal-id="$SP_ID" tenant-id="$TENANT_ID" \
  --subscription "$SUBSCRIPTION_ID" \
  --secret-archive "{key-vault-id:$KVRESOURCE_ID, use-key-vault:true}" \
  --cluster-type "$CLUSTER_TYPE" --cluster-version "$CLUSTER_VERSION" \
  --tags $TAG_KEY1="$TAG_VALUE1" $TAG_KEY2="$TAG_VALUE2"

Параметры для операций кластера

Наименование параметра Description
CLUSTER_NAME Имя ресурса кластера
LOCATION Регион Azure, в котором развернут кластер
CL_NAME Пользовательское расположение диспетчера кластеров из портал Azure
CLUSTER_RG Имя группы ресурсов кластера
LAW_ID Идентификатор рабочей области Log Analytics для кластера
CLUSTER_LOCATION Локальное имя кластера
AGGR_RACK_RESOURCE_ID RackID для агрегатной стойки
AGGR_RACK_SKU SKU стойки для агрегатной стойки *См . номера SKU оператора Nexus Network Cloud SKU
AGGR_RACK_SN Серийный номер стойки для агрегатной стойки
AGGR_RACK_LOCATION Физическое расположение стойки для агрегатной стойки
AGGR_RACK_BMM Используется только для развертывания одной стойки, пустой для нескольких стоек
SA_NAME Имя устройства хранилища
SA_PASS Пароль администратора устройства хранилища
SA_USER Пользователь администратора устройства хранилища
SA_SN Серийный номер устройства хранилища
COMPX_RACK_RESOURCE_ID RackID для стойки CompX; повторение для каждой стойки в определениях вычислительных стоек
COMPX_RACK_SKU Номер SKU стойки для стойки CompX; повторение для каждой стойки в определениях вычислительных стоек *См . номера SKU сетевых номеров SKU оператора Nexus Network
COMPX_RACK_SN Серийный номер стойки для стойки CompX; повторение для каждой стойки в определениях вычислительных стоек
COMPX_RACK_LOCATION Физическое расположение стойки для стойки CompX; повторение для каждой стойки в определениях вычислительных стоек
COMPX_SVRY_BMC_PASS Пароль контроллера управления базовой платой (BMC) CompX Rack Servery; повторяйте для каждой стойки в определениях вычислительных стоек и для каждого сервера в стойке
COMPX_SVRY_BMC_USER Пользователь BMC CompX Rack ServerY; повторяйте для каждой стойки в определениях вычислительных стоек и для каждого сервера в стойке
COMPX_SVRY_BMC_MAC Mac-адрес CompX RackY BMC; повторяйте для каждой стойки в определениях вычислительных стоек и для каждого сервера в стойке
COMPX_SVRY_BOOT_MAC Mac-адрес mac-карты сетевого интерфейса CompX Rack ServerY; повторяйте для каждой стойки в определениях вычислительных стоек и для каждого сервера в стойке
COMPX_SVRY_SERVER_DETAILS Сведения о серверной стойке CompX; повторяйте для каждой стойки в определениях вычислительных стоек и для каждого сервера в стойке
COMPX_SVRY_SERVER_NAME Имя сервера стоек CompX; повторяйте для каждой стойки в определениях вычислительных стоек и для каждого сервера в стойке
MRG_NAME Имя группы управляемых ресурсов кластера
MRG_LOCATION Регион Azure кластера
NF_ID Ссылка на Network Fabric
SP_APP_ID Идентификатор приложения субъекта-службы
SP_PASS Пароль субъекта-службы
SP_ID Идентификатор субъекта-службы
TENANT_ID Идентификатор клиента подписки
SUBSCRIPTION_ID ИД подписки
KV_RESOURCE_ID Идентификатор Key Vault
CLUSTER_TYPE Тип кластера, single или MultiRack
CLUSTER_VERSION Версия кластера network Cloud (NC)
TAG_KEY1 Необязательный тег1 для передачи в создание кластера
TAG_VALUE1 Необязательное значение тега1 для передачи в создание кластера
TAG_KEY2 Необязательный тег 2 для передачи в создание кластера
TAG_VALUE2 Необязательное значение тега 2 для передачи в создание кластера

Удостоверение кластера

Начиная с версии API 2024-07-01, клиент может назначить управляемое удостоверение кластеру. Поддерживаются управляемые удостоверения, назначенные системой и назначаемые пользователем.

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

  • --mi-system-assigned — включение управляемого удостоверения, назначаемого системой. После добавления удостоверение можно удалить только через вызов API в настоящее время.
  • --mi-user-assigned — идентификаторы ресурсов, разделенных пробелами, для добавленных управляемых удостоверений, назначенных пользователем. После добавления удостоверение можно удалить только через вызов API в настоящее время.

Создание кластера с помощью редактора шаблонов Azure Resource Manager

Альтернативным способом создания кластера является редактор шаблонов ARM.

Чтобы создать кластер таким образом, необходимо предоставить файл шаблона (cluster.jsonc) и файл параметров (cluster.parameters.jsonc). Примеры для кластера SKU с 8-стойкой 2M16C можно найти с помощью этих двух файлов:

cluster.jsonc , cluster.parameters.jsonc

Примечание.

Чтобы получить правильное форматирование, скопируйте необработанный файл кода. Значения в файле cluster.parameters.jsonc зависят от клиента и не могут быть полным списком. Обновите поля значений для конкретной среды.

  1. Перейдите к портал Azure в веб-браузере и войдите в систему.
  2. Найдите "Развернуть пользовательский шаблон" в строке поиска портал Azure и выберите его из доступных служб.
  3. Щелкните "Создать собственный шаблон" в редакторе.
  4. Щелкните "Загрузить файл". Найдите файл шаблона cluster.jsonc и отправьте его.
  5. Нажмите кнопку Сохранить.
  6. Нажмите кнопку "Изменить параметры".
  7. Нажмите кнопку "Загрузить файл". Найдите файл параметров cluster.parameters.jsonc и отправьте его.
  8. Нажмите кнопку Сохранить.
  9. Выберите правильную подписку.
  10. Найдите группу ресурсов, чтобы узнать, существует ли она. Если нет, создайте новую группу ресурсов.
  11. Убедитесь, что все сведения об экземпляре верны.
  12. Щелкните Просмотреть и создать.

Проверка кластера

Успешное создание кластера Nexus операторов приводит к созданию ресурса Azure в подписке. Идентификатор кластера, состояние подготовки кластера и состояние развертывания возвращаются в результате успешного выполнения cluster create.

Просмотрите состояние кластера:

az networkcloud cluster show --resource-group "$CLUSTER_RG" \
  --cluster-name "$CLUSTER_RESOURCE_NAME"

Создание кластера завершается после того, как provisioningState ресурс отображает: "provisioningState": "Succeeded"

Ведение журнала кластера

Журналы создания кластера можно просмотреть в следующих расположениях:

  1. портал Azure журналы действий Resource/ResourceGroup.
  2. Azure CLI с --debug флагом, переданным в командной строке.

Развертывание кластера

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

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

  1. Проверка свойств кластера или стойки.
  2. Создание загрузочного образа для эфемерного кластера начальной загрузки (проверка инфраструктуры).
  3. Взаимодействие с интерфейсом интеллектуального интерфейса управления платформой (IPMI) целевого компьютера начальной загрузки.
  4. Выполнение проверок оборудования.
  5. Мониторинг процесса развертывания кластера.

Разверните локальный кластер:

az networkcloud cluster deploy \
  --name "$CLUSTER_NAME" \
  --resource-group "$CLUSTER_RG" \
  --subscription "$SUBSCRIPTION_ID" \
  --no-wait --debug

Совет

Чтобы проверить состояние az networkcloud cluster deploy команды, ее можно выполнить с помощью флага --debug . Это позволит получить или Location заголовок, используемый Azure-AsyncOperation для запроса operationStatuses ресурса. Дополнительные сведения см. в разделе " Сбой развертывания кластера". При необходимости команда может выполняться асинхронно с помощью флага --no-wait .

Развертывание кластера с проверкой оборудования

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

Внимание

Процесс проверки оборудования записывает результаты в указанный analyticsWorkspaceId в разделе "Создание кластера". Кроме того, предоставленный субъект-служба в объекте кластера используется для проверки подлинности в API сбора данных рабочей области Log Analytics. Эта возможность отображается только во время нового развертывания (зеленое поле); существующий кластер не будет иметь журналы, доступные ретроактивно.

Примечание.

Контроллер RAID сбрасывается во время развертывания кластера, обтирая все данные с виртуальных дисков сервера. Любые оповещения контроллера управления базовыми дисками (BMC) обычно могут игнорироваться, если не существует дополнительных оповещений физических дисков и (или) контроллеров RAID.

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

В предоставленной рабочей области Log Analytics объекта кластера появится новая настраиваемая таблица с именем кластера в качестве префикса и суффикса *_CL . В разделе журналов ресурса LAW запрос можно выполнить в новой *_CL таблице настраиваемого журнала.

Развертывание кластера с пропуском конкретного компьютера без операционной системы

Параметр --skip-validation-for-machines представляет имена компьютеров без операционной системы в кластере, которые должны пропускаться во время проверки оборудования. Пропущенные узлы не проверяются и не добавляются в пул узлов. Кроме того, пропущенные узлы не учитывают общий объем, используемый вычислениями пороговых значений.

az networkcloud cluster deploy \
  --name "$CLUSTER_NAME" \
  --resource-group "$CLUSTER_RG" \
  --subscription "$SUBSCRIPTION_ID" \
  --skip-validations-for-machines "$COMPX_SVRY_SERVER_NAME"

Сбой развертывания кластера

Чтобы отслеживать состояние асинхронной операции, запустите с включенным флагом --debug . При --debug указании ход выполнения запроса можно отслеживать. URL-адрес состояния операции можно найти, проверив выходные данные отладки, Azure-AsyncOperation которые ищут в Location ответе HTTP на запрос на создание. Заголовки могут предоставлять OPERATION_ID поле, используемое в вызове API HTTP.

OPERATION_ID="12312312-1231-1231-1231-123123123123*99399E995..."
az rest -m GET -u "https://management.azure.com/subscriptions/${SUBSCRIPTION_ID}/providers/Microsoft.NetworkCloud/locations/${LOCATION}/operationStatuses/${OPERATION_ID}?api-version=2022-12-12-preview"

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

{
  "endTime": "2023-03-24T14:56:59.0510455Z",
  "error": {
    "code": "HardwareValidationThresholdFailed",
    "message": "HardwareValidationThresholdFailed error hardware validation threshold for cluster layout plan is not met for cluster $CLUSTER_NAME in namespace nc-system with listed failed devices $COMP0_SVR0_SERVER_NAME, $COMP1_SVR1_SERVER_NAME"
  },
  "id": "/subscriptions/$SUBSCRIPTION_ID/providers/Microsoft.NetworkCloud/locations/$LOCATION/operationStatuses/12312312-1231-1231-1231-123123123123*99399E995...",
  "name": "12312312-1231-1231-1231-123123123123*99399E995...",
  "resourceId": "/subscriptions/$SUBSCRIPTION_ID/resourceGroups/$CLUSTER_RESOURCE_GROUP/providers/Microsoft.NetworkCloud/clusters/$CLUSTER_NAME",
  "startTime": "2023-03-24T14:56:26.6442125Z",
  "status": "Failed"
}

См. статью "Отслеживание асинхронных операций с помощью Azure CLI " для другого примера. Дополнительные сведения см. в статье "Устранение неполадок подготовки BMM", которые могут оказаться полезными при сбое проверки или развертывания конкретных компьютеров.

Проверка развертывания кластера

Просмотрите состояние кластера на портале или с помощью Azure CLI:

az networkcloud cluster show --resource-group "$CLUSTER_RG" \
  --name "$CLUSTER_NAME"

Развертывание кластера выполняется, когда для подробных данныхStatus задано Deploying значение и подробное значениеStatusMessage показывает ход развертывания. Ниже приведены некоторые примеры хода развертывания, показанные в подробной версииStatusMessage Hardware validation is in progress. (если кластер развернут с помощью проверки оборудования), Cluster is bootstrapping., , KCP initialization in progress.Management plane deployment in progress., Cluster extension deployment in progress.и waiting for "<rack-ids>" to be readyт. д.

Снимок экрана: портал Azure, показывающий ход развертывания кластера kcp init.

Снимок экрана: портал Azure с приложением расширения развертывания кластера.

Развертывание кластера будет завершено, когда для подробного значенияStatusMessage задано Running значение и подробно отображается сообщение Cluster is up and running.

Снимок экрана: портал Azure с полным развертыванием кластера.

Просмотрите версию управления кластера:

az k8s-extension list --cluster-name "$CLUSTER_NAME" --resource-group "$MRG_NAME" --cluster-type connectedClusters --query "[?name=='nc-platform-extension'].{name:name, extensionType:extensionType, releaseNamespace:scope.cluster.releaseNamespace,provisioningState:provisioningState,version:version}" -o table --subscription "$SUBSCRIPTION_ID"

Ведение журнала развертывания кластера

Журналы создания кластера можно просмотреть в следующих расположениях:

  1. портал Azure журналы действий Resource/ResourceGroup.
  2. Azure CLI с --debug флагом, переданным в командной строке.

Снимок экрана: портал Azure с журналом действий развертывания кластера.

Обновление удостоверений кластера с помощью API

Управляемые удостоверения кластера можно назначать с помощью ИНТЕРФЕЙСА командной строки. Отмена назначения удостоверений осуществляется с помощью вызовов API. Обратите внимание, <APIVersion> что API версии 2024-07-01 или более поздней версии.

  • Чтобы удалить все управляемые удостоверения, выполните следующую команду:

    az rest --method PATCH --url /subscriptions/$SUB_ID/resourceGroups/$CLUSTER_RG/providers/Microsoft.NetworkCloud/clusters/$CLUSTER_NAME?api-version=<APIVersion> --body "{\"identity\":{\"type\":\"None\"}}"

  • Если были добавлены управляемые удостоверения, назначаемые пользователем и назначаемым системой, можно удалить, обновив следующие type SystemAssigned:

    az rest --method PATCH --url /subscriptions/$SUB_ID/resourceGroups/$CLUSTER_RG/providers/Microsoft.NetworkCloud/clusters/$CLUSTER_NAME?api-version=<APIVersion> --body @~/uai-body.json

    Пример текста запроса (uai-body.json):

    {
  "identity": {
      "type": "SystemAssigned"
  }
}

  • Если добавлены управляемые удостоверения, назначаемые пользователем и назначаемые системой, можно удалить, обновив следующие type UserAssignedзначения:

    az rest --method PATCH --url /subscriptions/$SUB_ID/resourceGroups/$CLUSTER_RG/providers/Microsoft.NetworkCloud/clusters/$CLUSTER_NAME?api-version=<APIVersion> --body @~/uai-body.json

    Пример текста запроса (uai-body.json):

    {
  "identity": {
      "type": "UserAssigned",
  	"userAssignedIdentities": {
  		"/subscriptions/$SUB_ID/resourceGroups/$UAI_RESOURCE_GROUP/providers/Microsoft.ManagedIdentity/userAssignedIdentities/$UAI_NAME": {}
  	}
  }
}

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

    az rest --method PATCH --url /subscriptions/$SUB_ID/resourceGroups/$CLUSTER_RG/providers/Microsoft.NetworkCloud/clusters/$CLUSTER_NAME?api-version=<APIVersion> --body @~/uai-body.json

    Пример текста запроса (uai-body.json):

    {
  "identity": {
      "type": "UserAssigned",
  	"userAssignedIdentities": {
  		"/subscriptions/$SUB_ID/resourceGroups/$UAI_RESOURCE_GROUP/providers/Microsoft.ManagedIdentity/userAssignedIdentities/$UAI_NAME": null
  	}
  }
}

Удаление кластера

Удаление кластера удаляет ресурсы в Azure и кластере, который находится в локальной среде.

Примечание.

Если в кластере существуют какие-либо ресурсы клиента, они не будут удалены до тех пор, пока эти ресурсы не будут удалены.

Снимок экрана: портал с ошибкой удаления из-за ресурсов клиента. 

az networkcloud cluster delete --name "$CLUSTER_NAME" --resource-group "$CLUSTER_RG"