Windows Azure en pratique…
Olivier Léal, 
29 décembre 2011
Le PaaS Microsoft Windows Azure est l’une des plateformes « as a service » les plus abouties. Cependant, pour éviter les déceptions, il est important de bien comprendre les caractéristiques clés afin d’en faire le meilleur usage possible.
PaaS = Un cloud orienté services où l’infrastructure nécessaire au déploiement d’une application est créée à partir des informations associées au package de déploiement de l’application. Pour faire simple, c’est l’infrastructure qui se construit autour de l’application à héberger.
Répondons à des questions de base :
Que peut-on faire ou ne pas faire avec une instance de calcul (un serveur Windows dans le cloud Microsoft) ?
- On peut y faire exécuter n’importe qu’elle type d’application compatible avec l’OS Windows : c’est-à-dire du .net, mais aussi du java, php, ruby, … L’utilisation de .net est facilitée, cependant, il existe de nombreux sdk additionnels permettant de déployer et exécuter d’autres types d’exécutables.
- On ne peut pas y faire persister ses informations : l’état d’une instance Azure est à considérer comme « stateless ». Une instance Azure peut être réinstallée à tout moment et par conséquent, toutes les données stockées localement seront perdues.
Comment gérer la persistance des données ?
- Il existe deux services essentiels pour le stockage des données :
- SQL Azure : une base SQL Server en haute disponibilité pour le stockage des données relationnelles, limitée à 150 Go par database,
- les Blob : un entrepôt de stockage orienté clé/valeur sans limite de taille.
- Il existe un autre mode de persistance des données appelé Azure Drive. Il s’agit de pouvoir monter un disque persistant sur les instances de calculs. Les données de ce disque virtuel sont persistées dans les blobs Azure. Un Azure Drive peut être accessible en lecture pour plusieurs instances de calculs, cependant l’écriture est réservée à une seule instance.
Idéalement, la gestion de la persistance des données ne s’effectue plus via le système de fichier NTFS, mais par l’utilisation des services de stockage : SQL Azure ou les services associés aux Blobs.
Peut-on installer d’autres SGBD / Systèmes clé/valeur ?
Oui et Non :
- Oui, il est possible de démontrer qu’on peut arriver à faire fonctionner MySQL, Oracle,… par des procédures de déploiement complexes, mais c’est sans aucun support et en s’assurant soi-même de la bonne écriture des données principalement dans des Azure Drive ou en faisant le pari qu’avec « x » instances en cluster et en répliquant les données, il est peu probable que l’ensemble du pool d’instances soit arrêté à un même instant. A cela on peut ajouter le fait que l’utilisation des upgrade domains et des fault domains réduit à presque rien ce risque.
- Oui, pour des solutions comme un moteur de recherche dont la donnée peut être reconstruite. C’est le cas par exemple avec Apache SOLR que nous avons déjà déployé en production dans le Cloud Windows Azure. Mais aussi pour d’autres services comme Hadoop, Memcache, … Cependant, certains services comme la base NoSQL MongoDB propose maintenant un package d’installation compatible avec le stockage sur des blobs (MongoDB sur Azure).
- Non, car pour un déploiement en production, il est indispensable, au final, de s’appuyer sur SQL Azure et les Blob afin de disposer des garanties indispensables à la pérennité des données. Cependant, comme pour le cas de MongoDB, les logiciels proposent de plus en plus des adaptations afin d’assurer une compatibilité avec ces modes de stockage. L’avenir n’est plus au stockage des données dans des « file systems » ntfs/fat/…
La mise en oeuvre d’applications dans un PaaS nécessite une bonne compréhension de ses caractéristiques. Une fois cet apprentissage réalisé, il est possible de faire bien plus de choses qu’avec une architecture physique . L’ensemble des services proposés par le cloud est utilisable via des APIs, ainsi une application peut elle-même décider d’actions sur son hébergement afin d’adapter sa consommation en ressources.
Olivier LEAL
Merci pour le retour ! :o)
Il est effectivement important de noter la notion de stateless de Windows Azure qui n’a rien a voir avec la NON-gestion de sessions conseillée pour les applications distribuées, mais qui traite bien de la NON-persistance de vos données. Le fonctionnement est différent de AWS où les données stockées sur les disques locaux éphémères de votre instance ne sont pas garanties (pas de réplication RAID 1 comme les EBS), mais perdurent durant la vie de votre instance jusqu’à ce que vous cliquiez sur « terminate » et relâchiez la ressource EC2 (ou bien que l’instance EC2 crashe ;ob). Sur Azure, l’instance peut être détruite et reconstruite à tout instant sans action de votre part ! Il peut s’agir du passage d’un passage de patch MS, d’une action de maintenance, … La destruction/reconstruction de votre instance Azure peut avoir lieu à tout instant. C’est la différence entre le IaaS AWS et le PaaS Azure ! En PaaS, vous n’avez pas la main sur l’infrastructure sous-jacente. Dans un pur PaaS, vous ne devriez même pas avoir accès à l’OS : MS laisse cette possibilité pour vous permettre d’installer des composants autres que .Net sur les instances de calculs Azure.
Et comme le précise Olivier, pour la production, restez le plus proche possible du paradigme proposé par MS Azure pour vous assurer une bonne qualité de service. Vouloir faire du IaaS comme sur AWS et mettre en place certains éléments comme des bases de données/systèmes de stockage autres que les services proposés par Azure (Table Service, Blob Azure, SQL Azure, …) ne vous conduira à rien de bon.
PaaS = utiliser les APIs mises à disposition par Azure pour l’accès et le stockage de vos ressources ! :o)
Frédéric FAURE
Bonjour,
Je ne comprend pas bien la différence faite entre les disques locaux d’un EC2 et ceux d’un rôle Azure. Il me semble que les deux scenarios : celuide destruction / reconstruction automatique sous Azure, et de crash d’instance EC2 doivent être traités de manière similaire. Les deux sont imprévisibles. Et dans les deux cas, il me semble qu’il faut prévoir des processus de réplication et de reprise de données pour assurer une continuité et une cohérence dans le service. C’est pourquoi je ne vois pas bien en quoi il serait, par exemple, moins opportun d’installer MySQL en production sur Azure que sur AWS.
Effectivement, sur le scénario d’un crash hardware, le résultat est le même : perte des disques locaux et il fallait avoir sauvegardé sa donnée !
En revanche, une instance EC2 ne sera pas patchée à notre insu lors d’opérations de maintenance à l’initiative d’Amazon : AWS est de type IaaS et nous sommes maître de notre instance virtuelle et de tout ce qu’il y a dedans (OS, logiciels, …). Nous décidons des redémarrages, patchs à passer sur l’OS, … et les données sur les disques locaux ne sont jamais altérées. Elles ne sont détruites que lorsque nous effectuons l’action « terminate » sur l’instance EC2.
Sur Azure, une opération de maintenance de type passage de patch sur l’OS (du Guest ou du Host) peut être à l’initiative de Microsoft, ce qui a une incidence sur le lecteur D: (partition système) qui est mis à jour. De même, attention, le disque E: (sur lequel les packages sont déployés) est dynamique et peut donc prendre une autre lettre (F:, G:, …) suite à une opération. Lors d’un redémarrage simple, les 3 disques sont généralement persistés, mais aucune garantie n’est prise par MS : Azure est de type PaaS, l’accès à l’OS est octroyé pour nous donner plus de liberté, mais nous n’avons pas la totale maîtrise dessus.
Dans le cas d’une base de données, l’installer sur un disque local d’un EC2 est tolérable pour peu que l’on fasse des backups réguliers car les crash hardware sont rares. Sur Azure, cela revient à jouer à la roulette russe car à tout moment, l’instance peut être simplement redémarrée (donc interruption de service), voire pire : patché (interruption de service plus longue, voire modification de la lettre du troisième disque). C’est pour cela que le SLA d’Azure ne fonctionne qu’à partir de 2 instances démarrées pour un rôle donné, pour qu’il y en ait toujours une UP. Si tu ne fais que de la lecture sur ta base ce n’est pas trop problématique avec 2 instances UP avec le même jeu de données. Mais si tu fais de l’écriture c’est ingérable : il te faudra mettre des systèmes de réplication poussés pour t’assurer que ce que tu écriras sur une instance sera bien répliqué sur une ou plusieurs autres pour ne pas perdre la donnée en cas d’opérations sur l’OS. En plus, il n’est pas possible de mettre en place du master-slave dans un même rôle car les instances sont équivalentes (on peut envisager de les spécialiser – master ou slave – dans un même rôle avec un mutex dans un espace partagé, genre le table service, mais ça devient trop du bricolage), ce qui t’oblige à jouer sur plusieurs rôles avec probablement un rôle dédié pour du proxying pour orienter les requêtes vers l’un ou l’autre. Je te laisse imaginer la complexité du chantier ! :o)
Frédéric FAURE