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

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

• Allocation surestimée d’un disque permettant en théorie de subvenir aux besoins futurs du système ce qui occasionne un surcoût.
• Allocation d’un disque pour assurer la pérennité à court ou moyen terme puis migration des données sur un disque plus grand quand le premier sera trop petit. Cette solution va demander un coût élevé en termes de maintenance et d’indisponibilité du système.
• Utilisation de LVM2 (Logical Volume Manager, version 2) pour la gestion des disques. Elle permet de lisser l’augmentation de la quantité d’espace alloué en ajoutant des disques au fur et à mesure des besoins tout en assurant un minimum d’indisponibilité.

Principe de fonctionnement
L’unité de base est le volume physique représenté par un disque (PV : Physical Volume). Un ou plusieurs PV sont nécessaires pour construire un VG (Volume Group). Cette entité va donc fédérer les PV pour mettre leur espace en commun et le rendre disponible pour créer un ou des LV (Logical Volume). C’est le LV qui sera formaté et utilisé comme un disque standard.

Logical Volume Management

Monter un système LVM2
LVM2 est relativement simple à exploiter. Quand on dispose d’un disque physique attaché au système et accessible via les devices habituels (/dev/hdx ou /dev/sdx), il est simple d’ajouter ce disque à un système LVM ou de créer celui-ci.
LVM2 dispose de 3 niveaux de commandes :

• Les commandes destinées à la partie devices physiques qui sont préfixées par « pv » (pvcreate, pvscan, pvs, pvdisplay, pvremove, pvmove, pvchange).
• Les commandes destinées à gérer les « volume group » qui sont préfixées par « vg » (vgcreate, vgdisplay, vgscan, vgs, vgck, vgremove, vgchange, vgimport, vgexport).
• Les commandes destinées à gérer les « logical volume » qui sont préfixées par « lv » (lvcreate, lvmdiskscan, lvs, lvdisplay, lvremove, lvextend).

De plus, il existe une commande de bas niveau, dmsetup, prévue pour la gestion de LVM2, mais elle est réservée aux cas exceptionnels (récupération de données après un crash très grave du système LVM, par exemple).

Pour créer un système LVM2 il suffit d’ajouter un disque physique à la liste des devices utilisables par LVM2 avec la commande « pvcreate » :

pvcreate /dev/sdd

Une fois le device connu par LVM2, on peut le rattacher à un volume group ou créer un nouveau volume group (un système peut comporter plusieurs volume groups) :

vgcreate vg_exemple /dev/sdd (pour la création d’un VG)

vgextend vg_exemple /dev/sde (pour l’ajout d’un PV à un VG existant du nom de « vg_exemple »)

Cette opération a permis d’ajouter des Physical Extents (PE) au VG. Ces PE sont des blocs d’espace disque : le PE est l’unité de calcul de LVM, exprimé en Ko. Une fois cette opération réalisée nous disposons donc d’un VG avec de l’espace supplémentaire que nous pouvons, à loisir, destiner à la création d’un nouveau LV ou à l’augmentation de la taille d’un LV ou aux deux en même temps :

lvcreate -l 10230 vg_exemple -n lv_exemple (va créer une LV du nom de « lv_exemple » sur le VG « vg_exemple ».

Il ne reste plus qu’à formater le LV (ext3, xfs, …). Il faut cependant faire attention au type de Filesystem que l’on y place. Tous les Filesystems ont leurs spécificités et leurs contraintes, certain n’acceptent pas le redimensionnement à la volée, d’autres n’accepteront tout simplement pas la diminution de taille.

Remarque : Il est possible de monter un système Linux bootable sur un volume LVM mais cette opération est délicate et relativement dangereuse à réaliser.

Elasticité et souplesse de la solution
Une fois que nous disposons d’un système comportant LVM2 il est possible ensuite d’ajouter des disques, d’en retirer, de faire migrer les données d’un disque à un autre ou de répartir les données d’un disque vers la place libre du VG dont il fait parti. Toutes ces opérations se font sans stopper les traitements en cours sur un disque (copies de fichiers, base de données… etc). Il est à noter que certaines opérations peuvent avoir un léger impact sur les performances pendant leur déroulement (migration de données). Mais ces opérations sont relativement rapides et ne causeront donc que peu de dérangement.
Seule les opérations d’augmentation et, à fortiori, de réduction de la taille d’un Filesystem peut nécessiter l’arrêt des traitements sur un LV. Cependant, le redimensionnement d’un Filesystem est une opération rapide qui ne dure en général jamais plus que quelques dizaines de secondes.

Fonctionnalités avancées
LVM2 ne s’arrête pas là. Il dispose de fonctionnalités qui vont nous faciliter la vie.

Snapshot
Le Snapshot est un volume logique permettant de prendre une photo à un instant ‘t’ d’un autre volume logique du même volume groupe. Cette photo permettra de travailler sur des données qui ne bougent pas (ex: sauvegarde). De plus le Snapshot ne nécessite pas autant de place que le volume d’origine. On peut considérer qu’il faut réserver 15% de la taille du volume pour un Snapshot. Ces 15% sont destiné à absorber les modifications effectuées sur le volume d’origine ce qui permet de figer le Snapshot. Mais ces 15% ne sont qu’une estimation et il faut adapter cette taille à la quantité prévisible de données écrites pendant l’utilisation du Snapshot.
La principale limite du Snapshot est sa volatilité. Il n’existera plus après un reboot de l’OS.

Stripping
Le principe du Stripping LVM2, à l’instar de RAID0, est de répartir les écritures d’un volume logique sur plusieurs volumes physiques. A la création du volume logique nous devons spécifier le nombre d’unités physiques à utiliser (unités présentes dans le VG). Cette technique permet d’améliorer les performances mais rend LVM plus sensible aux pannes d’un disque. En ce qui concerne les pannes, nous pouvons nous appuyer sur la robustesse des EBS (qui assure la durabilité des données via RAID1) pour garantir un maximum de sécurité à ce sujet.

Mirroring
Tout comme en RAID1, LVM2 propose une solution de mirroring. Ce mirroring s’effectue entre deux VG distincts (donc des disques physiques séparés). Il permet d’ajouter un niveau de sécurité supplémentaire au système LVM2.

LVM2 hors du nuage
Les avantages de LVM2 sont également appréciables dans une infrastructure physique. Dans ce cas, les volumes physiques peuvent être de différentes formes. Nous pouvons aussi bien avoir des disques physiques de différentes technologies que des disques réseau (LUNs dans un SAN, …). La solution de mirroring de LVM2 est appréciable quand le RAID1 n’est pas applicable entre deux unités de stockage.

Conclusion
Vous l’aurez compris, le couple EBS/LVM2 est parfait pour permettre une maitrise au plus juste de la quantité d’espace à allouer et ainsi de mieux maitriser les coûts. Mais ce couple va plus loin en proposant une souplesse d’utilisation et une sécurité en termes de manipulation des unités de stockage. Il offre de plus des fonctionnalités permettant d’améliorer les performances.

Laurent ROUX

Merci qui ?

Merci Puppet !

Pour plus d’informations sur Puppet, vous pouvez également consulter cette rubrique sur Decrypt.

Frédéric FAURE

Capistrano est un produit open source qui permet d’associer des machines à des rôles (exemple : role :web, « frontal1 », « frontal2 ») et d’exécuter une tâche donnée en parallèle sur toutes les machines d’un ou plusieurs rôles. Il permet également de capitaliser les connaissances sur les différentes tâches de l’infrastructure et les rend reproductibles et centralisées, donc fiables. Il se connecte en SSH et donc assure un niveau de sécurité minimum.

Version IPhone
Version IPod

Puppet et Capistrano sont 2 outils ayant pour but de capitaliser les connaissances sur le fonctionnement d’une infrastructure et de l’automatiser de façon à l’homogénéiser et la fiabiliser.

Chacun des outils à son propre rôle et utiliser les 2 est une très bonne solution, Puppet étant attaché au maintient d’une configuration iso à tout moment entre chaque machine d’un même type et Capistrano permettant d’exécuter des tâches plus ou moins complexes en parallèle sur des groupes de machines assignées à des rôles.

Il est également possible en poussant le fonctionnement un peu plus loin, dans un environnement virtualisé par exemple, d’avoir un script qui démarre des machines, installe le client Puppet sur celles-ci, référence les nouvelles machines et accepte les certificats au niveau du Puppet Master, puis redémarre le client, avant de lancer une tâche Capistrano qui déploie la dernière version de l’application à partir de SVN sur les serveurs ne possédant pas encore l’application. En un clic, il est possible de multiplier le nombre de ses frontaux pour absorber un pic de charge par exemple.

Le mot clé est : « automatisation ! »

Frédéric FAURE

L’approche open source du produit lui a permis d’obtenir une diversité de templates via la communauté.
Il est possible de créer ses propres templates pour n’importe quel outil à partir du moment où celui-ci est capable de fournir des statistiques. Il est ainsi même possible de mettre en place des graphiques pour suivre le fonctionnel d’une application par exemple (nombre de visites ou de joueurs connectés, nombre de transactions effectuées, …).

Les templates de graphes que vous créez ou mis à disposition par la communauté peuvent être importés ou exportés via de simples fichiers XML associés à un script (perl, python, …) de récupération d’informations pour le service monitoré à coller dans le répertoire « /scripts » de votre Cacti.

Cacti permet de suivre l’évolution d’une infrastructure et des services proposés au fil du temps et conserve un historique des valeurs capturées permettant de tracer des graphes sur la journée autant que sur le mois ou bien sur l’année. Cacti est basé sur l’outil de log d’informations et de graphe RRDtool.

On peut retrouver Cacti sur son site : http://www.cacti.net/ .
Je vous invite également à consulter son forum http://forums.cacti.net/ sur lequel de nombreuses informations sont mises à disposition par les créateurs et la communauté. Vous y trouverez par exemple des informations sur les plugins ou bien les templates à disposition de l’outil afin de grapher vos services (http://forums.cacti.net/about32151.html, http://forums.cacti.net/about15067.html, …).

Vous pouvez également accéder aux versions IPhone et IPod de ce webcast :

Version IPhone
Version IPod

Graphes sur différentes périodes
Voici le rendu d’un graphe sur différentes périodes :

Thread Scoreboard Apache – Hourly – 1 Minute Average

Thread Scoreboard Apache - Hourly - 1 Minute Average

Thread Scoreboard Apache – Daily – 5 Minutes Average

Thread Scoreboard Apache - Daily - 5 Minutes Average

Thread Scoreboard Apache – Weekly – 30 Minutes Average

Thread Scoreboard Apache - Weekly - 30 Minutes Average

Thread Scoreboard Apache – Monthly – 2 Hours Average

Thread Scoreboard Apache - Monthly - 2 Hours Average

Thread Scoreboard Apache – Yearly – 1 Day Average

Thread Scoreboard Apache - Yearly - 1 Day Average

Frédéric FAURE