KENNISMAKING MET WINDOWS AZURE

KENNISMAKING MET WINDOWS AZURE DAVID CHAPPELL OKTOBER 2010 GESPONSORD DOOR MICROSOFT CORPORATION

INHOUD Een overzicht van Windows Azure... 2 Rekenen... 4 Opslag... 6 Fabric controller... 7 CDN (Content Delivery Network)... 9 Connect... 10 Werken met Windows Azure: scenario's... 12 Een schaalbare webapplicatie maken... 12 Een applicatie voor parallelle verwerking maken... 13 Een schaalbare webapplicatie met achtergrondverwerking maken... 14 Een webapplicatie met relationele gegevens maken... 15 Een lokale webapplicatie met relationele gegevens migreren... 16 Cloud-opslag gebruiken vanuit een applicatie in het eigen datacenter of een gehoste applicatie... 17 Windows Azure begrijpen: een nadere beschouwing... 18 Windows Azure-applicaties maken... 18 De rekenservice nader bekeken... 19 De opslagservice nader bekeken... 20 Blobs... 20 Tabellen... 21 Wachtrijen... 23 De fabric controller nader bekeken... 25 Nieuwe ontwikkelingen... 26 Conclusies... 27 Meer informatie... 27 Over de auteur... 27 1

EEN OVERZICHT VAN WINDOWS AZURE Cloud computing is gearriveerd. Applicaties uitvoeren en gegevens opslaan in een datacenter dat via internet toegankelijk is, biedt een groot aantal voordelen. Maar waar applicaties ook worden uitgevoerd, er is altijd een platform voor nodig. Voor applicaties die in het datacenter van de organisatie zelf worden uitgevoerd, bestaat dit platform doorgaans uit een besturingssysteem, een manier om gegevens op te slaan en eventueel enkele andere componenten. Voor applicaties die in de cloud worden uitgevoerd, is een soortgelijke basis nodig. Het doel van Windows Azure is deze basis te leveren. Windows Azure maakt deel uit van een groter Windows Azure-platform en maakt het mogelijk dat in de cloud applicaties kunnen worden uitgevoerd en gegevens kunnen worden opgeslagen. In figuur 1 ziet u hoe dat in zijn werk gaat. Bedrijven Gebruikers Internet Applicaties Gegevens Windows Azure Microsoft-datacenters Figuur 1: Windows Azure-applicaties worden uitgevoerd in Microsoft-datacenters en zijn toegankelijk via internet. Windows Azure is een service. Klanten ontvangen geen software die zij op hun eigen computer moeten installeren, maar gebruiken Windows Azure nu om applicaties uit te voeren en gegevens op te slaan op computers van Microsoft die via internet toegankelijk zijn. Deze applicaties kunnen services bieden voor bedrijven, consumenten of beide. Hieronder volgen enkele voorbeelden van soorten applicaties die op Windows Azure kunnen worden gebouwd: Een onafhankelijke softwareleverancier ontwikkelt een applicatie die gericht is op zakelijke gebruikers. Deze benadering wordt vaak met de term SaaS (Software as a Service) aangeduid.windows Azure is 2

onder meer ontwikkeld om de SaaS-applicaties van Microsoft zelf te ondersteunen, dus ISV's kunnen Azure gebruiken als basis voor een breed scala aan zakelijke cloud-applicaties. Een softwareleverancier ontwikkelt een SaaS-applicatie die gericht is op consumenten in plaats van bedrijven. Windows Azure ondersteunt zeer schaalbare software. Dat betekent dat Windows Azure uitermate geschikt is als platform voor een bedrijf dat een grote consumentenmarkt wil bedienen. Bedrijven kunnen Windows Azure gebruiken om applicaties te ontwikkelen en uit te voeren die door hun eigen werknemers worden gebruikt. Hoewel voor deze situatie niet de enorme schaalbaarheid van een consumentgerichte applicatie nodig is, is Windows Azure ook voor dit soort situaties zeer geschikt omdat de oplossing zeer betrouwbaar en gemakkelijk te beheren is. Windows Azure bestaat uit vijf componenten die het mogelijk maken om applicaties uit te voeren en gegevens op te slaan in de cloud, zoals u kunt zien in figuur 2. Applicaties en gegevens CDN Connect Rekenen Opslag Fabric controller Figuur 2: Windows Azure bestaat uit vijf hoofdcomponenten: Rekenen, Opslag, Fabric Controller, CDN en Connect. Deze componenten zijn: Windows Azure Rekenen: voert applicaties uit in de cloud. Deze applicaties doen sterk denken aan een Windows Server-omgeving, maar het Windows Azure-programmeermodel is niet volledig identiek aan het Windows Server-model in een eigen datacenter. Opslag: verzorgt binaire en gestructureerde gegevensopslag in de cloud. Fabric controller: implementeert, beheert en houdt toezicht op applicaties. De fabric controller regelt tevens de updates van de systeemsoftware voor het gehele platform. CDN (Content Delivery Network): versnelt de algehele toegang tot binaire gegevens in de Windows Azure-opslag door wereldwijd kopieën van deze gegevens in cache te bewaren. Connect: met Connect realiseert u verbindingen op IP-niveau tussen computers in uw eigen datacenter en Windows Azure-applicaties. In rest van deze sectie de worden deze technologieën nader toegelicht. 3

REKENEN Windows Azure-rekenen kan allerlei soorten applicaties uitvoeren. Waar u een applicatie ook voor gebruikt, er moeten altijd een of meer roles voor worden geïmplementeerd. Windows Azure voert vervolgens meerdere instances van iedere rol uit en maakt gebruik van de geïntegreerde load balancing om de aanvragen over de verschillende instances te verdelen. In figuur 3 ziet u hoe dat werkt. Web role instances Worker role instances VM role instances IIS Load balancer HTTP/HTTPS, TCP Virtuele computers Applicaties en gegevens CDN Connect Rekenen Opslag Fabric controller Figuur 3: een actieve Windows Azure-applicatie bestaat uit een combinatie van web role instances, worker role instances en VM role instances. In de huidige versie van Windows Azure kunnen ontwikkelaars kiezen uit drie soorten rollen: Web roles: voornamelijk bedoeld om het maken van webapplicaties te vereenvoudigen. Iedere web role instance bevat een vooraf geconfigureerde versie van Internet Information Services (IIS) 7, waardoor het maken van applicaties met ASP.NET, Windows Communication Foundation (WCF) of een andere webtechnologie heel eenvoudig is. Ontwikkelaars kunnen echter ook hun eigen programmeertaal gebruiken. Het gebruik van.net Framework is niet vereist. Dat betekent dat ook niet-microsoft technologieën, zoals PHP en Java, kunnen worden gebruikt. Worker roles: deze voeren verschillende soorten Windows-code uit. Het grootste verschil tussen een web role en een worker role is het feit dat worker roles geen geconfigureerde IIS bevatten. De code die ze uitvoeren wordt daarom niet gehost door IIS. Een worker role kan bijvoorbeeld een simulatie uitvoeren of video's verwerken; nagenoeg alles in feite. Een applicatie maakt doorgaans gebruik van een web role voor communicatie met gebruikers geeft vervolgens de taken voor verwerking door aan een worker role. En nogmaals, een ontwikkelaar kan naar wens.net Framework of andere software 4

gebruiken die op Windows wordt uitgevoerd, inclusief technologieën die niet afkomstig zijn van Microsoft. VM roles: deze voeren de door de gebruiker aangeleverde Windows Server 2008 R2-images uit. Een VM role kan bijvoorbeeld handig zijn bij het verplaatsen van een Windows Server-applicatie in het eigen datacenter naar Windows Azure. Als u een applicatie naar Windows Azure wilt verplaatsen, kunt u gebruikmaken van de Windows Azureportal. Tezamen met de applicatie worden de configuratiegegevens verzonden zodat het platform weet hoeveel instances er van iedere role moeten worden uitgevoerd. Vervolgens maakt de Windows Azurefabric controller een virtuele machine (VM) voor iedere instance, waarop de code voor de bijbehorende role wordt uitgevoerd. Zoals u ziet in figuur 3, kunnen de aanvragen van de gebruikers van de applicatie worden gegenereerd met protocollen als HTTP, HTTPS en TCP. Hoe deze aanvragen ook binnenkomen, door middel van load balancing worden ze over alle instances van een role verdeeld. Omdat het met de load balancer niet mogelijk is een affiniteit met een bepaalde role instance te maken, worden sticky sessies niet ondersteund en kan niet worden gegarandeerd dat meerdere aanvragen van dezelfde gebruiker naar dezelfde instance van een role worden verzonden. Dat betekent dat role instances in Windows Azure niet zelf hun status voor meerdere aanvragen kunnen bijhouden. In plaats daarvan moet een client-specifieke status naar Windows Azure-opslag worden geschreven en worden opgeslagen in SQL Azure (een ander onderdeel van het Windows Azure-platform) of extern worden bijgehouden. Een ontwikkelaar kan iedere combinatie van web role instances, worker role instances en VM role instances gebruiken bij het maken van een Windows Azure-applicatie. Als de workload van de applicatie toeneemt, kan de Windows Azure-portal worden gebruikt om meer instances voor iedere rol van de applicatie aan te vragen. Als de workload afneemt, kan het aantal instances dat wordt uitgevoerd, worden teruggebracht. Windows Azure beschikt daarnaast ook over een API waarmee al deze taken programmatisch kunnen worden uitgevoerd. Voor het wijzigen van het aantal instances dat wordt uitgevoerd is geen handmatige actie vereist, maar het platform schaalt applicaties niet automatisch op basis van hun workload. Bij het maken van Windows Azure-applicaties kan een ontwikkelaar dezelfde talen en tools gebruiken als voor iedere andere Windows-applicatie. Zo kunnen web roles bijvoorbeeld worden geschreven met ASP.NET of Visual Basic, maar ook WCF en C# kunnen worden gebruikt. Worker roles kunnen ook in deze.net-talen worden geschreven of de ontwikkelaar kan C++ zonder.net Framework of Java gebruiken. En hoewel Windows Azure is voorzien van add-ins voor Visual Studio, is het gebruik van deze ontwikkelomgeving niet verplicht. Als een ontwikkelaar bijvoorbeeld PHP gebruikt, kan hij een andere tool gebruiken voor het schrijven van applicaties. Voor monitoring en debugging van Windows Azure-applicaties kan ieder instance een logboek-api aanroepen die informatie wegschrijft naar een gemeenschappelijk logbestand voor de hele applicatie. Een ontwikkelaar kan het systeem ook zodanig configureren dat er prestatiecounters voor een applicatie worden verzameld, dat het CPU-gebruik wordt gemeten, dat eventuele crashdumps worden opgeslagen, enzovoort. Deze gegevens worden in de Windows Azure-opslag bewaard en een ontwikkelaar kan code schrijven om deze gegevens te onderzoeken. Als een worker role instance bijvoorbeeld drie keer binnen een uur vastloopt, kan via aangepaste code een e-mail naar de beheerder van de applicatie worden verzonden. 5

De mogelijkheid om code uit te voeren vormt een essentieel onderdeel van een cloud-platform, maar dat is nog niet genoeg. Applicaties hebben ook permanente opslag nodig. Dit is de taak Windows Azureopslagservice. Daarover leest u hieronder meer. OPSLAG Applicaties gebruiken gegevens op veel verschillende manieren. Daarom is de Windows Azureopslagservice voorzien van verschillende opties. In figuur 4 worden deze weergegeven. Blobs Tabellen Wachtrijen HTTP/HTTPS, OData Applicaties en gegevens CDN Connect Rekenen Opslag Fabric controller Figuur 4: blobs, tabellen en wachtrijen van de Windows Azure-opslagservice. De eenvoudigste manier om gegevens in de Windows Azure-opslag op te slaan is het gebruik van blobs. Een blob bevat binaire gegevens en de hiërarchie is eenvoudig, zoals blijkt uit figuur 4: iedere container kan een of meer blobs bevatten. Blobs kunnen maximaal 1 Terabyte groot zijn en bijbehorende metagegevens bevatten, zoals informatie over de locatie waar een JPEG-foto is gemaakt of wie de zanger is van een MP3-bestand. Blobs bieden tevens ondersteuning voor Windows Azure drives, waardoor een role instance in Windows Azure met permanente opslag kan communiceren alsof het een lokaal NTFSbestandssyteem betreft. Blobs zijn ideaal voor sommige situaties, maar voor andere te ongestructureerd. Als applicaties op een verfijndere manier met gegevens moeten werken, maakt Windows Azure-opslag gebruik van tabellen. Laat u niet misleiden door de naam: dit zijn geen relationele tabellen. De gegevens in iedere tabel zijn opgeslagen in een groep entiteiten die eigenschappen bevatten. Een applicatie kan gegevens in een tabel opvragen via het OData-protocol en niet via SQL. De reden hiervoor is dat op die manier horizontaal geschaalde opslag mogelijk is - schaling door de gegevens over meerdere computers te verdelen. Dat is veel effectiever dan een standaard relationele database. Sterker nog, één Windows Azure-tabel kan miljarden entiteiten bevatten met terabytes aan gegevens. 6

Blobs en tabellen zijn gericht op het opslaan en ophalen van gegevens. De derde optie in Windows Azureopslag, wachtrijen, heeft een totaal ander doel. Een primaire functie van wachtrijen is web role instances asynchroon te laten communiceren met worker role instances. Een gebruiker kan bijvoorbeeld een aanvraag indienen om een rekenintensieve taak uit te voeren via een webinterface die door een Windows Azure web role wordt geïmplementeerd. De web role instance die de aanvraag ontvangt, kan een bericht naar een wachtrij verzenden waarin de taak wordt beschreven. De worker role instance die deze wachtrij gebruikt, leest het bericht en voert de beschreven taak vervolgens uit. De resultaten kunnen via een andere wachtrij worden geretourneerd of op een andere manier worden afgehandeld. Ongeacht de manier waarop de gegevens zijn opgeslagen - in blobs, tabellen of in wachtrijen - worden alle gegevens die in Windows Azure-opslag worden bewaard driemaal gerepliceerd. Dankzij deze replicatie is fouttolerantie mogelijk. Het verliezen van een instance is immers niet noodlottig. Het systeem biedt echter sterke consistentie, waardoor een applicatie die gegevens leest die net zijn geschreven, gegarandeerd ontvangt wat is geschreven. Windows Azure maakt ook een back-up van alle gegevens en bewaart die in een ander datacenter in dezelfde regio. Als het datacenter met de gegevens niet beschikbaar is of als daar een calamiteit plaatsvindt, hebt u via deze back-up toegang toch tot de gegevens. Windows Azure-opslag is toegankelijk via een Windows Azure-applicatie, via een applicatie in het eigen datacenter of via een applicatie die bij een hoster of op een ander cloud-platform wordt uitgevoerd. In al deze gevallen maakt Windows Azure-opslag gebruik van de conventies van REST om de gegevens te identificeren en beschikbaar te maken, zoals u ziet in figuur 4. Blobs, tabellen en wachtrijen worden door middel van URI's van een naam voorzien en zijn toegankelijk via standaard HTTP-acties. Een.NET-client kan hiervoor gebruikmaken van een bibliotheek die door Windows Azure wordt geleverd, maar dat is geen vereiste. Een applicatie kan ook gebruikmaken van gewone HTTP-aanroepen. Het bouwen van Windows Azure-applicaties die gebruikmaken van blobs, tabellen en wachtrijen kan zeker zinvol zijn. Applicaties die gebruikmaken van relationele opslag kunnen in plaats daarvan SQL Azure gebruiken, dat ook deel uitmaakt van het Windows Azure-platform. Applicaties die worden uitgevoerd op Windows Azure (of op andere locaties) kunnen met deze technologie via SQL toegang te krijgen tot relationele opslag in de cloud. FABRIC CONTROLLER Alle Windows Azure-applicaties en alle gegevens in Windows Azure-opslag bevinden zich in een datacenter van Microsoft. Binnen het datacenter wordt de reeks computers die voor Windows Azure en de software op die computers is gereserveerd, beheerd door de fabric controller. In figuur 5 ziet u hoe dat werkt. 7

Role instances Fabric agent Opslag Fabric agent Fabric controller Applicaties en gegevens CDN Connect Rekenen Opslag Fabric controller Figuur 5: de fabric controller communiceert via de fabric agent met Windows Azure-applicaties. De fabric controller is zelf een gedistribueerde applicatie die op een groep computers wordt gerepliceerd. De fabric controller is eigenaar van alle bronnen in zijn omgeving: computers, switches, load balancers, enzovoort. Omdat de fabric controller met een fabric agent op elke computer kan communiceren, is iedere Windows Azure-applicatie in de fabric bij de fabric controller bekend. (De fabric controller ziet Windows Azure-opslag als een gewone applicatie, met als gevolg dat de details van gegevensbeheer en replicatie niet zichtbaar zijn voor de controller.) Omdat de fabric controller dit allemaal weet, kan deze een aantal nuttige dingen doen. De fabric controller houdt bijvoorbeeld toezicht op alle actieve applicaties, waardoor een actueel beeld ontstaat van alles wat er gebeurt. De fabric controller bepaalt ook waar nieuwe applicaties moeten worden gestart en kiest de fysieke servers om het hardwaregebruik te optimaliseren. Hiervoor maakt de fabric controller gebruik van de configuratiegegevens die bij iedere Windows Azure-applicatie worden geüpload. Dit bestand bevat een op XML gebaseerde beschrijving van wat een applicatie nodig heeft: het aantal benodigde web role instances, het aantal benodigde worker role instances, enzovoort. Op het moment dat de fabric controller een nieuwe applicatie implementeert, wordt dit configuratiebestand gebruikt om vast te stellen hoeveel VM's moeten worden gemaakt. Nadat deze VM's zijn gemaakt, worden ze door de fabric controller beheerd. Als voor een applicatie bijvoorbeeld vijf web role instances nodig zijn en er één uitvalt, start de fabric controller automatisch een nieuwe web role. Als de computer waarop de VM wordt uitgevoerd uitvalt, start de fabric controller een nieuw instance van de rol in een nieuwe VM op een andere machine en wordt de load balancer ingesteld voor deze nieuwe VM. Met Windows Azure kunnen ontwikkelaars kiezen uit vijf VM-grootten. De opties zijn: 8

Extra klein, met een processor met één kern van 1,0 GHz, 768MB geheugen en 20GB aan opslag. Klein, met een processor met één kern van 1,6 GHz, 1,75 GB geheugen en 225 GB aan opslag. Gemiddeld, met een processor met twee kernen van 1,6 GHz, 3,5 GB geheugen en 490 GB aan opslag. Groot, met een processor met vier kernen van 1,6 GHz, 7 GB geheugen en 1000 GB aan opslag. Extra groot, met een processor met acht kernen van 1,6 GHz, 14 GB geheugen en 2040 GB aan opslag. Een extra kleine instance deelt een processorkern met andere extra kleine instances. Bij alle andere grootten worden voor ieder instance één of meer processorkernen gereserveerd. Dat betekent dat de prestaties van een applicatie voorspelbaar zijn en dat er geen sprake is van een willekeurige limiet met betrekking tot hoe lang een instance kan worden uitgevoerd. Een web role instance kan bijvoorbeeld alle tijd gebruiken die nodig is om een aanvraag van een gebruiker te verwerken, terwijl een worker role instance misschien wel de waarde van pi tot een miljoen cijfers achter de komma gaat berekenen. Voor web roles en worker roles (maar niet voor VM roles) beheert de fabric controller tevens het besturingssysteem in iedere instance. Dit beheer omvat onder meer het verwerken van patches voor het besturingssysteem en het bijwerken van de systeemsoftware. Zo kunnen ontwikkelaars zich concentreren op het maken van applicaties en hoeven zij zich geen zorgen te maken over het beheer van het platform. Het is belangrijk dat u zich realiseert dat de fabric controller er altijd van uitgaat dat er minimaal twee instances van iedere role worden uitgevoerd. Hierdoor kan de fabric controller één instance afsluiten om de software bij te werken zonder dat dit ertoe leidt dat de gehele applicatie wordt afgesloten. Mede daardoor is het uitvoeren van één instance van een Windows Azure role doorgaans geen goed idee. CDN (CONTENT DELIVERY NETWORK) Een algemeen gebruik van blobs is het opslaan van informatie die toegankelijk moet zijn vanaf veel verschillende locaties. Denk bijvoorbeeld aan een applicatie die video's beschikbaar stelt voor Flash-, Silverlight- of HTML 5-clients over de hele wereld. Om in dergelijke situaties de prestaties te verbeteren, beschikt Windows Azure over een CDN (Content Delivery Network). Het CDN bewaart kopieën van een blob in datacenters dicht in de buurt van de clients die de blob gebruiken. In figuur 6 ziet u de weergave van dit principe. 9

Blobs Windows Azure Applicaties en gegevens CDN Connect Rekenen Opslag Fabric controller Figuur 6: het Windows Azure CDN plaatst kopieën van blobs over de hele wereld in de cache, zodat gebruikers sneller toegang hebben tot die gegevens. Neem deze afbeelding niet te letterlijk. Het Windows Azure CDN beschikt in werkelijkheid over veel meer cache-locaties wereldwijd dan hier wordt aangegeven, maar het concept klopt wel. De eerste keer dat een bepaalde blob door een gebruiker wordt opgevraagd, slaat het CDN een kopie van die blob op een locatie op die geografisch dicht bij de gebruiker ligt. De volgende keer dat de blob wordt opgevraagd, wordt de inhoud uit de cache gebruikt en niet de inhoud op de oorspronkelijke locatie. Stel dat Windows Azure wordt gebruikt voor het weergeven van video's van een sportevenement aan een publiek dat is verdeeld over meerdere landen of regio's. De eerste gebruiker die de video opent, profiteert niet van CDN omdat de blob nog niet in de cache in zijn regio staat. Alle overige gebruikers in dezelfde regio profiteren hier echter wel van, omdat het exemplaar uit de cache sneller kan worden geladen. CONNECT Het uitvoeren van applicaties in de Microsoft-cloud is zinvol. Maar de applicaties en gegevens die we in de organisatie zelf uitvoeren en gebruiken zullen niet zomaar verdwijnen. Daarom is een goede verbinding tussen de eigen datacenter-omgeving en Windows Azure zeer belangrijk. Windows Azure Connect helpt u hierbij. Door te zorgen voor connectiviteit op IP-niveau tussen een Windows Azure-applicatie en computers buiten de Microsoft-cloud, wordt het gebruik van deze combinatie eenvoudig. Dit idee wordt geïllustreerd in figuur 7. 10

Applicaties en gegevens Role instances Endpoint agent IPsec Windows-computer in het eigen datacenter Windows Azure Rekenen Applicaties en gegevens CDN Connect Rekenen Opslag Fabric controller Figuur 7: Windows Azure Connect maakt communicatie op IP-niveau mogelijk tussen Windowscomputers in het eigen datacenter en een Windows Azure-applicatie. Zoals u in de illustratie ziet, moet u voor het gebruik van Windows Azure Connect op iedere computer in het eigen datacenter een endpoint agent installeren die zorgt voor de verbinding met een Windows Azure-applicatie. (Omdat de technologie is gebouwd rondom IP v6, is de endpoint agent momenteel alleen beschikbaar voor Windows Server 2008, Windows Server 2008 R2, Windows Vista en Windows 7.) De Windows Azure-applicatie moet daarnaast ook zijn geconfigureerd voor gebruik met Windows Azure Connect. Als dat eenmaal is gebeurd, kan de agent IPsec gebruiken om te communiceren met een bepaalde rol in de applicatie. Houd er wel rekening mee dat dit geen volledige VPN (Virtual Private Network) is. Microsoft heeft plannen aangekondigd voor een volledige VPN, maar Windows Azure Connect is een eenvoudigere oplossing. Voor het instellen van Windows Azure Connect hoeft u bijvoorbeeld uw netwerkbeheerder niet in te schakelen. U hoeft alleen de endpoint agent op een lokale computer te installeren. Met deze benadering voorkomt u tevens de potentiële complexiteit van het configureren van IPsec. Dat wordt voor u door Windows Azure Connect gedaan. Als de technologie eenmaal is ingesteld, lijkt het alsof de rollen in een Windows Azure-applicatie op hetzelfde IP-netwerk worden uitgevoerd als de computers in het eigen datacenter. Dat maakt het volgende mogelijk: Een Windows Azure-applicatie heeft rechtstreeks toegang tot een database in het eigen datacenter. Stel dat een organisatie een bestaande Windows Server-applicatie die met ASP.NET is gebouwd, verplaatst naar een Windows Azure web role. Als de database waarvan deze applicatie gebruikmaakt niet kan worden mee verplaatst, kan een Windows Azure Connect-verbinding ervoor zorgen dat de 11

applicatie, die nu op Windows Azure wordt uitgevoerd, net als daarvoor toegang krijgt tot de database in het eigen datacenter. Daarvoor hoeft zelfs de connection string niet te worden aangepast. Een Windows Azure-applicatie kan via een domein aan de omgeving in het eigen datacenter worden gekoppeld. Hierdoor kunnen gebruikers op de eigen locatie gebruikmaken van eenmalige aanmelding (SSO) voor de cloud-applicatie. Bovendien kan de applicatie dan toegangsbeheer gebruikmaken van Active Directory-accounts en groepen. Het is belangrijk de cloud goed af te stemmen op de huidige omgeving in het eigen datacenter. Door rechtstreekse connectiviteit op IP-niveau te bieden, maakt Windows Azure Connect dit eenvoudiger voor Windows Azure-applicaties. WERKEN MET WINDOWS AZURE: SCENARIO'S Het is belangrijk dat u de verschillende onderdelen van Windows Azure begrijpt, maar dat is niet genoeg. De beste manier om kennis te maken met dit platform is het bekijken van enkele voorbeelden. In deze sectie worden daarom enkele scenario's besproken voor het gebruik van Windows Azure: het maken van een schaalbare webapplicatie, het maken van een applicatie voor parallelle verwerking, het maken van een webapplicatie met achtergrondverwerking, het maken van een webapplicatie met relationele gegevens, het migreren van een webapplicatie met relationele gegevens en het gebruik van cloud-opslag vanuit een applicatie in het eigen datacenter of een gehoste applicatie. EEN SCHAALBARE WEBAPPLICATIE MAKEN Stel dat een organisatie een webapplicatie wil maken die toegankelijk is via internet. Normaal gesproken zou die applicatie worden uitgevoerd in het datacenter van de organisatie of bij een hoster. In veel gevallen is een cloud-platform zoals Windows Azure echter een betere keuze. Als de applicatie bijvoorbeeld veel gelijktijdige gebruikers moet kunnen verwerken, is het verstandig deze op een platform te bouwen dat speciaal hiervoor is ontwikkeld. De geïntegreerde ondersteuning voor schaalbare applicaties en gegevens van Windows Azure zorgt ervoor dat een veel grotere workload kan worden verwerkt dan bij conventionele webtechnologieën. Of stel dat de workload van de applicatie sterk wisselt, met grote pieken in langere perioden met een lager gebruik. Dit is bijvoorbeeld het geval bij een website voor kaartverkoop of een videosite met nieuwsberichten, applicaties die vooral op een bepaald moment van de dag worden gebruikt, enzovoort. Als dit type applicatie in een conventioneel datacenter wordt uitgevoerd, moeten er altijd genoeg computers beschikbaar zijn voor de mogelijke pieken, ook al wordt een groot deel van het systeem meestal niet gebruikt. Als de applicatie daarentegen op Windows Azure is gebouwd, kan de organisatie die de applicatie uitvoert het aantal instances vergroten wanneer dat nodig is en vervolgens weer terugkeren naar het kleinere aantal. Omdat de kosten voor Windows Azure op gebruik zijn gebaseerd - u betaalt per uur voor ieder instance - is de kans groot dat dit goedkoper is dan het inzetten van een groot aantal computers die meestal worden gebruikt. Om een zeer schaalbare webapplicatie te maken op Windows Azure, kan een ontwikkelaar gebruik maken van web roles en tabellen. Figuur 8 laat zien hoe dit werkt. 12

Schaalbare webapplicatie Web role instance Tabellen Gebruikers Figuur 8: een schaalbare webapplicatie kan gebruikmaken van web role instances en tabellen. In dit voorbeeld zijn de clients browsers, dus kan ASP.NET of een andere webtechnologie worden gebruikt voor de applicatielogica. Het is ook mogelijk een schaalbare webapplicatie met op REST en/of SOAP gebaseerde webservices te maken met behulp van WCF en die services vervolgens vanuit bijvoorbeeld een Silverlight-client aan te roepen. In beide gevallen geeft de ontwikkelaar op hoeveel instances van de web role moeten worden uitgevoerd en daarop maakt de fabric controller van Windows Azure het gewenste aantal VM's aan. Zoals eerder vermeld houdt de fabric controller toezicht op deze instances en zorgt er zo voor dat het gevraagde aantal instances altijd beschikbaar is. Voor gegevensopslag maakt de applicatie gebruik van Windows Azure-opslagtabellen, die horizontaal geschaald kunnen worden voor het verwerken van zeer grote hoeveelheden gegevens. EEN APPLICATIE VOOR PARALLELLE VERWERKING MAKEN Schaalbare webapplicaties zijn handig, maar Windows Azure is ook zeer geschikt voor andere situaties. Denk eens aan een organisatie die op sommige momenten zeer veel rekenkracht nodig heeft voor een parallelle verwerkingsapplicatie. Hier zijn talloze voorbeelden van te verzinnen: rendering van special effects voor films, ontwikkeling van nieuwe medicijnen in een farmaceutisch bedrijf, financiële modellen bij een bank, enzovoort. Hoewel u een grote cluster met computers kunt gebruiken om in deze incidentele behoefte te voorzien, is dit een dure oplossing. Windows Azure voorziet u van deze bronnen als dat nodig is en levert een rekencluster op aanvraag. Een ontwikkelaar kan worker roles gebruiken om dit type applicatie te maken. En hoewel er meer mogelijkheden denkbaar zijn, maken parallelle applicaties vaak gebruik van grote datasets die in Windows Azure-blobs kunnen worden opgeslagen. In figuur 9 ziet u een voorbeeld van zo'n applicatie. 13

Applicatie met parallelle verwerking Web role instance Wachtrijen Worker role instance Blobs Gebruiker Figuur 9: een parallelle verwerkingsapplicatie kan gebruikmaken van een web role instance, een groot aantal worker role instances, wachtrijen en blobs. In dit scenario wordt het parallelle werk uitgevoerd door meerdere worker role instances die tegelijkertijd worden uitgevoerd, waarbij ieder instance gebruikmaakt van blobgegevens. Omdat Windows Azure geen limiet oplegt met betrekking tot hoe lang een instance kan worden uitgevoerd, kan ieder instance een willekeurige hoeveelheid werk uitvoeren. Om met de applicatie te communiceren, heeft de gebruiker genoeg aan één web role instance. Via deze interface bepaalt de gebruiker hoeveel worker role instances moeten worden uitgevoerd, kan hij deze instances starten en stoppen, resultaten ophalen en nog veel meer. Communicatie tussen de web role instance en de worker role instances vindt plaats via de wachtrijen in Windows Azure-opslag. Gezien de enorme verwerkingskracht van de cloud, leidt deze aanpak tot uitstekende prestaties. Met Microsoft Windows HPC Server kunt u bijvoorbeeld een rekencluster maken door Windows Azure worker role instances te gebruiken naast of in plaats van fysieke servers in het eigen datacenter. Welke manier u echter ook kiest, het gebruik van deze nieuwe bron van rekenkracht is in heel wat situaties zeer zinvol. EEN SCHAALBARE WEBAPPLICATIE MET ACHTERGRONDVERWERKING MAKEN De meeste applicaties die vandaag de dag worden gemaakt, hebben een browserinterface. Voor applicaties die alleen maar aanvragen van de browser accepteren en verwerken is dit prima, maar dit systeem legt tevens beperkingen op. Er zijn veel situaties denkbaar waarbij een webapplicatie werkzaamheden moet kunnen starten die op de achtergrond worden uitgevoerd, onafhankelijk van het aanvraag/respons-gedeelte van de applicatie. Denk bijvoorbeeld aan een webapplicatie voor het uitwisselen van video's. De applicatie moet browseraanvragen van een groot aantal gebruikers tegelijkertijd kunnen verwerken. Een deel van deze aanvragen betreft het uploaden van nieuwe video's. Deze video's moeten worden verwerkt en worden opgeslagen zodat ze op een later kunnen worden bekeken. Het is natuurlijk niet zinvol om de gebruiker te laten wachten terwijl deze procedure wordt uitgevoerd. In plaatst daarvan moet het gedeelte van de applicatie dat aanvragen van de browser accepteert, een taak op de achtergrond kunnen maken die het werk uitvoert. 14

Web roles en worker roles kunnen samen worden gebruikt om dit te realiseren. In figuur 10 ziet u een voorbeeld van zo'n applicatie. Schaalbare webapplicatie met achtergrondverwerking Tabellen Web role instance Wachtrijen Worker role instance Blobs Gebruikers Figuur 10: een schaalbare webapplicatie met achtergrondverwerking maakt gebruik van de mogelijkheden van Windows Azure. Net als de schaalbare webapplicatie die eerder is besproken, maakt deze applicatie gebruik van meerdere web role instances om de aanvragen van gebruikers te verwerken. Om een groot aantal gelijktijdige gebruikers van dienst te kunnen zijn, worden tabellen gebruikt om profielgegevens in op te slaan. Voor de werkzaamheden die op de achtergrond worden uitgevoerd, wordt gebruik gemaakt van worker role instances en worden de taken via wachtrijen doorgegeven. In dit voorbeeld werken de worker role instances met blobgegevens, maar andere opties zijn ook mogelijk. Dit voorbeeld laat zien hoe een applicatie veel van de standaardvoorzieningen van Windows Azure combineert: web role instances, worker role instances, blobs, tabellen en wachtrijen. En hoewel dat niet uit de illustratie blijkt, kan een applicatie voor het delen van video ook gebruikmaken van Windows Azure CDN om de toegang te versnellen. Hoewel niet voor iedere applicatie al deze voorzieningen nodig zijn, is het belangrijk dat ze aanwezig zijn om complexe scenario's als deze te kunnen realiseren. EEN WEBAPPLICATIE MET RELATIONELE GEGEVENS MAKEN Blobs en tabellen zijn geschikt voor sommige situaties. Voor veel andere situaties zijn relationele gegevens echter meer geschikt. Stel dat een bedrijf een applicatie voor de eigen medewerkers wil maken en uitvoeren op Windows Azure. Misschien is die applicatie bedoeld voor een kortere periode, waardoor het toewijzen van een server in het datacenter van de organisatie niet de moeite waard is. Of misschien moet de applicatie zo snel mogelijk klaar zijn voor gebruik en is er geen tijd om te wachten op het beschikbaar stellen van een server door de interne IT-afdeling. Of wellicht is de organisatie van mening dat het uitvoeren van de applicatie op Windows Azure goedkoper en eenvoudiger is. 15

Wat de onderliggende reden ook is, voor deze applicatie hebt u waarschijnlijk niet alle uitgebreide schalingsmogelijkheden van Windows Azure-tabellen nodig. In plaats daarvan kan het bedrijf de voorkeur geven aan de vertrouwde relationele benadering, inclusief de vertrouwde rapportagetools. In dit geval kan Windows Azure worden gebruikt in combinatie met SQL Azure-database, zoals u in figuur 11 ziet. Nieuwe webapplicatie met relationele gegevens Web role instance SQL Azure Gebruikers Figuur 11: een Windows Azure-applicatie kan gebruikmaken van SQL Azure voor een oplossing met relationele gegevens. Met SQL Azure beschikt u over een grote subset van SQL Server-functies, waaronder rapportages, in de vorm van een beheerde cloud-service. Applicaties kunnen databases maken, SQL-queries uitvoeren, enzovoort, maar het databasesysteem en de hardware hoeven niet te worden beheerd. Daarvoor zorgt Microsoft. Een SQL Azure-database is toegankelijk via het TDS-protocol (Tabular Data Stream), net als de versies van SQL Server in het eigen datacenter. Hierdoor heeft een Windows Azure-applicatie toegang tot relationele gegevens via bekende methoden, zoals ADO.NET. En omdat SQL Azure een cloud-service is, zijn de kosten gebaseerd op gebruik. Omdat Windows Azure en SQL Azure cloud-tegenhangers zijn van de applicaties en gegevens in het eigen datacenter, is het verplaatsen van de code en gegevens voor zulke applicaties tussen deze twee werelden zeer eenvoudig. Niet alles is helemaal hetzelfde. De Windows Azure-applicatie moet bijvoorbeeld in staat zijn meerdere instances uit te voeren, maar de cloud en de omgeving in het eigen datacenter komen grotendeels overeen. Deze portabiliteit is handig wanneer u een applicatie wilt maken waarvan de code en gegevens zowel in het eigen datacenter als in de cloud kunnen worden gebruikt. EEN LOKALE WEBAPPLICATIE MET RELATIONELE GEGEVENS MIGREREN Stel dat een organisatie, in plaats van een nieuwe webapplicatie voor Windows Azure te bouwen, een bestaande Windows Server-applicatie naar het cloud-platform wil verplaatsen. Dat kan bijvoorbeeld worden gedaan door gebruik te maken van een Windows Azure VM role. Zoals u in figuur 12 ziet, lijkt dit veel op het vorige scenario. 16

Gemigreerde lokale webapplicatie met relationele gegevens VM role instance SQL Azure Gebruikers Figuur 12: sommige applicaties in het eigen datacenter kunnen naar Windows Azure worden gemigreerd met behulp van de VM role en SQL Azure. Voor het gebruik van een VM role moet een organisatie een VHD (Virtual Hard Disk) maken op een computer in het eigen datacenter waarop Windows Server 2008 R2 wordt uitgevoerd. Deze image kan vervolgens worden geüpload naar Windows Azure en uitgevoerd in een VM role. Zoals u in de illustratie ziet, heeft de applicatie toegang tot relationele gegevens in SQL Azure. Een andere optie is de gegevens lokaal te laten staan en deze rechtstreeks via Windows Azure Connect te benaderen, zoals eerder omschreven. Een VM role kan zinvol zijn. Het is echter belangrijk dat u zich realiseert dat voor het verplaatsen van een Windows Server-applicatie naar Windows Azure wellicht meer nodig is dan het verpakken van de applicatie in een VHD en deze in een VM role uitvoeren. U hebt eerder gezien dat de fabric controller ervan uitgaat dat er altijd minimaal twee instances van iedere rol worden uitgevoerd. (Dit is een vereiste voor de Service Level Agreement (SLA) voor Windows Azure.) Houd er tevens rekening mee dat Windows Azure alle gebruiksaanvragen met load balancing over de instances van een rol verdeelt. Als de applicatie die wordt gemigreerd volgens die methode is gebouwd - misschien wordt die applicatie al met load balancing in een webfarm uitgevoerd - kan die op Windows Azure worden uitgevoerd, zonder dat er grote wijzigingen hoeven te worden aangebracht. Als de applicatie echter is bedoeld voor het uitvoeren van één instance, dan moeten er enkele wijzigingen in de applicatie worden aangebracht voordat deze op Windows Azure kan worden uitgevoerd. CLOUD-OPSLAG GEBRUIKEN VANUIT EEN APPLICATIE IN HET EIGEN DATACENTER OF EEN GEHOSTE APPLICATIE Hoewel Windows Azure over veel verschillende mogelijkheden beschikt, hebt u er voor een applicatie soms slechts één nodig. Denk bijvoorbeeld maar eens aan een applicatie in het eigen datacenter of een gehoste applicatie waarmee een grote hoeveelheid gegevens moet worden opgeslagen. Een bedrijf wil 17

bijvoorbeeld oude e-mails archiveren om te besparen op de opslagkosten maar wil die e-mails wel beschikbaar houden. Een nieuwswebsite die via een hoster wordt uitgevoerd heeft bijvoorbeeld behoefte aan een schaalbare, wereldwijd toegankelijke locatie om grote hoeveelheden tekst, afbeeldingen, video's en profielgegevens van de gebruikers op te slaan. Een website voor het uitwisselen van foto's wil de gegevens opslaan bij een betrouwbare derde partij. Al deze scenario's kunnen met Windows Azure-opslag worden geregeld, zoals u ziet in figuur 13. Blobs Tabellen Applicatie in eigen datacenter of gehoste applicatie Figuur 13: een applicatie in het eigen datacenter of een gehoste applicatie kan gebruikmaken van Windows Azure-blobs of -tabellen om gegevens in de cloud op te slaan. Zoals eerder vermeld heeft een applicatie in het eigen datacenter of een gehoste applicatie rechtstreeks toegang tot Windows Azure-opslag. Hoewel toegang tot de gegevens doorgaans trager verloopt dan bij lokaal opgeslagen gegevens, is deze oplossing wel goedkoper, beter schaalbaar en betrouwbaarder. Voor sommige applicaties is dit zeker het overwegen waard. En hoewel dat niet zichtbaar is in de illustratie, kunnen applicaties op dezelfde manier gebruikmaken van SQL Azure. WINDOWS AZURE BEGRIJPEN: EEN NADERE BESCHOUWING Als u Windows Azure echt wilt begrijpen, moet u de basis van het platform begrijpen en de scenario's herkennen waarvoor Windows Azure geschikt is. Het gaat daarbij om meer dan alleen technologie. In deze sectie wordt een aantal van de interessantere aspecten van Windows Azure nader bekeken. WINDOWS AZURE-APPLICATIES MAKEN Voor ontwikkelaars lijkt het maken van een Windows Azure-applicatie zeer veel op het bouwen van een traditionele Windows-applicatie. Het platform zowel.net-applicaties als applicaties die zijn gebouwd met niet-beheerde code. Een ontwikkelaar kan dus de oplossing gebruiken die het meest geschikt is voor het probleem. Om een en ander nog eenvoudiger te maken, bevat Visual Studio projecttemplates voor het maken van Windows Azure-applicaties. U kunt applicaties ook rechtstreeks vanuit Visual Studio naar Windows Azure uploaden. 18

Een duidelijk verschil tussen een cloud-oplossing en een oplossing in het eigen datacenter is dat Windows Azure-applicaties niet lokaal worden uitgevoerd. Dit verschil zou het ontwikkelen kunnen bemoeilijken. Als oplossing hiervoor biedt Microsoft de development fabric aan. Dat is een versie van de Windows Azure-omgeving die op de computer van de ontwikkelaar wordt uitgevoerd. De development fabric wordt op één computer of server uitgevoerd. De development fabric emuleert de functionaliteit van Windows Azure in de cloud, inclusief web roles, worker roles, VM roles en alle drie de Windows Azure-opslagopties. Een ontwikkelaar bouwt een Windows Azure-applicatie, implementeert deze in de development fabric en kan deze op nagenoeg dezelfde manier uitvoeren als in de cloud. Hij bepaalt bijvoorbeeld het aantal instances dat van iedere rol moet worden uitgevoerd, kan wachtrijen gebruiken voor communicatie tussen deze instances en kan verder nagenoeg alles wat met Windows Azure zelf mogelijk is. Nadat de applicatie is gemaakt en lokaal is getest, kan de ontwikkelaar de code en het bijbehorende configuratiebestand uploaden en de applicatie vervolgens uitvoeren. Een Windows Azure-applicatie wordt, ongeacht de manier waarop die is gemaakt, doorgaans door middel van een procedure met twee stappen beschikbaar gemaakt in de cloud. Eerst uploadt de ontwikkelaar de applicatie naar de staging-omgeving van het platform. Als de ontwikkelaar vindt dat de applicatie in gebruik kan worden genomen, gebruikt hij de Windows Azure-portal om de aanvraag hiervoor in te dienen. De overschakeling van de staging-fase naar de productiefase kan zonder downtime plaatsvinden, waardoor een actieve applicatie naar een nieuwe versie kan worden geüpgraded zonder dat de gebruikers daar iets van merken. De applicatie heeft in de staging-fase een DNS-naam die als volgt is opgebouwd: <GUID>.cloudapp.net, waarbij <GUID> staat voor de Globally Unique Identifier die door Windows Azure wordt toegewezen. Voor de productiefase kiest de ontwikkelaar een DNS-naam in hetzelfde domein, bijvoorbeeld myazureservice.cloudapp.net. Als de ontwikkelaar een ander domein wil gebruiken dan het domein cloudapp.net van Microsoft, kan hij een DNS-alias maken met behulp van een standaard CNAME. Als de applicatie eenmaal toegankelijk is voor gebruikers, moeten deze waarschijnlijk de mogelijkheid hebben om zich te identificeren. Daarvoor kunnen ontwikkelaars in Windows Azure de op HTTP gebaseerde verificatiemethoden gebruiken die zij willen. Een ASP.NET-applicatie kan bijvoorbeeld gebruikmaken van een lidmaatschapprovider om de gebruiker-id's en wachtwoorden op te slaan of een andere methode, zoals de Windows Live ID-service van Microsoft. Voor Windows Azure-applicaties kan ook WIF (Windows Identity Foundation) worden gebruikt voor op claims gebaseerde id's. De keuze is geheel aan de ontwikkelaar van de applicatie. DE REKENSERVICE NADER BEKEKEN Net als de meeste technologieën heeft Windows Azure-rekenen sinds de eerste release een aantal ontwikkelingen ondergaan. Oorspronkelijk kon de code in web roles en worker roles bijvoorbeeld alleen in de gebruikersmodus worden uitgevoerd. Momenteel zijn beide rollen voorzien van de optie voor verhoogde bevoegdheden, waardoor applicaties ook in de beheermodus kunnen worden uitgevoerd. Dat is bijvoorbeeld zinvol voor applicaties die een COM-component moeten installeren. Dat leverde namelijk problemen op bij de eerste release van Windows Azure. Het uitvoeren van een instance van een web role of worker role begint telkens helemaal van voren af aan: het onderliggende besturingssysteem in de VM is een standaard-image die door Windows Azure is 19

gedefinieerd. Dat betekent dat de installatie van software die door de role wordt uitgevoerd, opnieuw moet worden uitgevoerd wanneer er een nieuwe instance wordt gemaakt. Dat vormt geen probleem voor eenvoudige installaties, zoals het toevoegen van een enkele COM-component. Maar stel dat de instance, voordat die kan worden gebruikt, een allerlei software moet installeren. Dat leidt dan natuurlijk tot ongewenste vertragingen. Deze vertragingen voorkomen is een van de belangrijkste doelen van VM roles. In plaats van de benodigde installatie uit te voeren telkens als er een instance wordt gemaakt, kan alle vereiste software worden opgenomen in een VHD. Die VHD wordt vervolgens gebruikt om een VM role instance te maken. Dit gaat aanzienlijk sneller dan het gebruik van web of worker roles met verhoogde bevoegdheden. Dit is ook een oplossing wanneer handmatig ingrijpen is vereist tijdens de installatieprocedure. Dat is immers niet mogelijk met Windows Azure. Een andere wijziging ten opzichte van de oorspronkelijke versie van Windows Azure is dat het platform nu ondersteuning biedt voor toegang via RDP (Remote Desktop Protocol). Dat is handig voor bijvoorbeeld debuggen. De ontwikkelaar heeft dan rechtstreeks toegang tot een specifieke instance. RDP kan echter niet worden gebruikt voor VDI (Virtual Desktop Infrastructure). Windows Azure ondersteunt dit scenario (voorlopig in ieder geval) nog niet. Andere belangrijke aspecten van Windows Azure-rekenen zijn al beschikbaar sinds de eerste release van de technologie. Zo kunnen ontwikkelaars met Windows Azure aangeven in welk datacenter een applicatie moet worden uitgevoerd en waar de gegevens moeten worden opgeslagen. Daarnaast kunnen zij aangeven welke applicaties en welke gegevens (inclusief de gegevens in SQL Azure-database) in hetzelfde datacenter moeten worden geplaatst. Microsoft biedt Windows Azure voorlopig aan in datacenters in de Verenigde Staten, Europa en Azië, maar er zullen er nog meer volgen. DE OPSLAGSERVICE NADER BEKEKEN Voordat Windows Azure-opslag kan worden gebruikt, moet de ontwikkelaar een storage account maken. Om de toegang tot de gegevens in deze account te beheren, voorziet Windows Azure de maker van een geheime sleutel. Iedere aanvraag van een applicatie naar informatie in deze opslagaccount (blobs, tabellen en wachtrijen) is voorzien van een handtekening die met deze geheime sleutel is gemaakt. Met andere woorden, verificatie vindt plaats op accountniveau (hoewel blobs ook over een andere optie beschikken, maar daarover later meer). Windows Azure-opslag is niet voorzien van access control-lijsten of een andere geavanceerde manier om te bepalen wie er toegang heeft tot de gegevens. Blobs Blobs, binary large objects, zijn vaak precies datgene wat een applicatie nodig heeft. Of blobs nu video, audio, gearchiveerde e-mails of iets anders bevatten, ze zorgen ervoor dat applicaties gegevens op een algemene manier kunnen opslaan en toegankelijk kunnen maken. Als een ontwikkelaar blobs wil gebruiken, moeten eerst een of meer containers in een opslagaccount worden gemaakt. Iedere container kan een of meer blobs bevatten. Om een bepaalde blob te kunnen vinden, kan een applicatie een URI gebruiken, die als volgt is opgebouwd: 20

http://<storageaccount>.blob.core.windows.net/<container>/<blobname> <StorageAccount> is een unieke ID die wordt toegewezen als er een nieuwe opslagaccount wordt gemaakt, en <Container> en <BlobName> zijn de naam van een specifieke container en een blob in die container. Er bestaan twee soorten blobs: Block blobs, die elk maximaal 200 GB aan gegevens kunnen bevatten. Ten behoeve van efficiëntere overdracht is een block blob opgedeeld in blokken. Als er een probleem optreedt, wordt geprobeerd het meest recente blok opnieuw te verzenden en niet de hele blob. Nadat alle blokken van de blob zijn geüpload, kan de hele blob in één keer worden doorgevoerd. Page blobs, die elk maximaal 1 TB aan gegevens kunnen bevatten. Een page blob is onderverdeeld in pagina's van 512 bytes en een applicatie kan afzonderlijke pagina's in de blob lezen en schrijven. Containers kunnen worden gemarkeerd als privé of openbaar, ongeacht welk type blob ze bevatten. Voor blobs in een privé-container moeten zowel de lees- als schrijfaanvragen zijn ondertekend met de sleutel van de opslagaccount van de blob. Blobs in een openbare container kunnen door iedere applicatie worden gelezen, maar schrijfaanvragen moeten zijn ondertekend. Dat kan handig zijn wanneer u bijvoorbeeld video's, foto's of andere niet-gestructureerde gegevens voor iedereen beschikbaar wil maken via internet. Windows Azure CDN kan zelfs alleen worden gebruikt voor gegevens die in openbare blob-containers zijn opgeslagen. Een ander belangrijk aspect van blobs is de rol die zij spelen bij het ondersteunen van Windows Azuredrives. Om te begrijpen wat die rol inhoudt, moet u zich realiseren dat role instances vrij toegang hebben tot het lokale bestandssysteem. Standaard is deze opslag echter niet permanent: Als het instance wordt afgesloten, verdwijnen de VM en de lokale opslag. Door een Windows Azure-drive voor de instance te implementeren kunt u ervoor zorgen dat een page blob eruitziet als een lokale drive, inclusief een NTFSbestandssysteem. Schrijfbewerkingen naar de drive kunnen direct naar de onderliggende blob worden geschreven. Als de instance niet actief is, worden deze gegevens permanent in de page blob opgeslagen en kunnen ze zo weer worden geladen. Drives kunnen bijvoorbeeld op onderstaande manieren worden gebruikt: Een ontwikkelaar kan een VHD (Virtual Hard Disk) met een NTFS-bestandssysteem uploaden en deze implementeren als een Windows Azure-drive. Dit is een handige manier om bestandsysteemgegevens uit te wisselen tussen Windows Azure en een Windows-serversysteem in het eigen datacenter. Een Windows Azure-ontwikkelaar installeert een MySQL-databasesysteem in een role instance van Windows Azure en gebruikt een Windows Azure drive als onderliggende opslag. Tabellen Een blob is eenvoudig te begrijpen, het is eigenlijk niet meer dan een verzameling bytes, maar tabellen zijn iets complexer. In figuur 14 ziet u hoe de onderdelen van een tabel eruitzien. 21

Tabel Tabel Tabel... Entiteit Entiteit Entiteit... Eigenschap Eigenschap Eigenschap... Naam Type Waarde Figuur 14: tabellen bieden opslagfaciliteiten op entiteitniveau. Zoals u in de illustratie ziet, bevat iedere tabel een aantal entiteiten. Een entiteit bevat nul of meer eigenschappen, ieder met een naam, een type en een waarde. Er worden verschillende typen ondersteund, bijvoorbeeld Binary, Bool, DateTime, Double, GUID, Int, Int64 en String. Een eigenschap kan verschillende typen hebben op verschillende momenten, afhankelijk van de waarde die in de eigenschap is opgeslagen, en niet alle eigenschappen in een entiteit hoeven van hetzelfde type te zijn. Een ontwikkelaar kan zelf bepalen wat het beste is voor de applicatie. Wat een entiteit ook bevat, de maximale grootte is 1 MB en een entiteit wordt altijd als een eenheid benaderd. Als een entiteit wordt gelezen, worden alle eigenschappen geretourneerd en als een entiteit wordt geschreven, worden alle eigenschappen vervangen. Het is ook mogelijk een groep entiteiten binnen één tabel op atomische wijze bij te werken, zodat u zeker weet dat alle updates slagen of mislukken. Windows Azure-opslagtabellen verschillen op meerdere punten van relationele tabellen. Om te beginnen zijn het geen normale tabellen. Ze kunnen niet worden benaderd met ADO.NET en bieden geen ondersteuning voor SQL-queries. En tabellen in Windows Azure-opslag dwingen geen schema af. De eigenschappen binnen één entiteit kunnen verschillende typen hebben en die typen kunnen na verloop van tijd veranderen. De voor de hand liggende vraag is: waarom? Waarom is er geen ondersteuning voor normale relationele tabellen met standaard SQL-queries? Het antwoord vloeit voort uit een primaire doelstelling van Windows Azure om ondersteuning te leveren voor zeer schaalbare applicaties. Traditionele relationele databases kunnen verticaal worden geschaald, waarbij steeds meer gebruikers worden ondersteund door het DBMS op steeds grotere computers uit te voeren. Maar voor echte ondersteuning voor een zeer groot aantal gelijktijdige gebruikers moet de opslag 22

horizontaal worden geschaald, niet verticaal. Dit is alleen mogelijk als het opslagmechanisme eenvoudiger wordt gemaakt. Traditionele relationele tabellen met standaard SQL zijn niet erg geschikt voor dit doel. Daarvoor is de structuur nodig die door Windows Azure-tabellen wordt geleverd. Het gebruik van tabellen vereist enig denkwerk van ontwikkelaars, omdat de vertrouwde relationele concepten niet ongewijzigd kunnen worden toegepast. Voor het bouwen van zeer schaalbare applicaties is deze benadering echter wel heel zinvol. Ontwikkelaars hoeven zich geen zorgen meer te maken over de schaal. Zij kunnen naar hartenlust nieuwe tabellen maken en entiteiten toevoegen, Windows Azure zorgt voor de rest. Bovendien hoeven ontwikkelaars geen DBMS te onderhouden, omdat Windows Azure dat zelf doet. Het doel hiervan is dat ontwikkelaars zich volledig kunnen richten op de applicatie en zich niet bezig hoeven te houden met de technieken voor het opslaan en beheren van grote hoeveelheden gegevens. Net als bij alle andere onderdelen van Windows Azure-opslag zijn tabellen toegankelijk via REST. Een.NET-applicatie kan hiervoor gebruikmaken van WCF Data Services waardoor de onderliggende HTTPaanvragen worden verborgen. Iedere applicatie,.net of een ander type, kan deze aanvragen rechtstreeks indienen. Een query op een tabel wordt bijvoorbeeld uitgedrukt als een HTTP GET, met een URI die als volgt is opgebouwd: http://<storageaccount>.table.core.windows.net/<tablename>?$filter=<query> Hier staat <TableName> voor de tabel waarop de query moet worden uitgevoerd en <Query> voor de query die op de tabel moet worden uitgevoerd. Als de query een groot aantal resultaten retourneert, ontvangt de ontwikkelaar een 'continuation token' dat in de volgende query kan worden opgenomen. Door dit herhaaldelijk te doen, wordt de volledige resultatenset in gedeelten ontvangen. Windows Azure-tabellen zijn niet voor ieder opslagscenario de juiste keuze en voor het gebruik van Windows Azure-tabellen moeten ontwikkelaars enkele nieuwe dingen leren. Voor applicaties die de schaalbaarheid nodig hebben die door Windows Azure-tabellen wordt verschaft, zijn ze echter zeer geschikt. Wachtrijen Terwijl tabellen en blobs vooral bedoeld zijn voor het opslaan en ophalen van gegevens, is het voornaamste doel van wachtrijen communicatie mogelijk maken tussen de verschillende onderdelen van een Windows Azure-applicatie. Net als bij alle andere onderdelen van Windows Azure-oplag worden wachtrijen benaderd via REST. Zowel Windows Azure-applicaties als externe applicaties verwijzen naar een wachtrij met een URI die als volgt is opgebouwd: http://<storageaccount>.queue.core.windows.net/<queuename> Zoals eerder vermeld, worden wachtrijen vaak gebruikt om interactie mogelijk te maken tussen web role instances en worker role instances. In figuur 15 ziet u hoe dat werkt. 23

1) Werk ontvangen Web role instance 3) Bericht uit wachtrij ophalen Worker role instance 4) Werk uitvoeren 2) Bericht in wachtrij plaatsen Wachtrij 5) Bericht verwijderen Figuur 15: berichten worden in de wachtrij geplaatst, uit de wachtrij opgehaald, verwerkt en vervolgens expliciet uit de wachtrij verwijderd. In een normaal scenario worden meerdere web role instances uitgevoerd, die ieder taken van gebruikers ontvangen (stap 1). Om deze taken door te geven aan worker role instances, schrijft een web role instance een bericht naar een wachtrij (stap 2). Dit bericht, dat maximaal 8 KB groot kan zijn, kan een URI bevatten die verwijst naar een blob of naar een entiteit in de tabel of naar iets anders, dat hangt af van de applicatie. Worker role instances lezen de berichten in deze wachtrij (stap 3) en voeren de beschreven taak uit (stap 4). Houd er echter rekening mee dat het bericht na het lezen niet uit de wachtrij wordt verwijderd. Het bericht wordt slechts gedurende een bepaalde tijd (standaard 30 seconden) onzichtbaar gemaakt voor andere lezers. Nadat de worker role instance de taak uit het bericht heeft uitgevoerd, moet het bericht expliciet uit de wachtrij worden verwijderd (stap 5). Het scheiden van web role instances en worker role instances is aan te raden. Dan hoeft de gebruiker niet te wachten totdat er een grote taak is uitgevoerd en wordt de schaalbaarheid eenvoudiger: u hoeft alleen maar web role instances en/of worker role instances toe te voegen. Maar waarom moeten instances berichten expliciet verwijderen? Het antwoord is dat hierdoor fouten beter kunnen worden afgehandeld. Als de worker role instance die het bericht ontvangt het bericht zonder problemen verwerkt, wordt het bericht verwijderd terwijl dat nog steeds onzichtbaar is (binnen de tijdspanne van standaard 30 seconden). Als een worker role instance een bericht echter uit de wachtrij ophaalt en vervolgens vastloopt voordat de taak uit het bericht kan worden voltooid, dan wordt het bericht niet uit de wachtrij verwijderd. Nadat de time-out voor de onzichtbaarheid is verstreken, wordt het bericht weer in de wachtrij weergegeven en kan het door een andere worker role instance worden gelezen. Het doel hiervan is dat ieder bericht ten minste eenmaal wordt uitgevoerd. Zoals u uit deze beschrijving kunt opmaken, zijn wachtrijen in Windows Azure-opslag niet precies hetzelfde als wachtrijen in Microsoft Message Queuing (MSMQ) of andere meer bekende technologieën. Een standaardsysteem met wachtrijen hanteert vaak het principe 'first in, first out', waarbij ieder bericht slechts eenmaal wordt aangeleverd. Bij wachtrijen in Windows Azure-opslag is dat niet vanzelfsprekend. Zoals reeds is opgemerkt, kan een bericht meerdere keren worden aangeleverd en bestaat er geen 24