Cómo optimizar el rendimiento de ClusterControl y sus componentes

La supervisión y la gestión son fundamentales para cualquier entorno de producción porque el rendimiento importa. Las interfaces de usuario lentas que se retrasan o no responden, las alertas retrasadas y los tiempos de espera de trabajo del clúster cuando el servidor carece de recursos son cosas que pueden causar problemas. Hay formas de mejorar el rendimiento de ClusterControl, especialmente si administra varios clústeres y cada clúster contiene varios nodos. Este blog proporciona algunos consejos de ajuste. Los puntos elaborados aquí están seleccionados en función de nuestra experiencia en el manejo de problemas de rendimiento informados por nuestros usuarios y clientes.

Como introducción, ClusterControl consta de varios componentes principales:una aplicación web (frontend) basada en PHP y varios procesos demonizados (backend). Estos aprovechan una base de datos MySQL/MariaDB para el almacenamiento persistente. Está controlando efectivamente su clúster desde la aplicación web, que se traducirá en una serie de llamadas de proceso ejecutadas por los procesos de back-end para administrar y monitorear sus clústeres de base de datos.

Base de datos MySQL

Los componentes de ClusterControl se basan en una base de datos MySQL o MariaDB como almacenamiento persistente para monitorear los datos recopilados de los nodos administrados y todos los metadatos de ClusterControl (p. ej., qué trabajos hay en la cola, programas de respaldo, estados de respaldo, etc.). De forma predeterminada, la secuencia de comandos del instalador instalará cualquier versión que venga del repositorio estándar del sistema operativo. La siguiente es la versión de MySQL/MariaDB que está instalando el instalador:

• CentOS/Redhat 6 - MySQL 5.1

• CentOS/Redhat 7 - MariaDB 5.5

• Ubuntu 18.04 (Biónico) - MySQL 5.7

• Ubuntu 16.04 (Xenial) - MySQL 5.7

• Ubuntu 14.04 (Confiable) - MySQL 5.5

• Debian 9 (Stretch) - MySQL 5.5

• Debian 8 (Jessie) - MySQL 5.5

• Debian 7 (Wheezy) - MySQL 5.5

La secuencia de comandos del instalador haría algunos ajustes básicos, como configurar la ubicación del directorio de datos, el puerto de MySQL, el usuario y el tamaño del grupo de búfer de InnoDB al comienzo de la etapa de instalación. Sin embargo, es posible que el ajuste no sea adecuado una vez que haya importado o creado más clústeres/nodos. Con una mayor cantidad de nodos para monitorear y administrar, ClusterControl usaría más recursos, y la capa de la base de datos suele ser el primer cuello de botella que encuentran los usuarios. Es posible que se necesiten algunos ajustes adicionales para contener la carga entrante.

ClusterControl es lo suficientemente inteligente como para detectar cualquier anomalía de rendimiento al escribir las siguientes líneas dentro de cmon_X.log (donde X es la ID del clúster):

2018-11-28 01:30:00 : (INFO) CmonSheetManager at 0x3839af0 loaded 70 values for key 'diskstat' between 2018-11-23 01:30:00 - 2018-11-28 01:30:0
0.
2018-11-28 01:30:00 : (INFO) SQL processing: 220.0000ms
2018-11-28 01:30:00 : (INFO) Parsing       : 0.0000ms
2018-11-28 01:30:00 : (INFO) Sum           : 220.0000ms

Lo anterior simplemente significa que se necesitaron 220 ms (valor de suma) para cargar 70 valores para el componente "diskstat", donde la mayor parte del tiempo de procesamiento ocurría en la etapa de procesamiento de SQL y 0 ms para analizar el conjunto de resultados de SQL Esto concluye que la capa SQL tomó la mayor parte del tiempo de procesamiento cuando ClusterControl intentó consultar el conjunto de datos.

Creemos que la mayoría de las consultas SQL ejecutadas por ClusterControl están correctamente optimizadas para una sola instancia de MySQL y utilizan la indexación adecuada. En pocas palabras, si ve que algo como lo anterior aparece regularmente en el archivo de registro, es necesario realizar algunas mejoras en la capa de la base de datos, como se muestra en las siguientes secciones.

Ajuste del tamaño del grupo de búfer de InnoDB

El tamaño del grupo de búfer es un componente importante y debe configurarse por adelantado para mejorar el rendimiento de MySQL. Permite que el procesamiento de MySQL ocurra dentro de la memoria en lugar de golpear el disco. Una regla general simple es verificar la proporción de aciertos de InnoDB y buscar la siguiente línea en la sección BUFFER POOL AND MEMORY:

Buffer pool hit rate 986 / 1000

La tasa de aciertos de 986/1000 indica que de 1000 lecturas de fila, pudo leer la fila en RAM 986 veces. Las 14 veces restantes, tuvo que leer la fila de datos del disco. En pocas palabras, 1000/1000 es el mejor valor que estamos tratando de lograr aquí, lo que significa que los datos a los que se accede con frecuencia caben completamente en la RAM.

Aumentar el valor de innodb_buffer_pool_size ayudará mucho a acomodar más espacio para que funcione MySQL. Sin embargo, asegúrese de tener suficientes recursos de RAM de antemano. De forma predeterminada, ClusterControl asigna el 50 % de la RAM al grupo de búfer. Si el host está dedicado a ClusterControl, incluso puede impulsarlo a un valor más alto, como el 70 %, siempre que ahorre al menos 2 GB de RAM para los procesos y cachés del sistema operativo. Si no puede asignar tanto, aumentar la memoria RAM es la única solución.

Cambiar este valor requiere un reinicio de MySQL (anterior a MySQL 5.7.5), por lo que el orden correcto de reinicio del servicio será:

1. Modifique el valor de innodb_buffer_pool_size dentro de my.cnf.
2. Detenga el servicio CMON.
3. Reinicie el servicio MySQL/MariaDB.
4. Inicie el servicio CMON.

O simplemente reinicie el host si puede permitirse un tiempo de inactividad más prolongado.

Ajuste de max_connections

De forma predeterminada, el script del instalador configurará el valor max_connections hasta 512. Esto es bastante alto, aunque sensato, ya que ClusterControl apenas alcanza las 200 conexiones en total, a menos que el servidor MySQL se comparta con otras aplicaciones o tenga decenas de nodos MySQL monitoreados por ClusterControl. (estamos hablando de 30 nodos y más).

Un valor alto de max_connections desperdicia recursos y ajustar el valor afectará la memoria máxima configurada para MySQL. Si es mayor que la RAM del sistema, existe la posibilidad de que el proceso del servidor MySQL finalice con una excepción OOM, si se utilizan todas las conexiones.

Para verificar esto, simplemente busque el estado de MySQL de max_used_connections. Las siguientes son las conexiones máximas jamás alcanzadas por MySQL en un nodo ClusterControl que monitorea 2 clústeres con 6 nodos MySQL en total:

mysql> SHOW STATUS like 'max_used_connections';
+----------------------+-------+
| Variable_name        | Value |
+----------------------+-------+
| Max_used_connections | 43    |
+----------------------+-------+

Un buen valor para comenzar es Max_used_connections x 2, y aumentarlo gradualmente si el valor crece constantemente. La modificación de la variable max_connections se puede realizar dinámicamente a través de la instrucción SET GLOBAL.

Usando el archivo de socket MySQL

De forma predeterminada, la secuencia de comandos del instalador configurará automáticamente el siguiente valor de host dentro de cada archivo de configuración de la base de datos de ClusterControl:

Lo anterior forzará al cliente MySQL a conectarse a través de una red TCP, al igual que conectarse a un host MySQL remoto, aunque ClusterControl se ejecuta en el mismo servidor que el servidor MySQL. Lo configuramos a propósito de esta manera para simplificar el proceso de instalación, ya que casi todas las plataformas de sistemas operativos preconfiguran el archivo de socket MySQL de manera diferente, lo que reduce en gran medida la tasa de fallas en la instalación.

Cambiar el valor a "localhost" forzará al cliente a usar el archivo de socket MySQL Unix en su lugar:

En los sistemas basados ​​en Unix, los programas MySQL tratan el nombre de host localhost de manera especial, de una manera que probablemente sea diferente de lo que espera en comparación con otros programas basados ​​en red. Para las conexiones a localhost, los programas MySQL intentan conectarse al servidor local mediante un archivo de socket Unix. Esto ocurre incluso si se da una opción --port o -P para especificar un número de puerto.

El uso del archivo de socket MySQL UNIX es mucho más seguro y reducirá la sobrecarga de la red. Siempre se recomienda sobre TCP. Sin embargo, debe asegurarse de que el archivo de socket esté configurado correctamente. Debe existir en las siguientes directivas dentro de my.cnf y en todos los archivos de opciones de MySQL en el nodo ClusterControl, por ejemplo:

[mysqld]
socket=/var/lib/mysql/mysql.sock

[client]
socket=/var/lib/mysql/mysql.sock

[mysql]
socket=/var/lib/mysql/mysql.sock

[mysqldump]
socket=/var/lib/mysql/mysql.sock

Cambiar el archivo de socket también requerirá un reinicio de MySQL y CMON. Si está utilizando "localhost", puede agregar algunas opciones de configuración adicionales como skip-networking=1, para evitar aceptar conexiones remotas. Nuestra imagen de Docker de ClusterControl utiliza este enfoque para superar una limitación en el proxy de ventana acoplable cuando se vincula a puertos.

Abrir SSH con SSSD

ClusterControl utiliza el protocolo SSH como su principal canal de comunicación para administrar y monitorear nodos remotos. Las configuraciones predeterminadas de OpenSSH son bastante decentes y deberían funcionar en la mayoría de los casos. Sin embargo, en algunos entornos donde SSH está integrado con otras herramientas de mejora de seguridad como SElinux o System Security Services Daemon (SSSD), podría tener un impacto significativo en el rendimiento de SSH.

Hemos visto muchos casos en los que se establece una cantidad cada vez mayor de conexiones SSH en cada uno de los nodos administrados y, finalmente, tanto el servidor de ClusterControl como todos los nodos administrados maximizan la memoria del sistema con conexiones SSH. En algunos casos, solo un reinicio normal del sistema completo por la noche en el servidor de ClusterControl podría resolver el problema.

Si ejecuta su infraestructura con System Security Services Daemon (SSSD), se recomienda comentar la siguiente línea dentro de la configuración del cliente OpenSSH en /etc/ssh/ssh_config en el nodo ClusterControl:

#ProxyCommand /usr/bin/sss_ssh_knownhostsproxy -p %p %h

Lo anterior omitirá el uso de SSSD para administrar la clave de host, que será manejada por el cliente OpenSSH en su lugar.

A partir de ClusterControl 1.7.0, tiene la opción de utilizar la herramienta de supervisión basada en agentes con Prometheus. Con el monitoreo basado en agentes, ClusterControl no usa SSH para muestrear métricas de host que pueden ser excesivas en algunos entornos.

Sistema de archivos y partición

El controlador ClusterControl escribe una nueva entrada en su archivo de registro casi cada segundo para cada clúster. Para aquellos que quieran aprovechar esta escritura secuencial en el disco y deseen ahorrar costos, pueden usar un disco de eje para este propósito. Modifique la siguiente línea dentro de todo cmon_X.cnf:

logfile=/new/partition/log/cmon_X.log

Reemplace X con la ID del clúster y reinicie el servicio CMON para aplicar los cambios.

Si está utilizando ClusterControl como repositorio de copia de seguridad, se recomienda que asigne suficiente espacio en disco en una partición separada que no sea la partición raíz. Se pone mejor si la partición reside en un sistema de archivos en red o en clúster para facilitar el montaje con los nodos de destino al realizar la operación de restauración. Hemos visto casos en los que las copias de seguridad creadas consumieron todo el espacio en disco de la partición principal, lo que finalmente afectó a ClusterControl y sus componentes.

Manténgase actualizado

ClusterControl tiene un ciclo de lanzamiento corto:al menos un nuevo lanzamiento principal cada trimestre del año más parches de mantenimiento semanales (principalmente correcciones de errores, si los hay). El motivo es que ClusterControl admite múltiples proveedores y versiones de bases de datos, sistemas operativos y plataformas de hardware. A menudo se introducen cosas nuevas y se desaprueban cosas viejas de lo que se proporciona. ClusterControl tiene que mantenerse al día con todos los cambios introducidos por los proveedores de aplicaciones y seguir las mejores prácticas en todo momento.

Recomendamos a los usuarios que utilicen siempre la última versión de ClusterControl (actualizar es fácil) junto con el navegador web más reciente (construido y probado en Google Chrome y Mozilla Firefox), ya que es muy probable que aprovechemos las nuevas funciones disponibles en la última versión.

Reflexiones finales

Si tiene alguna pregunta o encuentra algún problema o problemas de lentitud al usar ClusterControl, contáctenos a través de nuestro canal de soporte. Las sugerencias y los comentarios son muy bienvenidos.

¡Feliz afinación!