Los balanceadores de carga son un componente esencial de cualquier configuración de base de datos de alta disponibilidad. Se utilizan para aumentar la capacidad y la confiabilidad de sus sistemas y aplicaciones críticos al evitar que un servidor se sobrecargue. Hablamos mucho sobre ellos en el blog de Variousnines, por ejemplo, por qué los necesita y cómo funcionan. Uno de los balanceadores de carga más populares disponibles para MySQL y MariaDB es HAProxy.
En cuanto a las características, HAProxy no es comparable a ProxySQL o MaxScale. Sin embargo, HAProxy es un balanceador de carga robusto y rápido que funcionará perfectamente bien en cualquier entorno, siempre que la aplicación pueda realizar la división de lectura/escritura y enviar consultas SELECT a un backend y todas las escrituras y SELECT...FOR UPDATE a un servidor separado. backend.
Es muy importante hacer un seguimiento de todas las métricas disponibles por HAProxy; debe poder conocer el estado de su proxy, especialmente para saber si ha encontrado algún problema.
ClusterControl siempre ha puesto a disposición una página de estado de HAProxy que muestra el estado del proxy en tiempo real. Ahora, con los nuevos paneles SCUMM (Severalnines ClusterControl Unified Monitoring &Management) basados en Prometheus, es posible rastrear fácilmente cómo cambian esas métricas con el tiempo.
Esta publicación de blog explorará las diferentes métricas presentadas en el panel de HAProxy SCUMM.
Exploración del panel HAProxy en ClusterControl
Todos los paneles de Prometheus y SCUMM están deshabilitados de forma predeterminada en ClusterControl. Sin embargo, implementarlos para cualquier clúster dado es solo cuestión de un clic. Si supervisa varios clústeres con ClusterControl, puede reutilizar la misma instancia de Prometheus para cada clúster.
Una vez implementado, puede acceder al panel de HAProxy. Echemos un vistazo a los datos disponibles en el panel:
Lo primero que verá cuando navegue hasta el panel de HAProxy es información sobre el estado de sus backends. Aquí, tenga en cuenta que lo que ve puede depender del tipo de clúster y de cómo haya implementado HAProxy. En este caso, implementamos un clúster de Galera y HAProxy se implementó de forma rotativa. Por lo tanto, verá tres backends para lecturas y tres para escrituras:seis en total. Esta es también la razón por la que ve todos los backends marcados como "Up".
En un escenario con un clúster de replicación, las cosas se verán diferentes ya que HAProxy se implementará en una división de lectura/escritura, y los scripts mantendrán solo un host (maestro) en funcionamiento en el escritor. backend.
Aviso, esta es la razón por la que a continuación verá dos servidores backend marcados como "Down":
En el siguiente gráfico, verá los datos enviados y recibidos por ambos backend (desde HAProxy a los servidores de la base de datos) y frontend (entre HAProxy y los hosts del cliente):
También puede verificar la distribución del tráfico entre backends en su configuración de HAProxy. En este caso, tenemos dos backends y las consultas se envían a través del puerto 3308, que actúa como el punto de acceso rotativo a nuestro clúster de Galera:
A continuación, puede ver cómo se distribuyó el tráfico entre todos los servidores back-end. En este escenario, debido al patrón de acceso por turnos, los datos se distribuyeron de manera más o menos uniforme en los tres servidores backend de Galera:
Información sobre sesiones, incluidas cuántas sesiones se abrieron desde HAProxy al backend servidores, también pueden ser monitoreados, como se ve en el siguiente gráfico. También puede realizar un seguimiento de cuántas veces por segundo se abrió una nueva sesión en el backend y cómo se ven esas métricas por servidor backend.
Los siguientes dos gráficos muestran el número máximo de sesiones por servidor backend y cuándo aparecieron problemas de conectividad. Esto puede ser muy útil para fines de depuración cuando se produce un error de configuración en la instancia de HAProxy y las conexiones comienzan a fallar.
Este siguiente gráfico es potencialmente más valioso ya que muestra varias métricas relacionadas con el error manejo, como errores, errores de solicitud, reintentos en el backend, etc. También hay un gráfico de "Sesiones" que muestra una descripción general de las métricas de la sesión.
Aquí puede ver que ClusterControl rastrea los errores de conexión en tiempo real, que puede ayudar a identificar el momento preciso en que los problemas comenzaron a evolucionar.
Por último, veremos los siguientes dos gráficos relacionados con las solicitudes en cola . HAProxy pone en cola las solicitudes al backend si los servidores backend están sobresaturados. Esto puede apuntar, por ejemplo, a los servidores de bases de datos sobrecargados, que no pueden manejar más tráfico.
Conclusión
Implementar y monitorear su balanceador de carga HAProxy en ClusterControl puede ayudar a facilitar el trabajo de administrar y monitorear sus conexiones. Tener una visibilidad clara del rendimiento de sus backends, la distribución del tráfico, las métricas de sesión, los errores de conexión y la cantidad de solicitudes en cola puede ayudar a garantizar la disponibilidad y la escalabilidad de cualquier configuración de base de datos.
ClusterControl hace que configurar y monitorear balanceadores de carga sea muy fácil para cualquier configuración de base de datos. ¿Aún no usas ClusterControl? Si desea ver por sí mismo lo fácil que es implementar y monitorear su balanceador de carga HAProxy con ClusterControl, lo invitamos a una prueba gratuita de 30 días de la plataforma, sin condiciones. Para obtener una explicación más detallada de por qué y cómo usar HAProxy para el equilibrio de carga, consulte nuestro tutorial sobre equilibrio de carga de MySQL con HAProxy.
