Utilizzare un database esterno

Questa pagina descrive come configurare Cyberwatch per l’utilizzo di un database esterno al posto del database containerizzato dell’istanza Cyberwatch.

Prerequisiti software

Cyberwatch supporta i database seguenti:

  • MariaDB 11.8 o 12.3

  • MySQL 8.4 o 9.7

    Si consiglia di utilizzare MariaDB 12.3 oppure, in caso di utilizzo di MySQL, la versione 9.7 LTS.

Prerequisiti hardware

Cyberwatch consiglia la seguente configurazione hardware sul server che ospita il database per garantire il corretto funzionamento dell’applicazione:

  • 2 vCPU
  • 12 GB di RAM
  • 100 GB di spazio su disco

Casi d’uso di un database esterno

Per impostazione predefinita, Cyberwatch utilizza un database MariaDB containerizzato.

L’utilizzo di un database esterno anziché containerizzato si rivela necessario in alcuni casi.

Cyberwatch richiede l’utilizzo di un database esterno per qualsiasi istanza destinata a monitorare 5000 o più asset. L’utilizzo di un database esterno è possibile anche per le istanze più piccole, tenendo conto dei vantaggi e dei limiti illustrati di seguito.

Vantaggi dell’utilizzo di un database esterno

  • possibilità di personalizzare le configurazioni del database
  • utilizzo di un server dedicato, che consente un’allocazione più precisa delle risorse
  • prestazioni migliori
  • meccanismi di replica e di backup configurabili in modo più preciso

Limiti legati all’utilizzo di un database esterno

  • l’utilizzo di un server dedicato comporta requisiti infrastrutturali aggiuntivi
  • la manutenzione del database e del server dedicato non è di competenza di Cyberwatch, sebbene i team Cyberwatch siano disponibili a fornire consulenza in caso di necessità

Creazione di un utente e di un database esterno dedicato

In caso di utilizzo di un server di database dedicato, è necessario creare un database concedendo tutti i privilegi a un utente dedicato. Per impostazione predefinita, Cyberwatch utilizza un database e un utente denominati olympe.

Queste operazioni possono essere effettuate eseguendo i comandi seguenti dal server di database:

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

Durante l’assegnazione dei privilegi, è necessario sostituire % con l’indirizzo IP del server Cyberwatch, o con il suo nome di dominio, nel formato %.example.com, a condizione che la sua risoluzione inversa sia funzionante. In caso di architettura a più nodi, questa operazione deve essere ripetuta per ciascun satellite, se l’assegnazione dei privilegi avviene tramite indirizzo IP.

Configurazione della piattaforma di base Cyberwatch

Generazione di un backup del database containerizzato

In caso di migrazione di un database containerizzato esistente, è necessario eseguire un backup del database dell’applicazione.

A tal fine, utilizzare il comando:

sudo cyberwatch backup save

Il dump generato è disponibile nella directory /var/lib/cyberwatch/backups/ e consentirà di ripristinare il database Cyberwatch.

Configurare i nodi Cyberwatch per l’utilizzo del database esterno

L’utilizzo di un database esterno richiede la configurazione del nodo master Cyberwatch con l’opzione --no-db. Nel caso di un’istanza a nodo singolo, con il comando:

sudo cyberwatch configure --no-db

Nel caso di un’istanza multi-nodo, è necessario specificare tutte le opzioni di configurazione. Configurare il nodo master con il comando seguente:

sudo cyberwatch configure --no-db --master

Configurare quindi i satelliti con il comando seguente:

sudo cyberwatch configure --no-db --satellite

L’opzione --no-db indica a Cyberwatch l’utilizzo di un database esterno e disattiva quindi l’utilizzo del database containerizzato.

Nel caso in cui i file di configurazione siano già presenti, l’eseguibile cyberwatch chiederà all’utente se desidera apportare modifiche alla configurazione.

Rispondendo affermativamente alle richieste di modifica della configurazione, è possibile configurare i certificati TLS e una parte delle variabili di connessione al database.

Generazione dei certificati

L’eseguibile cyberwatch consente di generare i certificati necessari per l’implementazione della crittografia TLS nella comunicazione tra le istanze Cyberwatch e il database dedicato.

Questi certificati consentono alle istanze Cyberwatch di verificare di connettersi effettivamente al servizio previsto, ma non consentono invece a tali servizi di verificare l’identità dei client che vi si connettono. In questo caso, un buon modo per rafforzare la configurazione del TLS unidirezionale resta quello di limitare i privilegi di accesso al database, definendo un elenco esaustivo delle origini dei client.

Pertanto, quando vengono richieste le informazioni per la generazione dei certificati, è opportuno inserire l’indirizzo IP e il nome o i nomi DNS dei servizi a cui le istanze si connetteranno.

Per il database, i certificati utili sono i seguenti:

  • /etc/cyberwatch/certs/cbw-root-ca-cert.pem: certificato root utilizzato per generare i certificati dei servizi. Consente alle istanze Cyberwatch di verificare i certificati installati sul database e sull’istanza Redis
  • /etc/cyberwatch/certs/cbw-db-cert.pem: certificato per il database
  • /etc/cyberwatch/certs/cbw-db-key.pem: chiave privata per il database

Questi tre file devono essere copiati sul server di database e indicati nel file di configurazione del database, come descritto più avanti.

Aggiungere il certificato root all’applicazione Cyberwatch

In caso di utilizzo di una coppia di chiavi firmata da un’autorità di certificazione esterna, è necessario dichiararla come autorità attendibile aggiuntiva presso Cyberwatch. A tal fine, è sufficiente concatenare il certificato root di tale autorità con quello di Cyberwatch.

Docker-Swarm

Con Docker Swarm, questa operazione può essere effettuata tramite il comando seguente:

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

Kubernetes

Con Kubernetes, è necessario creare un secret dedicato tramite il comando seguente, sostituendo YOUR_CA_FILE.pem con il nome del file contenente il certificato root:

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

Il nome del secret generato deve quindi essere indicato nel file values.yml del chart Helm:

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

Il chart deve quindi essere distribuito secondo la procedura indicata in Aggiornare l’applicazione e la piattaforma di base Cyberwatch su Kubernetes.

Adattare la configurazione di Cyberwatch al database esterno

Successivamente, è opportuno sostituire la password MYSQL_PASSWORD con quella dell’utente dedicato nel file /etc/cyberwatch/secrets.env.

Inoltre, le informazioni di connessione al database esterno sono modificabili dal file /etc/cyberwatch/containers.env, nel quale può essere necessario modificare:

  • il valore del campo MYSQL_HOSTNAME con l’indirizzo del server di database da contattare
  • il valore del campo MYSQL_DATABASE con il nome del database dedicato
  • il valore del campo MYSQL_USER con il nome dell’utente dedicato, creato in precedenza

Una volta applicata questa configurazione, è necessario riavviare il server di database per renderla persistente. È inoltre importante verificare che TLS sia effettivamente attivato dopo la definizione di questi certificati; a tal fine, è sufficiente eseguire il comando:

SHOW VARIABLES LIKE 'have_ssl';

Ripristinare il dump del database

Solo in caso di migrazione, è infine possibile ripristinare il database dell’applicazione eseguendo il comando:

sudo cyberwatch backup restore

Configurazione del database

Modifica della configurazione predefinita

Per poter beneficiare dei miglioramenti delle prestazioni attesi dall’utilizzo di un database esterno, è necessario configurarlo in base al dimensionamento dell’istanza Cyberwatch. La configurazione predefinita non è adeguata.

Il file di configurazione da modificare può dipendere dal database e dal sistema su cui è installato. In questa documentazione, si sceglie di modificare il file /etc/my.cnf (o /etc/mysql/my.cnf) considerando la configurazione descritta di seguito.

Ecco un esempio di configurazione tipica per un database esterno:

[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                  # Uniquement pour les serveurs 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

L’opzione innodb_snapshot_isolation è compatibile solo con i server MariaDB. È necessario rimuoverla per i server MySQL.

  • Le prime due righe consentono di definire il charset da utilizzare per evitare qualsiasi problema di codifica
  • Le tre righe successive sono le configurazioni InnoDB minime da utilizzare alla data di redazione di questa documentazione
  • Le tre righe seguenti consentono di specificare la posizione dei certificati sul server che ospita il database Questi consentono l’implementazione della crittografia TLS tra le istanze Cyberwatch e il database
  • L’ultima riga serve a impostare il database sul fuso orario UTC, in modo da non avere differenze di orario all’interno di Cyberwatch

Per ulteriori informazioni, consultare la documentazione di MariaDB relativa ai file di configurazione: https://mariadb.com/kb/en/configuring-mariadb-with-option-files/#default-option-file-locations-on-linux-unix-mac

Adattare la configurazione alle dimensioni del database

Questa configurazione predefinita deve essere adattata in base al dimensionamento del database Cyberwatch.

Le dimensioni del database dipenderanno principalmente dal numero di asset monitorati.

Per ottenere prestazioni ragionevoli, è necessario rispettare in ogni circostanza due regole d’oro:

  • la variabile innodb_buffer_pool_size deve essere sempre superiore alle dimensioni del database
  • la variabile innodb_log_file_size deve essere circa uguale o leggermente superiore al valore di innodb_buffer_pool_size/8

Altri parametri vengono spesso definiti per migliorare le prestazioni del database. L’ideale è seguire le raccomandazioni dello strumento MySQLTuner, che consente di effettuare una diagnosi dello stato di salute e delle prestazioni del database.

Utilizzo di MySQLTuner

MySQLTuner è uno strumento open source che consente di verificare la configurazione di un database MySQL e che fornisce raccomandazioni di configurazione per migliorare le prestazioni e la stabilità dell’installazione: https://github.com/major/MySQLTuner-perl

Lo strumento MySQLTuner è integrato nel container sidekiq dell’applicazione Cyberwatch e può quindi essere utilizzato con il comando seguente:

sudo cyberwatch mysqltuner

In base alle raccomandazioni fornite dallo script, potranno essere apportate modifiche alla configurazione del database. Per qualsiasi domanda, contattare il supporto tecnico di Cyberwatch.

Verificare la comunicazione con il database

La comunicazione con il database dedicato è considerata operativa quando l’output del comando seguente è simile a quello riportato di seguito:

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

Questo comando può essere eseguito dal nodo master o da un nodo satellite per verificare la comunicazione del nodo in questione con il database.