Tipi di iSCSI initiator
Nel mondo delle SAN iSCSI esistono varie possibilità nei tipi di iSCSI initiator (la parte “client” del protocollo iSCSI):
- Software initiator: tutto lo stack iSCSI (a parte i primi due livelli) è implementato in software (e per questa ragione richiede maggiori risorse di CPU/mem da parte dell’host).
- Hardware initiator: tutto lo stack iSCSI è implementato in hardware (utilizzando le risolrse hardware dell’adattatore); spesso è indicato anche come iSCSI HBA.
-
Hardware-assisted initiator: una parte dello stack iSCSI è implementato in hardware (ma potrebbero essere usate risorse non dell’adattatore, ma dell’host resources); questo è il caso, ad esempio, delle schede di rete (NIC) con funzioni di TCP Offload Engine (TOE).
Gli initiator hardware-assisted (anche indicati come hardware-accelerated) dipendono da specifiche funzioni hardware implementate in alcune schede di rete recenti, come è il caso di alcuni modelli di Broadcom. Notare che le schede Intel utilizzano una tecnologia leggermente differente chiamata Intel® I/O Acceleration Technology:
- http://download.intel.com/support/network/sb/19127_lad_competeguide_r04.pdf
- http://features.techworld.com/storage/1236/intels-i-o-at-is-not-a-toe-killer/
Nella terminologia VMware gli initiator hardware-assisted e HBA hardware sono anche chiamati:
- Dependent Hardware iSCSI Adapter: dipendono dalla parte di VMware networking, come nel caso di software initiators.
Sono le NIC con funzioni di offload di parte dello stack iSCSI, come ad esempio le Broadcom 5709 (notare che la funzione di offload può richiedere una licenza particolare per la NIC). - Independent Hardware iSCSI Adapter: implementano da sole la parte di networking e anche la parte di gestione (di solito nel firmware dell’HBA).
Sono le schede iSCSI HBA, come ad esempio le QLogic QLA4052.
Supporto in vSphere
In vSphere sono supportati sia gli initiator software e hardware; in entrambi i casi con il supporto del multi-pathing per un maggior livello di disponibilità e per gestire la ridondanza e i possibili guasti alla rete SAN. Una pratica raccomandata è di non combinare mai i diversi tipi di initiator su uno stesso host.
La configurazione nei due casi è differente: nel caso hardware independent (con iSCSI HBA) la configurazione è fatta nel firmware della scheda e questa viene vista come un normale storage adapter, nel caso software (ma anche in quello hardware dependent) la configurazione richiedere anche una corretta impostazione della parte di networking e anche del firewall (nella versione “legacy” ESX o in ESXi 5.0).
A partire da vSphere 4.1 è stato introdotto il supporto per alcuni tipi di iSCSI hardware dependent adapter, but con alcuni limiti (ad esempio non sono supportati i Jumbo Frames, e questo limite pare essere rimasto anche in vSphere 5.0). Per maggiori informazioni vedere:
- http://www.vmwareinfo.com/2009/01/iscsi-hardware-or-software-how-many.html
- http://vbl0g.blogspot.com/2010/07/vsphere-41-with-iscsi-offloading.html
- http://www.sanstor.info/5iSCSI%20software%20initiators%20vs.pdf
- http://www.dell.com/downloads/global/products/pedge/en/BroadcomDellEnhancedVirualizationFunctionalityWhitePaper.pdf
Performance
In vSphere (almeno dalla versione 4.0) la differenza di prestazioni (in particolare relative al throughput della parte storage iSCSI) tra i diversi tipi di initiator è abbastanza minima. La grossa differenza è che una soluzione hardware (independent) può implementare tutto lo stack iSCSI in hardware salvando risorse dell’host (di fatto salvando CPU e, in parte, memoria di sistema). Ma con i nuovi processori multi-core, il maggiore overhead di CPU di una soluzione software, può essere facilmente mitigato.
Per maggiori informazioni vedere:
La scelta più corretta?
Come spesso accade non esiste una scelta migliore in assoluto rispetto ad un’altra: dipende da diversi fattori, tra cui anche i requisiti del cliente. Quello che è importante capire è che il throughput non è influenzato in modo particolare dalla scelta del tipo di initiator, e quindi le performance non devono (secondo me) essere usate come criterio di scelta. Da notare che prestazioni dipendono molto di più dalla velocità delle NIC e della rete SAN (e anche dal numero di NIC) e dal supporto o meno ai Jumbo Frames (anche se non tutti gli storage presentano lo stesso grado di miglioramento).
La soluzione software iSCSI può essere necessaria quando si hanno un numero limitato di slot di espansione all’interno dell’host. In questo caso si possono riutilizzare NIC già presenti (anche se è vivamente consigliato mantenere NIC dedicate all’iSCSI sia per maggiore sicurezza che maggiori prestazioni). Un altr0 caso di utilizzo della soluzione software può essere per il contenimento dei costi, visto che una scheda iSCSI HBA può costare quanto (e a volto anche più) di una scheda FC HBA.
Invece, riguardo alla scelta tra hardware dependent o software iSCSI è possibile vedere: Software iSCSI Initiator with Jumbo Frames vs Hardware dependant iSCSI Initiator without Jumbo Frames and Software or Hardware iSCSI? No Jumbo Frame on HBA? Personalmente (ma altri la pensano in maniera diametralmente opposta) preferisco avere il supporto dei Jumbo Frames e quindi una soluzione software… chiaro che diviene importante configurare correttamente anche lo storage e gli switch iSCSI per il corretto supporto a questa funzione (e scegliere anche degli switch in grado di garantire buone prestazioni).
Maggiori informazioni
- http://www.yellow-bricks.com/2009/03/18/iscsi-multipathing-with-esxcliexploring-the-next-version-of-esx/
- http://virtualgeek.typepad.com/virtual_geek/2009/01/a-multivendor-post-to-help-our-mutual-iscsi-customers-using-vmware.html
- http://vmworld2010.com/docs/DOC-3844
- iSCSI HBA vs. Std NIC
- Re: General Question on hardware vs software iSCSI initiators