Sottoli in the cloudCome smaterializzare i server di gestione

d'impresa e vivere felici

Mercoledì 17 Novembre 2010, ore 07.30 AMLa san DS3300 IBM che fornisce lo storage per l'host ESXI con 5 server necessari al

funzionamento dell'azienda si blocca a causa di una rottura del controller iScsi.

Panico!

Copie immagine di Backup ferme a sabato 13 novembre

Lunghi tempi di recovery da copie su NAS e intervento di sistemisti e programmatori di terze parti

NON VA BENE!

Alcuni punti chiave da analizzare:L'azienda è stata ferma amministrativamente per 12 ore

Se si fosse dovuto ricorrere alla recovery l'impatto sarebbe statopiù doloroso, in quanto sarebbe stato necessario l'intervento umanoper più giorni per verificare l'effettiva consistenza delle copie,la recovery corretta dei dump dei database etc etc...

Qualche dato potrebbe essere stato perso?

Soluzione:

Soluzione:

FAILOVER

Prima un piccolo riepilogo

Attuale infrastruttura server Neri Sottoli:Un host esxi che fa girare 6 Virtual Machines linkato con 1 gigabit ethernet a una SAN ds3300 IBM in iScsi.La LUN iScsi è formattata in VMFS e i dischi delle virtual machines sono in formato thin-provisioning.

Backup Policies attuali

Il backup coinvolge i seguenti server: –Server2003 – Il server principale, nel quale girano gli applicativi

adonix. Il backup consiste in uno script rsync che ogni notte dal lunedì al sabato copia le directory dei dump del database

–Cappero2 – il server di controllo del dominio. Nel disco E di Cappero2 da circa 200Gb sono contenuti i documenti condivisi, i salvataggi dei file pst di outlook, i dump del database della Baa etc etc...

Backup Policies attuali

Copie a livello immagine Ogni week-end avviene la clonazione delle macchine più importanti

presso la SAN/NAS Emc2 situata in Geldor. – PC-ACCESSI il server che registra i cartellini d'accesso viene clonato

in circa un'ora alle 01.00 AM di ogni venerdì–Server2003 viene clonato in circa 8,5 ore alle 02.00PM di ogni sabato

–Cappero2 viene clonato in circa 17 ore alle 06.00 AM di ogni domenica

Recovery In caso di rottura della SAN principale DS3300 o

dell'host ESXi è prevista l'accensione di un host di riserva o di un ripristino delle immagini del fine

settimana più il caricamento dei salvataggi su NAS

Recovery In caso di rottura della SAN principale DS3300 o

dell'host ESXi è prevista l'accensione di un host di riserva o di un ripristino delle immagini del fine

settimana più il caricamento dei salvataggi su NAS

Too sloooooowww!

Recovery In caso di rottura della SAN principale DS3300 o

dell'host ESXi è prevista l'accensione di un host di riserva o di un ripristino delle immagini del fine

settimana più il caricamento dei salvataggi su NAS

Too sloooooowww!(and dangerous)

Vmware Vsphere enterprise edition

Step diversi per raggiungere il failover con VmwareHA tramite licenza vsphere essential plus:Tramite HA siamo in grado di costruire dei cluster di host definendo primari e secondari. Quando si attiva HA i nodi principali e quelli secondari sono in sincronia tramite heartbeat. Nel caso il nodo primario avesse problemi il secondarioentra in azione, facendo partire secondo un ordine deciso a priori le VM prima gestite dal nodo principale.Vantaggi: Tempi di downtime minimi, relativi solo al tempo di boot delle VM nelnodo di backup.Possibilità di fare bilanciamento del carico spostando sul nodo secondario macchine con carico di lavoro eccessivo o penalizzanti per il corretto funzionamentodel nodo primario Restart automatico di host che sono diventati instabili (VM windows imballate etc etc)

Breve iter per exempla

Tempi di recovery con HA

Circa 3 minuti per VM da ritirare su, moltiplicato per il numero di VM presenti nell’host fallito.Nel nostro caso avremo un down di 18 minuti circa in caso di fallimento dell’host principale

Non voglio aspettare nemmeno un secondo

Non voglio aspettare nemmeno un secondo

allora dobbiamo far entrare in gioco fault tollerance

Non voglio aspettare nemmeno un secondo

allora dobbiamo far entrare in gioco fault tollerance

falt tollerance tramite licenza vsphere advanced

fault tolerance si appoggia alla struttura HA già in essere prevedendo la possibilità di rendere alcune o tutte le VM di un host continuamente disponibili, anche in caso di crollo dell’host principale.Per fare questo, una VM gemella viene creata ed attivata nel cluster secondario. Tutte le operazione compiute nella VM vengono replicate in tempo reale nella gemella, che è pronta ad entrare in azione in caso di fallimento della principale

anche qui breve iter per exempla

riassumendo

con HA creo un cluster di host esxi eleggendo un nodo primario ed uno secondario, pronto ad entrare in azione in caso di fallimento dell’host principale. Devo attendere il

tempo di boot delle VM

con FT all’interno di HA creo delle repliche vive delle VM pronte a rendere disponibili alla rete locale le proprie risorse immediatamente in caso di crash dell’host principale

Hei, perché non mi hai parlato di storage?

Semplice, perché vmware non gestisce la replica dello storage iSCSI o FC. Può al limite gestire lo storage vmotion come completamento della famosa funzione

vmotion. In sostanza si può muovere a caldo i files di una VM da un datastore ad un altro, senza

dover fermare la VM

requisiti per una soluzione HA

software: vmware vsphere essential plus

hardware: un altro host gemello a quello esistenteuno switch gigabit per iscsiuno switch gigabit per heartbeatuna scheda ethernet supplementare per l’host già in essere

requisiti per una soluzione FT

software: vmware vsphere advanced

hardware: un altro host gemello a quello esistenteuno switch gigabit per iscsiuno switch gigabit per heartbeatuna scheda ethernet supplementare per l’host già in essere

ridondanza storage

nuove SAN con replication

SAN appliance in opensource con replica heartbeat, incorporando anche

la SAN già in essere

Anton de Martini

Sys Admin @ cpline.net

www.cpline.net

www.dema.tv

http://compl.in/fRyOQi