Felhőszerverek teljesítménytesztelése: Bennfentes útmutató a felhőalapú számítástechnikához

Sok új ügyfél, amikor elkezdi használni a CloudSigma-t, szeretné tesztelni a teljesítményt; gyakran össze akarják hasonlítani a felhőszerverek és a saját infrastruktúrájuk teljesítményeredményeit, és ez érthető is. Az erőforrások alapján történő egyszerű árösszehasonlítás egyáltalán nem mutatja meg a teljes képet; ami igazán számít, az a végeredmény: mennyibe kerül egy adott számítási feladat elvégzése?

Bármely adott követelmény esetén az eléréséhez szükséges erőforrások száma tág határok között mozoghat a különböző felhők között. Ez azt jelenti, hogy a puszta árak összehasonlítása nem működik. A dolog másik oldala, hogy a teljesítmény önmagában történő összehasonlítása semmivel sem jobb. Az érdemi összehasonlításoknak össze kell kapcsolniuk az árat és a teljesítményt, hogy kiszámítsák a számítási egységenkénti költség valamilyen mértékét. Ebben a bejegyzésben megosztom néhány gondolatomat a saját és más felhőszerverek teljesítményének mérésével (benchmarking) kapcsolatban. Tippeket is adok majd a hasznos eredmények eléréséhez, és ahhoz, hogy azok valójában mit is jelentenek.

Figyelmeztetések

Hogy előre tisztázzuk, meglehetősen szkeptikus vagyok a teljesítményteszteléssel kapcsolatban általánosságban. Ritkán nyújt valós betekintést a valós használatba. Röviden, semmi sem helyettesítheti a platformon használni kívánt tényleges alkalmazások futtatását. Ha ezt időben ésszerű költségek mellett meg tudja oldani, akkor egy ilyen folyamatnak nincs alternatívája.

Egy másik tényező a felhőszolgáltató leterheltsége. Előfordulhat, hogy teszteli a felhőszervereket, és kiváló eredményeket kap. Ezek azonban nagyrészt az adott szolgáltató kihasználtságának szintjéből (vagy annak hiányából) adódhatnak. Ez nem feltétlenül pozitív jel. Tükrözhet működési nehézségeket, elveszített ügyfeleket, korábbi rendelkezésre állási és megbízhatósági problémákat stb. Ezért a teljesítményteszt eredményeinek értelmezésekor mindig utána kell néznie a felhőszolgáltató korábbi leállásainak és egyéb lehetséges problémáinak.

Utolsó figyelmeztetésként: a teljesítmény nem az egyetlen tényező, amelyet figyelembe kell vennie. A gyengébb teljesítmény gyakran a mögötte lévő robusztusabb (és redundánsabb) hardverarchitektúrát tükrözheti. Ezért mindig nagyon fontos, hogy tisztában legyen azzal, milyen infrastruktúrára épül a felhő. Így reálisan hasonlíthatja össze az eredményeket, ami lehetővé teszi, hogy megalapozott vásárlási döntést hozzon.

A probléma meghatározása

A bejegyzés későbbi részében bemutatom a teljesítmény különböző aspektusait, és azt, hogyan érdemes a legjobban értelmezni az eredményeket. Bármilyen teljesítményteszt elvégzése előtt azonban fontos meghatározni, hogy milyen típusú számítási feladatokat szeretne végezni a felhőben; ez határozza meg a különböző teljesítménymutatók relatív fontosságát. Ha például egy adatbázis-szervert szeretne elhelyezni, amely erős olvasási, de alacsony írási terhelésnek lesz kitéve, akkor a felhőben a lemez teljesítményére, és különösen a nem szekvenciális olvasási hozzáférésre kell figyelnie.

Tehát, mielőtt elkezdené a felhőszerverek teljesítménytesztelését, rögzítse, mit tekintene jó teljesítménynek a felhő részéről. Meg kell határoznia, melyek a kulcsfontosságú szempontok, amelyek aránytalanul nagy hatással vannak a számítási feladatok valós teljesítményére. Ha erről már tiszta képe van, akkor áll készen arra, hogy elkezdje a teljesítménytesztelést.

Számítási teljesítmény

Amikor a nyers számítási teljesítményt vizsgáljuk, a CPU-ról és a RAM-ról beszélünk. A tiszta számítási szintű teljesítménybeli különbségek a felhők között valójában nem olyan nagyok. Van azonban néhány tényező, amely a valós különbségeket okozza.

A felhőben a számítási teljesítményt befolyásoló messze legnagyobb tényező az erőforrás-konkurencia (contention). A nyilvános felhők többbérlős (multi-tenant) környezetek. A RAM és a tárhely valójában nem osztható túl (bár túlértékesíthető), de a CPU igen, és ezt meg is teszik. A konkurencia szintje jelentősen eltér, de lényegében a nyilvános felhőszolgáltatók képesek egy fizikai gazdagép CPU-kapacitását több mint 100%-ban értékesíteni.

Néhány a legnagyobb szolgáltatók közül háromszorosnál is nagyobb CPU-túlterhelési arányt használ. Ez azt jelenti, hogy az ugyanazon a fizikai gépen lévő összes virtuális szerver teljes ‘eladott’ CPU-kapacitása akár a tényleges CPU-kapacitás háromszorosa is lehet. Ezt azért teszik, mert a legtöbb virtuális szerver az idő nagy részében közel sem használja ki a CPU-allokációjának 100%-át. Ennek ellenére a túlterhelési arányok közvetlenül befolyásolják a felhőszerverek teljesítménytesztjeit és a valós használatot. Ha a túlterheltség magas (azaz több mint 200%-os CPU-allokáció), akkor a felhőszerver teljesítménye jelentősen romlani fog.

Egyszerűen fogalmazva, ha bármely fizikai gép terhelése meghaladja a magonkénti 1-et, a számítási feladatok sorba rendeződnek, és a virtuális gépnek hosszabb időbe telik a munka elvégzése. Mivel a legtöbb felhőszolgáltatás kapacitás/óra alapon számláz, ez közvetlen költségkihatással van az adott felhő ügyfeleire.

A számítási teljesítményt befolyásoló másik fontos tényező a CPU-magok száma, amelyekhez a virtuális gép hozzáfér. Ez nem minden alkalmazás esetében tényező, de sok modern alkalmazás támogatja a többszálú működést. Ez gyakorlatilag azt jelenti, hogy az alkalmazás és/vagy az operációs rendszer képes elosztani a számítási feladatokat több mag között. Egy nagyszerű tipp a számítási teljesítmény javítására, ha az alkalmazás által támogatott szálak (azaz magok) számát hozzáigazítja a virtuális gép által elérhető magok számához.

Sajnos ez sok nyilvános felhő esetében nem lehetséges. Ennek az az oka, hogy a virtualizációs platformjaik nem támogatják a CPU-mag szintű virtualizációt. Más szóval, minden egyes magot egyszerre csak egy virtuális gép használhat. Azokban a felhőkben, amelyek támogatják a CPU-magok virtualizációját, érdemes kísérletezni az adott gép magjainak számának változtatásával, miközben a teljes CPU-méretet változatlanul hagyja.

Például, ha van egy 2 GHz-es gépe, megnézheti, hogyan befolyásolja a teljesítménytesztet a használt magok számának megduplázása kettőről négyre. Ezáltal az adott virtuális gépen futó alkalmazások képesek lesznek egyszerre négy magon keresztül végrehajtani a feladatokat. A mi esetünkben a virtuális gép által használt magok számát a webkonzol szerverrészletek paneljének ‘advanced’ lapján állíthatja be. Ne feledje, hogy a használt magok számának manuális felülírása előtt mindig ellenőrizze, mekkora a felhőszolgáltató szabványos magmérete. A mi esetünkben ez magonként 2,2 GHz, de ez felhőnként változik.

Javaslom, hogy fontolja meg a következők használatát: POV-RAY, CoreMark, Dhrystone vagy Whetstone használatát a felhőszerverek teljesítményének tesztelésére.

Tárhely: a felhőszerverek valódi teljesítménytesztje

Minden teljesítményt a leggyengébb láncszem korlátoz, ahol a szűk keresztmetszet kialakul. Jelenleg a technológia jelentősen fejlődött a virtualizáció terén a CPU és a RAM használatát illetően. Például egyetlen fizikai gép virtualizálható, és több felhőszerverrel rendelkezhet a teljes összesített teljesítmény minimális veszteségével. Sajnos a tárhely esetében még rengeteg fejlődésre van szükség. A végeredmény az, hogy a legtöbb esetben a felhőben lévő virtuális szerverek teljesítményét az adott felhő tárhelymegoldásának teljesítménye határozza meg.

Röviden, jelenleg a tárhely a szűk keresztmetszet a legtöbb számítási feladat teljesítményében a felhőben. Bármilyen eredményt is produkáljon a POV-Ray és más teljesítménytesztek a tiszta számítási feladatok terén, a valóság az, hogy az a sebesség, amellyel a virtuális szerver képes adatokat lekérni és írni a fizikai tárolólemezekre, jelenleg meghatározza a felhőszerver valós teljesítményét.

Ezt szem előtt tartva, a felhőben tapasztalható valós teljesítménybeli különbségek – még a számítási feladatok tekintetében is – általában a tárolási teljesítmény különbségeiből adódnak. Ahogy a bejegyzésben korábban említettük, a számítási feladattól függően nagyon eltérőek az ügyfelek igényei. Ez különösen igaz a tárolásra. Gyors olvasási hozzáférésre van szüksége nagy, szekvenciális adatblokkokhoz (például streaming médiához), vagy kis, különálló információkhoz (esetleg egy nagy adatbázisban)? Fenntartandó a nagy írási hozzáférés a gyorsan változó adatokhoz, amelyeket időszakosan, nagy löketekben érnek el? Számos forgatókönyv létezik, és mindegyik másképp fog teljesíteni ugyanazon a platformon.

Alapvetően a teljesítménybeli különbségek az architektúrára vezethetők vissza. Az architektúrában mutatkozó különbségek általában az adattárolás robusztusságának különböző mértékéből, annak redundanciájából adódnak, és ebből adódóan abból, hogy mekkora a valószínűsége annak, hogy az adatok helyrehozhatatlanul elvesznek. Magas szinten a felhők vagy központosított adatmegoldásokat alkalmaznak egy Storage Area Network (SAN) formájában, vagy elosztottabb helyi tárolási megoldásokat. Ezekben a tároló minden egyes fizikai gépen megtalálható.

A jó SAN-ok eleve magas szintű beépített redundanciával rendelkeznek. A teljesítmény azonban csorbát szenved, mivel a számítási feladatokhoz az adatokat a SAN-ról a hálózaton keresztül kell elküldeni a virtuális gép CPU-jához és RAM-jához. Ennek eredményeként a SAN-alapú felhők teljesítménye általában alacsonyabb az elosztott helyi tárolási megoldásokkal rendelkező felhőkhöz képest. A SAN másik hátránya, hogy egyetlen, igen nagy hibaforrást jelent. A SAN-ok rendkívül megbízhatóak. Ha azonban valaha is komoly hiba lép fel náluk (és már fordult elő ilyen), akkor valószínűleg nagyon nagy leállással és adatsérüléssel kell szembenéznie.

A SAN-t használó felhőszolgáltatók többsége – főként költségokokból – nem alkalmaz a vállalati környezetben megszokott, teljesen redundáns hibatűrő (fail-over) megoldásokat. Fontos felismerni, hogy nem minden SAN egyforma, és megérteni, hogy az adott felhőszolgáltató milyen szintű redundanciát alkalmaz a SAN-jai esetében.

A helyi tárolón alapuló felhők általában jó lemezteljesítménnyel rendelkeznek. Gyakran azonban csak nem perzisztens formában kínálnak helyi tárolást. Ez nem igazságos összehasonlítás a perzisztens tárolással. Az ideiglenes tárolásnak nem kell ugyanolyan módon robusztusnak lennie a hibákkal szemben, mint a tartós tárolásnak. A hiteles eredmények érdekében mindig fontos a perzisztens tárolót a perzisztens tárolóval összehasonlítani.

Az elosztott helyi tárolási megoldásokkal rendelkező felhők esetében azt is tudnia kell, hogy milyen redundanciával rendelkeznek. A merevlemezek jelentős arányban hibásodnak meg, ezért a tárolási módszer kritikus fontosságú. A legtöbb szolgáltató valamilyen formában használ RAID-et, de a biztonságnak nagyon eltérő szintjei vannak. A skála alján a RAID1 található, ahol két lemez lényegében tükrözi egymást. Ez általában jó teljesítményt nyújt. De ha az egyik lemez meghibásodik, amíg a cserelemez le nem másolja az összes adatot a régi lemezről, az adatok a teljes elvesztés veszélyének vannak kitéve, ha a második (erősen terhelt) lemez is meghibásodik. Emellett a RAID1 tömb újjáépítése során a lemezteljesítmény valószínűleg sokkal alacsonyabb lesz a normálisnál.

Sok szolgáltató ezért RAID5-öt (egy lemezmeghibásodásnak ellenálló) vagy RAID6-ot (két lemezmeghibásodásnak ellenálló) használ. A RAID6 messze a legbiztonságosabb megoldást kínálja a helyi tároláshoz, de komoly teljesítménybeli áldozatot követel. Mi a RAID6-ot használjuk, de ezt a kategória legjobb hardveres RAID-vezérlőkártyáival kombináljuk. Ezek nagy memóriapufferrel és akkumulátoros háttértámogatással rendelkeznek. Az általunk használt RAID-vezérlőkártyák valójában lényegesen drágábbak, mint a teljes lemeztömbök. Így a sokkal kevésbé ellenálló rendszerekkel összehasonlítható teljesítményt tudunk nyújtani, miközben továbbra is biztosítjuk a RAID6 tárolás nyújtotta hatalmas biztonsági hálót. Olvasson többet a mi felhőinfrastruktúránk kialakításáról, amellyel kapcsolatban nagyon nyitottak vagyunk.

Javaslom az IOzone vagy Bonnie++ használatát a lemezteljesítmény teszteléséhez.

Tehát a tárolási teljesítménytesztek eredményeinek értelmezésekor győződjön meg arról, hogy a következő információkkal is rendelkezik:

• milyen tárolási architektúrát használ a felhő (helyi, SAN, egyéb)?
• milyen hibatűrési és redundancia-intézkedések vannak érvényben az adatokra vonatkozóan?
• a tároló, amelyet épp tesztelek, ideiglenes vagy tartós?

E három kérdésre adott válaszok és a teljesítménytesztek eredményeinek összegzése meglehetősen jó betekintést nyújt majd a tényleges tárolási teljesítménybe.

Hálózatkezelés

A hálózat teljesítményének meghatározása és mérése lényegesen egyszerűbb, mint a számítási és a lemezteljesítményé. A hálózati teljesítménynek két kulcsfontosságú aspektusa van: a késleltetés és a sávszélesség.

Az Ön igényeitől függően a felhőszolgáltató által használt hálózat késleltetése lehet fontos vagy kevésbé fontos. Ha a felhőt nagyrészt önálló műveletekre használja, nem valószínű, hogy a késleltetés prioritást élvez majd. Ha azonban olyan valós idejű alkalmazásokat futtat, amelyek a felhőn kívüli világgal lépnek kapcsolatba, akkor a késleltetés kritikus teljesítmény-meghatározó tényező lesz.

Általában a késleltetés túlnyomó többsége a puszta fizikai távolságból adódik. Például  a London és San Francisco közötti késleltetés nagy része valójában az az idő, amíg a fény megteszi ezt a távolságot. A késleltetésbeli különbségeket a választott útvonal eltérő hatékonysága határozza meg. Ez az a szempont, amely felhőnként változik. Az útvonal hatékonysága közvetlen következménye azoknak a hálózati szolgáltatóknak, amelyekkel a felhő közvetlen kapcsolattal rendelkezik. Ez vagy tőlük vásárolt IP-kapcsolaton keresztül, vagy peering révén valósul meg. A késleltetések vizsgálatakor egyszerűen megpingelheti a felhőszerverét, és meghatározhatja annak teljesítményét. Fontos azonban meghatározni a tényleges végfelhasználók és a felhőszerver közötti teljesítményt is.

Ha a felhasználók többsége egy adott földrajzi helyen tartózkodik, vagy a hozzáférés elsősorban a vállalat székhelyéről történik, fontos, hogy  tesztelje a teljesítményt ezekről a helyekről. Az olyan kereskedelmi szolgáltatások, mint például a Pingdom költséghatékony módot kínálnak a késleltetés egyidejű meghatározására számos általános helyről világszerte.

A tényleges sávszélesség, amelyet a felhőszervere el tud érni, szintén nagyon fontos. A hagyományosabb tárhelymegoldásokkal ellentétben a felhőszolgáltatók általában az összesített adatforgalom mértéke alapján számítanak fel díjat. Más szóval, ez nem időfüggő, mint a Mbit-alapú elszámolás, amely fix szintű kapcsolatot biztosít a nap 24 órájában, a hét minden napján. Ennek ellenére sok felhőszolgáltató ‘korlátozza’ a virtuális szerverek sávszélességét. Ez mindaddig láthatatlan marad a felhasználó számára, amíg el nem éri ezt a korlátot. Ha a sávszélesség-profilja meglehetősen ingadozó, ez egy fontos teljesítménytényező lehet, amelyet figyelembe kell venni.

A felhőszerver tényleges sávszélességének teszteléséhez fontos, hogy megpróbáljon adatokat letölteni a felhőszerverre egy olyan forrásból, amely a saját oldalán nem korlátozza az átviteli sebességet. Gyakran úgy találom, hogy a rendelkezésre álló sebesség meghatározásának nagyszerű módja egy nagy fájl letöltése egy olyan jelentős szolgáltatótól, mint a Microsoft, Ubuntu, vagy még jobb, ha frissíti az operációs rendszert. Ez általában sok különböző fájlt tölt le egyszerre különböző helyekről. Ez elég jó képet ad a kapcsolat sebességéről.

Gyakran letöltök egy Fedora live CD -t a fő webhelyükről standard tesztként, de minimális elvárásként mindig érdemes kísérletezni néhány különböző fájllal és hellyel. Ha ragaszkodik ahhoz, hogy saját, nagyon gyors vállalati hálózata legyen, akkor tesztként letölthet egy fájlt a felhőszerveréről a saját hálózatára is.

Most adja hozzá újra az árat az eredmények súlyozásához

A fenti módszerekkel jó képet kaphat arról, hogyan teljesítenek a különböző felhőszerver-szolgáltatók. Továbbá tudnia kell, hogy mely szempontokra kell összpontosítania, amelyek a legfontosabbak az Ön egyedi igényei szempontjából.

Az utolsó lépés az, hogy árazási dimenziót adjunk a benchmark eredményekhez. Erre nincs képlet. Ez a fenti különböző szempontok relatív teljesítményétől függ, és ezeket Ön határozza meg. Ha az egyik felhő 40%-kal jobb teljesítményt nyújt (az Ön megítélése szerint), de csak 30%-kal drágább, akkor egyértelműen vonzónak tűnik. Hasonlóképpen, ha nagy sávszélességre van szüksége, az alacsonyabb számítási teljesítményt felülmúlhatja egy versenyképes adatátviteli díjszabás. A helyes döntés meghozatalának kulcsa az összes különböző tényező figyelembevétele.

Végezetül, a benchmarkingnak egy nagyobb folyamat részének kell lennie, amely meghatározza, hogy mely felhőszerverek megfelelőek az Ön számára. Ennek más szempontokat is magában kell foglalnia. Ezek közé tartozhatnak például a szolgáltatási szintű megállapodások, az adatokhoz/szolgáltatóhoz való kötődéssel kapcsolatos megfontolások, a fizikai helyszín és a jogi illetékesség. Mindezeknek a szempontoknak az összehangolásával Ön olyan helyzetbe kerül, hogy a legmegfelelőbb felhőszolgáltatót választhassa ki.