Selles artiklis tahaksime rääkida AccelStori All Flash-massiivide töötamise omadustest ühe populaarsema virtualiseerimisplatvormi – VMware vSphere – kontekstis. Eelkõige rõhutame neid parameetreid, mis aitavad saavutada maksimaalset efektiivsust sellise võimsa tööriista nagu All Flash kasutamisel.
AccelStor NeoSapphire™ All Flash massiivid on või nodiga seadmed, mis põhinevad SSD-draividel ja rakendavad andmete salvestamise ning neile juurdepääsu organiseerimise osas täiesti erinevat lähenemist, kasutades oma tehnoloogiat asemel väga levinud RAID-algoritme. Massiivid pakuvad hostidele blokeeritud juurdepääsu Fibre Channel'i või iSCSI liideste kaudu. Õigluse huvides märkime, et iSCSI liidese mudelid pakuvad ka failipõhist ligipääsu meeldiva boonuse näol. Kuid käesolevas artiklis keskendume blokaadi protokollide kasutamisele, kuna need on All Flash jaoks kõige tõhusamad.
AccelStor'i ja VMware vSphere'i virtuaaliseerimissüsteemi ühise töö käivitamise ja seadistamise kogu protsessi võib jagada mitmeks etapiks:
- Ühendustopoloogia rakendamine ja SAN-võrgu seadistamine;
- All Flash-massiivi seadistamine;
- ESXi hostide seadistamine;
- Virtuaalmasinate seadistamine.
Näidishardware'ina kasutati AccelStor NeoSapphire™ massiive, millel on Fibre Channel ja iSCSI liidesed. Põhioso põhjana kasutati VMware vSphere 6.7U1.
Enne artiklis kirjeldatud süsteemide käivitamist on tungivalt soovitatav tutvuda VMware'i dokumentatsiooniga, mis käsitleb jõudlusküsimusi ( ) ja iSCSI seadistusi ()
Ühendustopoloogia ja SAN-võrgu seadistamine
SAN-võrgu peamised komponendid on HBA-adapterid ESXi hostides, SAN-lülitid ja massiivi nodid. Tüüpiline sellise võrgu topoloogia näeb välja järgmine:
Termin Switch viitab nii eraldi füüsilisele lülitile või lülitite kogumile (Fabric) kui ka seadmele, mida jagatakse erinevate teenuste vahel (VSAN Fibre Channel'i puhul ja VLAN iSCSI puhul). Kaks sõltumatut lülitit/Fabric'i kasutamine välistab võimaliku riketeetme.
Kuigi hostide otseühendus massiiviga on toetatud, ei soovitata seda tungivalt. All Flash massiivide jõudlus on piisavalt kõrge ja maksimaalse kiirus saavutamiseks tuleks kasutada kõiki massiivi porte. Seetõttu on vähemalt ühe lüliti olemasolu hostide ja NeoSapphire™ vahel kohustuslik.
Kahe pordi olemasolu hosti HBA-s on samuti kohustuslik nõue maksimaalse jõudluse saavutamiseks ja tõrgeteta töö tagamiseks.
Kui kasutatakse Fibre Channel'i liidest, on vajalik tsoonimise seadistamine, et vältida võimalikke kokkupõrkeid algatajate ja sihtpunktide vahel. Tsoonid on ehitatud põhimõttel "üks algataja port - üks või mitu massiivi porti."
Kui iSCSI ühendust kasutatakse ühisel lõpp-punktide lülitil, on kindlasti vajalik iSCSI liikluse isoleerimine eraldi VLAN-is. Soovitav on ka lubada Jumbo Frame'i tugi (MTU = 9000), et suurendada pakettide suurust võrgus ja seeläbi vähendada edastamise käigus kasutatavat haldusinformatsiooni. Kuid tuleb meeles pidada, et korrektseks toimimiseks on vajalik muuta MTU parameeter kõigis võrgu komponentides ahelas «algataja-lüliti-siht».
All Flash mäluriba seadistamine
Mälu tarnitakse klientidele juba loodud gruppidega . Seega ei ole vaja võtta mingeid meetmeid andurite ühendamiseks ühiseks struktuuriks. Piisab vaid vajaliku suurusega ja vajaliku arvu mahutite loomist.
Kasutusmugavuse huvides on olemas funktsioon partii loomise jaoks, et luua korraga mitu määratud mahut. Vaikimisi luuakse "õhukesed" mahud, kuna see võimaldab tõhusamalt kasutada saadavat salvestusruumi (sh Space Reclamation toetuse kaudu). Jõudluse osas on erinevus "õhukeste" ja "paksude" mahutite vahel alla 1%. Siiski, kui on vaja välja pigistada kõik, mida maht suudab, saab alati konverteerida mis tahes "õhukese" mahut "paksuks". Tuleb siiski meeles pidada, et see operatsioon on pöördumatu.
Järgmine samm on luua loodud mahud avalikuks ja määrata juurdepääsuõigused nendele külaliste poolt ACL (iSCSI jaoks IP-aadressid ja FC jaoks WWPN) ja füüsilise portide eraldamise kaudu. iSCSI mudelite puhul toimub see läbi Targeti loomise.
FC mudelite puhul toimub publikatsioon LUNi loomise kaudu iga massiivi pordi jaoks.
Hostide seadistuse kiirendamiseks on võimalik neid gruppidesse liita. Kui hostis kasutatakse mitmeportilist FC HBA-d (mis praktikas on kõige sagedasem juhtum), tuvastab süsteem automaatselt, et sellise HBA portide WWPN-id erinevad üksteisest vaid ühe numbriga, mistõttu need kuuluvad samale hostile. Samuti toetavad mõlemad liidesed Target/LUN rühmituste loomist.
Oluline märkida iSCSI liidese kasutamisel on luua mahtude jaoks koheselt mitu sihtmärki, et suurendada jõudlust, kuna sihtmärgi järjekordi ei saa muuta ning see kujuneb tegelikult kitsaskohaks.
ESXi hostide seadistamine
ESXi hostide poolt toimub põhiseadistus täiesti oodatud stsenaariumi järgi. iSCSI ühenduse loomise järjekord on järgmine:
- Lisada Software iSCSI Adapter (ei ole vajalik, kui see on juba lisatud, või kui kasutatakse Hardware iSCSI Adapterit);
- Loodud vSwitch, mille kaudu kulgeb iSCSI liiklus, ja füüsiliste uplinkide ning VMkernali lisamine sellesse;
- Lisada Dynamic Discovery kaudu mahamisadresse;
- Loodud Datastore
Mõned olulised märkused:
- Üldiselt on võimalik kasutada ka olemasolevat vSwitchi, kuid eraldi vSwitchi korral on hosti seadistuste haldamine oluliselt lihtsam.
- Management liiklus ja iSCSI tuleb eraldada erinevatele füüsilistele linkidele ja/või VLANidele, et vältida jõudlusprobleeme.
- VMkernel'i IP-aadressid ja vastavad All Flash mahtude portide aadressid peavad kuuluma sama alavõrku, jälle jõudlusprobleemide tõttu.
- VMware'i eeskirjade kohaselt peab vSwitchil olema vähemalt kaks füüsilist uplinki, et tagada töökindlus.
- Jumbo Frame'ide kasutamise korral tuleb MTU muuta nii vSwitchis kui ka VMkernel'is.
- Oluline on meenutada, et VMware'i soovituste kohaselt peab iSCSI liikluseks kasutatavatele füüsilistele adapteritele olema häälestatud Teaming and Failover. Iga VMkernel peab töötama ainult läbi ühe uplinki; teine uplink tuleb seada unused režiimi. Töökindluse tagamiseks tuleb lisada kaks VMkernel'it, millest igaüks töötab oma uplinki kaudu.
VMkernel Adapter (vmk#)
Füüsiline Võrguaadapter (vmnic#)
vmk1 (Storage01)
Aktiivsed adapterid
vmnic2
Kasutamata adapterid
vmnic3
vmk2 (Storage02)
Aktiivsed adapterid
vmnic3
Kasutamata adapterid
vmnic2
Fibre Channeli kaudu ühendamiseks ei ole eelnevaid toiminguid vaja. Saate kohe luua Datastore'i.
Pärast Datastore'i loomist veenduge, et Target/LUN teed kasutavad Round Robin poliitikat, et saavutada parim jõudlus.
Vaikimisi seab VMware selle poliitika järgima skeemi: 1000 päringut esimese tee kaudu, järgmised 1000 päringut teise tee kaudu jne. Selline hosti suhtlemine kaheastmelise salvestusseadmaga on tasakaalustamata. Seetõttu soovitame seada Round Robin poliitika = 1 Esxcli/PowerCLI kaudu.
Parameetrid
Esxcli jaoks:
- Kuva saadaval LUN-id
esxcli storage nmp device list
- Kopeeri seadme nimi
- Muutke Round Robin poliitikat
esxcli storage nmp psp roundrobin deviceconfig set --type=iops --iops=1 --device="Device_ID"
Enamik tänapäevasi rakendusi on loodud suurte andmepakettide vahetamiseks, et maksimeerida ribalaiuse kasutust ja vähendada keskse protsessori koormust. Seetõttu edastab ESXi vaikimisi sisendi/väljundi päringud salvestusseadmele kogustes kuni 32767 KB. Siiski on väikeste koguste vahetamine mõnel juhul efektiivsem. AccelStori maatriksite puhul on need stsenaariumid:
- Virtuaalne masin kasutab UEFI-d Legacy BIOS-i asemel
- Kasutatakse vSphere Replikatsiooni
Sellistes stsenaariumides on soovitatav muuta parameetrit Disk.DiskMaxIOSize väärtusele 4096.
iSCSI ühenduste puhul on soovitatav muuta parameetrit Login Timeout väärtusele 30 (vaikeline 5), et suurendada ühenduse stabiilsust ja välja lülitada edasilükatud kinnituse edastamise pakettide DelayedAck. Mõlemad valikud asuvad vSphere klienti: Host → Configure → Storage → Storage Adapters → Advanced Options iSCSI adapteri jaoks.
Datastore'i jaoks kasutatavate mahu arv on piisavalt delikaatne teema. Loomulikult on soov luua üks suur maht kogu salvestusruumi jaoks, et lihtsustada haldamist. Siiski, mitme mahu ja seega ka datastore'i olemasolu mõjutab positiivselt üldist jõudlust (räsimiste kohta allpool rohkem). Seetõttu soovitame luua vähemalt kaks mahtu.
Veel suhteliselt hiljuti soovitas VMware piirata virtuaalmasinate arvu ühe datastore'i peal, et saavutada maksimaalne jõudlus. Kuid nüüd, eriti VDI levimisega, ei ole see probleem enam nii terav. Kuid see ei tühista vana reeglit — jaotada I/O intensiivsust nõudvad virtuaalmasinad erinevatele datastore'idele. Optimaalse arvu virtuaalmasinate määramiseks ühe mahu peal pole paremat viisi kui läbi viia oma infrastruktuuri raames.
Virtuaalmasinate seadistamine
Virtuaalmasinate seadistamisel ei ole erilisi nõudeid, pigem on need tavalised:
- Kasuta maksimaalselt ühilduvat VM versiooni
- Oluline on olla ettevaatlik, määrates RAM-i suurust tihedalt paiknevate virtuaalmasinate puhul, näiteks VDI-s (sest vaikimisi käivitamisel luuakse vahetusfail, mis on RAM-i suurusega, mis kulutab kasulikku mahtu ja mõjutab lõpptulemust)
- Kasutage IO osas kõige tootlikumaid adapteriversioone: võrgu tüüp VMXNET 3 ja SCSI tüüp PVSCSI
- Kasutage maksimaalse jõudluse tagamiseks Thick Provision Eager Zeroed ketast ja Thin Provisioningut, et maksimaalselt efektiivselt ruumi kasutada
- Vajadusel piirake mitte-kriitiliste masinate tööd, kasutades Virtual Disk Limiti
- VMware Tools tuleb kindlasti installida
Kässide märkused
Oote (või Outstanding I/O-d) on sisendi/väljundi (SCSI käskude) päringute arv, mis ootavad töötlemist igal hetkel konkreetses seadmes/rakenduses. Oote ületamisel antakse QFULL viga, mis väljendub latency tõusus. Diskipõhiste (spindle) salvestussüsteemide korral kehtib teoreetiliselt, et mida kõrgem on oote, seda parem on nende jõudlus. Siiski ei tasu sellega liialdada, kuna on kerge sattuda QFULL-ile. All Flash süsteemide puhul on olukord mõnevõrra lihtsam: mäluriba latentsus on korrutades tunduvalt madalam ja seetõttu ei ole sageli vaja eraldi oote suurust reguleerida. Kuid teiselt poolt, teatud kasutusstsenaariumides (konkreetsete virtuaalmasinate IO nõudmiste tugev tasakaalutus, maksimaalse jõudluse testimine jne) võib olla vajalik, kui mitte muuda ooteparameetreid, siis vähemalt mõista, milliseid näitajaid on võimalik saavutada ja, mis kõige tähtsam, milliseid teid pidi.
AccelStor All Flash süsteemil ei ole mahtude või sisend/väljundportide osas mingeid piiranguid. Vajadusel võib isegi üksik maht saada kõik ressursid süsteemist. Ainus piirang seab iSCSI sihtpunktidele. Just seetõttu oli varem vajalik luua mitu (ideaalis kuni 8) sihtpunkti iga mahu jaoks, et seda piirangut ületada. Kordame veel, et AccelStori süsteemid on väga tõhusad lahendused. Seetõttu tuleks kasutada kõiki süsteemi liidese porte maksimaalse kiiruseni jõudmiseks.
ESXi hosti küljest on olukord täiesti teine. Ise host rakendab võrdsuse põhimõtet ressursside juurdepääsuks kõigile osalistele. Seetõttu on olemas eraldi IO järjekorrad külghanje ja HBA jaoks. Külghanje järjekorrad kombineeritakse virtuaalse SCSI adapteri ja virtuaalse ketta järjekordadest:
HBA järjekord sõltub konkreetsest tüübist/tootjast:
Virtuaalmasina lõplik jõudlus määratakse hosti komponentide madalaima järjekorra (Queue Depth limit) väärtuse järgi.
Nende väärtuste abil saab hinnata jõudluse näitajaid, mida saame erinevates konfiguratsioonides saavutada. Näiteks tahame teada teoreetilist jõudlust virtuaalmasinal (ilma talituse sõltumata) latentsusega 0,5 ms. Siis on selle IOPS = (1,000/latency) * Outstanding I/Os (Queue Depth limit)
Näited
Näide 1
- FC Emulex HBA adapter
- Üks VM andmebaasis
- VMware Paravirtual SCSI adapter
Siin määrab Queue Depth limit Emulex HBA. Seetõttu on IOPS = (1000/0.5)*32 = 64K
Näide 2
- VMware iSCSI tarkvara adapter
- Üks VM andmebaasis
- VMware Paravirtual SCSI adapter
Siin määrab Queue Depth limit juba Paravirtual SCSI adapter. Seetõttu on IOPS = (1000/0.5)*64 = 128K
AccelStori tippmudelid, kõik Flash andmemälud (näiteks, ) suudavad tagada kirjutamise jõudluse 700K IOPS 4K plokiga. Sellise ploki suuruse puhul on täiesti ilmne, et üksnes virtuaalmasin ei suuda sellist andmemälu koormata. Selleks on vaja 11 (näiteks 1) või 6 (näiteks 2) virtuaalmasinat.
Seega, kui kõik kirjeldatud virtuaalse andmekeskuse komponendid on õigesti seadistatud, on võimalik saavutada väga muljetavaldavaid tulemusi jõudluse osas.
4K Random, 70% lugemine/30% kirjutamine
Tegelikult on reaalne maailm palju keerulisem, et seda kirjeldada lihtsa valemiga. Ühel serveril asub alati hulk virtuaalmasinaid erinevate konfigureerimiste ja IO-nõuetega. Samuti tegeleb sisendi/väljundi töötlemisega hosti protsessor, mille jõudlus ei ole lõpmatu. Seega, et avada sama reaalsuses on vaja vähemalt kolme hosti. Lisaks toovad virtuaalmasinates töötavad rakendused oma päringud. Seetõttu pakume täpsete mõõtmete määramiseks kõigi Flash-massiivide klientide infrastruktuuris reaalses tööülesandete täitmisel.
Allikas: habr.com
