Alta disponibilidad de sus base de datos con Percona XtraDB Cluster en Kubernetes

Uno de los grandes retos al que nos podemos enfrentar cuando una aplicación crece, es la expansión a otras regiones, implicando nuevos retos tecnológicos a nivel de infraestructura. El problema es que si tu infraestructura está en una región y tus clientes acceden a la aplicación desde otra, la latencia se incrementa cuanto mayor sea la distancia… Esto hace que se incremente a su vez el tiempo de carga y merme la “experiencia” de uso de dicha aplicación. Cuando usas clouds públicos como AWS, Azure o Google Cloud realmente no es muy complejo pues los mismos te dan las herramientas necesarias para lograrlo, en cambio cuando tienes una infraestructura hidrida o simplemente cuentas con servidores propios debes crear dicha infraestructura

Para ello muchas empresas optan por dos opciones principales a la hora de expandir su aplicación por el mundo:

  1. Colocar CDNs y nodos en otras regiones los cuales hacen que el contenido cargue mucho más rápido, que si tienen que conectarse a la infraestructura de la región de origen. El problema de esto reside en que al final, si tienen que interaccionar con una base de datos muy frecuentemente el tiempo de carga sigue siendo bastante lento, ya que las consultas tienen que atravesar diversas regiones.
  2. Para solventar el problema anterior con las bases de datos, lo que se suele hacer es desplegar otra infraestructura nueva en la nueva región y «forzar» a los clientes de esa región que utilicen esa infraestructura, por ejemplo:
  • Si resides en Cuba, utilizarás el nombre de dominio aplicación.cu que corresponderá a la infraestructura de Cuba.
  • Si resides en España, utilizarás el nombre de dominio aplicación.es que corresponderá a la infraestructura de España.

    Los grandes inconvenientes en estos casos podrían ser:

  1. Mantenimiento y operatividad en ambas regiones; al tener varias infraestructuras el coste de mantener actualizada ambas es mayor, así como toda la monitorización y gestión de las mismas para que funcionen en “paralelo”.
  2. En caso de que un cliente se moviese de región por trabajo volvería a tener el problema de la latencia y mala experiencia de uso.

Para ello existen muchas soluciones en el mercado, pero a mi parecer me centraré en una que me ha dado muy buen resultado y es la combinación de varias tecnologías como:

Percona XtraDB Cluster como solución principal junto con  ProxySQL + Kubernetes + Percona XtraDB + Percona Management & Monitoring como complementos para hacer perfecta la operatividad.

Es por ello que la solución planteada sería la siguiente:

  • Utilizar Percona XtraDB Cluster como solución principal para crear un cluster de bases de datos de tipo maestro-maestro, consiguiendo replicar la información entre todas ellas en tiempo real. Haciendo todos los nodos primarios tanto de lectura como de escritura.
  • Utilizar ProxySQL para las peticiones y distribución de las consultas SQL, este software nos permite una escalabilidad inmensa si se utiliza con Kubernetes llegando a soportar más de 100k peticiones, pudiendo clasificar las consultas para mandarlas a un servidor u otro, alta disponibilidad y con un firewall adicional de acceso.
  • Utilizar Percona XtraDB Backup como solución a realizar backups en cada uno de los nodos, ya que esta solución permite el no bloquear las bases de datos en producción y lo hace óptimo para poder automatizar backups sobre la misma.
  • Por último para una correcta monitorización de toda esta nueva infraestructura haremos uso de PMM, el cual consiste en disponer de unos servicios que se conectan a cada uno de los clusters de Percona y podemos representar lo que está sucediendo utilizando Grafana.

Este sería el esquema de arquitectura empleado para la solución:

Para preparar este entorno sugiero usar k3s ya a su poco consumo y fácil despliege, supongamos que tenemos cuatro servidores que queremos usar para nuestras implementaciones de Kubernetes: un nodo master y tres nodos workers. En mi caso:

beast-node1-ubuntu (master)
beast-node2-ubuntu
beast-node3-ubuntu
beast-node4-ubuntu

En el master ejecutamos:

Para el paso dos, necesitamos preparar un script y necesitamos dos parámetros: la dirección IP del master y el token del mismo. Encontrar el token es probablemente la parte más complicada de esta configuración y está almacenado en el archivo /var/lib/rancher/k3s/server/node-token.

Teniendo estos parámetros, el script para otros nodos es:

Luego de ejecutar este script en otros nodos ya tendremos nuestro Kubernetes ejecutándose:

Esto es suficiente para una configuración básica de Kubernetes, para instalar el Percona usaremos kubectl.

Instalar Percona XtraDB Cluster en Kubernetes

Para instalar el Operador de Percona en Kubernetes usaremos el siguiente comando, pero antes crearemos un namespace para que toda la informacion del mismo este en dicho lugar

Una vez operativo el Operador desplegamos entonces el Percona XtraDB Cluster:

Nota: si vez que tu cluster no inicia revisa que CPU tengas puesto pues algunas veces da este problema

Una vez que arregles el CPU reinicias las instancias y procedes a comprobar el cluster.

Como comprobar el Percona XtraDB Cluster en Kubernetes

Es posible que el clúster tarde diez minutos en iniciarse. Cuando el comando kubectl get pxc -n percona finalmente le muestre el estado del clúster como listo, puede intentar conectarse al clúster.

Necesitará el nombre de usuario y la contraseña para que el usuario administrador acceda al clúster. Utilice el comando kubectl get secrets para ver la lista de objetos Secrets (de forma predeterminada, el objeto Secrets que le interesa tiene el nombre cluster1-secrets). Puede utilizar el siguiente comando para obtener la contraseña del usuario root:

Ejecute un contenedor con la herramienta mysql y conecte la salida de su consola a su terminal. El siguiente comando hará esto, nombrando al nuevo Pod percona-client:

Ejecutarlo puede requerir algo de tiempo para implementar el Pod correspondiente.

Ahora ejecute la herramienta mysql en el shell de comandos de percona-client usando la contraseña obtenida del secreto. El comando tendrá un aspecto diferente dependiendo de si su clúster proporciona equilibrio de carga con HAProxy (la opción predeterminada) o ProxySQL:

HAProxy:

ProxySQL:

Una vez dentro si quieres comprobar cuantos instancias o replicas tiene el cluster puedes hacerlo con el siguiente comando dentro del mysql

Dado que este operador es un recurso personalizado, podemos manipular el recurso perconaxtradbcluster para que le guste el recurso estándar de Kubernetes:

Al observar el conjunto de cargas de trabajo, podemos ver que el operador ha creado dos StatefulSets:

El operador también creará los servicios correspondientes que equilibrarán la carga de las conexiones a los respectivos pods:

Bibliografia

Si deseas personalizar y mejorar mejor su cluster puedes seguir la guia oficial de percona ygual recomiendo este articulo de Irontec donde pueden obtener varias optimizaciones.

¿De cuánta utilidad te ha parecido este contenido?

¡Haz clic en una estrella para puntuar!

Promedio de puntuación 5 / 5. Recuento de votos: 2

Hasta ahora, ¡no hay votos!. Sé el primero en puntuar este contenido.

Sobre Armando Felipe Fuentes Denis 82 artículos
Director de Infraestructura en Guajiritos S.R.L.

Sé el primero en comentar

Dejar una contestacion

Tu dirección de correo electrónico no será publicada.


*