Finalmente e con colpevole ritardo Microsoft ha rilasciato il Management Pack per il Failover Cluster di Windows Server 2008 colmando una grave deficienza nella lineup di MP di System Center Operation Manager 2007.

Avendo scelto di avere diversi cluster con questa tecnologia non posso che correre ad installarlo.

Questo il link:

http://www.microsoft.com/downloads/details.aspx?FamilyId=AC7F42F5-33E9-453D-A923-171C8E1E8E55&displaylang=en&displaylang=en

In dominii che hanno un livello di funzionalità Windows Server 2003 Microsoft ha deciso di inserire una modalità di Trust di tipo Selective (Selettiva) avente come obbiettivo quello di filtrare in maniera estreamemente fine gli utenti che si possono autenticare sul dominio Trusting.

Questa funzionalità è molto utile in quelle situazioni in cui il dominio di risorse (per usare un termine noto a chi viene da Windows NT 3.51 Advanced Server ) è un dominio di produzione in cui è meglio tenere alla larga gli utenti.

Ovviamente quest’ultima affermazione è in palese contrasto con la indispensabile riduzione di utenze e di dominii al fine di contenere il più possibile i costi di gestione.

La selective trust è una funzionalità che consente di scegliere esplicitamente, attraverso le funzioni di security avanzate in Active Directory quali utenti o gruppi del dominio Trusted hanno “Allow to authenticate” sul singolo server.

La cosa si complica un pochino quando il server su cui permettere l’accesso al security principal è un cluster Windows Server 2008.

Nell’ultima, robustissima, versione di Windows Server la casa di Redmond ha introdotto numerose modifiche sulla funzionalità Cluster di Failover astraendo tutta l’impostazione delle risorse in modo che sia possibile creare ruoli come File Server piuttosto che un Resource Group con dentro le risorse necessarie per fare file share.

Creando un File Server su un cluster di failover di Windows Server 2008 questo ha la buona educazione di registrarsi nei Computer in Active Directory il che implica il permesso di Allow to authenticate per le identità che si vuole autorizzare all’accesso sia sui server fisici (i nodi del cluster) che sul File Server virtuale.

Un piccolo prezzo da pagare rispetto alla comodità della Selective Trust sia per la gestione che per la sicurezza delle vostre risorse.

In passato avevo già risolto il non-problema di configurare e far funzionare corrrettamente l’NLB quando i server Windows sono su VMWare Virtual Infrastructure 3 semplicemente seguendo la guida di VMWare a riguardo.

Quando la VLAN è sempre la stessa e lo switch utilizzato è solo uno (magari grosso come il nostro core Cisco 65xx) la procedura è abbastanza semplice:

• Configurare l’NLB in Multicast e con IGMP attivo
• Stati ARP sul router dell’indirizzo fisico dell’NLB (MAC Address)
• Attivare l’IGMP sulla VLAN

Fatto questo gli host convergono e bilanciano che è una meraviglia.

Diverso il discorso se, per ragioni di porte disponibili, siete costretti ad aggiungere un ulteriore switch in trunk utilizzando un VTP.

Qui la faccenda si complica un pochettino visto che nella pagina 17 del manuale delle giovani marmotte del networking c’è scritto che su un router in trunk vanno attivati alcuni spoofing per evitare che le porte lascino passare troppo rumore.

Quello che accade è che se una delle macchine dell’NLB è attaccata a quella porta (o, per meglio dire, è virtualmente in un virtual switch in una virtual lan ) vedrà le altre macchine in converging e lei nel cluster mentre le altre due vedranno loro stesse in convergenza e la terza (quella nello switch) in converging.

La colpa è dell’IGMP Spoofing che impedisce il propagarsi dei pacchetti di multicast e dei rispettivi indirizzi ARP e RARP. Dunque è indispensabile permettere la piena comuncazione a Layer 2 tra i serve in NLB disabilitando alcuni sistemi di “protezione” dei router/switch.

Non appena applicata questa correzione i tre server hanno preso a sincronizzarsi senza più alcun problema.

Sto seguendo con un certo interesse la discussione avviata da Giorgio Malusardi in un suo post, riprendendo la discussione avviata da Mike DiPetrillo di Vmware.

Altri interventi illustri sono di Massimo Re Ferré di IBM (con cui ho avuto il piacere di collaborare nel primo progetto di Infrastruttura di produzione internet della mia azienda) che riprende ed amplia il discorso parlando di una nascente  IT 2.0.

Oggi Giorgio riprende la discussione segnalando un post nel Virtualization Team Blog di Microsoft.

Già ieri stavo valutando un mio intervento nella discussione per apportare quella che, nel mondo della erogazione di servizi su Internet, credo sia una esperienza valida.

Nell 2004/5 abbiamo iniziato ad introdurre la tecnologia di virtualizzazione (dopo averla a lungo usata sui desktop per test e sviluppo) anche in produzione per erogare servizi su Internet.

Principalmente la soluzione di VMware è stata primariamente utilizzata per virtualizzare, con il P2V vecchi server che comunque avevano ancora applicazioni valide da erogare per abbassare i costi di manutenzione di hardware vecchio.

Nel corso del 2006, alla disponibilità di VI3 con HA e DRS, abbiamo usato la soluzione di virtualizzazione anche per la progettazione di una nuova infrastruttura su 2 siti geografici.

Ad oggi, dopo 2 anni di go-live, possiamo già trarre alcuni insegnamenti che mi piacerebbe introdurre nella un pò troppo accademica discussione sulle tecnologie (non comparabili, in realtà) di QuickMigration e vMotion.

La QuickMigration altro non è che il failover cluster di Windows Server 2008 applicato ai servizi di virtualizzazione di Hyper-V. Il vMotion con HA e DRS è la possibilità di spostare una macchina, senza alcuna interruzione nell’erogazione dei servizi, in caso di manutenzione programmata o di ribalanciamento del carico  sugli host.

La precisazione appena fatta è importante per capire la reale portata e contesto di utilizzo di queste tecnologie. In caso di crash dell’hardware (host), del crash della macchina virtuale (guest) HA non fa altro che far ripartire rebootando il server virtuale su un nuovo host esattamente come QuickMigration.

Questo provoca comunque un disservizio la cui durata è proporzionale alla configurazione (leggasi software al suo interno e configurazione dei dischi).

Nel caso degli SQL Server o di Oracle (lo so sto bestemmiando…) la cosa si complica ulteriormente dovendo effettuare del recovery sul DB.

Dalla mia esperienza dunque nessuna delle soluzioni, in caso di malfunzionamento, assicura la continuità del servizio ed anzi i tempi di ripristino possono anche essere enormemente più lunghi di quelli di una coppia di server fisici in cluster di failover in considerazione dell’enorme carico che si finisce per mettere sugli host.

Dunque il nuovo paradigma per l’IT al momento è ancora largamento incompleto ed inefficiente nella parte più complessa e che, paradossalmente, meno dovrebbe accorgersi della virtualizzazione: il management e lo sviluppo.

Nella mia personale esperienza la gestione delle macchine virtualizzate aumenta in maniera considerevole la complessità della farm nel suo insieme dovendo tenere conto di nuove e, a volte, poco evidenti variabili legate alle nuove funzionalità della piattaforma di virtualizzazione.

Per quanto riguarda il software diventa ancora più critica diventa la fase di progettazione e implementazione delle policy di recovery delle applicazioni che non può dare per scontata la disponibilità di servizi e il loro recovery da failure in tempi ristretti.

Aggiungiamo che diventa ancora più critica la policy di recovery visto che, come fa giustamente notare il blog del Virtualization Team di Microsoft, la perdita di un host virtuale è un vero disastro.

Infine esiste un fenomeno degenerativo che accelera le problematiche appena esposte: fare macchine virtuali è troppo facile, troppo più facile che fare applicazioni performanti e quindi, ironia delle sorte rispetto alla consolidation, si moltiplicano in maniera esponenziale i server.

Dunque la virtualizzazione va “corretta” con un approccio pragmatico su alcuni ruoli che, a mio giudizio, vanno tenuti fisici (grossi database cluster in primis), con l’aumento di utilizzo convinto di sistemi di gestione vm-aware, l’adozione coscenziosa e costante di metodologie di progettazione e realizzazione di software assolutamente collaudate (ITIL, ad esempio)

Nessuna delle tecnologie di migrazione potrà mai risolvere il problema alla base del successo (o del fallimento) delle infrastrutture tecnologiche.