Servers in datacenters verbruiken minder energie zodra hun zogeheten powermanagement is geoptimaliseerd. Dat wisten we al en optimalisatie van deze instellingen is zelfs wettelijk verplicht. Brancheorganisaties Dutch Data Center Association (DDA) en NLdigital starten een campagne om servereigenaren te wijzen op deze verplichting.
Datacenters worden geassocieerd met een hoog energieverbruik. Vooral de systemen voor koeling en elektriciteitsdistributie verbruiken veel stroom. De sector werkt al langere tijd aan energiebesparende maatregelen. Deze hebben voornamelijk betrekking op de eigen systemen in de datacenters. De servers in deze ruimten zijn echter meestal eigendom van derden; organisaties die de faciliteiten huren voor plaatsing van hun eigen apparatuur.
Uitdaging
‘Met dit initiatief willen we onze klanten, die de eigenaar zijn van de servers, informeren over de verdere energie-efficiëntiemogelijkheden van hun computerapparatuur’, zegt DDA-directeur Stijn Grove. Optimalisatie van het powermanagement is een maatregel op de lijst van erkende maatregelen voor datacenters, de zogeheten EML-lijst. De uitdaging zit hem volgens de brancheorganisaties in het feit dat de servereigenaren deze optimalisatie moeten instellen.
De datacenters die zijn aangesloten bij het initiatief gaan hun klanten persoonlijk attenderen op de noodzaak tot het nemen van deze maatregelen. Ook zullen zij hun vragen een Energie Efficiëntie Verklaring (EEV) te ondertekenen. Hierin geeft de klant aan bewust te zijn van deze maatregel, inventariseert hoe de instellingen staan en hoe hij deze aanpast indien nodig.
Handleiding
Hoe de aanpassing het beste plaatsvindt, staat vermeld in de ‘Handleiding Happy Flow’ (pdf), een document dat in samenwerking met fabrikanten werd opgesteld in het kader van Leap. Leap is een eerder initiatief van onder meer NLdigital en Amsterdam Economic Board voor technische maatregelen die leiden tot energiebesparing in de sector. Wat de juiste instellingen zijn, is afhankelijk van de gebruikte hardware en software zoals het besturingssysteem.
Bij de installatie van nieuwe servers wordt geadviseerd deze direct in ‘balanced mode’ te zetten. Hierdoor worden klokfrequenties van de processor aangepast aan de werkdruk, legde technisch adviseur Dirk Harryvan van Certios eerder uit bij Computable. In het geval dat een processor langer werkloos is (idle) en de powermanagement-instelling het toestaat, is de processor in een lagere energietoestand te brengen of zelfs uit te zetten. Dit kan gemiddeld tien procent energie besparen, zonder merkbare gevolgen voor de serverprestatie.
Alleen jammer dat de meest belangrijke instelling niet wordt genoemd: Software. Het is allemaal wel leuk om te kijken naar BIOS instellingen maar dat werkt alleen als de processor ook daadwerkelijk niet wordt aangesproken door de software. Er zijn in software, zowel kernel als applicaties, diverse timers en keep-alive functies, die allemaal tegelijk de processor dusdanig actief houden dat effectief de CPU nooit even rust krijgt, en dus niet terug schakelt in een lagere C-state.
Vrijwel alle processoren kennen C-states, dat gaat van C0 tot C5. C0 is volledige load. Bij C1 is er minder load. Nog geen 10% van de processoren in datacenters wereldwijd komen ooit in de C1 state. C2 wordt maar zelden bereikt, C3, 4 en 5 vrijwel nooit. Dit heeft niets te maken met C-state instellingen van de hardware maar met software die de processor actief houdt.
Een voorbeeld. Toen Linux op het mainframe ging draaien, zo’n 20 jaar geleden, hebben we gezien dat deze machines 100% actief bleven. In de kernel waren verschillende timers actief die elk voor zich de kernel actief hielden. Er is toen een patch uitgebracht die de kernel jiffies bundelde waardoor een Linux machine nog maar een paar keer per seconde actief werd in plaats van meer dan 300 keer per seconde. Bedenk dan even dat deze patch ervoor heeft gezorgd dat alle Linux machines (en dan niet alleen mainframe servers) een stuk minder CPU en dus stroom gingen verbruiken.
Een ander voorbeeld. In de afgelopen twee (!) jaar heb ik een ticket open gehad bij Suse. Sinds SLES 12.5 is er een update gekomen die ervoor zorgt dat de machine 100-en keren per seconde wakker wordt. Uiteindelijk is gevonden dat in de netwerk modules een tabel elke paar millisecondes wordt geraadpleegd om te kijken of er nog obsolete items in zitten. Misschien effectief in drukke webservers (dat was de reden van de patch) maar zeker niet voor idle servers. Het gevolg was dat onze idle servers twee keer zoveel CPU gingen gebruiken. Na twee jaar is er dan eindelijk een patch uitgebracht (met ingang van SLES 15.3) die dit gedrag weer terugdraaide. Maar het kostte me erg veel moeite om Suse ervan te overtuigen dat er 1) een echt probleem is, en 2) dat dit ook echt opgelost moet worden. (Tip, upgrade naar SLES 15.3 of een vergelijkbare kernel versie in je favoriete distributie.)
Is dit nu belangrijk voor idle servers? JA! Idle servers zijn verantwoordelijk voor zeker 50% (!) van het energieverbuik in een datacenter. Dus ik kijk veel liever naar het terugbrengen van het energieverbruik van idle servers dan voor productionele load. De eerste is alleen maar overhead, de tweede is datgene waar de klant voor betaalt. Virtualisatie kan dan misschien wel een beetje helpen maar ook virtuele CPU load is nog steeds CPU load die fysiek moet worden uitgevoerd, met bijbehorend stroomverbruik.
In het verleden is (door Intel) Powertop ontwikkeld. Voornamelijk om de lifetime van Laptop batterijen te kunnen verhogen, maar uiteraard kon dit dan ook het stroomverbruik van servers terugbrengen. Met Powertop kun (of liever gezegd, kon) je bekijken welke processen actief zijn en in welke mate. Ik heb dit regelmatig gebruikt om te bepalen welk process mijn servers actief hield. Helaas werkt Powertop niet meer in nieuwe Linux kernels omdat na een patch de wakeups van specifieke processen in de kernel niet meer gemeten kunnen worden.
Ik heb een paar jaar geleden een discussie op een forum gehad waarbij men zich afvroeg waarom de nieuwe linux kernel zoveel aandacht had voor energieverbuik. Immers “onze servers zitten op netstroom”. (Jawel, een letterlijke quote, alsof netstroom gratis is.) Zolang zogenaamde specialisten en/of ontwikkelaars zich niets aantrekken van CPU verbruik van OS en/of applicaties is daar nog een wereld te winnen. Dat levert uiteindelijk veel meer op dan wat de hardware ooit kan klaar spelen. De Intels van deze wereld hebben C-states ontwikkeld om het energieverbruik van processoren te verminderen maar de applicaties zorgen ervoor dat deze C-states vrijwel nooit worden aangsproken.
Hierbij een paar zaken die echt helpen:
– Draai geen GUI op de servers. Een GUI (Windows, X-windows) minimaal ver-TIEN-voudigd(!) het energieverbruik van een server. Het is niet voor niks dat zelfs Microsoft een Windows server versie heeft uitgebracht waar de GUI kan worden uitgeschakeld.
– Draai geen onnodige processen. (Duh, dat is een no-brainer.)
– Schakel USB uit. USB scant zeer regelmatig de USB poorten om nieuwe hardware te vinden. Hoe vaak heb je nieuwe hardware op een USB poort? Toch zeker niet elke 10 milliseconden?
– Voor linux machines, schakel terug van run-crons naar run-parts. In de crontab wordt run-crons elk kwartier uitgevoerd, ook voor standaard crons zoals cron.hourly, daily, weekly en monthly. Daarmee is de standaard cron dubbel zo duur geworden. Ik heb run-parts weer in mijn machines zitten, er is werkelijk geen enkele reden te bedenken waarom ik elk kwartier de cron.daily zou moeten raadplegen.
– Draai applicaties niet in een High-Availability mode tenzij daar ook echt een reden voor is. HA houdt de kernel actief doordat deze in de gaten moet houden of de remote node (nog steeds) actief is. Sommige databases hebben dit standaard aan staan, ook zonder HA configuratie.
– Evalueer je applicatie. Zeker grote applicaties hebben standaard van allerlei processen actief die niets toevoegen aan de functionaliteit. Bijvoorbeeld Oracle heeft standaard een aantal processen die een database onnodig bezig houden.
– Draai geen Java applicaties. Java doet zijn housekeeping in idle time. Waardoor een idle server dus veel minder vaak ook echt idle is. Java is met name een nachtmerrie in gevirtualiseerde omgevingen omdat dit betekent dat resource sharing veel moeilijker wordt als (alle) servers actief blijven.
Mooie reactie Berry alleen wil ik graag een nuancering maken over de specialisten want hoewel ik het eens ben met de onderstaande opmerking zet ik zogenaamde even tussen haakjes omdat we kennis van de fysieke infrastructuur geabstraheerd hebben middels virtualisatie:
“Zolang (zogenaamde) specialisten en/of ontwikkelaars zich niets aantrekken van CPU verbruik van OS en/of applicaties is daar nog een wereld te winnen.”
Serverless cowboys trekken zich alleen iets aan van resource belastingen als dit tot knelpunten leidt en dit hebben we met virtualisatie opgelost zodat een oneindige schaalbaarheid niet noodzaakt tot enige efficiëntie in de code. Want de verborgen kosten in een transactionele wereld zitten allang niet meer in het stroomverbruik van de CPU maar in de I/O.
inderdaad mooie reactie Berry,
@oudlid, als je serverless codeert is het de bedoeling dat je je niets aantrekt van servers. Je wordt gefactureerd voor het gebruik van je code en de resources die het daarbij nodig heeft. Niet verborgen dus. dwz servers wel maar verbruik niet. Zowel klant als cloudleverancier heeft daarbij profijt van efficient verbruik van resources, of dat nou cpu of i/o is.
Oneindige schaalbaarheid is een illusie. Schaalbaarheid staat of valt bij de mogelijkheid om een systeem uit te breiden. Dat geldt voor alle servers, ook virtuele. Al is een virtuele omgeving, zeker in een cluster, wel makkelijker te schalen. Het ligt er alleen maar aan hoeveel geld je daarvoor kunt of wilt uitgeven. Inderdaad gaat het dan om meer dan alleen CPU, ook IO en geheugen zijn een factor. Maar ook IO kost geld (lees stroomverbruik), zelfs nog veel meer dan een paar extra CPU cycles.
Ook serverless is onzin, code moet nog altijd op een server draaien. Dat je als eindgebruiker dan niet weet waar het draait wil niet zeggen dat er geen server achter zit. Als klant hoef je dan misschien niet meer te betalen voor een fysieke server, uiteindelijk moet alle CPU- (of IO- of geheugen-) verbruik in het datacenter nog steeds betaald worden. Dus als je meer overhead hebt worden de CPU kosten gewoon hoger.
Met name de aanbeveling die in het artikel wordt gedaan, balanced mode, is leuk, maar dan moet de CPU wel in idle mode gaan. En zolang dat niet het geval is (minder dan 10% C1-state) levert dat niet zoveel op.
In mijn omgevingen heb ik slechts 25% van de servers 100% actief (vergelijkbaar met C0 en C1 state). De rest is slechts af en toe actief, alleen als het ook echt nodig is. Deze zijn tot 80% van de tijd dormant (vergelijkbaar met C5-state). Zeker in virtuele omgevingen is het van belang om er voor te zorgen dat machines zo min mogelijk actief zijn, waardoor er meer resources overblijven voor echt productionele load. Toegegeven, het kost wat moeite en af en toe een knokkerij met de leverancier (Suse), maar dit maakt de omgeving wel erg efficiënt.
“Als klant hoef je dan misschien niet meer te betalen voor een fysieke server, uiteindelijk moet alle CPU- (of IO- of geheugen-) verbruik in het datacenter nog steeds betaald worden. Dus als je meer overhead hebt worden de CPU kosten gewoon hoger.”
precies en die rekening krijgt de cloud klant dus ook gepresenteerd (gefactureerd worden is zegmaar dat je het moet betalen 😉 en als het elders goedkoper kan om zelfde code op zelfde schaal te laten draaien dan gaat die daarheen. Zowel klant als leverancier hebben daarom profijt van een kostefficiente infrastructuur.
De I/O lijkt me bepalend als we ervan uitgaan dat de plaatsing van de workload begint bij de mobiliteit van de data want het abstraheren van de workload met de mogelijkheden van virtualisatie biedt – zoals Dino opmerkt – de mogelijkheid om de verwerking daar te laten doen waar deze het efficiënst is. En hierin hebben we ondertussen meer keuzen dan een CPU in het datacenter want ik ben het helemaal met Berry eens dat de software zelf veel meer kan doen.