none
Implementazione Cluster Windows 2008 R2 con 2 Nodi in modalita Nod & File Majority RRS feed

  • Domanda

  • Ho due server identici con le seguenti caratteristiche ciascuno

    - Dual Xeon E5645 Six Core (24 core virtuali a server) con 48GB di RAM

    - 2 dischi SAS-II 15K da 300GB in RAID 1 per il sistema operativo su controller PCI-Express Adaptech E6504E

    - 4 dischi SAS-II 15K da 600Gb in RAID 10 da utilizzare per il cluster dove inserire le macchine virtuali da gestire (7 in tutto) su controller Integrato LSI 2008 Falcon della Supermicro X8DA6

    - 2 dischi SATA-III SSD da 128GB in RAID 1 per i database di una macchina virtuale per avere maggiore velocità su controller Integrato LSI 2008 Falcon della Supermicro X8DA6

    - 2 LAN intel GBE una per la connessione Host e una per le comunicazioni del Cluster

    - 1 Quad Port BGE Intel 340TX4 per le macchine virtuali

    Il problema è il seguente, ho fatto l'installazione di Windows 2008 R2 aggiornato all'ultima patch, Driver WHQL aggiornati, installato il solo servizio Hyper-V e installo la funzione Cluster, eseguo la diagnosi del cluster.

    Questa mi da errore per tutte le voci di archiviazione in quanto non trova dischi condivisi gestiti dal cluster.

    Nell'ultima voce, sempre inerente al controllo di archiviazione, mi riporta che i dischi SAS in RAID 10 e SSD sono enable per la funzione cluster e il controller SAS Falcon 2008 viene riconosciuto.

    Tuttavia non so come proseguire per far si che i dischi siano gestiti dal cluster, suppongo in sincronia, per far si che le macchine virtuali siano protette dal fault in alta affidabilità.

    Ho letto che una delle novità principali di Windows 2008R2 era appunto la gestione senza il costoso disco di quorum e che bastava anche un controller SAS per gestire i dischi e avrei così eliminato il problema del fault del Quorum.

    Con l'impostazione Node & File Majority "avrei" potuto mettere i dati nei dischi di ciascun server gestito dal cluster e il cluster stesso si sarebbe occupato della sincronia tra i dischi dei vari nodi. Cosa che si può fare con Windows 2008 e un software di sincronia HP piuttosto che di altri produttori come ho visto fare in internet.

    Spero di non aver preso un abbaglio, dalle immagini schematiche delle modalità cluster e dalle relative informazioni avevo capito che si poteva.

    Qualcuno mi sa aiutare? In tutti i siti che ho trovato le spiegazioni si fermano sempre a come configurare la cartella di Majority e non da delucidazioni sulla gestione dischi purtroppo.

    lunedì 27 febbraio 2012 16:01

Risposte



  • Ciao LW,

    mi associo a Gianfranco (e mi permetto di aggiungere qualche dettaglio).

    Uno dei requisiti fondamentali per il cluster, da Windows 2003 in poi, è un disco shared, cioè visto da tutti i nodi. I dati della risorsa clusterizzata (il file dei DBS SQL, i DB di Exchange, i VHD delle Macchine virtuali) devono stare sul disco shared, in tal modo entrambi i nodi possono accedere ai dati della risorsa (es: il vhd della Macchina virtuale), che sono sul disco shared, e riescono a prendere il controllo della risorsa. Con questa architettura, se una risorsa Macchina Virtuale è attiva su nodo 1 e il nodo 1 fallisce, è possibile fare failover della risorsa Macchina Virtuale su nodo 2, perché anche nodo 2 accede al disco shared e vede gli stessi dati (il VHD) della risorsa.

    Come dischi shared sono supportati dischi (LUN) esposti da SAN (sia con connessione Fiber Channel che iSCSI), ma anche dischi SAS, anche in questo ultimo caso i dischi devono essere condivisi: vari vendor cominciano a fornire SAN con connessione SAS: lo storage ha una un controller con attacco esterno tramite cui i server si collegano allo storage (ovviamente anche i server devono montare un controller disco con attacco esterno, tramite cui si collegano allo storage); quindi non si usano né connessione Fiber Channel né iSCSI, ma SAS con connettore esterno.

    Il Cluster è lui stesso una risorsa e quindi i dati relativi devono essere salvati in un disco condiviso: il disco di Quorum. Anche in questo caso, entrambi i nodi devono poter accedere al disco di Quorum, in modo da prendere il controllo del Cluster in caso di fault dell’altro nodo. Il quorum viene usato anche per l’arbitrato, ma quella è un’altra storia.

    L’introduzione del File Share Majority serve per avere un cluster anche nel caso in cui  i nodi non abbiano dischi condivisi, tipico nel caso di geo-cluster, cioè due (o più) nodi che si trovano in due siti geograficamente separati. Ma in questo caso se vogliamo avere delle risorse clusterizzate (SQL, Exch, Macchine virtuali) è necessario che ci sia un meccanismo di replica tra gli storage dei due nodi, è il discorso di prima: entrambi i nodi devono avere accesso agli stessi dati. In questo caso non si ottiene con i 2 nodi che accedono allo stesso disco, ma con i 2 nodi che hanno ognuno il proprio disco e il SW di replica dello storage che tiene sincronizzati i due dischi. Risultato: i due nodi vedono gli stessi dati. Di solito questo meccanismo è fornito dal vendor dello storage.

    Non è mai esistito un Software, integrato nel sistema operativo, che sincronizzasse di dischi locali di un server permettendo di creare un cluster usando dischi locali.

    Solo gli storage di fascia alta forniscono funzionalità (tramite software specifici e proprietari) di sincronizzazione degli storage. Queste funzionalità permettono di implementare, tra le altre cose, i geo-cluster. Supponiamo di avere 2 nodi in due siti geograficamente distinti: in ciascun sito c’è uno storage (SAN, connesso sia via Fiber Channel che via iSCSI) e ciascun nodo accede al proprio storage locale. Il vendor dello storage fornisce un Sw che permette di tenere replicati (replica sincrona o asincrona) i due storage (la licenza per questi SW è molto costosa, mi è capitato un progetto dove si parlava di 20.000€ e, ripeto, solo per la licenza del Sw di replica! Poi c’era il costo degli storage, ecc. ecc.). Quindi in questo caso un nodo ha il controllo della risorsa (ad es. una macchina virtuale) e quando viene fatta una modifica sul VHD della macchina virtuale, la modifica viene replicata dal SW di replica sullo storage (e quindi sul VHD) dell’altro sito. Ma, ripeto, queste sono funzionalità fornite dallo storage (di fascia alta, quindi molto costosi) e, per le repliche sincrone, richiedono connessioni, tra i due storage, con latenza molto bassa (ottenibili solo con Fiber Channel).

    In questo caso i due nodi non hanno dischi shared (è il Sw di replica del vendor dello storage che fa si che entrambi i nodi vedano lo stesso disco, tenendo sincronizzati i due storage), quindi non si può usare un disco condiviso per il disco di Quorum, e si usa una modalità File Share Majority. Quindi mi dispiace ma non è assolutamente possibile fare un cluster senza dischi shared usando solo le funzionalità fornite dal Sistema Operativo.

    Visti i server che hai acquistato (tiro a indovinare 5-10 k a server?) l’acquisto di uno storage di fascia bassa con funzionalità iSCSI non avrebbe inciso troppo sul costo finale. Interessanti anche le soluzioni con storage connesso via SAS, hanno latenza e prestazioni paragonabili a Fiber Channel (arrivano a 6 Gb) senza averne i costi.

    Forse puoi recuperare la situazione verificando quanto costa uno storage che ti permetta di riutilizzare i dischi che hai montato sui server (forse anche uno dei controller?).

    Ciao
    Fabrizio


    lunedì 5 marzo 2012 12:30
  • Ciao Lonewolf,

    per definizione un failover cluster necessita di uno storage condiviso accessibile da tutti i nodi del cluster, altirmenti il failover stesso risulta impossibile. Lo storage locale dei server non e' utilizzabile a questo scopo, perlomeno con gli strumenti nativi 2008, di conseguenza e' corretto che il tool di validazione del cluster dia errore.

    Non c'e' bisogno di cercare tanto tra la documentazione, basta questo:

    http://technet.microsoft.com/en-us/library/cc732181(v=ws.10).aspx

    "Storage: You must use shared storage that is compatible with Windows Server 2008 R2".  Notare la parola "shared".

    Per cui o acquisti uno storage condiviso da dedicare ai due server via SAS, iSCSI o FC, oppure provi soluzioni commerciali di terze parti che "virtualizzano" un NAS utilizzando lo storage locale dei server, come per esempio questo:

    http://hyperv.starwindsoftware.com/


    Saluti, Gianfranco Bartolini

    domenica 4 marzo 2012 23:08
  • ciao,

    il disegno che hai indicato serve SOLO ed ESCLUSIVAMENTE  a descrivere il funzionamento dei servizi di cluster. Cioè permette di implementare i servizi di cluster SENZA disco condiviso (Quorum).

    Ma per le risorse, cioè le VM, è necessario un disco condiviso dove mettere, nel nostro esempio, i vhd delle VM.

    Windows NON è in grado di mirrorare i dischi tra server diversi. Nell'immagine che citi tu l'unica cosa che fa è salvare i dati di configurazione del cluster su una share (il file share majority) invece di salvare su un disco condiviso (Disco di Quorum).

    ciao

    Fabrizio

    venerdì 9 marzo 2012 14:30

Tutte le risposte

  • Ciao LoneWolf,

    Non sono sicura se la tua richiesta fosse ancora di attualità, intanto vorrei chiederti, per il caso fortunato in cui riesci a trovare la soluzione, di condividerla con la community, in modo che possa essere trovata e utilizzata dagli altri membri che riscontranno scenari simili.

    Se questa problematica è urgente per il tuo lavoro, per analisi approfondite puoi anche valutare di aprire un incident preso il supporto di Microsoft (ritieni che questo tipo di assistenza potrebbe essere a pagamento).

    Grazie,


    Anca Popa Follow ForumTechNetIt on Twitter

    La Conferenza Italiana sulla Virtualizzazione

    Microsoft offre questo servizio gratuitamente, per aiutare gli utenti e aumentare il database dei prodotti e delle tecnologie. Il contenuto viene fornito “così come è” e non comporta alcuna responsabilità da parte dell'azienda. 

    venerdì 2 marzo 2012 08:08
  • La richiesta è ancora attuale, molto attuale.

    Sto consultando tutta la docuemntazione che riesco a reperire su internet e fare vari tentativi. Purtroppo il passaggio che a me serve non viene mai spiegato o fatto a grandi linee.

    Se non trovo soluzione a breve sarò costretto ad aprire un incident e sperare che la configurazione che voglio sia fattibile che è la cosa che mi interessa e stando ai documenti reperiti sembrerebbe di si.

    Aspetto con fiducia di avere qualche delucidazione utile almeno per capire se quello che intendo fare è fattibile (ovvero utilizzare dei volumi di ciascun server per la funzione di Cluester con macchine virtuali Hyper-v in alta affidabilità).

    venerdì 2 marzo 2012 10:04
  • Semplifico la richiesta...

    A me basterebbe sapere se con il solo software Windows 2008 R2 in modalità cluster per hyper-V ad alta affidabilità, con due server uguali come nodi, posso usare come dischi dati i dischi interni SAS messi in replica tra loro al posto di un costoso NAS iSCSI.

    I dischi mi vengono segnalati come idonei dal tools di certificazione del cluster ma non non utilizzabili perchè mi riporta non visibili da entrambi i nodi o appartenenti ad un altro cluster.

    Nella modalità Cluster "node and file majority" non esistono dischi di quorum e ogni nodo ha i suoi dischi mi pare di capire.

    Trovo diverse immagini che rappresentano la mia situazione, dove ogni nodo ha il suo disco dati e vengono descritti come in sincronia tra i vari server.

    Con il Windows 2008 mi è stato detto che serviva un software di terze parti per mantenere la sincronia tra i dischi (dischi contenenti nel mio caso le macchine Hyper-V). Mentre Windows 2008 R2, da quello che avevo appreso da internet, riesce a farlo da solo.

    Tuttavia la verifica del cluster mi dice che i dischi non sono visibili da entrambi i nodi ma che se sto usando un software di sincrornia allora va bene e di contattare i produttore del software.

    Mi sono sbagliato? Devo per forza acquistare questo software di sincronia? e se si che software mi consigliate? 

    venerdì 2 marzo 2012 17:33
  • ciao Lonewolf,

    a me risulta che non si possa fare quello che vuoi tu senza software di terze parti (che non conosco), ma usare uno storage condiviso, anche perchè in hyper-V deve essere usata la tecnologia CSV.

    Magari poi qualcuno con più esperienza di me mi potrebbe smentire. 

    Un' altra cosa: verifica che i tuoi dischi ssd supportano il raid 1, perchè di solito ci sono problemi.


    Alberto Lissoni MCSA, MCTS, MCITP Server

    sabato 3 marzo 2012 09:26
  • Ciao Lonewolf,

    per definizione un failover cluster necessita di uno storage condiviso accessibile da tutti i nodi del cluster, altirmenti il failover stesso risulta impossibile. Lo storage locale dei server non e' utilizzabile a questo scopo, perlomeno con gli strumenti nativi 2008, di conseguenza e' corretto che il tool di validazione del cluster dia errore.

    Non c'e' bisogno di cercare tanto tra la documentazione, basta questo:

    http://technet.microsoft.com/en-us/library/cc732181(v=ws.10).aspx

    "Storage: You must use shared storage that is compatible with Windows Server 2008 R2".  Notare la parola "shared".

    Per cui o acquisti uno storage condiviso da dedicare ai due server via SAS, iSCSI o FC, oppure provi soluzioni commerciali di terze parti che "virtualizzano" un NAS utilizzando lo storage locale dei server, come per esempio questo:

    http://hyperv.starwindsoftware.com/


    Saluti, Gianfranco Bartolini

    domenica 4 marzo 2012 23:08


  • Ciao LW,

    mi associo a Gianfranco (e mi permetto di aggiungere qualche dettaglio).

    Uno dei requisiti fondamentali per il cluster, da Windows 2003 in poi, è un disco shared, cioè visto da tutti i nodi. I dati della risorsa clusterizzata (il file dei DBS SQL, i DB di Exchange, i VHD delle Macchine virtuali) devono stare sul disco shared, in tal modo entrambi i nodi possono accedere ai dati della risorsa (es: il vhd della Macchina virtuale), che sono sul disco shared, e riescono a prendere il controllo della risorsa. Con questa architettura, se una risorsa Macchina Virtuale è attiva su nodo 1 e il nodo 1 fallisce, è possibile fare failover della risorsa Macchina Virtuale su nodo 2, perché anche nodo 2 accede al disco shared e vede gli stessi dati (il VHD) della risorsa.

    Come dischi shared sono supportati dischi (LUN) esposti da SAN (sia con connessione Fiber Channel che iSCSI), ma anche dischi SAS, anche in questo ultimo caso i dischi devono essere condivisi: vari vendor cominciano a fornire SAN con connessione SAS: lo storage ha una un controller con attacco esterno tramite cui i server si collegano allo storage (ovviamente anche i server devono montare un controller disco con attacco esterno, tramite cui si collegano allo storage); quindi non si usano né connessione Fiber Channel né iSCSI, ma SAS con connettore esterno.

    Il Cluster è lui stesso una risorsa e quindi i dati relativi devono essere salvati in un disco condiviso: il disco di Quorum. Anche in questo caso, entrambi i nodi devono poter accedere al disco di Quorum, in modo da prendere il controllo del Cluster in caso di fault dell’altro nodo. Il quorum viene usato anche per l’arbitrato, ma quella è un’altra storia.

    L’introduzione del File Share Majority serve per avere un cluster anche nel caso in cui  i nodi non abbiano dischi condivisi, tipico nel caso di geo-cluster, cioè due (o più) nodi che si trovano in due siti geograficamente separati. Ma in questo caso se vogliamo avere delle risorse clusterizzate (SQL, Exch, Macchine virtuali) è necessario che ci sia un meccanismo di replica tra gli storage dei due nodi, è il discorso di prima: entrambi i nodi devono avere accesso agli stessi dati. In questo caso non si ottiene con i 2 nodi che accedono allo stesso disco, ma con i 2 nodi che hanno ognuno il proprio disco e il SW di replica dello storage che tiene sincronizzati i due dischi. Risultato: i due nodi vedono gli stessi dati. Di solito questo meccanismo è fornito dal vendor dello storage.

    Non è mai esistito un Software, integrato nel sistema operativo, che sincronizzasse di dischi locali di un server permettendo di creare un cluster usando dischi locali.

    Solo gli storage di fascia alta forniscono funzionalità (tramite software specifici e proprietari) di sincronizzazione degli storage. Queste funzionalità permettono di implementare, tra le altre cose, i geo-cluster. Supponiamo di avere 2 nodi in due siti geograficamente distinti: in ciascun sito c’è uno storage (SAN, connesso sia via Fiber Channel che via iSCSI) e ciascun nodo accede al proprio storage locale. Il vendor dello storage fornisce un Sw che permette di tenere replicati (replica sincrona o asincrona) i due storage (la licenza per questi SW è molto costosa, mi è capitato un progetto dove si parlava di 20.000€ e, ripeto, solo per la licenza del Sw di replica! Poi c’era il costo degli storage, ecc. ecc.). Quindi in questo caso un nodo ha il controllo della risorsa (ad es. una macchina virtuale) e quando viene fatta una modifica sul VHD della macchina virtuale, la modifica viene replicata dal SW di replica sullo storage (e quindi sul VHD) dell’altro sito. Ma, ripeto, queste sono funzionalità fornite dallo storage (di fascia alta, quindi molto costosi) e, per le repliche sincrone, richiedono connessioni, tra i due storage, con latenza molto bassa (ottenibili solo con Fiber Channel).

    In questo caso i due nodi non hanno dischi shared (è il Sw di replica del vendor dello storage che fa si che entrambi i nodi vedano lo stesso disco, tenendo sincronizzati i due storage), quindi non si può usare un disco condiviso per il disco di Quorum, e si usa una modalità File Share Majority. Quindi mi dispiace ma non è assolutamente possibile fare un cluster senza dischi shared usando solo le funzionalità fornite dal Sistema Operativo.

    Visti i server che hai acquistato (tiro a indovinare 5-10 k a server?) l’acquisto di uno storage di fascia bassa con funzionalità iSCSI non avrebbe inciso troppo sul costo finale. Interessanti anche le soluzioni con storage connesso via SAS, hanno latenza e prestazioni paragonabili a Fiber Channel (arrivano a 6 Gb) senza averne i costi.

    Forse puoi recuperare la situazione verificando quanto costa uno storage che ti permetta di riutilizzare i dischi che hai montato sui server (forse anche uno dei controller?).

    Ciao
    Fabrizio


    lunedì 5 marzo 2012 12:30
  • Non è mai esistito un Software, integrato nel sistema operativo, che sincronizzasse di dischi locali di un server permettendo di creare un cluster usando dischi locali.

    Ciao Fabrizio

    il sw che ho indicato a LoneWolf fa proprio questo. Soluzioni del genere per VMware esistono da diversi anni, per Hyper-V stanno via via venendo fuori.

    Per il resto ottima spiegazione pienamente condivisa, con un investimento in hardware del genere e' piu' che naturale prevedere anche uno storage condiviso.


    Gianfranco Bartolini

    lunedì 5 marzo 2012 12:53
  • Ringrazzio tutti per le risposte che mi avete fornito, davvero molto gentili.

    Purtroppo il titolare non vuole se possibile il NAS per paura di rotture e d blocco conseguente delle attività della ditta.

    Per il costo dei server siamo partiti da server pre esistenti a cui è stato fatto un generoso upgrade di RAM / processori / dischi.

    Ora proverò a valutare il costo e le funzionalità dei software di sincronia come starwind che mi è stato consigliato o altri.

    Se avete conoscenze su software del genere o consigli da darmi vi ringrazzierei molto.

    P.S. in fututo il progetto prevederebbe di installare un terzo / quarto membro del cluster in altri due stabilimenti per cui forse la soluzione software potrebbe essee più facile da gestire (banda occupata a parte)

    Con il software ottengo sempre un fault toolerance per avere le macchine Hyper-V sempre attive in caso di guasto server host?

    Di nuovo grazie mille per l'aiuto che mi state dando

    lunedì 5 marzo 2012 14:49


  • Ciao a tutti.

    si, come dice correttamente Gianfranco, esistono dei Sw che si occupano di sincronizzare i dati tra due storage, anche a costo basso.

    Unico dettaglio su cui vorrei porre la vostra attenzione è l’integrità dei dati e il verso della replica. Se tali Sw garantiscono l’integrità dei dati all’interno della VM, e il verso della replica, hanno anche il mio voto J

    Prendiamo ad esempio i tuoi due server: NODO 1 e NODO2. Una VM attiva su nodo 1 (e quindi con il vhd salvato sui dischi di nodo 1), deve essere replicata dal Sw di replica anche sul nodo 2 (e quindi il VHD deve essere replicato anche sui dischi di nodo 2). Hai due criticità da risolvere:

    • Il verso della replica. Se la VM è attiva su nodo 1 la replica viaggia da nodo 1 a nodo 2 (cioè le modifiche che fai al VHD su nodo 1 vengono replicate sullo stesso vhd su nodo 2), ma se la VM (è una risorsa clusterizzata) fa failover su nodo 2? Il verso della replica va invertito PRIMA che la VM sia attiva su nodo 2. Se no tu hai la VM attiva su nodo 2, ma il vhd viene replicato da nodo 1 a nodo 2 = un disastro. Quindi il SW di replica deve fornirti anche un meccanismo di gestione del verso della replica (con alcuni storage viene installato un servizio su entrambi i nodi,
      con altri si usa uno script per gestire il verso di replica) che deve essere installato come risorsa clusterizzata e TUTTE le risorse devono avere come dipendenza questo meccanismo (SW? Script?) di gestione del verso di replica, chiamiamolo per semplicità “Risorsa Verso di Replica”. Ovvero, quando la risorsa Macchina virtuale fa failover da nodo 1 a nodo 2, non va online se non è già andato online la risorsa “Risorsa Verso di Replica” (che ha invertito il verso di replica dello storage da nodo 1ànodo2 a nodo2 ànodo1).
    • L’integrità dei dati delle risorse in Macchina virtuale. Supponi di avere exchange o un DB. Exchange e SQL, a livello applicativo, gestiscono la modifica di un dato nel DB, e la sua conseguente scrittura su disco, come un attività atomica che ha successo o fallisce (è il concetto di transazione) e ne viene fatto il rollback. Esempio semplice (e molto impreciso). Un applicativo fa una modifica nel DB:
      • Parte la transazione: scrittura di 1 dato nel DB.
      • Scrivo i dati da scrivere in un file temporaneo
      • aggiorno un indice in un file di log
      • Scrivo i file di log su disco
      • parte la modifica dei file del DB su disco
      • dopo che la scrittura è avvenuta con successo, aggiorno nuovamente l’indice nel file di log e dichiaro committed la transazione.
      • Se tra la scrittura del dato e la dichiarazione che la transazione è committed avviene qualche problema (fault di disco, mancanza di corrente) la transazione fallisce integralmente, viene fatto un roll back: tramite il file di log io so quale è stata l’ultima transazione committed e riporto il database all’ultimo stato in cui i dati erano integri.
      • Quindi il Db è sempre in uno stato integro.
    • Tutto questo è gestito da SQL (o Exchange o Active Directory) a livello applicativo, quindi è l’applicativo che gestisce commit o eventuale rollback
      • Torniamo ai nostri due nodi. Tu fai una modifica in un db in una Macchina Virtuale in nodo 1, quella modifica (con tutta la gestione della transazione di cui sopra) viene scritta sul VHD della VM su nodo 1, e poi il SW di replica deve replicare le modifiche su nodo 2. Questo
        funziona, e garantisce l’integrità del DB solo se la replica tra i due storage è sincrona. Cioè se quando faccio una scrittura su disco di nodo 1, il software di replica, PRIMA di dichiarare (al sistema operativo) che la scrittura ha avuto successo, replica la scrittura ANCHE su nodo 2. Solo a quel punto dichiara la scrittura avvenuta con successo (e la transazione si chiude felicemente come committed). Se la replica è asincrona ? ovvero se il SW fa scrivere su nodo 1, dichiara la scrittura avvenuta con successo e POI con tutta calma replica la scrittura su nodo 2 ?? cosa può succedere? anche qui semplifico molto:
        • Se una transazione inizia, le prime modifiche su disco vengono replicate dal SW di replica degli storage e poi c’è un crash di
          nodo 1, esiste il serio rischio che su nodo 2 ci sia una versione del DB non integra perché sono stati replicati i settori su disco del file del DB, ma SQL è andato in crash e non ha potuta fare l’eventuale rollback delle transazioni non committed. Non si può avere la certezza che il DB riparta correttamente su nodo 2, facendo eventuale rollback delle transazioni rimaste. Ripeto non è un problema del delay tra le due repliche (1 sec? 10 sec? Non è importante), ma del fatto che potrebbe bastare quel minimo delay per corrompere l’integrità del DB; supponi ad esempio che il crash interrompa la replica in corso: cosa è stato replicato su nodo 2 ? che dati nei transaction log? In che stato ? il problema è che non lo sappiamo e non abbiamo la certezza che quello che c’è su nodo 2 sia integro.

    Quindi è necessario usare SW che garantiscano replica sincrona (e che, generalmente, richiedono latenza molto bassa, ottenibile solo con connessione Fiber Channel). Se invece si vuole usare replica asincrona, ci vogliono software che, prima di replicare il VHD, mandano un segnale di quiesce all’applicazione (cioè dicono all’applicazione di fare il commit di tutte le transazioni e di mettersi in uno stato che garantisca l’integrità dei dati. Ad es: Windows Backup, tramite VSS  lo fa, prima di fare un backup a caldo, per essere certo di salvare qualcosa (DB? Exchange? VHD) di cui sia garantita l’integrità dei dati).

    Soluzioni alternative?

    - A costo zero puoi usare uno script Powershell per stoppare tutte le VM e esportarle verso nodo 2 hai garantita l’integrità dei dati a costo zero.

    - A livello applicativo installi i due nodi come due entità separate e gestisci la Business continuity a livello applicativo. Ad Esempio: installi una VM con SQL su nodo 1 e una VM con un altro SQL su nodo 2, mettendo in mirror i DB.

    Come discorso generale, tu stai cercando di implementare un cluster a due nodi e vorresti anche implementare una soluzione di Business Continuity (o un geo-cluster) verso altri 2 stabilimenti. Tutto questo a costo quasi zero.

    Come ti dicevo ci sono soluzioni SAN che costano meno di 5 K, per salire a soluzioni di replica (sincrona) degli storage tra due siti che costano da 20 k in su. Tutto il mondo compra queste soluzioni e non soluzioni a basso costo perché sono quelle che garantiscono il risultato.

    Intendiamoci, non sto assolutamente parlando delle soluzioni proposte da Gianfranco, perché non le conosco nello specifico. Sto facendo un discorso generale: verifica le funzionalità che ti servono per ottenere quello che vuoi. Spesso per risparmiare 3 k si acquistano soluzioni che poi non danno le funzionalità desiderato, vedi il discorso dello storage esterno.

    La vera domanda (più per il tuo titolare) è: quanti soldi ci rimetto se il server (e tutte le VM e quindi i servizi) stanno spente 1 giorno? Quanto mi costa ricostruire tutto se prende fuoco la sala server? Da lì si costruisce il budget per l’alta affidabilità e quello per l’eventuale Business Continuity.

    Ha ragione il tuo titolare a dire che gli storage si rompono e si rischia di perdere tutti i dati, ma quanto costa tutto questo? Se ho un backup su nastro e li ricostruisco (altra domanda, quanto ci vuole a ripristinare tutti i dati da nastro?) e dopo 2 gg ho tutto di nuovo funzionante, sono stato fermo 2 gg: quanti soldi ci ho rimesso? Da qui capisci se ha senso investire in qualche forma di replica dello storage.

    Ciao

    Fabrizio



    martedì 6 marzo 2012 07:48
  • Ciao Fabrizio,

    solo a titolo di precisazione, i software a cui mi riferisco non sono strumenti di replica bensì di virtualizzazione dello storage. Si prendono in carico lo storage locale di due server, tramite connessione di rete dedicata effettuano un "network mirror" ed il risultato lo espongono agli host come se fosse un unico storage. Il failover di uno storage è gestito dal sw di virtualizzazione ed è trasparente all'host soprastante.

    Dato che mi sembri pratico di storage per farti capire meglio è esattamente quello che fanno le soluzioni HP Lefthand oppure IBM San Volume Controller (SVC).

    Per il resto pienamente d'accordo con te su tutta la linea, quando si tratta di replica distribuita e geo-cluster occorre andarci con i piedi di piombo e non improvvisarsi esperti pena il rischio di disastri pericolosi. Inoltre pensare di farsi in casa soluzioni del genere a basso costo vuol dire cercarsi sicuramente i guai.


    Gianfranco Bartolini

    giovedì 8 marzo 2012 23:09
  • Ciao Lonewolf,

    il tuo titolare avrebbe ragione se ci si riferisse a NAS desktop da qualche centinaio di euro, soluzioni ben poco affidabili, ancor meno ridondate e tantomeno prestazionali che per questo tipo di progetti non vanno assolutamente prese in considerazione.

    Diverso è il discorso degli storage condivisi nati appositamente per questo scopo che sono completamente ridondati in tutte le loro componentistiche, come per es. le soluzioni IBM DS3500, HP MSA P2000, Dell MD3000, ecc.

    Questi sono storage (dal costo di qualche migliaio di euro) che sono frequentemente utilizzati nelle aziende che implementano soluzioni cluster (di virtualizzazione e non) e che necessitano di affidabilità, ridondaza e prestazioni. Sono questi i prodotti adatti al tuo scopo.

    I sw che ti ho indicato sono un'alternativa a minor costo degli storage suindicati, anche se con minori prestazioni. Va quindi valutato se possono fare al caso tuo. Un'altro prodotto del genere è questo: http://www.stormagic.com/SvSAN.php

    Per il discorso del cluster su più siti, come ti ha gia ampiamente e dettagliatamente spiegato Fabrizio occorre valutare bene la situazione prima di procedere. In particolare la distanza tra i siti, la banda e la latenza disponibili perchè questo determina il tipo di replica che è possibile utilizzare e di conseguenza la soluzione da adottare.

    In linea di massima se si riesce a stare entro i 100mt per soluzioni Ethernet o 300mt per soluzioni FC in modo da garantire uno o più collegamenti Gigabit non ci dovrebbero essere problemi. Se le distanze sono maggiori le cose si complicano e le soluzioni indicate non sono più valide.

    Però come ti dicevo occorre un'analisi approfondita di tutti gli aspetti per poter arrivare ad un progetto che stia in piedi, quindi ti consiglio di farti aiutare da un partner con competenze nel settore.


    Gianfranco Bartolini


    giovedì 8 marzo 2012 23:27
  • Sto ancora attendendo di avere dei costi dello StarWind iSCSI, per ora so che DataKeeper viene 1900 dollari a nodo per 1TB mentre HP offre lo stesso servizio a 8.000 euro di listino (4800,00 in offerta).

    Stando ai vari produttori software la loro soluzione è addirittura più prestante pensate un po ... 

    Ho dato anche un'occhiata ai SAN indicati da Gianfranco e il più appetibile sembra l'HP in offerta con 2 controller in fibra e 4 dischi da 300GB SAS

    Sono ancora un po confuso dai siti dove spiegano le modalità di cluster e vi sono le immagini della modialita Node & File Majority tiupo questa

    Dalla descrizione che non serve un disco di quorum immaginavo che Windows riuscisse a creare una sorta di mirror dei dischi dei nodi (c'è anche il tratto di connessione tra i server). Inoltre Windows stesso mi indicava le due copie di RAID come enable per l'uso del cluster, riconoscendo quindi dei dischi SAS interni al server.

    Una delle peculiarità di questa configurazione è proprio la possibilità di creare un cluster senza costosi SAN ed'è la configurazione ideale con 2 nodi e quella che Windows stesso propone nell'impostazione del cluster.

    venerdì 9 marzo 2012 11:04
  • Ciao

    perche non proponi al tuo capo una soluzione sempre a basso costo ma con un apparato di tipo HW e in futuro la migrazione a soluzioni piu solide?

    Ti faccio un esempio perche mi sono trovato nella tua stessa situazione e alla fine ho dovuto fare la scelta su due soluzioni,premetto che non voglio fare pubblicità a nessuno.

    Uno storage dell NX 300 che dispone di un s.o. WS2008R2 Storage edition che comunque ha un bel controller h700i oppure un Synology tipo rs810 ma ce ne sono anche tanti altri.

    Certo è logico non hai una architettura con i contro cluster :) pero' potrebbe essere un buon punto di inizio per poi passare a soluzioni con doppio controller che hanno prezzi decisamente più elevati.

    Nel mio caso ho optato per la prima soluzione anche se non garantita dal vendor per soluzioni in iSCSI ma avevo le mani legate da un contratto oltre a non avere un euro da spendere :)

    Ciao

    Luca

    venerdì 9 marzo 2012 11:39
  • Ciao Gianfranco,

    il LeftHand !!! non avevo capito a cosa ti riferivi, sorry :-)

    allora hai ufficialmente il mio voto !!!

    scherzi a parte, ma i SW di cui parli funzionano anche per i dischi locali di un server? pensavo che fossero SW proprietari dei vendor e servisero solo per storage di fascia alta (es, se ricordo bene, HP per LeftHand richiede latenza < 1msec, cioè fibra)

    ciao

    Fabrizio

    venerdì 9 marzo 2012 14:24
  • ciao,

    il disegno che hai indicato serve SOLO ed ESCLUSIVAMENTE  a descrivere il funzionamento dei servizi di cluster. Cioè permette di implementare i servizi di cluster SENZA disco condiviso (Quorum).

    Ma per le risorse, cioè le VM, è necessario un disco condiviso dove mettere, nel nostro esempio, i vhd delle VM.

    Windows NON è in grado di mirrorare i dischi tra server diversi. Nell'immagine che citi tu l'unica cosa che fa è salvare i dati di configurazione del cluster su una share (il file share majority) invece di salvare su un disco condiviso (Disco di Quorum).

    ciao

    Fabrizio

    venerdì 9 marzo 2012 14:30
  • Ciao Fabrizio,

    questi sw lavorano esclusivamente con i dischi locali dei server.

    Anche i produttori di storage come HP e IBM hanno implementato le loro soluzioni proprietarie ma il principio del "network mirror" è il medesimo.

    Dato che questi sw (ed anche HP Lefthand) lavorano in iSCSI va da sè che non si usi la fibra bensì un buon collegamento ethernet gigabit o meglio ancora 10GBe, con latenza non superiore a 2msec come specificato anche nella documentazione ufficiale HP:

    http://h10032.www1.hp.com/ctg/Manual/c01750150.pdf


    Gianfranco Bartolini


    venerdì 9 marzo 2012 22:57
  • Uno storage HP è sicuramente una soluzione ottima, chiaramente costa di più di una soluzione sw che sfrutta lo storage locale dei server. Nel tuo caso valuta anche il modello con controller SAS invece che Fibra, potresti risparmiare sensibilmente senza penalizzare in maniera sensibile le prestazioni.

    Personalmente avendo nel tuo caso già investito in una buona dose di storage locali, una valutata ai sw che ti ho indicato la farei comunque.

    Per lo schema indicato ti ha gia' risposto più che correttamente Fabrizio, manca proprio il volume condiviso in cui sono presenti i dati. Il file share serve solo per ospitare il disco di Quorum necessario al cluster.


    Gianfranco Bartolini


    venerdì 9 marzo 2012 23:05
  • Uno storage dell NX 300 che dispone di un s.o. WS2008R2 Storage edition che comunque ha un bel controller h700i oppure un Synology tipo rs810 ma ce ne sono anche tanti altri.

    Certo è logico non hai una architettura con i contro cluster :) pero' potrebbe essere un buon punto di inizio per poi passare a soluzioni con doppio controller che hanno prezzi decisamente più elevati.

    Ciao Luca,

    il problema è proprio questo, gli storage che hai proposto nascono e muoiono a singolo controller (= spof) e non sono upgradabili. A questo punto tanto vale una soluzione HP/IBM/Dell singolo controller con possibilità di espansione futura a doppio controller, perlomeno preservi l'investimento iniziale.


    Gianfranco Bartolini

    venerdì 9 marzo 2012 23:11
  • Molte grazie a tutti per il supporto.

    Sono alle prese ora con lo starwind software iSCSI in versione demo e sono riuscito a configurare come volevo il cluster. 

    Le prestazioni non so se sono ottimali in quanto per ora ho installato VM con servizi semplici, la macchina VM che gestisce il DB2 devo ancora installarla perchè deve essere fatta dal tecnico del gestionale.

    Ho comunque aperto un'altra rischiesta di assistenza per conoscere meglio il funzionamento del cluster con live migration che qualche problemino mi sta dando.

    Ringrazio di nuovo tutti per la gentile collaborazione e le spiegazioni esaustive.

    giovedì 22 marzo 2012 14:35
  • Grazie a te per il feedback.

    Ho spostato il nuovo thread in Prodotti e tecnologie per la virtualizzazione che mi sembrava il forum più indicato.


    Fabrizio Volpe
    MVP Directory Services
    MCSE (NT4)(2000)(2003) - MCSA (2003)
    MCTS (SQL 2005)(Exchange 2007)(Windows 2008)
    VMware Certified Professional on vSphere 4
    Fortinet Certified Network Security Professional (FCNSP)
    Fabrizio[_dot_]Volpe[_at_]GMX[_dot_]com

    giovedì 22 marzo 2012 14:47