Esta arquitectura de referencia es más adecuada para los siguientes casos de uso:
- Necesitas protección regional además de la protección zonal para tus aplicaciones críticas para la misión.
Esta arquitectura de referencia de disponibilidad incorpora réplicas de lectura dentro de la región para la alta disponibilidad y en todas las regiones para la DR. Esta implementación multirregional protege contra interrupciones significativas, como fallas eléctricas generalizadas y desastres naturales a gran escala.
Consideraciones sobre la arquitectura de referencia de disponibilidad
Cuando evalúes esta arquitectura de referencia de disponibilidad, ten en cuenta los siguientes factores:
- Latencia y ancho de banda de la red dentro de la región y entre regiones
- Ubicación geográfica de las bases de datos y los servidores de aplicaciones
- Estrategia para descargar cargas de trabajo de solo lectura en réplicas
- Implementa la alta disponibilidad en la región de DR remota
Es posible que se requiera un balanceo de cargas de solo lectura, en especial si usas servidores de aplicaciones regionales, de modo que las solicitudes se reenvíen a la base de datos más cercana para obtener la respuesta más rápida. Para obtener más información, consulta Solicita el enrutamiento a un balanceador de cargas de aplicaciones clásico multirregional.
Es posible que se requiera supervisación adicional para la replicación entre regiones para garantizar que la demora de replicación no comience a aumentar debido a la carga de transacciones o la capacidad de la red.
Para garantizar que tu DR sea exitoso, asegúrate de realizar pruebas exhaustivas. Es importante probar la funcionalidad y la capacidad de procesamiento de la aplicación si hay conexiones de red de alta latencia entre los servidores de aplicaciones y la base de datos.
Arquitecturas de alta disponibilidad en la región y de DR entre regiones
En la figura 1, se muestra una configuración sugerida de HA y DR con tres bases de datos de reserva de réplica de lectura en tres zonas de disponibilidad y dos regiones.
Figura 1. AlloyDB Omni con opciones de copias de seguridad y alta disponibilidad entre regiones.
Como se ilustra en la Figura 1, la replicación de transmisión síncrona a réplicas locales (dentro de la misma región) proporciona alta disponibilidad, mientras que la replicación de transmisión asíncrona a una réplica remota separada geográficamente proporciona protección de recuperación ante desastres regionales. En toda la configuración, solo la instancia principal puede realizar operaciones de lectura y escritura, mientras que las otras réplicas pueden atender consultas de lectura.
Configura la replicación de la instancia principal a las réplicas de la misma región en modo síncrono, mientras que la replicación a las réplicas entre regiones se debe configurar en modo asíncrono para evitar que la latencia afecte el rendimiento de escritura de la instancia principal. En caso de una falla regional, esta configuración podría generar un RPO distinto de cero. Sin embargo, esta configuración permite un RTO más rápido en caso de falla. Esto se debe a que la base de datos principal no necesita esperar la confirmación de las bases de datos en espera remotas antes de confirmar las transacciones.
Es posible que las copias de seguridad entre regiones adicionales se realicen desde las bases de datos de réplica de lectura y, de este modo, se agregue redundancia a las copias de seguridad que se realizan desde la base de datos principal.
Copias de seguridad de réplicas de lectura
Cuando usas implementaciones de Kubernetes, la implementación secundaria en la región alternativa se configura automáticamente con copias de seguridad adicionales. Cuando usas implementaciones que no son de Kubernetes, puedes optar por implementar copias de seguridad para satisfacer las necesidades de tu empresa. Ten en cuenta lo siguiente:
- Si tu copia de seguridad remota puede ser susceptible a fallas regionales, debes iniciar copias de seguridad adicionales en las regiones alternativas.
- Si necesitas redundancia de copias de seguridad, debes crear copias de seguridad de réplicas de lectura regionales.
Ubicación de la réplica de lectura para admitir la disponibilidad en varias zonas
En las implementaciones que no son de Kubernetes, puedes elegir réplicas de lectura específicas para que asuman el rol de principal en caso de que falle la principal. El operador de Kubernetes de AlloyDB Omni controla automáticamente la ubicación de los nodos en las zonas y los nodos en los que se deben implementar los Pods. Algunas opciones de configuración que afectan la colocación, como la afinidad y la tolerancia de los Pods, están disponibles en la configuración de la base de datos que se usa para implementar con el operador de AlloyDB Omni.
Migración de una arquitectura de solo HA a una arquitectura de HA y DR
En el caso de las implementaciones que no son de Kubernetes, debes compilar un nuevo servidor en espera en una región nueva y agregar esta configuración a la configuración del clúster de Patroni. En el caso de las implementaciones de Kubernetes, debes compilar una nueva implementación regional de Kubernetes, llamada clúster de base de datos secundaria, y habilitar la replicación entre centros de datos.
Implementación
Cuando elijas una arquitectura de referencia de disponibilidad, ten en cuenta los siguientes beneficios, limitaciones y opciones.
Beneficios
- Protege contra fallas zonales y de instancias
- Protección contra errores regionales
- Se reduce el RTO cuando la base de datos experimenta una falla regional
Limitaciones
- Puedes reducir el RPO para la recuperación regional con la replicación síncrona, pero este enfoque genera latencia adicional para el rendimiento de las transacciones. Para la replicación en regiones remotas y la recuperación ante desastres, te recomendamos que uses solo la replicación asíncrona.
- La configuración de la transmisión de WAL de PostgreSQL en modo síncrono ofrece cero pérdida de datos (
RPO=0
) durante el funcionamiento normal o las conmutaciones por error típicas. Sin embargo, este enfoque no protege contra la pérdida de datos en situaciones específicas de doble falla, como cuando se pierden todas las instancias en espera o dejan de ser accesibles desde la instancia principal, y esto es seguido inmediatamente por un reinicio de la instancia principal.
Opciones de protección de datos
- La arquitectura de disponibilidad estándar para las opciones de copia de seguridad y recuperación
- La arquitectura de disponibilidad mejorada para las opciones de alta disponibilidad
¿Qué sigue?
- Descripción general de la arquitectura de referencia de disponibilidad de AlloyDB Omni.
- Disponibilidad estándar de AlloyDB Omni.
- Disponibilidad mejorada de AlloyDB Omni.
- Trabaja con la replicación entre centros de datos.
- Solicita el enrutamiento a un balanceador de cargas de aplicaciones clásico multirregional..