En este documento, se describen los patrones, los pasos de configuración y la guía operativa para configurar topologías de recuperación ante desastres entre Spanner administrado en Google Cloud y Spanner Omni en un entorno externo, como AWS o un centro de datos local.
Si combinas la transmisión de transacciones con flujos de cambios y la conectividad de red dedicada a través de Cross‑Cloud Interconnect, puedes lograr objetivos de punto de recuperación (RPO) y objetivos de tiempo de recuperación (RTO) bajos en los límites de la nube.
Descripción general de la arquitectura
En una topología de recuperación ante desastres multinube, Spanner en Google Cloud sirve como la base de datos principal, y Spanner Omni sirve como una implementación en espera o un sitio secundario de recuperación ante desastres. Puedes replicar los cambios transaccionales de forma continua con los flujos de cambios.
En la siguiente tabla, se comparan las capacidades, los roles y los límites operativos de la base de datos entre una implementación principal de Spanner y una implementación secundaria de Spanner Omni en AWS.
| Capacidad o dimensión | Sitio principal: Spanner en Google Cloud | Sitio secundario: Spanner Omni en AWS |
|---|---|---|
| Modelo de implementación |
Servicio completamente administrado en Google Cloud. |
Software autoadministrado en AWS, como Amazon Elastic Compute Cloud (Amazon EC2) o Amazon Elastic Kubernetes Service (Amazon EKS). |
| ANS de disponibilidad |
Hasta un 99.999% para configuraciones multirregionales y un 99.99% para configuraciones regionales. Para obtener más información, consulta el ANS de Spanner. |
Administrado por el cliente; depende de tu infraestructura y topología. |
| Modo de replicación |
Replicación síncrona basada en Paxos en zonas y regiones. |
Captura de datos modificados (CDC) asíncrona y casi en tiempo real con flujos de cambios. |
| Objetivo de punto de recuperación (RPO) |
Casi nulo dentro de la instancia administrada. |
De menos de un segundo a segundos entre los límites de la nube, según la capacidad de procesamiento de la canalización y la latencia de la red. |
| Objetivo de tiempo de recuperación (RTO) |
Conmutación por error inmediata y automatizada entre réplicas |
Depende de tu runbook de DNS y de cambio de tráfico. |
| Capa de tránsito de red |
Intercambio de tráfico entre redes de nube privada virtual (VPC) o Cloud Interconnect. |
Cross‑Cloud Interconnect conectado a AWS Direct Connect. |
| Objetivo de almacenamiento de copias de seguridad |
Copias de seguridad de Spanner administradas por Google, que solo se pueden restablecer en Spanner administrado. |
Cloud Storage o Amazon Simple Storage Service (Amazon S3), que solo se pueden restablecer en Spanner Omni. |
Antes de comenzar
Antes de configurar la replicación entre Spanner y Spanner Omni, asegúrate de que tu entorno cumpla con estos requisitos:
- Aprovisiona la capacidad de destino coincidente: Ajusta el tamaño de tu implementación de Spanner Omni de destino para que coincida con la capacidad de E/S de CPU, memoria y almacenamiento de tu instancia principal de Spanner. Si la implementación es demasiado pequeña, puede causar un retraso en la replicación y evitar que el clúster en espera controle las cargas de trabajo durante una conmutación por error. Para obtener más información, consulta Requisitos del sistema.
- Sincroniza los esquemas de la base de datos y los datos de referencia: Crea la base de datos y las tablas de destino en Spanner Omni con el mismo dialecto de SQL, GoogleSQL o PostgreSQL, y las definiciones de esquema que tu base de datos de Spanner de origen. Como no puedes restablecer una copia de seguridad administrada de Spanner en Spanner Omni, exporta los datos existentes de Spanner a archivos Avro en Cloud Storage y, luego, impórtalos a Spanner Omni. Para obtener más información, consulta Esquema y modelo de datos, Desarrolla con Spanner Omni, Exporta bases de datos de Spanner a Avro e Importa y exporta datos.
- Establece la conectividad de red privada: Configura el enrutamiento de red privada entre tu red de VPC de Google Cloud y tu entorno externo para que tus trabajadores de replicación puedan conectarse a Spanner y al extremo de gRPC de Spanner Omni. Para obtener más información, consulta Elige un producto de Conectividad de red y Acelera la replicación con Cross-Cloud Interconnect.
Replica datos de forma continua con flujos de cambios
Para las aplicaciones que requieren continuidad empresarial multinube,
los flujos de cambios de Spanner generan
cambios en los datos transaccionales (operaciones INSERT, UPDATE y DELETE) en
el orden de la marca de tiempo de confirmación. Una canalización de replicación continua lee los registros de cambios
de Spanner en Google Cloud y los escribe en tu
implementación de Spanner Omni.
El uso de flujos de cambios para la replicación multinube proporciona los siguientes beneficios:
- Espera activa-pasiva: Mantiene una réplica tibia en Spanner Omni que está lista para entregar cargas de trabajo cuando inicias una conmutación por error.
- Replicación selectiva: Puedes configurar los flujos de cambios para que supervisen toda la base de datos o restringirlos a tablas y columnas específicas para reducir los costos de transferencia multinube.
- Paridad de dialectos: Debido a que Spanner Omni admite los mismos dialectos de GoogleSQL y PostgreSQL y la semántica de esquema que Spanner, las consultas de tu aplicación se ejecutan sin modificaciones después de la migración de sistemas.
Paso 1: Crea un flujo de cambios en la base de datos de origen
Crea un flujo de cambios en tu base de datos de Spanner de origen para hacer un seguimiento de los cambios en tus tablas de destino. Por ejemplo, ejecuta esta sentencia de DDL en tu base de datos de Spanner:
CREATE CHANGE STREAM CHANGE_STREAM_NAME
FOR TABLE_NAMES
OPTIONS (
retention_period = '7d',
value_capture_type = 'NEW_ROW_AND_OLD_VALUES'
);
Reemplaza lo siguiente:
CHANGE_STREAM_NAME: el nombre de tu flujo de cambios, por ejemplo,CsToOmniDrStream.TABLE_NAMES: Es una lista separada por comas de las tablas que se supervisarán, por ejemplo,Customers, Orders, AccountBalancesoALLpara supervisar todas las tablas de la base de datos.
Si configuras retention_period como '7d', se conservarán los registros de flujo de cambios durante un máximo de siete días, lo que ayuda a evitar la pérdida de datos si tu canalización de replicación experimenta interrupciones de mantenimiento o conectividad prolongadas. Para obtener más
información, consulta
Crea y administra flujos de cambios.
Paso 2: Implementa una canalización de captura de datos modificados
Para transmitir cambios de Spanner a Spanner Omni, implementa una canalización de captura de datos modificados (CDC) continua con Dataflow con Apache Beam o ejecuta Pods de trabajadores personalizados en Google Kubernetes Engine (GKE) o Amazon EKS.
Una canalización de replicación de producción realiza las siguientes tareas:
- Lee particiones: Usa la API de flujos de cambios de Spanner o el conector SpannerIO de Apache Beam para leer registros de cambios en particiones dinámicas de flujos de cambios. Para obtener más información, consulta Particiones, registros y consultas de flujos de cambios y Procesa registros de flujos de cambios con Dataflow.
- Almacena en búfer y ordena las mutaciones: Secuencia y agrupa las transacciones
según sus marcas de tiempo de confirmación (
commit_timestamp) por rango de claves o tabla para mantener la coherencia transaccional y maximizar la capacidad de procesamiento de escritura. - Escribe en Spanner Omni: Se conecta a través de gRPC al extremo privado de la implementación de Spanner Omni y aplica las mutaciones por lotes. Si usas el conector SpannerIO de Apache Beam con encriptación, usa Apache Beam 2.69.0 o una versión posterior para TLS, o 2.75.0 o una versión posterior para TLS mutua (mTLS). Para obtener más información, consulta Usa Apache Beam y SpannerIO para conectarte a Spanner Omni y Autenticación y autorización.
- Supervisa el retraso de replicación: Realiza un seguimiento de la diferencia entre la hora
actual y la
commit_timestampde los registros de cambios procesados para que puedas recibir alertas sobre los retrasos de replicación.
Si usas Dataflow o Apache Beam, debes usar el SDK de Java de Apache Beam, ya que el SDK de Python no incluye un conector de flujos de cambios. En el caso de los pods de trabajadores personalizados, en este ejemplo de Python, se muestra cómo configurar un cliente de Spanner Omni con encriptación TLS y aplicar un lote de mutaciones de flujo de cambios a una base de datos de destino. Para las cargas de trabajo de gran volumen, pon en cola y agrupa por lotes las mutaciones que no se superponen en el orden de la marca de tiempo de confirmación en los procesos de trabajador paralelos en lugar de confirmar un registro a la vez:
from google.cloud import spanner
from google.cloud.spanner_v1 import InstanceType
# Configure the Spanner Omni target client
omni_client = spanner.Client(
client_options={"api_endpoint": "ENDPOINT"},
instance_type=InstanceType.OMNI,
ca_certificate="PATH_TO_CA_CERT",
)
# Spanner Omni uses "default" as the instance ID
omni_instance = omni_client.instance("default")
omni_database = omni_instance.database("DATABASE_ID")
def apply_cdc_mutations_to_omni(records):
"""Applies a batch of ordered change stream records to Spanner Omni."""
def write_batch(transaction):
for record in records:
table_name = record["tableName"]
mutation_type = record["mutationType"] # INSERT, UPDATE, DELETE
row_data = record.get("columnValues", {})
if mutation_type in ("INSERT", "UPDATE"):
transaction.insert_or_update(
table=table_name,
columns=list(row_data.keys()),
values=[list(row_data.values())],
)
elif mutation_type == "DELETE":
key_columns = record["keyValues"]
transaction.delete(
table=table_name,
keyset=spanner.KeySet(keys=[list(key_columns.values())]),
)
omni_database.run_in_transaction(write_batch)
Reemplaza lo siguiente:
ENDPOINT: el extremo y el puerto de gRPC privados de tu instancia de Spanner Omni, por ejemplo,spanner-omni.internal.example.com:15000.PATH_TO_CA_CERT: Es la ruta de acceso al archivo del certificado de la autoridad certificadora (AC) para tu implementación de Spanner Omni.DATABASE_ID: Es el ID de la base de datos de Spanner Omni de destino.
Para obtener más información sobre cómo configurar las conexiones de cliente, consulta Usa la biblioteca cliente de Python para conectarte a Spanner Omni.
Acelera la replicación con Cross‑Cloud Interconnect
Confiar en la Internet pública o en los túneles VPN de IPsec entre Google Cloud y otro proveedor de servicios en la nube puede generar inestabilidad en la red, pérdida de paquetes, límites de ancho de banda y un retraso de replicación variable. Para las cargas de trabajo de producción que requieren un RPO bajo, usa Cross-Cloud Interconnect para establecer una conectividad física dedicada y de alta velocidad entre Google Cloud y tu proveedor de servicios en la nube externo.
En la siguiente tabla, se comparan las características de red entre las conexiones de VPN de IPsec o Internet pública y Cross‑Cloud Interconnect.
| Métrica de red | Internet pública o VPN con IPsec | Cross‑Cloud Interconnect |
|---|---|---|
| Capacidad del vínculo |
De 1.25 Gbps a 3 Gbps por túnel. |
Ancho de banda óptico dedicado de 10 Gbps o 100 Gbps por vínculo |
| Latencia y fluctuación de la red |
Rutas de tránsito de Internet variables e impredecibles |
Enrutamiento privado determinístico y de baja latencia |
| ANS de disponibilidad |
No hay ANS de rendimiento de extremo a extremo. |
ANS de disponibilidad del 99.9% o el 99.99% cuando se configura con conexiones redundantes. |
| Encriptación de la transferencia de datos |
La sobrecarga de IPsec y los límites de la criptografía de software. |
Encriptación de MACsec de velocidad de línea para Cloud Interconnect (IEEE 802.1AE). Para obtener más información, consulta Descripción general de MACsec para Cloud Interconnect. |
| Costos de la transferencia de datos |
Tarifas estándar de salida de Internet. |
Tarifas reducidas de transferencia de datos de Cloud Interconnect. |
Flujo de trabajo de configuración de red de alto nivel
Para configurar Cross‑Cloud Interconnect en tu canalización de replicación, completa estos pasos de alto nivel:
Solicita Cross‑Cloud Interconnect Interconnect: Solicita puertos de Cross‑Cloud Interconnect principales y redundantes en una instalación de colocación que se vincule con la ubicación de tu proveedor de servicios en la nube remoto. Por ejemplo, ejecuta el comando
gcloud compute interconnects create:gcloud compute interconnects create CONNECTION_NAME \ --interconnect-type=DEDICATED \ --link-type=CAPACITY \ --requested-link-count=LINK_COUNT \ --location=GOOGLE_CLOUD_LOCATION \ --remote-location=REMOTE_LOCATION \ --noc-contact-email=CONTACT_EMAILReemplaza lo siguiente:
CONNECTION_NAME: Es el nombre de tu conexión de Cross‑Cloud Interconnect.CAPACITY: Es la capacidad del vínculo, comoLINK_TYPE_ETHERNET_10G_LRoLINK_TYPE_ETHERNET_100G_LR.LINK_COUNT: Es la cantidad de vínculos que se solicitarán.GOOGLE_CLOUD_LOCATION: Es el dominio de disponibilidad perimetral para la ubicación de Google Cloud , por ejemplo,iad-zone1-1.REMOTE_LOCATION: Es la ubicación del proveedor de servicios en la nube remoto, por ejemplo,aws-us-east-1.CONTACT_EMAIL: Es la dirección de correo electrónico de tus operaciones de red.
Para obtener más información, consulta Elige tus ubicaciones y Pide tus puertos de AWS.
Configura Cloud Router y el intercambio de tráfico de BGP: Crea adjuntos de VLAN y configura sesiones del protocolo de puerta de enlace de frontera (BGP) entre Cloud Router en tu red de VPC de Google Cloud y la puerta de enlace privada virtual o la puerta de enlace de conexión directa en tu entorno de nube remoto. Para obtener más información, consulta Descripción general de Cloud Router, Configura tus recursos de Google Cloud y Configura tus recursos de AWS.
Valida la propagación de rutas: Verifica que las tablas de rutas en ambas redes propaguen bloques CIDR que no se superpongan para que los trabajadores de tu canalización de CDC y los nodos de Spanner Omni se comuniquen exclusivamente a través de direcciones IP privadas. Para obtener más información, consulta Verifica tus conexiones.
Para obtener instrucciones de configuración completas, consulta Conéctate a Amazon Web Services en la documentación de Cross‑Cloud Interconnect.
Lista de tareas para la conmutación por error y la guía de instrucciones
Cuando ejecutes un cambio o una conmutación por error de Spanner en Google Cloud a Spanner Omni, sigue estos pasos operativos:
- Agota los cambios en curso: Detén las operaciones de escritura de la aplicación en la base de datos principal de Spanner (si es accesible) y verifica que tu canalización de replicación de CDC haya procesado todos los registros de flujo de cambios hasta la marca de tiempo de confirmación más reciente.
- Redirecciona las conexiones de la aplicación: Actualiza los perfiles de configuración de la aplicación, las cadenas de conexión o los Secrets de Kubernetes para conectarte a tus extremos de Spanner Omni en lugar de Spanner en Google Cloud.
- Actualiza el DNS y el enrutamiento del tráfico: Cambia tus registros DNS o los destinos del balanceador de cargas global para enrutar el tráfico de los clientes al nivel de aplicación y a los balanceadores de cargas que se encuentran frente a tu implementación de Spanner Omni.
- Vuelve a sincronizar después de la recuperación: Después de restablecer el entorno principal deGoogle Cloud , invierte la dirección de replicación antes de conmutar por recuperación. Captura los cambios de Spanner Omni con un flujo de cambios y el conector de Debezium para publicar los cambios en Apache Kafka, con un consumidor que los aplique a Spanner. Como alternativa, puedes exportar tu base de datos de Spanner Omni a archivos Avro en Cloud Storage y, luego, importarlos a Spanner. Para obtener más información, consulta Importa y exporta datos e Importa archivos Avro de Spanner.