Í þessari grein langar mig að tala um eiginleika All Flash AccelStor fylki sem vinna með einum vinsælasta virtualization pallinum - VMware vSphere. Einbeittu þér sérstaklega að þeim breytum sem hjálpa þér að ná hámarksáhrifum af því að nota svo öflugt tól eins og All Flash.
AccelStor NeoSapphire™ Öll Flash fylki eru eða hnútatæki byggð á SSD drifum með í grundvallaratriðum mismunandi nálgun við að útfæra hugmyndina um gagnageymslu og skipuleggja aðgang að því með sértækni í stað hinna mjög vinsælu RAID reiknirit. Fylkin veita gestgjöfum blokkaðgang í gegnum Fibre Channel eða iSCSI tengi. Til að vera sanngjarn, tökum við fram að gerðir með ISCSI viðmóti hafa einnig skráaaðgang sem góðan bónus. En í þessari grein munum við einbeita okkur að notkun blokkarsamskiptareglna sem afkastamesta fyrir All Flash.
Allt ferlið við uppsetningu og síðari uppsetningu á sameiginlegri starfsemi AccelStor fylkisins og VMware vSphere sýndarvæðingarkerfisins má skipta í nokkur stig:
- Framkvæmd tenginga svæðisfræði og stillingar á SAN neti;
- Setja upp All Flash array;
- Stilla ESXi vélar;
- Að setja upp sýndarvélar.
AccelStor NeoSapphire™ Fibre Channel fylki og iSCSI fylki voru notuð sem sýnishorn af vélbúnaði. Grunnhugbúnaðurinn er VMware vSphere 6.7U1.
Áður en þú setur upp kerfin sem lýst er í þessari grein er mjög mælt með því að þú lesir skjölin frá VMware varðandi frammistöðuvandamál ( ) og iSCSI stillingar ()
Tengingarfræði og SAN netstillingar
Helstu þættir SAN nets eru HBA í ESXi vélum, SAN rofar og fylkishnútar. Dæmigerð staðfræði fyrir slíkt net myndi líta svona út:
Hugtakið Rofi vísar hér bæði til aðskilins líkamlegs rofa eða rofasetts (Fabric) og tækis sem deilt er á milli mismunandi þjónustu (VSAN þegar um Fibre Channel er að ræða og VLAN þegar um iSCSI er að ræða). Notkun tveggja óháðra rofa/efna mun útrýma hugsanlegum bilunarpunkti.
Ekki er mælt með beinni tengingu gestgjafa við fylkið, þó hún sé studd. Afköst All Flash fylkja eru nokkuð mikil. Og fyrir hámarkshraða verður að nota allar hafnir fylkisins. Þess vegna er tilvist að minnsta kosti einn skipti á milli vélanna og NeoSapphire™ skylda.
Tilvist tveggja hafna á hýsil HBA er einnig skyldubundin krafa til að ná hámarksafköstum og tryggja bilanaþol.
Þegar notast er við Fibre Channel tengi verður að stilla svæðisskipulag til að koma í veg fyrir mögulega árekstra milli frumkvöðla og skotmarka. Svæði eru byggð á meginreglunni um „ein frumkvöðlahöfn – ein eða fleiri fylkishöfn.
Ef þú notar tengingu í gegnum iSCSI ef þú notar rofa sem er deilt með öðrum þjónustum, þá er mikilvægt að einangra iSCSI umferð innan sérstakrar VLAN. Það er líka mjög mælt með því að virkja stuðning fyrir Jumbo Frames (MTU = 9000) til að auka stærð pakka á netinu og minnka þar með magn kostnaðarupplýsinga við sendingu. Hins vegar er þess virði að muna að fyrir rétta notkun er nauðsynlegt að breyta MTU færibreytunni á öllum nethlutum meðfram „initiator-switch-target“ keðjunni.
Setja upp All Flash array
Fylkið er afhent viðskiptavinum með þegar myndaða hópa . Þess vegna þarf ekki að grípa til aðgerða til að sameina drif í eitt mannvirki. Þú þarft bara að búa til magn af nauðsynlegri stærð og magni.
Til þæginda er virkni til að búa til lotu af nokkrum bindum af tiltekinni stærð í einu. Sjálfgefið er að þunnt bindi er búið til þar sem það gerir kleift að nýta tiltækt geymslupláss á skilvirkari hátt (þar á meðal stuðningur við Space Reclamation). Hvað varðar frammistöðu er munurinn á „þunnu“ og „þykku“ rúmmáli ekki meiri en 1%. Hins vegar, ef þú vilt „kreista allan safann“ úr fylki, geturðu alltaf breytt hvaða „þunnu“ rúmmáli sem er í „þykkt“. En það ber að hafa í huga að slík aðgerð er óafturkræf.
Næst er eftir að „birta“ stofnuðu bindi og stilla aðgangsrétt á þau frá hýsingum með því að nota ACL (IP tölur fyrir iSCSI og WWPN fyrir FC) og líkamlega aðskilnað með fylkishöfnum. Fyrir iSCSI módel er þetta gert með því að búa til Target.
Fyrir FC módel á sér stað birting með því að búa til LUN fyrir hverja höfn fylkisins.
Til að flýta fyrir uppsetningarferlinu er hægt að sameina gestgjafa í hópa. Þar að auki, ef gestgjafinn notar multiport FC HBA (sem í reynd gerist oftast), þá ákvarðar kerfið sjálfkrafa að port slíkrar HBA tilheyri einum gestgjafa þökk sé WWPN sem eru frábrugðin einum. Hópgerð Target/LUN er einnig studd fyrir bæði viðmótin.
Mikilvæg athugasemd þegar þú notar iSCSI viðmótið er að búa til mörg markmið fyrir bindi í einu til að auka afköst, þar sem biðröðinni á markinu er ekki hægt að breyta og verður í raun flöskuháls.
Stilla ESXi Hosts
Á ESXi hýsilhliðinni er grunnstilling framkvæmd í samræmi við algjörlega búist við atburðarás. Aðferð fyrir iSCSI tengingu:
- Bæta við hugbúnaði iSCSI millistykki (ekki krafist ef honum hefur þegar verið bætt við, eða ef þú ert að nota iSCSI millistykki fyrir vélbúnað);
- Að búa til vSwitch sem iSCSI umferð mun fara í gegnum og bæta líkamlegum upptengli og VMkernel við það;
- Að bæta fylkisföngum við Dynamic Discovery;
- Stofnun gagnageymslu
Nokkrar mikilvægar athugasemdir:
- Í almennu tilvikinu geturðu auðvitað notað núverandi vSwitch, en ef um sérstakan vSwitch er að ræða, verður stjórnun hýsilstillinganna miklu auðveldara.
- Nauðsynlegt er að aðskilja stjórnun og iSCSI umferð á aðskilda líkamlega tengla og/eða VLAN til að forðast frammistöðuvandamál.
- IP-tölur VMkernelsins og samsvarandi tengi All Flash fylkisins verða að vera innan sama undirnets, aftur vegna afköstunarvandamála.
- Til að tryggja bilanaþol samkvæmt VMware reglum verður vSwitch að hafa að minnsta kosti tvo líkamlega upptengla
- Ef Jumbo Frames eru notaðir þarftu að breyta MTU bæði vSwitch og VMkernel
- Það væri gagnlegt að minna þig á að samkvæmt VMware ráðleggingum um líkamlega millistykki sem verða notuð til að vinna með iSCSI umferð, þá er nauðsynlegt að stilla Teaming og Failover. Sérstaklega verður hver VMkernel að vinna í gegnum aðeins einn upptengil, seinni upptengilinn verður að skipta yfir í ónotaðan ham. Fyrir bilanaþol þarftu að bæta við tveimur VMkernel, sem hver um sig virkar í gegnum eigin upptengil.
VMkernel millistykki (vmk#)
Líkamlegt netkort (vmnic#)
vmk1 (Storage01)
Virkir millistykki
vmnic2
Ónotaðir millistykki
vmnic3
vmk2 (Storage02)
Virkir millistykki
vmnic3
Ónotaðir millistykki
vmnic2
Engin bráðabirgðaskref eru nauðsynleg til að tengjast í gegnum Fibre Channel. Þú getur strax búið til Datastore.
Eftir að hafa búið til Datastore þarftu að ganga úr skugga um að Round Robin stefnan fyrir slóðir að Target/LUN sé notuð sem árangursríkasta.
Sjálfgefið er að stillingar VMware gera ráð fyrir notkun þessarar stefnu í samræmi við kerfið: 1000 beiðnir í gegnum fyrstu slóðina, næstu 1000 beiðnir í gegnum seinni slóðina o.s.frv. Slík samskipti milli hýsilsins og tveggja stjórnenda fylkisins verða í ójafnvægi. Þess vegna mælum við með að stilla Round Robin stefnuna = 1 færibreytu í gegnum Esxcli/PowerCLI.
Breytur
Fyrir Esccli:
- Listi yfir tiltæk LUN
esxcli geymslu nmp tæki listi
- Afritaðu heiti tækis
- Breyta Round Robin stefnu
esxcli geymsla nmp psp roundrobin deviceconfig set —type=iops —iops=1 —device=“Device_ID”
Flest nútímaforrit eru hönnuð til að skiptast á stórum gagnapökkum til að hámarka bandbreiddarnýtingu og draga úr CPU álagi. Þess vegna gefur ESXi sjálfgefið út I/O beiðnir til geymslutækisins í klumpur allt að 32767KB. Hins vegar, í sumum tilfellum, mun skiptast á smærri bitum vera afkastameiri. Fyrir AccelStor fylki eru þetta eftirfarandi aðstæður:
- Sýndarvélin notar UEFI í stað Legacy BIOS
- Notar vSphere afritun
Fyrir slíkar aðstæður er mælt með því að breyta gildi færibreytunnar Disk.DiskMaxIOSize í 4096.
Fyrir iSCSI tengingar er mælt með því að breyta innskráningartímanum í 30 (sjálfgefið 5) til að auka tengingarstöðugleika og slökkva á DelayedAck seinkun fyrir staðfestingar á framsendingum pakka. Báðir valkostir eru í vSphere Client: Host → Stilla → Geymsla → Geymslutæki → Ítarlegir valkostir fyrir iSCSI millistykki
Frekar lúmskur punktur er fjöldi binda sem notuð eru fyrir gagnageymsluna. Það er ljóst að til að auðvelda stjórnun er vilji til að búa til eitt stórt bindi fyrir allt rúmmál fylkisins. Hins vegar, tilvist nokkurra binda og, í samræmi við það, gagnageymslu hefur jákvæð áhrif á heildarframmistöðu (meira um biðraðir hér að neðan). Þess vegna mælum við með að búa til að minnsta kosti tvö bindi.
Þar til tiltölulega nýlega ráðlagði VMware að takmarka fjölda sýndarvéla í einni gagnageymslu, aftur til að ná sem mestum afköstum. Hins vegar, sérstaklega með útbreiðslu VDI, er þetta vandamál ekki lengur svo bráð. En þetta dregur ekki úr langvarandi reglu - að dreifa sýndarvélum sem krefjast mikillar IO yfir mismunandi gagnaverslanir. Til að ákvarða ákjósanlegan fjölda sýndarvéla á hvert bindi er ekkert betra en innan innviða þess.
Að setja upp sýndarvélar
Það eru engar sérstakar kröfur þegar þú setur upp sýndarvélar, eða öllu heldur eru þær ósköp venjulegar:
- Að nota hæstu mögulegu VM útgáfuna (samhæfi)
- Það er varkárara að stilla stærð vinnsluminni þegar sýndarvélar eru settar þéttar fyrir, til dæmis í VDI (þar sem sjálfgefið er, við ræsingu, er búið til blaðsíðuskrá af stærð sem samsvarar vinnsluminni, sem eyðir gagnlegri getu og hefur áhrif á lokasýningin)
- Notaðu afkastamestu millistykkisútgáfurnar hvað varðar IO: netgerð VMXNET 3 og SCSI gerð PVSCSI
- Notaðu Thick Provision Eager Zeroed diskagerð fyrir hámarksafköst og Thin Provisioning fyrir hámarksnýtingu geymslupláss
- Ef mögulegt er, takmarkaðu virkni véla sem ekki eru I/O mikilvægar með því að nota Virtual Disk Limit
- Vertu viss um að setja upp VMware Tools
Athugasemdir um biðraðir
Biðröð (eða Outstanding I/Os) er fjöldi inntaks/úttaksbeiðna (SCSI skipana) sem bíða vinnslu á hverjum tíma fyrir tiltekið tæki/forrit. Ef biðröð flæðir yfir eru QFULL villur gefnar út, sem á endanum leiðir til aukningar á biðbreytu. Þegar þú notar diska (snælda) geymslukerfi, fræðilega séð, því hærri biðröð, því meiri afköst þeirra. Hins vegar ættir þú ekki að misnota það, þar sem það er auðvelt að lenda í QFULL. Þegar um All Flash kerfi er að ræða, annars vegar, er allt nokkuð einfaldara: Þegar öllu er á botninn hvolft hefur fylkið töf sem eru stærðargráðum lægri og því er oftast óþarfi að stýra sérstaklega stærð biðraða. En á hinn bóginn, í sumum notkunaratburðarás (mikil skekkja í IO kröfur fyrir sérstakar sýndarvélar, próf fyrir hámarksafköst osfrv.) er nauðsynlegt, ef ekki að breyta breytum biðraðanna, þá að minnsta kosti að skilja hvaða vísbendingar er hægt að ná, og aðalatriðið er með hvaða hætti.
Á AccelStor All Flash fylkinu sjálfu eru engin takmörk í tengslum við magn eða I/O tengi. Ef nauðsyn krefur getur jafnvel eitt bindi tekið við öllum auðlindum fylkisins. Eina takmörkunin á biðröðinni er fyrir iSCSI markmið. Það er af þessari ástæðu að þörfin á að búa til nokkur (helst allt að 8 stykki) skotmörk fyrir hvert bindi til að sigrast á þessum mörkum var gefið til kynna hér að ofan. Við skulum líka endurtaka að AccelStor fylki eru mjög afkastamiklar lausnir. Þess vegna ættir þú að nota allar viðmótstengi kerfisins til að ná hámarkshraða.
Hjá ESXi gestgjafanum er staðan allt önnur. Gestgjafinn sjálfur beitir þeirri framkvæmd jafnan aðgang að auðlindum fyrir alla þátttakendur. Þess vegna eru sérstakar IO biðraðir fyrir gestastýrikerfið og HBA. Biðraðir til gestastýrikerfisins eru sameinaðar úr biðröðum í sýndar SCSI millistykkið og sýndardiskinn:
Biðröð til HBA fer eftir tiltekinni tegund/söluaðila:
Endanleg frammistaða sýndarvélarinnar verður ákvörðuð af lægstu biðraðardýptarmörkum meðal hýsilhlutanna.
Þökk sé þessum gildum getum við metið árangursvísana sem við getum fengið í tiltekinni uppsetningu. Til dæmis viljum við vita fræðilegan árangur sýndarvélar (án blokkabindingar) með leynd upp á 0.5 ms. Þá er IOPS þess = (1,000/leynd) * Framúrskarandi I/Os (takmörk biðraðardýptar)
dæmi
Dæmi 1
- FC Emulex HBA millistykki
- Einn VM í hverja gagnageymslu
- VMware Paravirtual SCSI millistykki
Hér eru biðraðardýptarmörk ákvörðuð af Emulex HBA. Því IOPS = (1000/0.5)*32 = 64K
Dæmi 2
- VMware iSCSI hugbúnaðarmillistykki
- Einn VM í hverja gagnageymslu
- VMware Paravirtual SCSI millistykki
Hér eru biðraðardýptarmörkin þegar ákvörðuð af Paravirtual SCSI millistykkinu. Þess vegna IOPS = (1000/0.5)*64 = 128K
Helstu gerðir af öllum Flash AccelStor fylkjum (til dæmis, ) eru fær um að skila 700K IOPS skrifafköstum við 4K blokk. Með slíkri blokkastærð er alveg augljóst að ein sýndarvél er ekki fær um að hlaða svona fylki. Til að gera þetta þarftu 11 (til dæmis 1) eða 6 (til dæmis 2) sýndarvélar.
Fyrir vikið, með réttri uppsetningu allra lýstra íhluta sýndargagnaversins, geturðu fengið mjög glæsilegar niðurstöður hvað varðar frammistöðu.
4K Random, 70% Lesa/30% Skrifa
Reyndar er raunheimurinn miklu flóknari en hægt er að lýsa honum með einfaldri formúlu. Einn gestgjafi hýsir alltaf margar sýndarvélar með mismunandi stillingar og IO kröfur. Og I/O vinnsla er meðhöndluð af hýsingargjörvanum, en kraftur hans er ekki óendanlegur. Svo, til að opna alla möguleika þess sama í raun og veru þarftu þrjá gestgjafa. Auk þess gera forrit sem keyra inni í sýndarvélum sínar eigin breytingar. Þess vegna bjóðum við upp á nákvæma stærð Öll Flash fylki inni í innviðum viðskiptavinarins um raunveruleg núverandi verkefni.
Heimild: www.habr.com