Gironzolando per blog tecnici su Internet, ho già avuto modo nel recente passato di leggere qualcosa riguardo al problema delle scarse prestazioni di Windows Server 2012, “liscio” o “R2”, nel trasferimento di dati all’interno della rete lan, ma finora non mi era mai capitato di affrontare il problema “dal vivo”. Ebbene, poche settimane fa mi è toccato assistere alla penosa scena di un server nuovo di zecca, con a bordo Windows Server 2012, che trasferiva i dati in rete locale con le stesse performance di una (gloriosa) unità floppy di lontana memoria…

Quello che rende ancor più bizzarro il problema, se così lo possiamo definire, è il fatto che non capita spesso, anzi, si manifesterebbe irritabilmente in maniera imprevedibile, senza farsi annunciare da un qualche malessere durante la fase di installazione, quasi come se l’ultimo sistema operativo server di casa Microsoft volesse seguire le orme del fratellino minore per sistemi desktop, il famigerato Windows 8.x, in quanto ad accumulo di grattacapi.

Senza voler nulla togliere ai massimi esperti informatici, quello che posso fare qui è raccontare umilmente la mia esperienza e di come sono riuscito a risolvere il grattacapo al Cliente.
Tanto per iniziare, c’è un mix di fattori che concorrono a generare il problema: versione dei driver della scheda di rete, tipo di produttore del chipset della scheda di rete, schede di rete in modalità “Team”. Inizio da quest’ultimo aspetto: a partire da Windows Server 2012 è possibile gestire l’accorpamento delle schede di rete in un unico oggetto, il cosiddetto “Team”, attraverso il sistema operativo medesimo e senza più ricorrere a software di terze parti. Aggiungo, come nota ulteriore, che fino alla versione Windows Server 2008 R2 il software che gestiva le schede di rete in modalità “Team” era fornito solitamente dallo stesso produttore dell’hardware.

Altro aspetto: generalmente in fase di installazione e configurazione di un server si cerca di installare il software ed il firmware più aggiornato per ogni componente, in maniera da avere l’ultimissima configurazione disponibile nel caso sia necessario effettuare una chiamata presso l’assistenza tecnica del produttore dell’hardware ed esporgli il problema, sia esso un guasto ad un disco fisso come un malfunzionamento dell’unità di backup interna a nastro (come consuetudine il produttore dell’hardware, nel caso, “obbliga” il Cliente ad aggiornare driver di periferica e firmware all’ultima versione disponibile prima di rispondere alla richiesta di intervento – questo per avere uniformità di vedute su tutto il parco macchine installato).

Passo dunque ad esporre le tre soluzioni che ho trovato e poi applicato, nessuna delle quali preclude all’utilizzo delle altre e quindi si possono adottare tutte e tre contemporaneamente:

  1. Disabilitare nelle “Group Policy” l’opzione che consente a Windows Server 2012 di firmare digitalmente i pacchetti SMB. Eseguire il comando GPMC.MSC all’interno del prompt dei comandi (oppure digitarlo all’interno della finestra “Cerca”) per aprire lo strumento di gestione delle “Group Policy”. Fare ‘clic’ col tasto destro del mouse su “Default Domain Policy” e quindi scegliere “Edit”. Ora bisogna navigare all’interno dell’editor attraverso  Computer Configuration => Policies => Windows Settings => Security Settings => Local Policies => Security Options . A questo punto occorre porre su “DISABLED” l’opzione riferita a Microsoft Network Server: Digitally Sign Communications (Always) policy e l’opzione riferita a Microsoft Network Client: Digitally Sign Communications (Always) policy . Infine è necessario eseguire il comando GPUPDATE.EXE /FORCE per costringere il sistema operativo a dare una rifrescata alle “Group Policy” ed applicare i cambiamenti; in alternativa, se possibile, riavviare il server.
  2. Disabilitare l’opzione LSO nelle proprietà della scheda di rete. Dal Pannello di Controllo entrare in Sistema, Gestione Dispositivi e quindi Schede di Rete. All’interno delle Proprietà Avanzate della scheda di rete fisica (o della scheda di rete virtuale che gestisce il “Team” delle schede di rete fisiche) selezionare l’opzione LSO (Large Send Offload V2) per il protocollo IPv4 e quindi porla su “DISABLED”. Eseguire la medesima operazione anche per l’opzione LSO riferita al protocollo IPv6.
  3. Disabilitare l’opzione RSS nelle proprietà della scheda di rete. Dal Pannello di Controllo entrare in Sistema, Gestione Dispositivi e quindi Schede di Rete. All’interno delle Proprietà Avanzate della scheda di rete fisica (o della scheda di rete virtuale che gestisce il “Team” delle schede di rete fisiche) selezionare l’opzione RSS (Receive Side Scaling) e quindi porla su “DISABLED”.

Nota: per risolvere il problema del Cliente, ho applicato le tre soluzioni nell’ordine come sono state esposte sopra. La prima aveva permesso di incrementare le performance, ma non in maniera significativa. La seconda, sinceramente, non ha apportato alcuna variazione importante. La terza soluzione (disabilitare il Receive Side Scaling) è stata finalmente la mossa vincente e la velocità di scambio dei dati da/al server è ritornata “nella normalità” a cui siamo abituati.

Siccome non tutto quello che ho scritto è farina del mio sacco, qui di seguito elenco doverosamente gli opportuni riferimenti nel caso qualcuno volesse approfondire la questione:

How To Fix Windows Server Network Performance Problems

Windows Server 2012 slow network/SMB/CIFS problem

Large Send Offload and Network Performance

How to fix slow LAN transfer speed of files in Windows 7

Troubleshooting File Server Networking Issues in Windows Server 2012 R2

Windows Server 2012 – Affrontare il problema delle “scarse performance” in rete lan
Tagged on:                 

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *