Устранение ошибок репликации виртуальных машин из Azure в Azure

Статья
03/07/2024

Внимание

Эта статья ссылается на CentOS, дистрибутив Linux, который приближается к состоянию конца жизни (EOL). Обратите внимание на использование и план соответствующим образом. Дополнительные сведения см. в руководстве centOS End Of Life.

В этой статье описывается устранение распространенных ошибок в Azure Site Recovery во время репликации и восстановления виртуальных машин Azure из одного региона в другой. Дополнительные сведения о поддерживаемых конфигурациях см. в статье Azure Site Recovery support matrix for replicating from Azure to Azure (Матрица поддержки Azure Site Recovery для репликации виртуальных машин из Azure в Azure).

Проблемы с квотами ресурсов Azure (код ошибки 150097)

Убедитесь, что вашей подписки есть разрешение на создание виртуальных машин Azure в целевом регионе, который планируется использовать в качестве региона аварийного восстановления (DR). Вашей подписке необходима соответствующая квота для создания виртуальных машин требуемых размеров. По умолчанию Site Recovery выбирает размер целевой виртуальной машины, который совпадает с размером исходной виртуальной машины. Если соответствующий размер недоступен, Site Recovery автоматически выбирает наиболее близкий к нему доступный размер.

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

Replication couldn't be enabled for the virtual machine <VmName>.

Возможные причины

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

Устранение проблемы

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

Если целевое расположение имеет ограничение емкости, отключите репликацию и в этом расположении. После этого включите его в другом расположении, где подписка имеет достаточную квоту, чтобы создать виртуальные машины нужного размера.

Доверенные корневые сертификаты (код ошибки 151066)

Если на виртуальной машине присутствуют не все новейшие доверенные корневые сертификаты, задание по включению репликации для Site Recovery может завершиться ошибкой. Без этих сертификатов проверка подлинности и авторизация вызовов службы Site Recovery из виртуальной машины завершатся сбоем.

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

Site Recovery configuration failed.

Возможная причина

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

Устранение проблемы

Windows

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

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

Чтобы убедиться, что проблема устранена, перейдите на веб-сайт login.microsoftonline.com из браузера на виртуальной машине.

Дополнительные сведения см. в статье Настройка доверенных корневых сертификатов и запрещенных сертификатов.

Linux

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

Так как SUSE Linux использует символические ссылки (симлинки), чтобы получить список сертификатов, выполните следующие действия.

Войдите как привилегированный пользователь. Хэш-символ (#) — это командная строка по умолчанию.
Для изменения каталога выполните следующую команду.

cd /etc/ssl/certs
Проверьте, есть ли на компьютере корневой сертификат, выпущенный центром сертификации Symantec.

ls VeriSign_Class_3_Public_Primary_Certification_Authority_G5.pem
- Если такой сертификат не найден, выполните следующую команду, чтобы загрузить его. Проверьте его на наличие ошибок, а затем выполните рекомендуемые действия для устранения сетевых сбоев.
  
  wget https://docs.broadcom.com/docs-and-downloads/content/dam/symantec/docs/other-resources/verisign-class-3-public-primary-certification-authority-g5-en.pem -O VeriSign_Class_3_Public_Primary_Certification_Authority_G5.pem
Проверьте, есть ли на компьютере корневой сертификат, выпущенный центром сертификации Baltimore.

ls Baltimore_CyberTrust_Root.pem
- Если такой сертификат не найден, выполните следующую команду, чтобы загрузить его.
  
  wget https://www.digicert.com/CACerts/BaltimoreCyberTrustRoot.crt.pem -O Baltimore_CyberTrust_Root.pem
Проверьте, есть ли на компьютере сертификат DigiCert_Global_Root_CA.

ls DigiCert_Global_Root_CA.pem
- Если такой сертификат не найден, выполните следующую команду, чтобы загрузить его.
```
wget http://www.digicert.com/CACerts/DigiCertGlobalRootCA.crt

openssl x509 -in DigiCertGlobalRootCA.crt -inform der -outform pem -out DigiCert_Global_Root_CA.pem
```
Чтобы обновить хэши субъектов сертификата для загруженных сертификатов, запустите сценарий повторного хэширования.

c_rehash

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

ls -l | grep Baltimore

lrwxrwxrwx 1 root root   29 Jan  8 09:48 3ad48a91.0 -> Baltimore_CyberTrust_Root.pem

-rw-r--r-- 1 root root 1303 Jun  5  2014 Baltimore_CyberTrust_Root.pem

ls -l | grep VeriSign_Class_3_Public_Primary_Certification_Authority_G5

-rw-r--r-- 1 root root 1774 Jun  5  2014 VeriSign_Class_3_Public_Primary_Certification_Authority_G5.pem

lrwxrwxrwx 1 root root   62 Jan  8 09:48 facacbc6.0 -> VeriSign_Class_3_Public_Primary_Certification_Authority_G5.pem

ls -l | grep DigiCert_Global_Root

lrwxrwxrwx 1 root root   27 Jan  8 09:48 399e7759.0 -> DigiCert_Global_Root_CA.pem

-rw-r--r-- 1 root root 1380 Jun  5  2014 DigiCert_Global_Root_CA.pem

Создайте копию файла VeriSign_Class_3_Public_Primary_Certification_Authority_G5.pem и замените ее имя на b204d74a.0:

cp VeriSign_Class_3_Public_Primary_Certification_Authority_G5.pem b204d74a.0
Создайте копию файла Baltimore_CyberTrust_Root.pem и замените ее имя на 653b494a.0:

cp Baltimore_CyberTrust_Root.pem 653b494a.0
Создайте копию файла DigiCert_Global_Root_CA.pem и замените ее имя на 3513523f.0:

cp DigiCert_Global_Root_CA.pem 3513523f.0

Убедитесь в наличии файлов.

ls -l 653b494a.0 b204d74a.0 3513523f.0

-rw-r--r-- 1 root root 1774 Jan  8 09:52 3513523f.0

-rw-r--r-- 1 root root 1303 Jan  8 09:52 653b494a.0

-rw-r--r-- 1 root root 1774 Jan  8 09:52 b204d74a.0

Исходящие URL-адреса или диапазоны IP-адресов (код ошибки 151037 или 151072)

Чтобы реплика Site Recovery заработала, от виртуальной машины требуется исходящее подключение для конкретного URL-адреса. Если виртуальная машина находится за брандмауэром или использует правила группы безопасности сети (NSG) для управления исходящими подключениями, могут возникнуть следующие проблемы. Хотя мы продолжаем поддерживать исходящий доступ через URL-адреса, использование списка разрешенных диапазонов IP-адресов больше не поддерживается.

Возможные причины

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

Устранение проблемы

Если вы используете настраиваемый DNS-сервер, обеспечьте его доступность из региона аварийного восстановления.

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

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

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

Примечание.

При использовании частных конечных точек убедитесь, что виртуальные машины могут разрешать частные записи DNS.

com-error.

Проблема 2. Сбой при выполнении настройки Site Recovery (151196)

Возможная причина

Не удается подключиться к конечным точкам IP4 удостоверения и проверки подлинности Microsoft 365.

Устранение проблемы

Обеспечьте системе Azure Site Recovery доступ для выполнения проверки подлинности диапазонов IP-адресов Microsoft 365. Если вы используете правила группы безопасности сети Azure (NSG) или прокси-сервер брандмауэра для управления исходящим сетевым подключением на виртуальной машине, убедитесь, что вы используете правило NSG на основе тега службы Microsoft Entra для предоставления доступа к идентификатору Microsoft Entra ID. Мы больше не поддерживаем правила NSG на основе IP-адресов.

Проблема 3. Сбой при выполнении настройки Site Recovery (151197)

Возможная причина

Не удается подключиться к конечным точкам службы Azure Site Recovery.

Устранение проблемы

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

Проблема 4. Сбой репликации при использовании сетевым трафиком локального прокси-сервера (151072)

Возможная причина

Пользовательские параметры прокси-сервера недопустимы, или агенту службы "Мобильность" не удается автоматически определить параметры прокси-сервера из Internet Explorer (IE).

Устранение проблемы

Агент службы Mobility Service обнаруживает настройки прокси-сервера из Internet Explorer в ОС Windows и в каталоге /etc/environment в ОС Linux.
Если вы предпочитаете устанавливать прокси-сервер только для службы "Мобильность", данные прокси-сервера можно внести в файл ProxyInfo.conf, расположенный по адресу:
- Linux: /usr/local/InMage/config/
- Windows: C:\ProgramData\Microsoft Azure Site Recovery\Config
Файл ProxyInfo.conf должен содержать параметры прокси-сервера в таком формате INI.
```
[proxy]
Address=http://1.2.3.4
Port=567
```

Примечание.

Агент службы "Мобильность" поддерживает только прокси-серверы, которые не прошли проверку подлинности.

Дополнительные сведения

Чтобы указать необходимые URL-адреса или диапазоны IP-адресов, следуйте указаниям в статье Сети для репликации Azure — Azure.

Диск не найден в виртуальной машине (код ошибки 150039)

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

Azure data disk <DiskName> <DiskURI> with logical unit number <LUN> <LUNValue> was not mapped to a corresponding disk being reported from within the VM that has the same LUN value.

Возможные причины

Новый диск с данными был подключен к виртуальной машине, но не был инициализирован.
Диск с данными в виртуальной машине неправильно сообщает значение логического номера устройства (LUN), с использованием которого он был подключен к виртуальной машине.

Устранение проблемы

Убедитесь, что диски с данными инициализированы, а затем повторите операцию.

Windows: Подключение и инициализация нового диска.
Linux: Инициализация нового диска данных в Linux.

Если проблема не исчезнет, обратитесь в службу поддержки.

Для защиты доступны несколько дисков (код ошибки 153039)

Возможные причины

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

Устранение проблемы

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

Защита дисков

Откройте Реплицированные элементы>Имя виртуальной машины>Диски.
Выберите незащищенный диск, а затем нажмите Включить репликацию.

Закрытие предупреждения

Откройте Реплицированные элементы>Имя виртуальной машины.
Выберите предупреждение в разделе Обзор и нажмите кнопку OK.

Удаление виртуальной машины из хранилища сопровождается информационным сообщением (код ошибки 150225)

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

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

Предупреждение

Если вы не выполняете очистку:

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

Устранение проблемы

Примечание.

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

Удалите блокировку на виртуальной машине или группе ресурсов виртуальной машины. Например, на следующем изображении необходимо удалить блокировку ресурса на виртуальной машине MoveDemo:
Загрузите скрипт, чтобы удалить устаревшую конфигурацию Site Recovery.
Запустите скрипт Cleanup-stale-asr-config-Azure-VM.ps1. Укажите идентификатор подписки, группу ресурсов виртуальной машины и имя виртуальной машины в качестве параметров.
Если появится запрос на ввод учетных данных Azure, укажите их. Затем убедитесь, что сценарий выполняется без сбоев.

Репликация не включена на виртуальной машине с устаревшими ресурсами (код ошибки 150226)

Возможные причины

Виртуальная машина имеет устаревшую конфигурацию, оставшуюся от предыдущей защиты Site Recovery.

Устаревшая конфигурация может возникнуть на виртуальной машине Azure, если вы включили репликацию для виртуальной машины Azure с помощью Site Recovery, а затем:

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

Устранение проблемы

Примечание.

Удалите блокировку на виртуальной машине или группе ресурсов виртуальной машины. Например, на следующем изображении необходимо удалить блокировку ресурса на виртуальной машине MoveDemo:
Загрузите скрипт, чтобы удалить устаревшую конфигурацию Site Recovery.
Запустите скрипт Cleanup-stale-asr-config-Azure-VM.ps1. Укажите идентификатор подписки, группу ресурсов виртуальной машины и имя виртуальной машины в качестве параметров.
Если появится запрос на ввод учетных данных Azure, укажите их. Затем убедитесь, что сценарий выполняется без сбоев.

Не удается выбрать виртуальную машину или группу ресурсов в задании по включению репликации

Проблема 1. Группа ресурсов и исходная виртуальная машина находятся в разных расположениях

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

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

Проблема 2. Группа ресурсов не находится в выбранной подписке

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

Проблема 3. Устаревшая конфигурация

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

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

Устранение проблемы

Примечание.

Обновите модуль AzureRM.Resources перед использованием упомянутого ниже скрипта. Во время выполнения этих действий Site Recovery не удаляет исходную виртуальную машину и не влияет на нее каким бы то ни было образом.

Удалите блокировку на виртуальной машине или группе ресурсов виртуальной машины, если она имеется. Например, на следующем изображении необходимо удалить блокировку ресурса на виртуальной машине MoveDemo:
Загрузите скрипт, чтобы удалить устаревшую конфигурацию Site Recovery.
Запустите скрипт Cleanup-stale-asr-config-Azure-VM.ps1. Укажите идентификатор подписки, группу ресурсов виртуальной машины и имя виртуальной машины в качестве параметров.
Если появится запрос на ввод учетных данных Azure, укажите их. Затем убедитесь, что сценарий выполняется без сбоев.

Не удается выбрать виртуальную машину для защиты

Возможная причина

На виртуальной машине установлено расширение, в котором произошел сбой или которое не отвечает на запросы.

Устранение проблемы

Выберите Виртуальные машины>Параметры>Расширения и проверьте наличие расширений в состоянии сбоя. Удалите расширение в состоянии сбоя и повторите попытку применить защиту к виртуальной машине.

Недопустимое состояние подготовки виртуальной машины (код ошибки 150019)

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

На портале Azure в разделе Все службы выберите Обозреватель ресурсов.
Разверните список Подписки и выберите нужную подписку.
Разверните список ResourceGroups и выберите группу ресурсов, к которой относится виртуальная машина.
Разверните список ресурсов и выберите виртуальную машину.
Проверьте значение в поле provisioningState в представлении экземпляра справа.

Устранение проблемы

Если в поле provisioningState отображается значение Сбой, обратитесь в службу поддержки и предоставьте необходимые сведения для устранения проблемы.
Если в поле provisioningState отображается значение Обновление, возможно, началось развертывание другого расширения. Проверьте, выполняются ли на виртуальной машине какие-либо операции, дождитесь их завершения и еще раз попытайтесь выполнить задание Site Recovery для включения репликации.

Не удается выбрать целевую виртуальную машину

Проблема 1. Виртуальная машина подключена к сети, которая уже сопоставлена с целевой сетью.

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

Список выбора сети недоступен.

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

При отключении репликации виртуальной машины сетевое сопоставление не удаляется. Сопоставлять необходимо удалить из хранилища Службы восстановления, где находилась защищенная виртуальная машина. Выберите хранилище Служб восстановления и откройте Manage>Инфраструктура Site Recovery>Для виртуальных машин Azure>Сетевое сопоставление.

Удаление сетевого сопоставления.

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

Изменение сетевого сопоставления.

COM+ или VSS (код ошибки 151025)

При возникновении ошибки в службе COM+ или службе теневого копирования томов (VSS) отображается следующее сообщение.

Site Recovery extension failed to install.

Возможные причины

Служба системных приложений COM+ отключена.
Отключена служба теневого копирования томов (VSS).

Устранение проблемы

Настройте службу системных приложений COM+ и службу теневого копирования томов для автоматического режима запуска или запуска вручную.

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

Неподдерживаемый размер управляемого диска (код ошибки 150172)

При возникновении этой ошибки отображается следующее сообщение.

Protection couldn't be enabled for the virtual machine as it has <DiskName> with size <DiskSize> that is lesser than the minimum supported size 1024 MB.

Возможная причина

Размер диска меньше поддерживаемого размера, равного 1024 МБ

Устранение проблемы

Убедитесь, что размер диска поддерживается, а затем повторите операцию.

Защита не включена, если в GRUB используется имя устройства (код ошибки 151126)

Возможные причины

Файлы конфигурации GRUB для Linux (/boot/grub/menu.lst, /boot/grub/grub.cfg, /boot/grub2/grub.cfg и /etc/default/grub) могут указывать фактические имена устройств для параметров root и resume вместо значений универсального уникального идентификатора (UUID). Site Recovery требуются значения UUID, так как имена устройств могут изменяться. После перезагрузки при отработке отказа имя виртуальной машины может измениться, что приведет к возникновению проблем.

Ниже приведены примеры строк из файлов GRUB, в которых вместо требуемых значений UUID отображаются имена устройств.

Файл /boot/grub2/grub.cfg:

linux /boot/vmlinuz-3.12.49-11-default root=/dev/sda2 ${extra_cmdline} resume=/dev/sda1 splash=silent quiet showopts
Файл /boot/grub/menu.lst:

kernel /boot/vmlinuz-3.0.101-63-default root=/dev/sda2 resume=/dev/sda1 splash=silent crashkernel=256M-:128M showopts vga=0x314

Устранение проблемы

Замените имя каждого устройства соответствующим значением UUID.

Найдите UUID устройства, выполнив команду blkid <device name>. Например:

blkid /dev/sda1
/dev/sda1: UUID="6f614b44-433b-431b-9ca1-4dd2f6f74f6b" TYPE="swap"
blkid /dev/sda2
/dev/sda2: UUID="62927e85-f7ba-40bc-9993-cc1feeb191e4" TYPE="ext3"

Замените имя устройства на его UUID в формате root=UUID=<UUID> и resume=UUID=<UUID>. Например, после замены строка из файла /Boot/GRUB/menu.lst будет выглядеть следующим образом.

kernel /boot/vmlinuz-3.0.101-63-default root=UUID=62927e85-f7ba-40bc-9993-cc1feeb191e4 resume=UUID=6f614b44-433b-431b-9ca1-4dd2f6f74f6b splash=silent crashkernel=256M-:128M showopts vga=0x314
Повторите попытку применения защиты.

Сбой защиты из-за того, что устройство GRUB не существует (код ошибки 151124)

Возможная причина

Файлы конфигурации GRUB (/boot/grub/menu.lst, /boot/grub/grub.cfg, /boot/grub2/grub.cfg и /etc/default/grub) могут содержать параметры rd.lvm.lv или rd_LVM_LV. Эти параметры определяют устройства диспетчера логических томов (LVM), которые должны быть обнаружены во время загрузки. Если эти устройства LVM не существуют, защищенная система не загрузится и зависнет в процессе загрузки. Эта же проблема также будет наблюдаться на виртуальной машине отработки отказа. Рассмотрим несколько примеров.

Файл /boot/grub2/grub.cfg на RHEL7:

linux16 /vmlinuz-3.10.0-957.el7.x86_64 root=/dev/mapper/rhel_mup--rhel7u6-root ro crashkernel=128M\@64M rd.lvm.lv=rootvg/root rd.lvm.lv=rootvg/swap rhgb quiet LANG=en_US.UTF-8
Файл /etc/default/grub на RHEL7:

GRUB_CMDLINE_LINUX="crashkernel=auto rd.lvm.lv=rootvg/root rd.lvm.lv=rootvg/swap rhgb quiet
Файл /boot/grub/menu.lst на RHEL6:

kernel /vmlinuz-2.6.32-754.el6.x86_64 ro root=UUID=36dd8b45-e90d-40d6-81ac-ad0d0725d69e rd_NO_LUKS LANG=en_US.UTF-8 rd_NO_MD SYSFONT=latarcyrheb-sun16 crashkernel=auto rd_LVM_LV=rootvg/lv_root KEYBOARDTYPE=pc KEYTABLE=us rd_LVM_LV=rootvg/lv_swap rd_NO_DM rhgb quiet

В каждом примере GRUB должен обнаруживать два LVM устройства с именами root и swap из группы томов rootvg.

Устранение проблемы

Если устройство LVM не существует, создайте его или удалите соответствующие параметры из файлов конфигурации GRUB. Затем повторите попытку включения защиты.

Обновление службы "Мобильность" завершено с предупреждениями (код ошибки 151083)

Служба "Мобильность" Site Recovery состоит из множества компонентов, один из которых — драйвер-фильтр. Драйвер-фильтр загружается в системную память только во время перезагрузки системы. Всякий раз, когда обновление службы "Мобильность" включает изменения драйвера фильтра, компьютер обновляется, но по-прежнему продолжает отображаться предупреждение о том, что некоторые исправления нуждаются в перезагрузке. Это предупреждение появляется, потому что исправления драйвера фильтра могут вступить в силу только после загрузки нового драйвера фильтра, которое происходит только при перезагрузке.

Примечание.

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

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

Защита не включается, если существует управляемый диск реплики

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

Возможная причина

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

Устранение проблемы

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

Не удалось включить защиту, так как установщик не может найти корневой диск (код ошибки 151137).

Эта ошибка возникает для компьютеров Linux, на которых диск ОС шифруется с помощью Шифрования дисков Azure (ADE). Это проблема проявляется только для агента версии 9.35.

Возможные причины

Установщику не удалось найти корневой диск, на котором размещена корневая файловая система.

Устранение проблемы

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

Найдите биты агента в каталоге /var/lib/waagent на компьютерах RHEL и CentOS с помощью следующей команды:

# find /var/lib/ -name Micro\*.gz

Ожидаемые выходные данные:

/var/lib/waagent/Microsoft.Azure.RecoveryServices.SiteRecovery.LinuxRHEL7-1.0.0.9139/UnifiedAgent/Microsoft-ASR_UA_9.35.0.0_RHEL7-64_GA_30Jun2020_release.tar.gz
Создайте новый каталог и измените каталог на этот новый каталог.
Извлеките файл агента, указанный в первом шаге, с помощью следующей команды:

tar -xf <Tar Ball File>
Откройте файл prereq_check_installer.json и удалите следующие строки. Затем сохраните файл.
```
   {
      "CheckName": "SystemDiskAvailable",
      "CheckType": "MobilityService"
   },
```
Вызов установщика с помощью команды:

./install -d /usr/local/ASR -r MS -q -v Azure
Если запуск установщика будет завершен успешно, повторите попытку выполнения задания защиты.

Устранение неполадок и обработка изменений времени на реплицированных серверах

Эта ошибка возникает, когда время на исходном компьютере смещается вперед, а затем в течение короткого периода исправляет изменение, возвращаясь назад. Можно не заметить изменения, так как время исправляется очень быстро.

Исправление. Чтобы устранить эту проблему, дождитесь совпадения системного времени с соответствующим моментом в будущем. Другой вариант — отключить и включить репликацию еще раз, что возможно только для прямой репликации (данные реплицируются из основного в дополнительный регион) и неприменимо для обратной репликации (данные реплицируются из дополнительного в основной регион).

Следующие шаги

Репликация виртуальных машин Azure в другой регион Azure.

Устранение ошибок репликации виртуальных машин из Azure в Azure

Проблемы с квотами ресурсов Azure (код ошибки 150097)

Возможные причины

Устранение проблемы

Доверенные корневые сертификаты (код ошибки 151066)

Возможная причина

Устранение проблемы

Windows

Linux

Исходящие URL-адреса или диапазоны IP-адресов (код ошибки 151037 или 151072)

Возможные причины

Устранение проблемы

Проблема 2. Сбой при выполнении настройки Site Recovery (151196)

Возможная причина

Устранение проблемы

Проблема 3. Сбой при выполнении настройки Site Recovery (151197)

Возможная причина

Устранение проблемы

Проблема 4. Сбой репликации при использовании сетевым трафиком локального прокси-сервера (151072)

Возможная причина

Устранение проблемы

Дополнительные сведения

Диск не найден в виртуальной машине (код ошибки 150039)

Возможные причины

Устранение проблемы

Для защиты доступны несколько дисков (код ошибки 153039)

Возможные причины

Устранение проблемы

Защита дисков

Закрытие предупреждения

Удаление виртуальной машины из хранилища сопровождается информационным сообщением (код ошибки 150225)

Устранение проблемы

Репликация не включена на виртуальной машине с устаревшими ресурсами (код ошибки 150226)

Возможные причины

Устранение проблемы

Не удается выбрать виртуальную машину или группу ресурсов в задании по включению репликации

Проблема 1. Группа ресурсов и исходная виртуальная машина находятся в разных расположениях

Проблема 2. Группа ресурсов не находится в выбранной подписке

Проблема 3. Устаревшая конфигурация

Устранение проблемы

Не удается выбрать виртуальную машину для защиты

Возможная причина

Устранение проблемы

Недопустимое состояние подготовки виртуальной машины (код ошибки 150019)

Устранение проблемы

Не удается выбрать целевую виртуальную машину

Проблема 1. Виртуальная машина подключена к сети, которая уже сопоставлена с целевой сетью.

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

COM+ или VSS (код ошибки 151025)

Возможные причины

Устранение проблемы

Неподдерживаемый размер управляемого диска (код ошибки 150172)

Возможная причина

Устранение проблемы

Защита не включена, если в GRUB используется имя устройства (код ошибки 151126)

Возможные причины

Устранение проблемы

Сбой защиты из-за того, что устройство GRUB не существует (код ошибки 151124)

Возможная причина

Устранение проблемы

Обновление службы "Мобильность" завершено с предупреждениями (код ошибки 151083)

Защита не включается, если существует управляемый диск реплики

Возможная причина

Устранение проблемы

Не удалось включить защиту, так как установщик не может найти корневой диск (код ошибки 151137).

Возможные причины

Устранение проблемы

Устранение неполадок и обработка изменений времени на реплицированных серверах

Следующие шаги

Дополнительные ресурсы