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


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

Внимание!

В этой статье содержится ссылка на CentOS, дистрибутив Linux, который находится на грани окончания срока службы (EOL). Пожалуйста, рассмотрите использование и спланируйте соответствующим образом. Дополнительные сведения см. в руководстве по окончании жизненного циклов CentOS.

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

Максимальный поддерживаемый размер диска — 1022 ГБ.

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

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

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

  • Репликация блокируется на xx % Synchronized , и через некоторое время работоспособность репликации становится критической с ошибкой AzStackToAzStackSourceAgentDiskSourceAgentSlowResyncProgressOnPremToAzure. Ошибка возникает из-за того, что во время репликации 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. Если вы пытаетесь повторно защитить виртуальную машину, но на (модуль) недостаточно слотов для хранения дисков репликации, отобразится сообщение об ошибке Внутренняя ошибка. Вы можете проверка количество дисков данных, которые в настоящее время находятся на (модуль), или войти в (модуль), перейти к Просмотр событий и открыть журналы для Site Recovery Azure в разделе Журналы приложений и служб:

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

    Пример снимка экрана: журналы Site Recovery Azure.

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

Версия ядра виртуальной машины 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
    • RedHat/CentOS/RHEL: rpm -qa kernel

    На следующем рисунке показан пример виртуальной машины 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 или null, повторная защита может завершиться ошибкой. См. следующие примеры.

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

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

  • Всегда указывайте $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, в которой создается хранилище.

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

Дальнейшие действия