Usar una base de datos externa

Esta página describe cómo configurar Cyberwatch para utilizar una base de datos externa en lugar de la base de datos contenida en la instancia de Cyberwatch.

Requisitos de software

Cyberwatch soporta las siguientes bases de datos:

  • MariaDB 11.4 o 11.8

  • MySQL 8.X

    Le recomendamos utilizar MariaDB 11.8, o, si utiliza MySQL, al menos la versión 8.4 LTS.

Requisitos de hardware

Cyberwatch recomienda la siguiente configuración de hardware en el servidor que aloja la base de datos para asegurar el correcto funcionamiento de la aplicación:

  • 2 vCPU
  • 12 GB de RAM
  • 100 GB de espacio en disco

Casos de uso de una base de datos externa

Por defecto, Cyberwatch utiliza una base de datos MariaDB contenida.

El uso de una base de datos externalizada en lugar de una contenida resulta necesario en ciertos casos.

Cyberwatch requiere el uso de una base de datos externalizada para cualquier instancia destinada a supervisar 5000 o más activos. El uso de una base externalizada también es posible para instancias más pequeñas, considerando las ventajas y limitaciones que se detallan a continuación.

Ventajas del uso de una base externalizada

  • posibilidad de personalizar las configuraciones de la base
  • uso de un servidor dedicado, lo que permite asignar los recursos de forma más precisa
  • mejor rendimiento
  • mecanismos de replicación y copias de seguridad más configurables

Limitaciones relacionadas con el uso de una base externalizada

  • el uso de un servidor dedicado implica necesidades adicionales de infraestructura
  • el mantenimiento de la base de datos y del servidor dedicado no es responsabilidad de Cyberwatch, aunque nuestros equipos están disponibles para asesorarle en caso de necesidad

Creación de un usuario y una base externa dedicada

En el caso de utilizar un servidor de base de datos dedicado, es necesario crear una base otorgando todos los privilegios a un usuario dedicado. Por defecto, Cyberwatch utiliza una base de datos y un usuario llamados olympe.

Estas operaciones pueden realizarse ejecutando los siguientes comandos desde el servidor de base de datos:

CREATE DATABASE olympe;
CREATE USER 'olympe'@'%' IDENTIFIED BY 'password';
GRANT ALL PRIVILEGES ON olympe.* TO 'olympe'@'%';
FLUSH PRIVILEGES;

Al asignar los privilegios, es necesario reemplazar % por la dirección IP del servidor Cyberwatch, o su nombre de dominio, en el formato %.example.com, siempre que su resolución inversa sea funcional. En el caso de una arquitectura con varios nodos, esta operación debe repetirse para cada satélite, si la asignación de privilegios se realiza por dirección IP.

Configuración del socle Cyberwatch

Generación de una copia de seguridad de la base contenida

En caso de migración desde una base de datos contenida existente, debe realizarse una copia de seguridad de la base de datos de la aplicación.

Para ello, utilice el comando:

sudo cyberwatch backup save

El volcado generado está disponible en el directorio /var/lib/cyberwatch/backups/ y permitirá restaurar la base de datos de Cyberwatch.

Configurar los nodos Cyberwatch para usar la base de datos externa

El uso de una base de datos externalizada requiere configurar el nodo maestro Cyberwatch con la opción --no-db. En el caso de una instancia de un solo nodo, con el comando:

sudo cyberwatch configure --no-db

En el caso de una instancia multinodo, es necesario especificar todas las opciones de configuración. Configure el nodo maestro utilizando el siguiente comando:

sudo cyberwatch configure --no-db --master

A continuación, configure los satélites utilizando el siguiente comando:

sudo cyberwatch configure --no-db --satellite

La opción --no-db indica a Cyberwatch el uso de una base de datos externa y desactiva así el uso de la base contenida.

En caso de que los archivos de configuración ya existan, el ejecutable cyberwatch preguntará al usuario si desea realizar cambios en la configuración.

Responder afirmativamente a las solicitudes de cambios de configuración le permitirá configurar los certificados TLS así como parte de las variables de conexión a la base de datos.

Generación de los certificados

El ejecutable cyberwatch permite generar los certificados necesarios para implementar el cifrado TLS en la comunicación entre las instancias Cyberwatch y la base de datos dedicada.

Estos certificados permiten a las instancias Cyberwatch verificar que se conectan al servicio esperado, pero no permiten a estos servicios verificar la identidad de los clientes que se conectan. Una buena manera de reforzar en este caso la configuración de TLS unidireccional es limitar los privilegios de acceso a la base de datos, definiendo una lista exhaustiva de las fuentes de los clientes.

Así, al solicitar la información necesaria para la generación de los certificados, se debe indicar la dirección IP y el/los nombre(s) DNS de los servicios a los que se conectarán las instancias.

Para la base de datos, los certificados útiles son los siguientes:

  • /etc/cyberwatch/certs/cbw-root-ca-cert.pem : certificado raíz utilizado para generar los certificados de los servicios. Permite a las instancias Cyberwatch verificar los certificados depositados en la base de datos y la base Redis
  • /etc/cyberwatch/certs/cbw-db-cert.pem : certificado para la base de datos
  • /etc/cyberwatch/certs/cbw-db-key.pem : clave privada para la base de datos

Estos tres archivos deben copiarse en el servidor de base de datos y especificarse en el archivo de configuración de la base, estos elementos se detallan más abajo.

Añadir el certificado raíz a la aplicación Cyberwatch

En caso de utilizar un par de claves firmado por una autoridad de certificación externa, es necesario declararla como autoridad de confianza adicional ante Cyberwatch. Para ello, basta con concatenar el certificado raíz de dicha autoridad y el de Cyberwatch.

Docker-Swarm

En Docker Swarm, esta operación puede realizarse con el siguiente comando:

sudo cat ruta_del_certificado_raíz_de_la_autoridad_externa.pem >> /etc/cyberwatch/cbw-root-ca-cert.pem

Kubernetes

En Kubernetes, esto se realiza creando un secret dedicado mediante el siguiente comando, reemplazando YOUR_CA_FILE.pem por el nombre del archivo que contiene el certificado raíz:

kubectl -n cyberwatch create secret generic db-root-ca --from-file=db-root-ca.pem=YOUR_CA_FILE.pem

El nombre del secret generado debe especificarse después en el archivo values.yml del chart helm:

database:
  external: true
  
  tls: 
    mode: required
    secret: db-root-ca

El chart debe desplegarse según el procedimiento indicado en Actualizar la aplicación y el socle Cyberwatch en Kubernetes.

Adaptar la configuración de Cyberwatch a la base externa

A continuación, debe reemplazarse la contraseña MYSQL_PASSWORD por la del usuario dedicado en el archivo /etc/cyberwatch/secrets.env.

Además, la información de conexión a la base de datos externa se puede editar en el archivo /etc/cyberwatch/containers.env, donde puede ser necesario modificar:

  • el valor del campo MYSQL_HOSTNAME por la dirección del servidor de base de datos a contactar
  • el valor del campo MYSQL_DATABASE por el nombre de la base de datos dedicada
  • el valor del campo MYSQL_USER por el nombre del usuario dedicado, creado anteriormente

Una vez aplicada esta configuración, es necesario reiniciar el servidor de base de datos para que sea persistente. Además, es importante verificar que TLS esté activado tras la definición de estos certificados; para ello, basta con ejecutar el comando:

SHOW VARIABLES LIKE 'have_ssl';

Restaurar el volcado de la base de datos

En caso de migración únicamente, finalmente es posible restaurar la base de datos de la aplicación ejecutando el comando:

sudo cyberwatch backup restore

Configuración de la base de datos

Modificación de la configuración por defecto

Para poder aprovechar las mejoras de rendimiento que ofrece el uso de una base de datos externalizada, es necesario configurarla en función del dimensionamiento de la instancia Cyberwatch. La configuración por defecto no es suficiente.

El archivo de configuración a editar puede depender de la base de datos y del sistema en el que esté instalada. En esta documentación, elegimos modificar el archivo /etc/my.cnf (o /etc/mysql/my.cnf) considerando la configuración detallada a continuación.

A continuación, un ejemplo de configuración clásica para una base de datos externalizada:

[mysqld]
character-set-server       = utf8mb4
collation-server           = utf8mb4_general_ci
innodb_buffer_pool_size    = 3072M
innodb_log_file_size       = 768M
innodb_fast_shutdown       = 0
innodb_snapshot_isolation  = 0                  # Solo para servidores MariaDB
ssl-ca=/path/to/cbw-root-ca-cert.pem
ssl-cert=/path/to/generated-db-cert.pem
ssl-key=/path/to/generated-db-key.pem
default-time-zone=+00:00

La opción innodb_snapshot_isolation solo es compatible con servidores MariaDB. Debe eliminarse para servidores MySQL.

  • Las dos primeras líneas permiten definir el charset a utilizar para evitar cualquier problema de codificación
  • Las tres líneas siguientes son las configuraciones mínimas de InnoDB a utilizar a la fecha de redacción de esta documentación
  • Las tres siguientes líneas permiten especificar la ubicación de los certificados en el servidor que aloja la base de datos Estos permiten implementar el cifrado TLS entre las instancias Cyberwatch y la base de datos
  • La última línea es para poner la base de datos en la zona horaria UTC para no tener diferencia horaria dentro de Cyberwatch

Para más información, consulte la documentación de MariaDB sobre los archivos de configuración: https://mariadb.com/kb/en/configuring-mariadb-with-option-files/#default-option-file-locations-on-linux-unix-mac

Adaptar la configuración al tamaño de la base de datos

Esta configuración por defecto debe adaptarse según el dimensionamiento de la base de datos Cyberwatch.

El tamaño de la base de datos dependerá principalmente del número de activos supervisados.

Dos reglas de oro deben seguirse siempre para disponer de un rendimiento razonable:

  • la variable innodb_buffer_pool_size siempre debe ser superior al tamaño de la base de datos
  • la variable innodb_log_file_size debe ser aproximadamente igual o ligeramente superior al valor de innodb_buffer_pool_size/8

Otros parámetros suelen definirse para mejorar el rendimiento de la base de datos. Lo ideal es seguir las recomendaciones de la herramienta MySQLTuner, que permite realizar un diagnóstico del estado y el rendimiento de la base de datos.

Uso de MySQLTuner

MySQLTuner es una herramienta open source que permite auditar la configuración de una base de datos MySQL y que emite recomendaciones de configuración para mejorar el rendimiento y la estabilidad de la instalación: https://github.com/major/MySQLTuner-perl

La herramienta MySQLTuner está integrada en el contenedor sidekiq de la aplicación Cyberwatch y puede utilizarse con el siguiente comando:

sudo cyberwatch mysqltuner

Según las recomendaciones emitidas por el script, se podrán realizar modificaciones de configuración en la base de datos. En caso de duda, no dude en contactar con nuestro soporte técnico.

Verificar la comunicación con la base de datos

La comunicación con la base dedicada se considera operativa cuando la salida del siguiente comando es similar a la que se muestra a continuación:

  • sudo cyberwatch logs sidekiq_master para Docker Swarm
  • kubectl -n cyberwatch logs --selector app=sidekiq-master --tail=-1 para Kubernetes
Start healthcheck server...
Watch Redis
Testing redis uri redis:6379
Trying to connect to redis://redis:6379/0
Redis is up !
Watch Migration
All migration are done
Healthcheck completed reporting a successful start
Redis is on the same node, TLS is not required.
Checking if MariaDB supports TLS
TLS is available for MariaDB
Root CA found and valid, MariaDB certificate will be verified
2023-12-04T16:22:58.483Z pid=1 tid=53x INFO: Booted Rails 7.0.8 application in production environment

Este comando puede ejecutarse desde el nodo maestro o un nodo satélite para verificar la comunicación del nodo en cuestión con la base de datos.

Volver arriba

English Français Español