În acest articol, aș dori să vorbesc despre caracteristicile matricelor All Flash AccelStor care lucrează cu una dintre cele mai populare platforme de virtualizare - VMware vSphere. În special, concentrați-vă pe acei parametri care vă vor ajuta să obțineți efectul maxim din utilizarea unui instrument atât de puternic precum All Flash.
AccelStor NeoSapphire™ Toate matricele Flash sunt sau dispozitive nod bazate pe unități SSD cu o abordare fundamental diferită pentru implementarea conceptului de stocare a datelor și organizarea accesului la acesta folosind tehnologie proprietară în loc de algoritmii RAID foarte populari. Matricele oferă acces în bloc la gazde prin intermediul interfețelor Fibre Channel sau iSCSI. Pentru a fi corect, observăm că modelele cu interfață ISCSI au și acces la fișiere ca un bonus frumos. Dar în acest articol ne vom concentra pe utilizarea protocoalelor bloc ca fiind cele mai productive pentru All Flash.
Întregul proces de implementare și configurarea ulterioară a funcționării în comun a matricei AccelStor și a sistemului de virtualizare VMware vSphere poate fi împărțit în mai multe etape:
- Implementarea topologiei de conectare si configurarea retelei SAN;
- Configurarea matricei All Flash;
- Configurarea gazdelor ESXi;
- Configurarea mașinilor virtuale.
S-au folosit matrice AccelStor NeoSapphire™ Fibre Channel și matrice iSCSI ca probă de hardware. Software-ul de bază este VMware vSphere 6.7U1.
Înainte de a implementa sistemele descrise în acest articol, este foarte recomandat să citiți documentația de la VMware cu privire la problemele de performanță ( ) și setări iSCSI ()
Topologia conexiunii și configurația rețelei SAN
Componentele principale ale unei rețele SAN sunt HBA-urile din gazdele ESXi, switch-urile SAN și nodurile de matrice. O topologie tipică pentru o astfel de rețea ar arăta astfel:
Termenul Comutare aici se referă atât la un comutator fizic separat sau la un set de comutatoare (Fabric), cât și la un dispozitiv partajat între diferite servicii (VSAN în cazul Fibre Channel și VLAN în cazul iSCSI). Utilizarea a două întrerupătoare/Tesaturi independente va elimina un posibil punct de defecțiune.
Conexiunea directă a gazdelor la matrice, deși acceptată, nu este recomandată. Performanța matricelor All Flash este destul de ridicată. Și pentru viteza maximă, trebuie folosite toate porturile matricei. Prin urmare, prezența a cel puțin unui comutator între gazde și NeoSapphire™ este obligatorie.
Prezența a două porturi pe HBA gazdă este, de asemenea, o cerință obligatorie pentru a obține performanțe maxime și pentru a asigura toleranța la erori.
Când utilizați o interfață Fibre Channel, zonarea trebuie configurată pentru a elimina posibilele coliziuni între inițiatori și ținte. Zonele sunt construite pe principiul „un port inițiator – unul sau mai multe porturi matrice”.
Dacă utilizați o conexiune prin iSCSI în cazul utilizării unui comutator partajat cu alte servicii, atunci este imperativ să izolați traficul iSCSI într-un VLAN separat. De asemenea, este foarte recomandat să activați suportul pentru Jumbo Frames (MTU = 9000) pentru a crește dimensiunea pachetelor din rețea și, prin urmare, a reduce cantitatea de informații de supraîncărcare în timpul transmisiei. Cu toate acestea, merită să ne amintim că pentru o funcționare corectă este necesară modificarea parametrului MTU pe toate componentele rețelei de-a lungul lanțului „inițiator-comutator-țintă”.
Configurarea matricei All Flash
Matricea este livrată clienților cu grupuri deja formate . Prin urmare, nu trebuie luate măsuri pentru a combina unitățile într-o singură structură. Trebuie doar să creați volume de dimensiunea și cantitatea necesară.
Pentru comoditate, există o funcționalitate pentru crearea în lot a mai multor volume de o anumită dimensiune simultan. În mod implicit, sunt create volume subțiri, deoarece acest lucru permite o utilizare mai eficientă a spațiului de stocare disponibil (inclusiv suport pentru recuperarea spațiului). În ceea ce privește performanța, diferența dintre volumele „subțiri” și „groase” nu depășește 1%. Cu toate acestea, dacă doriți să „strângeți tot sucul” dintr-o matrice, puteți oricând să convertiți orice volum „subțire” într-unul „gros”. Dar trebuie amintit că o astfel de operațiune este ireversibilă.
În continuare, rămâne să „publicați” volumele create și să setați drepturi de acces la ele de la gazde folosind ACL-uri (adrese IP pentru iSCSI și WWPN pentru FC) și separarea fizică prin porturi de matrice. Pentru modelele iSCSI, acest lucru se realizează prin crearea unei ținte.
Pentru modelele FC, publicarea are loc prin crearea unui LUN pentru fiecare port al matricei.
Pentru a accelera procesul de configurare, gazdele pot fi combinate în grupuri. Mai mult, dacă gazda folosește un FC HBA multiport (ceea ce în practică se întâmplă cel mai des), atunci sistemul stabilește automat că porturile unui astfel de HBA aparțin unei singure gazde datorită WWPN-urilor care diferă cu unul. Crearea loturilor de țintă/LUN este, de asemenea, acceptată pentru ambele interfețe.
O notă importantă atunci când utilizați interfața iSCSI este să creați mai multe ținte pentru volume simultan pentru a crește performanța, deoarece coada de pe țintă nu poate fi modificată și va fi efectiv un blocaj.
Configurarea gazdelor ESXi
Pe partea gazdă ESXi, configurația de bază este efectuată conform unui scenariu complet așteptat. Procedura pentru conexiunea iSCSI:
- Adăugați adaptor iSCSI software (nu este necesar dacă acesta a fost deja adăugat sau dacă utilizați adaptor iSCSI hardware);
- Crearea unui vSwitch prin care va trece traficul iSCSI și adăugarea unui uplink fizic și VMkernal la acesta;
- Adăugarea de adrese matrice la Dynamic Discovery;
- Crearea unui depozit de date
Câteva note importante:
- În cazul general, desigur, puteți utiliza un vSwitch existent, dar în cazul unui vSwitch separat, gestionarea setărilor gazdei va fi mult mai ușoară.
- Este necesar să se separe traficul de management și iSCSI pe legături fizice și/sau VLAN-uri separate pentru a evita problemele de performanță.
- Adresele IP ale VMkernal și porturile corespunzătoare ale matricei All Flash trebuie să fie în aceeași subrețea, din nou din cauza problemelor de performanță.
- Pentru a asigura toleranța la erori în conformitate cu regulile VMware, vSwitch trebuie să aibă cel puțin două conexiuni fizice în sus
- Dacă sunt utilizate cadre Jumbo, trebuie să modificați MTU-ul atât pentru vSwitch, cât și pentru VMkernal
- Ar fi util să vă reamintim că, conform recomandărilor VMware pentru adaptoarele fizice care vor fi folosite pentru a lucra cu trafic iSCSI, este necesar să configurați Teaming și Failover. În special, fiecare VMkernal trebuie să funcționeze printr-un singur uplink, al doilea uplink trebuie să fie comutat în modul neutilizat. Pentru toleranța la erori, trebuie să adăugați două VMkernal-uri, fiecare dintre ele va funcționa prin intermediul propriei link-uri în sus.
Adaptor VMkernel (vmk#)
Adaptor de rețea fizică (vmnic#)
vmk1 (Depozitare01)
Adaptoare active
vmnic2
Adaptoare nefolosite
vmnic3
vmk2 (Depozitare02)
Adaptoare active
vmnic3
Adaptoare nefolosite
vmnic2
Nu sunt necesari pași preliminari pentru a vă conecta prin Fibre Channel. Puteți crea imediat un Datastore.
După crearea Datastore-ului, trebuie să vă asigurați că politica Round Robin pentru căile către țintă/LUN este utilizată ca cea mai performantă.
În mod implicit, setările VMware prevăd utilizarea acestei politici conform schemei: 1000 de solicitări prin prima cale, următoarele 1000 de solicitări prin a doua cale etc. O astfel de interacțiune între gazdă și matricea cu două controlere va fi dezechilibrată. Prin urmare, vă recomandăm să setați politica Round Robin = 1 parametru prin Esxcli/PowerCLI.
Parametrii
Pentru Esxcli:
- Listați LUN-urile disponibile
lista de dispozitive esxcli storage nmp
- Copiați numele dispozitivului
- Schimbați politica Round Robin
esxcli storage nmp psp roundrobin deviceconfig set —type=iops —iops=1 —device=“Device_ID”
Cele mai multe aplicații moderne sunt concepute pentru a schimba pachete mari de date pentru a maximiza utilizarea lățimii de bandă și pentru a reduce încărcarea CPU. Prin urmare, ESXi emite implicit solicitări I/O către dispozitivul de stocare în bucăți de până la 32767KB. Cu toate acestea, pentru unele scenarii, schimbul de bucăți mai mici va fi mai productiv. Pentru matricele AccelStor, acestea sunt următoarele scenarii:
- Mașina virtuală folosește UEFI în loc de Legacy BIOS
- Utilizează vSphere Replication
Pentru astfel de scenarii, se recomandă modificarea valorii parametrului Disk.DiskMaxIOSize la 4096.
Pentru conexiunile iSCSI, se recomandă modificarea parametrului Login Timeout la 30 (implicit 5) pentru a crește stabilitatea conexiunii și a dezactiva întârzierea DelayedAck pentru confirmările pachetelor redirecționate. Ambele opțiuni sunt în vSphere Client: Gazdă → Configurare → Stocare → Adaptoare de stocare → Opțiuni avansate pentru adaptorul iSCSI
Un punct destul de subtil este numărul de volume utilizate pentru depozitul de date. Este clar că, pentru ușurința administrării, există dorința de a crea un volum mare pentru întregul volum al matricei. Cu toate acestea, prezența mai multor volume și, în consecință, depozitul de date are un efect benefic asupra performanței generale (mai multe despre cozi mai jos). Prin urmare, vă recomandăm să creați cel puțin două volume.
Până de curând, VMware recomanda limitarea numărului de mașini virtuale dintr-un singur depozit de date, din nou pentru a obține cea mai mare performanță posibilă. Cu toate acestea, acum, mai ales odată cu răspândirea VDI, această problemă nu mai este atât de acută. Dar acest lucru nu anulează regula de lungă durată - de a distribui mașini virtuale care necesită IO intensivă în diferite depozite de date. Pentru a determina numărul optim de mașini virtuale pe volum, nu există nimic mai bun decât în cadrul infrastructurii sale.
Configurarea mașinilor virtuale
Nu există cerințe speciale la configurarea mașinilor virtuale, sau mai degrabă sunt destul de obișnuite:
- Utilizarea celei mai înalte versiuni posibile de VM (compatibilitate)
- Este mai atent să setați dimensiunea RAM atunci când plasați dens mașinile virtuale, de exemplu, în VDI (deoarece implicit, la pornire, este creat un fișier de pagină de o dimensiune proporțională cu RAM, care consumă capacitate utilă și are un efect asupra performanța finală)
- Utilizați cele mai productive versiuni de adaptor în ceea ce privește IO: tipul de rețea VMXNET 3 și tipul SCSI PVSCSI
- Utilizați tipul de disc Thick Provision Eager Zeroed pentru performanță maximă și Thin Provisioning pentru utilizarea maximă a spațiului de stocare
- Dacă este posibil, limitați funcționarea mașinilor critice fără I/O folosind Virtual Disk Limit
- Asigurați-vă că instalați VMware Tools
Note despre cozi
Coada (sau I/O-uri restante) este numărul de solicitări de intrare/ieșire (comenzi SCSI) care așteaptă procesarea la un moment dat pentru un anumit dispozitiv/aplicație. În cazul depășirii cozii, sunt emise erori QFULL, ceea ce are ca rezultat o creștere a parametrului de latență. Când se utilizează sisteme de stocare pe disc (spindle), teoretic, cu cât coada este mai mare, cu atât performanța lor este mai mare. Cu toate acestea, nu ar trebui să abuzați de el, deoarece este ușor să rulați în QFULL. În cazul sistemelor All Flash, pe de o parte, totul este oarecum mai simplu: la urma urmei, matricea are latențe cu ordine de mărime mai mici și, prin urmare, cel mai adesea, nu este nevoie să se regleze separat dimensiunea cozilor. Dar, pe de altă parte, în unele scenarii de utilizare (deformare puternică a cerințelor IO pentru anumite mașini virtuale, teste pentru performanță maximă etc.) este necesar, dacă nu să se modifice parametrii cozilor, atunci măcar să se înțeleagă ce indicatori poate fi atins și, principalul lucru este în ce moduri.
Pe matricea AccelStor All Flash în sine nu există limite în ceea ce privește volumele sau porturile I/O. Dacă este necesar, chiar și un singur volum poate primi toate resursele matricei. Singura limitare a cozii este pentru obiectivele iSCSI. Din acest motiv a fost indicată mai sus necesitatea creării mai multor ținte (ideal până la 8 piese) pentru fiecare volum pentru a depăși această limită. Să repetăm, de asemenea, că matricele AccelStor sunt soluții foarte productive. Prin urmare, ar trebui să utilizați toate porturile de interfață ale sistemului pentru a obține viteza maximă.
Pe partea de gazdă ESXi, situația este complet diferită. Gazda în sine aplică practica accesului egal la resurse pentru toți participanții. Prin urmare, există cozi de IO separate pentru sistemul de operare invitat și HBA. Cozile către sistemul de operare invitat sunt combinate de la cozile la adaptorul SCSI virtual și discul virtual:
Coada la HBA depinde de tipul/furnizorul specific:
Performanța finală a mașinii virtuale va fi determinată de cea mai mică limită de adâncime a cozii dintre componentele gazdă.
Datorită acestor valori, putem evalua indicatorii de performanță pe care îi putem obține într-o anumită configurație. De exemplu, dorim să cunoaștem performanța teoretică a unei mașini virtuale (fără blocare) cu o latență de 0.5 ms. Apoi IOPS-ul său = (1,000/latență) * I/O restante (limită de adâncime a cozii)
exemple
Exemplul 1
- Adaptor FC Emulex HBA
- Un VM pentru fiecare depozit de date
- Adaptor VMware Paravirtual SCSI
Aici limita de adâncime a cozii este determinată de Emulex HBA. Prin urmare, IOPS = (1000/0.5)*32 = 64K
Exemplul 2
- Adaptor software VMware iSCSI
- Un VM pentru fiecare depozit de date
- Adaptor VMware Paravirtual SCSI
Aici limita de adâncime a cozii este deja determinată de adaptorul Paravirtual SCSI. Prin urmare, IOPS = (1000/0.5)*64 = 128K
Modele de top ale matricelor All Flash AccelStor (de exemplu, ) sunt capabili să ofere performanțe de scriere de 700K IOPS la bloc 4K. Cu o astfel de dimensiune a blocului, este destul de evident că o singură mașină virtuală nu este capabilă să încarce o astfel de matrice. Pentru a face acest lucru, veți avea nevoie de 11 (de exemplu 1) sau 6 (de exemplu 2) mașini virtuale.
Drept urmare, prin configurarea corectă a tuturor componentelor descrise ale unui centru de date virtual, puteți obține rezultate foarte impresionante în ceea ce privește performanța.
4K aleatoriu, 70% citire/30% scriere
De fapt, lumea reală este mult mai complexă decât poate fi descrisă printr-o formulă simplă. O singură gazdă găzduiește întotdeauna mai multe mașini virtuale cu diferite configurații și cerințe IO. Iar procesarea I/O este gestionată de procesorul gazdă, a cărui putere nu este infinită. Deci, pentru a debloca întregul potențial al aceluiași în realitate, vei avea nevoie de trei gazde. În plus, aplicațiile care rulează în mașinile virtuale își fac propriile ajustări. Prin urmare, pentru dimensionare precisă oferim Toate matricele Flash în interiorul infrastructurii clientului asupra sarcinilor curente reale.
Sursa: www.habr.com