In questo articolo, desideriamo discutere le peculiarità del lavoro con i sistemi All Flash AccelStor su una delle piattaforme di virtualizzazione più popolari – VMware vSphere. In particolare, vogliamo evidenziare quei parametri che aiuteranno a ottenere il massimo effetto dall'uso di uno strumento così potente come All Flash.
I sistemi All Flash AccelStor NeoSapphire™ rappresentano o dispositivo a nodo singolo basato su SSD con un approccio radicalmente diverso nella realizzazione del concetto di archiviazione dei dati e organizzazione dell'accesso ad essi attraverso l'uso di tecnologia proprietaria invece di algoritmi RAID piuttosto popolari. I sistemi offrono accesso blocchi per gli host tramite interfacce Fibre Channel o iSCSI. Per essere giusti, notiamo che i modelli con interfaccia iSCSI hanno anche accesso file come un piacevole bonus. Tuttavia, in questo articolo ci concentriamo sull'implementazione di protocolli a blocchi, ritenuti i più performanti per All Flash.
L'intero processo di installazione e configurazione successiva della cooperazione tra il sistema AccelStor e la piattaforma di virtualizzazione VMware vSphere può essere suddiviso in diverse fasi:
- Implementazione della topologia di connessione e configurazione della rete SAN;
- Configurazione del sistema All Flash;
- Configurazione degli host ESXi;
- Configurazione delle macchine virtuali.
Come attrezzatura per gli esempi sono stati utilizzati i sistemi AccelStor NeoSapphire™ con interfaccia Fibre Channel e con interfaccia iSCSI. Come software di base – VMware vSphere 6.7U1.
Prima di procedere all'installazione dei sistemi descritti nell'articolo, si raccomanda vivamente di consultare la documentazione di VMware riguardante le questioni di prestazioni ( ) e le impostazioni iSCSI ()
Topologia di connessione e configurazione della rete SAN
I principali componenti della rete SAN sono gli adattatori HBA negli host ESXi, gli switch SAN e i nodi del sistema. Una topologia tipica di tale rete apparirà come segue:
Con il termine Switch si intende sia un singolo switch fisico o un insieme di switch (Fabric), sia un dispositivo condiviso tra diversi servizi (VSAN nel caso di Fibre Channel e VLAN nel caso di iSCSI). L'uso di due switch/Fabric indipendenti permetterà di eliminare una potenziale singola punto di guasto.
Sebbene il collegamento diretto degli host al array sia supportato, non è assolutamente raccomandato. Le prestazioni degli array All Flash sono piuttosto elevate. Per ottenere la massima velocità, è necessario utilizzare tutte le porte dell'array. Pertanto, è essenziale avere almeno uno switch tra gli host e NeoSapphire™.
La presenza di due porte sull'HBA dell'host è un requisito obbligatorio per raggiungere le massime prestazioni e garantire la resilienza.
Nel caso di utilizzo dell'interfaccia Fibre Channel, è necessaria una configurazione di zoning per escludere possibili collisioni tra initiatori e target. Le zone sono costruite secondo il principio 'una porta dell'initiator – una o più porte dell'array'.
Se si utilizza il collegamento tramite iSCSI e si impiega uno switch condiviso con altri servizi, è assolutamente necessario isolare il traffico iSCSI all'interno di un VLAN separato. È anche fortemente raccomandato abilitare il supporto per Jumbo Frames (MTU = 9000) per aumentare le dimensioni dei pacchetti in rete e, di conseguenza, ridurre la quantità di informazioni di overhead durante la trasmissione. Tuttavia, è importante ricordare che per un corretto funzionamento è necessario modificare il parametro MTU su tutti i componenti della rete nella catena 'initiator-switch-target'.
Configurazione dell'array All Flash
L'array viene fornito ai clienti con gruppi già formati . Pertanto, non è necessario eseguire alcuna operazione per unire i dispositivi di archiviazione in un'unica struttura. È sufficiente creare volumi della dimensione richiesta e nel numero necessario.
Per comodità, è disponibile la funzionalità di creazione batch di più volumi di dimensioni specificate. Di default vengono creati volumi 'thin', poiché questo consente di utilizzare in modo più razionale lo spazio di archiviazione disponibile (anche grazie al supporto dello Space Reclamation). Dal punto di vista delle prestazioni, la differenza tra volumi 'thin' e 'thick' non supera l'1%. Tuttavia, se è necessario 'estrarre il massimo' dall'array, è sempre possibile convertire qualsiasi volume 'thin' in 'thick'. Ma bisogna ricordare che tale operazione è irreversibile.
Successivamente, è necessario "pubblicare" i volumi creati e impostare i diritti di accesso ad essi da parte degli host utilizzando ACL (indirizzi IP per iSCSI e WWPN per FC) e la separazione fisica delle porte del array. Per i modelli iSCSI, questo viene fatto creando un Target.
Per i modelli FC, la pubblicazione avviene attraverso la creazione di LUN per ogni porta dell'array.
Per accelerare il processo di configurazione, gli host possono essere raggruppati. Infatti, se su un host viene utilizzato un HBA FC multiporta (cosa che accade più frequentemente in pratica), il sistema riconosce automaticamente che le porte di tale HBA appartengono a un unico host grazie a WWPN, che differiscono di uno. Inoltre, per entrambi gli interfacce è supportata la creazione batch di Target/LUN.
Un'importante osservazione nel caso si utilizzi l'interfaccia iSCSI è la creazione di più target per i volumi per aumentare le prestazioni, poiché la coda su un target non può essere modificata e sarà effettivamente un collo di bottiglia.
Configurazione degli host ESXi
Dal lato degli host ESXi, la configurazione di base viene eseguita secondo un copione piuttosto prevedibile. L'ordine delle operazioni per la connessione iSCSI è:
- Aggiungere un Software iSCSI Adapter (non necessario se è già stato aggiunto, o in caso di utilizzo di Hardware iSCSI Adapter);
- Creare un vSwitch, attraverso il quale passerà il traffico iSCSI, e aggiungere al suo interno uplink fisici e VMkernel;
- Aggiungere agli indirizzi dell'array nella Dynamic Discovery;
- Creazione di un Datastore
Alcuni importanti chiarimenti:
- In generale, è possibile utilizzare anche un vSwitch esistente, ma nel caso di un vSwitch separato, la gestione delle impostazioni dell'host sarà notevolmente più semplice.
- È necessario separare il traffico di gestione e iSCSI su collegamenti fisici e/o VLAN separati per evitare problemi di prestazioni.
- Gli indirizzi IP di VMkernel e delle relative porte dell'array All Flash devono trovarsi all'interno della stessa subnet, ancora una volta per motivi di prestazioni.
- Per garantire l'affidabilità secondo le regole VMware, il vSwitch deve avere almeno due uplink fisici.
- Se vengono utilizzati Jumbo Frames, è necessario modificare l'MTU sia su vSwitch che su VMkernel.
- Non sarà superfluo ricordare che, secondo le raccomandazioni di VMware per gli adattatori fisici che saranno utilizzati per gestire il traffico iSCSI, è obbligatorio configurare il Teaming e il Failover. In particolare, ogni VMkernel deve funzionare solo attraverso un uplink, mentre il secondo uplink deve essere impostato su modalità unused. Per garantire l'affidabilità, è necessario aggiungere due VMkernel, ognuno dei quali funzionerà attraverso il proprio uplink.
Adapter VMkernel (vmk#)
Adapter di rete fisico (vmnic#)
vmk1 (Storage01)
Adattatori attivi
vmnic2
Adattatori non utilizzati
vmnic3
vmk2 (Storage02)
Adattatori attivi
vmnic3
Adattatori non utilizzati
vmnic2
Per la connessione tramite Fibre Channel non è necessario alcun intervento preliminare. È possibile iniziare subito a creare il Datastore.
Dopo aver creato il Datastore, è importante assicurarsi che sia utilizzata la politica Round Robin per i percorsi verso il Target/LUN, poiché è la più performante.
Per impostazione predefinita, le configurazioni di VMware prevedono l'uso di questa politica secondo lo schema: 1000 richieste attraverso il primo percorso, le successive 1000 richieste attraverso il secondo percorso, e così via. Questo tipo di interazione dell'host con un array a due controller sarà sbilanciato. Pertanto, si consiglia di impostare il parametro Round Robin policy = 1 tramite Esxcli/PowerCLI.
Parametri
Per Esxcli:
- Elencare i LUN disponibili
esxcli storage nmp device list
- Copiare il nome del dispositivo
- Modificare la politica Round Robin
esxcli storage nmp psp roundrobin deviceconfig set —type=iops —iops=1 —device=«Device_ID»
La maggior parte delle applicazioni moderne è progettata per scambiare pacchetti di dati di grandi dimensioni, al fine di massimizzare l'utilizzo della larghezza di banda e ridurre il carico sulla CPU. Pertanto, ESXi per impostazione predefinita trasmette richieste di input/output ai dispositivi di archiviazione in porzioni fino a 32767KB. Tuttavia, per alcuni scenari, lo scambio di porzioni più piccole risulta più performante. In relazione agli array AccelStor, questi scenari sono:
- La macchina virtuale utilizza UEFI invece del Legacy BIOS
- È in uso vSphere Replication
Per tali scenari, si raccomanda di modificare il valore del parametro Disk.DiskMaxIOSize a 4096.
Per le connessioni iSCSI, si consiglia di modificare il parametro Login Timeout a 30 (di default 5) per aumentare la stabilità della connessione e disattivare il ritardo delle conferme dei pacchetti inviate DelayedAck. Entrambe le opzioni si trovano nel vSphere Client: Host → Configura → Storage → Storage Adapters → Opzioni avanzate per l'adattatore iSCSI.
Un aspetto abbastanza delicato è il numero di volumi utilizzati per il datastore. È chiaro che, per semplificare la gestione, si ha la tentazione di creare un unico grande volume per l'intero array. Tuttavia, avere più volumi e, di conseguenza, più datastore ha un effetto positivo sulle prestazioni generali (ne parleremo più in dettaglio nelle sezioni successive). Pertanto, raccomandiamo di creare almeno due volumi.
Fino a poco tempo fa, VMware consigliava di limitare il numero di macchine virtuali su un singolo datastore sempre con l'obiettivo di ottenere le massime prestazioni possibili. Tuttavia, attualmente, soprattutto con la diffusione del VDI, questo problema non è più così pressante. Ma ciò non annulla la regola di fondo: distribuire le macchine virtuali ad alta intensità di I/O su diversi datastore. Per determinare il numero ottimale di macchine virtuali su un volume, non c'è niente di meglio che effettuare all'interno della propria infrastruttura.
Configurazione delle macchine virtuali
Nella configurazione delle macchine virtuali non ci sono requisiti particolari, anzi, sono piuttosto ordinari:
- Utilizzare la versione VM massima possibile (compatibilità)
- Prestare attenzione nella definizione della dimensione della RAM in caso di elevata densità di macchine virtuali, ad esempio, in VDI (poiché per impostazione predefinita all'avvio viene creato un file di paging di dimensioni comparabili a quelle della RAM, il che consuma spazio utile e influisce sulle prestazioni finali)
- Utilizzare le versioni degli adattatori più performanti in termini di I/O: rete tipo VMXNET 3 e SCSI tipo PVSCSI
- Utilizzare il tipo di disco Thick Provision Eager Zeroed per le massime prestazioni e Thin Provisioning per un utilizzo ottimale dello spazio di archiviazione
- Limitare, se possibile, il funzionamento di macchine non critiche per l'I/O tramite Virtual Disk Limit
- Assicurarsi di installare VMware Tools
Osservazioni sulle code
La coda (o Outstanding I/Os) è il numero di richieste di input/output (comandi SCSI) in attesa di elaborazione in ogni momento su un dispositivo/applicazione specifica. In caso di overflow della coda, si verifica un errore QFULL, che si traduce in un aumento della latenza. Nell'uso di sistemi di storage su disco (spindles), teoricamente più alta è la coda, maggiore è la loro performance. Tuttavia, non bisogna esagerare, poiché è facile incorrere in un QFULL. Nel caso dei sistemi All Flash, da un lato, tutto è un po' più semplice: infatti, la matrice ha latenze di ordini di grandezza inferiori e quindi di solito non è necessario regolare separatamente la dimensione delle code. Dall'altro lato, in alcuni scenari d'uso (forti sbilanciamenti nei requisiti di IO per macchine virtuali specifiche, test di massima performance, ecc.), è necessario, se non modificare i parametri delle code, almeno comprendere quali risultati possono essere raggiunti e, soprattutto, quali percorsi seguire.
Nella stessa matrice All Flash AccelStor non ci sono limiti riguardo ai volumi o alle porte di input/output. Se necessario, anche un singolo volume può ricevere tutte le risorse della matrice. L'unico vincolo sulle code è presente per gli iSCSI target. Proprio per questo motivo si è sottolineata in precedenza la necessità di creare più (idealmente fino a 8) target per ogni volume per superare questo limite. Ripetiamo anche che le matrici AccelStor sono soluzioni altamente performanti. Pertanto, è consigliabile utilizzare tutte le porte di interfaccia del sistema per raggiungere la massima velocità.
Dal punto di vista dell'host ESXi, la situazione è completamente diversa. L'host stesso applica la pratica di accesso equo alle risorse per tutti i soggetti. Pertanto, esistono code IO separate per il sistema operativo guest e l'HBA. Le code verso il sistema operativo guest sono combinate da quelle verso l'adattatore SCSI virtuale e il disco virtuale:
La coda verso l'HBA dipende dal tipo/venditore specifico:
Le performance finali della macchina virtuale saranno determinate dal valore più basso del limite della coda (Queue Depth limit) tra i componenti dell'host.
Grazie a questi valori, è possibile valutare le prestazioni che possiamo ottenere in una determinata configurazione. Ad esempio, vogliamo conoscere le prestazioni teoriche di una macchina virtuale (senza legame con il blocco) con una latenza di 0,5 ms. Allora il suo IOPS = (1.000/latency) * Outstanding I/Os (limite di profondità della coda)
Esempi
Esempio 1
- Adattatore HBA FC Emulex
- Una VM su datastore
- Adattatore SCSI Paravirtual VMware
Qui il limite di profondità della coda è determinato dall'HBA Emulex. Pertanto IOPS = (1000/0,5)*32 = 64K
Esempio 2
- Adattatore software iSCSI VMware
- Una VM su datastore
- Adattatore SCSI Paravirtual VMware
Qui il limite di profondità della coda è determinato dall'Adattatore SCSI Paravirtual. Pertanto IOPS = (1000/0,5)*64 = 128K
I modelli di punta dei sistemi All Flash di AccelStor (ad esempio, ) sono in grado di garantire prestazioni di 700K IOPS in scrittura con un blocco di 4K. Con questa dimensione del blocco, è evidente che una singola macchina virtuale non riesce a caricare un sistema simile. Per questo ci vorranno 11 (per esempio 1) o 6 (per esempio 2) macchine virtuali.
In definitiva, con una corretta configurazione di tutti i componenti descritti del data center virtuale, è possibile ottenere risultati molto impressionanti in termini di prestazioni.
4K Random, 70% Read/30% Write
In realtà, il mondo reale è molto più complesso da descrivere con una semplice formula. Su un host ci sono sempre molte macchine virtuali con diverse configurazioni e requisiti di IO. Inoltre, il processore dell'host gestisce l'input/output, la cui potenza non è infinita. Quindi, per sbloccare il pieno potenziale di quel in realtà saranno necessari tre host. Inoltre, le applicazioni che operano all'interno delle macchine virtuali apportano le loro correzioni. Pertanto, per un dimensionamento preciso, suggeriamo sistemi All Flash all'interno dell'infrastruttura del cliente su compiti attuali reali.
Fonte: habr.com
