Оценка готовности к развертыванию среды для локальной среды Azure

Используйте проверяющий элемент подключения, чтобы проверить, имеют ли все компьютеры в системе подключение к Интернету и соответствуют минимальным требованиям к подключению. Предварительные требования к подключению см. в разделе "Требования к брандмауэру" для локальной службы Azure.

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

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

Запуск проверяющего средства подключения

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

1. Откройте PowerShell локально на рабочей станции, промежуточном сервере или локальном компьютере Azure.

2. Выполните проверку подключения, введя следующий командлет:

   Invoke-AzStackHciConnectivityValidation 
   

   Примечание.

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

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

Пример 1. Проверка подключения удаленного компьютера

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

$session = New-PSSession -ComputerName remotesystem.contoso.com -Credential $credential
Invoke-AzStackHciConnectivityValidation -PsSession $Session

Пример 2. Проверка подключения для определенной службы

Вы можете проверить подключение для определенной конечной точки службы, передав Service параметр. В следующем примере проверяющий проверяет подключение к конечным точкам службы Azure Arc.

Invoke-AzStackHciConnectivityValidation -Service "Arc For Servers"

Пример 3. Проверка подключения при использовании прокси-сервера

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

Invoke-AzStackHciConnectivityValidation -Proxy http://proxy.contoso.com:8080 -ProxyCredential $proxyCredential 

Пример 4. Проверка подключения и создание выходного объекта PowerShell

Выходные данные средства проверки подключения можно просмотреть как объект с помощью –PassThru параметра:

Invoke-AzStackHciConnectivityValidation –PassThru

Ниже приведен пример снимка экрана выходных данных:

Атрибуты проверяющего средства подключения

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

Выходные данные проверяющего средства подключения

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

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

Пример выходных данных: успешный тест

Далее представлен пример успешного вывода валидатора подключения. Выходные данные указывают на работоспособное подключение ко всем конечным точкам, включая известные службы Azure и службы наблюдаемости. В разделе "Диагностика" можно увидеть проверку наличия и работоспособности DNS-сервера. Он собирает параметры прокси-сервера WinHttp, IE и переменных среды для диагностики и сбора данных. Он также проверяет, используется ли прозрачный прокси-сервер в пути к исходящему трафику и отображает выходные данные.

Пример выходных данных: неудачный тест

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

Сценарий потенциального сбоя для проверяющего средства подключения

Валидатор подключения проверяет наличие проверки SSL перед тестированием подключения к любым необходимым конечным точкам. Если проверка SSL включена в локальной системе Azure, вы получите следующую ошибку:

Обходное решение

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

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

C:\> Import-Module AzStackHci.EnvironmentChecker 
C:\> Get-SigningRootChain -Uri <Endpoint-URI> | ft subject 

Например, если вы хотите проверить сведения о сертификате для двух конечных точек, скажем https://login.microsoftonline.com , и https://portal.azure.comвыполните следующие команды по отдельности для каждой конечной точки:

• Для https://login.microsoftonline.com:

  C:\> Import-Module AzStackHci.EnvironmentChecker 
  C:\> Get-SigningRootChain -Uri https://login.microsoftonline.com | ft subject
  

  Ниже приведен пример выходных данных.

  Subject
  -------
  CN=portal.office.com, O=Microsoft Corporation, L=Redmond, S=WA, C=US
  CN=Microsoft Azure TLS Issuing CA 02, O=Microsoft Corporation, C=US
  CN=DigiCert Global Root G2, OU=www.digicert.com, O=DigiCert Inc, C=US
  

• Для https://portal.azure.com:

  C:\> Import-Module AzStackHci.EnvironmentChecker
  C:\> Get-SigningRootChain -Uri https://portal.azure.com | ft Subject 
  
  

  Ниже приведен пример выходных данных.

  Subject
  -------
  CN=portal.azure.com, O=Microsoft Corporation, L=Redmond, S=WA, C=US
  CN=Microsoft Azure TLS Issuing CA 01, O=Microsoft Corporation, C=US
  CN=DigiCert Global Root G2, OU=www.digicert.com, O=DigiCert Inc, C=US
  

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

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

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

Запуск средства проверки оборудования

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

1. Откройте PowerShell от имени администратора локально на локальном компьютере Azure.

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

   Invoke-AzStackHciHardwareValidation 
   

Ниже приведены некоторые примеры использования аппаратного проверяющего элемента.

Пример 1. Проверка готовности оборудования одного или нескольких удаленных компьютеров

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

$session = New-PSSession –ComputerName remotesystem1.contoso.com,remotesystem2.contoso.com -Credential $credential  

Invoke-AzStackHciHardwareValidation -PsSession $Session 

Выходные данные проверки оборудования

Ниже приведены выходные данные успешных и неудачных запусков аппаратного валидатора.

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

Пример выходных данных: успешный тест

Ниже приведен пример выходных данных успешного выполнения проверки оборудования:

Пример выходных данных: неудачный тест

Ниже приведен пример выходных данных из неудачного запуска проверки оборудования:

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

Перед развертыванием Azure Local важно убедиться, что все узлы настроены согласованно и могут синхронизировать время.

Используйте проверяющий элемент программного обеспечения для проверки следующих компонентов на всех целевых узлах:

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

• Согласованность версий операционной системы. Гарантирует, что все узлы выполняют одну и ту же поддерживаемую версию ОС.

• Целостность группы локальных администраторов. Проверяет, разрешены ли все идентификаторы безопасности (SID) в локальной группе администраторов.

Запуск проверяющего средства программного обеспечения

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

1. Откройте PowerShell от имени администратора локально на локальном компьютере Azure.

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

   $session = New-PSSession -ComputerName remotesystem.contoso.com -Credential $credential
   Invoke-AzStackHciSoftwareValidation -PsSession $Session -Exclude Test-IsNotPartofDomain
   

Выходные данные проверяющего программного обеспечения

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

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

Пример выходных данных: успешный тест

Следующий пример — это выходные данные успешного запуска проверяющего программного обеспечения. Выходные данные указывают на то, что все проверки конфигурации операционной системы, локальной группы и NTP успешно завершены без проблем.

Пример выходных данных: неудачный тест

Следующий пример — это выходные данные из неудачного запуска проверяющего программного обеспечения. Выходные данные указывают на то, что большинство проверок пройдено, но одна проблема синхронизации с сервером NTP на V-HOST2 требует исправления, в результате 4 из 5 проверок (80%) завершились успешно.

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

Используйте валидатор Active Directory:

• Убедитесь, что средство подготовки Active Directory запущено, а gMSAs настроены и группы подготавливаются перед началом развертывания.
• Оцените любую проблему Active Directory во время развертывания. Группа поддержки может проверить журналы отчетов валидатора, чтобы оценить, запускали ли вы средство подготовки Active Directory перед развертыванием.

Запуск проверяющего средства Active Directory

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

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

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

2. Выполните следующую команду в PowerShell от имени администратора:

   $params = @{
   ADOUPath = 'OU=Hci001,DC=contoso,DC=local'
   DomainFQDN = 'contoso.local'
   NamingPrefix = "hci"
   ActiveDirectoryServer = 'contoso.local'
   ActiveDirectoryCredentials = (Get-Credential -Message 'Active Directory Credentials')
   ClusterName = 'S-Cluster'
   PhysicalMachineNames = "node01, node02, node03, node04"
   }
   Invoke-AzStackHciExternalActiveDirectoryValidation @params
   

   Командлет Invoke-AzStackHciExternalActiveDirectoryValidation проверяет, доступны ли модули Active Directory и объекты групповой политики (GPO), и пытается установить их, если они не доступны.

Выходные данные валидатора Active Directory

Ниже приведены выходные данные успешных и неудачных запусков проверяющего элемента Active Directory.

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

Пример выходных данных: успешный тест

Пример ниже — это результат успешного запуска валидатора Active Directory. Выходные данные указывают на то, что указанное OU существует и содержит правильные вложенные OU.

Пример выходных данных: неудачный тест

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

Чтобы устранить проблемы блокировки в этих выходных данных, откройте средство Active Directory и передайте следующие параметры:

.\AsHciADArtifactsPreCreationTool.ps1 -AsHciDeploymentUserCredential (get-credential) -AsHciOUName "OU=Hci001,DC=contoso,DC=local,DC=stbtest,DC=microsoft,DC=com" -AsHciPhysicalNodeList @("Physical Machine1", "Physical Machine2") -DomainFQDN "'contoso.local " -AsHciClusterName "s-cluster" -AsHciDeploymentPrefix "Hci001"

Возможно, IP-адреса, выделенные для Azure Local, уже могут быть активными в сети. Валидатор сети проверяет сетевую инфраструктуру на допустимость диапазонов IP-адресов, зарезервированные для развертывания. Он пытается выполнить ping и подключиться к портам WinRM и SSH, чтобы убедиться, что IP-адрес из зарезервированного диапазона IP-адресов не используется активным узлом.

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

Вы предоставляете JSON-файл ответа в качестве входных данных для командлета проверки сети. Файл ответа — это JSON-файл, созданный мастером развертывания портала Azure, который содержит полную конфигурацию развертывания. Сюда входят сведения о узле, параметры сети и зарезервированные диапазоны IP-адресов. Например, C:\MASLogs\Unattended-2024-07-18-20-44-48.json. Кроме того, можно вручную указать отдельные параметры при выполнении командлета проверки.

Запуск проверки сети

Чтобы запустить средство проверки сети локально на локальном узле Azure с файлом ответов, выполните следующие команды:

$allServers = @("<ServerIP1>", "<ServerIP2>")  # Replace with actual IP addresses 
$userName = "<LOCALADMIN>" 
$secPassWord = ConvertTo-SecureString "<LOCALADMINPASSWORD>" -AsPlainText -Force 
$hostCred = New-Object System.Management.Automation.PSCredential($userName, $secPassWord) 
[System.Management.Automation.Runspaces.PSSession[]] $allServerSessions = @() 
foreach ($currentServer in $allServers) { 
   $currentSession = Microsoft.PowerShell.Core\New-PSSession -ComputerName $currentServer -Credential $hostCred -ErrorAction Stop 
   $allServerSessions += $currentSession 
} 
$answerFilePath = "<ANSWERFILELOCATION>" # Like C:\MASLogs\Unattended-2024-07-18-20-44-48.json 
Invoke-AzStackHciNetworkValidation -DeployAnswerFile $answerFilePath -PSSession $allServerSessions -ProxyEnabled $false 

Чтобы локально запустить средство проверки сети на локальном узле Azure с помощью отдельных параметров, используйте следующие команды:

$answerFilePath = "<ANSWERFILELOCATION>" 
$managementSubnetCIDR = "<CIDR string for management subnet>" 
$logOutputPath = "<LOGFILELOCATION>" 
$userName = "<LOCALADMIN>" 
$secPassWord = ConvertTo-SecureString "<LOCALADMINPASSWORD>" -AsPlainText -Force 
$sessionCredential = New-Object System.Management.Automation.PSCredential($userName, $secPassWord) 
$answerFileContent = Get-Content $answerFilePath -Raw | ConvertFrom-Json 
$ipPools = New-Object System.Collections.ArrayList 
[System.Management.Automation.Runspaces.PSSession[]] $allServerSessions = @() 
foreach ($ipPool in $answerFileContent.scaleUnits[0].deploymentData.infrastructureNetwork[0].ipPools) { 
   $currentPoolObject = [PSCustomObject] @{ 
     StartingAddress = $ipPool.StartingAddress 
     EndingAddress = $ipPool.EndingAddress 
   } 
   $ipPools.Add($currentPoolObject) 
} 
[PSObject[]] $atcHostIntentsInfo = $answerFileContent.scaleUnits[0].deploymentData.hostNetwork.intents 
[System.String[]] $allServers = $answerFileContent.scaleUnits[0].deploymentData.physicalNodes.Name 
[System.Management.Automation.Runspaces.PSSession[]] $allServerSessions = @() 
foreach ($currentServer in $allServers) { 
   $currentSession = Microsoft.PowerShell.Core\New-PSSession -ComputerName $currentServer -Credential $sessionCredential -ErrorAction Stop 
   $allServerSessions += $currentSession 
} 
Invoke-AzStackHciNetworkValidation -IpPools $ipPools -ManagementSubnetValue $managementSubnetCIDR -PSSession $allServerSessions -SessionCredential $sessionCredential -OutputPath $logOutputPath -AtcHostIntents $atcHostIntentsInfo 

Выходные данные примера проверки сети

Ниже приведен пример выходных данных неудачного запуска проверки сети. Сбой возникает, так как сетевой адаптер имеет два IP-адреса, если он должен иметь только один.

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

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

Чтобы проверить следующее, можно использовать валидатор интеграции Arc:

• Группа ресурсов Arc еще не содержит ресурсы Arc с теми же именами, что и узлы в кластере, которые вы пытаетесь подключить.
• Один или несколько узлов еще не поддерживают Arc в другом идентификаторе подписки или в другой группе ресурсов.
• Указанный регион Azure действителен.
• Ограничение группы ресурсов в подписке не достигнуто.
• Ограничение на количество локальных ресурсов Azure в группе ресурсов регистрации не достигнуто.
• Ограничение количества назначений ролей в подписке не достигнуто.

Запуск проверяющего средства интеграции Arc

1. Откройте PowerShell на любом локальном компьютере Azure.

2. Выполните следующую команду, чтобы подключиться к Azure с учетной записью, которую вы планируете подключить к локальной системе Azure:

   Connect-AzAccount -Tenant <Your_tenant_ID> -Subscription <Your_subscription_ID> -DeviceCode
   

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

   $nodes = [string[]]("host1"," host2"," host3"," host4")
   

4. Выполните следующую команду, чтобы вызвать проверяющий элемент:

   Invoke-AzStackHciArcIntegrationValidation -SubscriptionID <Your subscription ID> -RegistrationResourceGroupName <Resource group to onboard your Azure Local system> -ArcResourceGroupName  <Resource group to onboard your Azure Local system> -NodeNames $nodes
   

Выходные данные проверяющего средства интеграции Arc

Ниже приведены выходные данные успешного и неудачного запуска проверяющего средства интеграции Arc.

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

Пример выходных данных: успешный тест

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

Пример выходных данных: неудачный тест

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