L’installazione di un Failover Cluster è un’operazione semplice dal punti di vista dell’operatività, ma complessa nella pianificazione. Uno dei punti chiavi per il buon funzionamento del cluster è appunto la configurazione delle reti utilizzate dal cluster. Infatti una configurazione non corretta di tali reti può determinare il mancato funzionamento del cluster o dei malfunzionamenti saltuari.
Di seguito faremo riferimento ad uno scenario di esempio relativo ad un Hyper-V cluster a due nodi, figura 1, ma i concetti non cambiano nel caso di più nodi.
Figura 1 – Scenario Hyper-V Cluster
Di seguito una descrizione delle reti necessarie al cluster che prenderemo in esame:
| Storage | Connessa verso la Storage in Fiber Channel o iSCSI |
| Cluster | Normalmente in idle, utilizzata per le comunicazioni inter-node cluster come l’heartbeat il Cluster Shared Volumes (CSV) redirection, ovvero quando gli I/O sono eseguiti dal Coordinator Node, ad esempio nel caso di fallimento della connettività da parte di un nodo verso lo storage o quando avvengono modifiche di metadati: creazione/eliminazione VM, avvio/arresto VM, Live Migration, Storage Migration, creazione Snapshot, estensione VHD dinamico, rename VM. Il traffico di questa rete è non routable e deve quindi essere sulla stessa subnet. |
| Live Migration | Normalmente in idle, utilizzata quando le VM vengono trasferite da un nodo all’altro e necessita di bassa latenza e alta banda. |
| Management | Connessa ai servizi Active Directory e DNS utilizzati dal cluster, inoltre permette la gestione del cluster come ad esempio il backup e la configurazione delle risorse del cluster (per esempio la creazione VM). Può necessitare di banda elevata nel caso si usi SCVMM per il deploy delle VM. |
| Production | Connessa alla VM e alla LAN aziendale, i requisiti di latenza e banda dipendono dai workloads e dai carichi delle VM, ma per evitare problemi co picchi di carico concorrenti sulle VM è meglio gestire questa rete per ottenere bassa latenza e alta banda. |
Schede di Rete Necessarie
Dal momento che lo scopo di un Failover Cluster è quello di garantire continuità di servizio occorre che ogni suo componente sia ridondato, quindi è necessario che ciascuna rete sia gestita da almeno due NIC per ogni host possibilmente di tipo diverso per ridurre i rischi di malfunzionamento dovuto al driver.
Le reti Production e Live Migration potrebbero richiedere un numero maggiore di NIC in base al numero e ai carichi delle VM.
Per gestire la continuità di servizio e l’ottimizzazione delle risorse è conveniente configurare ogni rete, ad eccezione di quella dedicata alla storage, per l’utilizzo del NIC Teaming utilizzando l’algoritimo di load balancing Dynamic (per un approfondimento su questo aspetto si veda il mio articolo Windows Server 2012 R2: Configurare il Teaming Load Balancing).
A riguardo si vedano anche le indicazioni fornite nel post Configuring Windows Failover Cluster Networks:
- “Use multiple physical network adapter cards. Multiple ports of the same multiport card or backplane used for networks introduces a single point of failure.”
- “Connect network adapter cards to different independent switches. Multiple Vlans patched into a single switch introduces a single point of failure.”
- “Use of NIC teaming for non-redundant networks, such as client connection, intra-cluster communication, CSV, and Live Migration. In the event of a failure of the current active network card will have the communication move over to the other card in the team.”
- “Using different types of network adapters eliminates affecting connectivity across all network adapters at the same time if there is an issue with the NIC driver.”
- “Ensure upstream network resiliency to eliminate a single point of failure between multiple networks.”
- “The Failover Clustering network driver detects networks on the system by their logical subnet. It is not recommended to assign more than one network adapter per subnet, including IPV6 Link local, as only one card would be used by Cluster and the other ignored.”
Configurazione delle Connessioni di Rete
Per il buon funzionamento e l’ottimizzazione del cluster è importante configurare in modo ottimale le connessioni di rete relative alle reti abilitando le funzionalità necessarie e disabilitando quelle non necessarie in base alle indicazioni fornite nei seguenti post Configuring Windows Failover Cluster Networks, Windows Server 2012 Hyper-V Best Practices (In Easy Checklist Form) e Hyper-V: How many network cards do I need?.
Di seguito uno schema delle indicazioni da seguire per la configurazione IPv4 di ciascuna rete:
| Storage | NetBIOS disabilitato Gateway e DNS non configurati Registrazione DNS disabilitata |
| Cluster | NetBIOS disabilitato Gateway e DNS non configurati Registrazione DNS disabilitata |
| Live Migration | NetBIOS disabilitato Gateway e DNS non configurati Registrazione DNS disabilitata |
| Management | NetBIOS abilitato Gateway configurato se necessario DNS configurati con gli IP dei DC Registrazione DNS abilitata |
| Production | NetBIOS disabilitato Gateway e DNS non configurati Registrazione DNS disabilitata |
Per quanto riguarda l’IPv6, la raccomandazione per Windows Server 2008, e successivi, è quella di lasciarlo abilitato su tutte le reti, volendo è possibile disabilitarlo sulla rete Production se nella Lan aziendale tale protocollo non è implementato. A riguardo si vedano le considerazioni nel seguente post Failover Clustering and IPv6 in Windows Server 2012 R2:
- “If both IPv4 and IPv6 are enabled (which is the default configuration), IPv6 will be always used by clustering. The key take away is that it is not required to configure IPv4 when the IPv6 stack is enabled and you can go as far as to unbind IPv4.”
- “The recommendation for Failover Clustering and Windows in general, starting in 2008 RTM, is to not disable IPv6 for your Failover Clusters. The majority of the internal testing for Failover Clustering is done with IPv6 enabled. Therefore, having IPv6 enabled will result in the safest configuration for your production deployment.”
- A common misconception is that Failover Clustering will cease to work if IPv6 is disabled. This is incorrect. The Failover Clustering release criterion includes functional validation in an IPv4-only environment.
Di seguito uno schema delle indicazioni da seguire per la configurazione delle comunicazioni inter-node cluster di ciascuna rete:
| Allow cluster network communication | Allow clients to connect | |
| Storage | No | – |
| Cluster | Si | No |
| Live Migration | Si | No |
| Management | Si | Si |
| Production | No | – |
Di seguito uno schema delle indicazioni da seguire per ulteriori configurazioni da impostare su ciascuna rete:
| Storage | Disabilitare il Client Microsoft per la condivisione file e stampanti Disabilitare tutti i protocolli tranne IPv4, IPv6, eventuali protocolli del produttore Se supportati abilitare i Jumbo Frames con valori tra 9000 e 9014 |
| Cluster | Abilitare il Client Microsoft per la condivisione file e stampanti per supportare l’utilizzo delle feature dell’SMB 3.0 (SMB multi-channel e SMB Direct) Impostare tale rete per comunicazioni CSV Se supportati abilitare i Jumbo Frames con valori tra 9000 e 9014 |
| Live Migration | Abilitare il Client Microsoft per la condivisione file e stampanti per supportare l’utilizzo delle feature dell’SMB 3.0 (SMB Direct) Se supportati abilitare i Jumbo Frames con valori tra 9000 e 9014 |
| Management | Abilitare il Client Microsoft per la condivisione file e stampanti per supportare l’utilizzo delle feature dell’SMB 3.0 |
| Production | Rimozione Client Microsoft per la condivisione file e stampanti Abilitare VMQ (Virtual Machine Queue) |
I Jumbo Frames possono incrementare fino a 6 volte il throughput riducendo l’utilizzo della CPU, ma occorre tenere presente che tutti gli end point della rete devono supportarne l’utilizzo (NIC, SAN, Switch, OS Host, OS Guest). Per verificare se i Jumbo frames funzionano correttamente è possibile verificare se il ping tra gli host sulle reti interessati con un pacchetto di 8K non viene frammentato (ping IPHost -f -l 8000). Per attivare la funzionalità dei Jumbo frame occorre configurarla sulla NIC della parent partion (OS Host), sulla NIC della VM (OS Gest), sull Hyper-V virtual switch.
Per utilizzare VMQ è necessario che le NIC devono supportare VMQ e che le VM devono eseguire OS che supportano VMQ (Windows Vista / Windows Server 2008 e successivi). Per verificare l’abilitazione di VMQ utilizzare il cmdlet Get-NetAdapterVMQQueue.
Per le reti su cui è stato abilitato il NIC Teaming disabilitare il TCP Chimney Offload in quanto non supportato in combinazione col NIC Teaming. Utilizzare il comando netsh int tcp show global per controllare l’impostazione del TCP Chimney Offload e verificare che la voce Chimney Offload State sia impostata a disabled, per disabilitare il TCP Chimney Offload utilizzare il comando netsh int tcp set global chimney=disabled.
Se si utilizza iSCSI occorre abilitare la rule del firewall in entrata “iSCSI Service (TCP-In)” e la rule in uscita “iSCSI Service (TCP-Out)”, è possibile eseguire tale configuurazione tramite la GUI o con il comando: Netsh advfirewall firewall set rule group=”iSCSI Service” new enable=yes
Per le rete della Live Migration utilizzare la compressione se si hanno NIC a 10Gbps o inferiore, con NIC superiori a 10Gbps utilizzare RDMA.
Ordine di Binding delle Connessioni di Rete
L’ordine di binding riflette l’ordine in cui il TCP/IP o il successivo protocollo disponibile è associato alle schede di rete e l’ordine in cui le connessioni di rete accedono ad dai servizi di rete.
Come indicato nei post Windows Server 2012 Hyper-V Best Practices (In Easy Checklist Form) e Configuring Windows Failover Cluster Networks la connessione di rete relativa alla rete di Management dovrebbe essere la prima nell’ordine di binding in modo da garantire che le connessioni per la gestione del cluster e verso l’Active Directory siano servite più rapidamente.
In Windows Server 2012/R2 la connessione di rete relativa al Cluster Network Driver (NETFT.SYS) adapter viene automaticamente posizionata al fondo dell’ordine di binding.
Per gestire l’ordine di binding da riga di comando è possibile utilizzare l’utility nvspbind che permette di visualizzare le informazioni dei network adapter e l’ordine di binding compresi quelli nascosti (come ad esempio il Cluster Network Driver adapter).
#REM Elenco network adapter su file (l’adapter del cluster è il Microsoft Failover Cluster Virtual Adapter)
nvspbind /n > NICInfo.txt
#REM Ordine di binding per l’IPv4 su file
nvspbind /o ms_tcpip > BindingOrderIPv4.txt
#REM Ordine di binding per l’IPv6 su file
nvspbind /o ms_tcpip6 > BindingOrderIPv6.txt
Volendo l’utility nvspbind permette anche di modificare l’ordine di binding e di gestire i vari protocolli, a riguardo si veda l’help a corredo del tool.
Come best practices è consigliabile controllare di avere lo stesso ordine di binding sui vari nodi del cluster confrontando l’output su file generato da nvspbind.
Conclusioni
La configurazione delle reti del cluster è di fatto uno dei punti fondamentali per il buon funzionamento dello stesso. Ovviamente non tutte le indicazioni fornite nell’articolo sono utilizzabili in qualunque scenario, ad esempio l’utilizzo o meno del Jumbo frame e di VMQ andrebbe testato per verificare se vi sono reali vantaggi.
Quindi l’indicazione è quella di iniziare con le configurazioni valide in generale provando poi quelle più specifiche e nel caso non vi siano evidenti differenze il mio consiglio è quello mantenere le configurazioni più semplici possibili. Inoltre si ricordi che è sempre bene predisporre gli elementi della struttura di rete che si desidera utilizzare (switch dedicati, VLAN, NIC Teaming, Virtul Switch di Hyper-V) prima di configurare il cluster e operare in seguito solo eventuali ritocchi sulle impostazioni.