vitabaks.postgresql_cluster

Descripción general Versiones Perspectivas

Clúster de Alta Disponibilidad de PostgreSQL :elephant: :sparkling_heart:

Estrellas de GitHub

Clúster de Alta Disponibilidad de PostgreSQL listo para producción (basado en Patroni). Automatización con Ansible.

postgresql_cluster automatiza el despliegue y la gestión de clústeres de PostgreSQL altamente disponibles en entornos de producción. Esta solución está diseñada para ser utilizada en servidores físicos dedicados, máquinas virtuales, y en infraestructuras tanto locales como en la nube.

Puedes encontrar una versión de esta documentación que es buscable y más fácil de navegar en postgresql-cluster.org

:trophy: Utiliza el programa de apoyo para obtener soporte personalizado, o simplemente para contribuir a este proyecto.

Configuraciones soportadas del Clúster de Postgres

postgresql_cluster

Tienes tres esquemas disponibles para el despliegue:

1. Solo Alta Disponibilidad de PostgreSQL

Este es un esquema simple sin balanceo de carga.

Componentes de alta disponibilidad:

Patroni es una plantilla para que crees tu propia solución personalizada de alta disponibilidad usando Python y, para máxima accesibilidad, un almacén de configuración distribuido como ZooKeeper, etcd, Consul o Kubernetes. Se utiliza para automatizar la gestión de instancias de PostgreSQL y la conmutación automática en caso de fallos.
etcd es un almacén de claves y valores distribuido y fiable para los datos más críticos de un sistema distribuido. etcd está escrito en Go y utiliza el algoritmo de consenso Raft para manejar un registro replicado altamente disponible. Es utilizado por Patroni para almacenar información sobre el estado del clúster y parámetros de configuración de PostgreSQL. ¿Qué es el Consenso Distribuido?
vip-manager (opcional, si se especifica la variable cluster_vip) es un servicio que se inicia en todos los nodos del clúster y se conecta al DCS. Si el nodo local posee la clave de líder, vip-manager inicia la VIP configurada. En caso de un failover, vip-manager elimina la VIP en el antiguo líder y el servicio correspondiente en el nuevo líder la inicia allí. Se utiliza para proporcionar un único punto de entrada (VIP) para el acceso a la base de datos.
PgBouncer (opcional, si la variable pgbouncer_install es true) es un agrupador de conexiones para PostgreSQL.

2. Alta Disponibilidad de PostgreSQL con Balanceo de Carga

Este esquema permite la distribución de la carga para las operaciones de lectura y también permite escalar el clúster con réplicas de solo lectura.

Al desplegar en proveedores de la nube como AWS, GCP, Azure, DigitalOcean y Hetzner Cloud, un balanceador de carga de la nube se crea automáticamente por defecto para proporcionar un único punto de entrada a la base de datos (controlado por la variable cloud_load_balancer).

Para entornos no en la nube, como cuando se despliega en tus propios equipos, se encuentra disponible el balanceador de carga HAProxy. Para habilitarlo, establece with_haproxy_load_balancing: true en el archivo vars/main.yml.

:heavy_exclamation_mark: Nota: Tu aplicación debe tener soporte para enviar solicitudes de lectura a un puerto personalizado 5001 y solicitudes de escritura al puerto 5000.

puerto 5000 (lectura/escritura) maestro
puerto 5001 (solo lectura) todas las réplicas

si la variable "synchronous_mode" es 'true' (vars/main.yml):

puerto 5002 (solo lectura) réplica sincrónica únicamente
puerto 5003 (solo lectura) réplicas asincrónicas únicamente

Componentes del balanceo de carga HAProxy:

HAProxy es una solución gratuita, muy rápida y confiable que ofrece alta disponibilidad, balanceo de carga y proxying para aplicaciones basadas en TCP y HTTP.
confd gestiona archivos de configuración locales de aplicación usando plantillas y datos de etcd o consul. Se utiliza para automatizar la gestión de archivos de configuración de HAProxy.
Keepalived (opcional, si se especifica la variable cluster_vip) proporciona una dirección IP virtual de alta disponibilidad (VIP) y un único punto de entrada para el acceso a las bases de datos. Implementa VRRP (Protocolo de Redundancia de Router Virtual) para Linux. En nuestra configuración, keepalived verifica el estado del servicio HAProxy y, en caso de fallo, delega la VIP a otro servidor en el clúster.

3. Alta Disponibilidad de PostgreSQL con Descubrimiento de Servicio Consul

Para usar este esquema, especifica dcs_type: consul en el archivo de variables vars/main.yml.

Este esquema es adecuado para acceso solo a maestro y para balanceo de carga (usando DNS) para la lectura a través de réplicas. El Descubrimiento de Servicios de Consul con resolución DNS se utiliza como punto de acceso del cliente a la base de datos.

Punto de acceso del cliente (ejemplo):

master.postgres-cluster.service.consul
replica.postgres-cluster.service.consul

Además, puede ser útil para un clúster distribuido a través de diferentes centros de datos. Podemos especificar por adelantado en qué centro de datos se encuentra el servidor de base de datos y luego usar esto para aplicaciones que se ejecutan en el mismo centro de datos.

Ejemplo: replica.postgres-cluster.service.dc1.consul, replica.postgres-cluster.service.dc2.consul

Se requiere la instalación de Consul en modo cliente en cada servidor de aplicación para la resolución DNS del servicio (o usar resolución DNS remota en lugar de instalar un cliente local de Consul).

Compatibilidad

Distribuciones basadas en RedHat y Debian (x86_64)

Distribuciones de Linux soportadas:

Debian: 11, 12
Ubuntu: 22.04, 24.04
CentOS Stream: 9
Oracle Linux: 8, 9
Rocky Linux: 8, 9
AlmaLinux: 8, 9

Versiones de PostgreSQL:

todas las versiones de PostgreSQL soportadas

:white_check_mark: probado, funciona bien: PostgreSQL 10, 11, 12, 13, 14, 15, 16

Tabla de resultados de pruebas automatizadas diarias de despliegue de clúster:

Distribución	Resultado de prueba
Debian 11
Debian 12
Ubuntu 22.04
Ubuntu 24.04
CentOS Stream 9
Oracle Linux 8
Oracle Linux 9
Rocky Linux 8
Rocky Linux 9
AlmaLinux 8
AlmaLinux 9

Versión de Ansible

Versión mínima soportada de Ansible: 8.0.0 (ansible-core 2.15.0)

Requisitos

Haz clic aquí para expandir...

Este playbook requiere privilegios de root o sudo.

Ansible (¿Qué es Ansible??)

si dcs_type: "consul", por favor instala los requisitos del rol de Consul en el nodo de control:

ansible-galaxy install -r roles/consul/requirements.yml

Requisitos de puertos

Lista de puertos TCP requeridos que deben estar abiertos para el clúster de bases de datos:

5432 (postgresql)
6432 (pgbouncer)
8008 (API REST de patroni)
2379, 2380 (etcd)

para el esquema "[Tipo A] Alta Disponibilidad de PostgreSQL con Balanceo de Carga":

5000 (haproxy - (lectura/escritura) maestro)
5001 (haproxy - (solo lectura) todas las réplicas)
5002 (haproxy - (solo lectura) réplica sincrónica únicamente)
5003 (haproxy - (solo lectura) réplicas asincrónicas únicamente)
7000 (opcional, estadísticas de haproxy)

para el esquema "[Tipo C] Alta Disponibilidad de PostgreSQL con Descubrimiento de Servicio Consul (DNS)":

8300 (RPC de servidor Consul)
8301 (Consul Serf LAN)
8302 (Consul Serf WAN)
8500 (API HTTP de Consul)
8600 (servidor DNS de Consul)

Recomendaciones

Haz clic aquí para expandir...

linux (Sistema Operativo):

Actualiza tu sistema operativo en tus servidores objetivo antes de desplegar;

Asegúrate de que la sincronización de tiempo esté configurada (NTP). Especifica ntp_enabled:'true' y ntp_servers si deseas instalar y configurar el servicio ntp.

DCS (Almacén de Consenso Distribuido):

Los discos rápidos y una red fiable son los factores más importantes para el rendimiento y la estabilidad de un clúster de etcd (o consul).

Evita almacenar los datos de etcd (o consul) en el mismo disco junto con otros procesos (como la base de datos) que usan intensivamente los recursos del subsistema de disco. Almacena los datos de etcd y postgres en discos diferentes (ver variables etcd_data_dir, consul_data_path), usa unidades SSD si es posible. Consulta las recomendaciones de hardware y guías de ajuste.

Se recomienda desplegar el clúster DCS en servidores dedicados, separados de los servidores de bases de datos.

Ubicación de miembros del clúster en diferentes centros de datos:

Si prefieres una configuración de centros de datos cruzados, donde las bases de datos replicadas se encuentran en diferentes centros de datos, la ubicación de los miembros de etcd se vuelve crítica.

Hay muchas cosas a considerar si deseas crear un clúster de etcd realmente robusto, pero hay una regla: no coloques todos los miembros de etcd en tu centro de datos principal. Consulta algunos ejemplos.

Cómo prevenir la pérdida de datos en caso de conmutación automática (modes sincrónicos):

Por razones de rendimiento, la replicación sincrónica está desactivada por defecto.

Para minimizar el riesgo de perder datos en la conmutación automática, puedes configurar los ajustes de la siguiente manera:

synchronous_mode: 'true'
synchronous_mode_strict: 'true'
synchronous_commit: 'on' (o 'remote_apply')

Comenzando

Para ejecutar la Consola del Clúster de PostgreSQL, ejecuta el siguiente comando:

docker run -d --name pg-console \
  --publish 80:80 \
  --publish 8080:8080 \
  --env PG_CONSOLE_API_URL=http://localhost:8080/api/v1 \
  --env PG_CONSOLE_AUTHORIZATION_TOKEN=secret_token \
  --volume console_postgres:/var/lib/postgresql \
  --volume /var/run/docker.sock:/var/run/docker.sock \
  --volume /tmp/ansible:/tmp/ansible \
  --restart=unless-stopped \
  vitabaks/postgresql_cluster_console:2.0.0

Nota: Se recomienda ejecutar la consola en la misma red que tus servidores de bases de datos para habilitar el monitoreo del estado del clúster. En este caso, reemplaza localhost con la dirección IP de tu servidor en la variable PG_CONSOLE_API_URL.

Abrir la interfaz de la consola

Dirígete a http://localhost/ y usa secret_token para la autorización.

Nota: Si has configurado la consola en un servidor diferente, reemplaza 'localhost' por la dirección del servidor. Utiliza el valor de tu token si lo has redefinido en la variable PG_CONSOLE_AUTHORIZATION_TOKEN.

Haz clic aquí para expandir... si prefieres la línea de comandos.

Línea de comandos

Instala Ansible en un nodo de control (que podría ser fácilmente una laptop)

sudo apt update && sudo apt install -y python3-pip sshpass git
pip3 install ansible

Descarga o clona este repositorio

git clone https://github.com/vitabaks/postgresql_cluster.git

Ve al directorio del playbook

cd postgresql_cluster/automation

Edita el archivo de inventario

Especifica direcciones IP (no públicas) y configuraciones de conexión (`ansible_user`, `ansible_ssh_pass` o `ansible_ssh_private_key_file` para tu entorno)

nano inventory

Edita el archivo de variables vars/main.yml

nano vars/main.yml

Conjunto mínimo de variables:

proxy_env # si es necesario (para descargar paquetes)
cluster_vip # para el acceso de clientes a bases de datos en el clúster (opcional)
patroni_cluster_name
postgresql_version
postgresql_data_dir
with_haproxy_load_balancing 'true' (Tipo A) o 'false'/por defecto (Tipo B)
dcs_type # "etcd" (por defecto) o "consul" (Tipo C)

Consulta los archivos vars/main.yml, system.yml y (Debian.yml o RedHat.yml) para más detalles.

si dcs_type: "consul", por favor instala los requisitos del rol de Consul en el nodo de control:

ansible-galaxy install -r roles/consul/requirements.yml

Intenta conectar a los hosts

ansible all -m ping

Ejecuta el playbook:

ansible-playbook deploy_pgcluster.yml

Desplegar Clúster con TimescaleDB

Para desplegar un Clúster de Alta Disponibilidad de PostgreSQL con la extensión TimescaleDB, solo necesitas añadir la variable enable_timescale.

Ejemplo:

ansible-playbook deploy_pgcluster.yml -e "enable_timescale=true"

Cómo empezar desde cero

Si necesitas empezar desde el principio, puedes utilizar el playbook remove_cluster.yml.

Variables disponibles:

remove_postgres: detener el servicio de PostgreSQL y eliminar datos.
remove_etcd: detener el servicio de ETCD y eliminar datos.
remove_consul: detener el servicio de Consul y eliminar datos.

Ejecuta el siguiente comando para eliminar componentes específicos:

ansible-playbook remove_cluster.yml -e "remove_postgres=true remove_etcd=true"

Este comando eliminará los componentes especificados, permitiéndote comenzar una nueva instalación desde cero.

:warning: Cuidado: ten cuidado al ejecutar este comando en un entorno de producción.

¡Danos una estrella!

Si encuentras útil nuestro proyecto, ¡considera darnos una estrella en GitHub! Tu apoyo nos ayuda a crecer y nos motiva a seguir mejorando. Darle una estrella al proyecto es una manera simple y efectiva de mostrar tu aprecio y ayudar a otros a descubrirlo.

Patrocina este proyecto

Al patrocinar nuestro proyecto, contribuyes directamente a su mejora continua e innovación. Como patrocinador, recibirás beneficios exclusivos, incluido soporte personalizado, acceso anticipado a nuevas características y la oportunidad de influir en la dirección del proyecto. Tu patrocinio es invaluable para nosotros y ayuda a garantizar la sostenibilidad y el progreso del proyecto.

¡Conviértete en patrocinador hoy y ayúdanos a llevar este proyecto al siguiente nivel!

Apoya nuestro trabajo a través de GitHub Sponsors