Ivan Salvade’

Il mio punto di vista su Virtualizzazione, Sicurezza, Messaggistica, Network Management…

  • Ivan

    248418_467427256623661_1655875885_n.jpg
  • Abbonati

  •  

    settembre 2017
    L M M G V S D
    « gen    
     123
    45678910
    11121314151617
    18192021222324
    252627282930  
  • Tag Cloud

Implementare Lync Server 2010 : Parte 5

Scritto da Ivan Salvade' il 29 settembre 2011

In questa quinta parte dell’articolo vedremo come installare definitivamente il Front-End Server di Lync, rispettando la topologia creata e pubblicata con il Topology Builder (vedi le parti 3 e 4 dell’articolo).

Ecco i link alle precedenti parti pubblicate :

—————————————————————————————————————————————————————————————————————————————————

L’installazione del Front-End Server si effettua utilizzando il “Lync Server Deployment Wizard”.   Vengono eseguiti 4 passaggi fondamentali :

  1. Installazione del Local Configuration Store
  2. Installazione dei ruoli previsti
  3. Configurazione dei certificati
  4. Start dei servizi

Si comincia con il lancio del Wizard dalla pagina di Setup (Fig. 1) :

1.JPG Fig. 1

Lanciamo il primo step, che installa il Local Configuration Store (Fig. 2) :

21.JPG  Fig. 2

Sono opportune alcune delucidazioni sullo step 1.  Cos’è il “Local Configuration Store”?

Lync Server 2010 prevede che tutti i dati sulla topologia, sulle policy e sulla configurazione siano memorizzati in quello che si chiama “Central Management Store” (CMS).  Il CMS è un database SQL di lettura/scrittura che, in un topologia Lync di tipo Enterprise, viene creato su un server standalone (il Back-End Server) già dotato di un’installazione SQL, mentre in una installazione Lync di tipo Standard viene creato in un’istanza di SQL Express installata sul server stesso.

Il CMS viene poi replicato localmente su tutti i server aggiuntivi che verranno inseriti nella topologia Lync prescelta.

Nel CMS, l’istanza SQL creata si chiama “RTC”, mentre in tutte le repliche locali verranno create istanze di nome “RTCLocal”.

Quando utilizziamo un Lync Server Standard Edition, sussiste la casistica in cui il server ospita sia il CMS che una replica locale (infatti troveremo una doppia istanza di SQL Express, “rtc” e “rtclocal”).   Lo step 1 del wizard installa l’istanza “rtclocal”, creandola come replica dell’istanza “rtc”.   Sebbene su una Standard Edition può sembrare assurdo l’utilizzo di due istanze praticamente identiche, questo è molto importante negli ambienti più grandi, in quanto aggiunge ridondanza e consistenza dei dati in tutta l’organizzazione, in caso di problemi al CMS.

La creazione del CMS è già stata eseguita precedentemente, durante la preparazione della Standard Edition (vedi la parte 3 dell’articolo).

Proseguendo col wizard, ecco che ci viene chiesto come creare il Local Configuration Store (Figg. 3 e 4).  Si ottiene come replica del CMS :

3.JPG  Fig. 3

41.JPG  Fig. 4

Ora si esegue il secondo step che installa i componenti secondo la topologia prescelta (Figg. 5 e 6) :

51.JPG  Fig. 5

6.JPG  Fig. 6

Se precedentemente non fosse stato installato IIS con tutti i componenti necessari, comparirebbe l’errore di Fig. 7.  Per comodità, l’errore riporta con precisione quali componenti di IIS è necessario installare :

7-errore-componenti-iis-mancanti.JPG  Fig. 7 (clicca per ingrandire)

Un altro prerequisito è Microsoft Visual J# 2.0 : viene installato in automatico se mancante (Fig. 8 ) :

8.JPG   Fig. 8

Lo step 2 si completa (Fig. 9 ) :

9.JPG   Fig. 9

Ora si esegue lo step 3 che prevede la configurazione dei certificati (Fig. 10).   Ogni Front-End Server richiede 3 certificati : un “Default Certificate”, un certificato web interno, un certificato web esterno.   I certificati possono essere ottenuti da una Certification Authority di tipo Enterprise installata nella propria rete (come mostrerò tra poco), oppure, in alternativa, possono essere acquistati da una Certification Authority pubblica esterna.  Utilizzando i certificati di tipo SAN (Subject Alternative Names), è possibile riunire in un unico certificato tutti i nomi FQDN richiesti dal wizard.  Lo step 3 può essere utilizzato per richiedere, installare, assegnare, rinnovare i certificati.

a.JPG Fig. 10

In Fig. 11, dopo aver verificato di selezionare tutti i tre tipi di certificato, cliccare “Request” e proseguire (Fig. 12) :

b.JPG Fig. 11

c.JPG  Fig. 12

Se la Certification Authority è interna, si può spedire ad essa direttamente la richiesta dei certificati (Fig. 13) :

d.JPG  Fig. 13

Nel mio esempio la CA è installata su un Domain Controller (Fig. 14) :

e.JPG  Fig. 14

Se siete già loggati come Domain Admins, non servono altre credenziali (Fig. 15) :

f.JPG  Fig. 15

Il template di certificato deve essere “Web Server”.  Va bene quello di dafault.  Se ne può eventualmente utilizzare uno personalizzato, che deve essere configurato ed attivato nella console di gestione della Certification Authority (Fig. 16) :

g.JPG  Fig. 16

Inserire un nome per il certificato.  E’ un nome puramente informativo (Fig. 17) :

h.JPG  Fig. 17

La richiesta di un certificato obbliga sempre ad inserire alcune informazioni di riconoscimento (Figg. 18 e 19) :

i.JPG  Fig. 18

j.JPG  Fig. 19

Tutti i nomi necessari da configurare nel certificato sono automaticamente popolati dal wizard (Fig. 20).  Il certificato sarà di tipo SAN (Subject Alternative names) :

k.JPG  Fig. 20

In Fig. 21 è consigliato selezionare il proprio SIP Domain, soprattutto per sfruttare la caratteristica del sign-in automatico dei client :

l.JPG  Fig. 21

Di norma, non servono ulteriori nomi alternativi (Fig. 22) :

m.JPG  Fig. 22

Ecco il riassunto della richiesta in Fig. 23 e l’esecuzione dei comandi in Fig. 24 :

n.JPG  Fig. 23

o.JPG  Fig. 24

Il certificato è stato rilasciato dalla CA.  Ora procediamo ad assegnare il certificato ai corretti servizi (Figg. 25,26,27,28) :

p.JPG  Fig. 25

q.JPG  Fig. 26

r.JPG  Fig. 27

s.JPG  Fig. 28

L’esito finale è riportato in Fig. 29 :

t.JPG  Fig. 29

Si può procedere all’avvio dei servizi (Figg. 30,31,32) :

u.JPG Fig. 30

v.JPG  Fig. 31

w.JPG  Fig. 32

L’installazione è completa.  Possiamo tentare il lancio della console centrale di gestione di Lync (il “Lync Server Control Panel”) dal menù programmi (Fig. 33) :

lancio-finale-del-control-panel-di-lync.JPG   Fig. 33

Se non è stato precedentemente installato Microsoft Silverlight 4, si ottiene l’errore di Fig. 34.   Eventualmente procedere all’installazione di Silverlight, e ritentare :

silverlight-non-installato-e-sito-non-in-local-intranet.JPG    Fig. 34   (clicca per ingrandire)

Bisogna anche ricordarsi di inserire lo URL che richiama il Control Panel (https://admin.nomedominio) nei siti appartenenti alla zona “Local Intranet” del browser.

Dopo queste operazioni, dovrebbe apparire regolarmente l’interfaccia del Control Panel (Fig. 35) :

control-panel-finale.JPG      Fig. 35   (clicca per ingrandire)

Nella Parte 6 dell’articolo vedremo come registrare opportunamente alcuni record nel DNS interno, allo scopo di permettere la corretta localizzazione dei servizi ai client.

  • Share/Bookmark

Pubblicato in Lync Server 2010 | Nessun commento »

Cluster Shared Volumes (CSV) : parte 8

Scritto da Ivan Salvade' il 26 giugno 2011

In questa ottava parte dell’articolo su CSV, dimostrerò step-by-step come rendere altamente disponibile, in un cluster CSV,   una macchina virtuale dotata di dischi Pass-Through.   Ecco i link alle precedenti parti dell’articolo :

Come già spiegato nella Parte 3 di questo articolo, nella sezione “Utilizzo dei Pass-Through Disk con CSV”, è possibile eseguire una Live Migration di una macchina virtuale dotata di dischi Pass-Through, a patto di configurarla correttamente nell’ambiente di Cluster CSV.   La configurazione deve prevedere :

  1. l’inserimento nello spazio CSV del vhd contenente il sistema operativo della macchina virtuale
  2. l’inserimento, come “dipendenza” della macchina virtuale”, di uno o più dischi pass-through in dotazione alla macchina virtuale, che verranno utilizzati tipicamente per la parte dati

Vediamo in questo articolo le procedure step-by-step per questo tipo di implementazione.

In questa dimostrazione, parto dall’assunzione di aver già reso altamente disponibile una macchina virtuale, come illustrato nella Parte 7 di questo articolo.

Per prima cosa, vado a ricavare sull’iSCSI Target Software un LUN da dedicare come disco pass-through alla macchina virtuale. Nella figura, il LUN è il Virtual Disk 2 inserito in LUN-02 (Fig. 1) :

lun-da-dedicare-come-passthrough.jpg      Fig. 1

Non appena rendo visibile il nuovo LUN al Nodo 1 tramite l’iSCSI Initiator, eccolo comparire nella console Gestione Disco (Fig. 2) :

lun-visto-da-nodo1.jpg      Fig. 2

Eseguo il solito Online del disco (Fig. 3) …

online-lun.jpg      Fig. 3

…e la solita inizializzazione per rendere il disco riconoscibile dal sistema operativo e dai servizi di Clustering (Fig. 4) :

initialize-lun.jpg      Fig. 4

Ora riportare Offline il disco appena inizializzato : Hyper-V richiede che il disco sia Offline affinchè lo si possa agganciare come pass-through alla macchina virtuale; inoltre non serve formattarlo già ora, in quanto ci penserà il sistema operativo della macchina virtuale (Fig. 5) :

riportare-offline-il-lun-se-no-non-si-aggiunge-come-passthrough.jpg      Fig. 5

Il disco deve essere reso visibile tramite iSCSI Initiator anche al Nodo 2, altrimenti il Cluster restituisce il seguente errore (Fig. 6) :

se-lun-non-mappato-a-entrambi-i-nodi-cluster-non-lo-vede.jpg      Fig. 6

Dopo che il disco è stato reso visibile a entrambi i nodi, si procede a dichiarare il disco al Cluster, con l’azione “Add Disk” della console del Failover Cluster, sezione Storage (Fig. 7) :

aggiunta-disco-al-cluster-storage.jpg      Fig. 7

Ecco il riassunto dello storage ora disponibile : il Disk 1 in Quorum, il Disk 2 in CSV, il nuovo Disk 3 compare nello storage disponibile (Fig.8) :

riassunto-storage.jpg      Fig. 8

Come già detto, non è possibile assoggettare a CSV un disco che si pensa di utilizzare come pass-through in una macchina virtuale.  Il tentativo di eseguire questa operazione (Fig. 9) …

tentativo-di-mettere-in-csv-il-lun-passthrough.jpg      Fig. 9

… porta a degli errori, visibili in Fig. 10 e Fig. 11 :

esito-1.jpg      Fig. 10

esito2.jpg  

Fig. 11

Quali sono le motivazioni dell’errore di Fig. 11 ?   La tecnica CSV richiede che i dischi siano dotati di almeno una partizione formattata NTFS per poter ospitare i vhd delle macchine virtuali, e inoltre devono essere in stato Online, altrimenti CSV non riesce a leggere le informazioni di partizionamento dei dischi.   Nel nostro caso, però, dobbiamo tenere il disco Offline, perchè solo in questo stato è possibile inserirlo come pass-through in una macchina virtuale.   Questi due concetti antagonisti creano il suddetto errore.

Ora proviamo ad inserire il Disk 3 come pass-through disk della macchina virtuale, utilizzando la voce Settings nelle proprietà della macchina in console del Failover Cluster (Fig. 12) :

tentativo-di-assegnare-il-lun-passthrough-a-vm.jpg      Fig. 12

Essendo il disco Offline, lo si può vedere nella sezione “Physical Hard Disk” (Fig. 13) :

disco-9-messo-come-passthrough.jpg      Fig. 13

Ora, nella sezione “Disk Drives”, compare il “Cluster Disk 3″.   Eseguo anche un Refresh (essenziale!!) della configurazione della macchina virtuale (Fig. 14) :

refresh-della-vm.jpg      Fig. 14

Il primo refresh, però, comporta dei (giusti…) ”Warning” indicati in Fig. 15 , Fig. 16 e Fig. 17 :

refresh-e-warning-della-vm.jpg      Fig. 15

avviso-rosso.jpg

Fig. 16

avviso-giallo.jpg

               Fig. 17

La motivazione dei warning di Fig. 17 è la seguente : eseguendo il refresh della macchina virtuale nella console del cluster, il cluster si è accorto che il “Cluster Disk 3″ (quello identificato dal cluster come \\.\PhysicalDrive9) non è ancora sotto il suo controllo.  In effetti, come si nota in Fig. 8, quel disco è visibile solo nella sezione “Available Storage”;  non è mai stato dichiarato in uso da qualche risorsa del cluster.   Il refresh della macchina virtuale esegue proprio questa operazione.  Infatti, appena sotto i due warning gialli, si nota proprio la dichiarazione del disco al cluster : “Adding the new storage required by virtual machine ‘HA-Test to the cluster“.

Ora, rieseguendo un secondo refresh a scopo di controllo, si nota il differente esito (Fig. 18 e Fig. 19) :

rifatto-con-lun-in-possesso-del-cluster.jpg      Fig. 18

il-refresh-e-ora-corretto.jpg      Fig. 19

Ora il disco è completamente sotto il controllo del cluster, ed inoltre è dichiarato come dipendenza della macchina virtuale.  Qualunque operazione di migrazione della macchina virtuale si porterà dietro pure il pass-through disk (Fig. 20) :

lun-ora-in-dipendenza.jpg      Fig. 20

Nella precedente Fig. 20, notare come la macchina virtuale era in esecuzione su Nyc-Host1.  Ecco ora l’esecuzione di una nuova Live Migration della macchina virtuale HA-Test (Fig. 21) :

migrazione-in-corso.jpg      Fig. 21

Al completamento della Live Migration, si nota che l’owner è diventato NYC-Host2 (Fig. 22) :

migrazione-finita.jpg      Fig. 22

Eseguendo un Diskpart all’interno della macchina virtuale, si nota come il disco pass-through venga correttamente visto (Disk 1).  E’ addirittura in stato Offline : è possibile ora procedere a partizionarlo e formattarlo secondo le esigenze, utilizzando il sistema operativo della macchina virtuale (Fig. 23) :

lun-visto-da-dentro-vm.jpg      Fig. 23

Conclusione : la Live Migration di una macchina virtuale dotata di dischi Pass-Through funziona! Eccome se funziona!!  :-)

Buona implementazione a tutti!!  :-)

  • Share/Bookmark

Pubblicato in Clustering, Hyper-V, Virtualizzazione, Windows Server 2008 R2 | 1 Commento »

Cluster Shared Volumes (CSV) : parte 5

Scritto da Ivan Salvade' il 28 maggio 2011

In questa quinta parte dell’articolo su CSV, analizzerò il funzionamento del “Redirected Access” (aka “Redirected  I/O”, aka “Redirected Mode”) in un cluster CSV.   Ecco i link alle precedenti parti dell’articolo :

Il Redirected I/O in scenari di Fault-Tolerance

E’ una feature molto utile, ma anche pericolosa se non se ne conoscono i principi di funzionamento.   Utilizza la “Cluster Network” dedicata alle comunicazioni CSV.

Lo scopo primario del Redirected I/O è fornire ridondanza al percorso di accesso allo storage del cluster.

Come spiegato nella Parte 1 di questo articolo, ogni volume CSV ha il proprio Coordinator Node, che rappresenta l’owner del volume e gestisce direttamente (Direct I/O) le operazioni sui metadati dei files inerenti le macchine virtuali.   Se gli host non-coordinator avessero bisogno di eseguire pure essi tali operazioni, dovrebbero trasmetterle al Coordinator Node tramite la rete dedicata alle comunicazioni CSV, utilizzando il protocollo SMB2 (Redirected I/O).  Questo traffico è raro, e utilizza poca banda.

Tutti i nodi, invece, eseguono operazioni di lettura/scrittura nei VHD utilizzando il proprio collegamento allo storage (Direct I/O).

Dopo questo ripasso, nella figura che segue, si suppone la caduta del collegamento allo storage dell’Hyper-V Host 2.

redirected-mode-theory.jpg

A questo punto, si attiva automaticamente il Redirected Mode, che inoltra all’altro nodo (tramite la NIC CSV) il traffico diretto allo storage.  Questo “inoltro” viene effettuato tramite una connessione SMB2 tra i due nodi : tra l’altro, questo è il motivo per cui si obbliga a lasciare attivo “Client for Microsoft Networks” e “File and Print Sharing” sulle schede di rete dedicate al traffico CSV.  Quando si è in Redirected I/O sulle operazioni di lettura/scrittura  nei VHD, l’utilizzo di banda della NIC CSV è alto.

Per capire quale nodo ha perso la connessione allo storage CSV, è sufficiente ricercare l’evento 5121 tra gli eventi del cluster, nella console del Failover Cluster.

Questa è la parte utile del Redirected I/O : senza di esso, le macchine virtuali sull’Host 2 si fermerebbero in assenza del collegamento diretto allo storage.  In questo modo, invece, continuano a funzionare, seppur con minori performance.

Perché minori performance?  Naturalmente, far transitare le comunicazioni SCSI in una sessione SMB è notevolmente più lento che farle transitare su una connessione iSCSI dedicata o addirittura su una connessione Fibre Channel!

Bisogna anche dire che, se la connessione allo storage fosse ridondata da MPIO, non sussisterebbe il problema.  Ma MPIO non è la scelta di tutti, naturalmente…

N.B : il Redirected I/O può anche essere attivato manualmente nella console del cluster, come illustrato nella seguente figura :

turn-on-redirected-mode.jpg

Ecco il warning che compare se si esegue l’attivazione del Redirected Access :

warning-redirected-mode.jpg

Nella prima delle due figure, si nota come sia disponibile anche una seconda opzione assieme al Redirected Access : l’opzione è “Turn On maintenance for this Cluster Shared Volume”.    E’ interessante capire le differenze tra le due azioni.

  • Redirected Access : in questo stato, CSV è disponibile a tutti i nodi nello spazio C:\ClusterStorage, ma tutti i nodi (tranne il Coordinator Node) eseguono le proprie operazioni di I/O tramite il Coordinator Node.  Queste operazioni sono trasportate via SMB2
  • Maintenance Mode : in questo stato, il servizio Cluster su ogni nodo cerca quali risorse (macchine virtuali) stanno utilizzando CSV, e le “spegne” utilizzando il loro metodo predefinito di spegnimento, che può essere un completo “Shut Down” o un “Save State” (configurabile in ogni macchina virtuale).  Quindi nessuno può più usare CSV, che è rimosso dallo spazio C:\ClusterStorage.  Il LUN sarà però ancora disponibile sul Coordinator Node, ed utilizzabile per eseguirci certe operazioni, per esempio un comando Chkdsk per controllare eventuali settori difettosi.  Quando si termina lo stato di Maintenance, bisogna riavviare manualmente tutte le macchine virtuali precedentemente arrestate.

Il Redirected I/O in altri scenari

In altri scenari, il Redirected Mode può essere “meno entusiasmante”.   Per esempio, in tutti quegli scenari in cui certe operazioni di gestione sul cluster o sull’Hyper-V richiedono accesso esclusivo al File System.

L’esempio più lampante è la necessità/volontà di eseguire un backup del volume CSV, utilizzando un software di backup che sappia eseguire una Volume Shadow Copy a livello host (per es. Data Protection Manager 2010).

Una tale operazione richiede l’accesso esclusivo (da parte del Coordinator Node) al CSV nello storage.   L’unico modo per garantirlo, è iniziare una sessione di Redirected I/O del volume CSV, costringendo tutti gli altri nodi a comunicare con lo storage attraverso la NIC CSV e il Coordinator Node.

Ricordando già da ora che Windows Server Backup non supporta i volumi CSV, rimando alla successiva sesta parte di questo articolo la trattazione del backup in ambiente di cluster CSV e non-CSV.

  • Share/Bookmark

Pubblicato in Clustering, Hyper-V, Virtualizzazione, Windows Server 2008 R2 | Nessun commento »

Cluster Shared Volumes (CSV) : parte 4

Scritto da Ivan Salvade' il 23 maggio 2011

In questa quarta parte dell’articolo su CSV, analizzerò la configurazione di rete necessaria per la migliore implementazione della tecnica CSV.  Ecco i link alle precedenti parti dell’articolo :

Terminologie

E’ importante non fare confusione tra diverse terminologie utilizzate quando si parla di configurazione di rete in ambiente Cluster / Hyper-V:

  • Schede di rete (Physical Network Adapters) : rappresentano l’hardware, cioè le schede di rete fisicamente inserite nei server che rappresentano i nodi del cluster
  • Reti del Cluster (Cluster Networks) : rappresentano le reti create durante la formazione del cluster, che collegano le schede di rete appartenenti ad una stessa sottorete, presenti sui nodi del cluster.   Per esempio, se durante la creazione del cluster venissero rilevate su 2 nodi le seguenti schede di rete :
    • Nodo 1 : scheda di rete con indirizzo IP 192.168.1.1/24
    • Nodo 2 : scheda di rete con indirizzo IP 192.168.1.2/24
    • … verrebbe creata una Cluster Network chiamata “Cluster Network 1″, con Network ID 192.168.1.0 e subnet mask 255.255.255.0, visualizzabile nella console del Cluster; questa Cluster Network verrebbe ritenuta LAN utile a far transitare su di essa traffico di rete relativo al cluster, collegando le schede di rete suddette

  • Reti Virtuali (Virtual Networks) : rappresentano le reti create sugli host Hyper-V (è molto comodo immaginarle come degli “switch di rete” veri e propri), utilizzate per collegare tra di loro in rete le macchine virtuali, gli host fisici e il resto della LAN aziendale

Le reti da utilizzare in un cluster CSV

Sicuramente vi è la necessità di dotare i nodi del cluster di più schede di rete. Si va da un minimo di 2-3 schede di rete per nodo in piccoli ambienti, ad un massimo di 7-8 schede di rete per nodo in grandi ambienti, dove è anche importante la ridondanza delle reti stesse.

N.B. : questa sezione non può essere esaustiva : la configurazione di rete, soprattutto in grossi ambienti di virtualizzazione, deve essere opportunamente progettata e testata a seconda delle necessità. Quelle che seguono sono solo generali linee guida.

Detto questo, quali sono le reti necessarie ? Ecco l’elenco completo :

  • GESTIONE : rete su cui si effettuano le operazioni di gestione del cluster, dell’Hyper-V e delle macchine virtuali, oltre ad ospitare il flusso di dati di un’eventuale backup via rete della Parent Partition e/o delle Child Partitions
  • PUBBLICA : rete su cui fluiscono i dati destinati alle macchine virtuali. Si deve affacciare alla rete di produzione e tipicamente possiede un gateway
  • iSCSI : rete dedicata alle comunicazioni iSCSI verso lo storage. Se si utilizza uno storage raggiungibile in fibra ottica, questa rete non è necessaria
  • PRIVATA : rete su cui fluiscono le comunicazioni interne del cluster (Hearthbeat) e anche le comunicazioni CSV (se CSV è implementato)
  • LIVE MIGRATION : rete su cui fluisce una Live Migration di Hyper-V·
  • CSV : rete dedicata alle comunicazioni CSV, se non si vuole utilizzare la PRIVATA a tale scopo

La seguente tabella può riassumere la massima dotazione di schede di rete necessaria (per nodo), a seconda del tipo di connessione allo storage, in un cluster Hyper-V configurato con CSV e su cui si vogliono eseguire le Live Migrations :

Gestione

Pubblica

iSCSI

Privata

Live Mig.

CSV

Totali

FC

1

1 / 2

/

1

1

1

5 / 6

iSCSI

1

1 / 2

2

1

1

1

7 / 8

Nelle colonne “Pubblica” e “iSCSI”, la seconda scheda di rete indica la possibilità/necessità di ridondare quel tipo di rete. Se si sceglie la ridondanza, è necesario implementare opportunamente una soluzione MPIO (Multipath I/O).

In un piccolo ambiente, è possibile ridurrre anche a 2/3 il numero di reti necessarie, sebbene in questo caso non si possano ottenere né le massime performance del cluster, né la ridondanza dei percorsi di rete. Bisognerebbe poi ricorrere all’implementazione di VLAN e/o QoS per isolare i vari tipi di traffico e garantire loro la necessaria banda. Esempi potrebbero essere questi :

  • Scheda di rete 1 : Gestione + Pubblica + Iscsi (comunque sconsigliata : iSCSI richiederebbe sempre una scheda di rete riservata!)
  • Scheda di rete 2 : Privata + Live Migration + CSV

Oppure

  • Scheda di rete 1 : Gestione + Pubblica
  • Scheda di rete 2 : Iscsi
  • Scheda di rete 3 : Privata + Live Migration + CSV

Tutte le suddette schede di rete dovrebbero essere almeno di tipo 1GbE. Le generali performance non possono altro che migliorare se abbiamo in dotazione le 10GbE : queste andrebbero implementate preferibilmente sulle reti iSCSI, CSV e Live Migration, soprattutto se utilizzate per più scopi.

Il Teaming delle schede di rete

Microsoft non supporta direttamente il NIC teaming per Hyper-V, in quanto non possiede drivers proprietari di tutte le marche di schede di rete esistenti al mondo. D’altro canto i drivers forniti dai produttori delle schede di rete spesso riportano il teaming come “opzione possibile”.

In definitiva, si può affermare che il teaming è utilizzabile anche in ambiente Hyper-V, ma a patto che il supporto in caso di problematiche venga dato dal fornitore del driver.

Ricordo anche che non è supportato il teaming delle schede di rete utilizzate per le comunicazioni iSCSI. Quindi non si può utilizzare una scheda di rete logica (cioè creata su due fisiche in teaming) quando si utilizza il “Microsoft iSCSI Software Initiator” per presentare i LUN ad una Parent Partition di Hyper-V.

Creazione delle Cluster Networks

Prima di procedere alla creazione di un cluster, è opportuno pianificare con precisione quante Cluster Networks si vogliono utilizzare, e di conseguenza quante schede di rete è necessario installare sui nodi.     A questo scopo, consultare la precedente sezione “Le reti da utilizzare in un cluster CSV”.

Una volta installate le schede di rete nei nodi (possibilmente tutte dello stesso costruttore e tutte con gli stessi parametri di configurazione), è opportuno assegnare loro un nome preciso per meglio riconoscerle (es. Rete Pubblica, Rete Privata, Rete iSCSI, ecc.), oltre alla configurazione IP prevista.

Per controllare se le schede di rete sono configurate correttamente, si utilizza il wizard “Validate a Configuration” dalla console del Failover Cluster.   Questo wizard esegue i seguenti test :

  • Inventario hardware e software dei nodi
  • Test della configurazione di rete
  • Test dello storage
  • Test della configurazione del sistema

E’ opportuno eseguire singolarmente e ripetutamente il test della configurazione di rete (molto veloce), finchè il report non presenta una valutazione positiva della configurazione di rete effettuata.   Il test esegue i seguenti controlli :

  • controlla l’ordine dei “Bindings” delle schede di rete sui nodi
  • presenta in anteprima le Cluster Networks che verrebbero create nel cluster, in base alle schede di rete fisiche installate nei nodi
  • controlla che, per una particolare Cluster Network, tutte le schede di rete abbiano l’indirizzo IP assegnato con la stessa modalità (o tutti statici, o tutti dinamici)
  • controlla che, per una particolare Cluster Network, tutte le schede di rete utilizzino la stessa versione di IP (o tutte IPV4, o tutte IPV6)
  • controlla che non ci siano schede di rete con indirizzi IP duplicati
  • controlla il numero di schede di rete presenti su ogni nodo : se ne viene trovata una sola, viene segnalato il “single point of failure” della Cluster Network mappata a quella scheda di rete
  • controlla che nessun nodo abbia multiple schede di rete sulla stessa subnet
  • controlla che i nodi possano comunicare su tutte le reti con una latenza accettabile
  • controlla che il Windows Firewall sia configurato correttamente su tutti i nodi

Le schede di rete vanno configurate sui nodi in maniera speculare.  Ecco un esempio nella seguente illustrazione :

cluster-network-diagram.jpg   (clicca per ingrandire)

Nella seguente figura, ecco le schede di rete opportunamente create e rinominate su un nodo del cluster :

elenco-connessioni-rete-consigliate-per-csv.jpg

Facendo trovare le schede di rete già perfettamente configurate al wizard di creazione del cluster, questo creerà le Cluster Networks in maniera pulita e consistente, associando alla stessa Cluster Network le schede di rete appartenenti alla stessa subnet.

Il cluster crea le Cluster Networks con una nomenclatura di default : “Cluster Network 1″, “Cluster Network 2″, ecc… .   E’ opportuno rinominarle in maniera appropriata appena si accede alla console del Failover Cluster.

L’ordine di creazione rispetta l’ordine di binding delle schede di rete dei nodi.  Quindi, come si vede nella figura, se l’ordine di binding prevede “Rete di Gestione” al primo posto e “Rete iSCSI” al secondo, le schede “Rete di Gestione” dei vari nodi saranno associate alla “Cluster Network 1″, mentre le schede “Rete iSCSI” dei vari nodi saranno associate alla “Cluster Network 2″, e via dicendo.

Se i bindings sui vari nodi non sono regolati in maniera identica, viene tenuto buono l’ordine di binding del “primo nodo”, dove con “primo nodo” si intende quello il cui nome DNS è primo in ordine alfabetico (non è tenuto in considerazione l’ordine degli indirizzi IP).

Ordine di binding delle schede di rete consigliato in un cluster CSV

E’ importante regolare l’ordine di binding dei server Hyper-V dotati di multiple schede di rete, soprattutto se sono inseriti in un cluster.  Supponendo di utilizzare una scheda di rete per ogni scopo, l’ordine di binding consigliato è il seguente :

  1. Rete dedicata alla gestione dell’Hyper-V
  2. Rete dedicata alle comunicazioni iSCSI
  3. Rete dedicata alla Live Migration
  4. Rete dedicata agli Heartbeat del cluster e alle comunicazioni CSV
  5. Rete pubblica (col gateway) su cui sono collegate le Virtual Networks degli host Hyper-V

In Windows Server 2008 R2, per regolare l’ordine di binding delle schede di rete, si utilizza lo strumento “Network and Sharing Center”, si entra in “Change Adapter Settings”, e si preme il tasto ALT : compare in alto una barra dei menù, dove si utilizza l’elenco “Advanced” per la regolazione :

come-accedere-ai-bindings.jpg

bindings.jpg

Dedicare una rete alle comunicazioni CSV

Come accennato in anteprima nella parte 2 di questo articolo, la raccomandazione principale in ambiente CSV è quella di dedicare una rete (”Cluster Network”) alle comunicazioni CSV.

Per default, il cluster sceglie in automatico la rete da utilizzare per le comunicazioni CSV.  La scelta è effettuata ricercando le schede di rete che appaiono essere “le migliori” (più veloci) tra quelle disponibili nei nodi.   E’ tuttavia possibile imporre al cluster una scelta obbligata, utilizzando due particolari parametri delle reti di un cluster : ”Metric e “Autometric“.

Al parametro “Metric” possono essere assegnati (manualmente da noi o in automatico dal cluster) valori numerici che indicano il “costo” di una certa rete : più il valore è basso, più quella rete è ritenuta veloce, e quindi idonea per le comunicazioni CSV.

Il parametro Autometric è booleano.  Può assumere i valori True (default) o False.  Quando è posto a True, il cluster regola in automatico il valore del parametro Metric delle reti.   Non appena imposto manualmente il parametro Metric, il parametro Autometric viene automaticamente modificato in False.

Quando il parametro Autometric è posto a True, il cluster assegna in automatico un valore 1000 o superiore per quelle  reti che non hanno un default gateway impostato (per esempio le reti private), mentre assegna un valore 10000 o superiore per le reti che sono dotate di default gateway (per esempio le reti pubbliche, usate per collegarsi al parco client o a Internet).

Ecco un esempio :

comandi-shell-get-su-5-reti-copy.jpg   (clicca sulla figura per ingrandire)

Per imporsi sulla rete da usare per le comunicazioni CSV, assegnare al parametro Metric della rete prescelta un valore inferiore a 1000, o comunque inferiore a qualunque altro parametro Metric impostato su altre reti.

Per eseguire questa operazione, si utilizza un comando di Powershell, disponibile dopo aver caricato il modulo di comandi per il Failover Cluster.   Il comando è : Get-ClusterNetwork.

Per caricare il modulo di comandi, aprire Powershell e digitare :

Import-Module FailoverClusters

Per visualizzare la situazione del momento, si può utilizzare la seguente sintassi :

Get-ClusterNetwork | Ft  Name, Address, Metric, Autometric, Role

Questo comando elenca le proprietà attuali delle reti presenti sul cluster (nome, indirizzo IP, valori assegnati ai parametri Metric e Autometric, ruolo).     La proprietà “Ruolo” può avere i seguenti valori :

  • 1 :  rete ad uso privato
  • 3 :  rete ad uso misto pubblico/privato
  • 0 :  rete ignorata dal cluster (non sono permesse le comunicazioni del cluster)

Per modificare il parametro Metric di una rete (es. per impostarlo a 100), usare la seguente sintassi :

(Get-ClusterNetwork “Cluster Network x“).metric = 100

Il ruolo delle reti viene scelto dal Cluster in base alle seguenti valutazioni :

  • Rete con il parametro Metric più basso : rete per CSV e comunicazioni interne del cluster
  • Rete con il secondo parametro Metric più basso : rete utilizzata per la Live Migration
  • Reti  con parametri Metric più alti : reti utilizzate per il traffico pubblico e di gestione

Ecco un esempio di settaggio statico del parametro Metric delle Cluster Network :

regolazione-statica-delle-metriche.jpg    (clicca sulla figura per ingrandire)

Nota : la rete utilizzata per la Live Migration può essere scelta anche dalla console grafica del Failover Cluster, nelle proprietà di una macchina virtuale clusterizzata, nel tab “Network for Live Migration”.    E’ possibile indicare anche più di una rete :  verranno utilizzate nell’ordine di preferenza indicato.   Il parametro è globale : una volta configurato per una macchina virtuale, si applica anche alle altre dello stesso cluster.

Nella quinta parte di questo articolo, analizzerò il funzionamento del Redirected Access in un cluster CSV.

  • Share/Bookmark

Pubblicato in Clustering, Hyper-V, Virtualizzazione, Windows Server 2008 R2 | Nessun commento »

Cluster Shared Volumes (CSV) : parte 3

Scritto da Ivan Salvade' il 17 maggio 2011

In questa terza parte dell’articolo su CSV, analizzerò più nel dettaglio il dimensionamento e il posizionamento dei LUN, dei volumi e dei files vhd in un ambiente di Cluster CSV.

Ecco i link alle precedenti parti dell’articolo :

Posizionamento e dimensionamento di LUN, volumi e VHD

Se ci trovassimo di fronte ad un semplice server fisico, su cui dovessimo disporre i dischi nella maniera migliore per garantire massime performance di accesso al sistema operativo e ai dati, la configurazione migliore sarebbe la seguente :

  • I file di sistema (compreso il file di paging) su un disco fisico
  • I dati su un altro disco fisico

Ulteriori migliorie della configurazione prevederebbero :

  • La creazione di un volume RAID 1 (su due dischi fisici) per i files di sistema
  • La creazione di un volume RAID 5 o RAID 1+0 o RAID 6 (su una moltitudine di dischi fisici) per i dati
  • L’eventuale separazione del file di paging dai files di sistema, ponendolo su un volume RAID 0 creato su una moltitudine di dischi fisici

Per un server virtuale clusterizzato, la disposizione dei dischi dovrebbe ricalcare il precedente modello, e cioè :

  • I files di sistema (incluso il file di paging) in un VHD posto su un volume assoggettato a CSV
  • I dati in un altro VHD posto su un altro volume assoggettato a CSV

L’aggiunta di successive macchine virtuali, dovrebbe sempre ricalcare lo stesso modello.  Dato che è possibile posizionare diverse macchine virtuali sullo stesso LUN (vedi “Architettura e principi di funzionamento” nella parte 1 dell’articolo), dovremmo sempre piazzare i VHD dei files di sistema sul volume a loro dedicato, e i VHD dei dati sull’altro volume a loro dedicato.  La seguente figura illustra la topologia appena discussa :

csv1.jpg

In generale, bisogna sempre cercare di riprodurre con i VHD la configurazione dei dischi che si utilizzerebbe se i server fossero fisici piuttosto che virtuali.   E’ importante valutare anche il carico di lavoro che le applicazioni all’interno delle macchine virtuali esercitano sui dischi (per es. Sql Server o Exchange Server generano tipicamente un elevato numero di operazioni I/O sui dischi).

Più è elevato il numero di operazioni di I/O, più bisogna orientarsi verso configurazioni RAID (sui dischi fisici dove sono creati i LUN assoggettati a CSV) che garantiscano massime performance oltre che ridondanza (RAID 1+0 e RAID 5 su un buon numero di dischi sono tipicamente le migliori configurazioni RAID.  Consultare anche le Best Practices del vendor del sistema di storage, a questo proposito).

Per le applicazioni basate su database, è molto frequente adottare la best practice di separare su LUN diversi i database e i files delle transazioni;  questo per un discorso di performance, ma anche di miglior recuperabilità in caso di disastro.   La stessa best practice andrebbe utilizzata se l’applicazione risiedesse in una macchina virtuale.   Quindi potremmo avere una disposizione dei VHD come segue :

  • Un VHD contenente file di sistema e file di paging, posto su un LUN assoggettato a CSV, creato a sua volta in modalità RAID 1 su due dischi fisici
  • Un VHD contenente il database applicativo, posto su un LUN separato assoggettato a CSV, creato a sua volta in modalità RAID 1+0 o RAID 5 su un certo numero di dischi fisici (più sono, più otteniamo performance)
  • Un VHD contenente i files di transazione dell’applicazione, posto su un LUN separato assoggettato a CSV, creato a sua volta in modalità RAID 1 su due dischi fisici

Se disponiamo di multiple macchine virtuali con requisiti simili, potremmo dedicare un LUN ad ospitare tutti i VHD dei file di sistema, un LUN ad ospitare tutti i VHD dei database, un LUN ad ospitare tutti i VHD dei files di transazione delle varie macchine virtuali.

Quanti LUN si devono creare per ospitare i VHD delle macchine virtuali?    Dipende ovviamente dal carico di lavoro sui dischi che esercitano le applicazioni all’interno delle macchine virtuali.   Se queste generano poco I/O, si possono piazzare anche più VHD di più macchine virtuali su uno stesso LUN assoggettato a CSV, altrimenti separare opportunamente i VHD su più LUN, e utilizzare soluzioni RAID sui dischi fisici che garantiscano il massimo delle performance.

Configurazione ottimale dei VHD

In Hyper-V è possibile utilizzare dischi VHD di tre tipi :

  1. Fixed
  2. Dynamically Expanding
  3. Differencing

E’ importante scegliere opportunamente il tipo di VHD, per non andare incontro a problemi di performance.   Tutti e tre questi tipi di VHD sono comunque supportati dalla tecnica CSV.

Fixed Disk

In fase di creazione viene richiesta una dimensione massima (127 GB di default, massino 2TB).  Il file VHD viene immediatamente creato con una dimensione pari a quella impostata.  Il contenuto viene poi man mano scritto nel VHD, ma questo non comporta l’espansione del file VHD, che rimane sempre della stessa grandezza.

Vantaggi : conosco in anticipo l’occupazione di spazio sui LUN fisici, non corro il rischio di avere in futuro un over-commit sui dischi, la frammentazione è ridotta, le performance sono ottimali e paragonabili a quelle dei dischi fisici.

Svantaggi : difficilmente trasportabile, soprattutto se molto grande

Dynamically Expanding Disk

In fase di creazione viene richiesta una dimensione massima (127 GB di default, massino 2TB).  Il file VHD viene però creato molto piccolo (pochi KB), e viene espanso man mano che si procede ad inserire dati.  L’espansione massima sarà pari alla dimensione massima indicata in fase di creazione.

Vantaggi : facilmente trasportabile, in quanto inizialmente la sua dimensione può essere molto contenuta

Svantaggi : frammentazione più accentuata, performance minori a causa dell’overhead di attività necessaria ad espandere continuamente il VHD e a causa della frammentazione stessa, minor controllo dell’occupazione di spazio su disco (devo continuamente controllare l’espansione per evitare l’esaurimento di spazio sul LUN fisico), alcune applicazioni possono non supportare i VHD di questo tipo (per esempio Microsoft non supporta Exchange 2007 o 2010 virtualizzati su VHD di tipo Dynamically Expanding)

I VHD di questo tipo sono consigliati in ambiente di test e sviluppo.  Con Hyper-V R2 SP1, le performance dei Dynamically Expanding Disk sono molto migliorate, e in alcuni casi sono simili a quelle dei Fixed Disk, ma per macchine virtuali con grossa attività di I/O sui dischi sono comunque consigliati i Fixed Disk.

Differencing Disk

Un Differencing Disk è un disco virtuale associato ad un altro disco virtuale in relazione Parent-Child.  Il Differencing Disk è il “Child”, mentre il disco virtuale associato è il “Parent”.  Il Parent Disk può essere qualunque tipo di VHD.  Il differencing disk memorizza un record di tutti i cambiamenti fatti al parent disk,  e dà la possibilità di salvare questi cambiamenti senza modificare il parent disk.   In ogni momento, è possibile “unire” il differencing disk con il parent disk, se necessario.

Il parent disk può essere reso di sola lettura, ed è agganciabile a diversi differencing disk, per poterlo utilizzare quindi da diverse macchine virtuali.  Questo è ottimo in ambiente di test e sviluppo.

Il differencing disk è sempre di tipo Dynamically Expanding, e non posso dichiararne una dimensione massima.  Inoltre non può essere compattato direttamente, ma solo dopo un’eventuale unione con il parent disk.

Essendo di tipo Dynamically Expanding, hanno i loro stessi vantaggi/svantaggi.  Sono consigliati in ambiente di test, ma non in produzione.

Utilizzo dei Pass-Through Disk con CSV

Oltre ai VHD, è possibile dedicare alle macchine virtuali un intero disco fisico/LUN, detto “Pass-Through Disk”.   Le macchine virtuali scriveranno i dati direttamente nei volumi fisici, senza eseguire l’incapsulamento nei VHD.   E’ possibile utilizzare come Pass-Through Disk i dischi fisici interni di un server, oppure dei LUN ottenuti su una SAN raggiungibile in fibra ottica o iSCSI.

Ecco alcune caratteristiche dei Pass-Through Disk :

  • Le richieste di lettura/scrittura sono spedite direttamente al volume fisico
  • Non sono soggetti al limite di 2 TB, che è invece la grandezza massima per i files VHD
  • Non supportano la creazione degli snapshot
  • Sono associabili ad una macchina virtuale solo se presenti in stato “Offline” sul server Hyper-V
  • Le performance sono ottime, spesso superiori a quelle dei VHD di tipo Fixed
  • La loro portabilità è problematica

Considerando vantaggi e svantaggi dei Pass-Through Disk, è da considerare il loro utilizzo se necessitiamo di massime performance e se vogliamo sfruttare volumi con grandezza superiore ai 2 Tb.

Ma in ambiente CSV, sono supportati i Pass-Through Disk?

Noto su alcuni forum una secca risposta “NO” a questo tipo di domanda.  In realtà non è propriamente così.   Ci sono alcune cose supportate e altre no, ma già da ora posso dire che una Live Migration di una macchina virtuale dotata di dischi Pass-Through in un ambiente di cluster CSV, è perfettamente possibile.  Bisogna solo adottare alcuni accorgimenti in fase di configurazione del cluster.

Ciò che veramente non è supportato, è aggiungere un disco Pass-Through nello spazio CSV del cluster : un Pass-Through è un LUN dedicato all’uso esclusivo di una macchina virtuale, mentre CSV significa condividere un volume NTFS a multiple macchine virtuali.  Sono quindi due concetti antagonisti, e il tentativo di aggiungere (nella console del cluster) un disco Pass-Through allo spazio CSV, genera veramente un errore.

Il trucco sta nel dichiarare il disco Pass-Through come semplice “dipendenza” della macchina virtuale clusterizzata, che avrà invece il VHD da cui esegue il boot caricato su un volume CSV.

In un prossimo articolo della serie, questo scenario verrà implementato e spiegato step-by-step.

In conclusione, è possibile utilizzare in un cluster CSV macchine virtuali dotate di dischi Pass-Through, a patto che la macchina virtuale esegua un boot da un VHD inserito nel volume CSV, mentre il disco Pass-Through verrà dichiarato come dipendenza della macchina virtuale, e conterrà tipicamente solo la parte Dati.   Di questa macchina virtuale così configurata, sarà possibile eseguire senza problemi una Live Migration o una Quick Migration.

Nella quarta parte di questo articolo, analizzerò la configurazione di rete necessaria per la migliore implementazione della tecnica CSV.

  • Share/Bookmark

Pubblicato in Clustering, Hyper-V, Virtualizzazione, Windows Server 2008 R2 | Nessun commento »

Cluster Shared Volumes (CSV) : parte 2

Scritto da Ivan Salvade' il 3 maggio 2011

Nella Parte 1 di questo articolo ho trattato dell’architettura generale di CSV e dei suoi principi di funzionamento.   Vediamo ora gli scopi precisi di utilizzo ed i requisiti necessari per l’implementazione della tecnica.

Scopi di utilizzo e benefici della tecnica CSV

Ripartiamo dalla constatazione che NON è strettamente obbligatorio configurare CSV quando si vuole implementare l’alta disponibilità delle macchine virtuali in Hyper-V, ma grazie ai suoi benefici, è altamente raccomandato utilizzarla.

Quali sono i vantaggi?

  1. Ridotto numero di LUN da creare.  Si può utilizzare CSV per ridurre il numero di LUN richiesti dalle macchine virtuali.  Quando si attiva e configura CSV, si possono memorizzare multiple macchine virtuali su un singolo LUN, e multipli “host server” possono accedere allo stesso LUN simultaneamente.
  2. Cluster Validation più veloce.  Utilizzando un minor numero di  LUN, il wizard che controlla la validità dello storage (”Cluster Validation Wizard” nella console del “Failover Cluster) viene eseguito più speditamente
  3. Miglior utilizzo di spazio su disco.  Invece di piazzare ogni singolo vhd su un disco separato con dello spazio libero in modo che il vhd possa espandersi, posso più facilmente occupare lo spazio libero su un LUN memorizzando su di lui multipli vhd (e se questi sono di tipo “Fixed”, posso già dall’inizio calcolare l’occupazione di spazio sul LUN).
  4. Nessun particolare requisito hardware necessario.  Si può implementare CSV su qualunque configurazione di dischi supportata, e su SAN a fibra ottica, iSCSI o SAS.
  5. Miglior recuperabilità.   CSV aumenta la recuperabilità in quanto il cluster può rispondere correttamente anche se la connettività tra un nodo e la SAN è interrotta, oppure una parte della rete è caduta.  Il cluster re-instrada il traffico CSV attraverso una parte intatta della SAN e/o della rete.   Le caratteristiche di ridondanza di CSV saranno oggetto di un futuro articolo di questa serie.
  6. La configurazione delle macchine virtuali in Cluster è molto più semplice di prima

Quindi l’utilizzo di CSV è altamente consigliato negli scenari in cui sono vere tutte le seguenti condizioni, o la maggior parte di esse :

  • presenza di numerose macchine virtuali, alla maggior parte delle quali bisogna garantire un’alta ridondanza
  • in caso di disastri, le macchine virtuali devono essere recuperate col minor downtime possibile
  • il trasferimento di macchine virtuali da un host all’altro (per es. per necessità di manutenzione di uno degli host) deve essere eseguito senza downtime delle macchine virtuali
  • l’ottimizzazione dei costi dello storage è importante

Requisiti per l’implementazione di CSV

I nodi del cluster devono avere i seguenti prerequisiti :

  • Tutti i nodi devono eseguire Windows Server 2008 R2 Enterprise o Datacenter Edition (Full o Server Core Installation), oppure Hyper-V Server 2008 R2.   E’ possibile combinare nello stesso cluster nodi che eseguono Hyper-V Server 2008 R2 con nodi che eseguono Windows Server 2008 R2 Enterprise o Datacenter Server Core Installation
  • La partizione di sistema su tutti i nodi deve avere la stessa lettera di drive (per es. C:)
  • I Ruoli Hyper-V e Failover Cluster devono essere installati su ogni nodo che esegue una supportata edizione di Windows Server 2008 R2
  • I processori di tutti i nodi devono supportare le tecniche Intel VT o AMD-V (attivabili nel BIOS)
  • Non utilizzare nei nodi processori di differente fornitori (es. Intel e AMD)
  • L’Hardware dei nodi dovrebbe essere il più simile possibile
  • Assicurarsi di dotare ogni nodo di adeguata RAM, in modo da supportare il failover delle macchine virtuali da altri nodi

Lo Storage deve avere i seguenti prerequisiti :

  • Lo storage su SAN deve essere compatibile con il Windows Server 2008 R2 Failover Cluster
  • I LUN creati sulla SAN devono essere raggiungibili da tutti i nodi, via Fibre Channel, SAS o iSCSI
  • Per assoggettare un LUN a CSV, questo deve essere visibile nella console del Cluster come “Physical Disk Resource” disponibile
  • Se una macchina virtuale è dotata di un “Pass-Through Disk”, questo non può essere assoggettato a CSV, ma ciò non significa che una Live Migration della macchina virtuale non possa essere eseguita.  Questo scenario verrà illustrato in un successivo articolo della serie
  • I dischi in CSV sono identificati con un nome di percorso.  Questi percorsi appaiono nella partizione di sistema dei nodi, nella cartella \ClusterStorage.  I percorsi non sono altro che dei “Junction Point” verso i LUN
  • I LUN possono essere creati col software di gestione del vendor della SAN, utilizzando configurazioni RAID di qualunque tipo : RAID 0, RAID 1, RAID 1+0, RAID 5, RAID 6.  Consiglio la soluzione RAID 1+0 per le migliori performance nonchè ridondanza, anche se è accettabile anche un RAID 5 su un buon numero di dischi fisici

I prerequisiti di rete devono essere i seguenti :

  • Installare un numero sufficiente di Schede di Rete in ogni nodo, in modo che una rete sia disponibile per CSV e altre reti siano disponibili per altri scopi (es. operazioni di gestione, traffico pubblico, traffico privato del cluster, connessioni via iSCSI allo storage)
  • Per tutte le Schede di rete che trasportano comunicazioni del cluster, assicurarsi di attivare “Client for Microsoft Networks” e “File and Print Sharing for Microsoft Networks”, allo scopo di supportare SMB 2.0 (Server Message Block), che è richiesto da CSV.   Solo una scheda di rete sarà la “preferred network” per le comunicazioni CSV, ma abilitare SMB 2.0 su tutte le schede di rete, permette al cluster di rispondere meglio alle rotture
  • Tutti i nodi di un cluster con CSV attiva, devono risiedere sulla stessa sottorete logica.  Questo significa che, in caso di Cluster Multisito che usano CSV, bisogna utilizzare una VLAN
  • Ulteriori considerazioni sull’ambiente di rete CSV saranno illustrate nella parte 4 di questo articolo

Nella terza parte di questo articolo analizzerò più nel dettaglio il dimensionamento e il posizionamento dei LUN, dei volumi e dei files vhd in un ambiente di Cluster CSV.

  • Share/Bookmark

Pubblicato in Clustering, Hyper-V, Virtualizzazione, Windows Server 2008 R2 | Nessun commento »

Microsoft iSCSI Software Target è ora gratuito

Scritto da Ivan Salvade' il 5 aprile 2011

Dal 4 aprile 2011 Microsoft ha deciso di rendere pubblico e gratuito il “Microsoft iSCSI Software Target”.

Essenzialmente è un software che permette di trasformare un server Windows in un dispositivo di storage (una sorta di SAN) raggiungibile via rete tramite protocollo iSCSI.  Può essere utile per diversi scopi :

  • Fornire storage condiviso ai cluster (in particolare cluster Hyper-V su cui attivare Live e Quick Migration)
  • Consolidare lo storage su un unico server, utilizzabile da diverse applicazioni e diversi server della rete
  • Abilitare il boot remoto di computer senza disco, utilizzando un’immagine di un sistema operativo raggiungibile via iSCSI

Microsoft iSCSI Software Target era già disponibile per l’uso in produzione a partire dal 2007, ma era incluso solo in Windows Storage Server;  dal 2009 era diventato disponibile in download per tutti i sottoscrittori di abbonamenti Technet e MSDN, a scopo di test e sviluppo.

Ora “Microsoft iSCSI Software Target 3.3″ è scaricabile gratuitamente (da qui) ed è installabile sui seguenti sistemi operativi :

  • Windows Server 2008 R2 e Windows Server 2008 R2 SP1 Standard Edition (Full installation)
  • Windows Server 2008 R2 e Windows Server 2008 R2 SP1 Enterprise Edition (Full installation)
  • Windows Server 2008 R2 e Windows Server 2008 R2 SP1 Datacenter Edition (Full installation)

E’ essenzialmente la stessa release presente in Windows Storage Server 2008 R2, ed è fornito ovviamente solo in piattaforma a 64 bit.  Non è installabile su Windows Server 2008 o Windows Server 2003.

E’ interessante tenere presente le Support Policies di Microsoft per iSCSI Software Target 3.3, visualizzabili al seguente link :

http://technet.microsoft.com/en-us/library/gg983493(WS.10).aspx

L’annuncio ufficiale del rilascio lo trovate qui :

http://blogs.technet.com/b/josebda/archive/2011/04/04/microsoft-iscsi-software-target-3-3-for-windows-server-2008-r2-available-for-public-download.aspx

Buona giornata!  :-)

  • Share/Bookmark

Pubblicato in Clustering, Generale, Gestione dei Sistemi, Virtualizzazione, Windows Server 2008 R2 | Nessun commento »

 
Usiamo i cookie per assicurarti la migliore esperienza di navigazione nel nostro sito web.
Ok