Come ottimizzare le prestazioni di ClusterControl e dei suoi componenti

Il monitoraggio e la gestione sono fondamentali per qualsiasi ambiente di produzione perché le prestazioni contano. Interfacce utente lente che sono in ritardo o non rispondono, avvisi ritardati e timeout dei processi del cluster quando il server è affamato di risorse sono tutte cose che possono causare problemi. Esistono modi per migliorare le prestazioni di ClusterControl, soprattutto se si gestiscono più cluster e ogni cluster contiene più nodi. Questo blog fornisce alcuni suggerimenti per l'ottimizzazione. I punti elaborati qui sono curati in base alla nostra esperienza nell'affrontare problemi di prestazioni segnalati dai nostri utenti e clienti.

Come introduzione, ClusterControl è costituito da diversi componenti principali:un'applicazione web (frontend) basata su PHP e una serie di processi demonizzati (backend). Questi sfruttano un database MySQL/MariaDB per l'archiviazione persistente. Stai controllando efficacemente il tuo cluster dall'applicazione web, che verrà tradotta in una serie di chiamate di processo eseguite dai processi di back-end per gestire e monitorare i tuoi cluster di database.

Database MySQL

I componenti ClusterControl si basano su un database MySQL o MariaDB come archivio permanente per monitorare i dati raccolti dai nodi gestiti e tutti i metadati ClusterControl (ad es. quali lavori ci sono nella coda, pianificazioni di backup, stati di backup, eccetera.). Per impostazione predefinita, lo script di installazione installerà qualsiasi versione fornita dal repository standard del sistema operativo. Quella che segue è la versione MySQL/MariaDB installata dal programma di installazione:

• CentOS/Redhat 6 - MySQL 5.1

• CentOS/Redhat 7 - MariaDB 5.5

• Ubuntu 18.04 (Bionic) - MySQL 5.7

• Ubuntu 16.04 (Xenial) - MySQL 5.7

• Ubuntu 14.04 (Trusty) - MySQL 5.5

• Debian 9 (Stretch) - MySQL 5.5

• Debian 8 (Jessie) - MySQL 5.5

• Debian 7 (Wheezy) - MySQL 5.5

Lo script di installazione eseguirà alcune regolazioni di base come la configurazione della posizione della directory dati, della porta MySQL, dell'utente e della dimensione del pool di buffer InnoDB all'inizio della fase di installazione. Tuttavia, l'ottimizzazione potrebbe non essere adatta dopo aver importato o creato più cluster/nodi. Con un numero maggiore di nodi da monitorare e gestire, ClusterControl utilizzerebbe più risorse e il livello del database è comunemente il primo collo di bottiglia che gli utenti incontrano. Potrebbero essere necessarie ulteriori regolazioni per contenere il carico in entrata.

ClusterControl è abbastanza intelligente da rilevare qualsiasi anomalia delle prestazioni scrivendo le seguenti righe all'interno di cmon_X.log (dove X è l'ID del cluster):

2018-11-28 01:30:00 : (INFO) CmonSheetManager at 0x3839af0 loaded 70 values for key 'diskstat' between 2018-11-23 01:30:00 - 2018-11-28 01:30:0
0.
2018-11-28 01:30:00 : (INFO) SQL processing: 220.0000ms
2018-11-28 01:30:00 : (INFO) Parsing       : 0.0000ms
2018-11-28 01:30:00 : (INFO) Sum           : 220.0000ms

Quanto sopra significa semplicemente che ci sono voluti 220 ms (valore Somma) per caricare 70 valori per il componente "diskstat", dove la maggior parte del tempo di elaborazione si stava verificando nella fase di elaborazione SQL e 0 ms per analizzare il set di risultati SQL Ciò conclude che il livello SQL ha impiegato la maggior parte del tempo di elaborazione quando ClusterControl ha tentato di interrogare il set di dati.

Riteniamo che la maggior parte delle query SQL eseguite da ClusterControl siano adeguatamente ottimizzate per una singola istanza MySQL e utilizzino un'indicizzazione adeguata. Detto semplicemente, se vedi qualcosa di simile a quanto sopra che appare regolarmente nel file di registro, sono necessari alcuni miglioramenti al livello del database, come mostrato nelle sezioni seguenti.

Regolazione della dimensione del pool di buffer InnoDB

La dimensione del pool di buffer è un componente importante e deve essere configurata in anticipo per migliorare le prestazioni di MySQL. Consente l'elaborazione di MySQL all'interno della memoria invece di colpire il disco. Una semplice regola pratica è controllare il rapporto di hit di InnoDB e cercare la seguente riga nella sezione BUFFER POOL AND MEMORY:

Buffer pool hit rate 986 / 1000

Il tasso di successo di 986/1000 indica che su 1000 letture di riga, è stato in grado di leggere la riga nella RAM 986 volte. Le restanti 14 volte, ha dovuto leggere la riga di dati dal disco. Detto semplicemente, 1000 / 1000 è il miglior valore che stiamo cercando di ottenere qui, il che significa che i dati a cui si accede di frequente si adattano completamente alla RAM.

Aumentare il valore di innodb_buffer_pool_size aiuterà molto a trovare più spazio su cui MySQL può lavorare. Tuttavia, assicurati di avere risorse RAM sufficienti in anticipo. Per impostazione predefinita, ClusterControl alloca il 50% della RAM al pool di buffer. Se l'host è dedicato a ClusterControl, puoi persino spingerlo a un valore più alto come il 70%, a condizione di risparmiare almeno 2 GB di RAM per i processi e le cache del sistema operativo. Se non puoi allocare così tanto, aumentare la RAM è l'unica soluzione.

La modifica di questo valore richiede un riavvio di MySQL (precedente a MySQL 5.7.5), quindi l'ordine di riavvio del servizio corretto sarà:

1. Modifica il valore di innodb_buffer_pool_size all'interno di my.cnf.
2. Interrompi il servizio CMON.
3. Riavvia il servizio MySQL/MariaDB.
4. Avvia il servizio CMON.

O semplicemente riavvia l'host se puoi permetterti un tempo di inattività più lungo.

Ottimizzazione max_connections

Per impostazione predefinita, lo script di installazione configurerà il valore max_connections fino a 512. Questo è piuttosto alto, anche se sano, poiché ClusterControl raggiunge a malapena 200 connessioni in totale, a meno che il server MySQL non sia condiviso con altre applicazioni o tu abbia decine di nodi MySQL monitorati da ClusterControl (stiamo parlando di 30 nodi e più).

Un valore di max_connections elevato spreca risorse e la regolazione del valore influirà sulla memoria massima configurata per MySQL. Se è maggiore della RAM di sistema, è possibile che il processo di MySQL Server venga terminato con un'eccezione OOM, se vengono utilizzate tutte le connessioni.

Per verificarlo, cerca semplicemente lo stato MySQL di max_used_connections. Quello che segue è il numero massimo di connessioni mai raggiunto da MySQL su un nodo ClusterControl che monitora 2 cluster con 6 nodi MySQL in totale:

mysql> SHOW STATUS like 'max_used_connections';
+----------------------+-------+
| Variable_name        | Value |
+----------------------+-------+
| Max_used_connections | 43    |
+----------------------+-------+

Un buon valore per iniziare è Max_used_connections x 2 e aumentarlo gradualmente se il valore cresce costantemente. La modifica della variabile max_connections può essere eseguita dinamicamente tramite l'istruzione SET GLOBAL.

Utilizzo del file socket MySQL

Per impostazione predefinita, lo script del programma di installazione configurerà automaticamente il seguente valore host all'interno di ogni file di configurazione del database ClusterControl:

Quanto sopra forzerà il client MySQL a connettersi tramite rete TCP, proprio come la connessione a un host MySQL remoto sebbene ClusterControl sia in esecuzione sullo stesso server del server MySQL. L'abbiamo appositamente configurato in questo modo per semplificare il processo di installazione poiché quasi ogni piattaforma del sistema operativo preconfigura il file socket MySQL in modo diverso, il che riduce notevolmente il tasso di errore dell'installazione.

La modifica del valore in "localhost" costringerà il client a utilizzare invece il file socket MySQL Unix:

Sui sistemi basati su Unix, i programmi MySQL trattano il nome host localhost in modo speciale, in un modo probabilmente diverso da quello che ci si aspetta rispetto ad altri programmi basati sulla rete. Per le connessioni a localhost, i programmi MySQL tentano di connettersi al server locale utilizzando un file socket Unix. Ciò si verifica anche se viene fornita un'opzione --port o -P per specificare un numero di porta.

L'uso del file socket MySQL UNIX è molto più sicuro e taglierà il sovraccarico della rete. È sempre consigliato su TCP. Tuttavia, è necessario assicurarsi che il file socket sia configurato correttamente. Deve esistere nelle seguenti direttive all'interno di my.cnf e in ogni file di opzioni MySQL sul nodo ClusterControl, ad esempio:

[mysqld]
socket=/var/lib/mysql/mysql.sock

[client]
socket=/var/lib/mysql/mysql.sock

[mysql]
socket=/var/lib/mysql/mysql.sock

[mysqldump]
socket=/var/lib/mysql/mysql.sock

La modifica del file socket richiederà anche un riavvio di MySQL e CMON. Se stai utilizzando "localhost", puoi aggiungere alcune opzioni di configurazione aggiuntive come skip-networking=1, per impedire di accettare connessioni remote. La nostra immagine ClusterControl Docker utilizza questo approccio per superare una limitazione nel proxy Docker durante l'associazione alle porte.

OpenSSH con SSSD

ClusterControl utilizza il protocollo SSH come canale di comunicazione principale per gestire e monitorare i nodi remoti. Le configurazioni OpenSSH predefinite sono abbastanza decenti e dovrebbero funzionare nella maggior parte dei casi. Tuttavia, in alcuni ambienti in cui SSH è integrato con altri strumenti di miglioramento della sicurezza come SElinux o System Security Services Daemon (SSSD), potrebbe avere un impatto significativo sulle prestazioni di SSH.

Abbiamo visto molti casi in cui una quantità sempre crescente di connessioni SSH stabilite a ciascuno dei nodi gestiti e, infine, sia il server ClusterControl che tutti i nodi gestiti esauriscono la memoria di sistema con le connessioni SSH. In alcuni casi, solo un normale riavvio dell'intero sistema notturno sul server ClusterControl potrebbe risolvere il problema.

Se esegui la tua infrastruttura con System Security Services Daemon (SSSD), ti consigliamo di commentare la seguente riga all'interno della configurazione del client OpenSSH in /etc/ssh/ssh_config sul nodo ClusterControl:

#ProxyCommand /usr/bin/sss_ssh_knownhostsproxy -p %p %h

Quanto sopra salterà utilizzando SSSD per gestire la chiave host, che sarà invece gestita dal client OpenSSH.

A partire da ClusterControl 1.7.0, è possibile utilizzare lo strumento di monitoraggio basato su agenti con Prometheus. Con il monitoraggio basato su agenti, ClusterControl non utilizza SSH per campionare le metriche host che possono essere eccessive in alcuni ambienti.

File system e partizionamento

Il controller ClusterControl scrive una nuova voce nel suo file di registro quasi ogni secondo per ogni cluster. Per coloro che vogliono sfruttare queste scritture sequenziali su disco e desiderano risparmiare sui costi, è possibile utilizzare un disco mandrino per questo scopo. Modifica la riga seguente all'interno di tutti cmon_X.cnf:

logfile=/new/partition/log/cmon_X.log

Sostituisci X con l'ID del cluster e riavvia il servizio CMON per applicare le modifiche.

Se si utilizza ClusterControl come repository di backup, si consiglia di allocare spazio su disco sufficiente su una partizione separata diversa dalla partizione radice. Migliora se la partizione risiede su un file system in rete o in cluster per un facile montaggio con i nodi di destinazione durante l'esecuzione dell'operazione di ripristino. Abbiamo visto casi in cui i backup creati hanno consumato tutto lo spazio su disco della partizione principale, con un impatto alla fine su ClusterControl e sui suoi componenti.

Rimani aggiornato

ClusterControl ha un ciclo di rilascio breve - almeno una nuova versione principale ogni trimestre dell'anno più patch di manutenzione settimanali (per lo più correzioni di bug, se presenti). Il motivo è che ClusterControl supporta più fornitori e versioni di database, sistemi operativi e piattaforme hardware. Spesso vengono introdotte nuove cose e vecchie cose deprecate da ciò che viene fornito. ClusterControl deve stare al passo con tutte le modifiche introdotte dai fornitori di applicazioni e seguire ogni volta le migliori pratiche.

Raccomandiamo agli utenti di utilizzare sempre l'ultima versione di ClusterControl (l'aggiornamento è facile) insieme al browser web più recente (costruito e testato su Google Chrome e Mozilla Firefox), poiché molto probabilmente stiamo sfruttando le nuove funzionalità disponibili nell'ultima versione.

Pensieri finali

Se hai domande o incontri problemi o problemi di lentezza durante l'utilizzo di ClusterControl, contattaci tramite il nostro canale di supporto. Suggerimenti e feedback sono molto graditi.

Buona messa a punto!