strutture:lnf:dr:calcolo:sistemi:galera_custer
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
strutture:lnf:dr:calcolo:sistemi:galera_custer [2015/11/24 15:31] – rorru@infn.it | strutture:lnf:dr:calcolo:sistemi:galera_custer [2016/10/13 14:43] (current) – [Spegnimento di tutti i nodi] rorru@infn.it | ||
---|---|---|---|
Line 1: | Line 1: | ||
+ | ====== Galera Cluster Test e Manutenzione ====== | ||
+ | ===== Introduzione ===== | ||
+ | |||
+ | Il cluster Galera (Percona XtraDB Cluster) in uso ai LNF è composto da 3 nodi in configurazione multi-master, | ||
+ | |||
+ | {{: | ||
+ | |||
+ | I nodi sono cosi organizzati: | ||
+ | |||
+ | * Il nodo **F** viene utilizzato per effettuare il backup secondo le schedule previste, e non viene solitamente impiegato dal load-balancer per soddisfare le richieste utente. Tuttavia, viene utilizzato per mantenere il servizio disponibile in casi di particolare emergenza dove i restanti nodi non risultano essere disponibili. | ||
+ | * Il nodo **G** e il nodo **L** vengono utilizzati per fornire il servizio durante il funzionamento ordinario, secondo una politica round-robin. | ||
+ | * Il cluster è organizzato in modo che fino a che un nodo nel sistema risulta funzionante, | ||
+ | * I nodi che compongono il cluster sono interconnesi tra loro in maniera completa, le relative connessioni sono schematizzate dai segmenti **A**, **B** e **C** nel diagramma sopra. | ||
+ | |||
+ | ===== Definizione dei test ===== | ||
+ | |||
+ | I test eseguiti mirano a verificare (in maniera non formale) il corretto funzionamento del cluster nel rispetto delle caratteristiche attese: | ||
+ | |||
+ | * **Fault tolerance** | ||
+ | * **Disaster recovery** | ||
+ | |||
+ | In maggior dettaglio, queste caratteristiche sono garantite dalla replicazione dei dati sui vari nodi (disaster recovery), che interagiscono coordinandosi nella fornitura del servizio al fine di ovviare a eventuali malfunzionamneti delle diverse componenti HW/SW del cluster (fault tolerance). | ||
+ | |||
+ | I test riguardano tre casistiche distinte: | ||
+ | |||
+ | * Partizionamento della rete | ||
+ | * Variazione dei nodi componenti il cluster in maniera // | ||
+ | * Variazione dei nodi componenti il cluster in maniera // | ||
+ | |||
+ | Queste tipologie di test non hanno lo scopo di coprire o indentificare tutte le situazioni che portano ad un malfunzionamento, | ||
+ | |||
+ | Vengono di seguito riportati le definizioni dei test e le osservazioni a riguardo. | ||
+ | |||
+ | ===== Network Partition ===== | ||
+ | |||
+ | Il partizionamento della rete è stato simulato attraverso la definizione di alcune regole per // | ||
+ | |||
+ | < | ||
+ | iptables -A INPUT -s < | ||
+ | iptables -A OUTPUT -d < | ||
+ | </ | ||
+ | quindi il nodo con ip '' | ||
+ | |||
+ | Un cluster Galera viene considerato il concetto di //Primary Component//, | ||
+ | |||
+ | ==== Isolamento parziale ==== | ||
+ | |||
+ | In questo caso di studio viene simulato il fault di un solo segmento di rete, come mostrato dallo schema: | ||
+ | |||
+ | {{: | ||
+ | |||
+ | In questo scenario, i nodi riescono ancora a condividere lo stato del cluster, e il funzionamento non viene inificiato. | ||
+ | |||
+ | ==== Isolamento totale ==== | ||
+ | |||
+ | In questo caso viene simulato il partizionamento della rete interrompendo la comunicazione tra due segmenti (1): | ||
+ | |||
+ | {{: | ||
+ | |||
+ | A questo punto un nodo del cluster (**F** nello schema) non riuscendo più a raggiungere gli altri due nodi, si ritrova isolato e interrompe il funzionamento (2). Ad ogni interrogazione risponderà con un messaggio del genere: | ||
+ | |||
+ | < | ||
+ | ERROR 1047 (08S01) at line 1: WSREP has not yet prepared node for application use | ||
+ | </ | ||
+ | Lo stato del nodo rispetto al cluster può essere verificato interrogando la variabile '' | ||
+ | |||
+ | < | ||
+ | SHOW STATUS WHERE Variable_name=' | ||
+ | +---------------+-------+ | ||
+ | | Variable_name | Value | | ||
+ | +---------------+-------+ | ||
+ | | wsrep_ready | ||
+ | +---------------+-------+ | ||
+ | </ | ||
+ | Possiamo inoltre verificare la cardinalità del cluster con: | ||
+ | |||
+ | < | ||
+ | SHOW STATUS WHERE Variable_name=' | ||
+ | </ | ||
+ | Se la query viene effettuata sul nodo isolato (**F** nel nostro caso) la risposta sarà: | ||
+ | |||
+ | < | ||
+ | +--------------------+-------+ | ||
+ | | Variable_name | ||
+ | +--------------------+-------+ | ||
+ | | wsrep_cluster_size | 1 | | ||
+ | +--------------------+-------+ | ||
+ | </ | ||
+ | Mentre se l' | ||
+ | |||
+ | < | ||
+ | +--------------------+-------+ | ||
+ | | Variable_name | ||
+ | +--------------------+-------+ | ||
+ | | wsrep_cluster_size | 2 | | ||
+ | +--------------------+-------+ | ||
+ | </ | ||
+ | In questa situazione, i nodi che continuano a comunicare tra loro costituiscono il //Primary Component// | ||
+ | |||
+ | A questo punto, se si procede al recovery, il nodo isolato potrebbe contattare nuovamente i nodi, e tornare a far parte del cluster. Immaginando di rispristinare un segmento di rete alla volta, diciamo il segmento **F-G**, il nodo precedentemente isolato tenta di sincronizzarsi con fli altri nodi, quindi individua un nodo all' | ||
+ | |||
+ | Per ovviare al problema, è possibile forzare il //donor// utilizzato per il sync impostando una voce nel file di configurazione del servizio, ora spento sul server isolato: | ||
+ | |||
+ | < | ||
+ | wsrep_sst_donor='< | ||
+ | </ | ||
+ | Dove '' | ||
+ | |||
+ | < | ||
+ | ... | ||
+ | wsrep_node_name='< | ||
+ | ... | ||
+ | </ | ||
+ | Prima di riavviare il servizio sul nodo precedentemente isolato, è necessario assicurarsi che tutti i nodi presenti nella la lista alla voce '' | ||
+ | |||
+ | < | ||
+ | ... | ||
+ | wsrep_cluster_address=" | ||
+ | ... | ||
+ | </ | ||
+ | e supponendo che il nodo isolato abbia ip '' | ||
+ | |||
+ | < | ||
+ | ... | ||
+ | wsrep_cluster_address=" | ||
+ | wsrep_node_name='< | ||
+ | ... | ||
+ | </ | ||
+ | E avviare il server. Dopo aver constatato il corretto riavvio, e dopo aver ripristinato per intero le connessioni di rete, possiamo ripristinare le voci sul file di configurazione ai valori originari, e modificare la variabile (dinamica) per rispecchiare la configurazione del cluster con la query: | ||
+ | |||
+ | < | ||
+ | SET GLOBAL wsrep_cluster_address=' | ||
+ | </ | ||
+ | ===== Stop dei servizi (alterazione struttura cluster graceful) ===== | ||
+ | |||
+ | Durante i test effettuati non sono stati riscontrati interruzioni del servizio o malfunzionamenti anche nel caso in cui i nodi che vengono spenti siano due. | ||
+ | |||
+ | {{: | ||
+ | |||
+ | Il cluster in questo caso, diviene consapevole della riduzione della cardinalità del cluster (e del //Primary Component// | ||
+ | |||
+ | ===== Crash della macchina (alterazione struttura cluster ungraceful) ===== | ||
+ | |||
+ | Nel test precedente i nodi " | ||
+ | |||
+ | Questo fa capire come questo tipo di situazioni causano i problemi pià difficili da gestire, e spesso richiedono manutenzione // | ||
+ | |||
+ | ==== Spegnimento di un nodo ==== | ||
+ | |||
+ | Spegnendo un solo nodo, il cluster viene mantenuto in vita dai nodi restanti che si accorgono velocemente della mancanza del nodo spento; non è necessario nessun intervento manuale. | ||
+ | |||
+ | ==== Spegnimento di due nodi ==== | ||
+ | |||
+ | Quando un ulteriore nodo viene spento, il nodo superstite non riceve nessuna informazione sullo spegnimento imminente, e non ha la possibilità di rimodulare il calcolo del quorum necessario al funzionamento del cluster. Quindi è costretto a interrompere la gestione delle richieste (come schematizzato in figura). | ||
+ | |||
+ | {{: | ||
+ | |||
+ | Infatti, se immettiamo la query: | ||
+ | |||
+ | < | ||
+ | SHOW STATUS WHERE Variable_name=' | ||
+ | </ | ||
+ | Possiamo analizzare la risposta ricevuta: | ||
+ | |||
+ | < | ||
+ | +---------------------------+--------------+ | ||
+ | | Variable_name | ||
+ | +---------------------------+--------------+ | ||
+ | | wsrep_local_state_comment | Initialized | ||
+ | | wsrep_cluster_size | ||
+ | | wsrep_cluster_status | ||
+ | | wsrep_ready | ||
+ | +---------------------------+--------------+ | ||
+ | </ | ||
+ | E quindi constatare che il nodo non è operativo e inoltre non far parte del //Primary Component// (dato che non esiste una partizione di nodi del cluster funzionanti, | ||
+ | |||
+ | < | ||
+ | SET GLOBAL wsrep_provider_options=' | ||
+ | </ | ||
+ | A questo punto il nodo continua ad operare in attesa che gli altri nodi vengano rispristinati, | ||
+ | |||
+ | ==== Spegnimento di tutti i nodi ==== | ||
+ | |||
+ | Quando l' | ||
+ | |||
+ | < | ||
+ | # mysqld_safe --wsrep-recover | ||
+ | 151105 15:41:34 mysqld_safe Logging to '/ | ||
+ | 151105 15:41:34 mysqld_safe Starting mysqld daemon with databases from / | ||
+ | 151105 15:41:34 mysqld_safe WSREP: Running position recovery with --log_error='/ | ||
+ | 151105 15:41:36 mysqld_safe WSREP: Recovered position 35114f7b-7320-11e5-9e1e-7f73435b73aa: | ||
+ | 151105 15:41:39 mysqld_safe mysqld from pid file / | ||
+ | </ | ||
+ | La stringa alla penultima voce indica, a fine riga, il numero di sequenza (nel nostro caso 259056). Il nodo che risulta avere il numero di sequenza più alto deve essere riavviato per primo. Per riavviare il server con numero di sequenza superiore digitare: | ||
+ | |||
+ | < | ||
+ | # systemctl start mysql@bootstrap.service | ||
+ | </ | ||
+ | |||
+ | In seguito poi è possibile riavviare i restanti nodi, che entreranno a far parte del cluster in maniera automatica. | ||
+ | ===== Monitoraggio dello stato durante un' | ||
+ | |||
+ | I problemi evidenziati ai punti precedenti si presentamo principalmente quando un' | ||
+ | |||
+ | < | ||
+ | SHOW STATUS LIKE ' | ||
+ | </ | ||
+ | I valori che la variable può assumere sono: | ||
+ | |||
+ | * " | ||
+ | * " | ||
+ | * " | ||
+ | |||
+ | Si noti che durante le fasi di sincronizzazione i due nodi coinvolti non risultano operativi per tutta la durata del trasferimento, |