Benchmarking van cloudservers: Een gids voor cloudcomputing-insiders

Veel nieuwe klanten willen de prestaties testen wanneer ze CloudSigma gaan gebruiken; ze willen vaak de prestatieresultaten vergelijken tussen cloudservers en hun eigen infrastructuur, en dat is logisch. Een directe prijsvergelijking per resource vertelt lang niet het hele verhaal; wat echt telt is het eindresultaat: hoeveel kost het om een specifieke computertaak uit te voeren?

Voor elke gegeven vereiste kan het aantal benodigde resources sterk variëren tussen clouds. Dit betekent dat alleen prijzen vergelijken niet werkt. De keerzijde is dat het geïsoleerd vergelijken van prestaties niet veel beter is. Betekenisvolle vergelijkingen moeten zowel prijs als prestaties samenbrengen om een maatstaf voor de kosten per rekeneenheid te berekenen. In dit bericht ga ik een aantal van mijn gedachten delen over het benchmarken van onze cloudservers en andere. Ik zal ook enkele tips geven voor het verkrijgen van nuttige resultaten en wat ze werkelijk betekenen.

Waarschuwingen vooraf

Om te beginnen ben ik vrij sceptisch over benchmarken in het algemeen. Het biedt zelden een echt inzicht in het praktijkgebruik. Kortom, er is geen echte vervanging voor het draaien van de daadwerkelijke applicaties die u op het platform wilt gebruiken. Als u dit kunt bereiken tegen een redelijke investering in tijd, dan is er geen vervanging voor een dergelijke test.

Een andere factor is hoe druk de cloudprovider het heeft. U kunt cloudservers benchmarken en uitstekende resultaten behalen. Deze kunnen echter grotendeels te wijten zijn aan de mate van gebruik (of het gebrek daaraan) van die specifieke provider. Dat is misschien geen positief teken. Het kan wijzen op operationele problemen, verloren klanten, eerdere problemen met beschikbaarheid en betrouwbaarheid, enz. U zou daarom altijd onderzoek moeten doen naar eerdere uitval en andere potentiële problemen van de cloudprovider bij het interpreteren van hun benchmarkresultaten.

Als laatste waarschuwing vooraf: prestaties zijn niet de enige factor die u in overweging moet nemen. Vaak kunnen lagere prestaties een weerspiegeling zijn van een robuustere (en redundante) onderliggende hardware-architectuur. Het is daarom altijd belangrijk om een zeer duidelijk beeld te hebben van de infrastructuur waarop de cloud is gebouwd. Zo kunt u resultaten eerlijk vergelijken, zodat u een weloverwogen aankoopbeslissing kunt nemen.

Definieer het probleem

Verderop in dit bericht zet ik de verschillende aspecten van prestaties uiteen en hoe u de resultaten het beste kunt interpreteren. Voordat u echter gaat benchmarken, is het belangrijk om het type computing te karakteriseren dat u in de cloud wilt gaan uitvoeren; dit bepaalt het relatieve belang van verschillende prestatiemaatstaven. Als u bijvoorbeeld een databaseserver wilt plaatsen die zwaar wordt belast met leesacties maar weinig schrijfacties, moet u letten op de schijfprestaties in de cloud en met name op niet-sequentiële leestoegang.

Dus voordat u begint met het benchmarken van cloudservers, moet u daadwerkelijk vastleggen wat u als goede prestaties van de cloud beschouwt. U moet bepalen welke aspecten cruciaal zijn en een onevenredige impact hebben op de prestaties van uw computing in de praktijk. Zodra u hier een duidelijk beeld van heeft, bent u in de positie om te beginnen met benchmarken.

Rekenprestaties

Als we kijken naar de pure rekenprestaties, hebben we het over CPU en RAM. De verschillen in prestaties op puur rekenniveau tussen clouds zijn eigenlijk niet zo groot. Er zijn echter enkele factoren die de werkelijke verschillen veroorzaken.

Veruit de grootste factor die de rekenprestaties in de cloud beïnvloedt, is overboeking (contention). Publieke clouds zijn multi-tenant omgevingen. RAM en opslag kunnen niet echt worden overgealloceerd (hoewel ze wel kunnen worden oververkocht), maar CPU kan dat wel en wordt dat ook. De mate van overboeking varieert aanzienlijk, maar in wezen zijn aanbieders van publieke clouds in staat om de CPU-capaciteit van een fysieke host voor meer dan 100% te verkopen.

Sommige van de grootste aanbieders gebruiken CPU-overboekingsratio's van meer dan drie keer. Dit betekent dat de totale ‘verkochte’ CPU-capaciteit van alle virtuele servers op dezelfde fysieke machine wel drie keer de werkelijke CPU-capaciteit kan zijn. Ze doen dit omdat de meeste virtuele servers het grootste deel van de tijd bij lange na niet 100% van hun toegewezen CPU gebruiken. Toch hebben overboekingsratio's een directe invloed op de prestatiebenchmarks en het praktijkgebruik van cloudservers. Als de overboeking hoog is (d.w.z. bij meer dan 200% CPU-toewijzing), zullen de prestaties van de cloudserver aanzienlijk verslechteren.

Simpel gezegd: als de belasting op een fysieke machine hoger is dan 1 per core, worden rekentaken in de wachtrij geplaatst en duurt het langer voordat die virtuele machine de taak heeft voltooid. Aangezien de meeste clouds kosten in rekening brengen op basis van capaciteit/uur, heeft dit een directe invloed op de kosten voor klanten van die cloud.

De andere belangrijke factor die de rekenprestaties beïnvloedt, is het aantal CPU-cores waartoe de virtuele machine toegang heeft. Dit is niet voor alle applicaties een factor, maar veel moderne applicaties ondersteunen wel multi-threading. In feite betekent dit dat de applicatie en/of het besturingssysteem in staat is om de rekentaken over meerdere cores te verdelen. Een geweldige tip om de prestaties van je computing te verbeteren, is het aantal threads (d.w.z. cores) dat een applicatie kan ondersteunen, af te stemmen op het aantal cores waartoe de virtuele machine toegang heeft.

Helaas is dit bij veel openbare clouds niet mogelijk. Dit komt omdat hun virtualisatieplatforms geen virtualisatie op CPU-coreniveau ondersteunen. Met andere woorden, elke core kan slechts door één virtuele machine tegelijk worden gebruikt. In clouds die wel virtualisatie van CPU-cores ondersteunen, zou je moeten experimenteren met het variëren van het aantal cores voor die machine, terwijl de totale CPU-grootte gelijk blijft.

Als je bijvoorbeeld een 2GHz-machine hebt, kun je zien hoe het verdubbelen van de gebruikte cores van twee naar vier je benchmarking beïnvloedt. Hierdoor kunnen applicaties die op die virtuele machine draaien, taken via vier cores tegelijkertijd uitvoeren. In ons geval kun je het aantal cores dat een virtuele machine gebruikt instellen via het tabblad ‘geavanceerd’ in het serverdetailvenster van de webconsole. Vergeet niet om altijd te controleren wat de standaard core-grootte van de cloudprovider is voordat je handmatig het aantal gebruikte cores overschrijft. In ons geval is dat 2,2 GHz per core, maar dit verschilt van cloud tot cloud.

Ik zou aanraden om te overwegen om POV-RAY, CoreMark, Dhrystone of Whetstone te gebruiken voor het benchmarken van de prestaties van cloudservers.

Opslag: de echte prestatiebenchmark voor cloudservers

Alle prestaties worden beperkt door de zwakste schakel waar een knelpunt ontstaat. Momenteel is de technologie op het gebied van virtualisatie aanzienlijk gevorderd met betrekking tot het gebruik van CPU en RAM. Een enkele fysieke machine kan bijvoorbeeld worden gevirtualiseerd en meerdere cloudservers hebben met minimaal verlies van de totale geaggregeerde prestaties. Helaas moet er op het gebied van opslag nog veel vooruitgang worden geboekt. Het eindresultaat is dat in de meeste gevallen de prestaties van virtuele servers in de cloud worden bepaald door de prestaties van de opslagoplossing van die cloud.

Kortom, opslag is momenteel de beperkende factor voor de prestaties van de meeste rekentaken in de cloud. Wat voor resultaten POV-Ray en andere benchmarks ook opleveren voor pure rekentaken, de realiteit is dat de snelheid waarmee de virtuele server gegevens kan ophalen van en schrijven naar fysieke opslagschijven momenteel de werkelijke prestaties van een cloudserver bepaalt.

Met dat in gedachten komen de werkelijke prestatieverschillen in de cloud, zelfs met betrekking tot rekentaken, meestal voort uit verschillen in opslagprestaties. Zoals eerder in dit bericht vermeld, zijn er zeer verschillende klantbehoeften afhankelijk van de rekentaak. Dit geldt nergens meer voor dan voor opslag. Heeft u snelle leestoegang nodig tot grote sequentiële datablokken (zoals streaming media) of to kleine, uiteenlopende stukjes informatie (misschien in een grote database)? Moet u zware schrijftoegang ondersteunen voor snel veranderende gegevens die periodiek in grote bursts worden opgevraagd? Er zijn talloze scenario's en elk scenario zal anders presteren op hetzelfde platform.

Fundamenteel komen de prestatieverschillen neer op architectuur. Die verschillen in architectuur zijn meestal het gevolg van verschillende mate van robuustheid met betrekking tot de opslag van gegevens, de redundantie ervan en dus eigenlijk de waarschijnlijkheid dat ze ooit onherstelbaar verloren gaan. Op een hoog niveau maken clouds gebruik van gecentraliseerde data-oplossingen in de vorm van een Storage Area Network (SAN) of meer gedistribueerde lokale opslagoplossingen. Daarbij bevindt de opslag zich op elke individuele fysieke machine.

Goede SAN’s hebben intrinsiek een hoog niveau van redundantie ingebouwd. De prestaties lijden er echter onder omdat gegevens van de SAN over het netwerk naar de CPU en het RAM van de virtuele machine’s moeten worden verzonden voor rekentaken. Als gevolg hiervan hebben op SAN gebaseerde clouds over het algemeen lagere prestaties onder gelijke omstandigheden in vergelijking met clouds met lokale gedistribueerde opslagoplossingen. Een ander nadeel van een SAN is dat het een zeer groot single point of failure vertegenwoordigt. SAN’s zijn uiterst betrouwbaar. Als het ooit echt misgaat (en dat is gebeurd), dan krijgt u waarschijnlijk te maken met een zeer grote uitval en corruptie van gegevens.

De meeste cloudleveranciers die SAN’s gebruiken, maken grotendeels om kostenredenen geen gebruik van volledig redundante fail-over-oplossingen zoals die in de enterprise-omgeving worden gebruikt. Het is belangrijk om te beseffen dat niet elke SAN gelijk is en om van de cloudleverancier te begrijpen welk niveau van redundantie zij toepassen bij hun SAN’s.

Op lokale opslag gebaseerde clouds hebben over het algemeen goede schijfprestaties. Vaak bieden ze echter alleen lokale opslag in een niet-persistente vorm aan. Dit is geen eerlijke vergelijking met persistente opslag. Tijdelijke opslag hoeft niet op dezelfde manier bestand te zijn tegen storingen als permanente opslag. Het is altijd belangrijk om persistente opslag te vergelijken met persistente opslag voor zinvolle resultaten.

Als u kijkt naar clouds met gedistribueerde lokale opslagoplossingen, moet u ook weten welke redundantie ze hebben. Harde schijven vallen in aanzienlijke mate uit en dus is de opslagmethode cruciaal. De meeste leveranciers gebruiken een of andere vorm van RAID maar er zijn zeer verschillende niveaus van veiligheid. Aan de onderkant heb je RAID1, waarbij twee schijven elkaar in feite spiegelen. Dit levert meestal goede prestaties op. Maar wanneer één schijf uitvalt, loopt de data het risico volledig verloren te gaan als de tweede (zwaar belaste) schijf uitvalt voordat de vervangende schijf alle data van de oude schijf heeft gekopieerd. Bovendien zullen de schijfprestaties tijdens de wederopbouw van de RAID1-array waarschijnlijk veel en veel lager zijn dan normaal.

Veel leveranciers gebruiken daarom RAID5 (bestand tegen het uitvallen van één schijf) of RAID6 (bestand tegen het uitvallen van twee schijven). RAID6 biedt veruit de veiligste oplossing voor lokale opslag, maar eist een grote tol van de prestaties. Onze aanpak is om RAID6 te gebruiken, maar dit te combineren met hoogwaardige hardware RAID-controllerkaarten. Deze hebben grote geheugencaches en zijn voorzien van een batterijback-up. De RAID-controllerkaarten die wij gebruiken zijn in feite aanzienlijk duurder dan de volledige schijfarrays. Hierdoor kunnen we prestaties leveren die vergelijkbaar zijn met veel minder veerkrachtige configuraties, terwijl we toch het zeer grote veiligheidsnet van RAID6-opslag bieden. Lees meer over onze cloudinfrastructuur -configuratie waar we zeer open over zijn.

Ik raad aan om IOzone of Bonnie++ te gebruiken voor schijfprestatietests.

Dus, bij het interpreteren van de resultaten van opslagbenchmarks moet u ervoor zorgen dat u ook over de volgende informatie beschikt:

• welke opslagarchitectuur gebruikt de cloud (lokaal, SAN, overig)?
• welke failover- en redundantiemaatregelen zijn er getroffen voor de data?
• is de opslag die ik benchmark tijdelijk of persistent?

Als u de antwoorden op deze drie vragen combineert met de resultaten van de benchmarking, krijgt u een vrij goed inzicht in de werkelijke opslagprestaties.

Netwerk

De prestaties van het netwerk zijn aanzienlijk eenvoudiger te bepalen en te meten dan reken- en schijfprestaties. Netwerkprestaties hebben twee belangrijke aspecten: latentie en bandbreedte.

Afhankelijk van uw behoeften kan de latentie van het netwerk dat de cloudleverancier gebruikt wel of niet belangrijk zijn. Als u de cloud gebruikt voor grotendeels op zichzelf staande bewerkingen, is het onwaarschijnlijk dat latentie een prioriteit zal zijn. Als u echter realtime applicaties uitvoert die communiceren met de wereld buiten de cloud, dan is latentie een cruciale prestatiebepalende factor.

Meestal is de overgrote meerderheid van de latentie het gevolg van pure fysieke afstand. De meeste latentie tussen Londen en San Francisco is bijvoorbeeld in feite de tijd die het licht kost om die afstand te overbruggen. Verschillen in latentie worden bepaald door de variërende efficiëntie van de afgelegde route. Dit is het aspect dat van cloud tot cloud verschilt. De efficiëntie van de route is een direct gevolg van de netwerkproviders waarmee de cloud directe verbindingen heeft. Dit gebeurt door IP-connectiviteit van hen af te nemen of via peering. Als u naar latenties kijkt, kunt u eenvoudig uw cloudserver pingen en de prestaties ervan bepalen. Het is echter belangrijk om de prestaties te bepalen tussen uw daadwerkelijke eindgebruikers en uw cloudserver.

Als de meeste van uw gebruikers zich in één geografisch gebied bevinden of als de toegang voornamelijk vanaf het hoofdkantoor van uw bedrijf zal zijn, is het belangrijk om de prestaties vanaf die locaties te testen. Commerciële diensten zoals Pingdom bieden een kosteneffectieve manier om de latentie vanaf een groot aantal algemene locaties wereldwijd tegelijkertijd te bepalen.

De werkelijke bandbreedte die uw cloudserver kan behalen is ook erg belangrijk. In tegenstelling to meer traditionele hostingoplossingen, rekenen cloudleveranciers meestal af op basis van het totale volume van de gegevensoverdracht. Met andere woorden, niet tijdsafhankelijk zoals bij een tarief per Mbit dat u 24/7 een vast connectiviteitsniveau biedt. Ondanks dit zullen veel cloudleveranciers de bandbreedte naar elke virtuele server ‘knijpen’. Dit is onzichtbaar voor de gebruiker totdat u die grens bereikt. Als u een vrij grillig bandbreedteprofiel heeft, kan dit een belangrijke prestatiefactor zijn om rekening mee te houden.

Om de werkelijke bandbreedte van uw cloudserver te testen, is het belangrijk om te proberen gegevens naar de cloudserver te downloaden van een bron die de overdrachtssnelheid aan hun kant niet daadwerkelijk beperkt. Ik vind vaak een geweldige manier om de beschikbare snelheid te bepalen, het downloaden van een groot bestand van een grote leverancier zoals Microsoft, Ubuntu of nog beter door het besturingssysteem te patchen. Dit downloadt meestal veel verschillende bestanden van verschillende locaties tegelijkertijd. Het geeft u een vrij goed gevoel voor de snelheid van uw verbinding.

Ik download vaak een Fedora live CD van hun hoofdsite als een standaardtest, maar u zou op zijn minst altijd moeten experimenteren met een paar verschillende bestanden en locaties. Als u erop staat uw eigen zeer snelle bedrijfsnetwerk te hebben, wilt u misschien in plaats daarvan als test een bestand van uw cloudserver naar uw eigen netwerk downloaden.

Voeg nu de prijsstelling weer toe om de resultaten te wegen

Met de bovenstaande methoden zou u een goed gevoel moeten krijgen van hoe de verschillende leveranciers van cloudservers presteren. Bovendien moet u weten op welke aspecten u zich moet richten die het belangrijkst zijn voor uw specifieke behoeften.

De laatste stap is het toevoegen van een prijsdimensie aan de benchmarkresultaten. Hier is geen formule voor. Het hangt af van de relatieve prestaties van de verschillende aspecten van hierboven en u bepaalt deze. Als één cloud 40% betere prestaties levert (zoals door u bepaald) maar slechts 30% duurder is, dan zijn ze duidelijk aantrekkelijk. Evenzo, als u een grote behoefte aan bandbreedte heeft, kunnen lagere rekenprestaties worden overtroffen door een concurrerend tariefplan voor gegevensoverdracht. De sleutel tot het nemen van de juiste beslissing is om alle verschillende factoren erbij te betrekken.

Ten slotte moet benchmarking deel uitmaken van een groter proces om te bepalen welke cloudservers geschikt zijn voor u. Dit moet ook andere aspecten omvatten. Dit kan bijvoorbeeld gaan om service level agreements, overwegingen rond data/vendor lock-in, fysieke locatie en juridische jurisdictie. Door al deze aspecten samen te brengen, positioneert u uzelf om de juiste keuze te maken voor een cloud computing-leverancier.