1. Sottoli in the cloud
Come smaterializzare i server di gestione
d'impresa e vivere felici

2. Mercoledì 17 Novembre 2010, ore 07.30 AM
La 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!

3. 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!

4. Alcuni punti chiave da analizzare:
L'azienda è stata ferma amministrativamente per 12 ore
Se si fosse dovuto ricorrere alla recovery l'impatto sarebbe stato
più doloroso, in quanto sarebbe stato necessario l'intervento umano
per più giorni per verificare l'effettiva consistenza delle copie,
la recovery corretta dei dump dei database etc etc...
Qualche dato potrebbe essere stato perso?

5. Soluzione:

6. Soluzione:
FAILOVER

7. 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.

8. 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...


9. 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

10. 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

11. 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!

12. 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)

13. Vmware Vsphere enterprise edition

14. Step diversi per raggiungere il failover con Vmware
HA 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 secondario
entra 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 nel
nodo di backup.
Possibilità di fare bilanciamento del carico spostando sul nodo secondario
macchine con carico di lavoro eccessivo o penalizzanti per il corretto funzionamento
del nodo primario
Restart automatico di host che sono diventati instabili (VM windows imballate etc etc)

15. Breve iter per exempla

16. 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

17. Non voglio aspettare nemmeno un
secondo

18. Non voglio aspettare nemmeno un
secondo
allora dobbiamo far entrare in gioco
fault tollerance

19. allora dobbiamo far entrare in gioco
fault tollerance
secondo
Non voglio aspettare nemmeno un

20. 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

21. anche qui breve iter per exempla

22. 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

23. 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

24. requisiti per una soluzione HA
software: vmware vsphere essential plus
hardware:
un altro host gemello a quello esistente
uno switch gigabit per iscsi
uno switch gigabit per heartbeat
una scheda ethernet supplementare per l’host già in essere

25. requisiti per una soluzione FT
software: vmware vsphere advanced
hardware:
un altro host gemello a quello esistente
uno switch gigabit per iscsi
uno switch gigabit per heartbeat
una scheda ethernet supplementare per l’host già in essere

26. ridondanza storage
nuove SAN con replication
SAN appliance in opensource con
replica heartbeat, incorporando anche
la SAN già in essere

27. Anton de Martini
Sys Admin @ cpline.net
www.cpline.net
www.dema.tv
http://compl.in/fRyOQi