MariaDB
 sql >> Database >  >> RDS >> MariaDB

Analisi comparativa delle distribuzioni manuali del database rispetto alle distribuzioni automatizzate

Esistono diversi modi per distribuire un database. Puoi installarlo manualmente, puoi fare affidamento sugli strumenti di orchestrazione dell'infrastruttura ampiamente disponibili come Ansible, Chef, Puppet o Salt. Questi strumenti sono molto popolari ed è abbastanza facile trovare script, ricette, playbook, il che ti aiuterà ad automatizzare l'installazione di un cluster di database. Esistono anche piattaforme di automazione di database più specializzate, come ClusterControl, che possono essere utilizzate anche per la distribuzione automatizzata. Quale sarebbe il modo migliore per distribuire il tuo cluster? Di quanto tempo avrai effettivamente bisogno per implementarlo?

Per prima cosa, chiariamo cosa vogliamo fare. Supponiamo di distribuire Percona XtraDB Cluster 5.7. Sarà composto da tre nodi e per questo utilizzeremo tre macchine virtuali Vagrant che eseguono Ubuntu 16.04 (immagine bento/ubuntu-16.04). Tenteremo di distribuire un cluster manualmente, quindi utilizzando Ansible e ClusterControl. Vediamo come saranno i risultati.

Distribuzione manuale

Impostazione del repository - 1 minuto e 45 secondi.

Prima di tutto, dobbiamo configurare i repository Percona su tutti i nodi Ubuntu. Una rapida ricerca su Google, ssh nelle macchine virtuali e l'esecuzione dei comandi richiesti richiede 1m45s

Abbiamo trovato la seguente pagina con le istruzioni:
https://www.percona.com/doc/percona-repo-config/percona-release.html

e abbiamo eseguito i passaggi descritti nella sezione "DISTRIBUZIONI GNU/LINUX BASATE SU DEB". Abbiamo anche eseguito apt update, per aggiornare la cache di apt.

Installazione dei nodi PXC - 2 minuti e 45 secondi

Questo passaggio consiste sostanzialmente nell'esecuzione di:

[email protected]:~# apt install percona-xtradb-cluster-5.7

Il resto dipende principalmente dalla velocità della tua connessione Internet mentre i pacchetti vengono scaricati. Sarà anche necessario il tuo input (passerai una password per il superutente) in modo che non sia un'installazione automatica. Al termine, ti ritroverai con tre nodi Percona XtraDB Cluster in esecuzione:

root     15488  0.0  0.2   4504  1788 ?        S    10:12   0:00 /bin/sh /usr/bin/mysqld_safe
mysql    15847  0.3 28.3 1339576 215084 ?      Sl   10:12   0:00  \_ /usr/sbin/mysqld --basedir=/usr --datadir=/var/lib/mysql --plugin-dir=/usr/lib/mysql/plugin --user=mysql --wsrep-provider=/usr/lib/galera3/libgalera_smm.so --log-error=/var/log/mysqld.log --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/run/mysqld/mysqld.sock --wsrep_start_position=00000000-0000-0000-0000-000000000000:-1

Configurazione dei nodi PXC - 3 minuti e 25 secondi

Qui inizia la parte difficile. È davvero difficile quantificare l'esperienza e quanto tempo ci vorrebbe per capire effettivamente cosa è necessario fare. Cosa c'è di buono, la ricerca su Google "come installare percona xtrabdb cluster" punta alla documentazione di Percona, che descrive come dovrebbe apparire il processo. Potrebbe comunque volerci più o meno tempo, a seconda di quanto hai familiarità con il PXC e Galera in generale. Nella peggiore delle ipotesi non sarai a conoscenza di alcuna azione aggiuntiva richiesta e ti connetterai al tuo PXC e inizierai a lavorarci, senza renderti conto che, in effetti, hai tre nodi, ognuno dei quali forma un cluster a parte.

Supponiamo di seguire la raccomandazione di Percona e di calcolare solo quei passaggi da eseguire. Insomma, abbiamo modificato i file di configurazione come da istruzioni sul sito di Percona, abbiamo anche provato a fare il bootstrap del primo nodo:

[email protected]:~# /etc/init.d/mysql bootstrap-pxc
mysqld: [ERROR] Found option without preceding group in config file /etc/mysql/my.cnf at line 10!
mysqld: [ERROR] Fatal error in defaults handling. Program aborted!
mysqld: [ERROR] Found option without preceding group in config file /etc/mysql/my.cnf at line 10!
mysqld: [ERROR] Fatal error in defaults handling. Program aborted!
mysqld: [ERROR] Found option without preceding group in config file /etc/mysql/my.cnf at line 10!
mysqld: [ERROR] Fatal error in defaults handling. Program aborted!
mysqld: [ERROR] Found option without preceding group in config file /etc/mysql/my.cnf at line 10!
mysqld: [ERROR] Fatal error in defaults handling. Program aborted!
 * Bootstrapping Percona XtraDB Cluster database server mysqld                                                                                                                                                                                                                     ^C

Questo non sembrava corretto. Sfortunatamente, le istruzioni non erano chiarissime. Ancora una volta, se non sai cosa sta succedendo, trascorrerai più tempo cercando di capire cosa è successo. Fortunatamente, stackoverflow.com è molto utile (sebbene non sia la prima risposta nell'elenco che abbiamo ricevuto) e dovresti renderti conto che ti manca l'intestazione della sezione [mysqld] nel tuo file /etc/mysql/my.cnf. L'aggiunta di questo su tutti i nodi e la ripetizione del processo di bootstrap ha risolto il problema. In totale abbiamo impiegato 3 minuti e 25 secondi (esclusa la ricerca su Google dell'errore poiché abbiamo notato immediatamente qual era il problema).

Configurazione per SST, inserimento di altri nodi nel cluster - A partire da 8 minuti all'infinito

Le istruzioni sul sito Percona sono abbastanza chiare. Una volta che hai un nodo attivo e funzionante, avvia semplicemente i nodi rimanenti e andrà tutto bene. Abbiamo provato e non siamo stati in grado di vedere più nodi unirsi al cluster. È qui che è praticamente impossibile dire quanto tempo ci vorrà per diagnosticare il problema. Ci sono voluti 6-7 minuti ma per poterlo fare velocemente devi:

  1. Acquisisci familiarità con la struttura della configurazione PXC:
    [email protected]:~# tree  /etc/mysql/
    /etc/mysql/
    ├── conf.d
    │   ├── mysql.cnf
    │   └── mysqldump.cnf
    ├── my.cnf -> /etc/alternatives/my.cnf
    ├── my.cnf.fallback
    ├── my.cnf.old
    ├── percona-xtradb-cluster.cnf
    └── percona-xtradb-cluster.conf.d
        ├── client.cnf
        ├── mysqld.cnf
        ├── mysqld_safe.cnf
        └── wsrep.cnf
  2. Scopri come funzionano le direttive !include e !includedir nei file di configurazione di MySQL
  3. Scopri come MySQL gestisce le stesse variabili incluse in più file
  4. Sapere cosa cercare ed essere a conoscenza delle configurazioni che porterebbero al bootstrap del nodo stesso per formare un cluster da solo

Il problema era legato al fatto che le istruzioni non menzionavano nessun file tranne /etc/mysql/my.cnf dove, infatti, avremmo dovuto modificare /etc/mysql/percona-xtradb-cluster.conf.d/wsrep .cnf. Quel file conteneva una variabile vuota:

wsrep_cluster_address=gcomm://

e tale configurazione forza il nodo al bootstrap poiché non ha informazioni su altri nodi a cui unirsi. Abbiamo impostato quella variabile in /etc/mysql/my.cnf ma in seguito è stato incluso il file wsrep.cnf, sovrascrivendo la nostra configurazione.

Questo problema potrebbe essere un serio ostacolo per le persone che non hanno familiarità con il funzionamento di MySQL e Galera, risultando anche in ore, se non di più, di debug.

Tempo di installazione totale - 16 minuti (se sei un DBA MySQL come me)

Siamo riusciti a installare Percona XtraDB Cluster in 16 minuti. Devi tenere a mente un paio di cose:non abbiamo ottimizzato la configurazione. Questo è qualcosa che richiederà più tempo e conoscenza. Il nodo PXC viene fornito con alcune semplici configurazioni, relative principalmente alla registrazione binaria e alla replica del set di scrittura Galera. Non c'è ottimizzazione di InnoDB. Se non hai familiarità con i componenti interni di MySQL, sono ore, se non giorni, per leggere e familiarizzare con i meccanismi interni. Un'altra cosa importante è che questo è un processo che dovresti riapplicare per ogni cluster che distribuisci. Infine, siamo riusciti a identificare il problema e risolverlo molto velocemente grazie alla nostra esperienza con Percona XtraDB Cluster e MySQL in generale. L'utente occasionale molto probabilmente trascorrerà molto più tempo cercando di capire cosa sta succedendo e perché.

Playbook Ansible

Ora, passa all'automazione con Ansible. Proviamo a trovare e utilizzare un playbook ansible, che potremmo riutilizzare per tutte le ulteriori distribuzioni. Vediamo quanto tempo ci vorrà per farlo.

Configurazione della connettività SSH - 1 minuto

Ansible richiede la connettività SSH su tutti i nodi per connetterli e configurarli. Abbiamo generato una chiave SSH e l'abbiamo distribuita manualmente tra i nodi.

Trovare Ansible Playbook - 2 minuti e 15 secondi

Il problema principale qui è che ci sono così tanti playbook disponibili là fuori che è impossibile decidere cosa sia meglio. Pertanto, abbiamo deciso di utilizzare i primi 3 risultati di Google e provare a sceglierne uno. Abbiamo deciso su https://github.com/cdelgehier/ansible-role-XtraDB-Cluster poiché sembra essere più configurabile degli altri.

Clonazione del repository e installazione di Ansible - 30 secondi

Questo è veloce, tutto ciò di cui avevamo bisogno era

apt install ansible git
git clone https://github.com/cdelgehier/ansible-role-XtraDB-Cluster.git

Preparazione del file di inventario - 1 minuto e 10 secondi

Anche questo passaggio è stato molto semplice, abbiamo creato un file di inventario utilizzando un esempio dalla documentazione. Abbiamo appena sostituito gli indirizzi IP dei nodi con quelli che abbiamo configurato nel nostro ambiente.

Preparazione di un Playbook - 1 minuto e 45 secondi

Abbiamo deciso di utilizzare l'esempio più esteso della documentazione, che include anche un po' di messa a punto della configurazione. Abbiamo preparato una struttura corretta per l'Ansible (non c'erano tali informazioni nella documentazione):

/root/pxcansible/
├── inventory
├── pxcplay.yml
└── roles
    └── ansible-role-XtraDB-Cluster

Quindi l'abbiamo eseguito ma immediatamente abbiamo ricevuto un errore:

[email protected]:~/pxcansible# ansible-playbook pxcplay.yml
 [WARNING]: provided hosts list is empty, only localhost is available

ERROR! no action detected in task

The error appears to have been in '/root/pxcansible/roles/ansible-role-XtraDB-Cluster/tasks/main.yml': line 28, column 3, but may
be elsewhere in the file depending on the exact syntax problem.

The offending line appears to be:


- name: "Include {{ ansible_distribution }} tasks"
  ^ here
We could be wrong, but this one looks like it might be an issue with
missing quotes.  Always quote template expression brackets when they
start a value. For instance:

    with_items:
      - {{ foo }}

Should be written as:

    with_items:
      - "{{ foo }}"

Ci sono voluti 1 minuto e 45 secondi.

Risolto il problema con la sintassi del Playbook - 3 minuti e 25 secondi

L'errore era fuorviante, ma la regola generale è provare la versione Ansible più recente, cosa che abbiamo fatto. Abbiamo cercato su Google e trovato buone istruzioni sul sito Web di Ansible. Anche il prossimo tentativo di eseguire il playbook non è riuscito:

TASK [ansible-role-XtraDB-Cluster : Delete anonymous connections] *****************************************************************************************************************************************************************************************************************
fatal: [node2]: FAILED! => {"changed": false, "msg": "The PyMySQL (Python 2.7 and Python 3.X) or MySQL-python (Python 2.X) module is required."}
fatal: [node3]: FAILED! => {"changed": false, "msg": "The PyMySQL (Python 2.7 and Python 3.X) or MySQL-python (Python 2.X) module is required."}
fatal: [node1]: FAILED! => {"changed": false, "msg": "The PyMySQL (Python 2.7 and Python 3.X) or MySQL-python (Python 2.X) module is required."}

La configurazione della nuova versione di Ansible e l'esecuzione del playbook fino a questo errore hanno richiesto 3 minuti e 25 secondi.

Correzione del modulo Python mancante - 3 minuti e 20 secondi

Apparentemente, il ruolo che abbiamo utilizzato non si occupava dei suoi prerequisiti e mancava un modulo Python per la connessione e la protezione del cluster Galera. Per prima cosa abbiamo provato a installare MySQL-python tramite pip, ma è diventato evidente che ci vorrà più tempo poiché richiedeva mysql_config:

[email protected]:~# pip install MySQL-python
Collecting MySQL-python
  Downloading https://files.pythonhosted.org/packages/a5/e9/51b544da85a36a68debe7a7091f068d802fc515a3a202652828c73453cad/MySQL-python-1.2.5.zip (108kB)
    100% |████████████████████████████████| 112kB 278kB/s
    Complete output from command python setup.py egg_info:
    sh: 1: mysql_config: not found
    Traceback (most recent call last):
      File "<string>", line 1, in <module>
      File "/tmp/pip-build-zzwUtq/MySQL-python/setup.py", line 17, in <module>
        metadata, options = get_config()
      File "/tmp/pip-build-zzwUtq/MySQL-python/setup_posix.py", line 43, in get_config
        libs = mysql_config("libs_r")
      File "/tmp/pip-build-zzwUtq/MySQL-python/setup_posix.py", line 25, in mysql_config
        raise EnvironmentError("%s not found" % (mysql_config.path,))
    EnvironmentError: mysql_config not found

    ----------------------------------------
Command "python setup.py egg_info" failed with error code 1 in /tmp/pip-build-zzwUtq/MySQL-python/

Questo è fornito dalle librerie di sviluppo MySQL, quindi avremmo dovuto installarle manualmente, il che era praticamente inutile. Abbiamo deciso di utilizzare PyMySQL, che non richiedeva l'installazione di altri pacchetti. Questo ci ha portato a un altro problema:

TASK [ansible-role-XtraDB-Cluster : Delete anonymous connections] *****************************************************************************************************************************************************************************************************************
fatal: [node3]: FAILED! => {"changed": false, "msg": "unable to connect to database, check login_user and login_password are correct or /root/.my.cnf has the credentials. Exception message: (1698, u\"Access denied for user 'root'@'localhost'\")"}
fatal: [node2]: FAILED! => {"changed": false, "msg": "unable to connect to database, check login_user and login_password are correct or /root/.my.cnf has the credentials. Exception message: (1698, u\"Access denied for user 'root'@'localhost'\")"}
fatal: [node1]: FAILED! => {"changed": false, "msg": "unable to connect to database, check login_user and login_password are correct or /root/.my.cnf has the credentials. Exception message: (1698, u\"Access denied for user 'root'@'localhost'\")"}
    to retry, use: --limit @/root/pxcansible/pxcplay.retry

Fino a questo punto abbiamo impiegato 3 minuti e 20 secondi.

Correzione dell'errore "Accesso negato" - 18 minuti e 55 secondi

Come per errore, ci siamo assicurati che la configurazione di MySQL fosse preparata correttamente e che includesse l'utente e la password corretti per la connessione al database. Questo, purtroppo, non ha funzionato come previsto. Abbiamo esaminato ulteriormente e abbiamo scoperto che il ruolo non ha creato correttamente l'utente root, anche se ha contrassegnato il passaggio come completato. Abbiamo fatto una breve indagine ma abbiamo deciso di apportare la correzione manuale invece di provare a eseguire il debug del playbook, il che avrebbe richiesto molto più tempo rispetto ai passaggi che abbiamo fatto. Abbiamo appena creato manualmente gli utenti [email protected] e [email protected] con password corrette. Questo ci ha permesso di passare questo passaggio e su un altro errore:

TASK [ansible-role-XtraDB-Cluster : Start the master node] ************************************************************************************************************************************************************************************************************************
skipping: [node1]
skipping: [node2]
skipping: [node3]

TASK [ansible-role-XtraDB-Cluster : Start the master node] ************************************************************************************************************************************************************************************************************************
skipping: [node1]
skipping: [node2]
skipping: [node3]

TASK [ansible-role-XtraDB-Cluster : Create SST user] ******************************************************************************************************************************************************************************************************************************
skipping: [node1]
skipping: [node2]
skipping: [node3]

TASK [ansible-role-XtraDB-Cluster : Start the slave nodes] ************************************************************************************************************************************************************************************************************************
fatal: [node3]: FAILED! => {"changed": false, "msg": "Unable to start service mysql: Job for mysql.service failed because the control process exited with error code. See \"systemctl status mysql.service\" and \"journalctl -xe\" for details.\n"}
fatal: [node2]: FAILED! => {"changed": false, "msg": "Unable to start service mysql: Job for mysql.service failed because the control process exited with error code. See \"systemctl status mysql.service\" and \"journalctl -xe\" for details.\n"}
fatal: [node1]: FAILED! => {"changed": false, "msg": "Unable to start service mysql: Job for mysql.service failed because the control process exited with error code. See \"systemctl status mysql.service\" and \"journalctl -xe\" for details.\n"}
    to retry, use: --limit @/root/pxcansible/pxcplay.retry

Per questa sezione abbiamo impiegato 18 minuti e 55 secondi.

Risolto il problema "Avvia i nodi slave" (parte 1) - 7 minuti e 40 secondi

Abbiamo provato un paio di cose per risolvere questo problema. Abbiamo provato a specificare il nodo usando il suo nome, abbiamo provato a cambiare i nomi dei gruppi, niente ha risolto il problema. Abbiamo deciso di ripulire l'ambiente utilizzando lo script fornito nella documentazione e ricominciare da zero. Non lo ha pulito ma ha solo peggiorato le cose. Dopo 7 minuti e 40 secondi abbiamo deciso di cancellare le macchine virtuali, ricreare l'ambiente e ricominciare da zero sperando che quando aggiungeremo le dipendenze Python, questo risolverà il nostro problema.

Risolto il problema "Avvia i nodi slave" (parte 2) - 13 minuti e 15 secondi

Sfortunatamente, la configurazione dei prerequisiti Python non ha aiutato affatto. Abbiamo deciso di terminare il processo manualmente, avviando il bootstrap del primo nodo e quindi configurando l'utente SST e avviando gli slave rimanenti. Questo ha completato la configurazione "automatizzata" e ci sono voluti 13 minuti e 15 secondi per eseguire il debug e quindi finalmente accettare che non funzionerà come previsto dal designer del playbook.

Ulteriore debug:10 minuti e 45 secondi

Non ci siamo fermati qui e abbiamo deciso che proveremo un'altra cosa. Invece di fare affidamento sulle variabili Ansible, mettiamo semplicemente l'IP di uno dei nodi come nodo principale. Questo ha risolto quella parte del problema e abbiamo finito con:

TASK [ansible-role-XtraDB-Cluster : Create SST user] ******************************************************************************************************************************************************************************************************************************
skipping: [node2]
skipping: [node3]
fatal: [node1]: FAILED! => {"changed": false, "msg": "unable to connect to database, check login_user and login_password are correct or /root/.my.cnf has the credentials. Exception message: (1045, u\"Access denied for user 'root'@'::1' (using password: YES)\")"}

Questa è stata la fine dei nostri tentativi:abbiamo provato ad aggiungere questo utente ma non ha funzionato correttamente tramite il playbook ansible mentre potevamo utilizzare l'indirizzo IPv6 localhost a cui connetterci quando si utilizza il client MySQL.

Tempo di installazione totale - Sconosciuto (installazione automatizzata non riuscita)

In totale abbiamo impiegato 64 minuti e non siamo ancora riusciti a far partire le cose automaticamente. I problemi rimanenti sono la creazione della password di root che non sembra funzionare e quindi l'avvio di Galera Cluster (problema utente SST). È difficile dire quanto tempo ci vorrà per eseguire il debug ulteriormente. È sicuramente possibile:è solo difficile da quantificare perché dipende davvero dall'esperienza con Ansible e MySQL. Non è sicuramente qualcosa che chiunque può semplicemente scaricare, configurare ed eseguire. Bene, forse un altro playbook avrebbe funzionato diversamente? È possibile, ma può anche causare problemi diversi. Ok, quindi c'è una curva di apprendimento da scalare e fare il debug ma poi, quando sei pronto, eseguirai semplicemente uno script. Bene, è quasi vero. Finché le modifiche introdotte dal manutentore non interromperanno qualcosa da cui dipendi o la nuova versione di Ansible interromperà il playbook o il manutentore semplicemente dimenticherà il progetto e smetterà di svilupparlo (per il ruolo che abbiamo usato c'è un'utile richiesta pull in attesa già da quasi un anno, il che potrebbe essere in grado di risolvere il problema della dipendenza da Python (non è stato unito). A meno che non accetti che dovrai mantenere questo codice, non puoi davvero fare affidamento sul fatto che sia accurato al 100% e funzioni nel tuo ambiente, soprattutto dato che lo sviluppatore originale non ha incentivi per mantenere aggiornato il codice. Inoltre, che dire delle altre versioni? Non è possibile utilizzare questo particolare playbook per installare PXC 5.6 o qualsiasi versione di MariaDB. Certo, ci sono altri playbook che puoi trovare. Funzioneranno meglio o forse passerai altre ore cercando di farli funzionare?

ClusterControlSingle Console per l'intera infrastruttura di databaseScopri cos'altro c'è di nuovo in ClusterControlInstalla ClusterControl GRATIS

Controllo cluster

Infine, diamo un'occhiata a come ClusterControl può essere utilizzato per distribuire Percona XtraDB Cluster.

Configurazione della connettività SSH - 1 minuto

ClusterControl richiede la connettività SSH su tutti i nodi per la connessione e la configurazione. Abbiamo generato una chiave SSH e l'abbiamo distribuita manualmente tra i nodi.

Configurazione di ClusterControl - 3 minuti e 15 secondi

La ricerca rapida "Installazione di ClusterControl" ci ha indirizzato alla pagina della documentazione di ClusterControl pertinente. Stavamo cercando un "modo più semplice per installare ClusterControl", quindi abbiamo seguito il link e abbiamo trovato le seguenti istruzioni.

Il download dello script e l'esecuzione sono stati necessari 3 minuti e 15 secondi, abbiamo dovuto intraprendere alcune azioni durante l'installazione in modo che non si tratti di un'installazione automatica.

Accesso all'interfaccia utente e avvio della distribuzione - 1 minuto e 10 secondi

Abbiamo puntato il nostro browser all'IP del nodo ClusterControl.

Abbiamo superato le informazioni di contatto richieste e ci è stata presentata la schermata di benvenuto:

Passaggio successivo:abbiamo scelto l'opzione di distribuzione.

Abbiamo dovuto trasmettere i dettagli sulla connettività SSH.

Abbiamo anche deciso il fornitore, la versione, la password e gli host da utilizzare. L'intero processo ha richiesto 1 minuto e 10 secondi.

Distribuzione del cluster Percona XtraDB - 12 minuti e 5 secondi

L'unica cosa rimasta era aspettare che ClusterControl finisse la distribuzione. Dopo 12 minuti e 5 secondi il cluster era pronto:

Tempo di installazione totale:17 minuti e 30 secondi

Risorse correlate ClusterControl per MySQL ClusterControl per MariaDB ClusterControl per Galera Cluster

Siamo riusciti a distribuire ClusterControl e quindi il cluster PXC utilizzando ClusterControl in 17 minuti e 30 secondi. La implementazione PXC stessa ha richiesto 12 minuti e 5 secondi . Alla fine abbiamo un cluster funzionante, distribuito secondo le migliori pratiche. ClusterControl garantisce inoltre che la configurazione del cluster abbia senso. In breve, anche se non sai nulla di MySQL o di Galera Cluster, puoi avere un cluster pronto per la produzione distribuito in un paio di minuti. ClusterControl non è solo uno strumento di distribuzione, è anche una piattaforma di gestione:rende ancora più facile per le persone che non hanno esperienza con MySQL e Galera identificare problemi di prestazioni (tramite consulenti) ed eseguire azioni di gestione (scalare il cluster su e giù, eseguire backup, creare schiavi asincroni di Galera). Ciò che è importante, ClusterControl sarà sempre mantenuto e può essere utilizzato per distribuire tutte le versioni di MySQL (e non solo MySQL/MariaDB, supporta anche TimeScaleDB, PostgreSQL e MongoDB). Ha anche funzionato immediatamente, cosa che non si può dire su altri metodi che abbiamo testato.

Se desideri provare lo stesso, puoi scaricare ClusterControl gratuitamente. Facci sapere come ti è piaciuto.