Acerca de la replicación asíncrona de Persistent Disk

La replicación asíncrona de Persistent Disks (replicación asíncrona de PD) proporciona una replica el almacenamiento en bloque con objetivo de punto de recuperación bajo (RPO) y objetivo de tiempo de recuperación bajo (RTO) para la recuperación ante desastres (DR) activa-pasiva entre regiones.

La replicación asíncrona de PD es una opción de almacenamiento que proporciona replicación asíncrona de datos entre dos regiones. En el improbable caso de una interrupción regional, la replicación asíncrona de PD te permite conmutar por error tus datos de SAP a una región secundaria y reiniciar tu carga de trabajo de SAP en esa región.

Puedes usar la replicación asíncrona de PD para administrar la replicación de las cargas de trabajo de Compute Engine a nivel de infraestructura, en lugar de a nivel de carga de trabajo.

Descripción general

La replicación asíncrona de Persistent Disk replica los datos de un disco que está conectado a una carga de trabajo en ejecución, el disco principal, a un disco independiente ubicado en otra región. El disco que recibe datos replicados se conoce como disco secundario.

La región en la que se encuentra el disco principal se conoce como región principal, y la región en la que se encuentra el disco secundario se conoce como región secundaria. Las regiones principal y secundaria se conocen como par de regiones.

Cualquier disco que cumpla con los requisitos de disco se puede usar como disco principal. Una vez que tengas un disco principal, puedes crear un disco secundario que haga referencia al disco principal y comenzar la replicación del disco principal al disco secundario.

Si detienes la replicación desde el disco principal en algún momento y quieres reiniciarla más adelante, debes crear un disco secundario nuevo para reiniciarla.

Grupos de coherencia

Los grupos de coherencia te permiten realizar pruebas de recuperación ante desastres (DR) y DR en varios discos. Un grupo de coherencia es una política de recursos que hace lo siguiente:

  • Alinea la replicación en los discos principales y garantiza que todos los discos contengan datos de replicación de un momento común, que se usan para la DR.
  • Alinea las clonaciones de discos de los discos secundarios y garantiza que todas las clonaciones de discos contengan datos de un momento común, que se usan para los simulacros de DR.

Si deseas alinear el período de replicación en varios discos, agrega discos principales a un grupo de coherencia. Si deseas clonar varios discos y asegurarte de que esas clonaciones tengan datos de un momento común, agrega discos secundarios a un grupo de coherencia. Un grupo de coherencia se puede usar para la replicación o la clonación, pero no para ambas de forma simultánea.

Si deseas agregar discos principales a un grupo de coherencia, debes agregar discos al grupo de coherencia antes de comenzar la replicación. Puedes agregar discos secundarios a un grupo de coherencia en cualquier momento.

Conmutación por error y por recuperación

En caso de interrupción en la región principal, es tu responsabilidad identificarla y reiniciar la carga de trabajo conmutando por error a los discos secundarios, en la región secundaria. La replicación asíncrona de PD no ofrece supervisión de interrupciones. Puedes identificar una interrupción con las métricas de RPO, las verificaciones de estado, las métricas específicas de la aplicación y comunicándote con el equipo de Atención al cliente de Cloud.

El proceso de conmutación por error incluye las siguientes tareas:

  1. Detén la replicación.
  2. Adjunta los discos secundarios a las VMs en la región secundaria.

Después de realizar la conmutación por error de los discos, es tu responsabilidad validar y reiniciar la carga de trabajo de la aplicación en la región secundaria, y volver a configurar las direcciones de red que se usan para acceder a la aplicación para que apunten a la región secundaria.

Después de una conmutación por error de la región principal a la región secundaria, esta se convierte en la región principal que actúa. Después de que se resuelva la interrupción o el desastre, puedes iniciar la conmutación por recuperación para iniciar la replicación desde la región secundaria original (la región principal que actúa) hasta la región. De forma opcional, puedes repetir el proceso para volver a mover la carga de trabajo a la región principal original.

El proceso de conmutación por recuperación incluye las siguientes tareas:

  1. Configura la replicación entre la región principal nueva y la región principal original.

    • El disco secundario original ahora es el disco principal nuevo, y lo configuras para que se replique en un disco secundario nuevo en la región principal original.
    • Puedes crear una nueva política de recursos del grupo de coherencia en la región principal nueva para que los discos principales nuevos (los discos secundarios originales) puedan replicarse de forma coherente en un conjunto nuevo de discos secundarios en la región principal original.

  2. (Opcional) Después de que se produzca la replicación inicial, puedes repetir el proceso de conmutación por error para devolver la carga de trabajo a la región principal original.

Encriptación de los discos

Los discos primarios y secundarios no admiten claves de encriptación proporcionadas por el cliente (CSEK). En su lugar, usa claves de Google y administradas por Google o claves de encriptación administradas por el cliente (CMEK). Si usas CMEK en el disco principal, también debes usar CMEK en el disco secundario. Puedes usar diferentes CMEK en ambos discos.

Personalización del disco secundario

Cuando creas un disco secundario, Compute Engine copia las propiedades del disco principal en el secundario. Estas propiedades incluyen la descripción, el tipo y las etiquetas del disco principal.

Si el disco principal es un disco de arranque, el disco secundario también tiene la configuración de arranque del disco principal. La configuración de inicio incluye información sobre la arquitectura del sistema operativo (SO), las licencias del SO y sus funciones de SO de invitado.

Puedes cambiar ciertas propiedades del disco secundario para que difieran del disco principal. Por ejemplo, el disco principal y el secundario deben tener el mismo tamaño y clave de encriptación, pero puedes asignar etiquetas adicionales al disco secundario.

En el caso de los discos de arranque, puedes habilitar opciones de seguridad o redes adicionales en el disco secundario si especificas funciones adicionales del SO invitado. Sin embargo, no puedes quitar ninguna de las funciones del SO invitado del disco principal. Compute Engine combina las funciones nuevas que especifiques con las funciones del SO invitado existentes del disco principal.

Ejemplo

Supongamos que tienes un disco de arranque llamado disk-1, con las siguientes funciones del SO invitado: [GVNIC, UEFI_COMPATIBLE].

Si creas un disco secundario a partir de disk-1, solo puedes especificar funciones adicionales. No puedes quitar las funciones UEFI_COMPATIBLE y GVNIC. Por lo tanto, si especificas MULTI_IP_SUBNET cuando creas el disco secundario, la función nueva se fusiona con las del disco principal, por lo que las funciones del SO invitado resultantes para el disco secundario son GVNIC, UEFI_COMPATIBLE y MULTI_IP_SUBNET.

Para aprender a personalizar un disco secundario, consulta Crea un disco secundario personalizado.

Replicación asíncrona de PD y Persistent Disks regionales

Puedes usar la replicación asíncrona de PD con Persistent Disks regionales para lograr alta disponibilidad (HA) y recuperación ante desastres (DR).

Los discos persistentes regionales se pueden usar como el disco principal o el secundario en un par de discos de replicación asíncrona de PD. Un par de discos es un disco principal que se replica en un disco secundario.

Cuando se usa un disco regional como disco principal, la replicación no se interrumpe, incluso si una de sus zonas experimenta una interrupción. El disco principal regional continúa replicando datos de la zona en buen estado al disco secundario. Del mismo modo, cuando un disco regional funciona como disco secundario, la replicación persiste a pesar de una interrupción en una de sus zonas. El uso de un disco regional como disco secundario prepara tu carga de trabajo para la alta disponibilidad en todas las zonas en caso de una conmutación por error, en la que el disco secundario pasa a ser el nuevo disco principal.

Limitaciones

  • La replicación asíncrona de PD solo es compatible con el Persistent Disk balanceado y de rendimiento (SSD).
  • Los discos de solo lectura y los discos de multiescritura no son compatibles.
  • Cada disco puede tener un tamaño máximo de 32 TiB.
  • Debes detener la replicación para poder borrar un disco principal o secundario.
  • Si la replicación está en curso para el disco de arranque de una VM, no podrás borrarla hasta que detengas la replicación.
  • Si un disco principal está conectado a una VM como disco que no es de arranque y el disco está configurado para borrarse con la VM, no puedes borrar la VM ni el disco hasta que detengas la replicación o desconectes el disco principal de la VM. Los intentos de borrar la VM fallarán hasta que detengas la replicación.

  • Cada proyecto puede tener como máximo 1,000 pares de discos en cada par de regiones.

    Por ejemplo, un proyecto determinado, project-1 puede tener hasta 1000 pares de discos en el par de regiones Iowa-Oregón. project-1 también puede tener hasta 1000 pares de discos en el par de regiones de Bélgica-Fráncfort.

Regiones admitidas

La replicación asíncrona de PD está disponible en todas las regiones de los siguientes continentes:

  • Asia, excepto Indonesia
  • Europa
  • Norteamérica
  • Oceanía

Puedes replicar un disco principal en una región determinada a un disco secundario en cualquier región disponible dentro del mismo continente. Esto significa que puedes crear un par de regiones de cualquier dos regiones dentro del mismo continente.

Por ejemplo, supongamos que tienes un disco principal en Frankfurt (europe-west3). Puedes replicar ese disco en un disco secundario en cualquier parte de Europa, pero no puedes replicarlo en una región de Norteamérica.

Para obtener una lista completa de todas las regiones de Compute Engine, consulta Regiones y zonas disponibles.

Rendimiento

El objetivo de punto de recuperación (RPO), o la demora en el tiempo para que los datos estén disponibles en el sitio secundario, depende de las tasas de cambio de disco. Por lo general, la replicación asíncrona de PD replica los datos con un RPO de destino de un minuto, hasta 12.5 GB de bloques modificados comprimidos por minuto con bloques de disco replicados con un nivel de detalle de bloque de 4 KB. Si un bloque determinado se cambia varias veces entre eventos de replicación, solo se replica el cambio más reciente en el disco secundario. A tasas de cambio de disco más altas, el RPO puede ser superior a un minuto y, por lo general, aumenta a medida que aumentan las tasas de cambio de disco. El RPO no se puede configurar.

El RPO puede superar un minuto en las siguientes situaciones:

  • Cuando se inicia la replicación del disco. Durante la replicación inicial, PD Async Replication replica todos los bloques usados en el disco principal en el disco secundario. La replicación inicial se completa cuando la métrica disk/async_replication/time_since_last_replication está disponible en Cloud Monitoring.
  • Si la tasa de cambio del disco es superior a 12.5 GB de bloques modificados comprimidos por minuto. Después de un aumento repentino en el cambio de disco, el RPO para ciclos de replicación posteriores puede superar un minuto mientras la replicación se actualiza.
  • Si desconectas un disco de una VM o reinicias una VM mientras se replica el disco. Es posible que los discos que se están replicando y que están separados de una VM vean un aumento del RPO de hasta cinco minutos durante un período breve.

Si quieres obtener información sobre cómo ver el RPO para los discos, consulta Métricas de rendimiento de la replicación asíncrona de Persistent Disks.

El objetivo de tiempo de recuperación (RTO) durante la conmutación por error depende del tiempo que se tarda en completar las diversas tareas involucradas en la conmutación por error de tu carga de trabajo a una región nueva. Las tareas como detener la replicación y conectar discos a las VMs en la región secundaria tardan solo unos minutos en completarse. Para acelerar el RTO, asegúrate de que las VMs se ejecuten en la región secundaria de modo que, si se produce la conmutación por error, no tengas que esperar a que se inicien las VMs.

¿Qué sigue?