Inleiding
In mijn vorige artikel over Windows Azure en schaling heb ik geprobeerd aan te geven welke schaalbaarheidsmodellen er op het Windows Azure platform beschikbaar zijn. Laat ik het nog eens samenvatten.
We kennen twee soorten schaling:
· Scale up, oftewel verticale schaling:
het zwaarder maken van de machine waarop de applicatie draait. Bijvoorbeeld door meer memory, harddisk of processor power toe te voegen.
· Scale out, oftewel horizontale schaling:
het verhogen van het aantal instanties waarop de applicatie draait. De server dimensies blijven hetzelfde, maar we zetten er meer naast elkaar.
De eerste methode van schaling zijn we bij een on premise situatie het meest gewend om te doen. Deze upgrade betekent meestal geen aanpassingen aan de applicatie en de overige netwerk componenten zoals loadbalancers. Op Windows Azure kunnen we dit ook, we kiezen dan voor een andere grootte van de VM. Deze kun je instellen in de configuratie van de Windows Azure role en dat is gedefinieerd in de ServiceDefinition. Dit kan zeker nuttig zijn en soms de enige oplossing.
Scale up met de Windows Azure sizes
De tweede methode is minder gebruikelijk in een on premise situatie, maar wel een van de krachtige punten van Windows Azure. Op Windows Azure kun je heel gemakkelijk het aantal instanties van een services/role verhogen. Dit kan zonder tussen komst van wie dan ook. Na de verhoging bevat de role ook automatisch de applicatie. Maar ook is automatisch de server opgenomen in de loadbalancer. In een on premises situatie vergt dit meestal meer tijd en handmatige acties. Soms moet er hardware aangeschaft worden en ligt het aanpassen van de loadbalancer bij een andere afdeling. Door een Scale out te doen ben je voorbereid op een Fail over scenario.
Scale out
Op het Windows Azure platform gaan beide schalingsmogelijkheden hand in hand. Om te kunnen voldoen aan de SLA (Service Level Agreement) van Microsoft op het Windows Azure platform, moet je minimaal 2 instanties van een service/role draaien. Dit is nodig om de beschikbaarheid van je service of website te garanderen. Het Windows Azure platform is in staat om te reageren op hardware falen en dan automatisch de gedupeerde instanties te verplaatsen of op een andere locatie binnen het data center op te starten. Als je maar 1 instantie van een service hebt draaien, dan zou dat uitval van je dienstverlening kunnen betekenen.
Zoals ik in mijn vorige artikel ook al beschreef, kun je natuurlijk ook nog meerdere instanties van een service/website draaien binnen een VM/Server. Hiermee kun je de kracht van een VM/Server volledig benutten.
Wat ik hiervoor besproken heb, gaat in principe steeds uit van de gelijke rollen. Op het Windows Azure platform onderkennen we op dit moment 3 rollen:
1. Web role (Front End / Website)
2. Worker Role (Back End / Windows Service)
De laatste laat ik even buiten beschouwing, aangezien dit een verhaal op zichzelf is. Voor de Web en Worker role geldt dat het eigenlijk VM’s zijn. VM’s in door jou gespecificeerde grootte. Het verschil is dat bij een Web role IIS standaard gestart is en bij een Worker rol niet.
Samenvoegen Rollen?
Maar als er dan zo weinig verschil tussen beide is, dan kan er dan ook gecombineerd worden? Jazeker en dat kan zelfs kosten efficiënt zijn. Op deze manier nut je de volledige capaciteit van de VM/Server uit, zonder dat je extra instanties nodig hebt.
Stel je het volgende scenario voor. Je hebt een WebRole met 2 Websites en je hebt een WorkerRole. Maar nu blijkt dat de WorkerRole met een minder grote VM had kunnen draaien. Dan kun je uiteraard een kleinere VM kiezen, maar als je al een XS gekozen hebt?
Sterker nog, de WebRole met zijn 2 WebSites gebruikt ook niet de volle kracht van de VM.
Niet volledig benutten van de capaciteit
Dan lijkt het interessant om beide rollen samen te voegen.
Gecombineerde rollen in een role
Dat samenvoegen gaat simpel, door de WorkerRole logica te verplaatsen naar de WebRole. Dat kan door de methode Run() toe te voegen aan de WebRole.cs.
Let op: je zult eventuele specifieke settings uit app.config of Role configuration wel moeten verplaatsen van WorkerRole naar de WebRole web.config of Role configuration.
public override void Run(){
Trace.WriteLine("WorkerRole entry point called", "Information");
while (true)
{
<own logic>
}
base.Run();
}
Hier een meer uitgewerkt voorbeeld.
WebRole.cs file
In de Local Development Emulator zie je dan ook daadwerkelijk de Traces langs komen. Terwijl de website gewoon in de browser geopend is en volledig functioneel. Uiteraard merk je als gebruiker van de Website niets dat er op de achtergrond nog een ander proces hard aan het werk is. Als je dat wel merkt, dan hebben we het daar zo over.
Het werkt
De andere kant om kan natuurlijk ook. Je hebt een WorkerRole en wilt daar een WebRole bijzetten. Je zult dan wel logica voor het starten van de website moeten inbouwen. De eerste kant uit is het eenvoudigst.
Rollen loskoppelen?
Maar stel je hebt een WebRole met 3 websites. Deze drie websites zijn samen gevoegd in een VM, omdat ze gezamenlijk de power van de VM consumeren (we laten 2 instanties ivm de SLA even buiten beschouwing).
Drie website in een Role
Maar nu blijkt Web3 meer power nodig te hebben en daardoor zit hij de Websites Web1 en Web2 in de weg. Dat is voor je dienstverlening niet handig en zou een oplossing kunnen zijn om Web3 in een eigen VM te laten draaien. Daarvoor pas je je solution aan en krijg je 2 WebRoles.
Opgesplitste rollen
Bij dit alles geldt natuurlijk nog steeds, als je je solution netjes ingericht hebt met verschillende classes, projecten etc, dan wordt het al gauw stukken makkelijker om deze exercitie uit te voeren.
Conclusie
De schalingsmogelijkheden op het Windows Azure platform zijn bijna onbeperkt. Je kunt een scale up of scale out uitvoeren zonder al te veel problemen. Je bent niet gebonden aan de specifieke rollen, je kunt ze prima combineren. De flexibiliteit van de Cloud kun je in verschillende vormen gebruiken.
[1] Let op, deze VM moet wel aan bepaalde voorwaarden voldoen etc.