In questo articolo vorrei parlare delle funzionalità degli array All Flash AccelStor che funzionano con una delle piattaforme di virtualizzazione più popolari: VMware vSphere. In particolare, concentrati su quei parametri che ti aiuteranno a ottenere il massimo effetto dall'utilizzo di uno strumento così potente come All Flash.
Gli array AccelStor NeoSapphire™ All Flash lo sono
L'intero processo di implementazione e successiva configurazione del funzionamento congiunto dell'array AccelStor e del sistema di virtualizzazione VMware vSphere può essere suddiviso in più fasi:
- Implementazione della topologia di connessione e configurazione della rete SAN;
- Configurazione dell'array All Flash;
- Configurazione degli host ESXi;
- Configurazione di macchine virtuali.
Come hardware campione sono stati utilizzati gli array Fibre Channel AccelStor NeoSapphire™ e gli array iSCSI. Il software di base è VMware vSphere 6.7U1.
Prima di distribuire i sistemi descritti in questo articolo, si consiglia vivamente di leggere la documentazione di VMware relativa ai problemi di prestazioni (
Topologia di connessione e configurazione della rete SAN
I componenti principali di una rete SAN sono gli HBA negli host ESXi, gli switch SAN e i nodi array. Una tipica topologia per una rete di questo tipo sarebbe simile alla seguente:
Il termine Switch qui si riferisce sia a uno switch fisico separato o a un insieme di switch (Fabric), sia a un dispositivo condiviso tra diversi servizi (VSAN nel caso di Fibre Channel e VLAN nel caso di iSCSI). L'utilizzo di due interruttori/tessuti indipendenti eliminerà un possibile punto di guasto.
La connessione diretta degli host all'array, sebbene supportata, è altamente sconsigliata. Le prestazioni degli array All Flash sono piuttosto elevate. E per la massima velocità è necessario utilizzare tutte le porte dell'array. Pertanto, è obbligatoria la presenza di almeno uno switch tra gli host e NeoSapphire™.
Anche la presenza di due porte sull'HBA host è un requisito obbligatorio per ottenere le massime prestazioni e garantire la tolleranza agli errori.
Quando si utilizza un'interfaccia Fibre Channel, la zonizzazione deve essere configurata per eliminare possibili collisioni tra iniziatori e obiettivi. Le zone sono costruite secondo il principio “una porta iniziatore – una o più porte array”.
Se si utilizza una connessione tramite iSCSI nel caso di utilizzo di uno switch condiviso con altri servizi, è imperativo isolare il traffico iSCSI all'interno di una VLAN separata. Si consiglia inoltre vivamente di abilitare il supporto per Jumbo Frames (MTU = 9000) per aumentare la dimensione dei pacchetti sulla rete e quindi ridurre la quantità di informazioni generali durante la trasmissione. È bene però ricordare che per un corretto funzionamento è necessario modificare il parametro MTU su tutti i componenti di rete lungo la catena “iniziatore-switch-target”.
Configurazione dell'array All Flash
L'array viene consegnato ai clienti con gruppi già formati
Per comodità, è disponibile la funzionalità per la creazione batch di più volumi di una determinata dimensione contemporaneamente. Per impostazione predefinita, vengono creati volumi thin, poiché ciò consente un utilizzo più efficiente dello spazio di archiviazione disponibile (incluso il supporto per Space Reclamation). In termini di performance, la differenza tra volumi “thin” e “thick” non supera l’1%. Tuttavia, se vuoi “spremere tutto il succo” da un array, puoi sempre convertire qualsiasi volume “sottile” in uno “spesso”. Ma va ricordato che tale operazione è irreversibile.
Successivamente, resta da "pubblicare" i volumi creati e impostare i diritti di accesso ad essi dagli host utilizzando ACL (indirizzi IP per iSCSI e WWPN per FC) e separazione fisica tramite porte dell'array. Per i modelli iSCSI ciò avviene creando una destinazione.
Per i modelli FC la pubblicazione avviene tramite la creazione di una LUN per ciascuna porta dell'array.
Per accelerare il processo di configurazione, gli host possono essere combinati in gruppi. Inoltre, se l'host utilizza un HBA FC multiporta (cosa che in pratica accade più spesso), il sistema determina automaticamente che le porte di tale HBA appartengono a un unico host grazie a WWPN che differiscono di uno. Per entrambe le interfacce è supportata anche la creazione batch di Target/LUN.
Una nota importante quando si utilizza l'interfaccia iSCSI consiste nel creare più destinazioni per i volumi contemporaneamente per aumentare le prestazioni, poiché la coda sulla destinazione non può essere modificata e costituirà effettivamente un collo di bottiglia.
Configurazione degli host ESXi
Sul lato host ESXi, la configurazione di base viene eseguita secondo uno scenario completamente previsto. Procedura per la connessione iSCSI:
- Aggiungi l'adattatore iSCSI software (non necessario se è già stato aggiunto o se stai utilizzando l'adattatore iSCSI hardware);
- Creazione di un vSwitch attraverso il quale passerà il traffico iSCSI e aggiunta di un uplink fisico e VMkernal;
- Aggiunta di indirizzi di array a Dynamic Discovery;
- Creazione dell'archivio dati
Alcune note importanti:
- In generale, ovviamente, è possibile utilizzare un vSwitch esistente, ma nel caso di un vSwitch separato, la gestione delle impostazioni dell'host sarà molto 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 del VMkernal e le porte corrispondenti dell'array All Flash devono trovarsi all'interno della stessa sottorete, sempre a causa di problemi di prestazioni.
- Per garantire la tolleranza agli errori secondo le regole VMware, vSwitch deve avere almeno due uplink fisici
- Se vengono utilizzati Jumbo Frames, è necessario modificare la MTU sia di vSwitch che di VMkernal
- Sarebbe utile ricordare che secondo le raccomandazioni VMware per gli adattatori fisici che verranno utilizzati per funzionare con il traffico iSCSI, è necessario configurare Teaming e Failover. In particolare, ogni VMkernal deve funzionare attraverso un solo uplink, il secondo uplink deve essere commutato in modalità non utilizzata. Per la tolleranza agli errori, è necessario aggiungere due VMkernal, ognuno dei quali funzionerà tramite il proprio uplink.
Adattatore VMkernel (vmk#)
Adattatore di rete fisica (vmnic#)
VMK1 (Archiviazione01)
Adattatori attivi
vmnic2
Adattatori non utilizzati
vmnic3
VMK2 (Archiviazione02)
Adattatori attivi
vmnic3
Adattatori non utilizzati
vmnic2
Non sono necessari passaggi preliminari per connettersi tramite Fibre Channel. Puoi creare immediatamente un Datastore.
Dopo aver creato il Datastore, è necessario assicurarsi che la policy Round Robin per i percorsi verso la destinazione/LUN sia utilizzata come la più performante.
Per impostazione predefinita, le impostazioni di VMware prevedono l'utilizzo di questa policy secondo lo schema: 1000 richieste tramite il primo percorso, le successive 1000 richieste tramite il secondo percorso, ecc. Tale interazione tra l'host e l'array a due controller sarà sbilanciata. Pertanto si consiglia di impostare il parametro Round Robin policy = 1 tramite Esxcli/PowerCLI.
Parametri
Per Esxcli:
- Elenca i LUN disponibili
Elenco dei dispositivi NMP di archiviazione esxcli
- Copia nome dispositivo
- Cambiare la politica del Round Robin
esxcli storage nmp psp roundrobin deviceconfig set —type=iops —iops=1 —device=“ID_dispositivo”
La maggior parte delle applicazioni moderne sono progettate per scambiare pacchetti di dati di grandi dimensioni al fine di massimizzare l'utilizzo della larghezza di banda e ridurre il carico della CPU. Pertanto, ESXi per impostazione predefinita invia richieste I/O al dispositivo di archiviazione in blocchi fino a 32767 KB. Tuttavia, per alcuni scenari, lo scambio di blocchi più piccoli sarà più produttivo. Per gli array AccelStor, questi sono i seguenti scenari:
- La macchina virtuale utilizza UEFI invece del BIOS legacy
- Utilizza la replica vSphere
Per tali scenari, si consiglia di modificare il valore del parametro Disk.DiskMaxIOSize su 4096.
Per le connessioni iSCSI, si consiglia di modificare il parametro Login Timeout su 30 (valore predefinito 5) per aumentare la stabilità della connessione e disattivare il ritardo DelayedAck per le conferme dei pacchetti inoltrati. Entrambe le opzioni sono in vSphere Client: Host → Configura → Archiviazione → Adattatori di archiviazione → Opzioni avanzate per adattatore iSCSI
Un punto piuttosto delicato è il numero di volumi utilizzati per il datastore. È chiaro che per facilità di gestione si desidera creare un unico grande volume per l'intero volume dell'array. Tuttavia, la presenza di più volumi e, di conseguenza, del datastore ha un effetto benefico sulle prestazioni complessive (maggiori informazioni sulle code di seguito). Pertanto, consigliamo di creare almeno due volumi.
Fino a tempi relativamente recenti, VMware consigliava di limitare il numero di macchine virtuali su un datastore, sempre per ottenere le massime prestazioni possibili. Tuttavia ora, soprattutto con la diffusione della VDI, questo problema non è più così acuto. Ma ciò non annulla la regola di lunga data: distribuire macchine virtuali che richiedono I/O intensivo su diversi datastore. Per determinare il numero ottimale di macchine virtuali per volume, non c'è niente di meglio di
Configurazione di macchine virtuali
Non ci sono requisiti particolari per la configurazione delle macchine virtuali, o meglio sono abbastanza ordinari:
- Utilizzando la versione VM più alta possibile (compatibilità)
- È più attento impostare la dimensione della RAM quando si posizionano macchine virtuali in modo denso, ad esempio in VDI (poiché per impostazione predefinita, all'avvio, viene creato un file di paging di dimensioni commisurate alla RAM, che consuma capacità utile e ha un effetto su lo spettacolo finale)
- Utilizzare le versioni dell'adattatore più produttive in termini di IO: tipo di rete VMXNET 3 e tipo SCSI PVSCSI
- Utilizza il tipo di disco Thick Provision Eager Zeroed per le massime prestazioni e Thin Provisioning per il massimo utilizzo dello spazio di archiviazione
- Se possibile, limitare il funzionamento delle macchine non critiche per l'I/O utilizzando il limite del disco virtuale
- Assicurati di installare VMware Tools
Note sulle code
La coda (o I/O in sospeso) è il numero di richieste di input/output (comandi SCSI) in attesa di elaborazione in un dato momento per un dispositivo/applicazione specifica. In caso di overflow della coda vengono emessi errori QFULL che alla fine comportano un aumento del parametro di latenza. Quando si utilizzano sistemi di archiviazione su disco (mandrino), in teoria, maggiore è la coda, maggiori saranno le loro prestazioni. Non bisogna però abusarne, poiché è facile imbattersi in QFULL. Nel caso dei sistemi All Flash, da un lato, tutto è un po 'più semplice: dopotutto, l'array ha latenze inferiori di ordini di grandezza e quindi, molto spesso, non è necessario regolare separatamente la dimensione delle code. D'altra parte, in alcuni scenari di utilizzo (forte distorsione dei requisiti IO per macchine virtuali specifiche, test per le massime prestazioni, ecc.) è necessario, se non modificare i parametri delle code, almeno capire quali indicatori può essere raggiunto e la cosa principale è in che modo.
Sull'array AccelStor All Flash stesso non ci sono limiti in relazione ai volumi o alle porte I/O. Se necessario, anche un singolo volume può ricevere tutte le risorse dell'array. L'unica limitazione sulla coda riguarda le destinazioni iSCSI. È per questo motivo che sopra è stata indicata la necessità di creare più target (idealmente fino a 8 pezzi) per ciascun volume per superare questo limite. Ripetiamo anche che gli array AccelStor sono soluzioni molto produttive. Pertanto, è necessario utilizzare tutte le porte di interfaccia del sistema per ottenere la massima velocità.
Lato host ESXi la situazione è completamente diversa. L'host stesso applica la pratica della parità di accesso alle risorse per tutti i partecipanti. Pertanto, sono presenti code di I/O separate per il sistema operativo guest e l'HBA. Le code al sistema operativo guest vengono combinate dalle code all'adattatore SCSI virtuale e al disco virtuale:
La coda all'HBA dipende dal tipo/fornitore specifico:
Le prestazioni finali della macchina virtuale saranno determinate dal limite di profondità della coda più basso tra i componenti host.
Grazie a questi valori possiamo valutare gli indicatori di prestazione che possiamo ottenere in una particolare configurazione. Ad esempio, vogliamo conoscere le prestazioni teoriche di una macchina virtuale (senza collegamento a blocchi) con una latenza di 0.5 ms. Quindi i suoi IOPS = (1,000/latenza) * I/O eccezionali (limite di profondità della coda)
Примеры
esempio 1
- Adattatore HBA FC Emulex
- Una VM per archivio dati
- Adattatore SCSI paravirtuale VMware
Qui il limite di profondità della coda è determinato da Emulex HBA. Pertanto IOPS = (1000/0.5)*32 = 64K
esempio 2
- Adattatore software iSCSI VMware
- Una VM per archivio dati
- Adattatore SCSI paravirtuale VMware
In questo caso il limite della profondità della coda è già determinato dall'adattatore SCSI paravirtuale. Pertanto IOPS = (1000/0.5)*64 = 128K
I principali modelli di array All Flash AccelStor (ad esempio,
Di conseguenza, con la corretta configurazione di tutti i componenti descritti di un data center virtuale, è possibile ottenere risultati davvero impressionanti in termini di prestazioni.
4K casuale, 70% lettura/30% scrittura
In effetti, il mondo reale è molto più complesso di quanto possa essere descritto con una semplice formula. Un host ospita sempre più macchine virtuali con diverse configurazioni e requisiti di I/O. Inoltre, l'elaborazione I/O è gestita dal processore host, la cui potenza non è infinita. Quindi, per sbloccare tutto il potenziale dello stesso
Fonte: habr.com