Устранение ошибок при переключении после отказа виртуальной машины в VMware или физического компьютера в Azure

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

Ошибки переключения при отказе

Файловер завершился со следующими ошибками:

Системе Site Recovery не удалось создать виртуальную машину в Azure после отказа. Это может произойти из-за одной из следующих причин:

Для создания виртуальной машины недостаточно квоты: Вы можете проверить доступную квоту, перейдя в раздел "Подписка" —> "Использование и квоты". Чтобы увеличить квоту, можно открыть новый запрос на поддержку .
Вы пытаетесь выполнить переключение на резерв виртуальных машин разных типов в одном сете доступности. Убедитесь, что вы выбираете одно семейство размеров для всех виртуальных машин в одной группе доступности. Измените размер, перейдя к параметрам вычислений виртуальной машины, а затем повторите отработку отказа.
Существует политика в подписке, которая предотвращает создание виртуальной машины. Измените политику, чтобы разрешить создание виртуальной машины, а затем повторите процесс отказоустойчивости.

Системе Site Recovery не удалось создать виртуальную машину в Azure после отказа. Это может произойти из-за сбоя внутренней активности гидратации для локальной виртуальной машины.

Чтобы запустить любую машину в Azure, среда Azure требует, чтобы некоторые драйверы были в состоянии начальной загрузки, и службы, такие как DHCP, должны быть в состоянии автоматического запуска. Таким образом, действие гидратации в момент переключения на резервный узел преобразует тип запуска драйверов atapi, intelide, storflt, vmbus и storvsc в "boot start". Он также преобразует тип запуска нескольких служб, таких как DHCP, в автозапуск. Это действие может завершиться ошибкой из-за конкретных проблем среды.

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

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

.\Script-no-hydration.ps1

Он дает следующий результат, если требуется гидратация:
```
REGISTRY::HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\services\storvsc           start =  3 expected value =  0

This system doesn't meet no-hydration requirement.
```
Если виртуальная машина соответствует требованиям без гидратации, сценарий дает результат "Эта система соответствует требованиям без гидратации". В этом случае все драйверы и службы находятся в состоянии, требуемом Azure, и гидратация на виртуальной машине не требуется.
Запустите скрипт no-hydration-set следующим образом, если виртуальная машина не соответствует требованиям no-hydration.

.\Script-no-hydration.ps1 -set

Это преобразует тип драйверов запуска и даст результат, как показано ниже:
```
REGISTRY::HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\services\storvsc           start =  3 expected value =  0

Updating registry:  REGISTRY::HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\services\storvsc   start =  0

This system is now no-hydration compatible.
```

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

Не удалось подключиться/RDP/SSH

Не удается подключить/RDP/SSH из-за следующих ошибок:

Кнопка "Подключиться" с серым цветом на виртуальной машине
Кнопка VMConnect доступна

Подробные инструкции по устранению неполадок с RDP см. здесь.

Подробные инструкции по устранению неполадок SSH см. здесь.

Если кнопка "Подключиться" на виртуальной машине после отказа в Azure неактивна, и вы не подключены к Azure через VPN-подключение Express Route или VPN типа "сеть-сеть", то

Перейдите в виртуальную машину>Сетевые настройки, нажмите на имя требуемого сетевого интерфейса.
Перейдите к ip-конфигурациям, а затем выберите поле имени требуемой IP-конфигурации.
Чтобы включить общедоступный IP-адрес, нажмите кнопку "Включить".
Щелкните "Настройка необходимых параметров>Создать новый".
Введите имя общедоступного адреса, выберите параметры по умолчанию для номера SKU и назначения, а затем нажмите кнопку "ОК".
Теперь, чтобы сохранить внесенные изменения, нажмите кнопку "Сохранить".
Закройте панели и перейдите к разделу "Обзор " виртуальной машины для подключения или RDP.

Не удается открыть последовательную консоль после переключения на резервный компьютер с интерфейсом UEFI в Azure.

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

Если ОС машины — Red Hat или Oracle Linux версии 7.* или 8.0, выполните следующую команду на виртуальной машине Azure для переключения при отказе с правами root. Перезагрузите виртуальную машину после команды.
```
grub2-mkconfig -o /boot/efi/EFI/redhat/grub.cfg
```

Непредвиденное сообщение о завершении работы (идентификатор события 6008)

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

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

Не удается выбрать хранилище данных

Эта проблема возникает, когда не удается увидеть хранилище в портале Azure при попытке повторно защитить виртуальную машину, которая пережила отказ. Это связано с тем, что главный целевой объект не распознается как виртуальная машина в vCenters, добавленных в Azure Site Recovery.

Дополнительные сведения о повторной защите виртуальной машины см. в статье «Повторная защита и возврат рабочих нагрузок на локальный сайт после аварийного восстановления в Azure».

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

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

Замечание

Операции обнаружения и обновления структуры могут занять до 30 минут.

Регистрация главного целевого объекта Linux с cs завершается ошибкой TLS 35

Регистрация целевого элемента Azure Site Recovery на сервере конфигурации завершается сбоем из-за включения прокси-сервера с проверкой подлинности на целевом элементе.

Эта ошибка указывается следующими строками в журнале установки:

RegisterHostStaticInfo encountered exception config/talwrapper.cpp(107)[post] CurlWrapper Post failed : server : 10.38.229.221, port : 443, phpUrl : request_handler.php, secure : true, ignoreCurlPartialError : false with error: [at curlwrapperlib/curlwrapper.cpp:processCurlResponse:231]   failed to post request: (35) - SSL connect error.

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

На виртуальной машине сервера конфигурации откройте командную строку и проверьте параметры прокси-сервера с помощью следующих команд:

cat /etc/environment echo $http_proxy echo $https_proxy
Если выходные данные предыдущих команд показывают, что определены параметры http_proxy или https_proxy, используйте один из следующих методов, чтобы разблокировать связь master Target с сервером конфигурации:
- Скачайте средство PsExec.
- Используйте средство для доступа к контексту пользователя системы и определите, настроен ли прокси-адрес.
- Если прокси-сервер настроен, откройте Internet Explorer в контексте системного пользователя с помощью средства PsExec.
  
  psexec -s -i "%programfiles%\Internet Explorer\iexplore.exe"
- Чтобы убедиться, что главный целевой сервер может взаимодействовать с сервером конфигурации:
  - Измените параметры прокси-сервера в Internet Explorer, чтобы обойти IP-адрес главного целевого сервера через прокси-сервер.
    или
  - Отключите прокси-сервер на главном целевом сервере.

Дальнейшие шаги

Устранение неполадок подключения RDP к виртуальной машине Windows
Устранение неполадок подключения SSH к виртуальной машине Linux

Если вам нужна дополнительная помощь, отправьте запрос на страницу вопросов Microsoft Q&A для Site Recovery или оставьте комментарий в конце этого документа. У нас есть активное сообщество, которое должно быть в состоянии помочь вам.

Обратная связь

Были ли сведения на этой странице полезными?

Last updated on 2025-12-09