PowerStore: Tehokkaat tekniikat tallennusjärjestelmän suorituskyvyn arviointiin

Huomautus: Vertailuanalyysi toimii vain, jos kaikki on määritetty PowerStoren parhaiden käytäntöjen mukaisesti eikä yhteys- tai määritysongelmia ole. Muuten testi tuottaa todennäköisesti epäolennaista tietoa.

• Testaa käyttämällä muuttujia, jotka muistuttavat todellista työmäärää/ympäristöä. Muista, että useimmat työkalut ovat simulaattoreita eivätkä koskaan saavuta 100% todellisesta simuloidusta tuotantokuormituksesta.
• Jos kuormitus vaihtelee suuresti, harkitse useiden luku- ja kirjoitustestien iteraatioita eri lohkokokoilla ja käyttöoikeusmalleilla.
• Käytä monisäikeisiä ja asynkronisia toimintoja tai testejä varmistaaksesi rinnakkaiset tai samanaikaiset suorituskykyominaisuudet ja varmistaaksesi, että kokonaissiirtopotentiaalia käytetään. 
• Harkitse ja tarkastele arvioitavien laitteiden alan standardien vertailuarvoja, koska ne liittyvät yrityksesi tuotannon työmäärään.
• Vältä testausta tyhjään tai vähän tilaa käyttävään tiedostojärjestelmään ja/tai taltioihin. Jos et varaa etukäteen tilaa kirjoituskuormituksille, näet viiveen, joka johtuu tilan varaamisesta lennossa testin aikana.
• Älä unohda testata Lue I/O:ta, koska se on yleensä hallitseva näistä kahdesta useimmissa ympäristöissä. Huomioi pakettien/kehysten hävikki verkkoinfrastruktuurissa testauksen aikana.
• Varmista, että testaat useilla laitteilla, jotta voit simuloida tyypillistä ympäristöä, jossa on useita isäntiä tai asiakkaita. Esimerkiksi PowerStoressa hyvä luku on 16 nidettä. Volyymien määrä vastaa yleensä käytettyjen (fyysisten tai virtuaalisten) isäntien tai asiakkaiden määrää. Tässä saavutetaan samanaikaisuus.

 

Benchmarking-työkalut ja simulaattorit
Muista, että useimmat työkalut ovat simulaattoreita, eivätkä ne todennäköisesti koskaan saa 100% todellisesta tuotantokuormituksesta simuloitua. Näitä vertailutyökaluja käytetään saamaan käsitys siitä, miten suorituskyky voisi, pitäisi tai olisi tietyissä tilanteissa. Dell ei omista näitä työkaluja eikä vastaa niihin mahdollisesti liittyvistä ongelmista.

Varmista kaikissa suorituskyvyn testaustilanteissa, että käytetään työkaluja, joissa on asynkroniset ja monisäikeiset ominaisuudet. Esimerkkejä näistä työkaluista:

• Joustava I/O-testeri (FIO)
• IOmeter
• Vdbench (edellyttää Oracle-tiliä)
• NFSometri (Vain Fedora/NFS)
• Intelin NAS-suorituskyvyn tarkistuslista

 

Vältä seuraavan tyyppisiä testejä:

• Kopioi ja liitä
• Veto ja pudotus
• Yhden tiedostojärjestelmän varmuuskopio levylle
• DD-testit
• Suuri
• Vakio
• Mkfile
• Purkaminen, purkaminen ja pakkaaminen

Useimmissa esikuva-analyysiskenaarioissa on otettava huomioon tiettyjä asioita. Tämä osio ei korvaa työmäärän koon ja ominaisuuksien ymmärtämistä. Jos sinulla kuitenkin ei ole aiempia tietoja ja tarvitset karkean arvion sovelluksesi toiminnasta PowerStoren ominaisuuksien vertailemiseksi (ei tietyn kuormituksen suorituskykyä), ota huomioon seuraavat tekijät:

 

 

IODepth(jonon syvyys)
Pieni IO-syvyys (tai liian liian alhainen) voi rajoittaa potentiaalista suorituskykyä tilanteesta riippuen. Tarkista siksi aina, että IOdepth-syvyys on riittävän korkea vastaamaan tai jäljittelemään kuormituksen samanaikaisuusvaatimuksia. Liian alhainen IO-syvyys ei ehkä käytä laitetta oikein täysimääräisesti. Varo myös liian suurta IO-syvyyttä, tämä voi aiheuttaa merkittäviä jonoja laitteessa ja laitteen käyttöajasta riippuen seurauksena voi olla pidempiä vasteaikoja. Tämä voi heijastaa sitä, miltä ylikuormitettu järjestelmä voi näyttää.

Tässä testissä luvut ovat huomattavasti pienempiä, kun IOsyvyys on yksi, verrattuna jonkin todellisemman, kuten 64: n, IO-syvyyteen. Muista, että tämä tapahtuu all-flash-ryhmällä ja siten tämä käsite nähdään äärimmäisessä, mutta yhä yleisemmässä muodossaan."

IOdepth=1" se on noin ~ 30 000 tulo- ja lähtöoperaatiota sekunnissa (IOPS) keskimäärin testiä varten.

 

"IOdepth=64" on testin keskiarvo ~107 000 IOPS.

 

 

"IOdepth=256" on testin keskiarvo ~142 000 IOPS.

 

 

Kuten mainittiin, suorituskyky tasoittuu tiettyyn IOsyvyyteen useimmissa kokoonpanoissa. Täällä jonon syvyys on 512 ja IOPS kasvaa vain vähän IOsyvyydestä 64."

IOdepth=512" se on testin keskiarvo ~146 000 IOPS.

 

 


Asynkronointi vs. synkronointi
Käytössä on kaksi suurta erillistä moottoria. Suosituin ja ylivoimaisesti tehokkain suorituskyvyn kannalta on "asynkroninen I / O". Vähemmän tehokas ja suorituskykyisempi moottorityyppi on synkroninen I/O, ja sitä käytetään yleensä sovelluksissa, joilla on tiukat tietojen eheys- ja varmuusvaatimukset. Synkroninen I/O löytyy myös lähes nollasta palautumispisteen tavoitteen (RPO) replikointitekniikoista. Suorituskyvyn testauksessa ja vertailemisessa isännän näkökulmasta asynkroninen tarkoittaa, että yksittäiselle I/O:lle ei tarvita kuittausta seuraavan I/O:n pyytämiseksi. Synkronisissa työkuormissa I/O:lle tarvitaan kuittaus ennen seuraavan toimen myöntämistä ja kuittaus (ACK) jokaisesta seuraavasta pyydetystä I/O:sta. Tämän vuoksi synkronisessa I/O:ssa on yleensä enintään 1 jono, eikä resurssia koskaan käytetä täysimääräisesti. Synkronisten toimintojen kytkeminen pienellä tai yhdellä säikemäärällä voi rajoittaa suorituskykypotentiaalia vakavasti, joten varmista aina, että teet asynkronista testausta, ja jos käytät synkronista testausta, muista käyttää useita säikeitä, ellei sovellusympäristö nimenomaisesti osoita, ettei sitä ole.

Async (Libaio - Linuxin natiivi asynkronointi) = 1 säikeen



synkronointi (synkroninen I / O):  

 

 

Säikeiden määrä
Langat ovat tärkeitä. Testaus on aina tehtävä käyttämällä useita säikeitä, erityisesti synkronisissa testeissä / työkuormissa. Tällä pyritään simuloimaan työn/testin useita iteraatioita yrityssovelluksen prosessin käyttäytymisen perusteella. Useat säikeet yhdistettynä samanaikaiseen toimintaan ovat silloin, kun järjestelmän kokonaissuorituskyky saavutetaan. Useimmat asynkroniset moottorit käyttävät useita kierteitä, joten sinun ei tarvitse huolehtia kierteiden määrästä niin paljon. Jos säikeitä ei ole riittävästi synkronisten kuormitusten aikana, kuormitustestin kokonaispotentiaalista siirtonopeutta järjestelmään nähden voidaan rajoittaa huomattavasti."

Monisäikeinen" tarkoittaa useita säikeitä, jotka tekevät työtä rinnakkain. Jos sinulla on esimerkiksi yksi laite, joka voi palvella 1000 IOPS: ää synkronisessa kuormituksessa, tämä tarkoittaa, että laitteella on 1 ms: n vasteaika ilman jonoa (joten ilman jonoa palveluajan ja vasteajan pitäisi olla synonyymejä). On selvää, että laitteet, joiden vasteaika on 1 ms, voivat tehdä paljon enemmän työtä kuin 1000 IOPS, ja tämä saavutetaan pinoamalla useita säikeitä tai rinnakkaisia virtoja samasta työmäärästä. Joten jos lisäät säikeitä (tai "asioita, jotka tekevät tämän tietyn työn") 10: een, sinulla on nyt 10 yksittäistä säiettä, jotka tekevät I/O: n laitteeseen 1 ms: n nopeudella. Jokainen yksittäinen kuormitussäie saa edelleen 1 ms, mikä tarkoittaa, että jokainen säie saavuttaa edelleen vain 1000 IOPS: n, mutta nyt koko näiden useiden säikeiden suorittama "prosessi" tai "työ" saa 10 000 IOPS: n.

On työkaluja ja työkuormia, jotka voivat osua riittävästi laitteen rajoihin yhdellä säikeellä, ja jotkut tarvitsevat enemmän. Yhteenvetona voidaan todeta, että synkronista kuormaa simuloitaessa haluat olla mahdollisimman monta säiettä/työntekijää/virtaa vaikuttamatta kokonaisvasteaikaan. On kohta, jossa säikeiden määrän lisääminen lakkaa vaikuttamasta positiivisesti (kun laite on 100% varattu). Yleensä asynkronisissa työkuormissa säikeiden määrä hoidetaan oletusarvoisesti. Esimerkiksi alla näet edelleen eron 1 säikeen ja 10: n välillä asynkronisessa työmäärässä, vaikkakaan ei merkittävää. Tarinan opetus on, että asynkronisten työmäärien kanssa sinun ei pitäisi joutua huolehtimaan langoista niin paljon. 

Tässä yhdellä säikeellä voidaan saavuttaa 68 000 IOPS käyttämällä "libaio" (asynkroninen) -moottoria. 

 

Jos lisäät säikeitä (numjobs) arvoon 10, voit silti nähdä IOPS: n kasvun.

 

Synkronisten kuormitusten suhteen, vaikka tämä on ääritapaus, sinulla voi olla kaksi päätekijää, jotka tekevät tästä huonon suorituskyvyn testin, koska synkroninen luonne. 

lähetä I/O-1, odota ACK, lähetä I/O-2, odota ACK jne.

 Eikä pysty pinoamaan useita säikeitä samaan tarkoitukseen. 

job1=send I/O-1 - job2=send I/O-1 - job3=send I/O-1..... job1=get ack, send I/O-2 - job2=get ack, send I/O-2 - job3= get ack, send I/O-2 jne.

Suora lippu

Joissakin työkaluissa, erityisesti *nix-pohjaisissa työkaluissa/käyttöjärjestelmissä, saatat nähdä vaihtoehdon "Suora I/O". Tätä voidaan käyttää "asynkronisten" moottoreiden kanssa, eikä sitä pidä sekoittaa "synkronisiin" I/O-moottoreihin. Joissakin työkaluissa, joissa tätä merkintää ei ole määritetty, saatat kirjoittaa palvelimen välimuistiin etkä suoraan levylle. Isäntä haluaa ohittaa oman välimuistinsa ja kirjoittaa suoraan levylle. Tämä on olennainen tekijä tallennusta testattaessa. Kun sinulla on "suora" lippu, kirjoitat teknisesti levylle, vaikka "levy" tässä tapauksessa on todella tallennusvälimuisti. Tämä on edelleen hyväksyttävää testaustarkoituksiin, koska jopa oikealla työmäärällä simuloit ja jäljittelet tarkasti, miten tämä työkuorma toimii todellisessa ympäristössä, koska myös tuotantokuorma osuu välimuistiin ennen kuittauksen lähettämistä. (Älä tunne itseäsi huijatuksi vain siksi, että sinulla on mukana välimuistin suorituskykynumeroita eikä vain taustajärjestelmiä.)

 

Kaistanleveys (Mt/s) vs. siirtonopeus (IOPS)

Voit testata kahta päänäkökulmaa. Verkko- ja suorituskykymaailmassa siirtonopeus viittaa yleensä tiedonsiirtoon, mutta SAN-/lohkoympäristössä käytetään usein termiä "läpimeno" kuvaamaan IOPS:ia. Siksi sinun on ensin ymmärrettävä testattavat kuormituksen ominaisuudet.

Kaistanleveys (Mt/s) – Kaistanleveys tarkoittaa dataa, jonka putkeen tai järjestelmään mahtuu kerralla (tai X-välin sisällä, yleensä "sekunnissa"). Tämä tarkoittaa, että se mittaa, kuinka paljon tietoja olet siirtänyt tietyn ajanjakson aikana. Vaikka kaistanleveys ja IOPS eivät sulje toisiaan pois, sinulla voi olla suurempia tai pienempiä kaistanleveysnumeroita samalla IOPS-määrällä, kaikki riippuu lohkon koosta. Muista, että et mittaa nopeutta kaistanleveydellä, nopeus on jotain aivan muuta, ja vaikka se vaikuttaa kaistanleveyteen, sitä ei yleensä voi hallita raskaan kaistanleveyden työkuormilla. Siksi, jos testaat kaistanleveyttä, käytä aina suurempia lohkoja (kohtuuden rajoissa), jotta tietosi I/O-yksikköä kohden ovat suurempia kuin jos testaisit IOPS: ää, koska suurempien lohkojen huolto kestää luonnollisesti kauemmin. Jos esimerkiksi haluat saavuttaa 1 Mt/s, mutta käytät 8 kt:n lohkokokoa, sinun on painettava noin 125 IOPS:n nopeutta tämän saavuttamiseksi. Jos kuitenkin käyttäisit 512 kt:n lohkoja, se vaatisi vain kaksi (2) IOPS:ää.
(Jos säilyttäisit 125 IOPS: n ja kasvattaisit lohkon kokoa 8 kt: sta 512 kt: iin, työnnät nyt 64 Mt / s!)

Koska yhdessä I/O:ssa on kuitenkin enemmän tietoja, I/O:n "paketoiminen" (etsiminen, ketjuttaminen jne.) kestää yleensä kauemmin. Siksi huoltoajat voivat luonnollisesti olla pidempiä. Joskus sinulla on pienempi jono, joten vastausaikasi, vaikka ne ovat luonnollisesti pidempiä, pitäisi olla melko lähellä. Muista, että vaikka vasteajalla on merkitystä siinä, kuinka paljon kaistanleveyttä voit saavuttaa, I/O-yksikköä kohden olevan tietomäärän kasvu on yleensä suurempi kuin vasteajan (RT) pieni kasvu kyseisen I/O-tyypin kohdalla. Koska vasteajat ovat pidempiä, et halua, että suurten lohkotyökuormien on oltava satunnaisia. Joten kaistanleveyden kuormitukset ovat yleensä peräkkäisiä. Kun otat suuren lohkokuormituksen satunnaiseen luonteeseen, vakaa tiedonsiirtonopeus keskeytyy jatkuvasti ja alat tuntea hieman korkeampien I/O-vasteaikojen vaikutukset.

Suoritusteho (IOPS) – Suoritusteho/IOPS on yleisin perspektiivi pienten lohkojen työkuormissa, varsinkin kun niistä tulee satunnaisempia. Mitä tahansa yli 32 KB-64 KB voidaan pitää suurena lohkona. Läpimenossa edellä mainitut tekijät ovat tärkeimpiä (kuten säikeiden määrä, synkronointi tai asynkronointi, jonon syvyys ja niin edelleen). Tässä et yritä mitata, kuinka paljon kokonaistietoja voit siirtää X-välin aikana, vaan pikemminkin kuinka monta yksittäistä pakettia (I/O-pyyntöä), jotka sisältävät kyseiset tiedot, joita yrität huoltaa (joka x välein). OLTP:n (pankkitoiminta) kaltaisissa ympäristöissä on vähän väliä siitä, kuinka paljon tietoja ne voivat siirtää, koska niiden datajalanjälki on yleensä pieni. Nämä pienet tietojoukot voivat kuitenkin olla ja ovat yleensä varattuja. Näissä tietojoukoissa on suuri vinouma (viitataan pieneen tilaan, mutta ne vaihtelevat aggressiivisesti ja johdonmukaisesti). Pienet tietopaketit sisältävät yleensä vain pyyntöjä muuttaa / päivittää lohkoja, joissa on numeerisia tai pienempiä merkkijonoarvoja, joten suuria I/O-paketteja ei tarvita. Tapahtumien luonteen vuoksi ja koska niitä on niin paljon, haluamme kuitenkin varmistaa, että pystymme vastaamaan jokaiseen yksittäiseen kysyntään. Yleensä mitä pienempi lohkokoko on, sitä enemmän IOPS:ia voit saavuttaa tietyssä skenaariossa, ja vaikka pienet lohkokuormitukset liittyvät enimmäkseen satunnaiseen käyttöön, voit saavuttaa vielä suuremman siirtonopeuden pienillä peräkkäisillä lohkotyökuormilla. Pienet peräkkäiset lohkokuormitukset ovat kuitenkin erityisiä eivätkä yhtä yleisiä, joten testaa näitä skenaarioita vain, jos ympäristösi sitä vaatii.