In questu articulu, vogliu parlà di e caratteristiche di All Flash AccelStor arrays chì travaglianu cù una di e plataforme di virtualizazione più populari - VMware vSphere. In particulare, fucalizza nantu à quelli paràmetri chì vi aiuteranu à ottene u massimu effettu da aduprà un strumentu cusì putente cum'è All Flash.
AccelStor NeoSapphire™ Tutti i array Flash sò o Dispositivi di nodu basati in unità SSD cù un approcciu fundamentale differente per implementà u cuncettu di almacenamiento di dati è urganizà l'accessu à questu utilizendu tecnulugia proprietaria invece di l'algoritmi RAID assai populari. L'array furnisce l'accessu di bloccu à l'ospiti via Fibre Channel o interfacce iSCSI. Per esse ghjustu, avemu nutatu chì i mudelli cù una interfaccia ISCSI anu ancu accessu à u schedariu cum'è un bonu bonu. Ma in questu articulu avemu da fucalizza nantu à l'usu di protokolli di bloccu cum'è u più pruduttivu per All Flash.
Tuttu u prucessu di implementazione è a cunfigurazione successiva di l'operazione cumuna di l'array AccelStor è u sistema di virtualizazione VMware vSphere pò esse divisu in parechje tappe:
- Implementazione di a topologia di cunnessione è a cunfigurazione di a rete SAN;
- Configurazione di l'array All Flash;
- Configurazione di l'ospiti ESXi;
- Configurazione di macchine virtuali.
L'arrays AccelStor NeoSapphire ™ Fibre Channel è l'arrays iSCSI sò stati usati cum'è hardware di mostra. U software di basa hè VMware vSphere 6.7U1.
Prima di implementà i sistemi descritti in questu articulu, hè altamente cunsigliatu di leghje a documentazione di VMware in quantu à i prublemi di rendiment ( ) è paràmetri iSCSI ()
Topulugia di cunnessione è cunfigurazione di a rete SAN
I cumpunenti principali di una rete SAN sò HBA in host ESXi, switch SAN è nodi di array. Una topulugia tipica per una tale rete parerebbe cusì:
U terminu Cambia quì si riferisce à un cambiamentu fisicu separatu o un set di switches (Fabric), è à un dispositivu spartutu trà i diversi servizii (VSAN in u casu di Fibre Channel è VLAN in u casu di iSCSI). Utilizà dui interruttori / Tessuti indipindenti eliminerà un pussibbili puntu di fallimentu.
A cunnessione diretta di l'ospiti à l'array, ancu s'ellu hè supportata, hè assai sconsigliata. U rendiment di All Flash arrays hè abbastanza altu. È per a velocità massima, tutti i porti di l'array deve esse usatu. Dunque, a presenza di almenu un cambiamentu trà l'ospiti è NeoSapphire™ hè obligatoriu.
A prisenza di dui porti nantu à l'ospite HBA hè ancu un requisitu obligatoriu per ottene u massimu rendimentu è assicurà a tolleranza di difetti.
Quandu s'utilice una interfaccia di Fibre Channel, a zonificazione deve esse cunfigurata per eliminà pussibuli collisioni trà iniziatori è mira. I zoni sò custruiti nantu à u principiu di "un portu iniziatore - unu o più porti di array".
Se utilizate una cunnessione via iSCSI in u casu di utilizà un switch spartutu cù altri servizii, allora hè imperativu per isolà u trafficu iSCSI in una VLAN separata. Hè ancu assai ricumandemu per attivà u supportu per Jumbo Frames (MTU = 9000) per aumentà a dimensione di i pacchetti in a reta è cusì riduce a quantità di l'infurmazioni overhead durante a trasmissione. Tuttavia, vale a pena ricurdà chì per u funziunamentu currettu hè necessariu di cambià u paràmetru MTU in tutti i cumpunenti di a rete longu a catena "iniziatore-switch-target".
Configurazione di l'array All Flash
L'array hè furnitu à i clienti cù gruppi digià formati . Per quessa, ùn ci hè micca bisognu di piglià azzione per cumminà unità in una sola struttura. Solu bisognu di creà volumi di a dimensione è a quantità necessaria.
Per comodità, ci hè una funziunalità per a creazione di batch di parechji volumi di una certa dimensione à una volta. Per automaticamente, sò creati volumi sottili, postu chì questu permette un usu più efficaci di u spaziu di almacenamentu dispunibule (cumpresu u supportu per a Reclamazione di Spaziu). In quantu à u rendiment, a diffarenza trà volumi "magre" è "grossu" ùn supera micca 1%. In ogni casu, sè vo vulete "squeeze all the juice" fora di un array, pudete sempre cunvertisce ogni voluminu "magre" in un "grossu". Ma deve esse ricurdatu chì una tale operazione hè irreversibile.
In seguitu, resta à "publicà" i volumi creati è stabilisce i diritti d'accessu à elli da l'ospiti cù l'ACL (indirizzi IP per iSCSI è WWPN per FC) è a separazione fisica per i porti di array. Per i mudelli iSCSI, questu hè fattu creendu un Target.
Per i mudelli FC, a publicazione si faci per a creazione di un LUN per ogni portu di l'array.
Per accelerà u prucessu di stallazione, l'ospiti ponu esse cumminati in gruppi. Inoltre, se l'ospitu usa un FC HBA multiportu (chì in a pratica accade più spessu), u sistema determina automaticamente chì i porti di un tali HBA appartenenu à un unicu host grazia à i WWPNs chì sò diffirenti per unu. A creazione batch di Target/LUN hè ancu supportata per e duie interfacce.
Una nota impurtante quandu aduprate l'interfaccia iSCSI hè di creà parechje destinazioni per volumi à una volta per aumentà u rendiment, postu chì a fila nantu à u mira ùn pò micca esse cambiata è serà effettivamente un collu di bottiglia.
Configurazione di l'host ESXi
Da u latu di l'ospite ESXi, a cunfigurazione di basa hè realizata secondu un scenariu cumpletamente previstu. Prucedura per a cunnessione iSCSI:
- Add Software iSCSI Adapter (micca necessariu s'ellu hè digià statu aghjuntu, o s'è vo aduprate Hardware iSCSI Adapter);
- Crià un vSwitch attraversu quale u trafficu iSCSI passerà, è aghjunghjendu un uplink fisicu è VMkernal à questu;
- Aghjunghjendu indirizzi array à Dynamic Discovery;
- Creazione di datastore
Alcune note impurtanti:
- In u casu generale, sicuru, pudete aduprà un vSwitch esistente, ma in u casu di un vSwitch separatu, a gestione di i paràmetri di l'ospiti serà assai più faciule.
- Hè necessariu separà u trafficu di Gestione è iSCSI in ligami fisici separati è / o VLAN per evità prublemi di rendiment.
- L'indirizzi IP di u VMkernal è i porti currispondenti di l'array All Flash deve esse in a listessa subnet, di novu per via di prublemi di rendiment.
- Per assicurà a tolleranza di difetti secondu e regule VMware, vSwitch deve avè almenu dui uplinks fisici
- Se Jumbo Frames sò usati, avete bisognu di cambià u MTU di vSwitch è VMkernal
- Saria utile ricurdà chì sicondu i cunsiglii di VMware per l'adattatori fisichi chì seranu utilizati per travaglià cù u trafficu iSCSI, hè necessariu di cunfigurà Teaming è Failover. In particulare, ogni VMkernal deve travaglià per un solu uplink, u sicondu uplink deve esse cambiatu à u modu inutilizatu. Per a tolleranza di difetti, avete bisognu di aghjunghje dui VMkernals, ognuna di quale travaglià cù u so uplink.
Adattatore VMkernel (vmk#)
Adattatore di rete fisica (vmnic#)
vmk1 (Storage01)
Adattatori attivi
vmnic2
Adattatori inutilizati
vmnic3
vmk2 (Storage02)
Adattatori attivi
vmnic3
Adattatori inutilizati
vmnic2
Nisun passu preliminariu hè necessariu per cunnette via Fibre Channel. Pudete subitu creà un Datastore.
Dopu avè creatu u Datastore, avete bisognu di assicurà chì a pulitica Round Robin per i camini à u Target / LUN hè aduprata cum'è u più performante.
Per automaticamente, i paràmetri di VMware furnisce l'utilizazione di sta pulitica secondu u schema: 1000 dumande per u primu percorsu, i prossimi 1000 dumande per a seconda strada, etc. Tale interazzione trà l'ospite è a matrice di dui controller serà sbilanciata. Dunque, ricumandemu di stabilisce a pulitica Round Robin = 1 paràmetru via Esxcli / PowerCLI.
login
Per Esxcli:
- Lista LUN dispunibili
esxcli storage nmp lista di dispositivi
- Copia u nome di u dispositivu
- Cambia a pulitica Round Robin
esxcli storage nmp psp roundrobin deviceconfig set - type = iops - iops = 1 - device = "Device_ID"
A maiò parte di l'applicazioni muderni sò pensati per scambià grandi pacchetti di dati per maximizà l'utilizazione di larghezza di banda è riduce a carica di CPU. Dunque, ESXi per difettu emette richieste I / O à u dispositivu di almacenamento in pezzi finu à 32767KB. Tuttavia, per certi scenarii, u scambiu di pezzi più chjuchi serà più pruduttivu. Per i matrici AccelStor, questi sò i seguenti scenarii:
- A macchina virtuale usa UEFI invece di Legacy BIOS
- Utilizà vSphere Replication
Per tali scenarii, hè cunsigliatu di cambià u valore di u paràmetru Disk.DiskMaxIOSize à 4096.
Per e cunnessione iSCSI, hè cunsigliatu di cambià u paràmetru di Login Timeout à 30 (predeterminatu 5) per aumentà a stabilità di a cunnessione è disattivà u ritardu DelayedAck per cunferma di pacchetti trasmessi. E duie opzioni sò in vSphere Client: Host → Configure → Storage → Storage Adapters → Opzioni avanzate per l'adattatore iSCSI
Un puntu piuttostu sottile hè u numeru di volumi utilizati per u datastore. Hè chjaru chì per a facilità di gestione, ci hè un desideriu di creà un grande voluminu per tuttu u voluminu di l'array. In ogni casu, a prisenza di parechji volumi è, per quessa, u datastore hà un effettu benefizièvule nantu à u rendiment generale (più nantu à e file sottu). Dunque, ricumandemu di creà almenu dui volumi.
Finu à pocu tempu pocu tempu, VMware hà cunsigliatu di limità u numeru di macchine virtuali in un magazzinu di dati, di novu per ottene u più altu rendiment pussibule. Tuttavia, avà, soprattuttu cù a diffusione di VDI, stu prublema ùn hè più cusì acutu. Ma questu ùn annulla micca a regula di longa durata - per distribuisce e macchine virtuali chì necessitanu IO intensive in diverse datastores. Per determinà u nùmeru ottimali di macchine virtuali per volume, ùn ci hè nunda di megliu cà in a so infrastruttura.
Configurazione di macchine virtuali
Ùn ci sò micca esigenze speciali per a stallazione di macchine virtuali, o piuttostu sò abbastanza ordinarie:
- Utilizà a versione VM più alta pussibule (cumpatibilità)
- Hè più attentu à stabilisce a dimensione di RAM quandu si mette e macchine virtuali densamente, per esempiu, in VDI (perchè per automaticamente, à l'iniziu, hè creatu un schedariu di pagina di una dimensione proporzionata à a RAM, chì cunsuma capacità utile è hà un effettu in a performance finale)
- Aduprate e versioni di adattatori più produttivi in termini di IO: tipu di rete VMXNET 3 è tipu SCSI PVSCSI
- Aduprate Thick Provision Eager Zeroed tippu di discu per u massimu rendimentu è Thin Provisioning per u massimu usu di u spaziu di almacenamento
- Sè pussibule, limità u funziunamentu di e macchine critiche non I/O usendu Virtual Disk Limit
- Assicuratevi di stallà VMware Tools
Notes nantu à a fila
Queue (o Outstanding I/Os) hè u numeru di richieste di input/output (cumandamenti SCSI) chì aspettanu di trasfurmà in ogni mumentu per un dispositivu / applicazione specificu. In casu di overflow di fila, l'errori QFULL sò emessi, chì ultimamente risultatu in un aumentu di u paràmetru di latenza. Quandu si usanu sistemi di almacenamentu di discu (spindle), in teoria, u più altu hè a fila, u più altu u so rendiment. In ogni casu, ùn deve micca abusu, postu chì hè faciule per andà in QFULL. In u casu di i sistemi All Flash, da una banda, tuttu hè un pocu più simplice: dopu tuttu, l'array hà latenzi chì sò ordini di grandezza più bassu è per quessa, a maiò spessu, ùn ci hè bisognu di regulà separatamente a dimensione di e fila. Ma d'altra parte, in certi scenarii d'usu (fortu skew in i requisiti IO per e macchine virtuali specifiche, teste per u massimu rendimentu, etc.) hè necessariu, se micca di cambià i paràmetri di e fila, almenu per capiscenu chì indicatori. pò esse rializatu, è, a cosa principal hè in quale modi.
Nantu à l'array AccelStor All Flash stessu ùn ci sò limiti in relazione à volumi o porti I/O. Se ne necessariu, ancu un unicu voluminu pò riceve tutte e risorse di l'array. L'unica limitazione in a fila hè per i scopi iSCSI. Hè per questu mutivu chì a necessità di creà parechji (idealmente à 8 pezzi) miri per ogni voluminu per superà stu limitu hè statu indicatu sopra. Ripetemu ancu chì l'arrays AccelStor sò suluzioni assai pruduttivi. Dunque, duvete aduprà tutti i porti di l'interfaccia di u sistema per ottene a velocità massima.
Da u latu di l'host ESXi, a situazione hè completamente diversa. L'ospite stessu applica a pratica di l'accessu uguale à e risorse per tutti i participanti. Dunque, ci sò file IO separati per u SO invitatu è HBA. Queues à u SO invitatu sò cumminati da file à l'adattatore SCSI virtuale è u discu virtuale:
A fila à l'HBA dipende da u tipu / venditore specificu:
A prestazione finale di a macchina virtuale serà determinata da u limitu di Profondità di Coda più bassu trà i cumpunenti di l'ospiti.
Grazie à questi valori, pudemu valutà l'indicatori di rendiment chì pudemu avè in una cunfigurazione particulare. Per esempiu, vulemu cunnosce u funziunamentu teoricu di una macchina virtuale (senza ubligatoriu di bloccu) cù una latenza di 0.5ms. Allora i so IOPS = (1,000/latenza) * I/O eccezionali (limite di profondità di fila)
esempi
esempiu 1
- Adattatore FC Emulex HBA
- Una VM per datastore
- Adattatore VMware Paravirtual SCSI
Quì Queue Depth limitu hè determinatu da Emulex HBA. Dunque IOPS = (1000/0.5) * 32 = 64K
esempiu 2
- Adattatore software VMware iSCSI
- Una VM per datastore
- Adattatore VMware Paravirtual SCSI
Quì u limitu di Queue Depth hè digià determinatu da l'Adapter SCSI Paravirtual. Dunque IOPS = (1000/0.5) * 64 = 128K
I mudelli principali di tutti i array Flash AccelStor (per esempiu, ) sò capaci di furnisce prestazioni di scrittura 700K IOPS à bloccu 4K. Cù una tale dimensione di bloccu, hè abbastanza ovvi chì una sola macchina virtuale ùn hè micca capace di carricà un tali array. Per fà questu, avete bisognu di 11 (per esempiu 1) o 6 (per esempiu 2) macchine virtuali.
In u risultatu, cù a cunfigurazione curretta di tutti i cumpunenti descritti di un centru di dati virtuale, pudete ottene risultati assai impressiunanti in termini di prestazioni.
4K casuale, 70% di lettura / 30% di scrittura
In fatti, u mondu reale hè assai più cumplessu di ciò chì pò esse descrittu cù una formula simplice. Un host ospita sempre parechje macchine virtuali cù diverse cunfigurazioni è esigenze IO. È u prucessu I / O hè trattatu da u processatore di l'ospite, chì u so putere ùn hè micca infinitu. Dunque, per sbloccare tuttu u putenziale di u listessu in realtà, vi tuccherà trè ospiti. In più, l'applicazioni chì funzionanu in e macchine virtuali facenu i so propiu aghjustamenti. Dunque, per dimensionamentu precisu prupunemu Tutti i matrici Flash Dentru l'infrastruttura di u cliente nantu à i veri compiti attuali.
Source: www.habr.com