This post is also available in: Inglese

Nel caso si utilizzino dischi SSD collegati ad un controller RAID hardware come ad esempio il Dell PERC (molto comune su molti server Dell PowerEdge) si potrebbe incorrere il problema che i dischi non siano riconosciuti in qualità di dischi SSD, ma solo come “generici” dischi logici. Il motivo è la mancanza (su questo tipo di controller) di una funzione di tipo pass-thought che tratti il disco “as is” senza introdurre inutili funzionalità o livelli di astrazione.

Potrebbe non essere un problema se il disco comunque sarà utilizzato come disco (o come datastore su VMware), ma potrebbe essere un problema se si vuole impiegarlo come livello di cache per il filesystem o lo storage.

Se il server è standalone, si potrebbe pensare di sfruttare la funzione chiamata CacheCade ed implementata su schede PERC recenti ed in grado di ottimizzare le operazioni di I/O. Per maggiori informazioni sulla funzione di CacheCade rimando a questo link, ma ovviamente questo è vincolato solo ad alcuni scenari.

Come scritto, però in caso di soluzioni di cache custom (ad esempio PernixData), oppure se si vuole implementare una soluzione basata su Microsoft Windows Storage Pools nella versione 2012 R2 (con tiering) o su VMware VSAN l’uso delle schede PERC potrebbe dare qualche problema. Sarebbe meglio collegare i dischi direttamente ad una generica scheda SAS (senza RAID) oppure ovviamente avere soluzioni su PCI (come ad esempio Fusion-IO). Alcuni server PowerEdge già includono una scheda SAS integrata (e spesso anche un doppio backplane utilizzabile per splittare alcuni dischi sulla scheda PERC e altri sulla SAS), ma non sempre è così o non sempre è possibile ricablare il server.

Se bisogna per forza utilizzare un controller PERC (o in generale un controller RAID senza pass-throught) con dischi SSD collegati, il primo passo da fare è configurarli in RAID0, ovviamente solo nei casi descritti precedentemente, se l’obiettivo è creare un disco SSD per memorizzare dati allora è meglio una configurazione con ridondanza.

Altra accortezza è disabilitare la cache sul controller almeno per i dischi logici RAID0 associati ai dischi SSD: le logiche di read cache adattative e write back potrebbero non avere senso su dischi SSD e comunque introducono una latenza aggiuntiva.

Altro parametro potenzialmente importante è il block chunch o lo stripe size (sulle schede PERC lo stripe size può variare da 64k a 1MB) che può cambiare in base al tipo di utilizzo del disco. Ad esempio blocchi piccoli possono dare una maggiore flessibilità nelle scritture dei SSD (e tra l’altro migliorare anche la durata delle celle). Ma molto dipende anche dalla dimensione dei blocchi ai livelli più alti.

Potrebbe essere invece meno importante se creare RAID0 multipli con un rapporto 1:1 rispetto ai dischi SSD oppure uno solo che aggreghi tutti i dischi. Spesso il secondo approccio può rivelarsi il migliore, ma anche qua è meglio verificare.

Come scritto sulle PERC, quando usate con SSD, le funzioni di caching si possono disabilitare per la maggior parte dei casi (Storage Pools, VSAN, PernixData), riguardo l’aggregazione dei volumi può invece aver senso usare più dischi logici in rapporto 1:1 se si usano gli Storage Pools, mentre è meglio usare un unico RAID0 per VSAN e PernixData (delegando al controller il compito di gestire il pool di dischi in modo aggregato).

Nel caso si utilizzi VMware bisogna poi marcare quindi dischi come di tipo SSD. In laboratorio viene fatto spesso per “imbrogliare” l’hypervisor, ma in questo caso per informarlo. L’articolo di KB 2013188 (Enabling the SSD option on SSD based disks/LUNs that are not detected as SSD by default) spiega nel dettaglio i passi richiesti. Prima di tutto bisogna prima attivare la CLI locale (o SSH) oppure installare la RCLI.

A questo punto si possono identificare i dischi o da CLI:

esxcli storage nmp device list

Oppure da GUI, l’importante è trovare il proprio SSD disk (la dimensione potrebbe essere di aiuto, ma anche la relativa LUN ID aiuta) e copiarsi il relativo indentificativo:

Questo identificativo può essere poi memorizzato in una variabile per poi riusarlo (in questo caso si suppone di usare la CLI locale):

SSD=naa.6848f690e805d6001ac6b293065d565

Questo script sistemerà poi il relativo disco:

esxcli storage nmp satp rule add --satp VMW_SATP_LOCAL --device $SSD --option "enable_local enable_ssd"
esxcli storage core claiming unclaim --type device --device $SSD
esxcli storage core claimrule load
esxcli storage core claiming reclaim -d $SSD
esxcli storage core claimrule run
esxcli storage core device list -d $SSD

Il disco sarà ora marcato come di tipo SSD ed utilizzabile da VSAN o da prodotti di caching come ad esempio quella di VMware o PernixData o altre.

Andrea Mauro

Virtualization, Cloud and Storage Architect. Tech Field delegate. VMUG IT Co-Founder and board member. VMware VMTN Moderator and vExpert 2010-24. Dell TechCenter Rockstar 2014-15. Microsoft MVP 2014-16. Veeam Vanguard 2015-23. Nutanix NTC 2014-20. Several certifications including: VCDX-DCV, VCP-DCV/DT/Cloud, VCAP-DCA/DCD/CIA/CID/DTA/DTD, MCSA, MCSE, MCITP, CCA, NPP.