In questo articolo vogliamo illustrare le caratteristiche degli array All Flash AccelStor con una delle piattaforme di virtualizzazione più popolari: VMware vSphere. In particolare, ci concentriamo su quei parametri che possono massimizzare l'efficacia dell'uso di uno strumento potente come l'All Flash.
Gli array All Flash AccelStor NeoSapphire™ sono o nodali basati su dischi SSD, con un approccio radicalmente diverso nella realizzazione della conservazione dei dati e nell'organizzazione dell'accesso a essi, utilizzando la propria tecnologia anziché i ben noti algoritmi RAID. Gli array offrono accesso a blocchi per gli host tramite interfacce Fibre Channel o iSCSI. È giusto notare che i modelli con interfaccia iSCSI hanno anche accesso ai file come piacevole bonus. Tuttavia, in questo articolo ci concentreremo sull'applicazione dei protocolli a blocchi, poiché sono i più performanti per All Flash.
L'intero processo di implementazione e successiva configurazione per la collaborazione tra l'array AccelStor e il sistema di virtualizzazione VMware vSphere può essere suddiviso in diverse fasi:
- Implementazione della topologia di rete e configurazione della rete SAN;
- Configurazione dell'array All Flash;
- Configurazione degli host ESXi;
- Configurazione delle macchine virtuali.
Per gli esempi sono stati utilizzati array AccelStor NeoSapphire™ con interfaccia Fibre Channel e interfaccia iSCSI. Come software di base – VMware vSphere 6.7U1.
Prima di implementare i sistemi descritti nell'articolo, è altamente consigliato consultare la documentazione di VMware riguardante le questioni di prestazioni ( ) e le impostazioni iSCSI ()
Topologia di rete e configurazione della rete SAN
I principali componenti di una rete SAN sono gli adattatori HBA negli host ESXi, gli switch SAN e i nodi dell'array. Una tipica topologia di tale rete appare così:
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'utilizzo di due switch indipendenti/Fabric permetterà di escludere una potenziale singola fonte di guasto.
Anche se la connessione diretta degli host all'array è supportata, non è fortemente raccomandata. Le prestazioni degli array All Flash sono abbastanza elevate e per raggiungere 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 è anche un requisito fondamentale per raggiungere le massime prestazioni e garantire l'affidabilità.
Nel caso di utilizzo dell'interfaccia Fibre Channel, è necessaria la configurazione del zoning per evitare possibili collisioni tra initiatori e target. Le zone sono costruite sul principio 'una porta initiatore – una o più porte dell'array'.
Se si utilizza una connessione iSCSI attraverso uno switch condiviso con altri servizi, è fondamentale isolare il traffico iSCSI all'interno di un VLAN dedicato. Inoltre, è altamente consigliato abilitare il supporto per Jumbo Frames (MTU = 9000) per aumentare le dimensioni dei pacchetti in rete e, in tal modo, ridurre la quantità di informazioni di overhead durante il trasferimento. Tuttavia, è importante ricordare che per un corretto funzionamento è necessario modificare il parametro MTU su tutti i componenti della rete nella catena "iniziatore-switch-target".
Impostazione di un array All Flash
L'array è consegnato ai clienti con gruppi già formati . Pertanto, non è necessario effettuare alcuna operazione per unire i dischi in un'unica struttura. È sufficiente creare volumi della dimensione richiesta e nel numero necessario.
Per comodità, è disponibile la funzionalità di creazione di più volumi di dimensioni specificate in un'unica operazione. Di default, vengono creati volumi 'thin', poiché ciò consente di utilizzare in modo più efficiente lo spazio di archiviazione disponibile (incluso il supporto per il Space Reclamation). Dal punto di vista delle prestazioni, la differenza tra volumi 'thin' e 'thick' è inferiore all'1%. Tuttavia, se è necessario 'estrarre il massimo' dalla matrice, è sempre possibile convertire qualsiasi volume 'thin' in 'thick'. Ma è importante ricordare che tale operazione non è reversibile.
Successivamente, rimane da 'pubblicare' i volumi creati e definire i diritti di accesso per essi da parte degli host utilizzando ACL (indirizzi IP per iSCSI e WWPN per FC) e la separazione fisica tramite le porte della matrice. Per i modelli iSCSI, ciò avviene tramite la creazione di un Target.
Per i modelli FC, la pubblicazione avviene tramite la creazione di LUN per ogni porta della matrice.
Per velocizzare il processo di configurazione, i host possono essere raggruppati. Inoltre, se sul host sono utilizzati HBA FC a più porte (cosa che avviene più frequentemente nella pratica), il sistema determina automaticamente che le porte di tale HBA appartengono a un unico host grazie al WWPN, che differisce di uno. Sono supportate anche creazioni batch di Target/LUN per entrambi gli interfaccia.
Un'importante considerazione nell'utilizzo dell'interfaccia iSCSI è la creazione di diversi target per i volumi per aumentare le prestazioni, poiché la coda su un target non può essere modificata e rappresenta effettivamente un collo di bottiglia.
Configurazione degli host ESXi
Dal lato degli host ESXi, la configurazione di base viene eseguita secondo uno scenario piuttosto previsto. L'ordine delle operazioni per la connessione iSCSI è:
- Aggiungere un Software iSCSI Adapter (non necessario se è già stato aggiunto o nel caso si utilizzi un Hardware iSCSI Adapter);
- Creare un vSwitch attraverso il quale passerà il traffico iSCSI e aggiungere a esso gli uplink fisici e il VMkernel;
- Aggiungere agli indirizzi dell'array nel Dynamic Discovery;
- Creare un Datastore
Alcune importanti considerazioni:
- In generale, è possibile utilizzare 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 distinti per evitare problemi di prestazioni.
- Gli indirizzi IP del VMkernel e le rispettive porte dell'array All Flash devono trovarsi all'interno della stessa sottorete, ancora una volta per questioni di prestazioni.
- Per garantire l'affidabilità secondo le regole VMware, il vSwitch deve avere almeno due uplink fisici.
- Se si utilizzano Jumbo Frames, è necessario modificare il MTU sia sul vSwitch che sul VMkernel.
- Vale la pena ricordare che, secondo le raccomandazioni VMware per gli adattatori fisici che verranno utilizzati per lavorare con il traffico iSCSI, è imprescindibile configurare il Teaming e il Failover. In particolare, ogni VMkernel deve funzionare attraverso un solo uplink, mentre il secondo uplink deve essere impostato su unused. Per garantire la ridondanza, è necessario aggiungere due VMkernel, ognuno dei quali funzionerà attraverso il proprio uplink.
VMkernel Adapter (vmk#)
Physical Network Adapter (vmnic#)
vmk1 (Storage01)
Active Adapters
vmnic2
Unused Adapters
vmnic3
vmk2 (Storage02)
Active Adapters
vmnic3
Unused Adapters
vmnic2
Per connettersi tramite Fibre Channel non è richiesta alcuna azione preliminare. È possibile creare immediatamente un Datastore.
Dopo aver creato il Datastore, è necessario assicurarsi che venga utilizzata la politica Round Robin per i percorsi verso il Target/LUN come la più performante.
Per impostazione predefinita, le impostazioni di VMware prevedono l'uso di questa politica secondo lo schema: 1000 richieste tramite il primo percorso, le successive 1000 richieste tramite il secondo percorso, e così via. Questo tipo di interazione dell'host con un array a due controller non sarà bilanciato. 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 Device Name
- Modificare la Round Robin Policy
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 grandi dimensioni per massimizzare l'utilizzo della larghezza di banda e ridurre il carico sulla CPU. Pertanto, ESXi, per impostazione predefinita, invia le richieste di input/output ai dispositivi di archiviazione in porzioni fino a 32767KB. Tuttavia, in alcuni scenari, lo scambio di porzioni più piccole può essere più efficiente. Per quanto riguarda gli array AccelStor, questi sono i seguenti scenari:
- La macchina virtuale utilizza UEFI invece del Legacy BIOS
- Viene utilizzata vSphere Replication
Per tali scenari, si raccomanda di modificare il parametro Disk.DiskMaxIOSize a 4096.
Per le connessioni iSCSI, si consiglia di impostare il parametro Login Timeout a 30 (impostazione predefinita 5) per aumentare la stabilità della connessione e disabilitare la conferma ritardata dei pacchetti inviati (DelayedAck). Entrambe le opzioni si trovano in vSphere Client: Host → Configura → Archiviazione → Adattatori di archiviazione → Opzioni avanzate per l'adattatore iSCSI
Un aspetto importante da considerare è il numero di volumi utilizzati per il datastore. È comprensibile che, per semplificare la gestione, si possa essere tentati di creare un grande volume per l'intero array. Tuttavia, avere più volumi e, di conseguenza, più datastore contribuisce positivamente alle prestazioni complessive (maggiori dettagli sulle code più avanti nel testo). Pertanto, raccomandiamo di creare almeno due volumi.
Fino a poco tempo fa, VMware consigliava di limitare il numero di macchine virtuali su un datastore con l'obiettivo di ottenere le massime prestazioni possibili. Tuttavia, ora, soprattutto con la diffusione del VDI, questa problematica non è più così critica. Ciò non elimina comunque la regola consolidata: distribuire le macchine virtuali che richiedono un I/O intenso tra diversi datastore. Per determinare il numero ottimale di VM su un volume, non c'è nulla di meglio che effettuare nell'ambito della propria infrastruttura.
Configurazione delle macchine virtuali
Non ci sono requisiti particolari per la configurazione delle macchine virtuali, a dire il vero sono piuttosto ordinari:
- Utilizzare la versione VM massima possibile (compatibilità)
- Fai attenzione a impostare la dimensione della RAM quando si dispone densamente le macchine virtuali, ad esempio in VDI (poiché di default al momento dell'avvio viene creato un file di swapping di dimensioni comparabili a quelle della RAM, il che consuma capacità utile e influisce sulle prestazioni finali)
- Utilizzare le versioni degli adattatori più performanti per quanto riguarda IO: tipo di rete VMXNET 3 e SCSI tipo PVSCSI
- Utilizzare il tipo di disco Thick Provision Eager Zeroed per la massima prestazione e il Thin Provisioning per un uso dello spazio di archiviazione il più efficace possibile
- Limitare il funzionamento delle macchine non critiche per I/O utilizzando il Virtual Disk Limit, se possibile
- Assicurati di installare VMware Tools
Osservazioni sulle code
La coda (o Outstanding I/Os) è il numero di richieste di input/output (comandi SCSI) che attendono di essere elaborate in un dato momento da un dispositivo/applicazione specifici. In caso di overflow della coda, viene emesso un errore QFULL, che si traduce in un aumento del parametro di latenza. Utilizzando sistemi di storage a disco (spindle), teoricamente, maggiore è la coda, migliore è la loro performance. Tuttavia, non bisogna abusarne, poiché si rischia di incorrere in QFULL. Nel caso dei sistemi All Flash, da un lato, è tutto un po' più semplice: poiché l'array ha latenze di ordini di grandezza inferiori, di solito non è necessario regolare separatamente la dimensione delle code. D'altro canto, in alcuni scenari di utilizzo (forte sbilanciamento nella richiesta di IO per macchine virtuali specifiche, test di massimo rendimento, ecc.) è necessario non solo modificare i parametri delle code, ma anche comprendere quali risultati possono essere raggiunti e, soprattutto, quali sono i percorsi da seguire.
Nell'array AccelStor All Flash non ci sono limiti riguardo ai volumi o alle porte di input/output. Se necessario, anche un singolo volume può ottenere tutte le risorse dell'array. L'unico limite sulle code è imposto dai target iSCSI. Per questo motivo, è stata evidenziata la necessità di creare più target (ideale fino a 8) per ogni volume per superare questo limite. Ricordiamo anche che gli array AccelStor sono soluzioni altamente performanti. Pertanto, è consigliabile utilizzare tutte le porte della sistema per raggiungere la massima velocità.
Dal lato dell'host ESXi, la situazione è completamente diversa. L'host stesso applica una pratica di accesso equo alle risorse per tutti i partecipanti. Pertanto, esistono code IO separate per il sistema operativo guest e l'HBA. Le code per il sistema operativo guest sono una combinazione delle code per l'adattatore SCSI virtuale e il disco virtuale:
La coda per l'HBA dipende dal tipo/vendor specifico:
Le prestazioni finali della macchina virtuale saranno determinate dal valore minimo del limite della profondità della coda (Queue Depth limit) tra i componenti dell'host.
Grazie a questi valori, è possibile valutare le prestazioni che possiamo ottenere in una configurazione specifica. Ad esempio, vogliamo conoscere le prestazioni teoriche di una macchina virtuale (senza vincoli sul blocco) con una latenza di 0,5 ms. Quindi, le sue IOPS = (1.000 / latenza) * I/O in sospeso (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. Quindi, le 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 è già determinato dall'Adattatore SCSI Paravirtual. Quindi, le IOPS = (1000 / 0,5) * 64 = 128K
I modelli di punta delle array All Flash AccelStor (ad esempio, ) possono fornire prestazioni di 700K IOPS in scrittura con un blocco di 4K. Con questa dimensione di blocco è evidente che una singola macchina virtuale non è in grado di saturare tale array. Per farlo, serviranno 11 (per esempio 1) o 6 (per esempio 2) virtual machine.
Di conseguenza, 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% Lettura / 30% Scrittura
In realtà, il mondo è molto più complesso da descrivere con una formula semplice. Su un host sono sempre presenti molte macchine virtuali con varie configurazioni e requisiti di I/O. Inoltre, il processore dell'host gestisce l'input/output, le cui capacità non sono infinite. Pertanto, per sfruttare appieno il potenziale della stessa in realtà avremo bisogno di tre host. Inoltre, le applicazioni che operano all'interno delle macchine virtuali apportano le loro correzioni. Per questo motivo, per una corretta dimensionamento, suggeriamo All Flash array all'interno dell'infrastruttura del cliente su compiti attuali reali.
Fonte: habr.com
