Selles artiklis tahaksin rääkida kõigi Flash AccelStori massiivide funktsioonidest, mis töötavad ühe populaarseima virtualiseerimisplatvormiga - VMware vSphere. Eelkõige keskenduge neile parameetritele, mis aitavad teil saada maksimaalse efekti sellise võimsa tööriista nagu All Flash kasutamisel.
AccelStor NeoSapphire™ Kõik Flash-massiivid on või SSD-draividel põhinevad sõlmeseadmed, millel on põhimõtteliselt erinev lähenemisviis andmete salvestamise kontseptsiooni rakendamisele ja sellele juurdepääsu korraldamisele patenteeritud tehnoloogia abil väga populaarsete RAID-algoritmide asemel. Massiivid pakuvad juurdepääsu hostidele Fibre Channeli või iSCSI liideste kaudu. Ausalt öeldes märgime, et ISCSI-liidesega mudelitel on kena boonusena juurdepääs ka failidele. Kuid selles artiklis keskendume plokkprotokollide kasutamisele kui kõige produktiivsemale All Flashi jaoks.
Kogu AccelStori massiivi ja VMware vSphere virtualiseerimissüsteemi juurutamise ja sellele järgneva konfigureerimise protsessi saab jagada mitmeks etapiks:
- Ühenduse topoloogia ja SAN-võrgu konfiguratsiooni juurutamine;
- Kõikide Flash-massiivide seadistamine;
- ESXi hostide konfigureerimine;
- Virtuaalsete masinate seadistamine.
Riistvara näidisena kasutati AccelStor NeoSapphire™ Fibre Channel massiive ja iSCSI massiive. Baastarkvaraks on VMware vSphere 6.7U1.
Enne selles artiklis kirjeldatud süsteemide juurutamist on tungivalt soovitatav lugeda läbi VMware'i dokumentatsioon jõudlusprobleemide kohta ( ) ja iSCSI seaded ()
Ühenduse topoloogia ja SAN-võrgu konfiguratsioon
SAN-võrgu põhikomponendid on HBA-d ESXi hostides, SAN-lülitid ja massiivisõlmed. Sellise võrgu tüüpiline topoloogia näeb välja järgmine:
Termin Switch viitab siin nii eraldiseisvale füüsilisele lülitile või lülitite komplektile (Fabric) kui ka erinevate teenuste vahel jagatud seadmele (Fibre Channeli puhul VSAN ja iSCSI puhul VLAN). Kahe sõltumatu lüliti/kanga kasutamine kõrvaldab võimaliku tõrkepunkti.
Hostide otsene ühendamine massiiviga, kuigi seda toetatakse, pole tungivalt soovitatav. Kõigi Flash-massiivide jõudlus on üsna kõrge. Ja maksimaalse kiiruse saavutamiseks tuleb kasutada kõiki massiivi porte. Seetõttu on vähemalt ühe lüliti olemasolu hostide ja NeoSapphire™ vahel kohustuslik.
Kahe pordi olemasolu hosti HBA-l on samuti kohustuslik nõue, et saavutada maksimaalne jõudlus ja tagada tõrketaluvus.
Fibre Channel liidese kasutamisel tuleb tsoneerimine konfigureerida, et välistada võimalikud kokkupõrked algatajate ja sihtmärkide vahel. Tsoonid on üles ehitatud põhimõttel "üks initsiaatorport – üks või mitu massiivi porti".
Kui kasutate ühendust iSCSI kaudu, kui kasutate muude teenustega jagatud kommutaatorit, on hädavajalik isoleerida iSCSI-liiklus eraldi VLAN-is. Samuti on tungivalt soovitatav lubada Jumbo Frames'i (MTU = 9000) tugi, et suurendada võrgus olevate pakettide suurust ja seeläbi vähendada edastuse ajal edastatava teabe hulka. Siiski tasub meeles pidada, et korrektseks tööks on vaja muuta MTU parameetrit kõigil võrgukomponentidel ahelas "initsiaator-lüliti-sihtmärk".
Kogu Flashi massiivi seadistamine
Massiiv tarnitakse juba moodustatud rühmadega klientidele . Seetõttu ei ole ajamite üheks struktuuriks ühendamiseks vaja midagi ette võtta. Peate lihtsalt looma vajaliku suuruse ja koguse mahud.
Mugavuse huvides on funktsioon mitme kindla suurusega köite korraga loomiseks. Vaikimisi luuakse õhukesed mahud, kuna see võimaldab saadaolevat salvestusruumi tõhusamalt kasutada (sh ruumi taastamise tugi). Toimivuse osas ei ületa "õhukeste" ja "paksude" mahtude erinevus 1%. Kui aga soovite massiivist "kogu mahla välja pigistada", saate alati mis tahes "õhukese" mahu "paksuks". Kuid tuleb meeles pidada, et selline operatsioon on pöördumatu.
Järgmiseks jääb üle loodud köite "avaldamine" ja neile juurdepääsuõigused hostidelt, kasutades ACL-e (iSCSI IP-aadressid ja FC jaoks WWPN) ning massiiviportide füüsilist eraldamist. iSCSI mudelite puhul tehakse seda sihtmärgi loomisega.
FC-mudelite puhul toimub avaldamine massiivi iga pordi jaoks LUN-i loomise kaudu.
Seadistusprotsessi kiirendamiseks saab hoste ühendada rühmadesse. Veelgi enam, kui host kasutab mitmepordilist FC HBA-d (mis praktikas kõige sagedamini juhtub), määrab süsteem tänu ühe võrra erinevatele WWPN-idele automaatselt, et sellise HBA pordid kuuluvad ühele hostile. Mõlema liidese puhul toetatakse ka Target/LUN-i partii loomist.
Oluline märkus iSCSI-liidese kasutamisel on jõudluse suurendamiseks luua köidetele korraga mitu sihtmärki, kuna sihtmärgi järjekorda ei saa muuta ja see on tegelikult kitsaskoht.
ESXi hostide konfigureerimine
ESXi hosti poolel tehakse põhikonfiguratsioon täiesti oodatud stsenaariumi järgi. iSCSI-ühenduse protseduur:
- Lisa tarkvara iSCSI-adapter (ei ole vajalik, kui see on juba lisatud või kui kasutate riistvaralist iSCSI-adapterit);
- vSwitchi loomine, mille kaudu iSCSI-liiklus läbib, ning sellele füüsilise üleslingi ja VMkernali lisamine;
- Massiivi aadresside lisamine Dynamic Discoverysse;
- Andmesalve loomine
Mõned olulised märkused:
- Üldjuhul saab muidugi kasutada olemasolevat vSwitchi, kuid eraldi vSwitchi puhul on hosti seadete haldamine palju lihtsam.
- Toimivusprobleemide vältimiseks on vaja eraldada haldus- ja iSCSI-liiklus eraldi füüsilisteks linkideks ja/või VLAN-ideks.
- VMkernali IP-aadressid ja massiivi All Flash vastavad pordid peavad olema samas alamvõrgus, jällegi jõudlusprobleemide tõttu.
- VMware reeglite järgi tõrketaluvuse tagamiseks peab vSwitchil olema vähemalt kaks füüsilist üleslinki
- Kui kasutatakse Jumbo Frame'i, peate muutma nii vSwitchi kui ka VMkernali MTU-d
- Kasulik oleks teile meelde tuletada, et vastavalt VMware soovitustele füüsilistele adapteritele, mida kasutatakse iSCSI-liiklusega töötamiseks, on vaja konfigureerida Teaming ja Failover. Eelkõige peab iga VMkernal töötama ainult ühe üleslingi kaudu, teine üleslingi tuleb lülitada kasutamata režiimi. Veataluvuse tagamiseks peate lisama kaks VMkernali, millest igaüks töötab oma üleslingi kaudu.
VMkerneli adapter (vmk#)
Füüsiline võrguadapter (vmnic#)
vmk1 (Storage01)
Aktiivsed adapterid
vmnic2
Kasutamata adapterid
vmnic3
vmk2 (Storage02)
Aktiivsed adapterid
vmnic3
Kasutamata adapterid
vmnic2
Fibre Channeli kaudu ühenduse loomiseks pole eeltoiminguid vaja. Saate kohe luua andmesalve.
Pärast andmesalve loomist peate veenduma, et Round Robin poliitikat sihtmärgi/LUN-i teede jaoks kasutatakse kõige tõhusamalt.
Vaikimisi näevad VMware seaded ette selle poliitika kasutamise vastavalt skeemile: 1000 päringut läbi esimese tee, järgmised 1000 päringut teise tee kaudu jne. Selline suhtlus hosti ja kahe kontrolleri massiivi vahel on tasakaalustamata. Seetõttu soovitame Esxcli/PowerCLI kaudu määrata parameetri Round Robin = 1.
Parameetrid
Esxcli jaoks:
- Loetlege saadaolevad LUN-id
esxcli salvestusruumi nmp-seadmete loend
- Kopeerige seadme nimi
- Round Robini poliitika muutmine
esxcli salvestusruum nmp psp roundrobin deviceconfig set —type=iops —iops=1 —device=“Seadme_ID”
Enamik kaasaegseid rakendusi on loodud suurte andmepakettide vahetamiseks, et maksimeerida ribalaiuse kasutamist ja vähendada protsessori koormust. Seetõttu väljastab ESXi vaikimisi sisend-/väljundpäringuid salvestusseadmele kuni 32767 kB suuruste tükkidena. Mõne stsenaariumi korral on väiksemate tükkide vahetamine siiski produktiivsem. AccelStori massiivide puhul on järgmised stsenaariumid.
- Virtuaalne masin kasutab pärand-BIOS-i asemel UEFI-d
- Kasutab vSphere'i replikatsiooni
Selliste stsenaariumide puhul on soovitatav muuta parameetri Disk.DiskMaxIOSize väärtuseks 4096.
iSCSI-ühenduste puhul on soovitatav muuta sisselogimise ajalõpu parameetriks 30 (vaikimisi 5), et suurendada ühenduse stabiilsust ja keelata edasisaadetud pakettide kinnituste viivitus DelayedAck. Mõlemad suvandid on vSphere Clientis: Host → Seadistamine → Salvestus → Salvestusadapterid → iSCSI-adapteri täpsemad suvandid
Üsna peen punkt on andmesalve jaoks kasutatud köidete arv. On selge, et haldamise hõlbustamiseks soovitakse luua üks suur köide kogu massiivi mahule. Kuid mitme köite ja vastavalt ka andmesalve olemasolu mõjutab üldist jõudlust soodsalt (järjekordade kohta leiate lähemalt allpool). Seetõttu soovitame luua vähemalt kaks köidet.
Veel suhteliselt hiljuti soovitas VMware piirata virtuaalmasinate arvu ühes andmesalves, et saavutada võimalikult suur jõudlus. Kuid nüüd, eriti VDI levikuga, pole see probleem enam nii terav. Kuid see ei tühista pikaajalist reeglit - levitada intensiivset IO-d nõudvaid virtuaalmasinaid erinevates andmehoidlates. Virtuaalsete masinate optimaalse arvu kindlaksmääramiseks köite kohta pole midagi paremat oma infrastruktuuri piires.
Virtuaalsete masinate seadistamine
Virtuaalsete masinate seadistamisel pole erinõudeid või pigem on need üsna tavalised:
- Kõrgeima võimaliku VM-i versiooni kasutamine (ühilduvus)
- Ettevaatlikum on RAM-i suuruse määramine virtuaalmasinate tihedal paigutamisel, näiteks VDI-sse (kuna vaikimisi luuakse käivitamisel RAM-ile vastava suurusega lehefail, mis kulutab kasulikku mahtu ja avaldab mõju viimane esitus)
- Kasutage IO osas kõige produktiivsemaid adapteriversioone: võrgutüüp VMXNET 3 ja SCSI tüüp PVSCSI
- Maksimaalse jõudluse saavutamiseks kasutage Thick Provision Eager Zeroed kettatüüpi ja salvestusruumi maksimaalseks ärakasutamiseks Thin Provisioningi
- Võimalusel piirake mitte-I/O-kriitiliste masinate tööd Virtual Disk Limit abil
- Installige kindlasti VMware Tools
Märkused järjekordade kohta
Järjekord (või tasumata sisendid/väljundid) on sisend-/väljundpäringute (SCSI-käskude) arv, mis konkreetse seadme/rakenduse jaoks igal ajahetkel töötlemist ootavad. Järjekorra ületäitumise korral väljastatakse QFULL-i vead, mille tulemuseks on lõpuks latentsusparameetri suurenemine. Ketta (spindli) salvestussüsteemide kasutamisel on teoreetiliselt nii, et mida kõrgem on järjekord, seda suurem on nende jõudlus. Kuid te ei tohiks seda kuritarvitada, kuna QFULL-i on lihtne sattuda. Kõikide Flashi süsteemide puhul on ühest küljest kõik mõnevõrra lihtsam: on ju massiivi latentsusajad suurusjärgu võrra väiksemad ja seetõttu pole enamasti vaja järjekordade suurust eraldi reguleerida. Kuid teisest küljest on mõne kasutusstsenaariumi korral (konkreetsete virtuaalmasinate IO nõuete tugev kalduvus, maksimaalse jõudluse testid jne) vaja kui mitte muuta järjekordade parameetreid, siis vähemalt aru saada, millised näitajad on on võimalik saavutada ja peamine on see, mis viisil.
AccelStor All Flash-massiivil endal ei ole helitugevuste ega I/O-portide osas piiranguid. Vajadusel võib isegi üks köide vastu võtta kõik massiivi ressursid. Järjekorra ainus piirang on iSCSI sihtmärkide jaoks. Just sel põhjusel viidati eespool vajadusele luua iga köite jaoks mitu (ideaaljuhul kuni 8 tükki) sihtmärki, et see piir ületada. Kordame ka, et AccelStori massiivid on väga produktiivsed lahendused. Seetõttu peaksite maksimaalse kiiruse saavutamiseks kasutama kõiki süsteemi liidese porte.
ESXi hosti poolel on olukord täiesti erinev. Võõrustaja ise rakendab kõigi osalejate jaoks võrdset juurdepääsu ressurssidele. Seetõttu on külalis-OS-i ja HBA jaoks eraldi IO-järjekorrad. Külalis-OS-i järjekorrad kombineeritakse virtuaalse SCSI-adapteri ja virtuaalse ketta järjekordadest:
Järjekord HBA-sse sõltub konkreetsest tüübist/müüjast:
Virtuaalse masina lõpliku jõudluse määrab hostikomponentide madalaim järjekorra sügavuse piirang.
Tänu nendele väärtustele saame hinnata toimivusnäitajaid, mida konkreetses konfiguratsioonis saame. Näiteks tahame teada virtuaalse masina teoreetilist jõudlust (ilma ploki sidumiseta) latentsusajaga 0.5 ms. Siis selle IOPS = (1,000/latentsus) * Tasumata sisendid/väljundid (järjekorra sügavuse piirang)
näited
Näide 1
- FC Emulex HBA adapter
- Üks VM andmesalve kohta
- VMware paravirtuaalne SCSI-adapter
Siin määrab järjekorra sügavuse piirangu Emulex HBA. Seetõttu IOPS = (1000/0.5)*32 = 64K
Näide 2
- VMware iSCSI tarkvaraadapter
- Üks VM andmesalve kohta
- VMware paravirtuaalne SCSI-adapter
Siin määrab järjekorra sügavuse piirangu juba paravirtuaalne SCSI-adapter. Seetõttu IOPS = (1000/0.5)*64 = 128K
Kõikide Flash AccelStori massiivide tippmudelid (näiteks ) on võimelised pakkuma 700K IOPS-i kirjutamisjõudlust 4K-plokis. Sellise ploki suuruse juures on üsna ilmne, et üksainus virtuaalmasin ei ole võimeline sellist massiivi laadima. Selleks vajate 11 (näiteks 1) või 6 (näiteks 2) virtuaalmasinat.
Selle tulemusel võite virtuaalse andmekeskuse kõigi kirjeldatud komponentide õige konfigureerimisega saavutada jõudluse osas väga muljetavaldavaid tulemusi.
4K juhuslik, 70% lugemine/30% kirjutamine
Tegelikult on tegelik maailm palju keerulisem, kui seda lihtsa valemiga kirjeldada saab. Üks host majutab alati mitut erineva konfiguratsiooni ja IO-nõuetega virtuaalmasinat. Ja sisend-/väljundtöötlusega tegeleb hostprotsessor, mille võimsus ei ole lõputu. Niisiis, et avada selle kogu potentsiaal tegelikkuses vajate kolme hosti. Lisaks teevad virtuaalmasinates töötavad rakendused oma muudatusi. Seetõttu pakume täpse suuruse määramiseks Kõik Flash-massiivid kliendi infrastruktuuri sees tegelike jooksvate ülesannete täitmisel.
Allikas: www.habr.com