Tässä artikkelissa haluan puhua kaikkien Flash AccelStor -taulukoiden ominaisuuksista, jotka toimivat yhdessä suosituimmista virtualisointialustoista - VMware vSphere. Keskity erityisesti niihin parametreihin, jotka auttavat sinua saamaan maksimaalisen vaikutuksen käyttämällä niin tehokasta työkalua kuin All Flash.
AccelStor NeoSapphire™ Kaikki Flash-järjestelmät ovat tai solmulaitteet, jotka perustuvat SSD-asemiin, joilla on täysin erilainen lähestymistapa tiedontallennuskonseptin toteuttamiseen ja pääsyn järjestämiseen patentoidulla tekniikalla suosittujen RAID-algoritmien sijaan. Taulukot tarjoavat estopääsyn isännille kuitukanava- tai iSCSI-rajapintojen kautta. Ollakseni rehellinen, huomaamme, että malleissa, joissa on ISCSI-liitäntä, on myös tiedostojen käyttöoikeus mukavana bonuksena. Mutta tässä artikkelissa keskitymme lohkoprotokollien käyttöön All Flashin tuottavimpana.
Koko AccelStor-taulukon ja VMware vSphere -virtualisointijärjestelmän käyttöönotto- ja konfigurointiprosessi voidaan jakaa useisiin vaiheisiin:
- Yhteystopologian käyttöönotto ja SAN-verkon konfigurointi;
- Kaikkien Flash-taulukoiden määrittäminen;
- ESXi-isäntien määrittäminen;
- Virtuaalikoneiden asentaminen.
Esimerkkilaitteistona käytettiin AccelStor NeoSapphire™ Fibre Channel - ja iSCSI-matriiseja. Perusohjelmisto on VMware vSphere 6.7U1.
Ennen tässä artikkelissa kuvattujen järjestelmien käyttöönottoa on erittäin suositeltavaa lukea VMwaren dokumentaatio suorituskykyongelmista ( ) ja iSCSI-asetukset ()
Yhteystopologia ja SAN-verkkokokoonpano
SAN-verkon pääkomponentit ovat HBA:t ESXi-isännissä, SAN-kytkimet ja ryhmäsolmut. Tyypillinen topologia tällaiselle verkolle näyttäisi tältä:
Termi Switch viittaa tässä sekä erilliseen fyysiseen kytkimeen tai kytkimien joukkoon (Fabric) että laitteeseen, joka on jaettu eri palvelujen välillä (VSAN Fibre Channelin tapauksessa ja VLAN iSCSI:n tapauksessa). Kahden erillisen kytkimen/kankaan käyttö eliminoi mahdollisen vikakohdan.
Isäntien suoraa yhdistämistä taulukkoon ei suositella, vaikka se on tuettu. Kaikkien Flash-taulukoiden suorituskyky on melko korkea. Ja maksimaalisen nopeuden saavuttamiseksi on käytettävä kaikkia taulukon portteja. Siksi vähintään yhden kytkimen läsnäolo isäntien ja NeoSapphire™:n välillä on pakollista.
Kahden portin läsnäolo isäntä-HBA:ssa on myös pakollinen vaatimus maksimaalisen suorituskyvyn saavuttamiseksi ja vikasietoisuuden varmistamiseksi.
Fibre Channel -liitäntää käytettäessä kaavoitus on määritettävä siten, että mahdolliset törmäykset aloitteentekijöiden ja kohteiden välillä voidaan eliminoida. Vyöhykkeet on rakennettu periaatteella "yksi aloitusportti – yksi tai useampi ryhmäportti".
Jos käytät iSCSI-yhteyttä muiden palvelujen kanssa jaetun kytkimen käytössä, on välttämätöntä eristää iSCSI-liikenne erillisessä VLAN-verkossa. On myös erittäin suositeltavaa ottaa käyttöön Jumbo Frames (MTU = 9000) tuki verkon pakettien koon kasvattamiseksi ja siten tiedonsiirron aikana lähetettävän tiedon määrän vähentämiseksi. On kuitenkin syytä muistaa, että oikean toiminnan kannalta on välttämätöntä muuttaa MTU-parametria kaikissa verkkokomponenteissa "initiator-switch-target"-ketjussa.
Asetetaan kaikki Flash-taulukko
Matriisi toimitetaan asiakkaille, joilla on jo muodostettu ryhmä . Siksi taajuusmuuttajien yhdistämiseksi yhdeksi rakenteeksi ei tarvitse tehdä toimenpiteitä. Sinun tarvitsee vain luoda vaaditun kokoisia ja määrällisiä määriä.
Mukavuuden vuoksi on toiminto, jolla voidaan luoda useita tietyn kokoisia määriä kerralla. Oletuksena luodaan ohuita taltioita, koska tämä mahdollistaa käytettävissä olevan tallennustilan tehokkaamman käytön (mukaan lukien tuki Space Reclamationille). Suorituskyvyn suhteen ero "ohuiden" ja "paksujen" tilavuuksien välillä ei ylitä 1%. Jos kuitenkin haluat "puristaa kaiken mehun" matriisista, voit aina muuntaa minkä tahansa "ohuen" tilavuuden "paksuksi". Mutta on muistettava, että tällainen toimenpide on peruuttamaton.
Seuraavaksi on jäljellä luotujen taltioiden "julkaiseminen" ja niiden käyttöoikeuksien asettaminen isänniltä käyttämällä ACL:itä (IP-osoitteet iSCSI:lle ja WWPN FC:lle) ja fyysistä erottelua ryhmäporttien avulla. iSCSI-malleissa tämä tehdään luomalla kohde.
FC-malleissa julkaisu tapahtuu luomalla LUN jokaiselle taulukon portille.
Asennusprosessin nopeuttamiseksi isännät voidaan yhdistää ryhmiin. Lisäksi, jos isäntä käyttää moniporttista FC HBA:ta (mitä käytännössä useimmiten tapahtuu), niin järjestelmä määrittää automaattisesti, että tällaisen HBA:n portit kuuluvat yhdelle isännälle WWPN-numeroiden, jotka eroavat toisistaan yhdellä. Target/LUN:n eräluomista tuetaan myös molemmissa liitännöissä.
Tärkeä huomautus käytettäessä iSCSI-käyttöliittymää on luoda useita kohteita taltioille kerralla suorituskyvyn lisäämiseksi, koska kohteen jonoa ei voida muuttaa ja se on käytännössä pullonkaula.
ESXi-isäntien määrittäminen
ESXi-isäntäpuolella peruskonfigurointi suoritetaan täysin odotetun skenaarion mukaan. iSCSI-yhteyden muodostaminen:
- Lisää ohjelmisto iSCSI-sovitin (ei vaadita, jos se on jo lisätty tai jos käytät Hardware iSCSI -sovitinta);
- Luodaan vSwitch, jonka kautta iSCSI-liikenne kulkee, ja lisäämällä siihen fyysinen uplink ja VMkernal;
- Matriisiosoitteiden lisääminen Dynamic Discoveryyn;
- Tietosäilön luominen
Muutamia tärkeitä huomautuksia:
- Yleisessä tapauksessa voit tietysti käyttää olemassa olevaa vSwitchiä, mutta erillisen vSwitchin tapauksessa isäntäasetusten hallinta on paljon helpompaa.
- Hallinta- ja iSCSI-liikenne on erotettava erillisiin fyysisiin linkkeihin ja/tai VLAN-verkkoihin suorituskykyongelmien välttämiseksi.
- VMkernalin IP-osoitteiden ja vastaavien All Flash -taulukon porttien on oltava samassa aliverkossa, jälleen suorituskykyongelmien vuoksi.
- VMware-sääntöjen mukaisen vikasietoisuuden varmistamiseksi vSwitchillä on oltava vähintään kaksi fyysistä uplink-linkkiä
- Jos Jumbo Frame -kehyksiä käytetään, sinun on vaihdettava sekä vSwitchin että VMkernalin MTU
- Olisi hyödyllistä muistuttaa, että VMwaren suositusten mukaan fyysisille sovittimille, joita käytetään iSCSI-liikenteen kanssa, on tarpeen määrittää Teaming ja Failover. Erityisesti jokaisen VMkernalin tulee toimia vain yhden uplink-linkin kautta, toinen uplink on kytkettävä käyttämättömään tilaan. Vikasietokykyä varten sinun on lisättävä kaksi VMkernalia, joista jokainen toimii oman uplink-linkkinsä kautta.
VMkernel-sovitin (vmk#)
Fyysinen verkkosovitin (vmnic#)
vmk1 (Tallennus01)
Aktiiviset sovittimet
vmnic2
Käyttämättömät adapterit
vmnic3
vmk2 (Tallennus02)
Aktiiviset sovittimet
vmnic3
Käyttämättömät adapterit
vmnic2
Yhteyden muodostaminen kuitukanavan kautta ei vaadi ennakkotoimenpiteitä. Voit luoda Datastoren välittömästi.
Tietosäilön luomisen jälkeen sinun on varmistettava, että Round Robin -käytäntöä poluille Target/LUNiin käytetään tehokkaimpana.
Oletusarvoisesti VMware-asetukset mahdollistavat tämän käytännön käytön järjestelmän mukaisesti: 1000 pyyntöä ensimmäisen polun kautta, seuraavat 1000 pyyntöä toisen polun kautta jne. Tällainen isännän ja kahden ohjaimen ryhmän välinen vuorovaikutus on epätasapainoinen. Siksi suosittelemme Round Robin -käytäntö = 1 -parametrin asettamista Esxcli/PowerCLI:n kautta.
Parametrit
Esxcli:
- Listaa käytettävissä olevat LUN:t
esxcli-tallennus nmp-laiteluettelo
- Kopioi laitteen nimi
- Muuta Round Robin -käytäntöä
esxcli-tallennustila nmp psp roundrobin laitekokoonpano —type=iops —iops=1 —device=“Device_ID”
Useimmat nykyaikaiset sovellukset on suunniteltu vaihtamaan suuria datapaketteja kaistanleveyden maksimoimiseksi ja prosessorin kuormituksen vähentämiseksi. Siksi ESXi lähettää oletusarvoisesti I/O-pyynnöt tallennuslaitteelle jopa 32767 kt:n paloina. Joissakin skenaarioissa pienempien osien vaihtaminen on kuitenkin tuottavampaa. AccelStor-taulukot ovat seuraavat:
- Virtuaalikone käyttää UEFI:ää Legacy BIOSin sijaan
- Käyttää vSphere-replikointia
Tällaisissa skenaarioissa on suositeltavaa muuttaa Disk.DiskMaxIOSize-parametrin arvoksi 4096.
iSCSI-yhteyksissä on suositeltavaa muuttaa Login Timeout -parametrin arvoksi 30 (oletusarvo 5) yhteyden vakauden lisäämiseksi ja DelayedAck-viiveen poistamiseksi käytöstä edelleenlähetettyjen pakettien vahvistuksille. Molemmat vaihtoehdot ovat vSphere Clientissä: Isäntä → Määritä → Tallennus → Tallennussovittimet → iSCSI-sovittimen lisäasetukset
Melko hienovarainen kohta on tietovarastoon käytettyjen taltioiden määrä. On selvää, että hallinnan helpottamiseksi halutaan luoda yksi suuri volyymi koko taulukon tilavuudelle. Useiden taltioiden ja vastaavasti tietovaraston läsnäolo vaikuttaa kuitenkin suotuisasti yleiseen suorituskykyyn (lisätietoja jonoista alla). Siksi suosittelemme luomaan vähintään kaksi osaa.
Suhteellisen äskettäin asti VMware neuvoi rajoittamaan virtuaalikoneiden määrää yhdessä tietovarastossa, jälleen parhaan mahdollisen suorituskyvyn saavuttamiseksi. Nyt, varsinkin VDI:n leviämisen myötä, tämä ongelma ei kuitenkaan ole enää niin akuutti. Mutta tämä ei kumoa pitkäaikaista sääntöä - jakaa virtuaalikoneita, jotka vaativat intensiivistä IO:ta eri tietovarastoissa. Virtuaalikoneiden optimaalisen määrän määrittämiseksi tilavuutta kohden ei ole mitään parempaa kuin sen infrastruktuurissa.
Virtuaalikoneiden asentaminen
Virtuaalikoneita määritettäessä ei ole erityisiä vaatimuksia, tai pikemminkin ne ovat melko tavallisia:
- Korkeimman mahdollisen VM-version käyttäminen (yhteensopivuus)
- On huolellisempaa asettaa RAM-muistin koko, kun virtuaalikoneita sijoitetaan tiheään esimerkiksi VDI:hen (koska oletuksena käynnistettäessä luodaan RAM-muistia vastaavan kokoinen sivutiedosto, joka kuluttaa hyödyllistä kapasiteettia ja vaikuttaa viimeinen esitys)
- Käytä IO:n kannalta tuottavimpia sovitinversioita: verkkotyyppi VMXNET 3 ja SCSI-tyyppi PVSCSI
- Käytä Thick Provision Eager Zeroed -levytyyppiä maksimaalisen suorituskyvyn saavuttamiseksi ja Thin Provisioningia tallennustilan maksimaaliseen käyttöön
- Jos mahdollista, rajoita muiden kuin I/O-kriittisten koneiden toimintaa Virtual Disk Limit -sovelluksella
- Muista asentaa VMware Tools
Huomautuksia jonoista
Jono (tai Outstanding I/Os) on niiden syöttö-/lähtöpyyntöjen (SCSI-komentojen) määrä, jotka odottavat tietyn laitteen/sovelluksen käsittelyä kulloinkin. Jos jonon ylivuoto tapahtuu, QFULL-virheitä annetaan, mikä lopulta johtaa latenssiparametrin kasvuun. Levy- (kara) -tallennusjärjestelmiä käytettäessä teoriassa mitä korkeampi jono, sitä parempi niiden suorituskyky. Sinun ei kuitenkaan pidä käyttää sitä väärin, koska siihen on helppo törmätä QFULLiin. Kaikkien Flash-järjestelmien tapauksessa kaikki on toisaalta hieman yksinkertaisempaa: taulukossa on kuitenkin suuruusluokkaa pienemmät latenssit ja siksi jonojen kokoa ei useimmiten tarvitse erikseen säädellä. Mutta toisaalta joissakin käyttöskenaarioissa (joiden virtuaalikoneiden IO-vaatimusten voimakas vino, maksimaalisen suorituskyvyn testit jne.) on välttämätöntä, jos ei muuttaa jonojen parametreja, niin ainakin ymmärtää, mitkä indikaattorit voidaan saavuttaa, ja pääasia on millä tavoin.
Itse AccelStor All Flash -ryhmässä ei ole rajoituksia volyymeille tai I/O-porteille. Tarvittaessa jopa yksi taltio voi vastaanottaa kaikki taulukon resurssit. Ainoa jonon rajoitus koskee iSCSI-kohteita. Tästä syystä edellä mainittiin tarve luoda useita (mieluiten jopa 8 kappaletta) kohdetta kullekin levylle tämän rajan ylittämiseksi. Toistakaamme myös, että AccelStor-taulukot ovat erittäin tuottavia ratkaisuja. Siksi sinun tulee käyttää kaikkia järjestelmän liitäntäportteja maksiminopeuden saavuttamiseksi.
ESXi-isäntäpuolella tilanne on täysin erilainen. Isäntä itse soveltaa käytäntöä, jonka mukaan resurssit ovat yhtäläiset kaikille osallistujille. Siksi vieraskäyttöjärjestelmälle ja HBA:lle on erilliset IO-jonot. Vieraskäyttöjärjestelmän jonot yhdistetään jonoista virtuaaliseen SCSI-sovittimeen ja virtuaalilevyyn:
Jono HBA:han riippuu tietystä tyypistä/toimittajasta:
Virtuaalikoneen lopullinen suorituskyky määräytyy isäntäkomponenttien alimman Jonon syvyysrajan mukaan.
Näiden arvojen ansiosta voimme arvioida suoritusindikaattoreita, jotka voimme saada tietyssä kokoonpanossa. Haluamme esimerkiksi tietää virtuaalikoneen (ilman lohkosidontaa) teoreettisen suorituskyvyn, jonka latenssi on 0.5 ms. Sitten sen IOPS = (1,000 XNUMX/latenssi) * jäljellä olevat I/O:t (jonon syvyysraja)
Примеры
Esimerkki 1
- FC Emulex HBA -sovitin
- Yksi VM per tietovarasto
- VMwaren paravirtuaalinen SCSI-sovitin
Tässä Jonon syvyysrajan määrittää Emulex HBA. Siksi IOPS = (1000/0.5)*32 = 64K
Esimerkki 2
- VMware iSCSI -ohjelmistosovitin
- Yksi VM per tietovarasto
- VMwaren paravirtuaalinen SCSI-sovitin
Tässä jonon syvyysrajan määrittää jo Paravirtual SCSI -sovitin. Siksi IOPS = (1000/0.5)*64 = 128K
Kaikkien Flash AccelStor -taulukoiden huippumallit (esim. ) pystyvät tuottamaan 700K IOPS-kirjoitussuorituskyvyn 4K-lohkolla. Tällaisella lohkokoolla on ilmeistä, että yksittäinen virtuaalikone ei pysty lataamaan tällaista taulukkoa. Tätä varten tarvitset 11 (esimerkiksi 1) tai 6 (esimerkiksi 2) virtuaalikoneita.
Tämän seurauksena voit saada erittäin vaikuttavia tuloksia suorituskyvyn suhteen, kun kaikki kuvatut virtuaalisen datakeskuksen komponentit on määritetty oikein.
4K satunnainen, 70 % luku/30 % kirjoitus
Itse asiassa todellinen maailma on paljon monimutkaisempi kuin sitä voidaan kuvata yksinkertaisella kaavalla. Yksi isäntä isännöi aina useita virtuaalikoneita, joilla on erilaiset kokoonpanot ja IO-vaatimukset. Ja I/O-käsittelystä huolehtii isäntäprosessori, jonka teho ei ole ääretön. Joten vapauttaaksesi sen täyden potentiaalin todellisuudessa tarvitset kolme isäntää. Lisäksi virtuaalikoneiden sisällä toimivat sovellukset tekevät omat säätönsä. Siksi tarjoamme tarkan mitoituksen Kaikki Flash-taulukot asiakkaan infrastruktuurin sisällä todellisissa ajankohtaisissa tehtävissä.
Lähde: will.com