Cluster Shared Volumes (CSV) : parte 4

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 :

     (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 :

     (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 :

     (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 / Save :

Lascia un commento

Questo sito usa Akismet per ridurre lo spam. Scopri come i tuoi dati vengono elaborati.