HA? FT? FC! (forse)

[antoniox]

Riprende la saga dei miei post.

L'argomento è sempre lo stesso: come assicurare che i server siano sempre funzionanti?

Ecco: la domanda che mi ponevo era in realtà sbagliata nella sua essenza.
Devo ringraziare il buon Carmine Lamberti (fornitore dell'applicativo che utilizzo in ufficio) che mi ha illuminato a proposito. Spero di riportare in maniera, di seguito, le considerazioni fatte e sollecito un confronto.

A me (utente ma anche amministratore o committente) non frega nulla di come stiano i server, se accesi o spenti o quale stia lavorando e quale no.
A me interessa che i servizi che essi erogano non si fermino mai.

Ragionando su questo, mi faceva notare che l'HA (High Availability) o il FT (Faul Tolerance) proposti da VMWare non sono la panacea.
Queste caratteristiche assicurano che le macchine virtuali funzionino ma non mettono al riparo da una eventuale corruzione del file system che le renderebbe di fatto inservibili con conseguenze facilmente intuibili sull'erogazione dei servizi.

(una corretta gestione dei backup delle VM e dei dati, permetterebbe di certo un ripristino quasi immediato e senza perdite importanti di dati, almeno nel contesto non di massima criticità nel quale opero)


La soluzione suggerita è quella di implementare un cluster di failover (FC) per rendere i servizi web, sql e AD.


La prima domanda è: che ne pensate?

La seconda è più complessa.
Non avendo mai avuto a che fare con queste caratteristiche, non mi è ben chiara la gestione "materiale" delle risorse.
In particolare: su due (o più) server fisici (nodi) installo il SO (Windows 2008 Enterprise); i server hanno quindi necessità di un sistema di dischi possibilmente in RAID.

Non mi è chiaro se sia necessaria o meno una SAN; non mi è chiaro se i dati (ad esempio il database SQL) siano memorizzati contemporaneamente su entrambi i server oppure sulla SAN (LUN condivise).
Non mi è chiaro se sia necessaria la presenza di un altro server che faccia da DC (Domain Controller).
Non mi è chiaro se costituisca una complicazione inutile installare il SO anziché sul server fisico su una macchina virtuale nel server fisico per sfruttare le possibilità di backup\duplicazione delle VM.

Grazie.

[OUTATIME]

Dipende come vuoi assicurare la continuità del servizio.

Se crei un cluster applicativo, teoricamente potresti evitare un cluster VMware, viceversa se crei un cluster VMware potresti evitare il cluster applicativo.

Oppure li puoi avere entrambi.

La corruzione del filesystem, la risolvi o con un cluster applicativo o con una adeguata strategia di disaster recovery.

Quale che sia la strada, sono tanti soldi da spendere...

[antoniox]

Dipende come vuoi assicurare la continuità del servizio.
In maniera che sia amministrabile in maniera "semplice", sicuramente.
La scarsità di risorse non consente strade come l'outsourcing oppure la presenza di un responsabile (capace) dell'IT nell'organizzazione.

Quale che sia la strada, sono tanti soldi da spendere...
:D vero! Vorrei limitarmi a considerare una infrastruttura di 2 server fisici + una NAS i-scsi, per ora. Più i costi delle licenze, ovviamente.


La corruzione del filesystem, la risolvi o con un cluster applicativo o con una adeguata strategia di disaster recovery.
Preferibile la prima alternativa.

Grazie per il contributo.

[Tasslehoff]

Riprende la saga dei miei post.

L'argomento è sempre lo stesso: come assicurare che i server siano sempre funzionanti?

Ecco: la domanda che mi ponevo era in realtà sbagliata nella sua essenza.
Devo ringraziare il buon Carmine Lamberti (fornitore dell'applicativo che utilizzo in ufficio) che mi ha illuminato a proposito. Spero di riportare in maniera, di seguito, le considerazioni fatte e sollecito un confronto.

A me (utente ma anche amministratore o committente) non frega nulla di come stiano i server, se accesi o spenti o quale stia lavorando e quale no.
A me interessa che i servizi che essi erogano non si fermino mai.

Ragionando su questo, mi faceva notare che l'HA (High Availability) o il FT (Faul Tolerance) proposti da VMWare non sono la panacea.
Queste caratteristiche assicurano che le macchine virtuali funzionino ma non mettono al riparo da una eventuale corruzione del file system che le renderebbe di fatto inservibili con conseguenze facilmente intuibili sull'erogazione dei servizi.

(una corretta gestione dei backup delle VM e dei dati, permetterebbe di certo un ripristino quasi immediato e senza perdite importanti di dati, almeno nel contesto non di massima criticità nel quale opero)


La soluzione suggerita è quella di implementare un cluster di failover (FC) per rendere i servizi web, sql e AD.


La prima domanda è: che ne pensate?L'obiezione fatta dal tuo fornitore è sensata, le virtual machines sono suscettibili di corruzione del filesystem, ma quale sistema non lo è?
Qualsiasi sistema fa uso di un repository che utilizza un qualche tipo di filesystem, quindi non capisco che senso abbia fare questa obiezione.

Se si riferisce al fatto che con vmware avresti più strati di filesystem su cui poggiano i tuoi dati (es filesystem del datastore vmware e filesystem della vm guest) hai ragione, ma questo si pone unicamente con l'utilizzo di hard disk virtuali "classici" (i normali file .vmdk per intenderci utilizzano la nomenclatura di vmware), se come storage della virtual machines utilizzi della lun (fibre channel o iSCSI non importa) raw salti direttamente uno step e utilizzi le lun della san di turno direttamente, esattamente come faresti con un server fisico.

La seconda è più complessa.
Non avendo mai avuto a che fare con queste caratteristiche, non mi è ben chiara la gestione "materiale" delle risorse.
In particolare: su due (o più) server fisici (nodi) installo il SO (Windows 2008 Enterprise); i server hanno quindi necessità di un sistema di dischi possibilmente in RAID.

Non mi è chiaro se sia necessaria o meno una SAN; non mi è chiaro se i dati (ad esempio il database SQL) siano memorizzati contemporaneamente su entrambi i server oppure sulla SAN (LUN condivise).
Non mi è chiaro se sia necessaria la presenza di un altro server che faccia da DC (Domain Controller).
Non mi è chiaro se costituisca una complicazione inutile installare il SO anziché sul server fisico su una macchina virtuale nel server fisico per sfruttare le possibilità di backup\duplicazione delle VM.

Grazie.Premessa doverosa: la quasi totalità degli approcci di fault tolerance che esulano dall'ambito applicativo generano sempre e comunque dei down. Magari brevi o molto brevi, ma il passaggio dei servizi da un server all'altro (anche automaticamente) genera un down e un ripristino dei servizi, ragion per cui occorre che le applicazioni che utilizzano le risorse erogate da questo servizio prevedano questa casistica.
Le uniche (almeno dalla mia esperienza) architetture di fault tolerance che non generano down fanno uso di meccanismi applicativi specifici del servizio di turno; tra questi spesso ci sono due approcci differenti, nodi differenti con ciascuno il proprio repository che replicano i dati istantaneamente (es Lotus Domino cluster o MySQL giusto per citare i primi che mi vengono in mente) oppure nodi separati che utilizzano contemporaneamente lo stesso repository condiviso (es Oracle RAC con ASM).

Come vedi l'approccio è molto diverso, in questo genere di architetture c'è uno strato software che gestisce la sincronizzazione oppure che media l'accesso al repository fisico (che può essere lo storage oppure un dbms di un qualche tipo), nel caso di architetture di fault tolerance gestite dal sistema operativo l'approccio è di tipo differente, con un nodo attivo e uno passivo, e dove in caso di down le risorse (lun, storage di rete, alias di rete o altro) vengono montate e attivate sul nodo passivo e i servizi vengono avviati.

Il caso che tu descrivi (cluster Windows) è un caso particolare, puoi fare lo stesso (e in modo molto più gestibile e meno dispendioso) anche con Redhat.
Io non ho mai creato cluster Windows per cui non ho dati certi e specifici, però mi pare di ricordare che Active directory sia un requisito; lo storage condiviso ti serve solo se il software che vuoi mettere in HA non può replicare i dati tra un nodo e l'altro del cluster, e può essere una banale share SMB, una export NFS, può essere una lun iSCSI oppure una lun Fibre Channel, insomma cambiano i protocolli che utilizzi per rendere accessibile quel determinato device di storage ma la sostanza resta sempre la stessa.

[antoniox]

non capisco che senso abbia fare questa obiezione.
Credo sia da leggere nel senso che: se avviene la corruzione del FS di un server, i servizi si bloccano fino a quando il server non viene ripristinato. Se questo accade al FS di uno dei nodi del cluster, i servizi non si arrestano.
E' corretto?

la quasi totalità degli approcci di fault tolerance che esulano dall'ambito applicativo generano sempre e comunque dei down

e

nel caso di architetture di fault tolerance gestite dal sistema operativo l'approccio è di tipo differente, con un nodo attivo e uno passivo, e dove in caso di down le risorse (lun, storage di rete, alias di rete o altro) vengono montate e attivate sul nodo passivo e i servizi vengono avviati.
Ottime osservazioni.


lo storage condiviso ti serve solo se il software che vuoi mettere in HA non può replicare i dati tra un nodo e l'altro del cluster
OK. Chiaro.

Grazie per il tuo intervento.