En la continuación de la serie sobre Patroni que encontrarás en el blog, vamos a ver cómo escalar nuestro cluster. Para ello, partimos de la base tratada en el anterior post sobre la alta disponibilidad en PostgreSQL, que si no lo has visto o necesitas refrescar la memoria, aquí te lo dejamos.

Pero… ¿Por qué escalar?

Nos referimos a escalar a la capacidad de llevar a cabo una ampliación de los recursos del mismo, cuando hablamos de un sistema informático. Si este sistema es elástico podremos, además de ampliar, reducir los recursos. Esta ampliación puede ser de dos tipos: escalado horizontal o escalado vertical. El escalado horizontal consiste en añadir más instancias como las que está prestando ya el servicio, mientras que el escalado vertical consiste en ampliar los recursos de las instancias ya existentes.

El tipo de escalado que llevemos a cabo dependerá de las necesidades que tengamos. En nuestro caso concreto, con Patroni podemos disponer de un nodo de lectura y escritura y múltiples nodos de solo lecturas. Por lo tanto, si queremos ajustar nuestro sistema para un cambio en el volumen de escrituras, será necesario un escalado vertical, mientras que si lo queremos hacer para las lecturas, podemos utilizar un escalado horizontal.

Escalado vertical

El escalado vertical en Patroni es realmente sencillo si nos encontramos en un entorno cloud. Para ello, solo tendremos que apagar las instancias y asignar los nuevos recursos. Es importante tener en cuenta que dependiendo del tipo de entorno en el que estemos trabajando, deberemos llevar a cabo estas acciones primando la disponibilidad del servicio. Por lo tanto, tendremos que hacerlo siempre sobre nodos de lectura y siempre y cuando sea posible ofrecer el servicio con el resto de instancias de lectura.

Es importante, una vez disponemos de los nuevos recursos, ajustar las configuraciones de PostgreSQL para el nuevo tamaño, de lo contrario el cambio puede no tener ningún efecto práctico. Si estás interesado en saber más sobre el tuning en PostgreSQL, no dudes en escribirnos por redes sociales para que hagamos un artículo al respecto.

Escalado horizontal

En cuanto al escalado horizontal podemos añadir instancias (scale out) o eliminarlas (scale in).

Comenzamos tratando el scale in. En este caso no es necesario parar ninguna de las instancias durante el proceso, pero es importante tener en cuenta que para completar la puesta en marcha se necesita sincronizar toda la información de la bbdd al nuevo nodo y esto puede afectar al rendimiento del sistema.

Para el scale out simplemente tenemos que seguir los pasos de la puesta en marcha tratados en el anterior post de esta serie pero teniendo en cuenta que ya tenemos nodos en funcionamiento:

• Actualizar la configuración de Patroni incluyendo en el pg_hba la ip del nuevo servidor con los permisos necesarios de replicación. Lanzar sobre los nodos existentes y asegurarse de que sí se ha modificado el pb_hba en /var/lib/postgresql/<version>/main/pg_hba.conf.
• Instalar postgres, parar el servicio y eliminar el contenido de /var/lib/postgresql/<version>/main.
• Instalar etcd y unir el nuevo nodo al cluster. Este paso es opcional, ya que no es necesario tener tantos nodos de etcd como nodos de Patroni.
• Instalar el servicio de watchdog si el cluster actual también cuenta con él.
• Instalar Patroni, cargar la configuración, habilitar y reiniciar el servicio.

Llevar a cabo un scale in es mucho más sencillo. Para ello solo tenemos que parar el servicio de Patroni, momento en el cuál dejamos de ver ese nodo desde el resto.

Si además contamos con el servicio de etcd también en esa instancia, deberemos eliminarlo del cluster con el comando.

etcdctl member remove <id>

Una vez realizados estos pasos, la instancia está completamente fuera del cluster. Así, podemos llevar a cabo otros trabajos de limpieza como desinstalar PostgreSQL y eliminar los datos, o directamente eliminar la instancia sin que afecte al servicio.

Como has podido comprobar, escalar un cluster de Patroni es realmente sencillo, sobre todo una vez dominada la puesta en marcha del cluster. En futuras entregas de esta serie trataremos otros temas de la administración del cluster como los cambios de servicio o la recuperación de la replicación. Mientras tanto, puedes ver alguno de nuestros artículos que tratan este tema como el bloat en PostgreSQL.