Erlang: Pi2 ARM cluster tegen Xeon VM

Dit is geen speelgoed

English version - Engelstalige versie (origineel)

Version francophone - Franstalige versie

In het kort

Een goedkoop, energie-efficiënt ARM cluster prototype bewijst dat het een mogelijk alternatief kan zijn tegenover een meer traditioneel server platform voor een real-world Erlang/OTP server applicatie.

Na de inleiding volgt een beschrijving van de vergeleken platforms, een kort woord over toepassing die werd gebruikt om ze te vergelijken, de verkregen grafieken en bijhorende observaties en ten slotte een conclusie.

Inleiding

AMD’s aankondiging van een 64-bit ARMv8 CPU, de Opteron A1100, wekte mijn curiositeit. Hardware platforms zijn tegenwoordig zo krachtig en kostbaar dat ze op meerdere niveaus gevirtualiseerd moeten worden (computers, storage, netwerk, …), evenveel extra lagen van bijkomende complexiteit, om ze volledig te kunnen benutten. Dit maakt de gedachte van eenvoudige, goedkope en energiezuinige hardware bijzonder verfrissend.

Met de juiste software en tools om load-balancing, fail-over en andere uitdagingen van distributed computing aan te gaan, is dat gedacht een bijna perfect werkend prototype geworden.

Testplatforms

Terwijl ontwikkelingsborden met behulp van de Opteron A1100 al beschikbaar zijn, heb ik mijn keuze op de Raspberry Pi 2 (model B) als een kosteneffectief test platform gevestigd. Het draait de server OS (Debian) perfect. En gezien de 32 bit ARMv7 CPU (dezelfde als in mijn smartphone) een oudere en langzamer architectuur is die zelfs geen warmtedissipatie nodig heeft, deed de chip het vrij goed.

De responsiviteit van de applicatie op de Raspberry cluster was zeer voldoende voor normaal gebruik, ondanks de zwakke punten van het platform. Gezien de resultaten van de vergelijking, ben ik er bijna zeker van dat hij onze huidige werklast in productie zou kunnen verwerken zonder al te veel moeite.

PI2C

Raspberry Pi 2 Cluster

Raspberry Pi 2 specificaties:

• CPU: Cortex A7 quad @ 950 MHz, 1 GB RAM, lichtjes overklokt
• Opslag: 32 GB Samsung EVO + MicroSD
• Kostprijs: ~ 30 €
• Stroomverbruik standby: 3,33w belast: 4,8w
• 100 Mbps Ethernet *

De hele cluster (4 Pi2’s: 1 Apache load balancing proxy, 3 voor de toepassing cluster):

• Kostprijs: ~ 200 €
• Stroomverbruik standby: 13W belast: 18W
• De Apache proxy, die 2 Ethernet-poorten heeft, dient ook als DHCP, DNS, en router (NAT) voor de andere leden van de cluster, die over zijn eigen intern netwerk beschikt.

DevX

Xeon Server

Het gelaat van “serious computing”

DevX is de applicatie ontwikkeling server, en draait in een VmWare gevirtualiseerde HP BladeSystem omgeving met StoreVirtual iSCSI SAN-opslag in een zaal met airconditioning, en heeft meerdere 24/7 hardware support contracten. Specificaties:

• VM: 2x 2,4Ghz cores (Xeon E5620), 3 GB Ram
• Opslag: 50 GB iSCSI
• Bladeserver stroomverbruik*: 250W (niet inbegrepen: de opslag en airconditioning)
• Server blade kosten*: ongeveer 5000 € (niet inbegrepen: support contracten, opslag, blade enclosure en airconditioning). RCP van de CPU alleen: $ 391,00
• De server kosten en energie verbruik moeten worden aangepast aan het aantal lopende VM’s op de hardware (6)

De test applicatie

De applicatie die gebruikt wordt in deze vergelijking is een real-world server applicatie: het e-justitie platform van de Belgische Raad van State. Het is gebaseerd op Erlang / OTP, en kan worden uitgevoerd in zowel enkele als in een gedistribueerde (meerdere instanties) modus. Het test scenario maakt gebruik van standaard operaties die door de applicatie aangeboden zijn, maar is desondanks niet representatief van hoe een echte gebruiker zou handelen (een mens van vlees en bloed is veel trager). Het is ook sterk afhankelijk van de database (Mnesia): daarom werd er ook een pure berekening test toegevoegd.

De toepassing (database inbegrepen) werd niet gewijzigd, buiten hercompilatie, om te kunnen draaien op de ARM instructieset of op een hardwareplatform met beperkte resources. En de meeste fouten die door de stress-testing aan het licht werden gebracht (zoals de neiging van de toepassing om zich te verzuipen in hoge aantallen gelijktijdige aanvragen) zijn reeds gecorrigeerd, maar dat is een onderwerp voor een ander artikel.

Overwegingen over beide omgevingen

PI2C:

+Applicatie draait in één Erlang node op elk cluster lid;
- Zeer trage storage. Streng willekeurige lezen & schrijven test: respectievelijk 1.819 en 855kb/s;
- Langzamer netwerk, en het feit dat de DB, Mnesia, zich met de verschillende clusterleden moet synchroniseren, waardoor bij overbelasting een achterstand van transacties ontstaat, die nog word verergerd door de trage opslaglaag.

DevX:

+ De oorspronkelijke omgeving waarin de applicatie is ontwikkeld
+ Snelle storage. Streng willekeurige lezen & schrijven test: respectievelijk 27.577 en 11.062kb/s
+ Enkele instantie: geen synchronisatie nodig met andere instanties
- Toepassing is verdeeld over 2 Erlang nodes (mochiweb server en applicatie kern), hetgeen wat latency toevoegt

Vergelijkende prestatietests

Methodiek en concepten:

Cyclus: een cyclus bestaat uit verschillende seriële operaties zoals het creëren van een object, browsen, wijzigen en verwijderen. Het weerspiegelt wat een menselijke gebruiker zou doen, maar véél sneller.

Agent: Een agent voert cycli (meervoud van cyclus, men leert elke dag wat bij) uit. Eenmaal een cyclus met succes werd uitgevoerd, wordt een nieuwe cyclus gestart. Meerdere agenten kunnen gelijktijdig worden uitgevoerd. Elke proef begint met 1 agent en verdubbeld hun aantal stapsgewijs tot 128 of 256, afhankelijk van het optreden van time-out’s.

Het python multi-mechanize performance test framework werd gebruikt om de tests uit te voeren, waarmee HTTP-queries werden gegenereerd en gericht op de load-balacing Apache proxy van de doelomgeving. Een volledige test duurde 120 seconden, en start al zijn agenten (indien van toepassing) binnen de 10 seconden (dit bevoordeelde DevX wellicht een beetje).

Prestatievergelijking tussen PI2C en DevX

Dit is een directe prestatievergelijking tussen beide omgevingen, waar elk zijn sterkste kant toont: zuivere CPU-snelheid voor DevX (wanneer licht beladen) en load balancing voor PI2C (eenmaal zwaar beladen).

• Als er slechts één actieve agent is heeft DevX’s snelle CPU een duidelijk voordeel. PI2C heeft het moeilijker: de taak kan niet worden gesplitst tussen cluster leden, en er is dus slechts 1 op de 3 CPU’s die kan werken op een bepaald moment;
• Met slechts 2 cores bereikt DevX zijn plateau (100% belasting) aan 4 gelijktijdige agenten, terwijl PI2C met zijn 12 cores zijn toppunt maar bereikt bij 32. Hij verbeterde onderweg gestaag zijn prestaties, en bereikte meer dan 70% van de prestaties van DevX;
• Met 128 gelijktijdige agenten beginnen beide omgevingen time-outs te ervaren : opvragingen die te lang duren en worden opgegeven;
• Eenmaal 256 gelijktijdige agenten actief zijn worden de scores negatief, wat betekent dat zelfs de eerste cyclus van bepaalde agenten niet voltooid werd (dit vertaalt zich via een negatieve score als gevolg van een paar eigenaardigheden van het test framework).

Hier is te zien hoe PI2C het prestatieniveau van DevX benaderde: hij was in staat het aantal cycli per agent langer stabiel te houden.

• Vanaf 4 gelijktijdige agenten ervaart DevX een lineaire vermindering van succesvolle cycli: hun aantal halveert bij elke verdubbeling van het aantal agenten;
• PI2C toont een veel geleidelijker vermindering, die pas lineair wordt vanaf 16 gelijktijdige agenten.

PI2C: Invloed van clustergrootte

Voor deze test werd alleen de PI2C cluster gebruikt, met een verschillend aantal clusterleden.

• Hoe minder clusterleden, des te sneller de toepassing in het begin is. Dit komt omdat er minder databasereplicatie- en synchronisatiebewerkingen nodig zijn;
• Eenmaal een bepaalde belastingdrempel voorbij kickt load balancing in met al zijn voordelen: de belasting wordt verdeeld over de verscheidene clusterleden. Met andere woorden: de toepassing kan scalen.
• Prestatieverhoging is niet lineair: het verdubbeld niet wanneer het aantal clusterleden verdubbeld, vanwege de kosten van database distributie en replicatie. Dit is een bekend gedrag van Mnesia, en hoeft alleen maar in aanmerking worden genomen (net zoals de Whatsapp mensen deden).

Zuivere rekenkracht test

Met oog op pure rekenkracht uit te testen heb ik een eenvoudige Mandelbrot fractal genererende functie toegevoegd. Een cyclus wordt een enkele berekening, en bevrijd hierdoor PI2C van zijn te langzame opslagmedium, waardoor hij zijn ruwe, ongebreidelde, krankzinnige processing power kan ontketenen.

Meerdere omgeving configuraties worden hier getoond. PI2C met verschillende aantallen actieve clusterleden, en een opgefokte DevX met dubbel zoveel CPU cores.

• De lineaire toename van prestaties laat zien hoe de belasting wordt verdeeld onder de leden van de cluster of processor kernen (zoals verwacht: dit is enkel een berekening);
• PI2C overtreft DevX eens 32 gelijktijdige agenten actief zijn. Om zeker te zijn dat dit niet te wijten was aan een onbekende bottleneck (test PC, netwerk, proxy, …), werd dezelfde test uitgevoerd met een DevX van 4 cores, hetgeen daadwerkelijk zijn score verdubbelde: geen bottleneck.
• Let op de betere prestaties van de 4x DevX gebruikt door één enkele agent ten opzichte van de 2x DevX. 4 cores doen DevX niet sneller werken, hij kan niet sneller dan 2,4 GHz: het verschil ligt gewoon bij Erlang en de toepassing die de enkele query verspreid over meer cores (parallele programmatie). Dit maakt 8+ core ARM CPU nog interessanter.
• PI2C kan de taken van een enkele query alleen verspreiden over de CPU van één cluster-lid. Dat is de reden waarom elke configuratie van PI2C vrijwel dezelfde score heeft bij de eerste stap. Hetzelfde geldt voor twee actieve agenten en beide configuraties met minstens 2 leden.
• De bijna perfecte lineaire verhoging van de prestaties, samen met het aantal CPU cores of cluster leden laat zien hoe scalable de Erlang VM werkelijk is (niets nieuws, eigenlijk).

Mnesia transactie modus test

Dit onderwerp is eerder van belang voor Erlang gebruikers. Mnesia, door gebruik van mnesia:activity/2, kan worden geraadpleegd op 4 verschillende manieren: met of zonder transacties, synchroon of asynchroon. Elke methode heeft zijn voordelen, een evenwichtsoefening tussen prestaties en consistentie. PI2C ervoer een aantal fouten in asynchrone modes, als gevolg van de transactie achterstand die zo groot werd dat de gegevens tussen cluster leden begon te verschillen (dat is te verwachten).

Het verschil tussen synchrone en asynchrone modi (nog zo’n schoon meervoud) is duidelijk niet relevant voor DevX (geen andere cluster leden om zich mee te synchroniseren), terwijl PI2C de verwachte trade-offs van prestaties ten opzichte van betrouwbaarheid vertoont. Zonder het extra gewicht van transacties en synchroniciteit, in het licht-blauw, is PI2C wel in staat om DevX’s niveau bijna te bereiken (voordat hij in vlammen neerstort).

• Het enige merkbare verschil DevX is tussen «dirty» operaties (zonder transacties) en transacties (met table locks, rollbacks in geval van storingen, …);
• PI2C DB foutgehaltes bereikten 1-in-100 in async_dirty en 1-in-500 in asynchrone transactie modi (geen enkel wanneer gesynchroniseerd, zoals verwacht);
• In de cluster is er een performance hit als synchroniciteit wordt gedwongen, maar dat verschil verdwijnt bijna onder zware belasting, waar de toegevoegde beperking transactie achterstand en overbelasting helpt te vermijden, en door echte consistentie wat nutteloze operaties vermijdt.

Conclusie

Met een betere storage layer zou PI2C een véél ernstigere tegenstander geweest zijn tegenover een “traditionele” virtuele server, voor een fractie van het geld- en energieverbruik. Ik moest het nog melden, maar de test applicatie heeft nog een aantal seriële knelpunten, taken die niet kunnen worden geparalleliseerd, zoals interacties met een Prolog socket server, die zeker een negatieve invloed op de prestaties van de cluster hebben gehad.

Het prototype is in staat geweest om de haalbaarheid en zelfs de prestaties van een zeer bescheiden ARM cluster aan te tonen. Ik begin mij er van te overtuigen dat modernere en krachtigere ARM-chips (ze blijven maar komen), met ernstige opslag en netwerkmogelijkheden, hun aanwezigheid in serverlokalen zullen kunnen rechtvaardigen, en eventueel een nieuw tijdperk zullen invoeren van goedkope en energiezuinige serverruimtes die, afhankelijk van waar je ze installeert, niet eens meer gekoeld hoeven te worden.