En nuestro blog anterior, hemos discutido ClusterControl CMON HA para alta disponibilidad de bases de datos distribuidas escrito por Krzysztof Ksiazek en dos publicaciones separadas. En este blog, cubriremos la distribución de nodos en las instalaciones y en una nube pública (usando Google Cloud Platform (GCP)).
La razón por la que escribimos este blog es porque recibimos preguntas sobre cómo implementar una instancia de alta disponibilidad de ClusterControl con nodos CMON ejecutándose localmente y otros nodos CMON ejecutándose en un centro de datos diferente (como una nube pública). En nuestro blog anterior ClusterControl CMON HA para alta disponibilidad de bases de datos distribuidas, usábamos nodos Galera Cluster, pero esta vez usaremos MySQL Replication usando Percona Server 5.7. Una configuración ideal para esto es encapsular siempre la comunicación de los nodos de su entorno local y los nodos que residen en una nube pública a través de VPN o un canal seguro.
ClusterControl CMON HA se encuentra en las primeras etapas, por lo que creemos que aún no está lo suficientemente maduro. Sin embargo, nuestro CMON HA puede brindarle la sensación de funcionalidad para implementar un ClusterControl para que esté altamente disponible. Procedamos a cómo puede implementar y configurar la distribución de los nodos a través de las instalaciones a través de la nube pública.
¿Qué es un CMON?
Antes de pasar al tema principal, permítanos presentarle qué es CMON. CMON significa ClusterControl Controller, que es el "cerebro principal" de ClusterControl. Un servicio de back-end que realiza tareas de automatización, administración, programación de monitoreo y también la disponibilidad de alta disponibilidad. Los datos que se recopilan se almacenan en la base de datos CMON, para lo cual estamos utilizando bases de datos compatibles con MySQL como almacén de datos.
La configuración arquitectónica
Es posible que algunos de ustedes no conozcan las capacidades de ClusterControl que puede realizar y configurar para alta disponibilidad. Si tiene varios nodos de ClusterControl (o CMON) en ejecución, es posible sin costo alguno. Es posible que pueda ejecutar toneladas de nodos de ClusterControl cuando lo necesite.
Para esta configuración, tendremos nodos de ClusterControl encima de un ClusterControl para crear o implementar los nodos de la base de datos y administrar una conmutación por error automática cada vez que ocurra una falla, por ejemplo. Aunque puede usar MHA, Orchestrator o Maxscale para administrar la conmutación por error automática, pero por eficiencia y velocidad, usaré ClusterControl para hacer las cosas especiales que otras herramientas que he mencionado no tienen.
Veamos el diagrama de esta configuración:
La configuración basada en ese diagrama muestra que además de CMON de tres nodos , un CMON (ClusterControl) en ejecución está encima de ellos que monitoreará la conmutación por error automática. Luego, HAProxy podrá equilibrar la carga entre los tres nodos CMON monitoreados, donde un nodo está ubicado en una región separada alojada en GCP para este blog. Puede notar que no incluimos Keepalived, eso se debe a que no podemos colocar un VIP en GCP ya que está en una red diferente.
Como habrá notado, colocamos un total de tres nodos. CMON HA requiere que necesitemos al menos 3 nodos para proceder con un proceso de votación o el llamado quórum. Entonces, para esta configuración, requerimos que tenga al menos 3 nodos para tener una mayor disponibilidad.
Implementación de nodos de ClusterControl locales
En esta sección, esperamos que ya haya configurado o instalado su interfaz de usuario de ClusterControl, que usaremos para implementar un clúster de replicación de MySQL de tres nodos usando Percona Server.
Primero vamos a crear el clúster implementando una nueva replicación de MySQL como se muestra a continuación.
Tome nota de que estoy usando Percona Server 5.7 aquí, para el cual el valor predeterminado la configuración de ClusterControl funciona de manera eficiente.
Luego defina el nombre de host o IP de sus nodos,
En este punto, esperamos que ya haya configurado un sistema de dos nodos Replicación maestro/esclavo alojada o ejecutándose localmente. La siguiente captura de pantalla debería mostrar cómo se verán sus nodos:
Configurar e instalar ClusterControl y habilitar CMON HA en el primer nodo
De este blog anterior ClusterControl CMON HA para alta disponibilidad de bases de datos distribuidas, proporcionamos brevemente los pasos para hacerlo. Bajemos de nuevo y sigamos los pasos como se indica, pero para esta configuración de replicación Maestro/Esclavo en particular.
Lo primero que debe hacer, elija un nodo que desee que se instale primero ClusterControl (en esta configuración, termino instalando primero en el nodo 192.168.70.80) y siga los pasos a continuación.
Paso uno
Instalar ClusterControl
$ wget http://www.severalnines.com/downloads/CMON/install-cc
$ chmod +x install-cc
$ sudo ./install-cc # omit sudo if you run as rootTenga en cuenta que una vez que se le solicite que se detecte una instancia de mysql actual, debe permitir que ClusterControl use el mysqld existente en ejecución, ya que ese es uno de nuestros objetivos aquí para CMON HA y para esta configuración para usar el ya configuré MySQL.
Paso dos
Asocie CMON no solo para permitir a través de localhost, sino también en la dirección IP específica (ya que habilitaremos HA)
## edit /etc/default/CMON and modify the line just like below or add the line if it doesn't exist
RPC_BIND_ADDRESSES="127.0.0.1,192.168.70.80"Paso tres
Luego reinicie CMON,
service CMON restartCuarto Paso
Instalar las herramientas CLI de s9s
$ wget http://repo.severalnines.com/s9s-tools/install-s9s-tools.sh
$ chmod 755 install-s9s-tools.sh
$ ./install-s9s-tools.shDurante esta instalación, la herramienta s9s configurará un usuario administrador que puede usar cuando maneje el comando s9s, al igual que habilitar CMON HA.
Paso cinco
Habilitar CMON HA
$ s9s controller --enable-CMON-haPaso Seis
Por último, modifique /etc/my.cnf y agregue,
slave-skip-errors = 1062bajo la sección [mysqld]. Una vez agregado, no olvide reiniciar mysql como,
service mysql restarto
systemctl restart mysqlActualmente, esta es la limitación a la que nos enfrentamos con CMON HA, ya que intenta insertar entradas de registro en el esclavo, pero esto puede funcionar bien por ahora.
Configurar, instalar ClusterControl y habilitar CMON HA en el segundo nodo
Así de simple para el primer nodo. Ahora, en el segundo nodo (192.168.70.70), debemos realizar los mismos pasos, pero debemos realizar algunos ajustes en los pasos para que esta HA sea posible.
Paso uno
Copie la configuración al segundo nodo (192.168.70.70) desde el primer nodo (192.168.70.80)
$ scp -r /etc/CMON* 192.168.70.70:/etc/Paso dos
En el segundo nodo, edite /etc/CMON.cnf y asegúrese de que el host esté configurado correctamente. por ejemplo
vi /etc/CMON.cnfLuego asigne el parámetro de nombre de host como,
nombre de host=192.168.70.70
Paso tres
Instalar ClusterControl,
$ wget http://www.severalnines.com/downloads/CMON/install-cc
$ chmod +x install-cc
$ sudo ./install-cc # omit sudo if you run as rootSin embargo, omita la instalación de CMON (o ClusterControl Controller) una vez que encuentre esta línea,
=> An existing Controller installation detected!
=> A re-installation of the Controller will overwrite the /etc/CMON.cnf file
=> Install the Controller? (y/N):El resto, simplemente haga lo que hizo en el primer nodo, como configurar el nombre de host, usar la instancia de ejecución de mysqld existente, proporcionar la contraseña de MySQL y la contraseña para su CMON, que debe ser ambos tienen la misma contraseña que el primer nodo.
Cuarto Paso
Instalar las herramientas CLI de s9s
$ wget http://repo.severalnines.com/s9s-tools/install-s9s-tools.sh
$ chmod 755 install-s9s-tools.sh
$ ./install-s9s-tools.shPaso cinco
Copie la configuración restante del primer nodo al segundo nodo.
$ scp -r ~/.s9s/ 192.168.70.70:/root/
$ scp /etc/s9s.conf 192.168.70.70:/etc/
$ scp /var/www/html/clustercontrol/bootstrap.php 192.168.70.70:/var/www/html/clustercontrol/Paso Seis
Instalar paquete de controlador de clústercontrol,
Para Ubuntu/Debian,
$ apt install -y clustercontrol-controllerPara RHEL/CentOS/Fedora,
$ yum install -y clustercontrol-controllerSéptimo Paso
Copie el archivo /etc/default/CMON y modifique la dirección IP para la dirección de enlace RPC
scp /etc/default/CMON 192.168.70.70:/etc/default
RPC_BIND_ADDRESSES="127.0.0.1,10.0.0.103"Luego reinicie CMON de la siguiente manera,
service CMON restartPaso Ocho
Modifique /etc/my.cnf y agregue,
slave-skip-errors = 1062bajo la sección [mysqld]. Una vez agregado, no olvide reiniciar mysql como,
service mysql restarto
systemctl restart mysqlActualmente, esta es la limitación a la que nos enfrentamos con CMON HA, ya que intenta insertar entradas de registro en el esclavo, pero esto puede funcionar bien por ahora.
Paso Nueve
Finalmente, verifique cómo se ven los nodos CMON HA,
[[email protected] ~]# s9s controller --list --long
S VERSION OWNER GROUP NAME IP PORT COMMENT
l 1.7.5.3735 system admins 192.168.70.80 192.168.70.80 9501 Acting as leader.
f 1.7.5.3735 system admins 192.168.70.70 192.168.70.70 9501 Accepting heartbeats.
Total: 2 controller(s)Implementación de su nodo ClusterControl en la nube
Como mencionamos anteriormente, la configuración ideal para la comunicación es encapsular los paquetes a través de la VPN u otro medio de canal seguro. Si tiene inquietudes acerca de cómo hacer esto, consulte nuestro blog anterior Multi-DC PostgreSQL:configuración de un nodo en espera en una ubicación geográfica diferente a través de una VPN para el cual hemos abordado cómo puede crear una configuración de VPN simple usando OpenVPN.
Entonces, en esta sección, esperamos que ya haya configurado la conexión VPN. Ahora, lo que vamos a hacer es agregar un esclavo que se supone que debemos distribuir la disponibilidad de CMON en Google Cloud Platform. Para hacer esto, simplemente vaya a Agregar esclavo de replicación, que se puede encontrar haciendo clic en el ícono del clúster cerca de la esquina derecha. Vea cómo se ve a continuación:
Ahora, así es como terminaremos con:
Ahora, dado que agregamos un nuevo esclavo que está alojado en GCP, es posible que deba seguir nuevamente lo que hicimos anteriormente en el segundo nodo. Te transmitiré que sigas esos pasos y sigas las instrucciones sobre cómo lo hicimos en el segundo nodo.
Una vez que lo tenga correctamente, terminará con el siguiente resultado:
[[email protected] ~]# s9s controller --list --long
S VERSION OWNER GROUP NAME IP PORT COMMENT
l 1.7.5.3735 system admins 192.168.70.80 192.168.70.80 9501 Acting as leader.
f 1.7.5.3735 system admins 192.168.70.70 192.168.70.70 9501 Accepting heartbeats.
f 1.7.5.3735 system admins 10.142.0.39 10.142.0.39 9501 Accepting heartbeats.dónde en los nodos
- 192.168.70.80 - (node8) y reside en mi local
- 192.168.70.70 - (node7) y reside en mi local
- 10.142.0.39 - (gnode1) está alojado en GCP y en otra región
CMON HA en acción
Mi colega Krzysztof Ksiazek ya proporcionó la configuración para HA usando HAProxy aquí en este blog ClusterControl CMON HA para alta disponibilidad de bases de datos distribuidas - Parte dos (Configuración de acceso GUI).
Para seguir el procedimiento indicado en el blog, asegúrese de tener los paquetes xinetd y pathlib. Puede instalar xinetd y pathlib de la siguiente manera,
$ sudo yum install -y xinetd python-pathlib.noarchAsegúrese también de tener el CMONhachk definido en /etc/services tal como se muestra a continuación:
[[email protected] ~]# grep 'CMONhachk' /etc/services
CMONhachk 9201/tcpy asegurar los cambios y reiniciar xinetd,
service xinetd restartOmitiré el procedimiento Keepalived y HAProxy y espero que haya configurado en consecuencia. Una conclusión que debe tener en cuenta en esta configuración es que el uso de Keepalived no se puede aplicar si está dispersando el VIP de la red local a la nube pública porque es una red totalmente diferente.
Ahora, veamos cómo reacciona CMON HA si los nodos están inactivos. Como se mostró anteriormente, el nodo 192.168.70.80 (nodo 8) actuaba como líder tal como se muestra a continuación:
Donde la base de datos del nodo maestro también muestra que el nodo 8 es el maestro de la vista de topología de ClusterControl . Intentemos eliminar node8 y ver cómo procede CMON HA,
Como puede ver, gnode1 (nodo GCP) está asumiendo el liderazgo a medida que el nodo8 se cae. Verificando los resultados de HAProxy a lo siguiente,
y nuestros nodos ClusterControl muestran que el nodo 8 está inactivo, mientras que el nodo GCP está tomando más como el maestro,
Por último, acceder a mi nodo HAProxy que se ejecuta en el host 192.168.10.100 en el puerto 81 muestra la siguiente interfaz de usuario,
Conclusión
Nuestro ClusterControl CMON HA existe desde la versión 1.7.2, pero también ha sido un desafío para nosotros debido a varias preguntas y preferencias sobre cómo implementarlo, como usar MySQL Replication sobre Galera Cluster.
Nuestro CMON HA aún no está maduro, pero ahora está listo para satisfacer sus necesidades de alta disponibilidad. Se pueden aplicar diferentes enfoques siempre que sus comprobaciones determinen el nodo correcto que está en funcionamiento.
Lo alentamos a que configure e implemente usando CMON HA y háganos saber qué tan bien se adapta a sus necesidades o si el problema persiste, háganos saber cómo ayudarlo a satisfacer sus necesidades de alta disponibilidad.
