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


Известные проблемы: Azure Site Recovery в Azure Stack Hub

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

Максимальный размер диска: 1022 ГБ

При защите виртуальной машины Azure Site Recovery необходимо добавить еще 1 ГБ данных на существующий диск. Так как Azure Stack Hub имеет жесткое ограничение для максимального размера диска в 1023 ГБ, максимальный размер диска, защищенного Site Recovery, должен быть равен или меньше 1022.

При попытке защитить виртуальную машину с диском 1023 Гб происходит следующее поведение:

  • Включение защиты выполняется успешно, так как начальный диск только 1 ГБ создается и готов к использованию. На этом шаге отсутствует ошибка.

  • Репликация блокируется при синхронизации xx% и через некоторое время работоспособность реплика tion становится критической с ошибкой AzStackToAzStackSourceAgentDiskSourceAgentSlowResyncProgressOnPremToAzure. Ошибка возникает из-за того, что во время реплика tion Site Recovery пытается изменить размер начального диска до 1024 ГБ и записать в него. Эта операция завершается ошибкой, так как Azure Stack Hub не поддерживает диски размером 1024 ГБ.

    Снимок экрана: портал Azure с максимальной ошибкой диска.

  • Начальный диск, созданный для этого диска (в целевой подписке), по-прежнему имеет размер 1 ГБ, а журнал действий показывает несколько сбоев диска записи с сообщением об ошибке: значение "1024" параметра "disk.diskSizeGb" выходит за пределы диапазона. Значение "1024" должно быть от "1" до "1023" включительно.

    Снимок экрана: портал Azure с ошибками диска записи.

Текущее решение этой проблемы — создать новый диск (из 1022 ГБ или меньше), подключить его к исходной виртуальной машине, скопировать данные из диска 1023 ГБ в новый, а затем удалить диск размером 1023 ГБ из исходной виртуальной машины. После выполнения этой процедуры на виртуальной машине все диски меньше или равны 1022 ГБ, вы можете включить защиту с помощью Azure Site Recovery.

Повторная защита: доступные слоты дисков данных на (модуль)

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

  2. Начальное допустимое число дисков, которые повторно защищаются одновременно, равно 31. Размер (модуль) по умолчанию, созданного из элемента Marketplace, Standard_DS4_v2, который поддерживает до 32 дисков данных, а сам (модуль) использует один диск данных.

  3. Если сумма защищенных виртуальных машин превышает 31, выполните одно из следующих действий:

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

    Примечание.

    Мы не тестируем и проверяем большие номера SKU виртуальных машин для (модуль) виртуальной машины.

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

    Снимок экрана: Просмотр событий для Azure Site Recovery.

    Снимок экрана: журналы Azure Site Recovery.

    Найдите последнее предупреждение, чтобы определить проблему.

Версия ядра виртуальной машины Linux не поддерживается

  1. Проверьте версию ядра, выполнив команду uname -r.

    Снимок экрана: версия ядра Linux.

    Дополнительные сведения о поддерживаемых версиях ядра Linux см. в Azure для поддержка Azure матрицы.

  2. При поддержке версии ядра отработка отказа, которая приводит к перезапуску виртуальной машины, может привести к обновлению виртуальной машины отработки отказа до более новой версии ядра, которая может не поддерживаться. Чтобы избежать обновления из-за перезагрузки отработки отказа виртуальной машины, выполните команду sudo apt-mark hold linux-image-azure linux-headers-azure , чтобы обновить версию ядра.

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

    • Debian/Ubuntu: dpkg --list | grep linux-image

    На следующем рисунке показан пример виртуальной машины Ubuntu версии 5.4.0-1103-azure, который не поддерживается. После выполнения команды вы увидите поддерживаемую версию 5.4.0-1077-azure, которая уже установлена на виртуальной машине. С помощью этой информации можно выполнить откат к поддерживаемой версии.

    Снимок экрана: версия ядра виртуальной машины Ubuntu проверка.

  4. Откат до поддерживаемой версии ядра, выполнив следующие действия:

    1. Сначала создайте копию /etc/default/grub в случае ошибки, например sudo cp /etc/default/grub /etc/default/grub.bak.

    2. Затем измените /etc/default/grub , чтобы задать GRUB_DEFAULT предыдущей версии, которую вы хотите использовать. Возможно, у вас есть что-то похожее на GRUB_DEFAULT="Расширенные параметры для Ubuntu>, с Linux 5.4.0-1077-azure".

      Снимок экрана: откат версии ядра виртуальной машины Ubuntu.

    3. Нажмите кнопку "Сохранить", чтобы сохранить файл, а затем нажмите кнопку "Выйти".

    4. Выполните обновление sudo update-grub grub.

    5. Наконец, перезагрузите виртуальную машину и перейдите к поддерживаемой версии ядра.

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

    Снимок экрана: обновление агента мобильности проверка.

Повторная защита повторной синхронизации вручную еще не поддерживается

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

Существует два типа повторной синхронизации:

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

    Снимок экрана: автоматическая повторная синхронизация на портале

  • Повторная синхронизация вручную. Требуется действие пользователя для активации повторной синхронизации вручную и требуется в следующих экземплярах:

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

    • Отсутствует диск реплика на (модуль).

    • Запись реплика превышает емкость диска реплика на (модуль).

      Совет

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

Известные проблемы в автоматизации PowerShell

  • Если оставить $failbackPolicyName и $failbackExtensionName пустую или пустую, повторная защита может завершиться ошибкой. См. следующие примеры.

    Снимок экрана: снимок экрана виртуальной машины не удалось выполнить ошибку операции.

    Пример снимка экрана: ошибка второй операции на другой виртуальной машине.

  • Всегда укажите $failbackPolicyName и $failbackExtensionName, как показано в следующем примере:

    $failbackPolicyName = "failback-default-replication-policy"
    $failbackExtensionName = "default-failback-extension"
    $parameters = @{
        "properties" = @{
            "customProperties" = @{
                "instanceType" = "AzStackToAzStackFailback"
                "applianceId" = $applianceId
                "logStorageAccountId" = $LogStorageAccount.Id
                "policyName" = $failbackPolicyName
                "replicationExtensionName" = $failbackExtensionName
            }
        }
    }
    $result = Invoke-AzureRmResourceAction -Action "reprotect" ` -ResourceId $protectedItemId ` -Force -Parameters $parameters 
    

предупреждение агента служба

При реплика использовании нескольких виртуальных машин в заданиях Site Recovery может быть изменено состояние работоспособности защищенного элемента на предупреждение.

Снимок экрана: предупреждение об изменении работоспособности защищенного элемента.

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

Совет

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

Удаление (модуль) виртуальной машины (источника) блокирует удаление хранилища (целевого объекта)

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

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

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