Windows Server: Configurare Teaming nei Domain Controller

Talvolta sui forum compare la domanda se convenga o meno utilizzare il NIC Teaming su Domain Controller fisici dal momento che comunemente anche i server di fascia bassa vengono dotati di main board con più interfacce ethernet disponibili.

Di seguito alcune considerazioni sulla base della versione del sistema operativo del Domani Controller.

Windows Server 2008 R2 e Precedenti

Fino a WS2008R2 il NIC Teaming può essere gestito solo tramite soluzioni di terze parti offerte dal vendor delle schede di rete. Questo implica che Microsoft non offre supporto alla funzionalità NICTeaming, ma dovrà essere il vendor delle schede di rete a farsi carico del supporto.

Inoltre per quanto riguarda la funzionalità del NIC Teaming applicata al ruolo Domain Controller valgono le considerazioni tratte dal post Friday Mail Sack: The Gang’s All Here Edition pubblicato sul blog del supporto Enterprise per Active Directory (Ask the Directory Services Team):

Generally speaking, we are not huge fans of NIC teaming, as we see customers having frequent driver issues and because a DC probably doesn’t need it. If clients are completely consuming 1Gbit or 10Gbit network interfaces, the DC is probably being overloaded with requests. Doubling that network would make things worse; it’s better to add more DCs. And if the DC is also running Exchange, file server, SQL, etc. you are probably talking about an environment without many users or clients.

A failover NIC solution is probably a better option if your vendor supports it. Meaning that the second NIC is only used if the first one burns out and dies, all on the same network.

In sostanza quindi il consiglio è quello di evitare l’utilizzo del NIC Teaming sui Domain Controller e se si riscontra un elevato carico di rete sul DC è consigliabile aggiungere altri DC all’infrastruttura in modo da aumentare la ridondanza oltre a ridurre il carico sui singoli DC. Il NIC Teaming in configurazione load balancing viene di fatto sconsigliato a causa di problemi legati ai driver che purtroppo sono frequenti, al limite è possibile valutare l’utilizzo del NIC Teaming in modalità failover per avere ridondanza nel caso di rottura di una scheda di rete.

A pagina 29 del documento Directory Service Blueprint.doc contenuto nel file WSSRA_Directory_Service_Implementation_Guides.exe disponibile al link Windows Server System Reference Architecture (WSSRA) viene esplicitamente confermato che per sistemi WS2003 il NIC Teaming in modalità load balancing non è supportato:

The second way to protect against a network failure is to configure each domain controller with two separate network cards. Each card is wired to redundant network switches and the cards are configured as a fault-tolerant team. The server would have one IP address, but in the event of network switch or card failure, the server will continue to operate using the additional connection. Note that this configuration can only be used for fault-tolerant capabilities, not load balancing. At this time, Microsoft does not support load balanced network teams on domain controllers due to potential data corruption issues. There is an increase in hardware costs, due to the redundant network cards, cables, and switches that are needed; there is also an additional management cost. In addition, this configuration would not protect against a failure at the router level. Finally, Active Directory is highly reliant on DNS. The DNS service should be available at all times to support requests from the domain controllers.

A parte le considerazioni fatte per il ruolo Domain Controller si tenga presente che, come descritto nella KB278431 Using teaming adapters with network load balancing may cause network problems, il NIC Teaming può causare problemi se utilizzato in combinazione con il Network Load Balancing (NLB). Sempre nella KB278431 viene chiarito il comportamento del Microsoft Product Support Services (PSS) nel caso debba gestire chiamate di supporto in cui nello scenario sia presente la funzionalità di NIC Teaming:

From the perspective of Microsoft Product Support Services (PSS), use of teaming on clustered or dedicated interfaces is acceptable. However, if problems that occur seem to be related to teaming, PSS may require that you disable teaming while the problem is investigated. If this disabling of teaming itself resolves the problem, you must seek assistance from the hardware manufacturer.

Sui DC WS2008 R2 il NIC Teaming può creare problemi all’esecuzione del tool Dcdiag.exe, a riguardo si veda FIX: The connectivity test that is run by the Dcdiag.exe tool fails together with error code 0x621.

Per ulteriori informazioni sul supporto del NIC Teaming con altri ruoli si vedano anche le seguenti:

Per quanto riguarda invece il ruolo file server si vedano invece le considerazioni fatte nel post Using the multiple NICs of your File Server running Windows Server 2008 (and 2008 R2) da Jose Barreto membro del File Server team in cui vengo presentati alcuni scenari alternativi all’utilizzo del NIC Teaming nel caso in cui il server disponga di più NIC.

Windows Server 2012 e Successivi

A partire da WS2012 il NIC Teaming è disponibile nativamente nel sistema operativo e di conseguenza è completamente supportato come indicato nel post NIC Teaming in Windows Server 2012 Brings Simple, Affordable Traffic Reliability and Load Balancing to your Cloud Workloads:

Windows Server 2012 includes an integrated NIC Teaming solution that is easy to setup and manage, is vendor independent, and that supports the performance optimizations provided by the underlying NICs. NIC Teaming is easily managed through PowerShell or a powerful, intuitive UI (the UI is layered on top of PowerShell). Teams can be created, configured, monitored, and deleted at the click of a mouse. Multiple servers can be managed at the same time from the same UI. Through the power of PowerShell remote management the NIC Teaming UI can be run on Windows 8 clients to remotely manage servers even when those servers are running Windows 2012 Server Core! A team can include NICs from any vendor – and it can even include NICs from multiple vendors. This vendor-agnostic approach brings a common management model to even the most heterogeneous datacenter. New NICs can be added to systems as needed and effortlessly integrated to the existing NIC Teaming configuration. Finally, the team supports all the networking features that the underlying NICs support, so you don’t lose important performance functionality implemented by the NIC hardware. The “no compromise” approach means that NIC Teaming can be deployed with confidence on all servers.

In caso anche se il NIC Teaming è ora supportato ritengo che la strategia più corretta sia quella di gestire l’alta affidabilità e l’alta disponibilità dei Domain Controller tramite un numero congruo degli stessi nell’infrastruttura in modo da suddividere i carichi e sopperire ad eventuali indisponibilità dal momento che Active Directory è stata appunto pensata tenendo presente questo tipo di necessità.

Ovviamente il discorso è diverso se parliamo di Domain Controller virtuali e quindi è ovviamente consigliabile che l’host di virtualizzazione sfrutti il NIC Teaming per offrire ai Domain Controller virtuali una connessione di rete affidabile e a banda elevata.

Per le considerazioni fatte precedentemente non è invece consigliabile eseguire il Guest NIC Teaming in un Domain Controller virtuale. Per maggiori informazioni sul NIC Teaming all’interno di una VM in Hyper-V si veda il documento Windows Server 2012 R2 NIC Teaming (LBFO) Deployment and Management a pagina 13:

NIC Teaming in a VM only applies to vmNICs connected to external switches; vmNICs connected to internal or private switches will show as disconnected when they are in a team. NIC teaming in Windows Server 2012 R2 may also be deployed in a VM.

This allows a VM to have virtual NICs connected to more than one Hyper-V switch and still maintain connectivity even if the physical NIC under one switch gets disconnected. This is particularly important when working with Single Root I/O Virtualization (SR-IOV) because SR-IOV traffic doesn’t go through the Hyper-V switch and thus cannot be protected by a team in or under the Hyper-V host.