다음을 통해 공유

Best Practice per SNP e Offload in Windows Server

  • 아티클

Ciao a tutti!

In passato abbiamo già affrontato l’argomento SNP e Offload in questo post.

Riassumendo molto in breve, si tratta di un insieme di feature che possono utilizzare accelerazione hardware per migliorare le performances di rete del server, con occhio particolare alla velocità di processing dei pacchetti e throughput. Per questo motivo, è ovvio che per funzionare al meglio c’è bisogno di perfetta sintonia tra software (Windows) e hardware (terze parti).

Viste le numerose richieste di assistenza che ci arrivano, abbiamo pensato di condividere con voi quali sono le best practice consigliate da Microsoft sull’argomento.

Windows Server 2003

Offload e SNP sono state introdotte a partire dalla SP2 di Win2003.

è storicamente noto che molti clienti che hanno installato Windows Server 2003 con SP2 su hardware che avrebbe potuto sfruttare le funzionalità abbiamo avuto diversi problemi causati da difficoltà di interoperabilità dei componenti e problemi con I driver delle schede di rete.

La posizione ufficiale Microsoft è quindi disabilitare SNP su Windows Server 2003. Per farlo in modo rapido e semplice, è sufficiente fare riferimento a http://support.microsoft.com/kb/948496

Il problema è che una volta visti I problemi su SNP in Windows Server 2003, nella comunità IT si è sparsa la pratica comune di disabilitare tutti I tipi di offload su tutte le versioni del sistema operativo, anche quando non necessario.

Windows Server 2008

A partire da Windows Server 2008, lo stack del TCP/IP di Windows è infatti stato completamente riscritto. La funzionalità dei componenti non è quindi più influenzata in alcun modo da quello che poteva succedere su Windows 2003. Per questo motivo è assolutamente sbagliato disabilitare a priori le tecniche di offload, in particolare è molto importante mantenere abilitato RSS (Receive-side scaling), la tecnica che permette al sistema operativo di distribuire il processing dei pacchetti di rete su più di una CPU nei sistemi multi-core.

Disabilitare RSS ha portato numerosi clienti ad avere problemi di performances e genericamente lentezza. Paradossalmente, ciò potrebbe portare anche a maggiori costi, visto che potrebbe indurre ad acquistare un hardware più potente del necessario per gestire lo stesso carico gestibile con RSS.

Le best practices sono quindi:

  • Installare SP2 (required)
  • Installare http://support.microsoft.com/kb/979614
  • Installare http://support.microsoft.com/kb/967224
  • Ri-abilitare RSS sia su sistema operativo che schede di rete
  • Aggiornare I drivers delle schede di rete all’ultima versione disponibile consigliata dai produttori hardware
  • Aggiornare il software antivirus e le definizioni all’ultima versione disponibile

Per completezza, I settaggi di default di Windows 2008 sono I seguenti:

image

Windows Server 2008 R2

Windows Server 2008 R2 non si discosta molto dalla versione precedente e quindi tali best practices per Windows 2008 sono ancora valide. Inoltre, sono stati risolti alcuni piccoli malfunzionamenti (vedi lista delle hotfix consigliate) e c’è stato un cambiamento sulla gestione del TCP Chimney (vedi post precedente per la descrizione dettagliata del componente).

TCP Chimney è di default disabilitato in Server 2008 mentre su 2008R2 lo stato è “automatic”. Questo significa che di default il sistema operativo considererà di “offloadare” una connessione solo se rispetta alcuni parametri, in particolare se:

  • la connessione è stabilita tramite un adapter 10Gbps Ethernet
  • il round trip time medio è inferiore ai 20 millisecondi
  • almeno 130Kb di dati sono già stati scambiati durante la connessione

Questo viene fatto per evitare di delegare alla scheda di rete connessioni per le quali non ci sarebbe alcun beneficio in termini di performance.

Le best practices sono quindi:

Per completezza, I settaggi di default di Windows 2008R2 sono i seguenti:

image

Grazie a tutti e alla prossima!

Stefano Gagliardi
Support Engineer
Microsoft Enterprise Platform Support

Comments

  • Anonymous
    January 01, 2003
    Parabens pelo artigo.