Microsoft vient de publier la nouvelle version du SDK pour Windows Azure, version 1.1 de Février 2010 que vous pouvez retrouver sur :
Hormis la correction de quelques bugs de la version 1.0 (Novembre 2009) notamment avec le StorageClient ou l’API Diagnostics (prochainement abordé dans le Coach Azure MSDN), cette nouvelle version apporte deux nouveautés non-négligeable :
- Le “OS Version Support”
- Un nouveau service des Azure Storage : le Azure Drive
OS Version Support
Le “OS Version Support” est un attribut (nommé “osVersion”) que l’on va placer sur notre ServiceConfiguration.cscfg (fichier de configuration de notre service Azure) pour définir quelle est la version de l’OS qui va exécuter notre application, on appelle cela le ‘”Guest OS”.
Pourquoi ? Tout simplement pour éviter les problèmes de changement/mise à jour des machines virtuelles qui exécutent mon application.
Ainsi une application écrite avec la version 1.0 du SDK pourra choisir de s’exécuter sur la version Windows Azure Guest OS 1.0 (Release 200912-01) ou sur la Windows Azure Guest OS 1.1 (Release 201001-01). Par contre une application écrite avec la version 1.1 du SDK Azure tournera forcement sur la Windows Azure Guest OS 1.1 (Release 201001-01).
On a donc le choix entre le Windows Azure Guest OS 1.1 défini par la clé WA-GUEST-OS-1.1_201001-01 et l’ancien Windows Azure Guest OS 1.0 défini par la clé WA-GUEST-OS-1.0_200912-01. Ainsi, bien que Microsoft continura d’e faire évoluer les Guest OS, mon application pourra continuer de fonctionner dans la version pour laquelle elle a était écrite sans problème d’upgrade.
Par exemple pour que mon service fonctionne sur la version 1.1, le début de mon fichier de configuration ressemblera à cela :
1
2
3
| <ServiceConfiguration serviceName="CloudService1" osVersion="WA-GUEST-OS-1.1_201001-01" xmlns="http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceConfiguration">
<Role name="WebRole1">
.... |
Azure Drive
Annoncé en Novembre 2009 lors de la PDC09, le service Azure Drive (anciennement XDrive) permet de “monter” le service des Azure Blobs comme une partition NTFS (ex: X:\) sur le service Compute de Windows Azure. Si ces notions ne vous sont pas familières je vous invite à parcourir notre coach Azure sur la MSDN ainsi que notre Azure Roadshow. Ce service n’est disponible que dans un rôle (web ou worker) Windows Azure en version 1.1 (voir OS Version ci-dessus).
Derrière cela se cache en fait le service des Azure Blobs qui va stocker un disque dur virtuel VHD. Ce VHD utilise le Azure Blob Page Blob introduit en Novembre 2009 et non le classique Block Blob. Vous retrouverez sur notre Azure Roadshow à la slide 67 les différences majeures entre les Blocks et Pages blob.
Le VHD doit être partitionné en NTFS et vous avez ensuite la possibilité de pouvoir uploader/downloader vos propres VHD en utilisant le service des Blobs. Comme l’indique la slide 67 de notre Azure Roadshow, votre VHD ne pourra excéder 1 To (limite d’un Page Blob). De plus chaque VM peut monter jusqu’à 16 “Drives”.
Côté “prix”, vous payerez l’utilisation du service des Azure Storage à savoir $0.15 par GB et $0.01 toutes les 10000 transactions dans le forfait “Consumption” (voir le détail ici).
On pourrait alors se demander comment connaitre le nombre de transaction effectué lorsque j’accède au contenu de mon VHD stocké dans un PageBlob ? C’est pourra cela qu’on utilise un ”local-cache” grâce aux “Local Storage” du service de Compute de Windows Azure.
Vous définissez ainsi un LocaStorage à utiliser sur votre VM (voir le Coach MSDN pour mieux comprendre le LocalStorage – en résumé c’est un espace de stockage NTFS local à la VM qui est réinitialisé à chaque démarrage de la VM) par les lignes :
1
2
3
4
5
| <LocalResources>
<LocalStorage name="MyAzureDriveCache"
cleanOnRoleRecycle="false"
sizeInMB="220000" />
</LocalResources> |
Votre LocalStorage pourra être accessible sur la lettre Z:\ dans votre VM Azure. La taille du LocalStorage dépend de la taille de votre VM. Sur une Small instance on dispose de 250Gb, sur une Extra large instance on a 2Tb (voir le détail ici).
Il faudra ensuitre initialiser votre LocalStorage pour qu’il remplisse son role de “cache” pour les Drives par la ligne :
1
2
| CloudDrive.InitializeCache(localCache.RootPath,
localCache.MaximumSizeInMegabytes); |
Et pour finir vous pourrez monter votre “drive” sur votre LocalStorage par le code :
1
2
3
| CloudDrive drive1 =
new CloudDrive(new Uri(“http://account.blob.core.windows.net/container/Blob1”), credentials);
drive1.Mount(200000, DriveMountOptions.None); |
En clair, ce service va nous permettre de manipuler nos dossiers/fichiers comme nous le faisions On-Premise sur nos Windows Server sans devoir réécrire nos applications existantes. Derrière cela tout repose sur les PageBlob nous garantissant une disponibilité de 99,99% et failover automatique.
Plus d’informations :
En ajoutant aussi que le nouvel éditeur de code en WPF (où l’on appréciera grandement le Zoom-In/Out lors de présentation), nous apporte des tas de possibilité en matière d’extension.
Nom: Sébastien Warin
