Como en todo sistema de información, hay que tener una estrategia de copias de seguridad (backups) o mejor aún, tener dos. Si tienes un cluster de ElasticSearch, en producción, tienes que asegurarte un buen sistema de backups, y la mejor forma de hacer uno de ellos es usando la capacidad de ElasticSearch de generar copias de seguridad usando snapshots con rotación
Para este tip, usaremos la versión 5.6 de ElsaticSearch que es la que estoy usando con un cliente, con 3 máquinas en el cluster, aunque es valido para elasticsearch en la versión 6. Los matices entre versiones son necesario revisarlos, y por tanto el lector debe entender que esto, es un tip y que no me responsabilizo de su eficiacia. Cada administrador debe trabajar, ejecutar y verificar sus sistemasAbdelkarim Mateos
Contenidos
Configuración del sistema de backup basado en NFS
Lo primero es leerse la documentación de ElasticSearch respecto del trabajo con snapshots, para poder comprender y actuar creando nuestra estrategia de copias de seguridad. Es importante entender también, como funciona ElasticSearch con su sistema de versiones, sino queremos tener más de un quebradero de cabeza.
Escenario
- [VARIABLE]: El contenido entre los corchetes debe ser sustituido por los valores adecuados de sus sistema
- Punto de montaje local NFS: [PATH_PUNTO_MONTAJE]/[DIRECTORIO]/ (esto es aconsejado por si el punto de montaje va a tener más directorios de backups)
- Punto de montaje remoto NFS: [NFSERVER]:[PATH]
- Nombre de mi estrategia de backups: [NOMBRE_BACKUP]
Montaje del punto local de nfs
Entendemos que el servidor NFS esta preparado para ser usado por cada uno de los elementos de nuestros cluster para el punto de montaje remoto, y por tanto podemos montarlo. En este punto, se entiende que ya tienes operativo un servidor NFS, configurado un punto de montaje remoto NFS valido para los elementos del cluster.
Editamos el fichero /etc/fstab en cada elemento del cluster
[SERVIDOR_NFS]:[PATH_NFS_REMOTO] [PATH_PUNTO_MONTAJE] nfs bg,hard,timeo=1200,rsize=1048576,wsize=1048576 0 0
Montamos el directorio en cada uno de los miembros del cluster y verificamos
mount -a; df -h
Configuración de ElasticSearch
Para que ElasticSearch funcione con este sistema, debemos también configurar todos los nodos del cluster editando el fichero de configuración /etc/elasticsearch/elasticsearch.yml y reiniciamos ES en cada uno de los elementos del cluster.
path.repo: ["[PATH_PUNTO_MONTAJE]/[DIRECTORIO]/"]
Activación del punto de montaje en ElasticSearch
$ curl -XPUT 'http://[MASTERNODE]:9200/_snapshot/[NOMBRE_BACKUP]' -H 'Content-Type: application/json' -d '{
"type": "fs",
"settings": {
"location": "[PATH_PUNTO_MONTAJE]/[DIRECTORIO]",
"compress": true
}
}'
#Podemos usar mejor
$ curl -XPUT 'http://[MASTERNODE]:9200/_snapshot/[NOMBRE_BACKUP]' -H 'Content-Type: application/json' -d '{"type": "fs", "settings": {"location": "[PATH_PUNTO_MONTAJE]/[DIRECTORIO]", "compress": true}}'
# Debe devolver
$ {"acknowledged":true}
Backup manual
Antes de abordar el sistema de backups con snapshots y rotación, vamos a comprender como funciona, y trabajar con algunos comandos que pueden ser de utilidad, pues a veces lo que queremos es un simple backup, para por ejemplo clonar nuestro cluster en desarrollo, etc.
Comprobamos
$ curl -X GET "[MASTERNODE]:9200/_snapshot?pretty=true"
# Debe devolver algo similar
{
"excelle_backup" : {
"type" : "fs",
"settings" : {
"compress" : "true",
"location" : "/backupremote2/elastic"
}
}
}
Información
En el manual tenemos más valores que podemos ajustar, y que debemos tener en cuenta, cuando nuestro cluster es un juguete de varios decenas de terabytes, sino queremos tener problemasCrear un backup del cluster
Sin entrar en estrategias de rotación, queremos crear nuestro primer backup del cluster. Sencillo. Le vamos a llamar copia_completa
curl -XPUT "$[MASTERNODE]:9200/_snapshot/[NOMBRE_BACKUP]/copia_completa?wait_for_completion=true"
El comando devolverá el resultado en un json, que nos permitirá conocer el estado del snapshot.
{
"snapshot": {
"snapshot": "copia_completa",
"uuid": "9wRjNEkuSvmJMsZYgpBQQg",
"version_id": 5061099,
"version": "5.6.10",
"indices": [".kibana", "excellenting"],
"state": "SUCCESS",
"start_time": "2018-08-23T08:02:22.144Z",
"start_time_in_millis": 1535011342144,
"end_time": "2018-08-23T08:19:16.983Z",
"end_time_in_millis": 1535012356983,
"duration_in_millis": 1014839,
"failures": [],
"shards": {
"total": 10,
"failed": 0,
"successful": 10
}
}
}
Estrategia de backups con rotación
En una primera instancia programé un sistema para rotar los backups, muy sencilla basándome en los comandos anteriores y apoyándome en jq, un preprocesador de ficheros json. Pero luego pensé en que sería mejor trabajar con Curator, que es una herramienta basada en Python, que contiene más herramientas necesarias en la gestión de los índices, pero como en tantas cosas de ElasticSearch, la documentación es una verdadero quebradero de cabeza, y lo que existe en Internet sobre el tema, es igual que siempre: las diferencias de versiones crean un batiburrillo de información de mala calidad. Asi que lo dejamos para otro artículo.
Snapshots sin Curator
Para una salida rápida modifique y verifique un script de Karel Bemelmans que mantengo en mi GitLab. Es importante entender que este script no hace comprobaciones, sobre el resultado del backup o del borrado. Sin ellos, pudiera ser que estemos realizando un backup que no sirve en caso de ser necesario.
El script puede ser ejecutado en la consola shell o en una tarea cron, y esta configurado para guardar las últimas 30 copias.
#!/usr/bin/env bash
#
# Create backup of ElasticSearch cluster with snapshots
# 23/08/18 abdelkarim.mateos@castris.com
#
# You need the jq binary
# download from https://stedolan.github.io/jq/
# sudo apt-get install jq
# yum install jq
# Mode cron
CRON=0
# Limit snapshots save on backup directory
LIMIT=30
#Name of our snapshot repo
MYBACKUP="excelle_backup"
# Name of this host
HOST=$(hostname)
# Snapshot unique name time based
SNAPDATE=$(date +%Y%m%d%H%M%S)
# Make backup
if [ "$CRON" = true ]; then
curl -XPUT "${HOST}:9200/_snapshot/${MYBACKUP}/$SNAPDATE?wait_for_completion=true"
else
curl -XPUT "${HOST}:9200/_snapshot/${MYBACKUP}/$SNAPDATE?wait_for_completion=true&pretty=true"
fi
## Remove old backups
# Get list of snapshots
SNAPSHOTS=$(curl -s -XGET "${HOST}:9200/_snapshot/${MYBACKUP}/_all" | jq -r ".snapshots[:-${LIMIT}][].snapshot")
echo $SNAPSHOTS
# Loop the list and delete those that exceed
for SNAPSHOT in $SNAPSHOTS
do
echo "Deleting snapshot: $SNAPSHOT"
if [[ $CRON ]]; then
curl -s -XDELETE "${HOST}:9200/_snapshot/${MYBACKUP}/$SNAPSHOT"
else
curl -s -XDELETE "${HOST}:9200/_snapshot/${MYBACKUP}/$SNAPSHOT?pretty=true"
fi
done
Backup: algo más que ejecutarlos
Una de las fallas más comunes de las estrategias de copias de seguridad, es la ausencia de la verificación de las acciones realizadas por el software de backup, y la otra es la no verificación de que los datos asegurados por la copia son validos para restaurar los datos. Esta última, incluye el norealizafr simulaciones de restauración, que nos permitan conocer tanto la validez de la copia, así como los procedimientos a seguir en caso de desastre, para optimizar al máximo los tiempos de recuperaciónRestaurar un snapshot
Obtener la lista de los snapshots disponibles
$ curl -s -XGET "[MASTERNODE]:9200/_snapshot/[NOMBRE_BACKUP]/_all?pretty"
{
"snapshots" : [
{
"snapshot" : "20180824085231",
"uuid" : "0xWrcEgKTUKd_bLFtPyzMw",
"version_id" : 5061099,
"version" : "5.6.10",
"indices" : [
".kibana",
"excellenting"
],
"state" : "SUCCESS",
"start_time" : "2018-08-24T06:52:31.545Z",
"start_time_in_millis" : 1535093551545,
"end_time" : "2018-08-24T06:52:34.471Z",
"end_time_in_millis" : 1535093554471,
"duration_in_millis" : 2926,
"failures" : [ ],
"shards" : {
"total" : 10,
"failed" : 0,
"successful" : 10
}
},
{
"snapshot" : "20180824085459",
"uuid" : "X_bpFybeQQyeNmnC5XU6Rg",
"version_id" : 5061099,
"version" : "5.6.10",
"indices" : [
".kibana",
"excellenting"
],
"state" : "SUCCESS",
"start_time" : "2018-08-24T06:54:59.243Z",
"start_time_in_millis" : 1535093699243,
"end_time" : "2018-08-24T06:55:02.031Z",
"end_time_in_millis" : 1535093702031,
"duration_in_millis" : 2788,
"failures" : [ ],
"shards" : {
"total" : 10,
"failed" : 0,
"successful" : 10
}
},
{
"snapshot" : "20180824085528",
"uuid" : "-Jtx_MFkROKpRuN2s-jgvQ",
"version_id" : 5061099,
"version" : "5.6.10",
"indices" : [
".kibana",
"excellenting"
],
"state" : "SUCCESS",
"start_time" : "2018-08-24T06:55:28.347Z",
"start_time_in_millis" : 1535093728347,
"end_time" : "2018-08-24T06:55:31.380Z",
"end_time_in_millis" : 1535093731380,
"duration_in_millis" : 3033,
"failures" : [ ],
"shards" : {
"total" : 10,
"failed" : 0,
"successful" : 10
}
}
]
}
Script para restaurar
Te dejo un pequeño script para restaurar. Recuerda al leerlo, que primero hay que cerrar el indice, si este existe. Si no existe te dará error el cerrarlo pero no es importante.
#!/usr/bin/env bash
#
# Restore a snapshot from our repository
# Name of snapshot to restore
SNAPSHOT=${1?Need a value}
HOST=$(hostname)
# Name of my index
INDEX="excellenting"
#Name of our snapshot repo
MYBACKUP="excelle_backup"
# We need to close the index first
curl -XPOST "$HOST:9200/${INDEX}/_close"
# Restore the snapshot we want
curl -XPOST "${HOST}:9200/_snapshot/${MYBACKUP}/${SNAPSHOT}/_restore" -d '{
"indices": "'"${INDEX}"'"
}'
# Re-open the index
curl -XPOST "${HOST}:9200/${MYBACKUP}/_open"
Curator — 25/07/2018
Al finalizar el artículo casi tenía el apartado correspondiente a Curator, pero una vez más la documentación es muy confusa, y la gran mayoría de los artículos están basado en Curator 5.4 o anterior, o son los típicos Copy & Paste que no funcionan, o bien la persona que los hizo no expreso bien su experiencia. Aun así, he dejado un borrador del tema, para ir investigando a ver si en estos días puedo finalizarlo.Una versión actualizada de los script la encontraras en mi GitLab personal
Buscando algo más
Auqne tengo mii propio trabajo, por mi edad, mis conocimientos, y mis capacidades, creo que aun puedo encontrar algo mejor. Si tienes alguna propuesta, escribemeComparte este articulo en