Elastic Computing in Windows Azure

Afgelopen donderdag was ik op kantoor bij besteproduct te Arnhem om te werken aan het gedistribueerde cache systeem van Windows Azure. We waren net live gegaan met de frontend van besteproduct, die nu ook in Windows Azure draait, maar het handmatig cachen verliep niet helemaal volgens verwachting. Tijdens mijn onderzoek viel het mij ineens op dat er iets gewijzigd was bij de Cloud Services. Het menu-item "SCALE" had het achtervoegsel "preview" gekregen. Vreemd want dat scale zat er al lang in. Daar kon je instellen hoeveel instanties van jouw website er in de lucht moesten zijn. Nadere inspectie leverde een nieuwe functionaliteit op: autoscale (afbeelding 1)

Afbeelding 1. Nieuw bij Cloud Services: De autoscale optie.

Het zal toch niet waar zijn?!?! Windows Azure is nu uitgerust met een heuse autoscaler, waarover ik een tijdje terug in een blog berichtte. Toen vermeldde ik ook al dat er commerciële autoscalers in omloop waren. Die zullen deze recente ontwikkeling niet echt op prijs stellen. Persoonlijk vind ik deze functionaliteit een logisch gevolg en verbaas mij erover dat dit er al niet veel eerder in zat.

Nog even een korte toelichting op de meerwaarde van deze functionaliteit (meer details in mijn blog Elastic Computing). De toegevoegde waarde van Windows Azure zit hem in het gegeven dat je moeiteloos meer (virtuele) servers kunt inschakelen wanneer dat nodig is en ze net zo eenvoudig weer kunt verwijderen. Met eigen servers is dat, vanwege contractuele afspraken, niet zo eenvoudig. Je kunt machines bijhuren/kopen, maar je komt er niet zo gemakkelijk meer vanaf. In Windows Azure kun je op ieder tijdstip machines toevoegen of verwijderen. En dat in een fractie van een paar minuten. Met elastic computing kun je dit op- of afschalen zelfs automatiseren op basis van het resourcegebruik, zoals processorbelasting en geheugengebruik. Dit automatiseren kun je zelf doen of je koopt een programmaatje dat dat doet. Nu is het dus onderdeel van Windows Azure (zij het een preview)

In afbeelding 1 zie je dat autscale standaard uit staat en dat je de keuze hebt uit schalen op basis van processorgebruik (CPU) of op basis van een wachtrij (QUEUE). Wanneer we CPU selecteren, krijgen we ineens een heleboel opties te zien (afbeelding 2)

Afbeelding 2. De extra opties wanneer we schaling op basis van CPU kiezen.

Allereerst kunnen we de "Instance Range" instellen. Hier bepalen we hoeveel instanties (virtuele servers) er minimaal moeten en maximaal mogen draaien. Vervolgens stellen we de "Target CPU"  in. Hier geven we het gebied op waarbinnen het gemiddeld processorgebruik moet liggen. Op basis van deze waarden zal Windows Azure gaan schalen. Wanneer de waarde beneden de onderwaarde komt, zal er afgeschaald worden en wanneer de waarde hoger dan de bovenwaarde ligt, zal er een opschaling plaatsvinden. Vervolgens kun je aangeven met hoeveel instanties er telkens opgeschaald (Scale up by) wordt. Omdat schalen tijd kost, kun je ook aangeven na hoeveel minuten er opnieuw geschaald mag worden. Hetzelfde kun je ook instellen voor het afschalen (Scale down by). Vergeet niet op de listig verborgen "Save" knop onderin beeld te drukken.
De eerste test was ietswat merkwaardig. Initieel begonnen we met twee instanties en toen we de autoscale activeerde, zaten we op nog maar één instantie, merkwaardig als de minimale hoeveelheid instanties op twee is afgeregeld. Twintig minuten later stond hij gelukkig weer op twee. Geen reden tot paniek dus. 

De scale optie "QUEUE" zal schaling realiseren op basis van het aantal queueberichten dat een instantie kan afhandelen. Wanneer we "QUEUE" selecteren, krijgen we het venster uit afbeelding 3

Afbeelding 3. De schaalopties wanneer we schaling op basis van queue selecteren.

Hier kunnen we wederom aangeven hoeveel instanties er minimaal en maximaal in de lucht mogen zijn. Vervolgens moeten we aangeven welke queue bekeken moet worden. Daarvoor selecteren we eerst een storage account, waarin de queue gedefinieerd is, en vervolgens de queue zelf. Target per machine is een belangrijke. Hier geef je op hoeveel queueberichten een machine maximaal kan afhandelen. De berekening is eenvoudiger dan je in eerste instantie zou vermoeden. Windows Azure bekijkt hoeveel berichten er in de queue staan en deelt deze door het aantal instanties dat momenteel draait. Is de uitkomst groter dan de ingestelde target-per-machinewaarde, dan zal er een opschaling plaats vinden. Wanneer de uikomst kleiner is, vindt er een afschaling plaats. Wederom kun je aangeven met hoeveel instanties er op- of afgeschaald wordt en na hoeveel minuten.

De autoscaler is een zeer welkome aanwinst in de cloudservices. De vraag is natuurlijk hoe lang deze optie gratis blijft. Persoonlijk zou ik ook op geheugengebruik willen schalen, maar op basis van CPU lijkt mij een goede start. Bij schaling op basis van de queue vind ik het jammer dat je geen queue uit de service bus kunt opgeven. Wellicht komt dat later nog. Het is tenslotte nog een preview. Het begin is er in ieder geval.