Questa è una domanda canonica su iSCSI che possiamo usare come riferimento.

iSCSI è un protocollo che inserisce i comandi SCSI come payload nei pacchetti di rete TCP. Come tale, è soggetto a una serie di problemi diversi rispetto, per esempio, a Fibre Channel. Ad esempio, se un collegamento viene congestionato e i buffer dello switch sono pieni, Ethernet per impostazione predefinita eliminerà i frame invece di dire all'host di rallentare. Questo porta a ritrasmissioni che portano ad un'elevata latenza per una porzione molto piccola del traffico di archiviazione.

Esistono soluzioni per questo problema, a seconda del sistema operativo client, inclusa la modifica delle impostazioni di rete. Per il seguente elenco di sistemi operativi, come sarebbe una configurazione client iSCSI ottimale? Implicherebbe la modifica delle impostazioni sugli switch? E la memoria?

• VMWare 4 e 5
• Windows Hyper-V 2008 e 2008r2
• Windows 2003 e 2008 su bare metal
• Linux su bare metal
• AIX VIO
• Qualsiasi altro sistema operativo che pensi sia rilevante

Non ho familiarità con VMWare, ma uso Xenserver e ho usato Hyper-V (R2).

Con la mia attuale configurazione Xenserver ho:

• 8 server Dell Poweredge 29xx
• 2 switch Dell Powerconnect 6248
• 2 Dell MD3000i SAN (iSCSI)

Ho impostato i miei switch in una configurazione multipath e ottimizzato per iSCSI da:

• Separare i miei switch in 3 VLAN (2 per il traffico iSCSI e 1 per la gestione)
• Utilizzo di JumboFrames
• Applicando le ottimizzazioni "iSCSI" di Powerconnect

Ogni server ha più schede di rete per fornire una connessione a ciascuno switch, fornendo a sua volta ridondanza tramite multipath tra i server e la SAN iSCSI. Le VLAN iSCSI non contengono altro traffico che iSCSI.

Sono lieto di segnalare che con questa configurazione il "cluster" di Xenserver funziona in modo eccellente.

In una nota a margine ho un server Windows 2008 collegato direttamente da iSCSI a una SAN HP (vecchio file server). Eseguiva Windows 2003 e rilasciava regolarmente la connessione (anche dopo una reinstallazione del 2003); tuttavia, non appena ho eseguito l'aggiornamento a Windows 2008, rimane collegato.

Sarò felice di rispondere a qualsiasi domanda sulla mia configurazione.

Questa non è una risposta ... ancora. Questo è il framework per la risposta generica. Se hai tempo, ti preghiamo di compilare tutto ciò che sai. Per quanto riguarda la configurazione di hardware specifico, si prega di inviare una risposta separata per ciascun fornitore in modo da poter mantenere tali informazioni organizzate e separate.

Profilo QoS alle porte, oltre a disattivare il controllo della tempesta, impostare MTU su 9000, attivare il controllo del flusso e mettere le porte in portfast

Rendimento e latenza

Firmware, driver e altri sistemi aggiornati

MPIO

Jumbo Frames / MTU

All'aumentare della velocità dei collegamenti di rete, aumenta anche il numero di pacchetti potenzialmente generati. Ciò produce sempre più tempo CPU / interruzione impiegato nella generazione di pacchetti che ha l'effetto sia di indebitare eccessivamente il sistema di trasmissione sia di assorbire una quantità eccessiva di larghezza di banda del collegamento con l'inquadramento.

I cosiddetti frame "jumbo" sono frame Ethernet che superano il limite canonico di 1518 byte. Mentre i numeri possono variare in base ai fornitori di switch, ai sistemi operativi e alle schede di rete, le dimensioni dei pacchetti jumbo più tipiche sono 9000 e 9216 byte (quest'ultimo è il più comune). Dato che circa 6X i dati possono essere inseriti in un frame 9K, il numero di pacchetti (e interruzioni) effettivi è ridotto di una quantità simile sull'host. Questi guadagni sono particolarmente pronunciati su collegamenti ad alta velocità (ad es. 10GE) che inviano grandi volumi di dati (ad es. ISCSI).

L'abilitazione dei jumbo frame richiede la configurazione sia dell'host che dello switch Ethernet e occorre prestare molta attenzione prima dell'implementazione. Diverse linee guida dovrebbero essere seguite-

1.) All'interno di un determinato segmento Ethernet (VLAN) tutti gli host e i router devono avere lo stesso MTU configurato. Un dispositivo senza una corretta configurazione vedrà frame più grandi come errori di collegamento (in particolare "giganti") e li eliminerà.

2.) All'interno del protocollo IP, due host con dimensioni dei frame diverse richiedono un meccanismo per negoziare una dimensione dei frame comune appropriata. Per TCP questa è la scoperta del percorso MTU (PMTU) e si basa sulla trasmissione di pacchetti non raggiungibili ICMP. Assicurarsi che PMTU sia abilitato su tutti i sistemi e che eventuali regole ACL o firewall consentano questi pacchetti.

Controllo del flusso Ethernet (802.3x)

Nonostante sia raccomandato da alcuni fornitori iSCSI, il semplice controllo del flusso ethernet 802.3x non dovrebbe essere abilitato nella maggior parte degli ambienti a meno che tutte le porte dello switch, le schede di rete e i collegamenti siano totalmente dedicati al traffico iSCSI e nient'altro. Se è presente altro traffico sui collegamenti (come la condivisione di file SMB o NFS, heartbeat per l'archiviazione in cluster o VMware, il controllo / monitoraggio del teaming NIC, ecc.) Il controllo di flusso 802.3x semplice non deve essere utilizzato in quanto blocca intere porte e anche l'altro traffico non iSCSI verrà bloccato. I vantaggi in termini di prestazioni di Ethernet Flow Control sono spesso minimi o inesistenti, il benchmarking realistico dovrebbe essere eseguito su tutte le combinazioni OS / NIC / switch / storage prese in considerazione per determinare se ci sono benefici effettivi.

La vera domanda dal punto di vista dei server è: interrompo il traffico di rete in caso di sovraccarico della mia scheda di rete o rete o comincio a eliminare e ritrasmettere i pacchetti? L'attivazione del controllo di flusso consentirà di svuotare i buffer della scheda NIC sul lato ricevitore, ma solleciterà i buffer sul lato mittente (normalmente un dispositivo di rete esegue il buffer qui).

TCP Congestion Control (RFC 5681)

TOE (motori di offload TCP / IP)

iSOE (motori offload iSCSI)

LSO (segmentazione TCP / offload invio di grandi dimensioni)

Isolamento di rete

Una best practice comune per iSCSI consiste nell'isolare sia gli iniziatori che i target da altro traffico di rete non di archiviazione. Ciò offre vantaggi in termini di sicurezza, gestibilità e, in molti casi, dedizione delle risorse al traffico di archiviazione. Questo isolamento può assumere diverse forme:

1.) Isolamento fisico: tutti gli iniziatori hanno una o più schede di rete dedicate esclusivamente al traffico iSCSI. Ciò può o potrebbe non implicare hardware di rete dedicato a seconda delle capacità dell'hardware in questione e dei requisiti operativi e di sicurezza specifici all'interno di una determinata organizzazione.

2.) Isolamento logico: principalmente nelle reti più veloci (ad es. 10GE), gli iniziatori hanno il tagging VLAN (vedi 802.1q) configurato per separare il traffico di archiviazione e non di archiviazione.

In molte organizzazioni vengono impiegati meccanismi aggiuntivi per assicurare anche che gli iniziatori iSCSI non siano in grado di raggiungersi su queste reti dedicate e che, inoltre, queste reti dedicate non siano raggiungibili da reti di dati standard. Le misure utilizzate per raggiungere questo obiettivo includono elenchi di controllo di accesso standard, VLAN private e firewall.

Qualcosa sul backplane e sul cambio di tessuto anche qui.

QoS (802.1p)

vLAN (802.1q)

STP (RSTP, MSTP, ecc.)

Soppressione del traffico (Storm Control, Multi / Broad-cast Control)

Sicurezza

Autenticazione e sicurezza

CHAP

IPSec

Mappatura LUN (migliori pratiche)

Qualche considerazione e ricerca che dovresti prendere in modo soggettivo riguardo a:

1) Multi-pathing: la tua soluzione SAN e il tuo sistema operativo, sia esso hypervisor o sistema operativo bare metal, potrebbero aver bisogno di software specifici del fornitore per il corretto funzionamento.

2) Iniziatori: è necessario verificare se l'iniziatore del software ha prestazioni sufficienti in base alle esigenze. Molte schede di rete hanno funzionalità di offload iSCSI che possono migliorare significativamente la velocità effettiva, ma alcuni hypervisor più vecchi sono stati notoriamente arrabbiati con il loro supporto saggio. Le offerte più mature (ESXi 4.1+) sembrano posizionarsi bene.

3) Sicurezza / Autorizzazioni - Assicurati di controllare completamente quali iniziatori richiedono l'accesso a quali LUN ... ti ritroverai in una brutta giornata se un amministratore su una delle tue macchine Windows esegue un "inizializzazione del disco" su un disco che è realmente utilizzato da un altro server come archivio dati VMware.