Utiliser une base de données externe

Cette page décrit comment configurer Cyberwatch pour utiliser une base de données externe à la place de la base de données conteneurisée de l’instance Cyberwatch.

Prérequis logiciels

Cyberwatch supporte les bases de données suivantes :

  • MariaDB 10.11 ou 11.4

  • MySQL 8.X

    Nous vous recommandons d’utiliser MariaDB 11.4, ou, si vous utilisez MySQL, la version 8.4 LTS au minimum.

Prérequis matériels

Cyberwatch recommande la configuration matérielle suivante sur le serveur hébergeant la base de données pour assurer le bon fonctionnement de l’application :

  • 2 vCPU
  • 12 Go de RAM
  • 100 Go d’espace disque

Cas d’usage d’une base de données externe

Cyberwatch utilise par défaut une base de données MariaDB conteneurisée.

L’utilisation d’une base de données externalisée plutôt que conteneurisée s’avère nécessaire dans certains cas de figure.

Cyberwatch requiert l’utilisation d’une base de données externalisée pour toute instance visant à superviser 5000 ou plus actifs. L’utilisation d’une base externalisée est également possible pour les instances plus petites, en considérant les avantages et limitations ci-dessous.

Avantages de l’utilisation d’une base externalisée

  • possibilité de personnaliser les configurations de la base
  • utilisation d’un serveur dédié, permettant d’allouer plus finement les ressources
  • meilleures performances
  • mécanismes de réplications et de sauvegardes plus finement paramétrables

Limitations liées à l’utilisation d’une base externalisée

  • l’utilisation d’un serveur dédié entraîne des besoins d’infrastructures supplémentaires
  • la maintenance de la base de données et du serveur dédié ne relève pas de Cyberwatch, bien que nos équipes soient disponibles pour vous conseiller en cas de besoin

Création d’un utilisateur et d’une base externe dédiée

Dans le cas d’une utilisation d’un serveur de base de données dédié, il est nécessaire de créer une base en y accordant tous les privilèges à un utilisateur dédié. Par défaut, Cyberwatch utilise une base de données et un utilisateur nommés olympe.

Ces opérations peuvent être réalisées par l’exécution des commandes suivantes depuis le serveur de base de données :

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

Lors de l’attribution des privilèges, il est nécessaire de remplacer % par l’adresse IP du serveur Cyberwatch, ou son nom de domaine, au format %.example.com, à condition que sa résolution inverse soit fonctionnelle. Dans le cas d’une architecture à plusieurs nœuds, cette opération est à répéter pour chaque satellite, si l’attribution des privilèges se fait par une adresse IP.

Configuration du socle Cyberwatch

Génération d’un backup de la base conteneurisée

Dans le cas d’une migration d’une base de données conteneurisée existante, une sauvegarde de la base de données de l’application doit être effectuée.

Pour ce faire, utiliser la commande :

sudo cyberwatch backup save

Le dump généré est disponible dans le répertoire /var/lib/cyberwatch/backups/ et permettra de restaurer la base de données Cyberwatch.

Configurer le nœud maître Cyberwatch pour utiliser la base de données externe

L’utilisation d’une base de données externalisée nécessite de configurer le nœud maître Cyberwatch avec l’option --no-db. Dans le cas d’une instance mono-nœud, avec la commande :

sudo cyberwatch configure --no-db

Si l’instance est composée de plusieurs nœuds, il est nécessaire de spécifier l’ensemble des options à utiliser.

Par exemple, pour utiliser une base de données externe sur un nœud maître avec des satellites :

sudo cyberwatch configure --no-db --master

L’option --no-db permet d’indiquer à Cyberwatch l’utilisation d’une base de données externe et désactive ainsi l’utilisation de la base conteneurisée.

Dans le cas où les fichiers de configuration sont déjà présents, l’exécutable cyberwatch va demander à l’utilisateur s’il souhaite apporter des changements de configuration.

Répondre positivement aux demandes de changements de configuration vous permettra de configurer les certificats TLS ainsi qu’une partie des variables de connexion à la base de données.

Génération des certificats

L’exécutable cyberwatch permet de générer les certificats nécessaires à la mise en place d’un chiffrement TLS pour la communication entre les instances Cyberwatch et la base de données dédiée.

Ces certificats permettent aux instances Cyberwatch de vérifier qu’elles se connectent bien au service attendu, mais ne permettent en revanche pas à ces services de vérifier l’identité des clients qui s’y connectent. Un bon moyen de durcir dans ce cas la configuration du TLS unidirectionnel reste de limiter les privilèges d’accès à la base de données, en définissant une liste exhaustive des sources des clients.

Ainsi, lors des demandes d’information permettant la génération des certificats, il convient de renseigner l’adresse IP et le(s) nom(s) DNS des services auxquels les instances vont se connecter.

Pour la base de données, les certificats utiles sont les suivants :

  • /etc/cyberwatch/certs/cbw-root-ca-cert.pem : certificat racine utilisé pour générer les certificats des services. Il permet aux instances Cyberwatch de vérifier les certificats déposés sur la base de données et la base Redis
  • /etc/cyberwatch/certs/cbw-db-cert.pem : certificat pour la base de données
  • /etc/cyberwatch/certs/cbw-db-key.pem : clé privée pour la base de données

Ces trois fichiers sont à copier sur le serveur de base de données et à renseigner dans le fichier de configuration de la base, ces éléments sont détaillés plus bas.

Ajouter le certificat racine à l’application cyberwatch

Dans le cas de la mise en place d’une paire de clés signée par une autorité de certification externe, il est nécessaire de la déclarer comme autorité de confiance supplémentaire auprès de Cyberwatch. Pour ce faire, il suffit de concaténer le certificat racine de cette autorité et celui de Cyberwatch.

Docker-Swarm

Sous Docker Swarm, cette opération peut être effectuée via la commande suivante :

sudo cat chemin_du_certificat_racine_de_lautorité_externe.pem >> /etc/cyberwatch/cbw-root-ca-cert.pem

Kubernetes

Sous Kubernetes, cela passe par la création d’un secret dédié via la commande suivante en remplaçant YOUR_CA_FILE.pem par le nom du fichier contenant le certificat racine :

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

Le nom du secret généré doit être ensuite renseigné dans le fichier values.yml du chart helm :

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

Le chart doit ensuite être déployé selon la procédure indiquée Mettre à jour l’application et le socle Cyberwatch sur Kubernetes.

Adapter la configuration de Cyberwatch à la base externe

Ensuite, il convient de remplacer le mot de passe MYSQL_PASSWORD par celui de l’utilisateur dédié dans le fichier /etc/cyberwatch/secrets.env.

Par ailleurs, les informations de connexion à la base de données externe sont éditables depuis le fichier /etc/cyberwatch/containers.env, il peut être nécessaire d’y modifier :

  • la valeur du champ MYSQL_HOSTNAME par l’adresse du serveur de base de données à contacter
  • la valeur du champ MYSQL_DATABASE par le nom de la base de données dédiée
  • la valeur du champ MYSQL_USER par le nom de l’utilisateur dédié, créé précédemment

Une fois cette configuration appliquée, il est nécessaire de redémarrer le serveur de base de données afin de la rendre persistante. De plus, il est important de vérifier que le TLS est bien activé suite à la définition de ces certificats, pour cela il suffit d’exécuter la commande :

SHOW VARIABLES LIKE 'have_ssl';

Restaurer le dump de base de données

Dans le cas d’une migration uniquement, il est finalement possible de restaurer la base de données de l’application en exécutant la commande :

sudo cyberwatch backup restore

Configuration de la base de données

Modification de la configuration par défaut

Afin de pouvoir profiter des améliorations de performance visées par l’utilisation d’une base de données externalisée, il est nécessaire de la configurer en fonction de du dimensionnement de l’instance Cyberwatch. La configuration par défaut n’est pas satisfaisante.

Le fichier de configuration à éditer peut dépendre de la base de données ainsi que du système sur laquelle elle est installée. Dans cette documentation, nous choisissons de modifier le fichier /etc/my.cnf (ou /etc/mysql/my.cnf) en considérant la configuration détaillée par la suite.

Voici un exemple de configuration classique pour une base de données externalisée :

[mysqld]
character-set-server       = utf8mb4
collation-server           = utf8mb4_general_ci
innodb_buffer_pool_size    = 2048M
innodb_log_file_size       = 512M
innodb_fast_shutdown       = 0
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
  • Les deux premières lignes permettent de définir le charset à utiliser afin d’éviter tout problème d’encodage
  • Les deux lignes suivantes sont les configurations InnoDB minimales à utiliser à la date de rédaction de cette documentation
  • Les trois prochaines lignes permettent de spécifier l’emplacement des certificats sur le serveur hébergeant la base de données Ceux-ci permettent la mise en place d’un chiffrement TLS entre les instances Cyberwatch et la base de données
  • La dernière ligne est pour mettre la base de données sur le fuseau horaire UTC afin de ne pas avoir de décalage horaire au sein de Cyberwatch

Pour en savoir plus, se référer à la documentation de MariaDB concernant les fichiers de configuration : https://mariadb.com/kb/en/configuring-mariadb-with-option-files/#default-option-file-locations-on-linux-unix-mac

Adapter la configuration à la taille de la base de données

Cette configuration par défaut doit être adaptée selon le dimensionnement de la base de données Cyberwatch.

La taille de la base de données dépendra principalement du nombre d’actifs supervisés.

Deux règles d’or sont à suivre en toutes circonstances pour disposer de performances raisonnables :

  • la variable innodb_buffer_pool_size doit toujours être supérieure à la taille de la base de données
  • la variable innodb_log_file_size doit être environ égale ou légèrement supérieure à la valeur de innodb_buffer_pool_size/8

D’autres paramètres sont fréquemment définis pour améliorer les performances de la base de données. L’idéal étant de suivre les recommandations de l’outil MySQLTuner qui permet de faire un diagnostic de l’état de santé et des performances de la base de données.

Utilisation de MySQLTuner

MySQLTuner est un outil open source permettant d’auditer la configuration d’une base de données MySQL et qui émet des recommandations de configuration permettant d’améliorer les performances et la stabilité de l’installation : https://github.com/major/MySQLTuner-perl

L’outil MySQLTuner est intégré dans le conteneur sidekiq de l’application Cyberwatch et peut donc être utilisé avec la commande suivante :

sudo cyberwatch exec sidekiq mysqltuner

En fonction des recommandations émises par le script, des modifications de configuration pourront être apportées à la base de données. En cas de question, n’hésitez pas à vous rapprocher de notre support technique.

Vérifier la communication avec la base de données

La communication avec la base dédiée est considérée opérationnelle lorsque le retour de la commande suivante est similaire au retour ci dessous :

  • sudo cyberwatch logs sidekiq_master pour Docker Swarm
  • kubectl -n cyberwatch logs --selector app=sidekiq-master --tail=-1 pour 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

Cette commande peut être exécutée depuis le nœud maître ou un nœud satellite afin de vérifier la communication du nœud en question avec la base de données.

Retour en haut