Acerca de la replicación asíncrona

La replicación asíncrona ofrece replicación de almacenamiento en bloques con objetivo de tiempo de recuperación (RPO) y objetivo de punto de recuperación (RTO) bajos para la recuperación tras fallos activa-pasiva entre regiones.

La réplica asíncrona es una opción de almacenamiento que proporciona la 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 gestionar la replicación de cargas de trabajo de Compute Engine a nivel de infraestructura, en lugar de a nivel de carga de trabajo.

Información general

La replicación asíncrona replica los datos de un disco conectado a una carga de trabajo en ejecución (el disco primario) en un disco independiente situado en otra región. El disco que recibe los datos replicados se denomina 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 denominan par de regiones.

Cualquier disco que cumpla 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 iniciar la réplica 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 nuevo disco secundario para reiniciar la replicación.

Grupos de coherencia

Los grupos de coherencia te permiten realizar pruebas de recuperación ante desastres 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 asegura que todos los discos contengan datos de replicación de un momento determinado, que se utiliza para la recuperación ante desastres.
  • Alinea los clones de discos de los discos secundarios y se asegura de que todos los clones de discos contengan datos de un momento dado, que se utiliza para las simulaciones de recuperación ante desastres.

Si quieres alinear el periodo de replicación en varios discos, añade discos primarios a un grupo de coherencia. Si quieres clonar varios discos y asegurarte de que esos clones tengan datos de un momento concreto, añade 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 simultáneamente.

Si quieres añadir discos principales a un grupo de coherencia, debes añadir discos al grupo de coherencia antes de iniciar la replicación. Puedes añadir discos secundarios a un grupo de coherencia en cualquier momento.

Conmutación por error y recuperación tras fallos

En caso de interrupción en la región principal, es tu responsabilidad identificar la interrupción y reiniciar tu carga de trabajo mediante los discos secundarios en la región secundaria. La replicación asíncrona no ofrece monitorización de interrupciones. Puedes identificar una interrupción mediante las métricas de RPO, las comprobaciones de estado, las métricas específicas de la aplicación y poniéndote en contacto con el equipo de Asistencia de Google Cloud.

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

  1. Detener la replicación.
  2. Conecta los discos secundarios a las VMs de 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, así como reconfigurar las direcciones de red que se usan para acceder a tu aplicación de forma que apunten a la región secundaria.

Tras una conmutación por error de la región principal a la secundaria, la región secundaria se convierte en la región principal activa. Una vez que se haya resuelto la interrupción o el desastre, puedes iniciar la conmutación por recuperación para empezar la replicación desde la región secundaria original (la región principal activa) a la región principal original. También puedes repetir el proceso para volver a mover la carga de trabajo a la región principal original.

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

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

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

  2. (Opcional) Una vez que se haya producido 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.

Cifrado del disco

Los discos principales y secundarios no admiten claves de cifrado proporcionadas por el cliente (CSEK). Usa Google-owned and Google-managed encryption keys o claves de cifrado gestionadas por el cliente (CMEK). Si usas CMEK en el disco principal, también debes usarla en el disco secundario. Puedes usar diferentes CMEKs en ambos discos.

Personalización de discos secundarios

Cuando creas un disco secundario, Compute Engine copia las propiedades del disco principal en el secundario. Estas propiedades incluyen la descripción, el tipo de disco 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 del SO invitado.

Puedes cambiar algunas propiedades del disco secundario para que sean diferentes a las del disco principal. Por ejemplo, el disco principal y el secundario deben tener el mismo tamaño y la misma clave de cifrado, pero puedes asignar etiquetas adicionales al disco secundario.

En el caso de los discos de arranque, puedes habilitar opciones adicionales de seguridad o de redes en el disco secundario especificando funciones adicionales del SO invitado. Sin embargo, no puedes eliminar ninguna de las funciones del SO invitado del disco principal. Compute Engine combina las nuevas funciones que especifiques con las funciones del SO invitado 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 al crear el disco secundario, la nueva función se combinará con las del disco principal, por lo que las funciones del SO invitado resultantes para el disco secundario serán GVNIC, UEFI_COMPATIBLE y MULTI_IP_SUBNET.

Para saber cómo personalizar un disco secundario, consulta Crear un disco secundario personalizado.

Réplica asíncrona y discos regionales

Puedes usar la réplica asíncrona con discos regionales para conseguir alta disponibilidad y recuperación tras fallos.

Los discos persistentes regionales se pueden usar como disco principal o secundario en un par de discos de réplica asíncrona. Un par de discos es un disco principal que se replica en un disco secundario.

Si usas un disco regional como disco principal, la replicación no se interrumpe aunque una de sus zonas sufra una interrupción. El disco principal regional sigue 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 aunque se produzca una interrupción en una de sus zonas. Si usas un disco regional como disco secundario, tu carga de trabajo estará preparada para tener una alta disponibilidad en todas las zonas en caso de conmutación por error, donde el disco secundario pasará a ser el nuevo disco principal.

Limitaciones

  • La réplica asíncrona solo se admite en los siguientes tipos de disco:
    • Disco persistente balanceado
    • Disco persistente de rendimiento (SSD)
    • Hyperdisk Balanced
    • Hyperdisk Balanced High Availability
    • Hyperdisk Extreme
  • No se admiten discos de solo lectura.
  • Los discos multiescritura solo se admiten en Hyperdisk Balanced y Hyperdisk Balanced High Availability.
  • Los cambios que hagas en el tamaño de Hyperdisk se aplicarán automáticamente al disco secundario. Sin embargo, los cambios en las propiedades de Hyperdisk, incluidos los cambios en las IOPS, el rendimiento y el modo de acceso, no se aplican automáticamente al disco secundario. Debe editar manualmente estas propiedades en el disco secundario.
  • Cada disco puede tener un tamaño máximo de 64 TiB.
  • Debes detener la replicación para poder eliminar un disco principal o secundario.
  • Si la replicación del disco de arranque de una máquina virtual está en curso, no podrás eliminar la máquina virtual hasta que detengas la replicación.
  • Si se conecta un disco principal a una VM como disco que no es de arranque y el disco está configurado para que se elimine con la VM, no podrás eliminar la VM ni el disco hasta que detengas la replicación o desvincules el disco principal de la VM. No podrás eliminar la VM hasta que detengas la replicación.

  • Cada proyecto puede tener un máximo de 1000 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 la combinación de regiones Bélgica-Fráncfort.

Regiones disponibles

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

  • Asia (excepto Indonesia)
  • Europa
  • Norteamérica
  • Oceanía

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

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

Para ver una lista completa de todas las regiones de Compute Engine, consulta Zonas y regiones disponibles.

Rendimiento

El objetivo de punto de recuperación (RPO) o el tiempo de espera para que los datos estén disponibles en el sitio secundario dependen de las tasas de cambio del disco. La replicación asíncrona suele replicar datos con un RPO objetivo de un minuto, hasta 12,5 GB de bloques modificados comprimidos por minuto, y los bloques de disco se replican con una granularidad de bloques de 4 KB. Si un bloque determinado cambia varias veces entre eventos de replicación, solo se replica en el disco secundario el cambio más reciente. Si las tasas de cambio de disco son más altas, el RPO puede ser superior a un minuto y suele aumentar a medida que crecen las tasas de cambio de disco. El RPO no se puede configurar.

El RPO puede superar un minuto en los siguientes casos:

  • Cuando se inicia la replicación del disco. Durante la réplica inicial, la réplica asíncrona replica todos los bloques usados del 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 comprimidos modificados por minuto. Después de un pico en los cambios de disco, el RPO de los ciclos de replicación posteriores puede superar un minuto mientras se pone al día la replicación.
  • Si desvinculas un disco de una VM o reinicias una VM mientras el disco se está replicando. Es posible que los discos que se estén replicando y que se hayan separado de una máquina virtual experimenten un aumento del RPO de hasta cinco minutos durante un breve periodo.

Para saber cómo ver el RPO de tus discos, consulta las métricas de rendimiento de la replicación asíncrona.

El tiempo de recuperación objetivo (RTO) durante la conmutación por error depende del tiempo que se tarde en completar las distintas tareas que implica la conmutación por error de tu carga de trabajo a una nueva región. Tareas como detener la replicación y adjuntar discos a las VMs de la región secundaria solo deberían tardar unos minutos en completarse. Puedes acelerar el tiempo de recuperación ante desastres asegurándote de que tienes máquinas virtuales en ejecución en la región secundaria para que, si se produce una conmutación por error, no tengas que esperar a que se inicien las máquinas virtuales.

Siguientes pasos