Con la aparición de Kubernetes y los operadores, nos han simplificado muchas de nuestras tareas del día a día.
Gestión de clusters de PostgreSQL en k8s con CloudNativePG
En el caso de la gestión de clusters de postgresql en k8s, el operador CloudNativePG (CNP) es un gran aliado. Aconsejamos leer uno de nuestros post sobre este operador aquí.
Si ya estamos familiarizados con CNP y llevamos trabajando con él algún tiempo seguramente se habrá encontrado con la necesidad de ampliar la capacidad de su arquitectura.
Escenario de despliegue y réplica entre datacenters
Supongamos que ya tienen desplegado un cluster de Postgresql gestionado por el operador CNP en un datacenter (A) y por necesidades de su infraestructura (seguridad, disponibilidad, etc…) quiere ampliar su capacidad y dotar de una réplica en otro datacenter (B).
Tipos de Replica Cluster en CloudNativePG
CNP usa el concepto de Replica Cluster que se puede usar principalmente para dos tipos de situaciones:
Standalone Replica Cluster (Read‑Only Workloads)
- Internamente lo denomina «Standalone Replica Cluster».
- La idea es replicar nuestro cluster principal (A), gestionado por CNP en un datacenter, en otro cluster de CNP en otro datacenter (B).
- Las réplicas son de solo lectura, útiles para liberar de carga operativa al cluster principal y usarlo, por ejemplo, para reporting o procesamiento analítico.
- También podría ser usado como entorno de DR.
Distributed Topology (Disaster Recovery (DR) y Alta disponibilidad (HA) )
- Internamente denominado «Distributed Topology».
- Puede ser usado de igual manera que el «Standalone Replica Cluster», pero con la ventaja de permitir una conmutación controlada de un cluster CNP de un datacenter a otro.
- Ideal para escenarios de DR y HA, con conmutación manual sencilla.
Procedimiento de conmutación y recuperación
Básicamente la diferencia entre las dos configuraciones es cómo se realiza la conmutación entre los cluster de CNP y cómo es el procedimiento de recuperación del entorno. Aunque el procedimiento de conmutación entre cluster no es automático, su implementación es muy sencilla, con lo que este tipo de configuraciones nos puede dotar a nuestra infraestructura de una gran capacidad de recuperación y, sobre todo, de seguridad ante posibles desastres.
Conclusiones
El uso de CNP nos puede ayudar a gestionar nuestros cluster de postgresql en k8s y ampliar nuestra capacidad a nivel de seguridad, DR y alta disponibilidad mediante el uso o configuración de la arquitectura «Standalone Replica Cluster» o «Distributed Topology».
En el siguiente post, realizaremos una explicación práctica de cómo implementar y configurar una configuración «Standalone Replica Cluster» o «Distributed Topology».
