Información acerca de la replicación asíncrona

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

La replicación asíncrona 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 te permite conmutar por error tus datos a una región secundaria y reiniciar tu carga de trabajo en esa región.

Puedes usar la replicación asíncrona 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 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 denomina región principal, y la región en la que se encuentra el disco secundario se denomina región secundaria. Las regiones principal y secundaria se conocen como par de regiones.

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

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

Grupos de coherencia

Los grupos de coherencia te permiten realizar pruebas de 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 todos 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 garantizar 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 una interrupción en la región principal, es tu responsabilidad identificar la interrupción y reiniciar la carga de trabajo conmutada por error con los discos secundarios en la región secundaria. La replicación asíncrona no ofrece supervisión de interrupciones. Puedes identificar una interrupción con las métricas del 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 conmutar por error los discos, es tu responsabilidad validar y reiniciar la carga de trabajo de tu aplicación en la región secundaria, y volver a configurar las direcciones de red que se usan para acceder a tu aplicación de modo que apunten a la región secundaria.

Después de una conmutación por error de la región principal a la secundaria, la región secundaria 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 manera 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 principales y secundarios no admiten claves de encriptación proporcionadas por el cliente (CSEK). En su lugar, usa Google-owned and Google-managed encryption keys o claves de encriptación administradas por el cliente (CMEK). Si usas CMEK en el disco principal, también debes usarla en el disco secundario. Puedes usar diferentes CMEK en ambos discos.

Cómo personalizar un disco secundario

Cuando creas un disco secundario, Compute Engine copia automáticamente las propiedades del disco principal en el disco secundario. 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 la misma clave de encriptación, pero puedes asignar etiquetas adicionales al disco secundario.

Si el disco principal es un disco de arranque, el disco secundario se crea con la configuración de arranque del disco principal. La configuración de inicio incluye información sobre la arquitectura del SO, las licencias del SO y sus funciones del SO invitado.

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

Para obtener más información sobre cómo personalizar un disco secundario, consulta Crea un disco secundario personalizado.

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 nueva característica se combina con las del disco principal, por lo que las características resultantes del SO invitado para el disco secundario son [GVNIC,UEFI_COMPATIBLE, and MULTI_IP_SUBNET].

Modifica un disco principal

Después de crear el disco secundario, es posible que desees modificar las propiedades del disco principal. En el caso de algunas propiedades, si realizas un cambio en el disco principal, Compute Engine actualiza automáticamente la propiedad en el disco secundario.

Compute Engine supervisa y actualiza automáticamente las siguientes propiedades:

  • Modo de acceso (solo para Hyperdisk)
  • Tamaño del disco
  • IOPS y capacidad de procesamiento aprovisionadas (solo para Hyperdisk)
  • Estado de la replicación

Si modificas cualquier otra propiedad del disco principal, debes actualizar el disco secundario de forma manual.

  • Para obtener información sobre cómo modificar las propiedades de un volumen de Hyperdisk, consulta Modifica un Hyperdisk.
  • Para obtener más información sobre cómo modificar las propiedades de un Persistent Disk, consulta Modifica un disco persistente.

Replicación asíncrona y discos regionales

Puedes usar la replicación asíncrona con discos 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. 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 actúa como disco secundario, la replicación persiste a pesar de una interrupción en una de sus zonas. Usar un disco regional como disco secundario prepara tu carga de trabajo para una 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 solo se admite para los siguientes tipos de discos:
    • Disco persistente balanceado
    • Persistent Disk de rendimiento (SSD)
    • Hiperdisco balanceado
    • Alta disponibilidad balanceada de Hyperdisk
    • Hiperdisco extremo
  • Los discos de solo lectura no son compatibles.
  • Los discos de multiescritura solo son compatibles con Hyperdisk Balanced y Hyperdisk Balanced High Availability.
  • No todos los cambios en las propiedades de Hyperdisk se aplican automáticamente al disco secundario. Para obtener más información sobre qué propiedades se aplican automáticamente al disco secundario, consulta Personalización del disco secundario.
  • Cada disco puede tener un tamaño máximo de 64 TiB.
  • Debes detener la replicación antes de borrar un disco principal o secundario.
  • Si la replicación está en curso para el disco de arranque de una VM, no podrás borrar la VM hasta que detengas la replicación.
  • Si un disco principal está conectado a una VM como un disco que no es de arranque y el disco está configurado para que se borre con la VM, no podrás 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 está disponible en todas las regiones de los siguientes continentes:

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

Puedes replicar un disco principal en una región determinada en un disco secundario en cualquier región disponible dentro del mismo continente. Esto significa que puedes crear un par de regiones a partir de dos regiones cualesquiera 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 lugar de Europa, pero no puedes replicarlo en una región de América del Norte.

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 para que los datos estén disponibles en el sitio secundario, depende de las tasas de cambio del disco. Por lo general, la replicación asíncrona 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. Con tasas de cambio de disco más altas, el RPO puede ser superior a un minuto y, por lo general, aumenta a medida que crecen las tasas de cambio de disco. El RPO no se puede configurar.

El RPO puede superar un minuto en las siguientes situaciones:

  • Cuándo comienza la replicación del disco. Durante la replicación inicial, la replicación asíncrona replica todos los bloques usados en el disco principal al 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 para ver el RPO de tus discos, consulta Métricas de rendimiento de la replicación asíncrona.

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?