Groene software; door beïnvloeden van gedrag

Kijkend naar energie verbruik zien we dat elke Watt die bespaard word bij de bron uiteindelijk optelt tot een veelvoud daar van in de gehele energie keten van het datacenter. Emerson noemt dat het Cascade Effect.

Nu we zien dat de PUE langzaam richting de (theoretische) 1 zakt, word het zaak om te kijken welke winsten er nog meer te behalen zijn in het datacenter. Op facilitair vlak gaat daar bij de focus naar bijvoorbeeld WUE. Op het vlak van IT was men al bezig efficiënter om te gaan met de bronnen door de inzet van bijvoorbeeld virtualisatie en deduplicatie. 

Dit alles speelt zich echter af op de IT infrastructuur laag. Wat zou er dus nog te behalen zijn bij de ‘echte’ bron in de ICT; software & applicatie ? Door hier te bezuinigen zouden we volgens het cascade effect een veelvoud moeten kunnen besparen.

Begin 2010 haalde ik al aan dat er diverse leveranciers, waar onder Microsoft, Intel en HP, bezig waren de mogelijkheden te verkennen door applicatie ontwikkelaars inzicht te geven in energie verbruik van hun systemen. Dit door middel van SDK’s.

In de afgelopen jaren, waar in ik verantwoordelijk was voor diverse omgevingen binnen commerciële en overheidsbedrijven, heb ik de kans gehad om te kunnen experimenteren met de gedachtes rond beïnvloeden van IT gebruik, door met name ICT-ers zelf. Dit door middel van transparantie in gebruik en verbruik van ICT en het ontwikkelen van kostenmodellen hier op.

Het recent opgerichte Knowledge Network Green Software is ook bezig met dit soort ontwikkeling. In aanloop naar een bijeenkomst hier over op 8 mei 2012 aanstaande, vast een samenvatting van mijn ervaringen rond de ontwikkeling van groene software door het beïnvloeden van verbruiksgedrag. 

Gedachte

Door ontwikkelaars inzicht te geven in verbruik, kun je zorgen dat ze efficiënt omspringen met hun resources. Dit is een normale manier van benaderen als het gaat om IT resources zoals CPU, RAM en verbruik van Disk I/O’s. De software ontwikkelaar controleert de performance van het systeem (eventueel met een software tester) zodat zijn eind product op een normale manier functioneert.

De opkomst van kosten modellen is ook een trend in ICT. Zeker de introductie van virtualisatie heeft dit bevorderd. Aan de ene kant was er de wens vanuit de business om meer naar een pay-per-use model te gaan en andere andere kant was er soms de wens vanuit de IT afdeling om virtualisatie aan banden te leggen. De zo genaamde VM Sprawl is een bekende term voor ICT-ers, waarbij het gemak en de lage kosten voor een virtuele server (VM) leiden tot honderden virtuele servers waar niemand meer van wat van wie ze zijn en waarom ze er zijn. Om dit gedrag aan banden te leggen werden de kosten van VM’s in beeld gebracht en (automatisch) door belast.

Wat nu als we het performance inzicht voor de ontwikkelaar uitbreiden met inzicht in stroom verbruik en deze voorzien van een kosten prikkel door kWh te verrekenen?

Hier mee zou hetzelfde gedrag gestimuleerd kunnen worden als die bij de introductie van slimme energie meters in de thuis omgeving; gedrag sturen door inzicht te geven. Het werkt voor de Eneco Toon en de Nuon E-manager…

OTAP

De experimenten werden uitgevoerd in een zo geheten OTAP omgeving (of DTAP in het Engels). Dit is een belangrijke basis aangezien een dergelijke omgeving zorgt voor gecontroleerde uitrol van software en een consistente omgeving. Dit betekend dat de omgeving waar in ontwikkeld, getest en geaccepteerd wordt gelijk is aan de productie omgeving.

In de OTA omgeving word de software ontwikkelaar of database query schrijver voorzien van enkele standaard metrieke voor zijn software ontwikkelaar; CPU , RAM en disk I/O gebruik.

Deze werd aangevuld met kWh gegevens van de gebruikte systemen. Al deze gegevens waren (near-)realtime beschikbaar. Zo was het effect van wijzigen van enkele regels code of een query op een database direct terug te zien.

Om de juiste prikkel te creëren werden alle projecten die de OTA omgeving gebruikte belast voor het gebruik van hun resources. Dit op basis van een vast component rond afschrijving van de gebruikte hardware en het beheer daar van. Het flexibele component was het kWh verbruik. Het loont dus voor de project leider om systemen s ’nachts uit te laten schakelen en projectleden te stimuleren energie efficiënte code te schrijven.

Na de normale OTA procedure word de software in productie genomen. Tijdens de experimenten word in productie nogmaals gemeten. Dit om te controleren of aangepaste versies van de software (releases) werkelijk efficiënter zijn geworden in de productie situatie.

 

Technische setup

Om dit alles technisch te kunnen laten werken is wel een omgeving nodig waar in de feedback bijna realtime aan de ontwikkelaar gegeven kan worden.

Tijdens de diverse experimenten werd daar voor het volgende gebruikt:

• HP c-class blades, IPMI, OA, ILO – De HP ILO en OA (voor blades) geeft realtime inzicht in energie verbruik. Deze gegevens zijn o.a. via scripts (SSH) op te vragen. Voor andere systemen kan men terug vallen op IPMI. Veel IPMI implementaties geven de mogelijkheid om energie verbruik te zien. Er zijn diverse (opensource) tools beschikbaar om IPMI gegevens op te vragen en te verwerken.
• Windows, Linux – Als besturingssysteem (OS). Deze OS’en kunnen optioneel gebruik maken van Microsoft’s Joulemeter of Intel’s Energy Checker SDK.
• Oracle DB , Java –
  Als database en default programmeer taal.
• HP OpenView, HP Insight Control – Voor collectie, verwerking en dashboarding van de gegevens. Uiteraard kan hier voor ook opensource producten zoals Cacti gebruikt worden.
• VMware vCenter – Voor inzicht in virtuele systemen.
• Visual Studio performance testing, HP LoadRunner (Mercury) – Deze ontwikkel tools bieden ook veel mogelijkheden om realtime gegevens rond performance en gebruik uit systemen te halen.

Aandachtspunten uit deze experimenten

Bovenstaande setups werkte uitstekend. Zonder veel moeite kon in de meeste gevallen 20% op de energie worden bespaard. Dit door de juiste query’s en code te schrijven. Ook werden de software ontwikkelaars scherper op het schrijven van code zonder al te veel overhead.

De experimenten kende ook de nodige (onopgeloste) uitdagingen:

– Virtualisatie; het meten van energie consumptie met IPMI op hardware niveau is goed te doen. Echter op VM niveau word het een stuk lastiger. VMware heeft al wat werk op dit vlak gedaan met hun Host Power Management in vSphere 5. Zie: http://www.vmware.com/files/pdf/hpm-perf-vsphere5.pdf. Dit is een goede eerste stap, maar verdient nog nadere uitwerking. Af en toe week het totaal energie verbruik op hardware niveau af van het totaal verbruik van de VM’s of werden er cijfers gerapporteerd die niet realistisch aan voelde. Microsoft is ook aardig op weg met hun Joulemeter. De whitepapers van dit Microsoft team zijn echt een must-read voor energie verbruik&virtualisatie. Het is echter onbekend wat de integratie is met Hyper-V. Energie meting opties met KVM of Xen zijn niet gevonden ten tijden van de testen.

– Slechte interne sensoren; in navolging van de afwijkende getallen in de virtualisatie omgeving rond energie verbruik zijn er controles gedaan met externe, geijkte, energie meters. Hierbij bleek er soms 40% verschil te zitten tussen de door HP OA/ILO gerapporteerde energie afname op hardware niveau en de externe meter. Al met al werd geconcludeerd dat in sommige hardware implementaties kwalitatief slechte sensoren gebruikt worden.

– OTAP gedachte; bovenstaande experimenten werken alleen als alle stappen uit het OTAP proces voorzien zijn van dezelfde of nagenoeg zelfde omgevingen. Dit betekend dat men niet alleen software op  release matige manier moet uitrollen, maar ook zo met infrastructuur moet omgaan. Hierbij waren tijdens de testen bijvoorbeeld verschillen te zien in energie efficiënte query’s die wel goed werkte in OTA maar in productie niet. Daarbij bleek productie in 1 geval voorzien te zijn van een Oracle database patch die niet in OTA aanwezig was. Deze had een 60% stijging in energie tot gevolg. In een ander geval waren het enkele ontbrekende Microsoft Windows patches.

– Keten denken & architectuur; al snel bleek dat energie verbruik en efficiëntie ook mee genomen moet worden in de totale architectuur van een applicatie en zijn infrastructuur. Juist bij de applicaties die meerdere systemen gebruiken om hun functionaliteit te kunnen leveren, zijn grote besparingen te halen. Een 3 lagen architectuur is daarbij niet vreemd tegenwoordig; database – applicatie – webserver. De focus tijdens de ontwikkeling dient dus breder te zijn dan enkel die ene query op de database. Hierbij kunnen integratie en test specialisten op infrastructuur en software niveau een rol spelen.

– Keuze van hardware, software; de testen en experimenten zijn uitgevoerd met componenten die op dit moment vast lagen in de architectuur en standaarden. Er is niet gekeken welke effecten de selectie van hardware, besturingssysteem, middelware, database, programmeertaal of programma framework heeft op de energie afname. Wel kwam de keuze voor hardware tot stand door SPECpower als selectie onderdeel te gebruiken.

– Open en integratie; integratie tussen de diverse IT lagen was de sleutel om dit geheel inzichtelijk te krijgen. De schakel die echter miste was de integratie met het fysieke datacenter. Zo levert de PDU en andere elementen uit de energie keten ook kWh gegevens. Deze waren lastig te integreren, zeker als het gaat om protocollen als Modbus.

Integratie en keten denken

Dit laatste punt word ook in de DatacenterPulse Top10 (PDF) voor 2012 aangehaald:

10. CONVERGED INFR. INTELLIGENCE • UPDATE: The Data Center Infrastructure is becoming a complex machine requiring connection up the stack • Treat the DC infrastructure as an IT system • Converge in the infrastructure instrumentation and control systems • Connect it into the IT systems for ultimate control• Standardize connections and protocols to connect components • What’s measured and controlled will be addressed and tuned

Daarbij is de laatste de ‘oneliner’ waar het allemaal om draait: “What’s measured and controlled will be addressed and tuned”

Ondanks bovenstaande uitdagingen zullen we zien dat de komende jaren er steeds efficiëntere software zal ontstaan. Dit zal misschien niet direct gedreven worden vanuit de enkele centen die bespaard worden op de kWh maar meer vanuit het pay-per-use kosten model waar Cloud computing ons mee confronteert. De uitrol van inefficiënte software code of frameworks zal direct een hogere rekening van Amazon (AWS) opleveren. En niets werkt zo stimulerend als dat…