Mnogi novi korisnici kada počnu koristiti CloudSigma žele testirati performanse; često žele usporediti rezultate performansi između cloud poslužitelja i vlastite infrastrukture, što ima smisla. Izravna usporedba cijena po resursu ne govori ni približno cijelu priču; ono što je stvarno važno je krajnji rezultat, koliko košta postizanje određenog računalnog zadatka?
Za bilo koji zadani zahtjev, broj resursa potrebnih za njegovo postizanje može se uvelike razlikovati među različitim cloud pružateljima. To znači da sama usporedba cijena ne funkcionira. S druge strane, usporedba performansi u izolaciji nije ništa bolja. Smislene usporedbe moraju objediniti i cijenu i performanse kako bi se izračunala neka mjera troška po računalnoj jedinici. U ovom postu podijelit ću neka svoja razmišljanja o testiranju performansi naših cloud poslužitelja i drugih. Također ću pružiti nekoliko savjeta za dobivanje korisnih rezultata i što oni zapravo znače.
Zdravstvena upozorenja
Da odmah objasnim, prilično sam skeptičan prema testiranju performansi općenito. Ono rijetko nudi stvarni uvid u stvarnu upotrebu. Ukratko, ne postoji prava zamjena za pokretanje stvarnih aplikacija koje namjeravate koristiti na platformi. Ako to možete postići uz razuman trošak u smislu vremena, onda nema zamjene za takav postupak.
Drugi čimbenik je opterećenost pružatelja cloud usluga. Možete testirati cloud poslužitelje i dobiti izvrsne rezultate. Međutim, oni mogu uvelike biti posljedica razine korištenja (ili nedostatka istog) tog određenog pružatelja usluga. To možda nije pozitivan znak. Može odražavati poteškoće u radu, izgubljene korisnike, prošle probleme s dostupnošću i pouzdanošću itd. Stoga biste uvijek trebali istražiti povijest ispada i drugih potencijalnih problema pružatelja cloud usluga kada tumačite njihove rezultate testiranja.
Kao posljednje upozorenje, performanse nisu jedini čimbenik koji biste trebali uzeti u obzir. Često niže performanse mogu odražavati robusniju (i redundantniju) hardversku arhitekturu u pozadini. Stoga je uvijek važno imati vrlo jasno razumijevanje na kakvoj je infrastrukturi cloud izgrađen. Tako možete pravedno usporediti rezultate, što vam omogućuje donošenje smislene odluke o kupnji.
Definirajte problem
Kasnije u ovom postu iznijet ću različite aspekte performansi i kako najbolje pristupiti tumačenju rezultata. Prije bilo kakvog testiranja performansi, međutim, važno je karakterizirati vrstu računalnih zadataka koje planirate obavljati u cloudu; to će odrediti relativnu važnost različitih metrika performansi. Na primjer, ako želite postaviti poslužitelj baze podataka koji će biti pod velikim opterećenjem čitanja, ali slabim upisivanjem, trebali biste obratiti pozornost na performanse diska u cloudu, a posebno na nesekvencijalni pristup čitanju.
Dakle, prije nego što započnete s bilo kakvim testiranjem performansi cloud poslužitelja, zapravo definirajte što biste smatrali dobrim performansama clouda. Trebali biste odrediti koji su aspekti ključni i imaju nerazmjeran utjecaj na stvarne performanse vašeg računalnog sustava. Kada budete imali jasnu predodžbu o tome, bit ćete u poziciji da počnete razmišljati o testiranju performansi.
Računalne performanse
Kada promatramo sirove računalne performanse, govorimo o procesoru (CPU) i radnoj memoriji (RAM). Razlike u performansama na čisto računalnoj razini između različitih cloud pružatelja zapravo nisu tako velike. Međutim, postoje neki čimbenici koji uzrokuju stvarne razlike.
Uvjerljivo najveći čimbenik koji utječe na računalne performanse u cloudu je konkurencija za resurse (contention). Javni cloudovi su višezakupnička (multi-tenant) okruženja. RAM i pohrana se zapravo ne mogu pre-alocirati (iako se mogu preprodati), ali CPU može i biva pre-alociran. Razine konkurencije znatno variraju, ali u biti pružatelji usluga javnog clouda mogu prodati CPU kapacitet fizičkog poslužitelja za više od 100%.
Neki od najvećih pružatelja usluga koriste omjere dijeljenja CPU-a od preko tri puta. To znači da bi ukupni ‘prodani’ kapacitet CPU-a svih virtualnih poslužitelja na istom fizičkom stroju mogao biti tri puta veći od njegovog stvarnog kapaciteta CPU-a. Oni to rade jer većina virtualnih poslužitelja većinu vremena ne koristi ni približno 100% svoje dodijeljene CPU snage. Ipak, omjeri dijeljenja izravno će utjecati na mjerila performansi cloud poslužitelja i stvarnu upotrebu. Ako je dijeljenje visoko (tj. na bilo čemu više od 200% dodijeljenog CPU-a), performanse cloud poslužitelja značajno će se pogoršati.
Jednostavno rečeno, ako opterećenje na bilo kojem fizičkom stroju prijeđe više od 1 po jezgri, računalni zadaci se stavljaju u red čekanja i vrijeme potrebno tom virtualnom stroju da dovrši posao bit će duže. S obzirom na to da većina cloud usluga naplaćuje na bazi kapaciteta po satu, to ima izravan utjecaj na troškove za korisnike tog clouda.
Drugi važan čimbenik koji utječe na računalne performanse je broj CPU jezgri kojima virtualni stroj ima pristup. To nije čimbenik za sve aplikacije, ali many moderne aplikacije podržavaju višedretvenost. Zapravo, to znači da je aplikacija i/ili operacijski sustav sposoban raspodijeliti računalne zadatke na više jezgri. Jedan izvrstan savjet za poboljšanje performansi vašeg računanja je usklađivanje broja dretvi (tj. jezgri) koje aplikacija može podržati s brojem jezgri kojima virtualni stroj ima pristup.
Nažalost, to nije moguće s mnogim javnim cloudima. To je zato što njihove virtualizacijske platforme ne podržavaju virtualizaciju na razini CPU jezgre. Drugim riječima, svaku jezgru može koristiti samo jedan virtualni stroj u isto vrijeme. U cloudima koji podržavaju virtualizaciju CPU jezgri, trebali biste eksperimentirati s promjenom broja jezgri za taj stroj, dok ukupnu veličinu CPU-a ostavljate istom.
Na primjer, ako imate stroj od 2 GHz, možete vidjeti kako udvostručenje jezgri u upotrebi s dvije na četiri utječe na vaše testiranje performansi. Na taj će način aplikacije koje se izvode na tom virtualnom stroju moći izvršavati zadatke putem četiriju jezgri istovremeno. U našem slučaju, možete postaviti broj jezgri koje virtualni stroj koristi putem kartice ‘napredno’ na našem modalnom prozoru s detaljima poslužitelja na web konzoli. Samo se sjetite uvijek provjeriti koja je standardna veličina jezgre pružatelja cloud usluga prije nego što ručno prepišete broj jezgri u upotrebi. U našem slučaju to je 2,2 GHz po jezgri, ali to se razlikuje od clouda do clouda.
Preporučio bih da razmislite o korištenju POV-RAY, CoreMark, Dhrystone ili Whetstone za testiranje performansi cloud poslužitelja.
Pohrana: stvarni test performansi cloud poslužitelja
Sve performanse ograničene su najslabijom karikom na kojoj se stvara usko grlo. Trenutno je tehnologija značajno napredovala na području virtualizacije u pogledu korištenja CPU-a i RAM-a. Na primjer, jedan fizički stroj može se virtualizirati i imati više cloud poslužitelja uz minimalan gubitak ukupnih agregatnih performansi. Nažalost, u slučaju pohrane, još uvijek treba postići veliki napredak. Krajnji rezultat je da je u većini slučajeva izvedba virtualnih poslužitelja u cloudu određena performansama rješenja za pohranu tog clouda.
Ukratko, pohrana je trenutno ograničavajući čimbenik za performanse većine računalnih zadataka u cloudu. Bez obzira na rezultate koje pov-ray i drugi testovi performansi mogu proizvesti za čiste računalne zadatke, stvarnost je da će brzina kojom virtualni poslužitelj može dohvatiti i zapisati podatke na fizičke diskove za pohranu odrediti stvarne performanse cloud poslužitelja u ovom trenutku.
Imajući to na umu, stvarne razlike u performansama u oblaku, čak i kada je riječ o računskim zadacima, obično proizlaze iz razlika u performansama pohrane. Kao što je ranije spomenuto u ovoj objavi, potrebe korisnika uvelike se razlikuju ovisno o računskom zadatku. To nikada nije točnije nego kada je riječ o pohrani. Treba li vam brz pristup čitanju velikih sekvencijalnih blokova podataka (kao što je streaming medija) ili malih nepovezanih dijelova informacija (možda u velikoj bazi podataka)? Trebate li održavati intenzivan pristup pisanju za podatke koji se brzo mijenjaju i kojima se pristupa povremeno u velikim naletima? Postoje brojni scenariji i svaki će raditi drugačije na istoj platformi.
U osnovi, razlike u performansama svode se na arhitekturu. Te razlike u arhitekturi obično proizlaze iz različitih stupnjeva robusnosti u pogledu pohrane podataka, njihove redundantnosti, a time zapravo i vjerojatnosti da će ikada biti nepovratno izgubljeni. Na visokoj razini, oblaci koriste ili centralizirana podatkovna rješenja u obliku Storage Area Network (SAN) ili distribuiranijih lokalnih rješenja za pohranu. Kod njih se pohrana nalazi na svakom pojedinačnom fizičkom stroju.
Dobri SAN-ovi sami po sebi imaju ugrađenu visoku razinu redundantnosti. Međutim, performanse ispaštaju jer se podaci moraju slati iz SAN-a preko mreže do procesora i RAM-a virtualnog stroja’ za računske zadatke. Kao rezultat toga, oblaci temeljeni na SAN-u obično imaju lošije performanse u izravnoj usporedbi s oblacima s lokalnim distribuiranim rješenjima za pohranu. Još jedan nedostatak SAN-a je taj što predstavlja vrlo veliku jedinstvenu točku kvara. SAN-ovi su iznimno pouzdani. Ako ikada ozbiljno zakažu (a jesu), vjerojatno ćete se suočiti s vrlo velikim prekidom rada i oštećenjem podataka.
Većina pružatelja usluga u oblaku koji koriste SAN-ove ne primjenjuje potpuno redundantna rješenja za oporavak od katastrofe kakva se koriste u poduzetničkim okruženjima, uglavnom iz razloga troškova. Važno je shvatiti da svaki SAN nije’ isti i razumjeti koju razinu redundantnosti pružatelj usluga u oblaku koristi sa svojim SAN-ovima.
Oblaci temeljeni na lokalnoj pohrani obično imaju dobre performanse diska. Međutim, često nude lokalnu pohranu samo u nepostojanom obliku. To nije’ pravedna usporedba s trajnom pohranom. Privremena pohrana ne mora’ biti robusna na kvarove na isti način kao i trajna pohrana. Uvijek je važno uspoređivati trajnu pohranu s trajnom pohranom radi smislenih rezultata.
Kada gledate oblake s distribuiranim lokalnim rješenjima za pohranu, također morate znati kakvu redundantnost imaju. Tvrdi diskovi otkazuju u značajnoj mjeri, pa je metoda pohrane ključna. Većina pružatelja usluga koristi neki oblik RAID, ali postoje vrlo različite razine sigurnosti. Na donjem kraju imate RAID1 gdje dva diska u biti zrcale jedan drugi. To obično ima dobre performanse. Ali kada jedan disk zakaže, dok zamjenski disk ne kopira sve podatke sa starog diska, podaci su u opasnosti od potpunog gubitka ako drugi (jako opterećeni) disk zakaže. Također, tijekom bilo kakve ponovne izgradnje RAID1 polja, performanse diska će vjerojatno biti puno, puno niže od normalnih.
Mnogi pružatelji usluga stoga koriste RAID5 (otporan na kvar jednog diska) ili RAID6 (otporan na kvar dvaju diskova). RAID6 nudi daleko najsigurnije rješenje za lokalnu pohranu, ali uz veliku cijenu u performansama. Naš pristup je korištenje RAID6, ali u kombinaciji s vrhunskim hardverskim RAID kontrolerskim karticama. One imaju velike memorijske predmemorije i baterijsko napajanje. RAID kontrolerske kartice koje koristimo zapravo su znatno skuplje od cijelih diskova. Tako možemo isporučiti performanse usporedive s mnogo manje otpornim konfiguracijama, dok i dalje nudimo vrlo veliku sigurnosnu mrežu RAID6 pohrane. Pročitajte više o našoj infrastrukturi u oblaku konfiguraciji o kojoj smo vrlo otvoreni.
Preporučujem korištenje IOzone ili Bonnie++ za testiranje performansi diska.
Dakle, kada tumačite rezultate testova performansi pohrane, pobrinite se da imate i sljedeće informacije:
- koju arhitekturu pohrane oblak koristi (lokalnu, SAN, drugu)?
- koje su mjere oporavka od kvara i redundancije uspostavljene za podatke?
- je li pohrana koju testiram privremena ili trajna?
Spajanje odgovora na ova tri pitanja s rezultatima testiranja performansi pružit će vam prilično dobar uvid u stvarne performanse pohrane.
Umrežavanje
Performanse umrežavanja znatno je jednostavnije odrediti i izmjeriti nego računalne performanse i performanse diska. Mrežne performanse imaju dva ključna aspekta: latenciju i propusnost.
Ovisno o vašim potrebama, latencija mreže koju pružatelj usluga u oblaku koristi može, ali i ne mora biti važna. Ako koristite oblak za uglavnom samostalne operacije, malo je vjerojatno da će latencija biti prioritet. Međutim, ako pokrećete aplikacije u stvarnom vremenu koje komuniciraju sa svijetom izvan oblaka, tada će latencija biti ključna odrednica performansi.
Obično velika većina latencije proizlazi iz same fizičke udaljenosti. Na primjer, većina latencije između Londona i San Francisca zapravo je vrijeme koje je svjetlosti potrebno da prijeđe tu udaljenost. Razlike u latenciji određene su različitom učinkovitošću odabrane rute. To je aspekt koji se razlikuje od oblaka do oblaka. Učinkovitost rute izravan je rezultat mrežnih pružatelja s kojima oblak ima izravne veze. To se postiže ili preuzimanjem IP povezivosti od njih ili putem peeringa. Kada promatrate latencije, možete jednostavno pingati svoj poslužitelj u oblaku i odrediti njegove performanse. Međutim, važno je odrediti performanse između vaših stvarnih krajnjih korisnika i vašeg poslužitelja u oblaku.
Ako se većina vaših korisnika nalazi na jednom geografskom području ili će se pristupati prvenstveno iz sjedišta vaše tvrtke, važno je testirati performanse s tih lokacija. Komercijalne usluge kao što su Pingdom nude isplativ način određivanja latencije s velikog broja općih lokacija istovremeno diljem svijeta.
Stvarna propusnost koju vaš poslužitelj u oblaku može postići također je vrlo važna. Za razliku od tradicionalnijih rješenja za hosting, pružatelji usluga u oblaku obično naplaćuju u odnosu na ukupni volumen prijenosa podataka. Drugim riječima, to ne ovisi o vremenu kao kod plaćanja po Mbitu, što vam pruža fiksnu razinu povezivosti 24/7. Unatoč tome, mnogi pružatelji usluga u oblaku će ‘prigušiti’ propusnost bilo kojeg virtualnog poslužitelja. To će biti nevidljivo korisniku sve dok ne naiđete na tu barijeru. Ako imate prilično promjenjiv profil propusnosti s izraženim skokovima, to bi mogao biti važan čimbenik performansi koji treba uzeti u obzir.
Kako biste testirali stvarnu propusnost svog poslužitelja u oblaku, važno je pokušati preuzeti podatke na poslužitelj u oblaku s izvora koji zapravo ne ograničava brzinu prijenosa na svojoj strani. Često smatram da je izvrstan način za određivanje dostupne brzine preuzimanje velike datoteke od velikog dobavljača kao što je Microsoft, Ubuntu ili još bolje ažuriranjem operativnog sustava. Time se obično preuzima mnogo različitih datoteka s različitih lokacija istovremeno. To će vam dati prilično dobar osjećaj o brzini vaše veze.
Često preuzimam Fedora live CD s njihove glavne stranice kao standardni test, ali trebali biste barem eksperimentirati s nekoliko različitih datoteka i lokacija. Ako inzistirate na tome da imate vlastitu vrlo brzu korporativnu mrežu, možda ćete umjesto toga htjeti preuzeti datoteku sa svog poslužitelja u oblaku na vlastitu mrežu kao test.
Sada ponovno dodajte cijene kako biste odvagnuli rezultate
Koristeći gore navedene metode, trebali biste dobiti dobar osjećaj o tome kako rade različiti pružatelji usluga poslužitelja u oblaku. Nadalje, trebali biste znati na koje se aspekte usredotočiti koji su najvažniji za vaše specifične potrebe.
Posljednji korak je dodavanje dimenzije cijena rezultatima benchmarkinga. Za to ne postoji formula. To ovisi o relativnim performansama različitih gore navedenih aspekata, a njih određujete vi. Ako jedan oblak pruža 40% bolje performanse (kako ste vi odredili), ali je samo 30% skuplji, onda očito izgleda privlačno. Slično tome, ako imate veliku potrebu za propusnošću, slabije računalne performanse može nadmašiti konkurentan plan cijena prijenosa podataka. Ključ donošenja ispravne odluke je uzimanje u obzir svih različitih čimbenika.
Naposljetku, benchmarking bi trebao biti dio šireg procesa određivanja koji su poslužitelji u oblaku pravi za vas. To bi trebalo uključivati i druge aspekte. Na primjer, oni mogu uključivati ugovore o razini usluge, razmatranja o ovisnosti o podacima ili dobavljaču (vendor lock-in), fizičku lokaciju i pravnu nadležnost. Objedinjavanjem svih ovih aspekata pozicionirat ćete se za donošenje ispravne odluke o odabiru pružatelja usluga računalstva u oblaku.
Komentari
Još nema komentara. Budite prvi.