Share via


Problemas conocidos: Azure Site Recovery en Azure Stack Hub

Precaución

En este artículo se hace referencia a CentOS, una distribución de Linux que está cerca del estado Fin de vida (EOL). Tenga en cuenta su uso y plan en consecuencia. Para obtener más información, consulte la guía de fin de vida de CentOS.

En este artículo se describen los problemas conocidos de Azure Site Recovery en Azure Stack Hub. Use las secciones siguientes para más información sobre los problemas conocidos actuales y las limitaciones de Azure Site Recovery en Azure Stack Hub.

El tamaño máximo de disco admitido es de 1022 GB

Al proteger una máquina virtual, Azure Site Recovery debe agregar más de 1 GB de datos a un disco existente. Dado que Azure Stack Hub tiene una limitación difícil para el tamaño máximo de un disco a 1023 GB, el tamaño máximo de un disco protegido por Site Recovery debe ser igual o menor que 1022.

Al intentar proteger una máquina virtual con un disco de 1023 Gb, se produce el siguiente comportamiento:

  • Habilitar la protección se realiza correctamente como un disco de inicialización de solo 1 GB se crea y está listo para su uso. No hay ningún error en este paso.

  • La replicación se bloquea al xx % Sincronizado y después de un tiempo, el estado de replicación se convierte en Crítico con el error AzStackToAzStackSourceDiskSourceAgentSlowResyncProgressOnPremToAzure. El error se produce porque, durante la replicación, Site Recovery intenta cambiar el tamaño del disco de inicialización a 1024 GB y escribir en él. Esta operación produce un error, ya que Azure Stack Hub no admite discos de 1024 GB.

    Captura de pantalla de Azure Portal que muestra el error máximo de disco.

  • El disco de inicialización creado para este disco (en la suscripción de destino) sigue teniendo un tamaño de 1 GB y el registro de actividadmuestra algunos errores de disco de escritura con el mensaje de error El valor "1024" del parámetro "disk.diskSizeGb" está fuera del intervalo. El valor '1024' debe estar comprendido entre '1' y '1023' inclusivo.

    Captura de pantalla de Azure Portal en la que se muestran errores de disco de escritura.

La solución alternativa actual para este problema es crear un nuevo disco (de 1022 GB o menos), conectarlo a la máquina virtual de origen, copiar los datos del disco de 1023 GB en el nuevo y, a continuación, quitar el disco de 1023 GB de la máquina virtual de origen. Una vez hecho este procedimiento, y la máquina virtual tiene todos los discos más pequeños o iguales a 1022 GB, puede habilitar la protección mediante Azure Site Recovery.

Reprotección: ranuras de disco de datos disponibles en el dispositivo

  1. Asegúrese de que la máquina virtual del dispositivo tiene suficientes ranuras de disco de datos, ya que los discos de réplica para la reprotección están conectados al dispositivo.

  2. El número de discos permitido iniciales que se vuelven a proteger al mismo tiempo es 31. El tamaño predeterminado del dispositivo creado a partir del elemento de Marketplace es Standard_DS4_v2, que admite hasta 32 discos de datos y el propio dispositivo usa un disco de datos.

  3. Si la suma de las máquinas virtuales protegidas es mayor que 31, realice una de las siguientes acciones:

    • Divida las máquinas virtuales que requieren reprotección en grupos más pequeños para asegurarse de que el número de discos que se vuelven a proteger al mismo tiempo no supera el número máximo de discos de datos que admite el dispositivo.
    • Aumente el tamaño de la máquina virtual del dispositivo de Azure Site Recovery.

    Nota

    No se prueban ni validan las SKU de máquina virtual de gran tamaño para la máquina virtual del dispositivo.

  4. Si intenta volver a proteger una máquina virtual, pero no hay suficientes ranuras en el dispositivo para contener los discos de replicación, se muestra el mensaje de error Se muestra un error interno . Puede comprobar el número de discos de datos actualmente en el dispositivo o iniciar sesión en el dispositivo, ir a Visor de eventos y abrir registros para Azure Site Recovery en Registros de aplicaciones y servicios:

    Captura de pantalla de ejemplo de Visor de eventos para Azure Site Recovery.

    Captura de pantalla de ejemplo de los registros de Azure Site Recovery.

    Busque la advertencia más reciente para identificar el problema.

No se admite la versión del kernel de máquina virtual Linux

  1. Para comprobar la versión del kernel, ejecute el comando uname -r.

    Captura de pantalla de ejemplo de la versión del kernel de Linux.

    Para más información sobre las versiones de kernel de Linux admitidas, consulte Azure to Soporte técnico de Azure matrix (Matriz de Azure para Soporte técnico de Azure).

  2. Con una versión de kernel compatible, la conmutación por error, que hace que la máquina virtual realice un reinicio, puede hacer que la máquina virtual conmutada por error se actualice a una versión más reciente del kernel que puede que no se admita. Para evitar una actualización debido a un reinicio de la máquina virtual de conmutación por error, ejecute el comando sudo apt-mark hold linux-image-azure linux-headers-azure para que la actualización de la versión del kernel pueda continuar.

  3. En el caso de una versión del kernel no compatible, compruebe si hay una versión anterior del kernel en la que puede revertir; para ello, ejecute el comando adecuado para la máquina virtual:

    • Debian y Ubuntu: dpkg --list | grep linux-image
    • RedHat/CentOS/RHEL: rpm -qa kernel

    En la imagen siguiente se muestra un ejemplo en una máquina virtual Ubuntu en la versión 5.4.0-1103-azure, que no es compatible. Después de ejecutar el comando, puede ver una versión compatible, 5.4.0-1077-azure, que ya está instalada en la máquina virtual. Con esta información, puede revertir a la versión compatible.

    Captura de pantalla de ejemplo de una comprobación de la versión del kernel de máquina virtual Ubuntu.

  4. Revierte a una versión de kernel compatible mediante estos pasos:

    1. En primer lugar, realice una copia de /etc/default/grub en caso de que se produzca un error; por ejemplo, sudo cp /etc/default/grub /etc/default/grub.bak.

    2. A continuación, modifique /etc/default/grub para establecer GRUB_DEFAULT en la versión anterior que desea usar. Es posible que tenga algo similar a GRUB_DEFAULT="Opciones avanzadas para Ubuntu Ubuntu>, con Linux 5.4.0-1077-azure".

      Captura de pantalla de ejemplo de una reversión de la versión del kernel de máquina virtual Ubuntu.

    3. Seleccione Guardar para guardar el archivo y, a continuación, seleccione Salir.

    4. Ejecute sudo update-grub para actualizar el grub.

    5. Por último, reinicie la máquina virtual y continúe con la reversión a una versión de kernel compatible.

  5. Si no tiene una versión anterior del kernel a la que puede revertir, espere a que se actualice el agente de movilidad para que se pueda admitir el kernel. La actualización se completa automáticamente, si está lista y puede comprobar la versión en el portal para confirmar lo siguiente:

    Captura de pantalla de ejemplo de la comprobación de actualizaciones del agente de movilidad.

Todavía no se admite volver a proteger la resincronización manual

Una vez completado el trabajo de re-protección, la replicación se inicia en secuencia. Durante la replicación, puede haber casos que requieran una resincronización, lo que significa que se desencadena una nueva replicación inicial para sincronizar todos los cambios.

Hay dos tipos de resincronización:

  • Resincronización automática. No requiere ninguna acción de usuario y se realiza automáticamente. Los usuarios pueden ver algunos eventos que se muestran en el portal:

    Captura de pantalla de ejemplo de resincronización automática en el portal Usuarios.

  • Resincronización manual. Requiere que la acción del usuario desencadene la resincronización manualmente y se necesite en las instancias siguientes:

    • Falta la cuenta de almacenamiento elegida para la reprotección.

    • Falta el disco de replicación en el dispositivo.

    • La escritura de replicación supera la capacidad del disco de replicación en el dispositivo.

      Sugerencia

      También puede encontrar los motivos de resincronización manual en la hoja de eventos para ayudarle a decidir si se requiere una resincronización manual.

Problemas conocidos de la automatización de PowerShell

  • Si deja $failbackPolicyName y $failbackExtensionName vacía o null, se puede producir un error en la re-protección. Consulte los siguientes ejemplos:

    Captura de pantalla de ejemplo de una máquina virtual que no pudo realizar el error de operación.

    Captura de pantalla de ejemplo del error de segunda operación en una máquina virtual diferente.

  • Especifique siempre y $failbackPolicyName$failbackExtensionName, como se muestra en el ejemplo siguiente:

    $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 
    

Advertencia del agente de servicio Mobility

Al replicar varias máquinas virtuales, es posible que vea que el estado del elemento protegido ha cambiado a Error de advertencia en los trabajos de Site Recovery.

Captura de pantalla de ejemplo de la advertencia de cambio de estado del elemento protegido.

Este mensaje de error solo debe ser una advertencia y no es un problema de bloqueo para los procesos reales de replicación o conmutación por error.

Sugerencia

Puede comprobar el estado de la máquina virtual correspondiente para asegurarse de que es correcto.

La eliminación de la máquina virtual del dispositivo (origen) bloquea la eliminación del almacén (destino)

Para eliminar el almacén de Azure Site Recovery en el destino, primero debe quitar todas las máquinas virtuales protegidas. Si elimina primero la máquina virtual del dispositivo, el almacén de Site Recovery bloquea la eliminación de los recursos protegidos e intenta eliminar el propio almacén también produce un error. También se produce un error al eliminar el grupo de recursos y la única manera de quitar el almacén es eliminando la suscripción de usuario de Azure Stack Hub en la que se crea el almacén.

Para evitar este problema, asegúrese de quitar primero la protección de todos los elementos del almacén antes de eliminar la máquina virtual del dispositivo. Esto permite que el almacén complete la limpieza de recursos en el dispositivo (lado de origen). Una vez quitados los elementos protegidos, puede eliminar el almacén y quitar la máquina virtual del dispositivo.

Pasos siguientes