Di recente, dopo svariati test effettuati in laboratorio, si è deciso di aggiornare i driver delle schede di rete installate su 2 macchine Windows Server 2003 R2 (in failover cluster) , passando dai driver Broadcom a quelli Intel (cosa molto più sensata dato che il produttore delle NIC è, per l’appunto, Intel).
Va detto che tale scelta è stata dettata anche dal fatto che con il software di gestione del teaming messo a disposizione da Broadcom, l’unica modalità selezionabile era il load balancing, ovvero la possibilità di transmettere/ricevere il traffico di rete “un po’ da una scheda ed un po’ dall’altra”. Fin qui nulla di male, se non fosse per il fatto che, in caso di fault di uno dei due switch o di una delle due schede del teaming, prima che il sistema riuscisse a riconvergere sull’unica NIC ancora funzionante, si è assistito ad un tempo di disservizio randomico, che poteva variare da qualche secondo a qualche minuto. Premesso che, a mio avviso, tale comportamento era strettamente legato alla durata della cache ARP dei sistemi coinvolti, una situazione del genere non era comunque tollerabile, soprattutto per dei sistemi di importanza critica e cruciale.
A differenza di quanto assistito per il software Broadcom, grazie al software Intel, configurando le schede in modalità switch failover, si è riusciti a ridurre notevolmente i tempi di riconvergenza, portandoli a circa un secondo (ed un solo pacchetto ICMP in request timeout). Tutto molto bello, a parte il fatto che dopo aver aggiornato i driver, il sistema ha iniziato a ricevere (ed inviare) i dati troppo lentamente.
Dopo aver analizzato innumerevoli tracciati Wireshark ed aver spulciato tutta la documentazione possibile ed immaginabile, sono arrivato alla conclusione che la causa della suddetta problematica era il TCP Offload (abilitato di default).
Cos’è il TCP Offload
Il TCP Offload è stato introdotto per ridurre l’overhead (leggasi carico aggiuntivo) dei server durante la gestione del traffico di rete (il quale è aumentato in modo esponenziale rispetto alle reti TCP/IP di un trentennio addietro). Nella fattispecie, grazie alla suddetta “feature”, il traffico viene gestito direttamente dall’hardware della NIC (senza quindi passare per la CPU). Per essere più precisi, vige la regola che per ogni byte di traffico di rete gestito dal server corrisponda un carico sulla CPU pari ad un HZ, quindi si può certamente intuire quanto il TCP offload possa portare (in alcuni casi) dei benefici a livello computazionale e prestazionale.
Solitamente tale configurazione è dunque migliorativa, salvo alcune eccezioni. Ad esempio, spesso accade che il TCP offload forgi dei segmenti TCP di dimensione superiore a 64 byte, i quali vengono incapsulati (layer 2) in frame di dimensione superiore ai 1500 byte (che rappresenta la MTU di default delle reti Ethernet e quindi quella supportata nativamente dalla stragrande maggioranza dei dispositivi di rete).
Cosa succede in questo caso? Ebbene, se gli switch non sono configurati a dovere, essi scarteranno (in modo trasparente, salvo previa connessione alla CLI se si tratta di dispositivi managed) i pacchetti con MTU > 1500 byte, riducendo drasticamente il throughput dei server.
In definitiva, nel caso in cui riscontraste una lentezza anomala in TX/RX da parte delle vostre macchine, vi consiglio, come primo step, di disabilitare tale opzione.
Alla prossima.
