Un backup coherente con la aplicación es imprescindible cuando se trabaja en ciertos entornos basados en datos donde la integridad, la consistencia de la aplicación y el tiempo en línea son esenciales para el negocio. Microsoft Azure añade Linux a la lista de sistemas operativos que soportan esta funcionalidad, especialmente interesante para bases de datos relacionales como MySQL.

Esta nueva herramienta facilita la automatización de tareas críticas como desplegar un nuevo nodo esclavo, restaurar bases de datos y tablas desde volcados y archivos en bruto, e incluso volver a una posición precisa de replicación recuperando registros binarios específicos. Además, el buen rendimiento de las redes de Azure reduce el tiempo requerido para tratar los problemas de demora de replicación.

Todo esto potencia que los administradores de bases de datos vuelvan a tener el control, hace que sus backups sean más fiables y representa una ventaja significativa ante instantáneas de disco simples.

Esta experiencia positiva fue una nueva oportunidad de colaboración con Microsoft, para así aprender de primera mano cómo funciona Azure entre bastidores. Hasta ahora está demostrando ser fructífera, ya que este conocimiento es ahora parte de nuestros procedimientos. Y, por tanto, del valor que agregamos a nuestros servicios para ayudar a nuestros clientes a crecer con nosotros.

Hacer backups coherentes con la aplicación para máquinas virtuales de Azure Linux

Hace unos días leí lo siguiente en uno de nuestros canales de mensajería instantánea *-hacker:

“Hace unos 30 segundos he explicado una limitación en esta funcionalidad y ahora acaban de anunciar que ya se ha arreglado… ¡Durante el día de hoy!
¡Esto pasa todo el rato!

No pude evitar sonreír y pensar “¡Sé lo que es eso!”, ya que es parte de nuestro día a día en CAPSiDE.

El Cloud (fíjate en la mayúscula) es un emocionante ecosistema donde la evolución impulsa la industria a un ritmo inverosímil, resultando en un repertorio de capacidades cada vez mayor. Estas ventajas competitivas pueden permitirte reaccionar más rápido, usar tus recursos de manera más eficiente, ser más flexible, superar fácilmente barreras obsoletas e ir de lo local a lo global en cuestión de minutos. Con todas estas capacidades a tu disposición, solo necesitas hacer un seguimiento de los cambios y renovarte constantemente para poder aprovecharlos. Esto es mejora continua en su mejor expresión.

¿Suena complejo? Bueno, es que lo es. Por suerte, viene de serie en el ADN de CAPSiDE y tenemos una excelente relación con los principales actores. Y entre ellos, Microsoft Azure destaca sin duda.

Como Gold Cloud Platform Partner de Microsoft y Azure Infrastructure & Datacenter Transformation Partner of the Year  -por segundo año consecutivo- colaboramos con Microsoft de diferentes maneras, una de ellas es probando nuevas funcionalidades en su fase preliminar. Esto es una gran oportunidad para nosotros a la hora de entender mejor cómo funciona todo entre bastidores. Y lo más importante, a la hora de ayudar a nuestros clientes a beneficiarse de estas nuevas herramientas en un tiempo récord.

Cuando se nos ofreció la oportunidad de probar una nueva herramienta para crear backups coherentes con la aplicación para máquinas virtuales de Azure Linux, pensamos que sería divertido y nos tiramos de cabeza a ello. Nuestro amor por Linux no es ningún secreto (¡y no somos los únicos!).

application-consistent backup

La herramienta

Antes de nada: ¿qué es un backup coherente con la aplicación en Azure? En pocas palabras, se puede definir como un momento de restauración que se crea sin tener que cerrar la máquina virtual, preservando la integridad de los datos (sin haber daños ni pérdidas) y que habilita específicamente la aplicación que los usa para reanudar un estado de consistencia.

Si la última premisa no se cumple, el backup cambiaría a una simple consistencia del sistema de archivos.

Los backups coherentes con la aplicación son particularmente importantes para las aplicaciones que mantienen datos temporales en la memoria o que requieren una transacción o una operación de input/output consistente.

Esto ya estaba disponible para máquinas virtuales de Windows después del flujo de trabajo de Volume Shadow Storage, tras la ejecución de la extensión del backup.

Con la nueva funcionalidad para máquinas virtuales de Linux, el backup también se activa a través de una extensión. Pero en este caso, se puede configurar para ejecutar ciertas acciones antes (preacciones) y después (postacciones) de que la intantánea tenga lugar. Hay parámetros adicionales disponibles, como por ejemplo si el backup debe continuar en caso de error en las preacciones, como en time out y la cantidad de reintentos para cada acción. Profundizando un poco, se ejecuta fsfreeze justo antes del backup para evitar cualquier operación write en el disco.

/application-consistentbackup

Los detalles finales de estas herramientas se encuentran en el anuncio oficial de Microsoft.

Posible escenario

Una vez se nos ha otorgado acceso a la fase preliminar de la funcionalidad, decidimos qué piezas del software utilizar, teniendo en cuenta las siguientes condiciones:

Teniendo esto en cuenta, nos decidimos por el servidor de la base de datos relacionales de MySQL 5.7 ejecutada en un servidor Ubuntu 16.04 LTS y evaluamos algunos posibles escenarios para la replicación maestro-esclavo.

Consideramos algunas implicaciones de los backups en los nodos maestro-esclavo, como:

Y finalmente, decidimos centrarnos en reproducir un escenario común y bien documentado consistente en un único master con uno o más servidores esclavos. Estos podrían estar o dedicados a los backups o ser parte de un grupo de solo lectura.

Una vez establecido, podemos pasar a las pruebas.

Pruebas

Ahora voy a explicar una de las pruebas realizadas, intentando que sea lo más simple y fácil de reproducir posible.

El objetivo de esta prueba en particular es demostrar que al usar el backup coherente con la aplicación desde un nodo esclavo, podemos desplegar otro que sea completamente operativo: actualizado y reanudando la replicación.

Ten en cuenta que, para que quedara claro, se han omitido partes secundarias del proceso.

application-consistent-backup

Requerimientos

Primero tenemos que configurar 3 máquinas virtuales:

$ sudo update-alternatives --install /bin/sh sh /bin/bash 100

$ sudo update-alternatives --install /bin/sh sh /bin/dash 50

$ sudo update-alternatives --config sh
There are 2 choices for the alternative sh (providing /bin/sh).

Selection Path Priority Status
------------------------------------------------------------
* 0 /bin/bash 100 auto mode
1 /bin/bash 100 manual mode
2 /bin/dash 50 manual mode

Press <enter> to keep the current choice[*], or type selection number:
$ sudo apt-get update && sudo apt-get upgrade
$ sudo apt-get install mysql-server
$ mysql_secure_installation

Desde el portal de Azure:

Entonces, necesitamos establecer una replicación master-esclavo entre node-a y node-b:

$ sudo vim /etc/mysql/mysql.conf.d/mysqld.cnf
$ egrep "^\s*(bind-address|server-id|log_bin|binlog_do_db)\s*=" /etc/mysql/mysql.conf.d/mysqld.cnf
bind-address            = <node-a-private-address>
server-id               = 1
log_bin                 = /var/log/mysql/mysql-bin.log
binlog_do_db            = sampledb
$ sudo service mysql restart
$ mysql <dbuser-and-password> -h localhost
mysql> CREATE DATABASE sampledb;
mysql> CREATE USER 'repl'@'%' IDENTIFIED BY '<hello-I-am-a-nice-password>';
mysql> GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%';
mysql> SHOW MASTER STATUS;
+------------------+----------+--------------+------------------+-------------------+
| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+------------------+----------+--------------+------------------+-------------------+
| mysql-bin.000001 |     1189 |              |                  |                   |
+------------------+----------+--------------+------------------+-------------------+
1 row in set (0.00 sec)
mysql> EXIT
$ sudo vim /etc/mysql/mysql.conf.d/mysqld.cnf
$ egrep "^\s*(bind-address|server-id|log_bin|binlog_do_db)\s*=" /etc/mysql/mysql.conf.d/mysqld.cnf
bind-address            = <node-b-private-address>
server-id               = 2
$ sudo service mysql restart
$ mysql <dbuser-and-password> -h localhost
mysql> CHANGE MASTER TO MASTER_HOST='<node-a-private-address>', MASTER_USER='repl', MASTER_PASSWORD='<hello-I-am-a-nice-password>', MASTER_LOG_FILE='mysql-bin.000001', MASTER_LOG_POS=1189;
mysql> START SLAVE;
mysql> EXIT

Una vez tenemos la replicación configurada y en funcionamiento, tendremos que poder probarla.

No necesitamos un conjunto de datos complejo, pero lo necesitamos de manera rápida. Así que ahí va una propuesta directa y divertida: echemos un vistazo al diccionario 😉

Instala un paquete de diccionario de sistema en Ubuntu:

$ sudo apt-get install wamerican

Y escribe dos scripts: uno para insertar palabras aleatorias del diccionario en una tabla en particular y otro para imprimir las últimas palabras insertadas con sus identificadores asignados automáticamente. Esto será útil para hacer crecer el tamaño de la base de datos de manera fácil y comprobar el progreso de replicación.

El ejemplo en pseudo código sería:

dictionary_file_lines = count lines of dictionary_file
repeat
  line_number = random % dictionary_file_lines
  line_content = get line line_number from dictionary_file
  insert line_content in table

De todas maneras, esto es solamente una propuesta. Puedes usar cualquier conjunto de datos que encaje con esta finalidad. Cuanto más grande, mejor.

Deja que el script se ejecute durante un rato, la replicación se puede comprobar desde el node-b:

mysql> SHOW SLAVE STATUS \G;

Los siguientes valores merecen una atención especial:

La documentación de comando cuenta con un montón de detalles.

Scripts a medida

El diseño de esta herramienta te otorga una gran libertad. La ventaja es que puedes definir un flujo de trabajo perfectamente adaptado a tus necesidades. El inconveniente es que eres la persona responsable de hacer que funcione. Situaciones como estas pueden ser grandes oportunidades para automatizar tu flujo de trabajo.

Como empresa multinacional que somos, los capsoides hablamos diferentes lenguas (sí, ¡los memes también son una lengua!), pero nuestra lengua franca es Perl. Aun así, actualmente esta extensión es compatible con las secuencias de comandos de Python y Bash. Al final optamos por el clásico Bash, lo sentimos Python.

Creamos un wrapper script para cada una de las dos acciones. Su único propósito es llamar al script principal con un parámetro pre o post. Esto ayuda a mantener limpia la configuración del plugin.

Además, se crearon dos archivos helper: uno con las variables y otro con las funciones. Sólo cobran vida cuando los convoca el script principal.

Finalmente, “el script principal” (TM). El meollo del asunto radica en cómo varía el flujo de trabajo dependiendo de la acción (pre o post) y la función del servidor (master o esclavo).

Ejemplo en pseudo código:

get server_information
load variables and functions
if requirements_are_met
  if action == pre
    if role == master
      run pre_master_actions
    else if role == slave
      run pre_slave_actions
  else if action == post
    if role == master
      run post_master_actions
    else if role == slave
      run post_slave_actions

Aquí es donde está el trabajo que hicimos, teniendo en cuenta los diferentes escenarios, se tiene que probar.

Por ejemplo, si tienes una gran tabla de archivo que se rotará o se truncará periódicamente, es posible que quieras programar algunos comandos de optimize table en el nodo maestro para ahorrar espacio de disco… pero ¿cómo afectaría esto al rendimiento? ¿Y al tiempo en línea? ¿Quieres confiar en backups maestros? ¿En backups esclavos? ¿En ambos? También, considerar diferentes operaciones de vaciado puede ser una opción.

Como con la mayoría de las cosas en el mundo de la tecnología, las cosas pueden complicarse.

Nos hemos centrado en un escenario donde el retraso de la replicación no será relevante. Mantener vivo el subproceso de input/output no valdrá para acelerar el tiempo de actualización, y los nodos esclavos están o dedicados a los backups o se usan como grupo para peticiones de sólo lectura. El nodo maestro debe apuntar a un tiempo en línea máximo, pero los nodos esclavos pueden tolerar breves tiempos de inactividad para tener backups sin procesar.

Un ejemplo de la secuencia para el backup de un nodo esclavo podría ser:

Puedes echar un vistazo al código de los scripts en el repositorio de GitHub MicrosoftAzureBackup/MySQL de Microsoft. Ten presente que todos los scripts vinculados se escribieron y fueron publicados para fines de prueba; solamente tú eres responsable de determinar si es apropiado usarlo o redistribuirlo, así como de asumir los riesgos asociados.

Los scripts deben colocarse en una nueva carpeta de /op/capside/azure. Revísalos con cuidado y personaliza especialmente las variables definidas en mysql-app-consistent-backup-env.sh.

Asegúrate de que solamente root tiene acceso a esta carpeta:

$ sudo chmod -R 700 /op/capside
$ sudo chown -R root:root /op/capside

Configuración del plugin

Edita la configuración del plugin para usar los scripts correctos y, de nuevo, asegúrate que solamente root tiene acceso al archivo para prevenir fallos en la ejecución:

$ sudo vim /etc/azure/PluginConfig.json
$ sudo egrep "\"(pre|post)ScriptLocation\"" /etc/azure/PluginConfig.json
        "preScriptLocation" : "/opt/capside/azure/pre-mysql-backup.sh",
        "postScriptLocation" : "/opt/capside/azure/post-mysql-backup.sh",
$ sudo chmod 700 /etc/azure/PluginConfig.json
$ sudo chown -R root:root /etc/azure/PluginConfig.json

De nuevo, los detalles finales de esta herramienta y específicamente los de la configuración del plugin se conocerán en el anuncio oficial de Microsoft.

Pruebas de backup

Puedes esperar a que la política del backup diaria active un backup para un node-b esclavo, o forzarlo a través del portal de Azure.

Comprueba la salida del registro creado por el script, tendría que parecerse a algo como esto:

[2017/03/02 09:07:24 UTC] INFO: Starting PRE actions for role slave
[2017/03/02 09:07:24 UTC] INFO: Stopping MySQL slave...
[2017/03/02 09:07:30 UTC] INFO: MySQL slave stopped.
[2017/03/02 09:07:30 UTC] INFO: Setting read-only status
[2017/03/02 09:07:30 UTC] INFO: Starting dump...
[2017/03/02 09:07:30 UTC] INFO: Dumping database sampledb...
[2017/03/02 09:07:30 UTC] INFO: Dumping table sampledb.sampletable...
[2017/03/02 09:07:30 UTC] INFO: 88      /opt/capside/azure/dumps/mysqldump-sampledb-sampletable-20170302-0907.sql.gz
[2017/03/02 09:07:30 UTC] INFO: Dump finished
[2017/03/02 09:07:30 UTC] INFO: Stopping MySQL service...
[2017/03/02 09:07:32 UTC] INFO: MySQL service stopped.
[2017/03/02 09:07:32 UTC] INFO: PRE for role slave finished
[2017/03/02 09:07:35 UTC] INFO: Starting POST actions for role slave
[2017/03/02 09:07:35 UTC] INFO: Starting MySQL service...
[2017/03/02 09:07:36 UTC] INFO: MySQL service started.
[2017/03/02 09:07:36 UTC] INFO: Unsetting read-only status
[2017/03/02 09:07:36 UTC] INFO: POST for role slave finished

Como puedes ver, solamente se tarda unos segundos en iniciar las opciones de post una vez las de pre hayan acabado.

application-consistent backup

Despliegue de un nuevo nodo esclavo

A estas alturas, tenemos un sistema de replicación master-esclavo MySQL de dos nodos funcionando correctamente, con backups diarios. Añadimos un nuevo nodo esclavo.

Desde el portal de Azure, ejecuta el File Recovery del node-b de la máquina virtual, acciona push en el script a través de scp al bash script de recuperación a la máquina virtual node-c y ejecútala para montar el disco nuevo.

Asegúrate que el servicio de MySQL está parado en la máquina virtual node-c, ya que vamos a destrozar su configuración y sus archivos de datos:

$ sudo service mysql stop

Sincroniza la configuración de MySQL y las carpetas de datos:

# rsync -avz --stats /path/to/the/recovery-mountpoint/Volume1/etc/mysql/* /etc/mysql/.

# rsync -avz --stats /path/to/the/recovery-mountpoint/Volume1/var/lib/mysql/* /var/lib/mysql/.

Ahora, ajusta los parámetros del archivo mysqld.cnf. Esto se podría automatizar fácilmente incrementando el valor del server-id y recuperando la IP privada desde la interfaz de red con comandos como ifconfig:

$ sudo egrep "^(bind-address|server-id)" /etc/mysql/mysql.conf.d/mysqld.cnf
bind-address            = <node-b-private-address>
server-id               = 2

# sudo sed -i 's/^\(\s*server-id\s*=\s*\)[0-9]*\s*$/\13/' /etc/mysql/mysql.conf.d/mysqld.cnf
# sudo sed -i 's/^\(\s*bind-address\s*=\s*\)[0-9\.]*\s*$/\1<node-c-private-address>/' /etc/mysql/mysql.conf.d/mysqld.cnf

$ sudo egrep "^(bind-address|server-id)" /etc/mysql/mysql.conf.d/mysqld.cnf
bind-address            = <node-c-private-address>
server-id               = 3

Enlaza los archivos transmitidos para evitar conflictos con el nombre del servidor (en caso de duda, consulta el valor de Relay_Log_File en la salida del comando SHOW SLAVE STATUS):

# ln -s <node-b-hostname>-relay-bin.index <node-c-hostname>-relay-bin.index
# ln -s <node-b-hostname>-relay-bin.000103 <node-c-hostname>-relay-bin.000103

Como alternativa, también puedes usar –relay-log de MySQL y opciones de –relay-log-index.

Para generar un nuevo identificador único universal, debemos eliminar el archivo auto.cnf:

$ sudo rm -f /var/lib/mysql/auto.cnf

Si no, la replicación de node-b se detendrá debido a que el server_uuid estará duplicado.

Reinicia el servicio de MySQL en la máquina virtual node-c:

$ sudo service mysql start

Verifica que la replicación se reanuda y se actualiza. ¡Voilà!

Bonus track


La ubicación predeterminada para los registros binarios es /var/log/mysql. Definir correctamente una política para archivar y rotar (o purgar) los binlogs maestros puede ser muy útil para habilitar una recuperación más granular con la utilidad mysqbinlog utility.

Para saber más

Puedes aprender más sobre los backups coherentes con la aplicación para máquinas virtuales de Linux en el blog de Microsoft y en las actualizaciones de Azure. Ambas fuentes facilitan el seguimiento de las nuevas funciones a medida que van estando disponibles.

La documentación online de Microsoft es una referencia muy buena que deberías guardar en los marcadores de tu navegador. Además, recomiendo leer el artículo sobre planificar el backup de la infraestructura de tu máquina virtual en Azure.

También puedes echar un vistazo a nuestro catálogo de cursos para catalizar tu transformación hacia un experto de Azure.

Application-consistent backup

¿Qué viene después?

Nos centramos en la operación, la automatización y la operación en 24×7 de plataformas digitales críticas para una amplia gama de clientes reconocidos a nivel mundial. No dudes en contactarnos si quieres conocer algunas de las formas en que podemos ayudar a tu empresa a aprovechar las posibilidades de la nube… ¡o incluso unirte a nuestro equipo!

Además, en la sesión de Microsoft Ignite sobre Azure Backup, Vijay Tandra Sistla y Aruna Somendra explicaron cómo usar estos scripts de MySQL. . ¡No te pierdas esta demo!

TAGS: application-consistent-backup, azure, azure lab, linux, microsoft, vm

speech-bubble-13-icon Created with Sketch.
Comentarios

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

*
*