Посмотреть известные проблемы в выпуске Azure Stack HCI 2405.1
Область применения: Azure Local 2311.2 и более поздних версий
В этой статье описаны критически важные известные проблемы и их обходные пути в выпуске Azure Stack HCI 2405.1.
Заметки о выпуске постоянно обновляются и по мере обнаружения критически важных проблем, требующих обходного решения, добавляются. Перед развертыванием Azure Stack HCI внимательно просмотрите сведения, содержащиеся в заметках о выпуске.
Важный
Для получения информации о поддерживаемых путях обновления для этого выпуска см. Информация о выпуске.
Дополнительные сведения о новых функциях в этом выпуске см. в Что нового в 23H2.
Проблемы с версией 2405.1
Этот релиз программного обеспечения соответствует номеру версии программного обеспечения 2405.1.4.
Заметки о выпуске для этой версии включают проблемы, исправленные в этом выпуске, известные проблемы в этом выпуске и отмеченные проблемы, перенесенные из предыдущих версий.
Исправлены проблемы
Ниже приведены исправленные проблемы в этом выпуске:
| Особенность | Проблема | Обходное решение или комментарии |
|---|---|---|
| Обновления | Исправлена проблема с обновлением. Эта проблема привела к сбою обновления после шага обновления Cluster-Aware (CAU), хотя повторное выполнение CAU в этом случае исправит проблему. | |
| Наблюдаемость | В этом выпуске исправлена проблема, которая приводила к отключению упреждающей коллекции журналов по умолчанию после установки расширения. | |
| Обновления | Устранена проблема, в результате которой диспетчеру жизненного цикла агента (ALM) не удавалось перезапустить службы после смены секретов. | |
| Обновления | В этом выпуске устранена проблема, из-за которой команда PowerShell Start-SolutionUpdate не смогла повторно выполнить обновление неудавшегося решения. |
|
| Обновления | Устранена проблема, из-за которой обновление расширения построителя решений не удалось скачать. | |
| Обновления | Устранена проблема, из-за которой обновления завершились сбоем во время проверки имени субъекта-службы (SPN) на основе параметров SPN развертывания. | |
| Обновления | Устранена проблема, из-за которой обновление Arc Resource Bridge (ARB) занимает много времени, и обновление завершается сбоем. | |
| Обновления | Устранена проблема, из-за которой проверки работоспособности обновлений Solution Builder отсутствовали в предварительных проверках перед обновлением или ежедневных проверках работоспособности. | |
| Добавление сервера Восстановление сервера |
Во время Add-Serverне следует ожидать, что сеть хранения кластера будет совпадать с идентификатором VLAN для хранилища. |
|
| Сетевые технологии | AzStackHci_Network_Test_Infra_IP_Connection необходимо учитывать серьезность определения конечной точки. |
Известные проблемы в этом выпуске
Корпорация Майкрософт не знает о известных проблемах в этом выпуске.
Известные проблемы из предыдущих выпусков
Ниже приведены известные проблемы из предыдущих выпусков:
| Особенность | Проблема | Обходное решение | ||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Обновление | При просмотре результатов проверки готовности для кластера Azure Stack HCI с помощью диспетчера обновлений Azure может быть несколько проверок готовности с одинаковым именем. | В этом выпуске нет известного обходного пути. Выберите Просмотреть сведения, чтобы ознакомиться с конкретной информацией о проверке готовности. | ||||||||||||||||||
| Управление виртуальными машинами Arc | В крупных сценариях развертывания, таких как обширные развертывания пула хостов AVD или крупномасштабная подготовка виртуальных машин, могут возникнуть проблемы с надежностью, вызванные ошибкой в внешней библиотеке сокетов Hyper-V. | Выполните следующие действия, чтобы устранить проблему: 1. Выполните команду Get-service mochostagent (\) get-process (\) kill. Проверьте выходные данные команды и проверьте, находится ли число дескрипторов в тысячах. 2. Выполните команду Get-service mochostagent (\) get-process, чтобы завершить процессы. 3. Выполните команду restart-service mochostagent, чтобы перезапустить службу mochostagent. |
||||||||||||||||||
| Развертывание | При развертывании Azure Stack HCI версии 23H2 с помощью портала Azure может возникнуть следующий сбой проверки развертывания: Could not complete the operation. 400: Resource creation validation failed. Details: [{"Code":"AnswerFileValidationFailed","Message":"Errors in Value Validation:\r\nPhysicalNodesValidator found error at deploymentdata.physicalnodes[0].ipv4address: The specified for \u0027deploymentdata.physicalnodes[0].ipv4address\u0027 is not a valid IPv4 address. Example: 192.168.0.1 or 192.168.0.1","Target":null,"Details":null}]. Если перейти на вкладку Сетевые в портале Azure в конфигурации намерения сети, можно увидеть следующую ошибку: выбранный физический сетевой адаптер не подключён к виртуальному коммутатору управления. |
Выполните процедуру, описанную в разделе Устранение неполадок проверки развертывания на портале Azure. | ||||||||||||||||||
| Развертывание | Развертывание с помощью портала Azure завершается ошибкой: не удалось получить секрет LocalAdminCredential из хранилища ключей. | В этом выпуске не существует обходного решения этой проблемы. Если возникла проблема, обратитесь в службу поддержки Майкрософт для дальнейших действий. | ||||||||||||||||||
| Развертывание | В некоторых случаях во время регистрации серверов Azure Stack HCI эта ошибка может появиться в журналах отладки: обнаружена внутренняя ошибка сервера. Возможно, не установлен один из обязательных расширений для развертывания устройства. | Выполните следующие действия, чтобы устранить проблему: $Settings = @{ "CloudName" = $Cloud; "RegionName" = $Region; "DeviceType" = "AzureEdge" } New-AzConnectedMachineExtension -Name "AzureEdgeTelemetryAndDiagnostics" -ResourceGroupName $ResourceGroup -MachineName $env:COMPUTERNAME -Location $Region -Publisher "Microsoft.AzureStack.Observability" -Settings $Settings -ExtensionType "TelemetryAndDiagnostics" -EnableAutomaticUpgrade New-AzConnectedMachineExtension -Name "AzureEdgeDeviceManagement" -ResourceGroupName $ResourceGroup -MachineName $env:COMPUTERNAME -Location $Region -Publisher "Microsoft.Edge" -ExtensionType "DeviceManagementExtension"New-AzConnectedMachineExtension -Name "AzureEdgeLifecycleManager" -ResourceGroupName $ResourceGroup -MachineName $env:COMPUTERNAME -Location $Region -Publisher "Microsoft.AzureStack.Orchestration" -ExtensionType "LcmController" New-AzConnectedMachineExtension -Name "AzureEdgeRemoteSupport" -ResourceGroupName $ResourceGroup -MachineName $env:COMPUTERNAME -Location $Region -Publisher "Microsoft.AzureStack.Observability" -ExtensionType "EdgeRemoteSupport" -EnableAutomaticUpgrade |
||||||||||||||||||
| Обновление | В этом выпуске возникает периодическая проблема, когда портал Azure неправильно указывает состояние обновления как не удалось обновить или в процессе, хотя обновление завершено. |
Подключитесь к локальной Azure через удаленный сеанс PowerShell. Чтобы подтвердить состояние обновления, выполните следующие командлеты PowerShell: $Update = get-solutionupdate| ? version -eq "<version string>"Замените строку версии на версию, которую вы используете. Например, "10.2405.0.23". $Update.stateЕсли состояние обновления установлено как , дальнейшие действия не требуются. Портал Azure правильно обновляет состояние в течение 24 часов. Чтобы обновить состояние раньше, выполните следующие действия на одном из узлов кластера. Перезапустите группу кластеров Cloud Management. Stop-ClusterGroup "Cloud Management"Start-ClusterGroup "Cloud Management" |
||||||||||||||||||
| Обновление | Во время первоначального обновления MOC происходит сбой из-за отсутствия целевой версии MOC в кэше каталога. Последующие обновления и повторные попытки отображают MOC в целевой версии, но обновление не удается, и в результате обновление Моста ресурсов Arc завершается сбоем. Чтобы проверить эту проблему, соберите журналы обновлений с помощью Устранение неполадок с обновлениями решения для Azure Stack HCI версии 23H2. Файлы журнала должны отображать аналогичное сообщение об ошибке (текущая версия может отличаться в сообщении об ошибке): [ERROR: { "errorCode": "InvalidEntityError", "errorResponse": "{\n\"message\": \"the cloud fabric (MOC) is currently at version v0.13.1. A minimum version of 0.15.0 is required for compatibility\"\n}" }] |
Выполните следующие действия, чтобы устранить проблему: 1. Чтобы найти версию агента MOC, выполните следующую команду: 'C:\Program Files\AksHci\wssdcloudagent.exe' version.2. Используйте выходные данные команды, чтобы найти версию MOC из приведенной ниже таблицы, которая соответствует версии агента, и задайте $initialMocVersion этой версии MOC. Установите параметр $targetMocVersion, найдя версию сборки Azure Stack HCI, до которой вы обновляетесь, и найдите соответствующую версию MOC из следующей таблицы. Используйте эти значения в скрипте устранения рисков, приведенном ниже:
Например, если версия агента — v0.13.0-6-gf13a73f7, v0.11.0-alpha.38, 01.06.2024, то $initialMocVersion = “1.0.24.10106”, а при обновлении до версии 2405.0.23 — $targetMocVersion = “1.3.0.10418”.3. Выполните следующие команды PowerShell на первом узле: $initialMocVersion = "<initial version determined from step 2>"$targetMocVersion = "<target version determined from step 2>"# Импорт модуля MOC дважды import-module mocimport-module moc$verbosePreference = "Continue"# Очистка кэша каталога SFS Remove-Item (Get-MocConfig).manifestCache# Установите текущую версию MOC перед обновлением и задайте состояние как неудача обновления Set-MocConfigValue -name "version" -value $initialMocVersionSet-MocConfigValue -name "installState" -value ([InstallState]::UpdateFailed)# Повторное выполнение обновления MOC до требуемой версии Update-Moc -version $targetMocVersion4. Возобновление обновления. |
||||||||||||||||||
| AKS на HCI | Создание кластера AKS завершается сбоем с Error: Invalid AKS network resource id. Эта проблема может возникать, если в связанном логическом сетевом имени содержится подчеркивание. |
Символы подчеркивания не поддерживаются в именах логических сетей. Не используйте подчеркивание в именах логических сетей, развернутых в Azure Stack HCI. | ||||||||||||||||||
| Восстановление сервера | В редких случаях операция Repair-Server завершается ошибкой HealthServiceWaitForDriveFW. В этих случаях старые диски из восстановленного узла не удаляются, а новые диски зависают в режиме обслуживания. |
Чтобы предотвратить эту проблему, перед началом работы с Repair-Serverубедитесь, что вы НЕ сливаете узел ни через Центр администрирования Windows, ни с помощью командлета PowerShell Suspend-ClusterNode -Drain. Если возникла проблема, обратитесь в службу поддержки Майкрософт для дальнейших действий. |
||||||||||||||||||
| Восстановление сервера | Эта проблема возникает, когда единственный сервер Azure Stack HCI обновляется с версии 2311 до 2402, а затем выполняется операция Repair-Server. Операция восстановления завершается ошибкой. |
Перед восстановлением одного узла выполните следующие действия. 1. Запустите версию 2402 для ADPrepTool. Выполните действия, описанные в подготовке Active Directory. Это действие быстро добавляет необходимые разрешения в организационную единицу (OU). 2. Переместите объект компьютера из компьютеров сегмент в корневую подразделение. Выполните следующую команду: Get-ADComputer <HOSTNAME> | Move-ADObject -TargetPath "<OU path>" |
||||||||||||||||||
| Развертывание | Если вы подготавливаете Active Directory самостоятельно (не используя скрипт и процедуру, предоставляемую корпорацией Майкрософт), проверка Active Directory может завершиться ошибкой с отсутствием разрешения Generic All. Это связано с тем, что в проверке обнаружена проблема, касающаяся наличия отдельной записи разрешений для msFVE-RecoverInformationobjects – General – Permissions Full control, которая необходима для восстановления BitLocker. |
Используйте метод скрипта Prepare AD или, если вы используете собственный метод, обязательно назначьте конкретное разрешение msFVE-RecoverInformationobjects – General – Permissions Full control. |
||||||||||||||||||
| Развертывание | В этом выпуске возникает редкая проблема, из-за которой запись DNS удаляется во время развертывания Azure Stack HCI. В этом случае будет видно следующее исключение: Type 'PropagatePublicRootCertificate' of Role 'ASCA' raised an exception:<br>The operation on computer 'ASB88RQ22U09' failed: WinRM cannot process the request. The following error occurred while using Kerberos authentication: Cannot find the computer ASB88RQ22U09.local. Verify that the computer exists on the network and that the name provided is spelled correctly at PropagatePublicRootCertificate, C:\NugetStore\Microsoft.AzureStack, at Orchestration.Roles.CertificateAuthority.10.2402.0.14\content\Classes\ASCA\ASCA.psm1: line 38, at C:\CloudDeployment\ECEngine\InvokeInterfaceInternal.psm1: line 127,at Invoke-EceInterfaceInternal, C:\CloudDeployment\ECEngine\InvokeInterfaceInternal.psm1: line 123. |
Проверьте DNS-сервер, чтобы узнать, отсутствуют ли записи DNS узлов кластера. Примените следующее смягчение на узлах, где отсутствует их запись DNS. Перезапустите службу DNS-клиента. Откройте сеанс PowerShell и выполните следующий командлет на затронутом узле: Taskkill /f /fi "SERVICES eq dnscache" |
||||||||||||||||||
| развертывания | В этом выпуске в развертывании с несколькими узлами возникает сбой удаленной задачи, которая приводит к следующему исключению:ECE RemoteTask orchestration failure with ASRR1N42R01U31 (node pingable - True): A WebException occurred while sending a RestRequest. WebException.Status: ConnectFailure on [https://<URL>](https://<URL>). |
Мера по устранению заключается в перезапуске агента ECE на затронутом узле. На сервере откройте сеанс PowerShell и выполните следующую команду:Restart-Service ECEAgent. |
||||||||||||||||||
| Добавить сервер | В этом выпуске и предыдущих выпусках при добавлении сервера в кластер невозможно обновить строку списка обхода прокси-сервера, чтобы включить новый сервер. Обновление переменных среды, касающихся списка обхода прокси-сервера на узлах, не обновит список обхода прокси-сервера в Azure Resource Bridge или AKS. | В этом выпуске нет обходного решения. Если вы столкнулись с этой проблемой, обратитесь в службу поддержки Майкрософт, чтобы определить дальнейшие действия. | ||||||||||||||||||
| Добавить/Восстановить сервер | В этом выпуске при добавлении или восстановлении сервера происходит сбой, когда сертификаты виртуальной машины сетевого контроллера или программного обеспечения балансировщика нагрузки копируются с существующих узлов. Сбой заключается в том, что эти сертификаты не были созданы во время развертывания или обновления. | В этом выпуске нет обходного решения. Если вы столкнулись с этой проблемой, обратитесь в службу поддержки Майкрософт, чтобы определить дальнейшие действия. | ||||||||||||||||||
| Деплоймент | В этом выпуске возникает временная проблема, приводяшая к сбою развертывания со следующим исключением:Type 'SyncDiagnosticLevel' of Role 'ObservabilityConfig' raised an exception:*<br>*Syncing Diagnostic Level failed with error: The Diagnostic Level does not match. Portal was not set to Enhanced, instead is Basic. |
Так как это временная проблема, повторная попытка развертывания должна устранить эту проблему. Дополнительные сведения о том, как повторно запустить развертывание. | ||||||||||||||||||
| Развертывание | В этом выпуске возникла проблема с полем URI/расположением секретов. Это обязательное поле, которое помечается Не обязательно и приводит к сбоям развертывания шаблона Azure Resource Manager. | Используйте пример файла параметров в развертывании Azure Stack HCI версии 23H2 с помощью шаблона Azure Resource Manager, чтобы убедиться, что все входные данные предоставляются в требуемом формате, а затем попробуйте развертывание. Если произошел сбой развертывания, необходимо также очистить следующие ресурсы, прежде чем повторно запустить развертывание: 1. Удалить C:\EceStore. 2. Удалить C:\CloudDeployment. 3. Удалить C:\nugetstore. 4. Remove-Item HKLM:\Software\Microsoft\LCMAzureStackStampInformation. |
||||||||||||||||||
| Безопасность | Для новых развертываний устройства с поддержкой Secured-core не будут иметь динамический корень измерения (DRTM) по умолчанию. Если вы попытаетесь включить (DRTM) с помощью командлета Enable-AzSSecurity, вы увидите сообщение об ошибке, что параметр DRTM не поддерживается в текущем выпуске. Корпорация Майкрософт рекомендует глубинную защиту, а безопасная загрузка UEFI по-прежнему защищает компоненты в цепочке загрузки статического корня доверия (SRT), гарантируя, что они загружаются только при подписании и проверке. |
DRTM не поддерживается в этом выпуске. | ||||||||||||||||||
| Сетевые | Проверка среды завершается ошибкой при использовании прокси-сервера. По замыслу конструкций список исключений отличается для winhttp и wininet, что приводит к сбою проверки. | Выполните следующие обходные действия: 1. Очистите список обхода прокси-сервера перед проверкой работоспособности и до начала развертывания или обновления. 2. После успешного прохождения проверки дождитесь, пока не произойдет сбой в развертывании или обновлении. 3. Снова задайте список обхода прокси-сервера. |
||||||||||||||||||
| Управление виртуальными машинами Arc | Развертывание или обновление моста ресурсов Arc может завершиться неудачей, если автоматически созданный временный секрет для субъекта-службы во время этой операции начинается с дефиса. | Повторите развертывание и обновление. Повторная попытка должна пересоздать секрет SPN, и операция, скорее всего, завершится успешно. | ||||||||||||||||||
| Управление виртуальными машинами Arc | Расширения Arc на виртуальных машинах Arc остаются в состоянии "Создание" на неопределенный срок. | Войдите на виртуальную машину, откройте командную строку и введите следующее: Windows: notepad C:\ProgramData\AzureConnectedMachineAgent\Config\agentconfig.json Linux: sudo vi /var/opt/azcmagent/agentconfig.json Затем найдите свойство resourcename. Удалите GUID, добавляемый в конец имени ресурса, поэтому это свойство соответствует имени виртуальной машины. Затем перезапустите виртуальную машину. |
||||||||||||||||||
| Управление виртуальными машинами Arc | При добавлении нового сервера в кластер Azure Stack HCI путь к хранилищу не создается автоматически для созданного тома. | Вы можете вручную создать путь к хранилищу для любых новых томов. Дополнительные сведения см. в статье Создание пути хранения. | ||||||||||||||||||
| Управление виртуальными машинами Arc | Перезапуск операции виртуальной машины Arc завершается примерно через 20 минут, хотя сама виртуальная машина перезапускается примерно за минуту. | В этом выпуске нет известного обходного решения. | ||||||||||||||||||
| Управление виртуальными машинами Arc | В некоторых случаях состояние логической сети отображается как сбой на портале Azure. Это происходит при попытке удалить логическую сеть без первого удаления ресурсов, таких как сетевые интерфейсы, связанные с этой логической сетью. Вы по-прежнему сможете создавать ресурсы в этой логической сети. Статус вводит в заблуждение в этом случае. |
Если статус этой логической сети был успешно на момент её развертывания, то можно продолжать создавать ресурсы на этой логической сети. | ||||||||||||||||||
| Управление виртуальными машинами Arc | В этом выпуске при обновлении виртуальной машины с диском данных, подключенным к нему с помощью Azure CLI, операция завершается ошибкой со следующим сообщением об ошибке: не удалось найти виртуальный жесткий диск с именем. |
Используйте портал Azure для всех операций обновления виртуальной машины. Дополнительные сведения см. в статье Управление виртуальными машинами Arc и управление ресурсами виртуальных машин Arc. | ||||||||||||||||||
| Обновление | В редких случаях эта ошибка может возникнуть при обновлении Azure Stack HCI: Type 'UpdateArbAndExtensions' of Role 'MocArb' raised an exception: Exception Upgrading ARB and Extension in step [UpgradeArbAndExtensions :Get-ArcHciConfig] UpgradeArb: Invalid applianceyaml = [C:\AksHci\hci-appliance.yaml]. |
Если вы видите эту проблему, обратитесь в службу поддержки Майкрософт, чтобы помочь вам выполнить следующие действия. | ||||||||||||||||||
| Сетевые технологии | В этом выпуске существует редкая проблема с DNS-клиентом, которая приводит к сбою развертывания в двухузловом кластере из-за ошибки разрешения DNS: произошла WebException при отправке RestRequest. WebException.Status: NameResolutionFailure. В результате этой ошибки запись DNS второго узла удаляется вскоре после её создания, что приводит к ошибке DNS. | Перезапустите сервер. Эта операция регистрирует запись DNS, которая предотвращает удаление. | ||||||||||||||||||
| Портал Azure | В некоторых случаях портал Azure может занять некоторое время для обновления, и представление может не быть текущим. | Чтобы просмотреть обновленное представление, может потребоваться 30 минут или более. | ||||||||||||||||||
| Управление виртуальными машинами Arc | В этой версии удаление сетевого интерфейса на виртуальной машине Arc через портал Azure не работает. | Используйте Azure CLI, чтобы сначала удалить сетевой интерфейс, а затем удалить его. Дополнительные сведения см. в статье Удаление сетевого интерфейса и удалениесетевого интерфейса. | ||||||||||||||||||
| Развёртывание | Указание имени подразделения в неправильном синтаксисе не обнаружено на портале Azure. Неправильный синтаксис содержит неподдерживаемые символы, такие как &,",',<,>. Неправильный синтаксис обнаруживается на более позднем этапе при проверке кластера. |
Убедитесь, что формат пути организационной единицы является правильным и не включает неподдерживаемые символы. | ||||||||||||||||||
| Развёртывание | Развертывание с помощью Azure Resource Manager истекает через 2 часа. Развертывания, превышающие 2 часа, отображаются как неудачные в группе ресурсов, хотя кластер успешно создан. | Чтобы отслеживать развертывание на портале Azure, перейдите к ресурсу кластера Azure Stack HCI, а затем перейдите к новой записи Deployments. | ||||||||||||||||||
| Azure Site Recovery | Нельзя установить Azure Site Recovery на кластер Azure Stack HCI в данной версии. | В этом выпуске нет известного обходного решения. | ||||||||||||||||||
| Обновление | При обновлении кластера Azure Stack HCI с помощью диспетчера обновлений Azure ход обновления и результаты могут не отображаться на портале Azure. | Чтобы обойти эту проблему, на каждом узле кластера добавьте следующий раздел реестра (значение не требуется):New-Item -Path "HKLM:\SYSTEM\CurrentControlSet\Services\HciCloudManagementSvc\Parameters" -forceЗатем на одном из узлов кластера перезапустите группу кластеров Cloud Management. Stop-ClusterGroup "Cloud Management"Start-ClusterGroup "Cloud Management"Это не полностью исправит проблему, так как сведения о ходе выполнения по-прежнему не отображаются в течение периода обновления. Чтобы получить последние сведения об обновлении, можно получить ход обновления с помощью PowerShell. |
||||||||||||||||||
| Обновление | В редких случаях, если неудачное обновление застряло в состоянии 'Выполняется' в диспетчере Azure Update Manager, кнопка Повторить попытку отключена. | Чтобы возобновить обновление, выполните следующую команду PowerShell:Get-SolutionUpdate
|
Start-SolutionUpdate. |
||||||||||||||||||
| Обновления | В некоторых случаях команды SolutionUpdate могут не работать, если их выполняют после команды Send-DiagnosticData. |
Закройте сеанс PowerShell, используемый для Send-DiagnosticData. Откройте новый сеанс PowerShell и используйте его для SolutionUpdate команд. |
||||||||||||||||||
| Обновление | В редких случаях при применении обновления с версии 2311.0.24 до 2311.2.4 показывается состояние кластера Выполняется вместо ожидаемого Не удалось обновить. | Повторите обновление. Если проблема сохранится, обратитесь в службу поддержки Майкрософт. | ||||||||||||||||||
| Обновление | Попытки установки обновлений решения могут завершиться сбоем в конце шагов CAU с помощью:There was a failure in a Common Information Model (CIM) operation, that is, an operation performed by software that Cluster-Aware Updating depends on.
Редкая проблема возникает, если ресурсы Cluster Name или Cluster IP Address не смогли запуститься после перезагрузки узла и наиболее типична в небольших кластерах. |
Если вы столкнулись с этой проблемой, обратитесь в службу поддержки Майкрософт для дальнейших действий. Они могут работать с вами, чтобы вручную перезапустить ресурсы кластера и возобновить обновление по мере необходимости. | ||||||||||||||||||
| Обновление | При применении обновления кластера к версии 10.2402.3.11 командлет Get-SolutionUpdate может не отвечать и в конечном итоге завершается сбоем с запросом RequestTimeoutException примерно через 10 минут. Это может произойти после сценария добавления или восстановления сервера. |
Используйте командлеты Start-ClusterGroup и Stop-ClusterGroup для перезапуска службы обновления. Get-ClusterGroup -Name "Azure Stack HCI Update Service Cluster Group"
|
Stop-ClusterGroup
Get-ClusterGroup -Name "Azure Stack HCI Update Service Cluster Group"
|
Start-ClusterGroup
Успешный запуск этих командлетов должен привести службу обновления в режим "в сети". |
||||||||||||||||||
| Кластер-осведомлённое обновление | Не удалось возобновить операцию узла. | Это временная проблема и может решиться самостоятельно. Подождите несколько минут и повторите операцию. Если проблема сохранится, обратитесь в службу поддержки Майкрософт. | ||||||||||||||||||
| Кластерно-ориентированное обновление | Приостановка операции узла зависла на протяжении более 90 минут. | Это временная проблема и может решиться самостоятельно. Подождите несколько минут и повторите операцию. Если проблема сохранится, обратитесь в службу поддержки Майкрософт. |
Дальнейшие действия
- Ознакомьтесь с обзором развертывания.