Comment scaler une infrastructure AWS (Amazon Web Services) ? Je vais décrire dans cette deuxième partie de l’article le modèle de l’architecture et les composants techniques sous-jacents à adopter afin de mettre en place une infrastructure scalable. Nous aborderons tout particulièrement le sujet de l’optimisation de l’accès aux données dans les architectures de type scale-out propices à la distribution, autant au niveau du modèle de données que des couches basses pour l’optimisation des I/O. Nous verrons également les concepts de développement à privilégier tel que le stateless dans la plus pure tradition REST. Je terminerai par quelques trucs et astuces en fin d’article. Le but est de vous permettre de constituer et d’optimiser votre infrastructure en comprenant le fonctionnement des outils proposés par Amazon pour en tirer le meilleur parti.

Le scale-out
Le scale-out est à opposer au scale-up : ce dernier correspond à l’augmentation dynamique des ressources d’un serveur donné (ajout de RAM ou de CPU) à la volée. Ainsi l’application continue à s’exécuter sur une même machine dont le potentiel à augmenté. Le scale-out, lui, pour répondre à la montée en charge d’une application propose d’augmenter le nombre de serveurs. Au final, le potentiel global de l’infrastructure augmente aussi, mais est réparti entre plusieurs serveurs. Cela implique que l’application supportée sur le serveur ait été pensée en termes de distribution, c’est à dire qu’elle puisse s’exécuter en parallèle sur plusieurs serveurs sans que cela n’en corrompe la logique métier ou ne pose des problèmes d’accès aux ressources (qui doivent alors être disponibles via le réseau et non en local sur un serveur donné par exemple).

Le scale-out, c’est un peu l’agent Smith de Matrix. Pour le scale-up, pensez plutôt au gentil bibendum de Ghost Buster !

Stateless
Le meilleur moyen d’obtenir une application facilement distribuable et performante est de la penser en mode stateless. C’est à dire que c’est la requête du client qui doit contenir l’ensemble des informations qui vont permettre le traitement de ladite requête côté serveur, soit via un cookie ou bien via les paramètres de l’URL. Quand cela est possible il faut privilégier cette approche à tout prix par rapport au mode statefull dans lequel la partie serveur doit maintenir un contexte pour chaque client afin de pouvoir résoudre sa requête. La conception stateless fait parti des grands concepts du REST. A ce sujet, je ne peux que vous conseiller de lire cet excellent article sur REST de Jean-Paul Figer dans lequel vous pourrez comprendre toute la simplicité et la puissance du style.

Si vous êtes obligés de gérer du statefull, il vous faudra utiliser un cache réseau, tel que Memcached, pour partager les contextes entre vos différents serveurs. N’envisagez pas la formule cache local et sticky session, car vous aurez du mal à bénéficier d’une répartition fluide au niveau de votre load balancing. N’envisagez pas non plus un cluster qui communique en multicast car le réseau Amazon ne permet pas d’en faire… Ou bien alors il faudrait que tous les serveurs communiquent en unicast avec une gateway qui s’occupe de la redistribution des communications… Vous êtes sûr que vous ne préférez pas du stateless ? ;ob

La mise en place d’applications stateless n’est pas arrivée avec le Cloud Computing et les AWS, en revanche ne pas penser dans ce sens, vous empêcherait de bénéficier de tout le dynamisme et la souplesse proposés par ces services.

Optimisation de l’accès aux données
L’optimisation de l’accès aux données passe par 2 éléments :

• Le modèle de données et l’architecture logicielle que l’on retrouve dans les architectures scalables, que l’on soit sur une infrastructure AWS ou non.
• La gestion des I/O que l’on peut optimiser, notamment via une utilisation approfondie des AWS.

Le modèle scalable
Cela pourrait faire l’objet d’un article à part entière, mais correspond à un modèle assez classique au sein des applications de type casual gaming ou bien plus généralement liées à des applications basées sur les graphes sociaux ou bien centrées sur une notion métier forte en particulier.

Pour résumer, 2 méthodes de stockage de données :

• Un stockage de ce que l’on peut appeler le méta-modèle, qui n’a pas vocation à être distribué, basé sur une base relationnelle (même si essentiellement utilisée sous forme d’accès clé-valeur) structurée, indexée, contenant les informations générales de chaque utilisateur (dans la cas d’une application sociale, avec les informations nom, top score, gains de la veille, …), essentiellement accédées en lecture et dont il est possible d’alléger la charge via un Memcached en frontal. Il est donc possible d’effectuer des requêtes ensemblistes de type SQL et ainsi de récupérer des informations via l’utilisation de clauses (WHERE). Cette base peut être un MySQL ou un PgSQL par exemple. Je vous invite à lire ce comparatif très intéressant de Guillaume Plessis entre l’utilisation de MySQL installé sur un EC2 et l’utilisation du service RDS (Relational Database Service) d’Amazon. Je ne trahirai en rien le suspens en vous disant que la base de données c’est une histoire de barbus ! :o)
• Un stockage pour les données plus volatiles (comme les données de jeu, …), avec un fort rapport écriture/lecture, difficilement cachables, et pour lesquelles il faut opter pour une réelle solution de stockage structurée non relationnelle de type clé-valeur (NoSQL / Not only SQL diront certains), permettant ainsi de distribuer facilement les données sur X serveurs. On peut citer un nombre certain de candidats : Redis, Tokyo Tyrant/Tokyo Cabinet, MemcacheDB, … Et également les nouveaux modèles peer to peer tels que Cassandra, …

Tokyo Cabinet

En l’occurrence, Tokyo Tyrant / Tokyo Cabinet est une solution que j’ai mise en place et qui me semble bonne. C’est un couple gérant respectivement les requêtes à partir de serveurs distants (interface réseau) et les accès au système de stockage. 6 APIs sont disponibles afin de stocker les données :

1. On memory Hash,
2. On memory B+tree,
3. File Hash,
4. File B+tree,
5. Fixed-length Array,
6. Table.

Chacune d’entre elles a ses propres spécificités et répond à des besoins particuliers en termes de performances et de fonctionnalités.

Au niveau performances, outre ses performances naturelles, il a l’avantage, notamment, de ne pas gérer l’authentification (standard chez les systèmes de stockage clé-valeur, la sécurité est censée être assurée au niveau réseau pour les accès au système de stockage et au niveau applicatif pour les accès à la donnée – pour ne récupérer que ce qui vous concerne), ce qui allège le nombre d’accès (pas besoin de requêtes d’authentification) par rapport à une base de données classique. De plus, pas de gestion d’index lourds à reconstruire (possible cependant sur l’API « Table » de la Tokyo Team), … Est-il nécessaire de préciser que ce qui vous prendra du temps sur l’accès à la donnée via le réseau (entre le serveur web ou applicatif et Tokyo Tyrant) c’est… Le réseau ! Donc dans tous les cas, préférez l’utilisation au niveau client (API) de « mget » (multi get), par exemple, en positionnant en paramètre le tableau de clés que vous souhaitez récupérer, plutôt que d’effectuer N fois un « get » à partir du client, donc N accès réseau. « mget » se résoudra, lui, au niveau de Tokyo Tyrant.

Ces raisonnements appliqués sur cet outil doivent être appliqués à tout stockage de type clé-valeur.

La gestion des I/O
Venons-en à la spécificité des AWS en termes de stockage : les EBS (Elastic Block Store). Les EBS sont des disques réseau optimisés en I/O, faciles à manipuler, permettant d’assurer la durabilité des données qui ne doivent pas être perdues lors de l’arrêt d’un EC2 (volatile). J’ai cependant constaté de manière empirique des écarts de latence : pas énormes, mais sur une application réellement sollicitée, il y a un ressenti. Ce n’est pas rédhibitoire, il faut juste en tenir compte. Si le Load Average de vos serveurs augmente, ce n’est pas forcément le CPU en cause… Pensez I/O ! ;ob

Tout d’abord penser striping, donc RAID0. Pas besoin de mirroring (RAID1), la durabilité des EBS est déjà assurée par Amazon, de manière transparente, par réplication réseau : tirons parti de ce service et concentrons nous sur le striping. Pensez également à répartir les écritures des différents fichiers physiques (données, updates logs, …) sur différents disques (dans le cas d’outils utilisant des update logs, et c’est le cas pour MySQL et Tokyo Tyrant par exemple, pensez à bien paramétrer leur taille). C’est ce qui permet d’avoir les meilleures optimisations. Ensuite, choisissez bien votre système de fichier par rapport à votre outil (EXT3, XFS, …) et pensez aux options de montage (noatime, nodiratime, …). Finalement vérifiez bien le scheduler/ordonnanceur par défaut sur les instances EC2 que vous démarrez : par défaut, il s’agit de l’ordonnanceur NOOP (requêtes I/O dans une simple file FIFO). Envisagez quelque chose de plus performant comme CFQ (Completely Fair Queuing) par exemple… Enfin je dis ça, mais cela dépend toujours de la couche logiciel au-dessus et si et comment elle gère les priorités : dans cet exemple (qui n’est pas sur EBS) sur MySQL Performance Blog, il apparaît que les ordonnanceurs NOOP et DEADLINE peuvent être de meilleure facture pour améliorer les I/O InnoDB. Comme quoi, il faut quand même mieux tester dans son propre cas ! ;ob

Logical Volume Management

Un autre outil que j’ai utilisé avec les EBS et qui fonctionne très bien est LVM2 (Logical Volume Management, version 2). Je ne l’ai pas utilisé dans le cadre d’une architecture avec un nombre élevé d’IOPS (I/O operations Per Second) et n’ai donc pas testé les possibilités de striping (RAID0) offertes par l’outil. En revanche, je l’ai utilisé dans le cadre d’une infrastructure nécessitant de pouvoir supporter des augmentations conséquentes du volume de données et ceci sans interruption de service. L’opération de snapshot d’un EBS et de recréation du volume est trop longue. LVM est la solution, puisque cette couche d’abstraction permet de gérer des volumes logiques de manière indépendante des ressources physiques : il suffit de lever une nouvelle ressource EBS (une ligne de commande), de l’associer à l’instance EC2 (une autre ligne de commande) et d’ajouter cette ressource au pool de ressources LVM. Il suffit alors d’agrandir le volume logique (toujours transparent et sans arrêt du service), puis d’étendre le système de fichiers. C’est la dernière opération (qui est commune avec celle de la recréation du volume EBS) qui peut nécessiter d’arrêter le service quelques instants (une dizaine de secondes). A noter qu’il est possible d’étendre son système de fichiers à chaud avec EXT3, personnellement, je préfère une interruption de service de quelques secondes sur ce genre d’opérations très courtes mais cruciales. ;ob En prime, il est facile de d’effectuer des backups sur un système LVM qui propose une option de snapshot différentiel que l’on peut monter comme un volume logique indépendant : lorsqu’il y a une modification sur le volume origine, la valeur initiale est copiée dans le volume snapshoté, donc on peut snapshoter des volumes importants sur un espace réduit car seule la fréquence de modification est importante. Vous pourrez trouver de plus amples informations sur LVM2 et EBS en consultant ce très bon article de Laurent Roux.

Tous ces exemples, pour montrer que les EBS sont une ressource très intéressante : il faut les considérer tout d’abord comme un moyen d’assurer la durabilité des ressources importantes avant de considérer l’aspect performance. En effet, la performance n’est pas forcément meilleure sur un EBS que sur les disques locaux d’une instance EC2 (Cf. un test simple et intéressant de Charles-Christian Croix ou bien encore des tests un peu plus complexes que vous pourrez retrouver en tapant « performance ephemeral disk ebs volume raid » dans Goggle, il y en a un certain nombre de très intéressants et je dois avouer que j’ai du mal à faire mon choix ;ob). Cependant, quand on prend le parti d’assurer la durabilité de ses données et donc d’utiliser un EBS (qui, pour ceux qui connaissent, est comparable à un LUN sur un SAN), il y a divers moyens d’optimiser leur performance.

Il est à noter que les utiliser pour répartir les fichiers (et donc les I/O) sur plusieurs disques EBS peut être une solution de performance pure.

A noter tout de même que la bande passante de l’EC2 est forcément limitant arrivée à un certain seuil : ajouter des EBS est intéressant pour lisser les écarts de variance (en RAID0) ou bien pour optimiser le débit, mais il n’en reste pas moins que si vous ajoutez plusieurs EBS à votre instance EC2 et qu’ils sont tous sollicités fortement… C’est la bande passante de l’EC2 qui bloque. Il va falloir ajouter un nouvel EC2 (scale-out pour augmenter les ressources, en l’occurrence la bande passante), lui attacher de nouveaux EBS (n’oubliez pas qu’un EBS ne peut être attaché qu’à un et un seul EC2) et distribuer la donnée dessus (sharding).

Dans tous les cas, la manipulation des EBS est aisée et cette souplesse est un atout.

Tips & tricks
Cette dernière partie regroupe quelques trucs et astuces.

Alias & IPs
Pensez sur une infrastructure AWS à positionner des alias correspondant aux IPs privées de vos instances dans le fichier des « hosts », que vous pouvez déployer ensuite via Puppet pour plus de réactivité vu que les IPs sont « variables » (lorsque vous arrêtez une instance et que vous en redémarrez une juste après, vous ne conservez pas la même IP). L’utilisation du fichier « hosts » évite des résolutions DNS internes chez Amazon.

CDN & S3 Headers
Pour les CDN (Content Delivery Network) que vous utilisez obligatoirement dans une architecture scalable, pensez à utiliser S3 afin de mettre à disposition les images et autres contenus statiques. Inutile de maintenir un serveur Web à cette seule fin, S3 est là pour ça pour un coût minime.

Pensez également dans certains cas où votre trafic est plus modéré et que vous ne souhaitez pas passez sur un CDN (pour des questions de coût par exemple ;ob), que vous pouvez toujours optimiser la gestion de vos ressources sur S3 en utilisant les méta-données attribuées aux dites ressources sur S3, en positionnant, par exemple, les headers de type Cache-Control ou Expires. Vous pouvez visualiser ces méta-données via le nouvel onglet S3 de la console d’administration Amazon.

Backups… What else ?
S3 est également la solution pour les backups. Je n’ai pas trouvé d’outils intégré satisfaisant pour cette tâche : j’utilise simplement un outil en ligne de commande « s3cmd » afin de stocker mes backups. J’ai intégré cet outil dans des tâches Capistrano appelées par cron. Très simple d’utilisation, s3cmd permet de consommer les services de S3 et offre la possibilité de transférer les données en HTTPS et également de les stocker sous un format crypté.

Conclusion
Il y aurait encore beaucoup de choses à dire sur ce sujet, mais ce sont à mon avis les principales, en tout cas par rapport à l’utilisation des services mis à disposition par les AWS. Ce qu’il en ressort, c’est :

• Le stateless et REST de manière générale, sont d’autant plus adaptés aux AWS qu’ils permettent de distribuer aisément la charge sur une infrastructure s’adaptant à la montée en charge sur un modèle scale-out.
• L’accès aux données est toujours le goulet d’étranglement des applications distribuées devant scaler. Il s’agit de travailler à ce niveau le modèle de données et de tirer parti des systèmes de stockage adéquates :
  • Technologies SQL pour les méta-données pouvant nécessiter du requêtage ensembliste et de la mise en  relation, tout en utilisant au maximum un cache réseau pour les informations avec un fort ratio lecture sur écriture.
  • Technologies NoSQL / Not only SQL / clé-valeur pour les informations pouvant être accédées par une clé unique, et ainsi bénéficier de la distribution inhérente au scale-out.
• Penser finalement aux couches basses en sélectionnant convenablement le système de fichiers et l’ordonnanceur. Pensez également RAID (striping) et LVM (extension de volume et snapshot différentiel) pour tirer parti de la souplesse d’utilisation des EBS et répartition des I/O sur différents devices (en prenant toujours garde à votre bande passante, au niveau EC2, qui peut devenir limitant : dans ce cas ajouter une ou plusieurs instances EC2 pour gagner en bande passante et distribuer – sharder – la donnée sur de nouveaux EBS).

J’espère que ce deuxième volet de mon retour d’expérience sur la scalabilité des infrastructures AWS vous aura intéressé.

Frédéric FAURE @Twitter @Ysance

Comment scaler une infrastructure AWS (Amazon Web Services) ? C’est une réponse détaillée que va apporter cet article en 2 parties : les outils à utiliser pour tirer parti du dynamisme des services Amazon et le modèle d’architecture à adopter pour une infrastructure scalable. Je me base sur mes expériences tirées de plusieurs projets de production sur les AWS, à la fois dans le domaine du casual gaming (sur Facebook), dans celui des infrastructures e-commerce ou bien encore dans le cadre du SIG (Système d’Information Géographique) grand public. Il est vrai que l’expérience dans le domaine du jeu est celle qui est actuellement la plus représentative en termes de scalabilité, du fait du nombre d’utilisateurs (> 800K DAU – Daily Active User – et plus de 20M de pages vues par jour), cependant les expériences dans le e-commerce et le SIG (expérience en cours :o)) offrent également une autre vision de la scalabilité, prenant en compte des problématiques différentes de disponibilité et de gestion des données. Je vais donc tenter de brosser un tableau exhaustif des éléments à prendre en compte afin d’optimiser le dynamisme d’une infrastructure montée dans un environnement de Cloud Computing et en l’occurrence dans celui des AWS.

Les outils
Je propose des exemples d’outils que j’ai utilisés dans mes différentes expériences de production et qui m’ont convaincu par leur efficacité. Cependant, ce n’est pas tant l’outil qui est mis en valeur que la fonctionnalité sous-jacente qu’il va falloir implémenter pour tirer parti au mieux des AWS.

Différence entre une infra AWS et une infra standard
Il y a 2 éléments de réponse :

• Tout d’abord, les AWS permettent de manipuler les composants Hardware et d’Infrastructure via la code (en passant par des APIs), cela permet un dynamisme qu’il va falloir exacerber en sélectionnant convenablement ses outils. Amazon propose de plus un certain nombre de garanties techniques sur leurs services, il conviendra d’en tirer parti afin de se concentrer sur l’essentiel.
• Ensuite, une seconde partie de la réponse devrait être : « aucune ! ». Cependant, force est de constater que bien souvent le côté plus douillet de l’infrastructure hébergée « à la maison » pousse à une certaine forme de laxisme sur un certain nombre de points. Le fait que Amazon, avec ses AWS, propose une solution volatile, au niveau des EC2 notamment, oblige à mettre en place des mécanismes qui devraient être standards.

Gestion de configuration centralisée
La possibilité d’instancier de multiple serveurs (EC2) à la volée pour répondre à un pic de charge ou des traitements ponctuels, nous oblige à utiliser un outil de gestion de configuration centralisée. L’utilité est multiple :

• Instancier rapidement une machine correspondant à un type prédéfini : serveur Web, serveur de cache, …
• Assurer l’homogénéité de la configuration de l’ensemble des instances d’un même type à tout instant.
• Capitaliser un savoir faire : les packages, configurations, services, … de chaque type d’instance est contenu dans un descripteur. Cela permet aux nouveaux venus (et aux autres) de connaitre la composition des serveurs sur la simple lecture du ou des descripteurs associés.

Puppet est une solution très intéressante pour cette tâche. L’architecture Puppet est constituée de:

• Un Puppet Master, gardien des configurations, il contient les descripteurs des packages à installer, fichiers de configuration à déposer et services à démarrer pour une nouvelle instance EC2 afin de la préparer suivant le type du ou des nœuds auxquels on l’a associée ou tout simplement pour maintenir à jour une instance existante.
• De multiples clients Puppet installés sur les instances EC2. Régulièrement, le client pull le master afin de vérifier que sa configuration est à jour. Il est également possible de faire du push sur les clients à partir du master pour déclencher une mise à jour urgente.

Il est ainsi très simple de monter une nouvelle instance d’un type donné et d’être sûr que, d’un serveur à un autre, la configuration est complètement identique. Il est à noter que les descripteurs du Puppet Master fonctionnent sur un système de nœuds et un serveur peut faire référence à plusieurs nœuds. On obtient donc une configuration très modulaire.

Descripteur Module Puppet

Le gestionnaire de configuration centralisée est indispensable sur une infrastructure scalable qui est amenée à avoir un grand nombre d’instances dont certaines devront être montées rapidement afin de répondre aux sollicitations des utilisateurs lors des pics de charge.

« Mais… », me direz-vous, « il faut bien installer le client sur la nouvelle machine ? ». Et oui, d’autant plus qu’il y a un système de requête/acceptation de certificat entre le client et le master afin que n’importe qui ne puisse accéder aux configurations. « Très simple ! », vous répondrais-je, au lieu d’utiliser une IHM, comme Elastic Fox, afin de se connecter aux APIs des services Amazon, il suffit de s’y connecter en lignes de commande via un script qui instancie un EC2, éventuellement crée un volume EBS et l’associe, se connecte en SSH sur la nouvelle machine et installe le client, se connecte sur le master et accepte la requête de certificat, redémarre le client et « hop ! ». L’instance s’installe et se configure toute seule. Les possibilités de réactivité et de dynamisme inhérentes aux EC2 et aux AWS de manière générale nous impose cela, sinon ce serait sous exploiter l’outil, voire le més-exploiter.

Et les AMIs (instance-store root devices) ou les EBS root devices (à noter que pour ces dernier, il n’y a pas encore beaucoup de choix en termes de templates) ? Il est cependant possible de se constituer une AMI ou bien un EBS root device avec le client Puppet installé dessus (et d’utiliser éventuellement les user-data au lancement de l’instance afin de le paramétrer si une configuration « statique » sur l’AMI n’est pas suffisante). Cependant, dans un environnement de production, l’AMI ou l’EBS root device ne permettent pas de remplacer un Puppet : si il faut modifier l’AMI à chaque modification de paramétrage et redéployer les EC2… On n’a pas fini. L’AMI est un bon outil pour instancier un template de base (au sens basique), pas pour conserver une infrastructure de production en bon ordre de fonctionnement.

Pour conclure, il est même possible d’envisager une auto-scalabilité (plus complète que celle proposée par le service Auto Scaling d’Amazon basé sur CloudWatch) qui reviendrait à déclencher ce script sur le dépassement d’une valeur d’un graphe de monitoring (métrologie), instanciant donc une nouvelle machine pour supporter la période de pic, instance qui serait « terminée » suite au passage en dessous d’un autre seuil sur ledit graphe. Les possibilités sont énormes. Cependant, le coût des derniers éléments à mettre en place sur une infrastructure importante de production pour accéder à l’auto-scalabilité est conséquent (complexité exponentielle). Si on a l’opportunité, c’est un bel ouvrage, sinon se « contenter » d’une solution aisément scalable où il suffit de lancer un script manuellement (ou bien à heure fixe basé sur l’étude des métriques remontés par la métrologie, ce qui est une bonne alternative) et éventuellement d’ajouter manuellement une ou deux références dans un fichier est une alternative tout à fait respectable.

Exécution de tâches automatisées en parallèle
Du fait de la variation du nombre d’instances en fonction de la charge d’une infrastructure scalable et surtout du nombre potentiellement important desdites instances, il n’est pas envisageable d’effectuer les opérations de maintenance et de déploiement unitairement sur chaque machine (et encore pire à la main !), ce qui non seulement serait chronophage, mais de surcroît source d’erreurs. Il est alors indispensable d’utiliser des outils spécialisés dans l’automatisation et l’exécution parallèle de tâches, tel que Capistrano, dont les bénéfices sont multiples :

• Scripter un certain nombre de tâches, complexes ou non, (livraisons, backups, publication/maintenance du site, …) et de les exécuter rapidement en parallèle sur X machines en une seule commande.
• Assurer la reproductibilité d’une tâche.
• Capitaliser un savoir faire (Cf. Puppet).

Descripteur Tache Capistrano

Cet outil est très simple d’utilisation et très pratique. Il exécute des tâches en parallèle (en se connectant en SSH – n’utilisez pas la clé « root » de vos instances EC2 dans l’outil, mais une autre dédiée, c’est plus classe…) sur un ou des groupes de serveurs définis par des rôles.

C’est un complément à Puppet et non un doublon car ils n’ont pas la même cible :

Objectif
Puppet - Homogénéité de la configuration du parc de serveurs.
Capistrano - Reproductibilité des tâches et exécution en parallèle.

Mode de fonctionnement
Puppet - Pull régulier des clients (voire push du master).
Capistrano - Tâches ponctuelles (appel manuel ou par cron).

Orientation
Puppet - Objets / notions prédéfinis tels que « Package », « Service », « File », …
Capistrano - Des commandes génériques comme « upload », « download », « system », « run », …

Cible
Puppet - Infrastructure et services.
Capistrano - Services et applicatif.

A noter, Webistrano est une IHM permettant d’accéder aux fonctionnalités de Capistrano et introduisant une notion de gestion de projet par la possibilité de gérer les accès aux tâches en fonction de son profil, de tracer qui a déployé quoi sur quel serveur et d’envoyer des alertes mails sur certaines actions. Je trouve cette jointure avec la gestion de projet intéressante.

Monitoring
C’est un des éléments cruciaux d’une architecture scalable, si ce n’est le principal. Il est indispensable d’avoir à disposition des métriques afin de savoir justement quand scaler. Il permet d’identifier les points d’engorgement de l’infrastructure, d’analyser l’évolution du trafic sur votre site et d’en déduire les comportements des utilisateurs et permet également de déclencher des alertes.

Cet apport de métriques est plus représentatif de la métrologie que de la supervision. On verra que, dans le cadre d’une infrastructure sur AWS, la métrologie a une valeur ajoutée plus importante que celle de la supervision (même si cette dernière reste indispensable). A ce propos, voici un éclaircissement sur les 2 disciplines du monitoring qu’il faut identifier :

• La supervision vérifie l’état d’un hôte ou d’un service et remonte une alerte sur la détection d’un comportement anormal (temps de réponse trop long, statut NOK, …) et implique une action immédiate de la part des interlocuteurs concernés. Une alerte doit signifier que l’hôte ou le service est inutilisable (critical) ou risque de l’être (warning) et ne pas renvoyer de « simples informations » qui pollueraient la visibilité des réels incidents.
• La métrologie permet d’historiser les données, éventuellement d’appliquer un traitement ou filtre dessus, avant de les présenter sous forme de graphiques ou de reporting. Ces données permettent d’apporter un correctif à postériori au niveau développement ou paramétrage des services afin d’apporter une optimisation desdits services et également de définir les ressources à attribuer aux services au plus juste. Cet aspect du monitoring est tout aussi important car il va permettre d’améliorer le service et donc le rendu des utilisateurs (internes ou clients finaux) et également de lisser les coûts. Les résultats issus de la métrologie doivent mettre aisément en valeur les améliorations à apporter en corrélant les valeurs récupérées.

Un certain nombre existent sur le marché avec leurs avantages et inconvénients, certains plus orientés supervision, d’autres plus métrologie. On citera Centreon/Nagios, Zabbix, Cacti ou encore Munin. Personnellement, j’utilise Centreon/Nagios essentiellement pour la supervision et Cacti pour la métrologie orientée logicielle avec des graphes pré-packagés comme pour Apache, MySQL, Memcached, … Mais j’ai eu de nombreux bons écho sur Zabbix pour son exhaustivité de fonctionnalités et Munin pour sa simplicité d’utilisation.

Thread Scoreboard Apache - Yearly - 1 Day Average

Il est à noter que ces outils fonctionnent pour la plupart (Centreon, Cacti et Munin) sur RRDtool (Round-Robin Database), un outil de gestion de base de données permettant également de représenter graphiquement les données contenues dans la base. Le gros avantage tient dans le fait que le volume de données stockées est minimal même pour la conservation de plusieurs mois, voire années de données. Cela est rendu possible par le calcul de moyennes sur des périodes (de 1 minute à 1 jour) : les données récentes sont exactes, alors que les plus anciennes sont approximées. Très pratique car nous avons à la fois des métriques récentes exactes et conservons un historique, une représentation de l’évolution de notre architecture, ce qui est capital afin de visualiser l’évolution des métriques clés et de comprendre les impacts de l’évolution des composants de ladite infrastructure ou bien des applications supportées au fur et à mesure des livraisons des différentes releases.

Concernant les infrastructures de type Cloud Computing, la discipline ayant la plus forte valeur ajoutée est la métrologie, car c’est elle qui va permettre d’apporter un feed back à vos outils d’automatisation.

Gardez à l’esprit également qu’il est intéressant de pouvoir intégrer dynamiquement les nouvelles machines installées et configurées par Puppet dans l’outil de monitoring. Privilégiez donc les outils de monitoring avec une configuration modulaire, ou simple d’accès via APIs.

Gestion des logs centralisée
C’est indéniable, plus vous aurez d’instances, plus vous aurez de logs éparses sur les diverses instances. De plus, diriger tous les logs vers le daemon syslog devient problématique car tous les composants de l’infrastructure ne gèrent pas forcément bien cela (redirection, respect du protocole syslog, …), sans parler de la ou des applications/briques fonctionnelles qui peuvent loguer dans des fichiers disparates sur le serveur.

Pensez à des outils comme Syslog-NG : il est composé d’un serveur et de plusieurs clients, en fait le même outil mais avec des configurations différentes. En plus, il est capable de vérifier régulièrement des fichiers de logs (d’applications métier par exemple) et de transmettre uniquement le différentiel, même si celui-ci ne respecte pas le protocole syslog :

• Le client récupère les logs de files(fichiers)/pipe/unix-dgram/… et envoie les infos sur le réseau (tcp/udp).
• Le serveur récupère les infos du réseau (tcp/udp) et les enregistre dans des fichiers, bases de données, …

Architecture Syslog-NG

Il s’agit juste de différences minimes en termes de configuration. Le composant peut également servir de relai sur des infrastructures plus complexes en recevant les logs du réseau à partir de divers clients et en les envoyant à nouveau sur le réseau à destination d’un serveur.

Il est possible d’appliquer des filtres avant d’envoyer les logs sur le réseau pour ne faire transiter que le nécessaire et ensuite il est également possible d’en appliquer au niveau du serveur pour gérer différemment les logs en provenance des clients en fonction de leur criticité, programme émetteur, hôte d’origine, …

C’est un outil simple et non intrusif pouvant prendre en compte les logs des applications éparses sur un serveur (même si ces logs ne respectent pas le format du protocole « syslog » – il y a cependant un plus à respecter ce protocole pour avoir une meilleure précision au niveau des « facilities » et « priorities »).

De même que pour le monitoring, gardez à l’esprit qu’il est intéressant de pouvoir intégrer (et retirer) dynamiquement les nouvelles instances à gérer au niveau du système de logs.

Conclusion
Au delà des outils présentés, ce sont les fonctionnalités sous-jacentes qui sont importantes. Ce qu’il en ressort, c’est :

• Les outils comme les gestionnaires de configuration centralisée, les outils d’exécution de tâches automatisées en parallèle ou bien les gestionnaires de logs vont prendre encore plus d’importance. Il n’est plus envisageable de travailler sans sur de telles infrastructures.
• Le monitoring est toujours une valeur clé et le restera, mais la métrologie permet avec l’analyse des métriques clés définis dans son infrastructure d’alimenter les outils d’automatisation.
• L’automatisation est bien le mot clé mis en avant par les AWS : l’accessibilité des ressources Hardware ou d’Infrastructure via du code permet d’aller vers des architectures de plus en plus autonomes. Il faut cependant positionner le curseur convenablement, sachant que les dernières étapes d’une automatisation complète seront les plus coûteuses.

J’espère que ce retour d’expérience vous aura intéressé autant que j’ai eu de plaisir à travailler sur ces infrastructures. Je continuerai cet article dans une deuxième partie consacrée au modèle d’architecture à appliquer pour des infrastructures scalables.

Frédéric FAURE @Twitter @Ysance

Je profite de Decrypt pour annoncer que je donnerai une formation sur les AWS (Amazon Web Services) destinée aux professionnels le Vendredi 9 Juillet 2010. Elle se déroulera à Paris en une journée. Cette formation est éligible au financement par les OPCA (Agefos, FAFIEC …), peut être intégrée à une période de professionnalisation ou à un DIF.

Le but de la formation est de donner une vue d’ensemble des différentes offres (AWS, GAE & Azure) et de leur positionnement et d’expliquer ce qu’est le Cloud Computing (modèle économique et services), puis de se concentrer sur l’offre d’Amazon (architecture, services, résilience, support, sécurité, …) et de la mettre en pratique (EC2, EBS et S3). La dernière partie est une ouverture sur les outils à mettre en place afin d’optimiser l’utilisation de ces ressources (gestionnaire de configuration centralisée, serveur de logs, métrologie, …).

La formation sera axée à la fois sur une approche théorique et pratique, avec 30% du temps de formation passé à réaliser des travaux pratiques (sur les composants principaux que sont EC2, EBS et S3, ainsi que manipulation des outils et gestion de compte AWS), et sur une forte interactivité afin de répondre à toutes vos interrogations.

Qui peut y participer ?
Des chefs de projet, architectes techniques et fonctionnels, administrateurs système, responsables d’équipes de développement, directeur/responsable informatique.

Quel est le programme proposé ?

1ère Demi-journée
Le Cloud Computing

• De quoi s’agit-il ?
• Les acteurs du marché et leurs différentes approches (Amazon, Microsoft, Google, …)

Le cas Amazon

• De quoi s’agit-il ?
• Comparaison d’une infrastructure Cloud AWS avec une infrastructure physique classique
• Les cas d’utilisation
• Les coûts

Les outils

• Gestion de son compte (clés, certificats, facturation, support, …)
• Les consoles d’administration (Console AWS, ElasticFox, S3 Organiser)
• Les APIs

2ème Demi-journée
Les services infrastructure AWS

• Elastic Compute Cloud (EC2)
• Elastic Block Storage (EBS)
• Simple Storage Service (S3)
• Séance de TP sur EC2, EBS et S3

AWS… Encore un peu plus loin

• Overview automatisation & dynamisme : gestion de la configuration centralisée avec Puppet, déploiement automatisé avec Capistrano, monitoring avec Cacti & Centreon/Nagios, gestion des logs avec Syslog-NG, auto-scalability, LVM, …

Les informations utiles

• Forums, sites, liens, livres blancs (sécurité, extension SI, …)

Quelles sont les modalités pratiques ?
Lieu : Mediasites, 42 rue Legendre, 75017 Paris – Métro : Villiers
Date : Vendredi 9 juillet 2010
Heure : 9h00 à 17h00

Durée : 1 journée
Tarif : 800 euros HT
Toutes les sessions se déroulent dans le centre de Paris. Cette formation est éligible au financement par les OPCA (Agefos, FAFIEC …), peut être intégrée à une période de professionnalisation ou à un DIF. Nous pouvons vous aider à monter votre dossier.

Pour vous inscrire, veuillez remplir ce formulaire.

Pour plus d’informations, veuillez contacter Catherine LHUISSIER à catherine.lhuissier@ysance.com.
Tél. : 01 83 62 11 58

En espérant que vous viendrez nombreux. :o)

Frédéric FAURE @Twitter @Ysance

Network and shared resources
The network is an important feature … and in more than one way! Effectively, the Cloud configuration is already prepared for you, and that’s convenient. But that also means that you don’t control it, and consequently you cannot monitor it yourself and therefore diagnose, for example, the causes of a slow-down. There is a similar lack of transparency concerning the shared resources at Cloud: at our level it is impossible to estimate the impact of other people using the resource we are sharing (such as the physical computer on top of which is based our EC2 instance, the physical device we use as an EBS network-attached device, the network bandwidth, etc.). The only network monitoring possible is limited to input/output on the instance (for example, an EBS is a network-attached device, so … there is no means of verifying the connectivity conditions, you will have to do with the I/O disks). The monitoring you can do is concentrated on the EC2 virtual instance itself (the instance is managed by a hypervisor and based on a Xen virtualization). Total visibility of our infrastructure is therefore not possible on Cloud. This must be taken into account… and accepted, if you wish to implement your architecture on Cloud. You must also weigh up the same lack of transparency for other shared resources as previously mentioned (EBS use, etc.).

AWS : Isolation of the EC2 Instance (from aws.amazon.com)

Likewise, a multicast is not possible when it comes to communication protocols: bear that in mind for certain clusters. This constraint is understandable, given the far-reaching impact that a mismanaged multicast can have.

That is due to Cloud’s own way of operating: it has easy ways which mask a certain number of elements you no longer control.

On-call support, monitoring, BCP (Business Continuity Planning) and penalties
One question I’ve been asked frequently is “Does Amazon provide on-call support (regarding your own application/infrastructure your are running on top of the AWS) ?” The answer is no. AWS must be seen as a set of tools offered by Amazon which ensures that these tools are always up and well working. They maintain these tools and the development of their various functions. However, you are responsible for your use of the tools (in any case they do not possess the private keys of your EC2 instances…), so there is no monitoring / on-call support / BCP (Business Continuity Planning) package.

Unlike the specific contracts you may sign with your hosting providers, you must provide for these elements yourself, or regarding on-call support for example, you could out-source it to a facilities management company. Ditto for monitoring: Amazon offers Amazon CloudWatch, but the information (% of CPU, read/written bytes onto disk and in/out bytes on the network) is too brief for genuine monitoring as provided by Centreon/Nagios, Cacti, Zabbix or Munin. The CloudWatch information is used by the Auto Scaling function, but does not replace true monitoring. Some traditional hosting providers offer packaged monitoring with their services.

AWS CloudWatch

As far as the BCP and penalties are concerned, it amounts to being internally hosted: you are responsible for your resources and you manage failure / disaster recovery in line with the tool’s capacities (the AWS). This is where it’s important to understand the global nature of the architecture of Amazon services: if you don’t understand how the tool works, you will not be able to implement an effective BCP. As for penalties, there’s nothing unusual: it simply means a smaller bill for the month when you come under the ‘Service unavailable’ category as defined by Amazon criteria. This has nothing to do with the penalties based on the amounts lost due to unavailability.

It is imperative to consider Amazon web services as a tool. In spite of it being an accessible AWS support (that you can call for tools’ level questions and issues) that you can pay for, you will not get the full contractual potential you would have with a more traditional hosting provider, and broadly speaking, you will be responsible for your architecture on all levels (including the security of your instances: don’t lose your keys! ;ob).

Security
Security…  frequently a taboo topic, as soon as we start talking about Cloud computing. I don’t mean the integrity of stored data or even access management on the virtual instances we are responsible for, I’m talking about the confidentiality of the stored data on the different services (S3, EBS, EC2, SQS, etc.) or data which transit between those services.

The first key point is that the level of security supplied in Amazon datacenters, not just physically but – equally importantly – in programmatically terms, will still be streets ahead of your average corporate computer room, even the datacenters of the smallest hosting providers. Firstly because that is Amazon’s business: a security problem revealed in their infrastructure would have immediate implications in terms of user reactions (and thus in terms of business ;ob). It is therefore an essential detail, especially as Amazon have to prove themselves in this sensitive area and they are therefore obliged to do their best to win their customers over. Furthermore, the sheer size of their structure enables them to pool their investments in security and make them pay for themselves: this is not conceivable for the smallest companies, or companies who do not specialize therein. Amazon therefore has the means and the obligation to ensure security.

What provokes my scepticism is that Cloud is not easily audited. You have to have faith. It is no more risky than placing your trust in a traditional hosting provider, or in your own internal teams… But it’s brand new! So be careful! A normal reaction. But perhaps this is exactly an opportunity for us to work on security at our own level, something often neglected, due to over-confidence or lack of interest. The first task is to encrypt the information: for stored data as well as data in transit. Remember to take into account the CPU overhead encryption/decryption procedures. The second is to fully understand the various security mechanisms of Amazon’s services:

AWS Multi-Factor Authentication

• Access Credentials: Access Keys, X.509 Certificates & Key Pairs
• Sign-In Credentials: E-mail Address, Password & AWS Multi-Factor Authentication Device
• Account Identifiers: AWS Account ID & Canonical User ID

Next you must select the people who’ll be authorized to access the different security keys.

Conclusion
The facilities provided by Cloud Computing inevitably come with some measure of reduced control and visibility on certain parts of the infrastructure, especially on the network. That’s the price you pay, be it quite negligible, or truly problematic: it all depends on your requirements.

AWS should be viewed as a complete tool, but one which does not excuse you from performing all the best practices or obtaining all the standard components of an infrastructure: log server, monitoring, BCP, configuration manager, etc. All these elements are and will continue to be your responsibility. One mustn’t have too naïve an expectation: as AWS offers HaaS and IaaS, you will still need a competent systems administrator, and particularly one who fully understands the AWS architecture (otherwise you might be disappointed) – if you switch to GAE (Google App Engine), you will still need an architect who fully understands GAE architecture, etc. The business is constantly evolving.

As for AWS security, I am reasonably confident. It must be emphasized firstly that information and data are probably less secure within your own company than entrusted to Amazon (in most cases anyway – I shouldn’t generalize ;ob).  AWS’ exposure on the Net and Amazon’s commitment to the business imply that Amazon take security very seriously. Furthermore, you are responsible for a large part of this security (management of the keys, etc.) and believe me, that is surely the most risky feature. When it comes to transferring and storing data, think “encryption”.

Frédéric FAURE @Twitter @Ysance

One year already!
Firstly allow me to direct you to a previous article I wrote on this subject nearly a year ago: Outlook is Cloudy … So much the better! (French version). I won’t paraphrase what I have already explained, purely in the spirit of DRY (Don’t Repeat Yourself :o))  and I will capitalize on the experience I have gained in this topic over the past year (Cloud Computing in general and AWS – Amazon Web Services – in particular), to answer some legitimate questions I have encountered since then.

The Framework

Cloud
As a reminder, there are several types of Cloud possibilities and I will stick with the AWS types which are infrastructure-oriented services, rather than the Google-type services (GAE – Google App Engine), to mention just one, which offers a running environment for your web applications developed with the APIs provided (similar to a framework). In fact, regarding the latter, we can’t speak for clients (they are the ones holding the credit card) about infrastructure management, because we upload our application using the APIs provided and leave the entire infrastructure management to the service provider. It doesn’t mean it’s less about Cloud computing, but simply about a Cloud service that’s more PaaS-oriented than infrastructure-oriented.

Several abstraction layers: each editor directs its service to one or more layers.

Physical infrastructure
As far as physical infrastructure is concerned, I will examine the notion of self-hosted infrastructure and equally the notion of infrastructure supported by a hosting provider. Similarly, I’ll also look at infrastructures based directly on hardware, as well as those based on virtualized environments. Cloud computing is also based on virtualization, but we are not so interested in that technology here, rather the way in which it is provided to clients (you). In fact, you can simply start up instances via a console, as you do for EC2s if you have an ESX (VMware) for example, but it involves “only” a hypervisor which partitions the physical servers into several virtual computers. You will still have to take care of buying equipment (blades, etc.), configuring the network, etc. But we will come back to these details later.

Cloud computing = Systems administrators marked down?
Yes, the sales are on! Are you looking for a sweater, a jacket, … a systems administrator? I have often come across people who think that Cloud (in the case of AWS) will enable them to get by without an experienced systems administrator, and to build an infrastructure with inferior competence. The answer is obvious: WRONG!

Perhaps a clever sales pitch can convince you that the various services are so user-friendly, you can do it all yourself, and that prepackaged AMIs (Amazon Machine Image) will make life easy, but it goes without saying that once you have started up the EC2 instances, you connect to the computers (SSH / port 22 for Linux and TSE / port 3389 for Windows), then you have to set the parameters, do the fine-tuning, etc.

What applies to systems administrators faced with AWS applies equally to systems architects in the context of Cloud computing services providing access to higher layers (PaaS like Google App Engine). A person with experience in the field, able to set up the infrastructure requirement is needed: the tool may change but the skills must still be available. Note however that if you use GAEs, you don’t need a systems administrator for the application. If the Cloud service editor is offering a service in a given layer (HaaS, IaaS, PaaS, etc.), there is no longer any need for people to deal with the lower layers. However, we do accept the framework supplied by the Cloud editor.

The systems administrator cannot be done away with, but his role is changing: he is becoming more and more of a developer. Indeed, being able to pull up resources on the fly will enable infrastructure management to be scheduled and automated via scripts which will call up the APIs provided by Amazon enabling communication with its web services. Everything at Amazon is web service: EC2, EBS, SQS, S3, SimpleDB: the only non-SOAP or REST operations that exist are when you connect directly to EC2 instances that you called up via web service or when EC2 instances dialogue with the EBS that you called up via … I’ll let you guess.

The administrator can then, rather than going into the computer room, add a disk, connect a server (which would be the case with a physical architecture) or else pick up the phone and ask the host to do it (fetch a coffee… call again… take a Xanax or a Prozac pill…  ;ob), request resources via a script in Ruby or Python… You can then take automation of a Cloud infrastructure much, much further, with a set of scripts and tools (see Installing an infrastructure on AWS: Best practices! (French version)).

The systems administrator’s craft is therefore evolving between a physical infrastructure and an AWS-type Cloud infrastructure: he is becoming more and more of a developer. But the systems administrator remains essential nevertheless.

Elastic is fantastic!
As I mentioned earlier, one of the crucial differences between the two types of infrastructure is the flexibility and dynamism provided by the Cloud solution, compared to a traditional physical architecture (whether it is based on virtualization or not). That means the elimination of the time it takes to install and set up the logistics (equipment purchase, installation of the OS, connecting to the network – the physical network and the configuration of the interfaces, etc.). Likewise, when you no longer need an item of hardware (EC2 virtual instance, EBS volume, S3 object, etc.), you return it to the resource pool: it will be reinitialized so that none of your data can be retrieved, and made available again until the next web service call.

You also have complete access to certain elements such as security groups (firewall) set for each instance… And that’s very useful. It’s very practical, particularly compared to a traditional hosting provider: do you remember the last time you had to change the firewall rules?  Would you like a Xanax? Are you sure?  ;ob

But it’s not simply about the pros and cons of purchasing servers versus running instances. AWS are backed by datacenters which are already industrially organized and tested. All the safety standards that need to be met in terms of fire protection, computer cooling, redundant electrical power supply, physical security against break-ins, distributing the hardware across 2 or more physical datacenters for disaster recovery, etc. entail a colossal initial investment and even when everything is installed, you still won’t be able to recreate the same quality within your company (99% of the time, in any case). You can get all that however, or part of it, with a traditional hosting provider.

But there are also all the more software-like services, such as data durability management (redundancy/replication as on the EBS and on S3), accessibility or high availability, monitoring hardware (to be alerted when physical components are showing signs of weakening), procedures for breakdowns, etc. I will let you read The 9 Principles of S3 (French version), so you understand just how many concepts are included. You won’t get all that with a traditional hosting provider (and forget about having it @Home ;ob). The quality of the S3 service is effectively a huge advantage, especially compared to current pricing… Let’s talk about prices!

The cost
There are no fixed rules. With Cloud, you pay for the resource by the hour and when you stop using it, you stop paying. Instances (Linux at the time I’am writing the article, but Windows will come soon) can also be reserved on the AWS for one year or for three years: this is known as Reserved Instances: you pay a one-time fee at the start, and afterwards you pay the hourly usage charge at a discounted rate, which leads you to a tipping point starting from a certain percentage of the resource use over the year (or three years). For more information, click here. To easily calculate how much your infrastructure will cost you, take advantage of the new calculator provided by Amazon: Simple Monthly Calculator. In all cases one part is related to the hourly usage and another to your traffic/volume stored.

Simple Monthly Calculator

You can do the comparison with the cost of your local infrastructure or with that of your hosting provider. The Cloud set price is particularly attractive in the following cases:

• The set price is unbeatable for POCs, demonstrations/presentations or architecture load/validation tests.
• It is very attractive for applications or APIs mounted on an SaaS-type economic model and for which you need to spend money on their resources only when the clients pay to use the abovementioned APIs.
• It is a good price for the social applications found on Facebook, for example, and which can take off overnight thanks to the social media phenomenon and may experience a boom (or a drop) in hits.
• It is also cost-effective when you are launching a new company, or a specific project within a larger entity and you do not wish to invest heavily in logistics right at the start.

For all the many other specific cases among you, you’ll have to do your own calculations.

Slacking off? No, of course not …
Usually, no matter what type of infrastructure you have, the same components and mechanisms should be installed. However, it must be acknowledged that often the cosy aspects of “home”-hosted infrastructure can lead to a certain lack of rigor on many issues. The fact that Amazon, with its AWS, offers a dynamic and volatile solution for these EC2s, compels you to install mechanisms (which should be standard) in order to consider failure or disaster recovery plans more seriously, given the volatile nature of the tool, and to identify the important data with the aim of ensuring data durability (EBS, S3 backups, etc).

Conclusion
The evolving duties of infrastructure management can be clearly seen in this first part: from handling physical resources by means of APIs, underlying mechanisms ensuring data durability, availability of services, etc. right up to server power supply and the physical security of datacenters, all of which are supported transparently. The end result: one should “only” see the API which dialogs with a distant server. That is the difference with physical infrastructures. The virtualization (which is one facet of AWS) that we know and have already been using for some time now, is used by Amazon: it’s not so much a technical revolution  - even though I don’t deny the complexity of the implementation and support that goes into it – as the service offered with it, which provides the real added value.  It is matched with a new ‘pay-as-you-use’ aaS (as a Service) economic model. This has enabled the emergence of some applications (such as the games found on social networks), which only a few years ago would otherwise have been compromised by the initial investment.

We will examine the other aspects differentiating these architectures in my second article on the subject.

Frédéric FAURE @Twitter @Ysance

Missions :

• Installer et administrer des serveurs physiques et virtuels de type Cloud Computing (Amazon Web Services)
• Superviser les serveurs
• Assurer une continuité de service
• Gérer les relations avec Amazon ainsi qu’avec les clients
• Assurer une veille R&D sur les nouveautés du marché
• Mettre en place des PRA

Profil :

Diplômé(e) d’un Bac + 2 à Bac + 5 en administration des réseaux, vous avez au minimum 3 ans d’expérience professionnelle sur un poste similaire. Vous démontrez un intérêt certain pour l’applicatif et connaissez obligatoirement Linux. Une expérience des projets soumis à des contraintes de montée en charge est indispensable.

Autonome, rigoureux(se), doté(e) d’un très bon relationnel et de fortes capacités d’adaptation, vous faites preuve d’un goût prononcé pour la technique. Vos qualités rédactionnelles, votre orientation client et votre empathie seront les clés de votre réussite sur ce poste. La maîtrise de l’anglais est impérative (l’ensemble de la documentation est en Anglais).

Pro-actif(ve), apte à travailler en équipe, passionné(e) de nouvelles technologies, vous souhaitez contribuer à la réalisation de projets ambitieux.

Référencés auprès de grands groupes de tous secteurs d’activités (banque/finance, distribution, services, transport, communication), nous vous proposons dès aujourd’hui de participer à de grands projets, riches techniquement et fonctionnellement.

En rejoignant Ysance, venez découvrir des projets innovants dans un environnement dynamique, à forte valeur ajoutée, et propice à des opportunités de carrière.

A noter :

• Poste basé sur Paris
• CDI à pourvoir rapidement
• Rémunération selon profil

A bientôt !

Frédéric FAURE

Je profite de Decrypt pour annoncer que je donnerai une formation sur les AWS (Amazon Web Services) destinée aux professionnels le Vendredi 11 Juin 2010. Elle se déroulera à Paris en une journée. Cette formation est éligible au financement par les OPCA (Agefos, FAFIEC …), peut être intégrée à une période de professionnalisation ou à un DIF.

La formation sera axée à la fois sur une approche théorique et pratique, avec 30% du temps de formation passé à réaliser des travaux pratiques (sur les composants principaux que sont EC2, EBS et S3, ainsi que manipulation des outils et gestion de compte AWS), et sur une forte interactivité afin de répondre à toutes vos interrogations.

Qui peut y participer ?
Des chefs de projet, architectes techniques et fonctionnels, administrateurs système, responsables d’équipes de développement, directeur/responsable informatique.

Quel est le programme proposé ?

1ère Demi-journée
Le Cloud Computing

• De quoi s’agit-il ?
• Les acteurs du marché et leurs différentes approches (Amazon, Microsoft, Google, …)

Le cas Amazon

• De quoi s’agit-il ?
• Comparaison d’une infrastructure Cloud AWS avec une infrastructure physique classique
• Les cas d’utilisation
• Les coûts

Les outils

• Gestion de son compte (clés, certificats, facturation, support, …)
• Les consoles d’administration (Console AWS, ElasticFox, S3 Organiser)
• Les APIs

2ème Demi-journée
Les services infrastructure AWS

• Elastic Compute Cloud (EC2)
• Elastic Block Storage (EBS)
• Simple Storage Service (S3)
• Séance de TP sur EC2, EBS et S3

AWS… Encore un peu plus loin

• Overview automatisation & dynamisme : gestion de la configuration centralisée avec Puppet, déploiement automatisé avec Capistrano, monitoring avec Cacti & Centreon/Nagios, gestion des logs avec Syslog-NG, auto-scalability, LVM, …

Les informations utiles

• Forums, sites, liens, livres blancs (sécurité, extension SI, …)

Quelles sont les modalités pratiques ?
Lieu : Mediasites, 42 rue Legendre, 75017 Paris – Métro : Villiers
Date : Vendredi 11 juin 2010
Heure : 9h00 à 17h00

Durée : 1 journée
Tarif : 800 euros HT
Toutes les sessions se déroulent dans le centre de Paris. Cette formation est éligible au financement par les OPCA (Agefos, FAFIEC …), peut être intégrée à une période de professionnalisation ou à un DIF. Nous pouvons vous aider à monter votre dossier.

Pour vous inscrire, veuillez remplir ce formulaire.

Pour plus d’informations, veuillez contacter Catherine LHUISSIER à catherine.lhuissier@ysance.com.
Tél. : 01 83 62 11 58

En espérant que vous viendrez nombreux. :o)

Frédéric FAURE @Twitter @Ysance

Réseau et ressources partagées

Un point important que le réseau… Et à plus d’un titre ! Effectivement, la configuration sur le Cloud est déjà prête, c’est commode. Mais cela implique que vous n’ayez pas la main dessus et par conséquent vous ne pourrez pas le monitorer vous même et donc déceler, par exemple, les causes d’un ralentissement. On note la même opacité en ce qui concerne les ressources partagées au niveau Cloud : il n’est pas possible de définir à notre niveau l’impact que peut avoir l’utilisation par d’autres personnes de la ressource que nous partageons (machine physique sur laquelle repose un EC2, partition d’un disque réseau EBS, bande passante réseau, …). Le monitoring réseau possible se limite en entrée/sortie de l’instance (par exemple un EBS est un disque réseau donc… pas moyen de vérifier l’état de la connectivité, on se contentera des Disk I/O). Le monitoring possible est concentré sur l’instance virtuelle EC2 elle-même (instance gérée par un hyperviseur et reposant sur une virtualisation Xen). La visibilité complète de notre infrastructure n’est donc pas possible au niveau Cloud. Cela est à prendre en compte… Et à accepter si vous souhaitez implémenter votre architecture sur le Cloud. La même opacité est à prendre en compte pour les autres ressources partagées comme citées précédemment (utilisation EBS, …).

AWS : Isolation des Instance EC2 (from aws.amazon.com)

De même, au niveau des protocoles de communication, il n y’a pas de multicast possible, pensez-y dans le cas de certains clusters. C’est une limitation qui se comprend du fait de la portée que peut avoir un multicast mal maitrisé.

C’est le fonctionnement même du Cloud qui veut ça : il y a des facilités qui masquent un certain nombre d’éléments dont vous n’avez plus le contrôle.

Astreintes, monitoring, PRA et pénalités
Une question qui m’a été posée plusieurs fois : « Amazon prend-il en charge des astreintes ? ». La réponse est non. Il faut voir les AWS comme un outil proposé par Amazon qui en assure le fonctionnement et l’évolution des fonctionnalités. En revanche, l’utilisation que vous en faite est à votre charge (de toute façon ils ne possèdent pas les clés privées de vos instances EC2, alors…) : pas monitoring, pas d’astreinte, pas de PRA (Plan de Reprise d’Activité) packagés.

Contrairement aux contrats spécifiques que vous pourrez passer avec vos hébergeurs, il faudra assumer vous même ces éléments, ou, pour des astreintes par exemple, les dédier à des sociétés faisant de l’infogérance. Pour le monitoring idem : le monitoring proposé par Amazon, Amazon CloudWatch, propose des informations (%CPU, bytes read/written sur disque et bytes in/out sur réseau) trop succinctes pour un réel monitoring tel que le ferait un Centreon/Nagios, Cacti, Zabbix ou Munin. Ces informations (celles de CloudWatch) sont utilisées par la fonctionnalité Auto Scaling, mais ne remplacent pas un vrai monitoring. Certains hébergeurs classiques proposent du monitoring intégré à leur prestation.

AWS CloudWatch

Concernant le PRA et les pénalités, cela revient à un hébergement en interne : vous êtes responsables de vos ressources et gérez les reprises sur incident en fonction des possibilités de l’outil (les AWS). C’est là qu’il est important de comprendre l’architecture des services Amazon dans leur globalité : si vous ne comprenez pas le fonctionnement de l’outil, vous ne pourrez mettre en place un PRA efficace. Concernant, les pénalités, rien de notable, il s’agit d’un allégement sur la facture du mois quand vous rentrez dans le cadre de l’indisponibilité du service selon les critères Amazon. Rien à voir avec des pénalités basées sur les montants perdus dûs à l’indisponibilité.

Il faut voir les services web Amazon comme un outil. Malgré, un support payant accessible, vous n’aurez pas les possibilités contractuelles que vous pourriez avoir avec un hébergeur plus classique et, de manière générale, serez responsable de votre architecture à tous points de vue (y compris au niveau de la sécurité de vos instances : ne perdez pas vos clés ! ;ob).

La sécurité
La sécurité… Un point souvent tabou dès que l’on commence à parler de Cloud Computing. Je ne parle pas de l’intégrité des données stockées ou bien de la gestion des accès sur les instances virtuelles à notre charge, je parle de la confidentialité des données stockées sur les différents services (S3, EBS, EC2, SQS, …) ou qui transitent entre lesdits services.

Tout d’abord, le premier point à noter est que le niveau de sécurité dans les datacenters d’Amazon, que ce soit physiquement ou bien informatiquement parlant, sera de toute façon meilleure que dans bons nombres de salles machines d’entreprises, voire de datacenters d’hébergeurs plus petits. Tout d’abord parce que c’est leur fond de commerce : un problème de sécurité dévoilé sur leur infrastructure aurait des implications immédiates en termes de « ressenti utilisateur » (et donc de business ;ob). C’est donc un point essentiel, surtout qu’ils ont tout à prouver dans ce domaine sensible, ils sont donc obligés de faire le maximum pour convaincre. En plus, l’importance de la taille de leur structure leur permet de mutualiser et de rentabiliser les coûts investis dans ce domaine, ce qui n’est pas envisageable pour de plus petites entreprises, ou des entreprises dont ce n’est pas le métier. Amazon a donc la possibilité et l’obligation de se soucier de la sécurité.

Ce qui amène ce scepticisme, c’est que le Cloud est difficilement auditable. Il faut faire confiance. Ce n’est pas plus risqué que de faire confiance à un hébergeur classique ou bien de faire confiance à ses équipes en interne… Mais c’est nouveau ! Alors méfiance ! C’est une réaction normale. Mais c’est peut-être l’occasion de travailler justement sur la sécurité au niveau sur lequel nous avons la main, chose qui est parfois laissé de côté par excès de confiance ou désintéressement. La première chose est de crypter les informations, autant celles stockées que celles qui transitent. Attention à prendre en compte le surcoût CPU des traitements liés au cryptage/décryptage. La seconde est de bien comprendre les différents mécanismes de sécurité des services Amazon :

AWS Multi-Factor Authentication

• Access Credentials: Access Keys, X.509 Certificates & Key Pairs
• Sign-In Credentials: E-mail Address, Password & AWS Multi-Factor Authentication Device
• Account Identifiers: AWS Account ID & Canonical User ID

Il faut ensuite identifier les personnes qui pourront avoir accès aux différentes clés de sécurité.

Conclusion
Les facilités apportées par le Cloud Computing sont obligatoirement accompagnées d’une maitrise et d’une visibilité moindres sur certaines parties de l’infrastructure, surtout au niveau réseau. C’est le prix à payer qui peut être tout à fait négligeable ou réellement problématique : tout dépend de vos besoins.

Il faut voir les AWS comme un outil complet, mais qui ne vous exemptera pas de toutes les bonnes pratiques et de tous les composants standards d’une infrastructure : serveur de logs, monitoring, PRA, gestionnaire de configuration, … Tous ces éléments sont et resteront à votre charge. Il ne faut pas avoir une vision trop naïve : les AWS proposant des services HaaS (Hardware as a Service) et IaaS (Infrastructure as a Service), vous aurez toujours besoin d’un administrateur système compétent et surtout qui aura bien compris l’architecture des AWS (ou vous risquez d’aller vers des déconvenues), si vous passez à GAE (Google App Engine), vous aurez toujours besoin d’un architecte qui aura bien compris l’architecture des GAE, … Le métier évolue.

Concernant la sécurité, je suis plutôt confiant. Il faut souligner d’abord que les informations sont probablement moins sécurisées chez vous que chez Amazon (enfin bien souvent, pas de généralités ;ob). L’exposition des AWS sur le Net et l’engagement d’Amazon dans ce business impliquent qu’Amazon prenne ce sujet très au sérieux. De plus, vous êtes responsables d’une bonne partie de cette sécurité (gestion des clés, …) et, croyez moi, c’est sûrement le point qui sera le plus risqué. Concernant le transfert et le stockage des données, pensez chiffrement.

Frédéric FAURE

Déjà un an
Je me permets tout d’abord de vous orientez vers un précédent article que j’ai écrit il y a maintenant près d’un an sur le sujet : Un avenir nuageux… Et c’est tant mieux !. Je ne paraphraserai pas ce que j’ai déjà expliqué précédemment dans une optique purement DRY (Don’t Repeat Yourself :o)) et profiterai de cette année d’expérience supplémentaire sur le sujet (le Cloud Computing en général et AWS – Amazon Web Services – en particulier) pour répondre aux interrogations légitimes que j’ai croisées depuis.

Le cadre
Le Cloud
Pour rappel, il y a plusieurs types d’offres au niveau du Cloud et je vais m’attacher à celles de type AWS qui sont des offres orientées infrastructures plutôt que des offres de type Google (GAE ou Google App Engine), pour ne citer que lui, qui propose un environnement d’exécution pour vos applications web développées avec les APIs mises à disposition (un framework en quelque sorte). En effet, dans le dernier cas, on ne peut pas parler au niveau client (nous qui mettons la carte bleue) de gestion d’infrastructure puisque nous uploadons notre application utilisant les APIs fournies et laissons l’intégralité de la gestion de l’infrastructure au fournisseur du service. Il ne s’agit pas moins de Cloud Computing, mais simplement d’une offre de Cloud orientée « PaaS » plutôt que infrastructure.

Plusieurs couches de virtualisation : chaque éditeur oriente son offre vers une ou plusieurs couches.

L’infrastructure physique
Concernant l’infrastructure physique, je considère autant l’infrastructure hébergée soi-même que celle prise en charge chez un hébergeur spécialisé. De même, je considère autant les infrastructures reposant directement sur l’OS de la machine que celles reposant sur des environnements virtualisés. Le Cloud repose également sur de la virtualisation, mais ce n’est pas la technologie qui nous intéresse ici, mais la manière de la mettre à disposition des clients (vous). En effet, vous pourrez démarrer simplement des instances via une console, comme pour les EC2, si vous avez un ESX (VMware) par exemple, mais il s’agit « uniquement » d’un hyperviseur qui partitionne les serveurs physiques en plusieurs machines virtuelles. Vous aurez donc toujours les problématiques d’achat de matériel (lames, …), de configuration du réseau, … Mais nous entrerons dans ces détails plus tard.

Le Cloud Computing = Administrateurs Systèmes en solde ?
Et oui, c’est la période des soldes ! Un pull, une veste, … Un administrateur système ? Plusieurs fois, j’ai croisé des gens pensant que le Cloud (dans le cas des AWS) allait permettre de se passer d’administrateurs systèmes expérimentés et de pouvoir monter une infrastructure avec des connaissances moindre. La réponse est claire : C’est complètement faux !

Peut-être qu’un discours commercial mettant en avant la facilité d’utilisation des différents services laisse envisager cette éventualité et que des AMIs (Amazon Machine Image) déjà prépackagées vont nous faciliter la vie, mais il n’en reste pas moins que une fois les instances EC2 démarrées, vous vous connectez aux machines (SSH / port 22 pour Linux et TSE / port 3389 pour Windows) et vous devez les paramétrer, les tuner, …

Ce qui est vrai pour l’administrateur système dans le cadre des AWS est aussi vrai pour les architectes dans le cadre de services de Cloud Computing proposant l’accès à des couches plus hautes ( « PaaS » comme Google App Engine, …). Il y a besoin d’une personne connaissant le métier et pouvant mettre en place le besoin en termes d’infrastructure : l’outil change, mais les compétences doivent toujours être là. A noter tout de même que si on utilise les GAE, il ne sera pas nécessaire d’avoir un administrateur système pour l’application elle-même. Si l’éditeur de service Cloud propose un service dans une couche donnée (HaaS, IaaS, PaaS, …), il n’y a plus besoin des personnes s’occupant des couches inférieures. Cependant, on accepte le cadre fournit par l’éditeur de Cloud.

L’administrateur système reste incontournable, mais il évolue : il devient de plus en plus un développeur. En effet, la possibilité de lever des ressources à la volée va permettre d’ordonnancer, d’automatiser, la gestion de l’infrastructure via des scripts qui feront appel aux APIs mises à disposition par Amazon permettant de communiquer avec ses services web. Tout est service web chez Amazon : EC2, EBS, SQS, S3, SimpleDB, …), les seules opérations non SOAP ou REST est lorsque vous vous connectez directement aux instances EC2 que vous avez levées via service web ou que les instances EC2 dialoguent avec les EBS que vous avez levés via… Je vous laisse deviner.

L’administrateur peut alors, plutôt que d’aller en salle machine, ajouter un disque, brancher un serveur, … (ce qui serait le cas dans une architecture physique) ou bien prendre le téléphone et demander à l’hébergeur de le faire (prendre un café… Appeler de nouveau… Prendre un Xanax ou un Prozac… ;ob), demander l’obtention de ressources via un script en Ruby, Python, … Il est ensuite possible de pousser beaucoup plus loin l’automatisation d’une infrastructure Cloud via un ensemble de scripts et d’outils (Cf. Mise en place d’une infrastructure sur AWS : best practices !).

Le métier de l’administrateur système évolue donc entre une infrastructure physique et une infrastructure Cloud type AWS : il devient de plus en plus un développeur. Mais il n’en reste pas moins indispensable.

L’Elastic c’est fantastique !
Comme évoqué précédemment, une des différences cruciales entre les 2 types d’infrastructures, c’est la souplesse et le dynamisme apporté par la solution Cloud par rapport à une architecture physique classique (qu’elle repose sur de la virtualisation ou non). C’est à dire la suppression du temps de mise en place de la logistique (achat de matériel, installation de l’OS, raccordement au réseau – physique et configuration des interfaces -, …). De même, quand vous n’avez plus besoin du matériel (instance virtuelle EC2, volume EBS, objet S3, …), vous le rendez au pool de ressources : il est alors réinitialisé afin qu’aucune de vos données ne puissent être récupérées et remis à disposition en attendant un autre appel web service.

Vous avez également un accès total à certains éléments comme les security groups (firewall) appliqués pour chaque machine, … Et c’est très utile. Cela est très pratique, notamment par rapport à un hébergeur classique : rappelez-vous la dernière fois que vous avez dû faire modifier les règles de firewall… Un petit Xanax ? Sûr ? ;ob

Mais il ne faut pas s’arrêter simplement à la notion d’achat de serveurs Vs démarrage d’instances. Derrière AWS, il y a des datacenters déjà montés et éprouvés de manière industrielle. Toutes les normes à respecter en terme de protection contre les incendies, le refroidissement des machines, les alimentations électriques redondantes, la sécurité physique contre les intrusions, la répartition des locaux physiques, … comportent un prix initial colossale et même une fois mises en place, vous ne pourrez reproduire une telle qualité chez vous (en tout cas dans 99% des cas). Vous pourrez cependant retrouver cela pour tout ou partie chez un hébergeur classique.

Mais il y a de plus tous les services plus « logiciels » comme la gestion de la durabilité des données (redondance/réplication comme sur les EBS et sur S3), l’accessibilité ou haute disponibilité, le monitoring hardware (à savoir quand est-ce que les composants physiques montrent des signes de faiblesse), les processus en cas de panne, … Je vous laisse lire Les 9 principes de S3, pour comprendre l’exhaustivité des notions que cela regroupe. Tout cela, vous ne le retrouvez pas chez un hébergeur classique (et oubliez cela chez vous ;ob). La qualité du service est en effet un plus incomparable, surtout par rapport aux prix pratiqués… Les prix parlons-en !

Les coûts
Il n’y a pas de règle figée. Au niveau Cloud, vous payez la ressource à l’heure et lorsque vous la relâchez, vous ne payez plus. Il y a également la possibilité de réserver des instances (Linux pour l’instant) sur les AWS à l’année ou pour 3 ans, c’est ce que l’on appelle les Reserved Instances : vous payez un forfait tout de suite et ensuite vous payez le coût horaire moins cher, ce qui vous amène à une bascule à partir d’un certain pourcentage d’utilisation de la ressource sur l’année (ou les 3 ans). Pour plus de détails, allez ici. Pour un calcul simple de combien vous coûtera votre infrastructure, profitez de la toute nouvelle calculatrice mise à disposition par Amazon, le Simple Monthly Calculator. Dans tous les cas il y a une par liée à l’utilisation horaire et une autre liée au trafic.

Simple Monthly Calculator

Vous pouvez effectuer la comparaison avec le coût de votre infrastructure locale ou bien avec ce que vous coûte votre hébergeur. La formule Cloud est notablement intéressante dans ces cas là :

• La formule est imbattable pour les POCs, les démonstrations/présentations ou bien les tests de charge/validation d’une architecture.
• Elle est très intéressante pour les applications ou APIs montées elles mêmes sur un modèle économique de type SaaS et qui ne nécessitent de dépenser de l’argent pour leurs ressources qu’à partir du moment où des clients paient pour utiliser lesdites APIs.
• Elle est intéressante pour les applications sociales que l’on trouve sur FaceBook, par exemple, et qui peuvent connaître un succès du jour au lendemain en profitant de phénomènes de viralité et voir leur fréquentation exploser (ou baisser).
• Elle est intéressante également lorsque l’on lance une société ou que l’on débute une activité ou un projet spécifique au sein d’une entité plus importante et que l’on ne souhaite pas un fort investissement immédiat dans la logistique.

Il vous faut pour les nombreux autres cas propres à chacun, faire votre calcul personnel.

Laxisme ? Mais noooooooon…
Normalement, quelque soit le type d’infrastructure, les mêmes composants/mécanismes devraient être mis en place. Cependant, force est de constater que bien souvent le côté plus douillet de l’infrastructure hébergé « à la maison » pousse à une certaine forme de laxisme sur un certain nombre de points. Le fait que Amazon, avec ses AWS, propose une solution volatile et dynamique au niveau de ces EC2 oblige à mettre en place des mécanismes (qui devraient être standards) afin de prendre en compte plus sérieusement, du fait de la volatilité de l’outil, les plans de reprise sur incident et identifier les données importantes afin d’assurer leur durabilité (EBS, backups sur S3, …).

Conclusion
On perçoit dans cette première partie l’évolution du métier de responsable d’infrastructure : la manipulation des ressources physiques se fait par le biais d’APIs, les mécanismes sous-jacents assurant la durabilité des données, la disponibilité des services, … jusqu’à l’alimentation électrique des serveurs et la sécurité physique des datacenters sont pris en charge de manière transparente. Au final, on ne voit « plus que » l’API qui dialogue avec un service distant. C’est là qu’est la différence avec les infrastructures physiques. La virtualisation (qui est une des facettes des AWS), que nous connaissons et utilisons déjà depuis quelques temps maintenant, est utilisée par Amazon : ce n’est pas tant une révolution technique, même si je ne doute pas de la complexité de mise en oeuvre derrière, c’est surtout le service offert qui est la vraie valeur ajoutée. Cela est accompagné d’un nouveau modèle économique aaS (as a Service) qui nous fait payer à l’utilisation. Cela permet à des applications (par exemple de type jeux que l’on retrouve sur les réseaux sociaux) de voir le jour, alors qu’il y a quelques années, leur émergence aurait été compromise par l’investissement initial.

Nous verrons les autres aspects différenciant ces architectures dans un second article sur le sujet.

Frédéric FAURE

Windows Azure, un système d’exploitation sur le cloud

Windows Azure est un système d’exploitation pour le cloud aux fonctionnalités limitées. Il permet de faire tourner des applications et de stocker des données. Il est facile d’augmenter une capacité de stockage ou d’exécution d’une application : bien entendu, le code de l’application doit aussi être prévu pour. Windows Azure prend en chargre la répartition de charge si il y a plusieurs instances de l’application.

L’environnement d’exécution de Windows Azure : la Fabric
La Fabric est le nom donné à l’environnement d’exécution. Elle peut héberger deux types d’applications, nommés « roles » : les web roles et les worker roles. Les web roles sont des applications à l’écoute de requêtes, comme les sites web ou autres applications web traditionnelles. Ceux-ci tournent sous IIS 7. Les worker roles sont des applications qui tournent en tâche de fond. Les instances des différents rôles sont gérés par la Fabric. La Fabric suit les indications fournies par l’utilisateur dans le fichier de configuration du service.

Le système de stockage de Windows Azure : Azure Storage Services
Azure Storage Services regroupe trois services de stockage de données : le blob storage service, le table storage service et le queue storage service. Le blob storage est l’équivalent du système de fichier. Il permet de stocker des fichiers. Pour les fichiers volumineux, il est prévu de pouvoir envoyer ou de récupérer les fichiers par parties. Il est possible d’associer des métadonnées à ces fichiers. Un service de cache (CDN), améliorant la rapidité d’accès partout dans le monde, est aussi proposé: c’est le Windows Azure Content Delivery Network. Ce service ne peut par contre être appliqué qu’aux fichiers publics puisque leur accès n’est soumis à aucune authentification. L’Azure Blob explorer offre une interface assez proche de l’explorateur de fichiers de Windows. Le table storage permet de stocker des données structurées, mais pas de manière relationnelle. Les tables contiennent des entités qui elles-mêmes contiennent des propriétés. Une table peut contenir des millions d’entités réparties physiquement sur plusieurs serveurs. Le queue storage est l’équivalent de Microsoft Message Queuing. Il permet de gérer une queue de messages, et donc une transmission asynchrone de messages. Ces trois moyens de stockage supportent une API REST, ce qui assure une large interopérabilité. L’intégrité des données est garantie par une triple sauvegarde des fichiers. L’accès est sécurisé grâce à une clé à fournir au moment de la requête.

Développer pour Windows Azure
Chaque compte sur Windows Azure offre un environnement de test et un environnement de production. Pour déployer une application, il faut uploader un fichier .cspkg et le fichier xml de configuration du service .cscfg sur le portail d’administration de son compte Windows Azure. Le fichier .cspkg est en fait un répertoire encrypté et zippé contenant le code de l’application. Le déploiement se fait d’abord sur l’environnement de test. Le passage du test à la production se fait grâce à un bouton sur la page d’administration. Le fichier de configuration est accessible et modifiable en ligne après le déploiement. Une API REST est dipsonible pour gérer certaines opérations de déploiement.

Le développement pour Windows Azure est particulièrement bien intégré avec les outils Microsoft existants, et notamment Visual Studio. Il existe déjà des templates de projet pour le cloud. Microsoft fournit un SDK de développement pour le cloud. Le framework .NET de développement reste le même. Ce SDK ajoute simplement quelques classes et facilite l’intégration dans Visual Studio. Associé à Visual Studio, il permet de simuler plusieurs instances de l’application tournant simultanément et de simuler l’accès à l’Azure Storage. Le développement en .NET pour Windows Azure impose cependant quelques contraintes : le code doit être compilé et ne doit pas faire appel au système de fichier traditionnel.

Windows Azure est ouvert aux applications écrites dans d’autres langages, tant que ceux-ci supportent le FastCGI, comme par exemple PHP, Ruby, Perl ou Python. Il faut pour cela activer l’utilisation de FastCGI, indiquer l’interpréteur utilisé dans le webrole.config et configurer le module de FastCGI de IIS 7 dans le web.config. Voici un lien indiquant la procédure à suivre.

SQL Azure

SQL Azure est un service de base de données sur le cloud qui s’appuie largement sur les technologies de Microsoft SQL Server 2008, mais n’assure pas de compatiblité ascendante au niveau des types de données. C’est à dire que les types de données et instructions dépréciés (deprecated) dans SQL Server 2008 ne sont pas supportés : ce sont des instructions et surtout des types SQL qui existaient en SQL 2005 ou 2000 et qui ne pourront plus être utilisés avec Azure. Pratiquement toutes les opérations autorisées sur une base de données classiques sont disponibles, à l’exception des fonctionnalités ne relevant pas de l’objet base de données lui-même, mais plutôt de l’administration de serveur. Ainsi, il n’est pas possible de synchroniser ou de répliquer des bases de données, ce qui aurait d’ailleurs peu d’intérêt puisque Microsoft assure qu’il ne peut y avoir de rupture de service (haute disponibilité), les instances de base de données étant toutes répliquées (assurant ainsi également la durabilité de l’information). Le relais s’effectue automatiquement en cas de crash d’un serveur. L’accès à SQL Azure se fait grâce à un driver ODBC, le framework ADO .NET ou pour PHP via le driver PHP SQL Server. L’appel à la base de données reste assez classique, moyennant quelques contraintes. Par exemple, l’authentification Windows n’est pas acceptée, ni l’utilisation du MultipleActiveResultSet de SQL Server. Des outils d’administration apparaissent, tel qu’un Assistant à la migration de SQL Server vers SQL Azure ou un Outil de visualisation de données.

.NET Services

Les .NET Services offrent des fonctionnalités standards mais avec un large scope d’application : le Service Bus et le Access Control Service.

Le Service Bus
Le Service Bus permet de connecter de manière sécurisée des services ou des applications Windows Azure et des bases SQL Azure avec d’autres applications et bases existantes, selon différents modèles de communication au travers du cloud, et de s’affranchir ainsi d’un certain nombre de problématiques réseau. Il s’agit du fonctionnement standard d’un bus de communication où l’application émettrice s’enregistre auprès du Service Bus avec une adresse de service du type

sb://MyApp.servicebus.windows.net/Services/MyFirstService

Ainsi, tous les messages envoyés sur cette adresse seront redirigés vers les applications qui y auront souscrit. Vous pourrez trouver les différents modèles de communication (unicast et multicast, connexions bi-directionnelles, émetteurs et récepteurs multiples, …) sur la page du service.

L’Access Control Service
L’Access Control Service permet de sécuriser l’utilisation d’applications par la mise en place de règles d’authentification et d’autorisation. C’est un système d’identité fédérée basé le projet Geneva de Microsoft. L’application demande une créance ( « claim » ) à son utilisateur, si celui-ci ne l’a pas il ne peut pas utiliser l’application.

La séquence d’obtention est la suivante :

1. l’application cliente demande à utiliser une fonctionnalité du service
2. le service lui demande le claim correspondant
3. l’application cliente demande le claim à un identity provider
4. l’identity provider vérifie son identité et lui fournit le claim
5. l’application cliente présente le claim au service
6. le service vérifie le claim et donne accès à la fonctionnalité

L’identity provider est un service tiers de confiance qui sait qui a droit à quel claim. L’avantage de ce fonctionnement est que l’application ne gère pas des accès selon des utilisateurs, mais selon des claim. La mise en place de ces règles se fait de manière déclarative grâce à des formulaires de saisie dans l’interface d’administration des .NET Services.

Conclusion
Toutes les fonctionnalités proposées sur la plateforme peuvent être utilisées conjointement ou séparément, avec des applications elles-même hébergées dans le cloud ou bien sur votre propre infrastructure physique. Par exemple, pour une application hébergée sur un serveur physique de l’entreprise, il est possible de sauvegarder des données sur SQL Azure et les gros fichiers sur un blob dans le cloud. Il serait également possible d’enregistrer cette application sur le Service Bus et de la rendre accessible uniquement par ce biais qui serait soumis à des règles d’accès.

Il faut signaler que Microsoft a bien préparé son lancement en proposant des versions gratuites de test auprès d’utilisateurs intéressés, ce qui a permis un premier recadrage des fonctionnalités attendues. Il y a déjà un certain nombre de projets autour d’Azure et d’applications de démonstration et de test, et surtout une communauté d’utilisateurs plutôt active. A noter aussi l’existence d’un assez grand nombre de webcasts techniques sur la question. Le Windows Azure Platform Training Kit contient des présentations techniques et des exemples assez éclairants.

Freddy TRANCART