Problemas conocidos: Azure Site Recovery en Azure Stack Hub

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 estricta 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 inferior a 1022.

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

• La habilitación de la protección se realiza correctamente porque solo se crea un disco de inicialización de 1 GB 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 la replicación se convierte en Crítico con el error AzStackToAzStackSourceAgentDiskAgentSlowResyncProgressOnPremToAzure. 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.

  

• 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 actividad muestra 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'.

  

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 al 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 inicial permitido de discos 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 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 ha producido un error interno. Puede comprobar el número de discos de datos que hay actualmente en el dispositivo o iniciar sesión en el dispositivo, ir a Visor de eventos y abrir registros de Azure Site Recovery en Registros de aplicaciones y servicios:

   

   

   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.

   

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

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 no ser compatible. Para evitar una actualización debido a un reinicio de 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. Para obtener una versión del kernel no compatible, compruebe si hay una versión de kernel anterior a la que puede revertir; para ello, ejecute el comando adecuado para la máquina virtual:

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

   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 admitida.

   

4. Vuelva 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 haya 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".

      

   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 de kernel antigua 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:

   

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:

  

• 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 en la automatización de PowerShell

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

  

  

• 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.

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

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. Al eliminar el grupo de recursos también se produce un error 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

• Azure Site Recovery en Azure Stack Hub
• Planeamiento de la capacidad de Azure Site Recovery en Azure Stack Hub