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


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 a una región secundaria y reiniciar tu carga de trabajo 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 en blanco independiente que se encuentra en otra región (el 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.

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

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

Grupos de coherencia

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

  • Alinea la replicación entre los discos principales y garantiza que todos los discos contengan datos de replicación de un momento común, que se usa para la DR.
  • Alinea los clones de discos desde discos secundarios y garantiza que todos los clones de discos contengan datos de un punto común en el tiempo, que se usa 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. Se puede usar un grupo de coherencia para la replicación o clonación, pero no ambos de manera 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 el caso de una interrupción en la región principal, es tu responsabilidad identificar la interrupción y reiniciar la carga de trabajo con 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 mediante las métricas de RPO, las verificaciones de estado, las métricas específicas de la aplicación y una comunicación con el servicio de Atención al cliente de Cloud.

El proceso de conmutación por error implica 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 a fin de que apunte a la región secundaria.

Después de una conmutación por error desde la región principal hasta 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 principal original. De manera opcional, puedes repetir el proceso para volver a mover la carga de trabajo a la región principal original.

El proceso de recuperación implica 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. Después de que se produce la replicación inicial, puedes repetir el proceso de conmutación por error para que la carga de trabajo vuelva a la región principal original (opcional).

Encriptación de los discos

Los discos principal y secundario no son compatibles con las claves de encriptación proporcionadas por el cliente (CSEK). En su lugar, usa claves de encriptación 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, este hereda las propiedades del disco principal, como la descripción, el tipo de disco y las etiquetas. Si el disco principal es un disco de arranque, el disco secundario hereda 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 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.

Para los discos de arranque, puedes habilitar opciones adicionales de seguridad o de red en el disco secundario mediante la especificación de funciones adicionales del SO invitado. Sin embargo, no puedes quitar ninguna de las funciones del SO invitado del disco principal. Compute Engine combina las características nuevas que especificas con las características del SO invitado existente del disco principal.

Ejemplo

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

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

Para obtener información sobre cómo 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 Persistent Disks 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 si una de las zonas del disco principal experimenta una interrupción. El disco principal regional continúa replicando desde la zona en buen estado hasta el disco secundario.

Cuando un disco regional se usa como disco secundario, la replicación se detiene si una de las zonas del disco secundario experimenta una interrupción. En este caso, la replicación no continúa a la zona en buen estado del disco secundario. Sin embargo, el uso de discos regionales como discos secundarios puede preparar tu carga de trabajo para la alta disponibilidad entre zonas en caso de que se produzca una conmutación por error cuando el disco secundario se convierta en 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.
  • Los discos pueden tener un tamaño máximo de 5 TiB.
  • La replicación asíncrona de PD admite 100 pares de discos en cada par de regiones y por proyecto.

  • La replicación asíncrona de PD admite una cantidad máxima de pares de discos en cada par de regiones y por proyecto. La cantidad máxima de pares de discos varía según el par de regiones. Por ejemplo, un proyecto determinado, project-1 puede tener hasta 100 pares de discos en el par de regiones Iowa-Oregón. project-1 también puede tener hasta 100 pares de discos en el par de regiones de Bélgica-Fráncfort.

Pares de regiones compatibles

La replicación asíncrona de Persistent Disks admite la replicación entre regiones específicas de Google Cloud. La replicación puede ocurrir desde y hacia los discos en cada región de un par de regiones.

En la siguiente tabla, se enumeran los pares de regiones de replicación asíncrona de PD compatibles, es decir, cada región compatible y sus regiones secundarias disponibles.

Región Regiones secundarias disponibles
asia-east1 (Condado de Changhua, Taiwán) asia-southeast1 (Jurong West, Singapur)
asia-east2 (Hong Kong, APAC) asia-southeast1 (Jurong West, Singapur)
asia-northeast1 (Tokio, Japón) asia-northeast2 (Osaka, Japón)
asia-northeast2 (Osaka, Japón) asia-northeast1 (Tokio, Japón)
asia-south1 (Bombay, India) asia-south2 Delhi (India)
asia-south2 Delhi (India) asia-south1 (Bombay, India)
asia-southeast1 (Jurong West, Singapur) asia-east1 (Condado de Changhua, Taiwán)
asia-east2 (Hong Kong, APAC)
australia-southeast1 (Sídney, Australia) australia-southeast2 (Melbourne, Australia)
australia-southeast2 (Melbourne, Australia) australia-southeast1 (Sídney, Australia)
europe-southwest1 (Madrid, España) europe-west1 (St. Ghislain, Bélgica)
europe-west1 (St. Ghislain, Bélgica) europe-southwest1 (Madrid, España)
europe-west2 (Londres, Inglaterra)
europe-west3 (Fráncfort, Alemania)
europe-west4 (Puerto de Ems, Países Bajos)
europe-west9 (París, Francia)
europe-west2 (Londres, Inglaterra) europe-west1 (St. Ghislain, Bélgica)
europe-west4 (Puerto de Ems, Países Bajos)
europe-west3 (Fráncfort, Alemania) europe-west1 (St. Ghislain, Bélgica)
europe-west4 (Puerto de Ems, Países Bajos)
europe-west8 (Milán, Italia)
europe-west10 (Berlín, Alemania)
europe-west4 (Puerto de Ems, Países Bajos) europe-west1 (St. Ghislain, Bélgica)
europe-west2 (Londres, Inglaterra)
europe-west3 (Fráncfort, Alemania)
europe-west6 (Zúrich, Suiza)
europe-west6 (Zúrich, Suiza) europe-west4 (Puerto de Ems, Países Bajos)
europe-west8 (Milán, Italia) europe-west12 (Turín, Italia)
europe-west3 (Fráncfort, Alemania)
europe-west9 (París, Francia) europe-west1 (St. Ghislain, Bélgica)
europe-west10 (Berlín, Alemania) europe-west3 (Fráncfort, Alemania)
europe-west12 (Turín, Italia) europe-west8 (Milán, Italia)
northamerica-northeast1 (Montreal, Quebec) us-east1 (Moncks Corner, Carolina del Sur)
us-central1 (Council Bluffs, Iowa) us-east1 (Moncks Corner, Carolina del Sur)
us-east4 (Ashburn, Virginia)
us-east5 (Columbus, Ohio)
us-west1 (The Dalles, Oregón)
us-east1 (Moncks Corner, Carolina del Sur) us-central1 (Council Bluffs, Iowa)
northamerica-northeast1 (Montreal, Quebec)
us-east4 (Ashburn, Virginia) us-central1 (Council Bluffs, Iowa)
us-east5 (Columbus, Ohio) us-central1 (Council Bluffs, Iowa)
us-west1 (The Dalles, Oregón) us-central1 (Council Bluffs, Iowa)
us-west2 (Los Ángeles, California)
us-west2 (Los Ángeles, California) us-west1 (The Dalles, Oregón)

Rendimiento

El objetivo de punto de recuperación (RPO) o el retraso durante el cual los datos están disponibles en el sitio secundario dependen 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 250 MB 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 el cambio más reciente se replica en el disco secundario. Con tasas de cambio de disco más altas, el RPO puede ser mayor a un minuto y, por lo general, aumenta a medida que crecen las tasas de cambio del disco. El RPO no se puede configurar.

El RPO puede superar un minuto en los siguientes casos:

  • Cuando comienza la replicación del disco. Durante la replicación inicial, la replicación asíncrona de PD replica todos los bloques usados en el disco principal del 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 250 MB 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 lo reinicias mientras se replica el disco. Los discos que están experimentando una replicación que están separados de una VM pueden ver un aumento del RPO de hasta cinco minutos durante un período corto.

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 lleva completar las diversas tareas involucradas en la conmutación por error tu carga de trabajo en una nueva región. 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?