Le fonctionnement

Varnish se configure simplement grâce à deux types de fichiers. Le fichier de configuration de Varnish où nous allons définir certains paramètres internes et les fichiers VCL qui permettent de configurer le comportement de Varnish via une sorte de langage de programmation.

Le principe de Varnish s’appuie sur la machine à état suivante :

Varnish permet d’intervenir au niveau de chacun des états pour effectuer des opérations sur HTTP ou sur lui-même. C’est cette finesse d’intervention qui permet à Varnish d’être véloce et complet.

Un client effectue une requête sur une ressource qui n’est pas en cache suivra le cheminement suivant :

Si cette ressource est demandée à nouveau, le chemin suivi change car la ressource est maintenant en cache :

Toutes ces étapes sont symbolisées en VCL par des “procédures standards” (vcl_recv, vcl_fetch, vcl_deliver… etc). Toutes ces procédures sont surchargables et nous pouvons aussi déclarer les nôtres qui seront appelées dans les procédures standards. Le langage VCL ne tolère aucun code orphelin, tout ce qui est déclaré doit être utilisé.

Le Cache

Varnish propose un cache en mémoire et un cache sur disque. Mais il faut faire un choix, les deux ne sont pas cumulables. Le cache accepte à peu près tout ce qui passe dans les mains de Varnish (pages HTML, fichiers statics, flux de données en JSON… etc), à partir du moment où l’on déclare l’objet cachable et qu’il a une TTL.
Le cache est alimenté juste après l’étape “Fetch”, en réalité c’est juste après la récupération de la donnée sur le backend. C’est à cet endroit que l’on va faire toutes les modifications de l’entête HTTP de la ressource cachée. Faire ces modifications au niveau du “Fetch” va permettre de garantir une entrée cache propre (ne pas avoir plusieurs entrées cache car une même ressource va avoir un payload différent). De plus l’objet est stocké dans le cache avec son entête HTTP, il est donc plus efficace de traiter une fois pour toute l’entête et la resservir avec l’objet.
Comme nous le verrons plus loin, la compression d’objet influe aussi sur les performances du cache. Il est préférable de stocker un objet compressé et laisser Varnish le délivrer compressé ou non suivant l’entête “Accept-Encoding”.

La définition correct de la TTL d’un objet pour manager le cache-control est un élément important de Varnish. Nous pouvons contrôler le cache de façon précise en définissant la TTL pour un type de ressource ou pour une url par exemple :

if(beresp.ttl > 0s){
  unset beresp.http.Expires;
  if ( req.backend == backend_S3 ) {
     set beresp.http.Cache-Control = "public, max-age=60";
     set beresp.ttl = 60s;
  } else {
     set beresp.http.Cache-Control = "public, max-age=7200";
     set beresp.ttl = 2h;
  }
}

Ici nous demandons à Varnish de cacher sur 60 secondes tout ce qui vient de le backend “backend_S3” et le reste sera caché deux heures.

Le cache peut se manager de deux façons différentes :

La Compression

Depuis la version 3.0, Varnish a la possibilité de compresser et décompresser des ressources. Cette fonctionnalité est importante pour 3 raisons :

Elle peut être activée simplement en harmonisant l’entête “Accept-Encoding” et en positionnant la variable “do_gzip” au niveau du backend ou de la réponse du backend. Pour le reste Varnish va adapter la réponse (objet compressé ou non) au client en s’appuyant sur le “Accept encoding” de la requête.
Il est bien sûr évident que la stratégie de compression doit être adaptée au type d’objet. On ne compressera pas un objet déjà compressé (gif, jpg…etc) :).

Le Loadbalancing

Varnish peut gérer des backends de tous horizons. Avec des sites de plus en plus chargés, il est capable d’offrir la possibilité de faire du loadbalancing. Varnish dispose de 3 types de loadbalancing qui sont appelés “Director” :

Varnish sait gérer l’éviction d’un backend lorsqu’il est indisponible. Cette fonctionnalité est d’autant plus utile quand nous activons le “probe” sur les backends.

backend server1 {
   .host = "server1.example.com";
   .probe = {
     .url = "/";
     .interval = 5s;
     .timeout = 1s;
     .window = 5;
     .threshold = 3;
   }
}

Varnish dispose aussi d’un mécanisme pour palier complètement à la défaillance d’un backend ou d’un Director. Nous appelons cela “Grace mode” ou “Saint mode”. Ces termes cachent la possibilité de servir un contenu caché même x minutes après la TTL en cas de non réponse d’un serveur. Il est aussi capable d’aiguiller une requête vers un autre serveur répondant correctement quand le serveur cible initial donne des réponses HTTP 500 à cause d’une trop grande charge par exemple.

Reverse Proxy

Nous avons vu que Varnish se place devant toute notre infrastructure. Il va permettre de masquer complètement l’architecture déployée en utilisant toute la puissance de Reverse Proxy qu’il met à notre disposition.

En fait, il nous permet de faire un découplage complet entre l’organisation des URIs d’appels et l’organisation de leurs traitements sur l’infrastructure.

Voici un exemple d’une requête cliente que nous arrivons à aiguiller avec Varnish vers un bucket S3 public du nom de “ressources” et l’aiguillage prend en compte ce qu’il y a dans le nom du host de la requete :

set req.backend = backend_s3;
if(req.url == "/ressources1.xml") {
  set req.url = regsuball(req.http.host,
              "^(?:.*[.])?([a-z]+)[.](?:net|com)$", "/ressource1.\1.xml");
}else if(req.url == "/ressource2.txt") {
  set req.url = regsuball(req.http.host,
              "^(?:([a-z]+)[0-9]*[.])(?:([a-z]+)*[.])[a-z]+$","/ressources.\1.\2.txt");
}
set req.http.host = "resources.s3.amazonaws.com";

backend  backend_s3 {
  .host = "ressources.s3.amazonaws.com";
  .port = "80";
  .connect_timeout = 5s;
  .first_byte_timeout = 3s;
  .between_bytes_timeout = 2s;
  .max_connections = 1000;
}

Sécuriser et nettoyage HTTP

Le protocole HTTP permet d’utiliser plusieurs types de méthodes (GET, POST, DELETE… etc). Ces méthodes peuvent être utilisées de différentes manières pour déclencher des actions spécifiques (cas de services REST) sur les services abrités sur les backends. Or la protection au niveau HTTP de ce genre de services est assez fastidieuse côté serveurs d’applications. Varnish va permettre de filtrer précisément ce qui doit passer et pour quelle utilisation. Nous allons donc limiter les effets de bords.
Imaginons que nous avons un service accessible uniquement en GET /service1/ et un deuxième /service2/ accessible lui en GET et POST nous allons écrire quelque chose comme ceci :

if (req.request != "GET" && req.request != "POST"){
  call error;
}

if (req.url ~ "^/service2"){
call service2;
}

if(req.request == "POST"){
  call error;
}

if (req.url ~ "^/service1"){
  call service1;
}

call error;

Dans cet exemple nous interdisons systématiquement tout ce qui n’est pas méthode GET ou POST. Ensuite pour une url qui commence par /service2 nous allons vers la routine qui va traiter le payload pour ce service. Puis nous bannissons la méthode POST et nous traitons les urls avec /service1 et enfin nous bannissons le reste.

Avec cette méthode aucune requête non prévue peut remonter vers un backend. Nous avons deux avantages :

Dans un deuxième cas de figure il peut être intéressant de normaliser les entêtes HTTP. Prenons l’exemple de l’Accept-Encoding. Varnish préconise de le normaliser ainsi :

if (req.http.Accept-Encoding) {
  if (req.http.Accept-Encoding ~ "gzip") {
    set req.http.Accept-Encoding = "gzip";
  } elsif (req.http.Accept-Encoding ~ "deflate") {
    set req.http.Accept-Encoding = "deflate";
  } else {
    remove req.http.Accept-Encoding;
  }
}

Tout simplement pour éviter de créer des entrées cache différentes pour un même payload uniquement parce que tous les clients n’écrivent pas cet entête de la même façon.

Nous pouvons aussi enlever certains headers qui peuvent donner trop d’informations sur l’infrastructure. Pour S3 par exemple nous allons passer ces commandes dans le fetch :

unset beresp.http.x-amz-id-2;
unset beresp.http.x-amz-request-id;
unset beresp.http.x-amz-meta-s3cmd-attrs;
unset beresp.http.x-amz-meta-s3fox-filesize;
unset beresp.http.x-amz-meta-s3fox-modifiedtime;

Ou positionner des entêtes plus personnelles :

set beresp.http.Server = « ServeurPerso »;

La dernière petite chose à penser pour le nettoyage réside dans le positionnement d’un content-type correct pour toutes des ressources. Cette opération se fait de la même manière que pour le nettoyage des headers en positionnant “set beresp.http.Content-Type” par groupe de ressources.

De par ces fonctionnalités, Varnish est capable d’assurer l’orchestration de la haute disponibilité d’une architecture. Il est capable de détecter les backends défaillants et même de les remplacer en s’appuyant sur son cache. Il va les protéger en prenant en compte une grande partie de la gestion des erreurs 404.

Uniformisation des Logs d’accès

Le process “varnishd” ne produit aucun log. Il se contente d’écrire les informations dans des segments de mémoire partagée. Ces segments sont consommés par des outils comme varnishadm, varnishlog ou encore varnishncsa. C’est principalement varnishncsa qui nous intéresse. C’est ce process qui va lire les informations et créer un fichier de log au format NCSA. L’avantage ici est énorme. Nous pouvons décharger les serveurs d’applications et front http de la production de ces logs. De plus ces logs seront moins éparpillés (quoi que, avec l’utilisation de syslog-ng ça ne soit pas un problème). Enfin les logs seront tous normalisés qu’ils soient sur Apache, Tomcat, JBoss ou encore lighttp et NginX. Nous pouvons donc penser uniquement aux traitements que nous allons bien pouvoir leur faire subir et ne plus passer du temps à tout reformater. Cette considération prend tout son sens quand on commence à atteindre plusieurs gigas de logs d’accès par jour.
Depuis la version 3.0, Varnishncsa permet de ne pas suivre la norme NCSA et nous laisse le choix du format de sortie.

Laurent ROUX

Le but de cet article est de montrer comment avoir un référentiel des instances disponibles sur un compte Amazon (ou autre) avec toutes les informations qui vont bien sans devoir utiliser la console web Amazon. Cette solution permet de pousser l’automatisation un cran plus loin en proposant une liste exhaustive que l’on peut automatiser et la possibilité d’avoir une liste des serveurs disponibles en une ligne de commande pour n’importe quel Devops allergique aux opérations sur navigateur web.

Dans le but de rester élastique dans la démarche, nous allons utiliser deux fonctionnalités DNS des plus intéressantes qui sont :

Nous allons aussi nous aider des API Amazon et tout ça dans un environnement Linux. Notre DNS va donc servir de base de données pour référencer les machines via leurs IP privées.

Liste des pré-requis

Un serveur T1-Micro sur Amazon servant de DNS est largement suffisant. Le package BIND9 doit être installé. Sachant que sur une infrastructure nous préférons utiliser des noms à la place des IP, l’utilisation d’un DNS est fortement conseillée. De plus, la configuration des différents éléments techniques d’une plate-forme est nettement plus souple en utilisant des noms.

Configuration

Pour effectuer des requêtes nsupdate sur un DNS il faut autoriser les IP des machines qui ont le droit d’émettre ces requêtes vers notre DNS (nsupdate et axfr). Ensuite il faut placer les bases du DNS (fichiers db.xxx) dans un endroit ou le process bind a le droit d’écrire. Pour des raisons de sécurité, il est hors de question que ce process puisse avoir un accès en écriture dans le répertoire /etc/ nous allons donc déplacer ces fichiers dans /var/cache/bind/.

Elements de Configuration DNS

Dans le fichier named.conf.local dans la section de la zone que nous voulons contrôler il faut ajouter l’ip de la machine autorisée à faire les requêtes nsupdate :

allow-update { xxx.xxx.xxx.xxx; };

Les requêtes AXFR sont autorisées dans ce même fichier de configuration en ajoutant l’ip des serveurs autorisés dans la sections “allow-transfer” de la zone.
Dans cette même section nous allons déplacer le fichier de la zone en modifiant son chemin :

file « /var/cache/bind/db.xxxx.yyyy »;

Démarche

Une fois cette opération réalisée nous pouvons utiliser les API Amazon pour récupérer les informations qui concernent une instance (par exemple, nous utiliserons ec2-describe-instances dont la documentation est à l’adresse suivante :  DOC API).
Les informations que nous allons récupérer (security groupes, Key, EBS ID…..), vont être réorganisées pour ensuite être injectées dans le DNS sous la forme d’enregistrements TXT en plus de l’enregistrement A utilisé pour référencer une adresse.
Pour réaliser une mise à jour automatique du DNS il est préférable d’exécuter une instruction de “delete” avant l’ajout d’un enregistrement. Vu que nous sommes sur un DNS qui sera utilisé pour les zones de notre infrastructure nous allons prendre en compte les trois enregistrements suivants :

Pour enlever les enregistrements précédents (dans le cas ou le serveur est déjà référencé ou pour enlever le serveur).

nsupdate
> server monserverdns.domain.com
> zone domain.net
> update delete monserver.domain.net A
> update delete monserver.domain.net TXT
> update delete zzz.yyy.xxx.www.in-addr.arpa. PTR
> send

Ensuite on enregistre le serveur.

nsupdate
> server monserverdns.domain.com
> zone domain.net
> update add monserver.domain.net 86400 IN A www.xxx.yyy.zzz
> update add monserver.domain.net 86400 IN TXT informations sur le serveur
> update add zzz.yyy.xxx.www.in-addr.arpa 86400 IN PTR monserver.domain.net.
> send

Nous partons du principe que le DNS est bien déclaré au niveau du fichier /etc/resolv.conf.

Une fois tous les enregistrements en place il suffit de passer la commande suivante pour que la liste apparaisse :

dig @ip_du_dns axfr domain.net

sh-3.2# dig @10.211.55.5 axfr test.net
; <<>> DiG 9.7.3-P3 <<>> @10.211.55.5 axfr test.net;
(1 server found)
;; global options: +cmd
test.net. 604800 IN SOA dns. root.test.net. 4 604800 86400 2419200 604800
test.net. 604800 IN NS dns.
test.net. 604800 IN A 10.211.55.5
test.net. 604800 IN AAAA ::1
s1.test.net. 86400 IN A 1.2.3.4
s1.test.net. 86400 IN TXT « tout » « ce » « que » « l » « on » « peut » « dire » « sur » « un » « serveur »
test.net. 604800 IN SOA dns. root.test.net. 4 604800 86400 2419200 604800
;; Query time: 19 msec
;; SERVER: 10.211.55.5#53(10.211.55.5)
;; WHEN: Mon Jan  9 16:03:56 2012
;; XFR size: 7 records (messages 1, bytes 237)

Nous touchons au but. Il suffit maintenant d’exécuter la même commande avec un grep sur “TXT” pour récupérer la liste qui nous intéresse.

Avec la commande suivante nous allons enlever l’enregistrement TXT du DNS :

nsupdate
> server monserverdns.test.com
> zone test.net
> update delete monserver.test.net TXT
> send

sh-3.2# dig @10.211.55.5 axfr test.net
; <<>> DiG 9.7.3-P3 <<>>
@10.211.55.5 axfr test.net;
(1 server found);;
global options: +cmd
test.net. 604800 IN SOA dns. root.test.net. 5 604800 86400 2419200 604800
test.net. 604800 IN NS dns.
test.net. 604800 IN A 10.211.55.5
test.net. 604800 IN AAAA ::1
s1.test.net. 86400 IN A 1.2.3.4
test.net. 604800 IN SOA dns. root.test.net. 5 604800 86400 2419200 604800
;; Query time: 2 msec
;; SERVER: 10.211.55.5#53(10.211.55.5)
;; WHEN: Mon Jan  9 16:15:30 2012
;; XFR size: 6 records (messages 1, bytes 183)

Nous avons donc une base de données (le serveur DNS) qui va nous servir de référence pour y placer toutes les informations des instances tirées des API Amazon.
Cet article n’aborde pas le côté sécurité de bind et ne fait donc pas référence à la gestion de clé pour les requêtes nsupdate.

Laurent ROUX

1. Champ Libre pour l’Open Source
2. La Portabilité dans le Cloud
3. DevOps
4. AWS, l’Unique ?
5. Cloud Privé : Mythe ou Réalité ?
6. Moteur Hybride
7. Infogérance

En vous souhaitant bon visionnage !

Frédéric FAURE @Twitter @Ysance

Urbandive is an immersive view service launched by the French YellowPages which allows you to travel in cities in France thanks to a 360° view. Urbandive focuses on providing high definition pictures and accurate professional and social content. One of the biggest jobs was to enable a fast scalable architecture, because it was really difficult to forecast the traffic load at production time. Traffic load may be influenced if the service receives attention from users as a result of advertising.

Below you will find a summary of the goals we achieve by using a Ruby scheduler built on top of Puppet on AWS to create a complete infrastructure.

Workflow & XTR-Lucid
Our scalability combo is : a home-made Ruby scheduler (XTR-Lucid) to deal with AWS APIs + the Puppet Master to install services and configure EC2 instances and keep them up-to-date during all the production time. This leads to full automation.

Here is the workflow (for the creation step, there are other workflows for stop/reboot/health-check/…) of our automation tool. The dashboard allows you to select a template (which contains the following informations : AMI id, instance type, availability zone, key, list of security groups, list of EBS – from snapshots or not -, …) and to set a name for the instance in the « create » workflow.

This schema gives the general idea of how it works.

To be more accurate and to explain the workflow just a bit :

• The scheduler can be outside or inside of AWS.
• First an action file is put into the TODO directory, by the web application (simple rhtml dashboard) or by the monitoring tool directly. For posting files from the monitoring tool, we will have to define thresholds after some weeks of use of the application. At this time, we have not enough data feedback as we just commenced production.
• The action file is then processed by the scheduler :

1. Connection to AWS and request to start an EC2 instance from the AMI.
2. Scheduler checks that instance is running, EBS (Elastic Block Store) are available, then in-use, and eventually that EC2 TCP stack is up and SSH is OK. Then it connects to the brand-new instance.
3. Puppet client is installed and started, so it sends a certificate request to the master.
4. Puppet client is stopped to avoid any interaction.
5. Connection to the PuppetMaster : update the main files (nodes files of PuppetMaster, « /etc/hosts » file, roles file of Capistrano) and then accept the certificate request of the client.
6. Capistrano updates the « /etc/hosts » file on all instances of our infrastructure as soon as a new EC2 instance comes up (or down), without having to trigger (puppetrun) the simultaneous « pull configuration » of all the Puppet clients.
7. Connection to the new instance.
8. Puppet client is started.
9. Puppet client connects to the master and authenticate. Then it gets what it needs to install and configure the new instance.
10. The installation occurs on the new instance that will be soon available.

• The scheduler doesn’t wait until the instance is fully configured to end the task : installation by Puppet is asynchronous. The scheduler just ends by updating its repository and the monitoring tool.

Technical note 1 : we use Capistrano mainly for application deployment. In the above case (create instance), we use it to update the « /etc/hosts » file on all instances of our infrastructure as soon as a new EC2 instance comes up (or down – it is the same use for stop instance), without having to trigger (puppetrun) the simultaneous « pull configuration » of all the Puppet clients (bad idea ;ob). That’s just a little tip for this workflow.

Technical note 2 : the Ruby scheduler works in asynchronous mode (for security reasons & to be called by other tools – like a monitoring one) by creating action files from the web application in the TODO directory (which can be filled by the monitoring tool for auto-scalability) checked every minute by a CRON which calls the heart of the automation tool.

Technical facts

• We have actually 40 – 50 servers, that’s our base, but we probably will go higher when the traffic will come with marketing campaigns.
• We use Lucid Lynx Ubuntu OS (from a standard AMI powered by Canonical).
• We use the PuppetMaster installed on Apache with Phusion Passenger to increase performances.
• We took Puppet (standard version) right from the Ubuntu repositories packaged in the AMI.

Why using Puppet (and especially on AWS) ?
Consistency & Flexibility
We have multiple services, so we need to be sure that each group of servers is consistent in terms of configuration. If we need to push a quick change on all nodes of a type at a given time, we can even push (trigger « pull », to be more accurate, with puppetrun) this new setting from the PuppetMaster without waiting the pull of Puppet client (30min period) and we are sure that this one is pushed everywere it is needed.
AWS offer AMIs to « snapshot » an instance and clone this one as many as we want. This is very good for developpement, load tests, .. But when we come into production, we cannot build another AMI each time we do a change on a setting and deploy again EC2 instances from the new AMI. We need something flexible to patch our configurations quickly, keeping consistency at all times.

Scalability & Ease
This is a new Internet service which can have a load peak at anytime depending on marketing campaigns. But we have to deal with financial things too. So we keep a base and have to start quickly full configured up-to-date instances within a few minutes. We achieve this by writing a home-made ruby-script-based scheduler (XTR-Lucid) that deals with AWS APIs to launch/stop EC2, add EBS (empty or from snapshot), add/remove to/from ELB, add/delete the new/old host to/from our monitoring tool, … AWS EC2 instances are kept in a repository on our Ruby scheduler. Then our tool lets Puppet take over which ensures for each brand-new instance started from a standard Lucid Lynx AMI that all services, configurations, security rules are installed/applied. So with the feedback of our monitoring tool, the infrastructure can grow and decrease alone (depending on the thresholds set) or we can deploy and stop instances in just one click on our web dashboard.

Operating
In such a project, there is a lot of various services to monitor for the Ops team (And… Yes ! Ops team is always essential, even with automated infrastructure ! :o)). So this is important to capitalize upon knowledge in Puppet descriptors and XTR-Lucid repository and templates, so that by simply reading the descriptors/repository/templates, the whole team knows all what it needs to know at a glance (no need to look everywhere). Things become a lot easier.

Portable Infrastructure
Because of the diversity of services run in the project, maybe not all will fit into AWS in a long term experience (over one year). Once we have real-life feedback on traffic, some services will stay on AWS, others, maybe, will migrate into our physical datacenter. So it will be easier to migrate because all the configuration is concentrated in Puppet descriptors. This enables us to re-deploy easily a brand-new infrastructure on another plateform (even if it is not in the Cloud).

I hope you enjoyed this. You can find here some more information on the way the Ops job is evolving, based on this experience (among others) : Solutions Linux / Open Source 2011 – Le métier de l’Administration Système avec le Cloud Computing (FR). These slides are the ones used for a talk I gave at Solution Linux 2011 (France).

Frédéric FAURE @Twitter @Ysance

De retour du salon Solutions Linux / Open Source 2011 (salon professionnel annuel dédié aux logiciels et solutions libres pour les entreprises), je publie les slides que j’ai présentés en compagnie d’Omer SHALA (Mappy) lors d’une des conférences du salon ayant pour sujet le Cloud Computing. Cette présentation porte sur l’évolution du métier de l’Administration Système avec l’utilisation du Cloud Computing. Nous avons pris comme support notre expérience du projet UrbanDive, le nouveau service de vue immersive en zone urbaine du groupe PagesJaunes.

Omer SHALA, responsable de l’infrastructure du projet, a tout d’abord exposé le contexte du projet, puis a expliqué les éléments de décision qui nous ont amené à choisir le Cloud Computing (et en l’occurrence les Amazon Web Services – AWS) pour mettre en place nos services. Il a finalement fait une synthèse de son expérience de la mise en place de cette infrastructure avec les services d’Amazon (de type IaaS – Infrastructure as a Service), par rapport à ses expériences avec des infrastructures plus classiques (en datacenter) au sein du groupe PagesJaunes.

J’ai repris la seconde partie de la conférence et ai exposé ma vision de l’évolution de l’administration système avec l’utilisation de solutions de type Iaas. Pour finir, j’ai présenté ce que nous avons mis en place pour optimiser le potentiel des services Amazon, notamment via l’automatisation :

• avec le développement d’un ordonnanceur Ruby (XTR-Lucid) pour interfacer les APIs proposées par Amazon et gérer les cinématiques de communication (création/suppression d’instances métier EC2 et disque réseaux EBS, déploiement des services, …) avec les AWS,
• avec l’utilisation d’outils Open Source comme le gestionnaire de configuration centralisé Puppet ou bien le scripteur/exécuteur de tâches Capistrano.

Je vous laisse visionner cette présentation en dessous !

Nous avons également inclus dans cette présentation la matrice de décision sur laquelle nous nous sommes basés pour décider de l’adoption du Cloud Computing pour la mise en place de l’infrastructure.

Frédéric FAURE @Twitter @Ysance

Finalement Cohérent – Construire des systèmes distribués et fiables à l’échelle mondiale exige des compromis entre la cohérence et la disponibilité.

À la base du Cloud Computing de Amazon se trouvent des services d’infrastructure tels S3 (Simple Storage Service) de Amazon, SimpleDB, et EC2 (Elastic Compute Cloud), qui fournissent des ressources pour la construction de plateformes de calcul à l’échelle d’Internet et d’une large gamme d’applications. Les exigences imposées aux dits services en infrastructure sont très strictes : ils doivent afficher de bonnes notes dans les domaines de la sécurité, la scalabilité, la disponibilité, la performance et la rentabilité, et ils doivent satisfaire ces besoins tout en desservant des millions de clients dans le monde, de façon continue.

Sous les couvertures, ces services sont des systèmes distribués colossaux qui opèrent à l’échelle mondiale. Cette échelle crée des défis supplémentaires, car quand un système traite des trillions et des trillions de requêtes, des évènements qui ont habituellement une probabilité d’occurrence faible sont désormais certains de se produire, ce qu’il faut prendre en compte dès le début lors de la conception et dans l’architecture du système. Etant donné l’étendue mondiale de ces systèmes, nous utilisons des techniques de réplication partout afin de garantir une performance cohérente et une haute disponibilité. Bien que la réplication nous rapproche de nos objectifs, elle ne peut les atteindre de façon parfaitement transparente ; sous plusieurs conditions, les clients de ces services seront confrontés avec les conséquences d’avoir utilisé des techniques de réplication au sein des services.

Une des façons par laquelle cela se manifeste est dans le type de cohérence des données fournie, surtout quand le système distribué sous-jacent fournit un modèle de cohérence à terme pour la réplication de données. Lors de la conception de ces systèmes à grande échelle chez Amazon, nous utilisons un jeu de principes et d’abstractions directeurs liés à la réplication de données à grande échelle et nous nous focalisons sur les compromis entre la haute disponibilité et la cohérence des données. Dans cet article je présente une partie du contexte pertinent qui a servi de socle à notre approche pour délivrer des systèmes distribués fiables qui doivent opérer à grande échelle. Une version antérieure de ce texte a été publiée sur le blog All Things Distributed en décembre 2007, et a été beaucoup améliorée grâce à l’aide de ses lecteurs.

Une Perspective Historique

Dans un monde idéal, il n’y aurait qu’un modèle de cohérence : à chaque fois qu’une mise à jour est faite, tous les observateurs la verraient. La première fois que ceci s’est avéré difficile était dans les systèmes de bases de données de la fin des années 70. La meilleure « œuvre historique » sur ce sujet est « Notes on Distributed Databases » , par  Bruce Lindsay et al. ⁵ Elle expose les principes fondamentaux de la réplication de bases de données et examine un certain nombre de techniques qui traitent de la réalisation de la cohérence. Plusieurs de ces techniques tentent d’obtenir la transparence de la distribution – c’est-à-dire que, pour l’utilisateur du système, il semble qu’il n’y ait qu’un seul système, au lieu d’un certain nombre de systèmes collaboratifs. Plusieurs systèmes pendant cette époque ont adopté l’approche qu’il était préférable de désactiver le système entier plutôt que de rompre cette transparence.²

Au milieu des années 90, avec l’essor de systèmes d’Internet plus importants, ces pratiques ont été revues. A cette époque, les gens commençaient à considérer l’idée que la disponibilité était peut-être la propriété la plus importante de ces systèmes, mais ils avaient du mal à décider avec quoi ils pourraient faire le compromis. Eric Brewer, professeur de systèmes à l’Université de Berkeley en Californie, et à l’époque le directeur de Inktomi, a réuni différents compromis dans son discours d’ouverture à la conférence PODC (Principles of Distributed Computing) en 2000.¹ Il a présenté le théorème CAP, qui dit que sur les trois propriétés des systèmes de données partagées – la cohérence des données, la disponibilité du système et la tolérance au partitionnement du réseau – seules deux peuvent être garanties à un moment donné. Une confirmation plus formelle se trouve dans un article publié en 2002 par Seth Gilbert et Nancy Lynch.⁴

Un système qui n’est pas tolérant aux partitionnements du réseau peut obtenir la cohérence et la disponibilité des données et le réalise souvent via l’utilisation des protocoles de transaction. Afin d’y parvenir, les systèmes client et de stockage doivent faire partie du même environnement : ils échouent comme un ensemble sous certains scénarios, et à ce titre, les clients ne peuvent observer des partitions. Une observation importante est que dans des systèmes distribués à plus grande échelle, les partitionnements du réseau sont un fait ; ainsi, la cohérence et la disponibilité ne peuvent être obtenues en même temps. Cela veut dire qu’il y a deux choix concernant ce que l’on peut laisser tomber : relâcher la cohérence permettra au système de rester hautement disponible sous les conditions du partitionnement, tandis que privilégier la cohérence veut dire que, sous certaines conditions, le système ne sera pas disponible.

Toutes les deux options exigent que le développeur client soit au courant de ce qu’offre le système. Si le système accentue la cohérence, le développeur doit tenir compte du fait que le système pourrait ne pas être disponible pour accepter par exemple une écriture. Si cette écriture échoue à cause de l’indisponibilité du système, alors le développeur devra décider ce qu’il faut faire des données qui restent à écrire. Si le système souligne la disponibilité, il pourra toujours accepter l’écriture, mais sous certaines conditions une lecture ne reflétera pas le résultat d’une écriture récemment complétée. Le développeur doit décider alors si le client a besoin d’accéder à la toute dernière mise à jour tout le temps. Il existe une gamme d’applications qui gèrent bien des données légèrement périmées, et elles sont bien desservies sous ce modèle.

En principe, la propriété de cohérence des systèmes de transactions telle que définie par les propriétés ACID (atomicité, cohérence, isolation, durabilité) est une sorte de garantie de cohérence différente. En ACID, la cohérence se rapporte à la garantie que quand une transaction est terminée, la base de données est dans un état cohérent ; par exemple, lors du transfert d’argent d’un compte à un autre, le montant total contenu dans les deux comptes ne devra pas changer. Dans des systèmes basés sur ACID, ce genre de cohérence est souvent la responsabilité du développeur qui écrit la transaction mais elle peut être appuyée par la gestion des contraintes d’intégrité par la base de données.

La Cohérence - Client et Serveur

Il existe deux perspectives sur la cohérence. L’une du point de vue développeur/client : comment ils observent les mises à jour des données. L’autre du côté du serveur : comment les mises à jour circulent dans le système et quelles garanties peuvent donner les systèmes concernant les mises à jour.

La Cohérence Client

La cohérence client comporte les éléments suivants :

• Un système de stockage. Pour l’instant on peut le considérer comme une simple boîte noire, mais on devrait supposer que, sous son couvercle, il y a quelque chose à grande échelle et hautement distribué, et qu’il a été construit afin de garantir la durabilité et la disponibilité.
• Le processus A. C’est un processus qui effectue les écritures sur et les lectures à partir du système de stockage.
• Les processus B et C. Ces deux processus sont indépendants du processus A, et ils effectuent des écritures sur et des lectures à partir du système de stockage. C’est sans importance si ce sont réellement des processus, ou plutôt des threads au sein du même processus ; ce qui compte est qu’ils sont indépendants et qu’ils doivent communiquer afin de partager des informations.
  La cohérence côté client concerne comment et quand des observateurs (en l’occurrence les processus A, B, ou C) voient les mises à jour effectuées sur un objet de données dans les systèmes de stockage. Dans les exemples suivants qui illustrent les différents types de cohérence, le processus A a effectué une mise à jour sur un objet de données :
• La cohérence forte. Après que la mise à jour soit terminée, tout accès suivant (par A, B, ou C) renverra la valeur actualisée.
• La cohérence faible. Le système ne garantit pas que les accès ultérieurs renverront la valeur actualisée. Un certain nombre de conditions doivent être respectées avant que la valeur ne soit renvoyée. La période entre la mise à jour et l’instant où il est garanti que tout observateur verra toujours la valeur actualisée se nomme la fenêtre d’incohérence.
• La cohérence à terme. C’est une forme spécifique de cohérence faible ; le système de stockage garantit que si aucune nouvelle mise à jour n’est effectuée sur l’objet, tous les accès finiront par renvoyer la dernière valeur actualisée.  Si aucun échec ne se produit, la taille maximale de la fenêtre d’incohérence peut être établie sur la base d’éléments tels les délais de communication, la charge sur le système et le nombre de répliques concernés par le schéma de réplication. Le système le plus répandu qui implémente la cohérence à terme est le DNS (Domain Name System). Les mises à jour d’un nom sont distribuées selon un modèle configuré et en association avec des caches à expiration; à terme, tous les clients finiront par voir la mise à jour.

Le modèle de cohérence à terme a un nombre de variations qu’il est important de considérer:

• La cohérence causale (causal consistency). Si le processus A a communiqué au processus B qu’il a mis à jour un objet de données, un accès ultérieur par le processus B renverra la valeur actualisée, et une écriture est garantie de remplacer l’écriture antérieure. Un accès via le processus C qui n’a pas de relation causale avec le processus A est sujet aux règles de cohérence à terme normales.
• La cohérence « lecture de vos écritures » (read-your-writes consistency). C’est un modèle important où le processus A, après qu’il a mis à jour un objet de données, accède toujours à la valeur actualisée et ne verra jamais une valeur antérieure. C’est un cas particulier du modèle de cohérence causale.
• La cohérence par session (session consistency). Ceci est une version pratique du modèle précédent, où un processus accède au système de stockage dans le cadre d’une session. Tant que la session existe, le système garantit la cohérence « lecture de vos écritures ». Si la session se termine à cause d’un scénario d’échec quelconque, une nouvelle session doit être créée, et les garanties ne recouvrent pas les sessions.
• La cohérence monotonique en lecture. Si un processus a vu une valeur particulière pour l’objet, tout accès ultérieur ne renverra jamais une valeur antérieure.
• La cohérence monotonique en écriture. Dans ce cas, le système garantit de sérialiser les écritures par le même processus. Les systèmes qui ne garantissent pas ce niveau de cohérence sont notoirement difficiles à programmer.

Un certain nombre de ces propriétés peuvent être associées les unes aux autres. Par exemple, on peut obtenir des lectures monotoniques associées à la cohérence par session. D’un point de vue pratique, ces deux propriétés (lectures monotoniques et « lecture de vos écritures ») sont tout à fait souhaitables dans un système de cohérence à terme, mais pas toujours exigées. Ces deux propriétés rendent plus simple pour les développeurs de construire des applications, tout en permettant au système de stockage de relâcher la cohérence et fournir une haute disponibilité.

Comme vous le voyez dans ces variations, un assez grand nombre de scénarios sont possibles. Tout dépend des applications spécifiques, si l’on peut gérer les conséquences ou non.

La cohérence à terme n’est pas une sorte de propriété ésotérique des systèmes distribués extrêmes. Beaucoup de RDBMSs (relational database management systems – systèmes de gestion de bases de données relationnelles) modernes qui fournissent de la fiabilité au niveau du backup principal implémentent leurs techniques de réplication tant en mode synchrone qu’asynchrone.  En mode synchrone, la mise à jour de la réplique fait partie de la transaction. En mode asynchrone, les mises à jour arrivent au backup de manière différée, souvent par l’exportation du log. En ce dernier mode, si le principal échoue avant l’exportation des logs, la lecture du backup promu produira des valeurs anciennes et incohérentes. Aussi, afin de supporter une meilleure performance scalable en lecture, les RDBMSs ont commencé à fournir la possibilité de lire à partir du backup, ce qui est un cas classique de fourniture de garanties de cohérence à terme dans lesquelles les fenêtres d’incohérence dépendent de la périodicité de l’exportation des logs.

La Cohérence Serveur

Pour la cohérence serveur, il nous faut regarder de plus près comment les mises à jour circulent dans le système afin de comprendre ce qui pilote les différents modes que peut rencontrer le développeur qui utilise le système. Etablissons d’abord quelques définitions avant de commencer :

N = le nombre de nœuds qui stockent les répliques des données

W = le nombre de répliques qui doivent accuser réception de la mise à jour avant que celle-ci ne soit complétée

R = le nombre de répliques qui sont contactées quand un objet de données est consulté via une opération de lecture

Si W+R > N, alors le jeu d’écritures et le jeu de lectures se recouvrent toujours et l’on peut garantir une cohérence forte. Dans le scénario de backup principal de RDBMS qui implémente de la réplication synchrone, N=2, W=2 et R=1. Qu’importe la réplique à partir de laquelle lit le client, il recevra toujours une réponse cohérente. Dans la réplication asynchrone quand la lecture du backup est activée, N=2, W=1 et R=1. Dans ce cas R+W=N et la cohérence ne peut être garantie.

Le problème de ces configurations, qui sont des protocoles de quorum de base, est que quand le système ne peut écrire sur les W nœuds à cause des échecs, l’opération d’écriture échoue obligatoirement, ce qui marque l’indisponibilité du système. Quand N=3 et W=3 et seulement deux nœuds sont disponibles, le système sera obligé de mettre l’écriture en échec.

Dans les systèmes de stockage distribué qui doivent fournir de la haute performance ainsi que de la haute disponibilité, le nombre de répliques est en général supérieur à deux. Les systèmes qui se focalisent uniquement sur la tolérance à la panne utilisent souvent N=3 (avec des  configurations W=2 et R=2). Les systèmes qui doivent servir des charges en lecture très élevées répliquent souvent leurs données au-delà de ce qui est requis pour la tolérance à la panne ; N peut être des dizaines, voire des centaines de nœuds, avec R configuré à 1, de telle sorte qu’une seule lecture renverra un résultat. Les systèmes qui s’occupent de la cohérence sont configurés à W=N pour les mises à jour, ce qui peut diminuer la probabilité de la réussite de l’écriture. Une configuration courante pour ces systèmes-là qui sont concernés par la tolérance à la panne mais pas par la cohérence, est d’utiliser W=1 afin d’obtenir la durabilité minimale de la mise à jour et ensuite de s’appuyer sur une technique de propagation épidémique dans le but de mettre à jour les autres répliques.

Comment configurer N, W et R dépend de ce qu’est le cas courant et de quel chemin de performance doit d’être optimisé. En R=1 et N=W nous optimisons pour le cas de la lecture, et en W=1 et R=N nous optimisons pour une écriture très rapide. Bien sûr, dans ce dernier, la durabilité n’est pas garantie en la présence d’échecs, et si W < (N+1)/2, il y a la possibilité d’écritures contradictoires quand les jeux d’écritures ne se recouvrent pas.

La cohérence faible/à terme se produit quand W+R <= N, ce qui signifie qu’il y a la possibilité que les jeux en lecture et en écriture ne se recouvriront pas. Si c’est une configuration délibérée et non basée sur un cas d’échec, alors ça n’a aucun sens de régler R autrement que sur 1.  Il existe deux cas très fréquents où cela se produit : le premier est la réplication à grande échelle pour le scaling en lecture mentionné plus haut ; le second se produit quand l’accès aux données est plus compliqué. Dans un modèle clé-valeur simple, il est facile de comparer des versions afin de déterminer la dernière valeur écrite sur le système, mais dans des systèmes qui renvoient des jeux d’objets, il est plus difficile de déterminer correctement le dernier jeu. Dans la plupart de ces systèmes où le jeu en écriture est plus petit que le jeu de répliques, un mécanisme est en place qui applique les mises à jour aux nœuds restants dans le jeu de répliques via une technique de propagation épidémique (lazy). La période jusqu’à ce que toutes les répliques soient mises à jour s’appelle la fenêtre d’incohérence, comme je l’ai évoquée plus haut. Si W+R <= N, alors le système est vulnérable à la lecture à partir de nœuds qui n’ont pas encore reçu les mises à jour.

Que les cohérences « lecture de vos écritures » (read-your-writes), session et monotonique peuvent être obtenues ou pas, dépend en général de l’association (stickiness) des clients au serveur qui exécute le protocole distribué pour eux. S’il s’agit du même serveur à chaque fois, il est alors relativement facile de garantir la « lecture de vos écritures » et les lectures monotoniques. Cela rend un peu plus difficile l’équilibrage de charges et la tolérance à la panne, mais c’est une solution simple. L’utilisation de sessions, qui ont de l’affinité (sticky), rend cela explicite et fournit un niveau d’exposition sur lequel les clients peuvent raisonner.

Parfois le client implémente la « lecture de vos écritures » et les lectures monotoniques. En rajoutant des versions aux écritures, le client rejette les lectures de valeurs ayant des versions qui précèdent la version vue en dernier.

Les partitions se produisent quand certains nœuds ne peuvent atteindre d’autres dans le système, mais tous les deux jeux de nœuds sont accessibles par des groupes de clients. Si vous utilisez une approche de type quorum majoritaire classique, alors la partition qui a W nœuds du jeu de répliques peut continuer à prendre des mises à jour pendant que l’autre partition devient indisponible. C’est également vrai pour le jeu en lecture. Etant donné que ces deux jeux se recouvrent, le jeu minoritaire devient par définition indisponible. Les partitions ne se produisent pas fréquemment, mais ils peuvent s’effectuer entre les datacenters, aussi bien que au sein des datacenters.

Dans certaines applications l’indisponibilité de toute partition est inadmissible, et il est important que les clients qui peuvent accéder à cette partition puissent avancer. Dans ce cas les deux côtés attribuent un nouveau jeu de nœuds de stockage pour recevoir les données, et une opération de fusion est exécutée quand la partition est réparée. Par exemple, chez Amazon, le panier de courses utilise un tel système de write-always (d’écriture permanente) ; dans le cas d’une partition, un client peut continuer d’ajouter des articles dans son panier même si le panier d’origine existe toujours dans d’autres partitions. L’application de gestion de panier aide le système de stockage à fusionner les paniers une fois la partition réparée.

Dynamo de Amazon

Un système qui a réuni toutes ces propriétés sous le contrôle explicite de l’architecture de l’application est Dynamo de Amazon, un système de stockage clé-valeur qui est utilisé en interne dans plusieurs services qui constituent la plateforme e-commerce (commerce électronique) d’Amazon, ainsi que dans les Amazon’s Web Services. Un des objectifs de conception de Dynamo est de permettre au propriétaire du service de l’application qui crée une instance du système de stockage Dynamo – qui s’étend fréquemment sur de multiples datacenters – de faire lui-même le compromis entre la cohérence, la durabilité, la disponibilité et la performance, tout en restant à un certain seuil de coût.³

Conclusion

Il existe deux raisons de tolérer l’incohérence des données dans des systèmes distribués fiables à grande échelle : l’amélioration de la performance en lecture et en écriture dans des conditions hautement concomitantes, et la gestion des cas de partitionnement où un modèle basé sur la majorité rendrait une partie du système indisponible bien que les nœuds soient opérationnels.

Que les incohérences soient admissibles ou non dépend de l’application client. Dans tous les cas le développeur doit savoir que les garanties de cohérence sont fournies par les systèmes de stockage et doivent être prises en compte lorsqu’on développe les applications. Il y a plusieurs améliorations pratiques que l’on peut faire au modèle de cohérence à terme, comme par exemple la cohérence par session et les lectures monotoniques, qui fournissent de meilleurs outils pour le développeur. Très souvent l’application est capable de gérer les garanties de cohérence à terme du système de stockage sans problème. Un cas précis fréquent est un site Web sur lequel on a la notion de la cohérence perçue par l’utilisateur. Dans ce scénario, la fenêtre d’incohérence doit être inférieure au temps estimé avant le retour du client pour le chargement de la page suivante. Ceci permet aux mises à jour de se propager dans le système avant que la lecture suivante ne soit prévue.

Le but de cet article est de sensibiliser le lecteur à la complexité des systèmes d’ingénierie qui doivent opérer à échelle globale et qui exigent un tuning méticuleux afin d’assurer la durabilité, la disponibilité et la performance exigées par leurs applications. L’un des outils du concepteur de systèmes est la durée de la fenêtre d’incohérence, pendant laquelle les clients des systèmes sont potentiellement exposés aux réalités de l’ingénierie des systèmes à grande échelle.

Werner Vogels @allthingsdistributed.com

Source : Eventually Consistent – Revisited
Traduction : Helen CHAUVEAU, Frédéric FAURE

References :

1. Brewer, E. A. 2000. Towards robust distributed systems (abstract). In Proceedings of the 19th Annual ACM Symposium on Principles of Distributed Computing (July 16-19, Portland, Oregon): 7
2. A Conversation with Bruce Lindsay. 2004. ACM Queue 2(8): 22-33.
3. DeCandia, G., Hastorun, D., Jampani, M., Kakulapati, G., Lakshman, A., Pilchin, A., Sivasubramanian, S., Vosshall, P., Vogels, W. 2007. Dynamo: Amazon’s highly available key-value store. In Proceedings of the 21st ACM Symposium on Operating Systems Principles (Stevenson, Washington, October).
4. Gilbert , S., Lynch, N. 2002. Brewer’s conjecture and the feasibility of consistent, available, partition-tolerant Web services. ACM SIGACT News 33(2).
5. Lindsay, B. G., Selinger, P. G., et al. 1980. Notes on distributed databases. In Distributed Data Bases, ed. I. W. Draffan and F. Poole, 247-284. Cambridge: Cambridge University Press. Also available as IBM Research Report RJ2517, San Jose, California (July 1979).

Fromage ou Dessert ?
Métrologie ou Supervision ? C’est la grande question. Il faut bien évidemment que les 2 composants du monitoring soient présents pour assurer le bien-être de votre infrastructure. Cependant, il n’est pas toujours évident de savoir dans quel domaine l’outil assure le service ou bien si il assure les 2. Le schéma ci-dessous indique à quel(s) groupe(s) appartiennent les outils étudiés.

Supervision ou/et Métrologie ?

La Matrice… Enfin ! :o)
La réponse n’est pas 42, rassurez-vous. Vous trouverez-ci dessous les éléments de décision qui permettront de choisir tel ou tel outil pour votre infrastructure.

Matrice - Outils Monitoring

Les + / -
Si je devais retenir un point positif et un axe d’amélioration pour chaque outil qui me feraient pencher pour son utilisation ou non en production, ce seraient ceux là :

Munin
+ : Sa configuration très simple sous forme de fichiers de configuration et de liens symboliques, en font un candidat idéal pour un gestionnaire de configuration centralisé comme Puppet et pour de l’automatisation.
- : L’absence actuelle sur ses graphiques d’une fonctionnalité de zoom et de time frame glissante rend son utilisation très difficile pour de la production.

Nagios
+ : Sa configuration sous forme de fichiers, qui peut être assez vite repoussante, en fait cependant un candidat idéal à la « pupettisation » et à l’automatisation. Au delà de cela, c’est, on peut le dire, un outil complet qui a fait ses preuves.
- : L’IHM… Il ne faut pas négliger cet aspect, car une information mise en forme « avec goût » aide aussi à sa compréhension et son interprétation. La forme est importante au delà de la pertinence de l’information.

Cacti
+ : Un outil de métrologie complet avec pas mal de fonctionnalités (Thold, Weathermap, …) apportées au travers de sa Plugin Architecture. La variété et les possibilités de ses tempates complexes sont aussi un atout non négligeable.
- : La création de ses templates peut s’avérer un peu complexe au premier abord avec les différentes couches (Data Queries, Data Input Method, Data Templates, Graph Templates, Host Templates, …). Un autre point quelque peu embêtant est le manque d’homogénéité dans la configuration de ses templates (casse-tête pour l’automatisation).

Centreon
+ : Une IHM agréable et intuitive. Les notions proposées permettent une prise en main intuitive et les templates (hosts, services, commandes, …) sont pratiques et simples à mettre en place.
- : Les graphiques se contentent de tracer les données de performance remontées par Nagios sans offrir la possibilité de les mettre en relation et de les travailler afin d’obtenir des graphes orientés « logiciel/métier » comme des graphes résumant l’utilisation d’un Apache ou d’un MySQL (par exemple).

Zabbix
+ : Un outil complet autant au niveau de la métrologie que de la supervision qui se suffit à lui-même pour monitorer de manière exhaustive une infrastructure. Les fonctionnalités très avancées permettent de gérer pratiquement tous les cas.
- : Un manque de lisibilité de certains écrans (comme celui des déclencheurs par exemple) et de leurs enchaînements et des notions qui manquent parfois de prise en main intuitive. L’interface Web fait également un peu « vieillote ».

Conclusion
Il n’y a pas de mauvaise solution, certaines seront simplement plus adaptées à ce que vous voulez en faire. Voici quelques possibilités afin d’obtenir un monitoring complet de votre infrastructure :

• Si vous voulez privilégier l’automatisation et la gestion centralisée des configurations de votre infrastructure (Cf. Puppet), pensez Munin-Nagios (vous aurez alors accès dans ce cas à 2 IHMs Web pour monitorer votre infrastructure), the « Double tap », the « Buddy system » du monitoring ! :o) Pas besoin d’accéder à des APIs plus ou moins avancées (comme pour leur camarades) pour ajouter/supprimer un host et associer les services à monitorer, tout est sous forme de fichiers de configuration et de symlinks. A noter que Munin n’exploitera pas les données de performances de Nagios mais celles de ses propres sondes et que la grosse lacune de Munin est l’absence actuelle sur ses graphiques d’une fonctionnalité de zoom et de time frame glissante qui rend son utilisation très difficile pour de la production.
• Si vous privilégiez une métrologie avancée donnant accès à des possibilités de supervision, pensez Cacti avec sa Plugin Architecture (assortie avec Thold par exemple). Prenez un peu de temps pour comprendre les notions utilisées pour créer les templates de graphes et créez vos propres graphes complexes ! Vous pourrez ensuite utilisez leurs métriques et la connaissance que vous aurez acquis dessus pour lever des alertes via Thold.
• Si vous privilégiez une supervision complète avec des possibilités de métrologie simple, Centreon est fait pour vous ! Surcouche de Nagios proposant un générateur de configuration, l’exploitation des données de performances de Nagios via RRDTool, du reporting agréable sur le statut de votre infrastructure, la possibilité de gérer une architecture distribuée de Nagios via son daemon CentCore qui se connecte sur les Nagios remote en SSH, … Centreon propose un pilotage de Nagios via une interface Web agréable et intuitive et une gestion de templates de hosts, services, commandes, … très pratique.
• Si vous êtes sans concessions, Zabbix vous offre une interface unifiée vous proposant aussi bien de superviser votre infrastructure avec des notions très avancées (mesures, déclencheurs, actions conditionnelles complexes, escalade, scénarii HTTP, …) que de travailler la partie métrologie avec la possibilité de créer des graphes complexes avec les mesures récupérées. A noter qu’au delà de l’aspect séduisant du « No Compromis », la prise en main est moins intuitive qu’un Centreon, par exemple, avec une IHM moins agréable et proposant parfois des enchaînements d’écrans un peu confus à mon sens.

Comme précisé dans la première partie de cet article, il est important de noter que je n’ai pas bien sûr pu tester les dernières versions de chaque outil, puisqu’il s’agit de retours d’expérience (sur plus de 2 ans) sur des environnements de production et qu’on n’en met pas un en place toutes les semaines ! ;ob Je suis donc ouvert à vos remarques sur les évolutions que vous aurez constatées sur vos outils favoris ou bien sur les éléments de décision que vous mettriez en plus dans la balance pour effectuer votre choix.

Frédéric FAURE @Twitter @Ysance

Monitoring = Métrologie + Supervision
Tout d’abord, un éclaircissement sur la sémantique utilisée est nécessaire afin que nous parlions bien tous de la même chose. Le monitoring est le terme global que l’on emploie afin de désigner le ou les outils qui vont nous permettre de suivre (monitorer) la vie de notre infrastructure. Le monitoring se décompose ensuite en 2 disciplines toutes aussi importantes l’une que l’autre et 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.

Maintenant que cette hypothèse sémantique est posée nous allons pouvoir utiliser ces termes dans la suite de l’article.

De l’évolution des outils
Il est important de préciser que je n’ai pas bien sûr pu tester les dernières versions de chaque outil, puisqu’il s’agit de retours d’expérience sur des environnements de production et qu’on n’en met pas un en place toutes les semaines ! ;ob Je n’ai pas non plus testé tous les plugins additionnels (par exemple ceux de Cacti) qui permettent d’ajouter des fonctionnalités à l’outil. C’est un retour d’expérience sur plus de 2 ans et, pour donner un ordre d’idée, les outils sur lesquels j’ai travaillé le moins récemment sont Cacti et Nagios, il y a environ 1 an.

Il y aura donc peut-être eu des mises à jours par rapports aux éléments que je cite, donc n’hésitez pas à me faire un retour sur le sujet via les commentaires si j’ai omis un nouvelle fonctionnalité importante qui est apparue récemment.

Centreon, une interface à Nagios
Avant d’entamer le coeur du sujet, à savoir le comparatif des outils, il est nécessaire de donner une explication sur le fonctionnement de Centreon et de son rapport à Nagios car, ne soyez pas choqués, le coeur de Centreon est basé sur Nagios. Oh le fourbe ! :o)

Nagios est un ordonnanceur qui va organiser (ordonnancer) les tests de supervision, appelés contrôles, sur les différents hosts et services cibles et agréger les résultats pour les mettre à disposition via une interface web en lecture seule. Nagios permet aussi de remonter des données de performance (via ses plugins) qu’il stocke dans un énorme fichier plat et qui est, par conséquent, inexploitable en l’état. Pour préciser la remontée de ces informations, chaque résultat de contrôle renvoyé par un plugin peut être suffixé d’un | (pipe) derrière lequel les données de performances dans un format « clé=valeur » sont ajoutées. Les données « post pipe » sont simplement extraites et stockées dans ledit fichier. Voici un exemple de données de performance issues d’un plugin (en rouge) :

PING ok – Packet loss = 0%, RTA = 0.80 ms | percent_packet_loss=0, rta=0.80

De plus, toute la configuration de Nagios s’effectue directement dans les fichiers de configuration « à la main », ce qui peut devenir un peu complexe sur des infrastructures de taille respectable.

C’est sur ce constat que vient se greffer Centreon en proposant une interface web différente de celle de Nagios et ajoute ainsi les fonctionnalités suivantes :

• Génération via IHM de la configuration potentiellement complexe de Nagios en mettant notamment à disposition des notions de templates d’hosts, de services, de commandes, … avec des possibilités d’héritages multiples.
• Stockage et exploitation (graphique) des données de performance (métrologie) de Nagios via l’outil open source RRDtool.
• Reporting plus lisible sur l’état des hosts et des services de l’infrastructure sur différentes périodes : pratique pour avoir une visibilité globale de la qualité de son infrastructure dans le temps et pratique pour fournir des rapports visuels dans le cadre de SLAs.
• Une interface ergonomique de visualisation de l’état des hosts et des services (je la trouve plus agréable que celle de Nagios qui fournit de base cette fonctionnalité sur sa propre IHM web).
• La possibilité de piloter plusieurs Nagios distribués et d’agréger leurs données : cela peut être utile sur de grosses infrastructures segmentées. Il est donc à noter qu’il est possible d’installer des Nagios autonomes sur des machines différentes de celle du Centreon qui collectera les données (via CentCore).

Voici quelques captures d’écran de Centreon :

Centreon - Configuration - Nagios - nagios.cfg

Centreon - Monitoring - Services - AllServices

Centreon - Reporting - Dashboard

Centreon - Views - Graphs

Et comme un schéma vaut mieux qu’un long discours, en voici un expliquant la relation entre les deux outils :

Architecture Centreon-Nagios

Je considère Centreon comme un outil à part entière, même si il utilise Nagios comme ordonnanceur, le coeur de la fonctionnalité de supervision.

Pour résumer, Centreon est un outil complet qui vous permettra d’ajouter une composante métrologique à un solide outil de supervision. Pratique donc pour unifier dans un même outil, une même interface, tout ce qui est nécessaire aux équipes d’exploitation pour surveiller l’infrastructure. A noter cependant que l’exploitation des données de performances ne vous permet pas de mettre en place des graphes aussi complexes que ceux que l’on peut produire avec des outils de métrologie plus avancés. Par exemple, on ne pourra pas remonter des informations plus orientées services comme celle d’un serveur Web ou d’une base de donnée et les mettre en corrélation, comme on peut le voir dans des graphes Cacti, Munin ou Zabbix.

Le Corbeau et le Cactus
Cela aurait pu être une fable mettant en scène un corbeau malhabile laissant des plumes sur le végétal facétieux. Mais il n’en n’ai rien, il s’agit de 2 outils de métrologie.

Munin est un outil très simple basé sur RRDtool qui propose une interface simpliste sans beaucoup de fonctionnalités. Les visualisations sur plusieurs échelles de temps (jour, semaine, mois et année) ne proposent pas de zoom ou de scroll, ce qui est limitant pour une production, c’est d’ailleurs à mon sens LE gros manque. Car outre cette limitation, il remplit les fonctionnalités essentielles d’un outil de métrologie pure et chaque graphique correspond à un unique script qui gère aussi bien la récupération des informations que leur mise en forme via RRDtool selon un template très bien pensé. Munin utilisant un agent sur la cible, il suffit de déployer l’agent avec la liste des graphiques de notre infrastructure et de n’activer ceux que nous souhaitons voir pour la cible via lien symbolique (comme les sites-enabled et les sites-available sous Apache par exemple). L’architecture est très pratique et la combo est très performante en utilisant Puppet (gestionnaire de configuration centralisé) pour les déploiements automatisés de machine et conserver homogènes les configurations de vos pools de machines. Cette combo m’a vraiment séduit. Surtout que qu’elle fonctionne très bien en corrélation avec un Nagios pur qui fonctionne également sur une configuration purement sous forme de fichiers. The « Double tap » ! C’est un peu le « Buddy system » du monitoring ! :o)

Si vous voulez en savoir plus sur les possibilités offertes par Puppet dans ce cadre, vous pouvez lire cet article si vous voulez en savoir plus sur un cas d’utilisation de Puppet ou bien celui-ci pour regarder une vidéo expliquant plus le fonctionnement interne de l’outil et sa configuration. Pour finir, cette citation :

En ce qui concerne la gestion et le suivi de la ferme web de FarmVille, nous exploitons quelques outils de gestion et de monitoring Open Source. Nous utilisons Nagios pour les alertes (supervision), Munin pour le monitoring et Puppet pour la configuration.

(précision sémantique Munin => métrologie) tirée d’une interview de Luke Rajlich (FarmVille). Pour l’interview complète, lisez Comment FarmVille scale pour récolter 75 millions de joueurs par mois si vous voulez vous convaincre de l’intérêt de cette solution. :o)

Voici quelques images de l’interface Munin pour vous faire une idée :

Munin - Overview

Munin - Overview Machine

Munin - CPU by day

Munin - Mysql Queries by day

Cacti est lui aussi un outil de métrologie, plus complet que le précédent, et qui a la particularité d’avoir une « Plugin Architecture » qui va permettre de lui ajouter pas mal de fonctionnalités en important des plugins et en les configurant via l’interface web. On note parmi les plugins disponibles Thold, qui permet de mettre en place un système de remontée d’alertes mail sur des évènements liés aux graphes mis en place, comme sur le dépassement d’une valeur absolue, sur un pourcentage d’augmentation/diminution, … Cela permet de capitaliser sur l’expérience tirée de l’analyse des graphes de son infrastructure et de prévenir en cas de fonctionnement anormal. Cependant, l’aspect supervision proposé ici ne sera pas aussi développé que ceux que l’on peut trouver sur des outils plus spécialisés et gérant des escalades, un panel de mesures/déclencheurs/actions extrêmement fins et modulables, des plages horaires et des groupes d’utilisateurs, … Tout ce qui fait un outil de supervision complet. Donc Cacti est avant tout un outil de métrologie avec pas mal de plugins intéressants et avec la possibilité de mettre à disposition une supervision simple qui peut convenir dans certains cas… simples. ;ob

Le point fort de Cacti réside dans les possibilités de customisation des graphes que l’on crée ou bien que l’on importe depuis les templates variés mis à disposition par la communauté. Il est parfois un peu compliqué, je trouve, de créer ses graphes : il faut bien comprendre le mécanisme ! Rien d’insurmontable en tout cas.

Voici quelques captures d’écran, afin de vous donner une idée de l’outil :

Cacti - Settings (from www.cacti.net)

Cacti - Tree View (from www.cacti.net)

Cacti - Apache Statistics - Thread scoreboard

Il est à noter que Cacti, contrairement aux autres outils présentés ici, ne fonctionne pas avec un système d’agents mais attaque directement un serveur SNMP sur la cible pour récupérer les informations système et, de la même manière, impose que les services monitorés (Apache, MySQL, …) laisse Cacti les interroger via le réseau. C’est une autre façon de concevoir les choses. Au choix.

Zabbix
Zabbix est un outil de supervision qui propose un palette de fonctionnalités complète de métrologie. Cela en fait un outil qui peut à lui seul monitorer une infrastructure sans faire de concession. C’est un point très important quand on veut unifier les différents aspects du monitoring (métrologie et supervision) de son infrastructure dans un même outil, une même interface, à disposition de ses équipes d’exploitation.

C’est un outils complet qui permet de gérer toutes les notions relatives à la supervision (escalade, alerting, plages horaires, mesures/déclencheurs/actions sur conditions, …) et également un outil de métrologie complet permettant de tracer des graphes mettant en corrélation toutes les mesures que l’on remonte. Il est à noter que contrairement aux autres outils mettant à disposition des fonctionnalités de métrologie, il est le seul à ne pas utiliser RRDtool, mais une base de données. Aucune contre-indication, c’est à titre informatif.

Il utilise un agent comme la plupart de ses camarades afin de monitorer les machines cibles (agent qui peut fonctionner en mode passif ou bien actif, genre j’attends que le serveur me demande ou bien je suis autonome et je lui envoie directement). Il est également possible pour les métriques non système d’utiliser des connexions directes : l’intérêt est d’utiliser la fonction zabbix_sender qui va remonter un ensemble de métriques en une seule fois. Explications : par défaut, Zabbix va établir autant de connexions que de couples « clé-valeur » à remonter… Pourquoi pas, mais quand je veux monitorer des services un peu complexes ou quand je veux récupérer beaucoup de métriques, ça devient un peu consommateur. Il est alors possible de positionner des scripts (comme les plugins Nagios, Cacti, Munin, …), dans la crontab du serveur Zabbix, qui vont récupérer une liste de couples « clé-valeur » (en se connectant directement via le réseau sur les services distants et sans passer par l’agent Zabbix), les stocker dans un fichier (temporaire) sur le serveur Zabbix lui-même et les envoyer en une seule fois à Zabbix via la commande… zabbix_sender !

A noter également la possibilité de construire des écrans, à partir de multiples éléments, qu’il en ensuite possible de faire défiler… sur un grand écran plat pour votre équipe d’exploitation préférée (ceci n’est pas un message personnel ;ob). Il y a également la possibilité de définir des cartes (dans le style de celles que l’on trouve dans Nagios ou bien dans le plugin Weathermap de Cacti) afin de visualiser l’état macro de votre système.

Voici quelques quelques captures d’écran de Zabbix :

Zabbix - Dashboard (from www.zabbix.com)

Zabbix - Apache - Thread Scoreboard (from www.zabbix.com)

Zabbix - Ecrans (from www.zabbix.com)

Zabbix - Graphes - Zoom In (from www.zabbix.com)

La suite…
Voilà pour la présentation des différents outils et la pose des hypothèses à partir desquelles je vais établir un comparatif entre ces différents outils. Le second article va synthétiser les éléments principaux de décision dans une matrice afin de comparer les outils proposés et d’évaluer leur correspondance sur chacun de ces critères.

Frédéric FAURE @Twitter @Ysance

Cet article constitue un retour d’expérience sur un benchmark CPU sur différents types (tailles) d’instances EC2 sur AWS. L’objectif était de constater le comportement, au niveau des ressources CPU, desdites instances lors d’une montée en charge sur un traitement multi-threadé et de les comparer par rapport à un étalon plus récent (choisi arbitrairement, comme un portable) que celui proposé par AWS : l’ECU ou EC2 Compute Unit.

Tout d’abord, je tiens à remercier Sylvain Terret qui a effectué le test « en ressortant un vieux bout de code du placard » et qui a aussi écrit un billet sur son blog sur le sujet. Ensuite, je fais également écho à un article intéressant (EC2 isn’t 50% slower) qui répond à quelques controverses sur la réalité des ressources CPU mises à disposition lors du lancement d’une instance EC2. Je vous invite à lire cet article synthétique et instructif, ainsi que les commentaires associés.

Pour commencer, le bench a été effectué sur un Ubuntu Lucid Lynx. Le code ci-dessous a été utilisé pour charger les différents types d’instances EC2 : il s’agit d’une multiplication de matrices basée sur l’API OpenMP.

Ce calcul matriciel va être exécuté plusieurs fois en incrémentant à chaque fois le nombre de threads qui vont se partager (parallélisation) le calcul. Ainsi, nous avons pu comparer un même traitement lorsqu’il est exécuté par 1, 2, … 12 threads et constater l’évolution du temps d’exécution en fonction du type d’instance EC2, c’est à dire, dans le cas qui nous intéresse, en fonction du nombre de CPUs disponibles sur chaque type d’instance. Il est à noter que chaque CPU affecté au traitement d’un thread donné est monopolisé à 100% lors de l’exécution du calcul.

Le code source est le suivant :

#include
#include
#include
#include

#define SIZE 2000

double get_time() {
struct timeval tv;
gettimeofday(&tv, (void *)0);
return (double) tv.tv_sec + tv.tv_usec*1e-6;
}

int main(int argc, char const *argv[]) {
int nb, i, j, k;
double t, start, stop;
double* matrice_A;
double* matrice_B;
double* matrice_res;

// Allocations
matrice_A = (double*) malloc(SIZE*SIZE*sizeof(double));
matrice_B = (double*) malloc(SIZE*SIZE*sizeof(double));
matrice_res = (double*) malloc(SIZE*SIZE*sizeof(double));

for(i=0; i for(j=0; j matrice_A[i*SIZE+j] = (double)rand()/(double)RAND_MAX;
matrice_B[i*SIZE+j] = (double)rand()/(double)RAND_MAX;
}
}
printf(« Nb.threads\tTps.\n »);

for(nb=1; nb<=12; nb++){
start = get_time();
#pragma omp parallel for num_threads(nb) private(j,k)
for(i=0; i for(j=0; j matrice_res[i*SIZE+j] = 0.0;
for(k=0; k matrice_res[i*SIZE+j] += (matrice_A[i*SIZE+k] * matrice_B[i*SIZE+j]);
}
}
}
stop = get_time();
t = stop – start;
printf(« %d\t%f\n », nb, t);
}
// Libérations
free(matrice_A);
free(matrice_B);
free(matrice_res);
return EXIT_SUCCESS;
}

Les instances benchées sont les suivantes :

• Standard Instances – Large Instance (M1.LARGE) 7.5 GB of memory, 4 EC2 Compute Units (2 virtual cores with 2 EC2 Compute Units each), 850 GB of local instance storage, 64-bit platform
• Standard Instances – Extra Large Instance (M1.XLARGE) 15 GB of memory, 8 EC2 Compute Units (4 virtual cores with 2 EC2 Compute Units each), 1690 GB of local instance storage, 64-bit platform
• High-CPU Instances – High-CPU Extra Large Instance (C1.XLARGE) 7 GB of memory, 20 EC2 Compute Units (8 virtual cores with 2.5 EC2 Compute Units each), 1690 GB of local instance storage, 64-bit platform

A noter, la définition de l’ECU (rien à voir avec une nouvelle-ancienne monnaie unique) qui est l’étalon AWS en termes de puissance CPU et qui correspond à :

EC2 Compute Unit (ECU) – One EC2 Compute Unit (ECU) provides the equivalent CPU capacity of a 1.0-1.2 GHz 2007 Opteron or 2007 Xeon processor.

Cela, disons-le, ne représente pas grand chose, mais j’y reviendrai plus tard.

A noter également notre étalon qui est constitué d’un portable posé sur le bureau et équipé d’un Core 2 Quad Q8400 @ 2.66 GHz x 1 (4 cores).

Synthèse graphique

CPU benchmark on EC2

Analyse des résultats

• Tout d’abord de manière macro, il est rassurant de voir que doubler le nombre de « virtual cores » (2 => 4 => 8) double les performances pour des « virtual cores » sensiblement identiques (2 virtual cores de 2 ECUs chacun => 4 virtual cores de 2 ECUs chacun => 8 virtual cores de 2.5 ECUs chacun). Comme le dit Sylvain : « Ca sent un peu le Captain Obvious, mais à bien y réfléchir, ce n’est pas une règle d’or dans l’informatique. »
• Le Core 2 Quad posé sur le bureau est plus efficace à nombre de coeurs équivalent que les instances EC2 (une M1.XLARGE avec 4 coeurs de 2 ECUs chacun dans notre cas).
• Ensuite, il est intéressant de noter que nous n’avons obtenu sur le lancement des instances que des processeurs Xeon (Intel) : E5430 @ 2.66 GHz pour les M1.LARGE et M1.XLARGE et E5410 @ 2.33 GHz pour les C1.XLARGE. Quelles auraient été les résultats si nous avions eu des Opteron (AMD) ? Il faut savoir que l’on ne choisit pas son type de processeur au lancement d’une instance. Cependant, cela fait quelques temps que je n’ai plus vu d’Opteron au lancement d’instances EC2 : il faut dire que je travaille depuis quelques temps quasi exclusivement sur la région européenne d’Amazon (par opposition aux EU, voire à l’APAC). Je n’ai pas investigué sur ce sujet beaucoup plus au delà.
• Une anomalie est à noter concernant les tests sur les M1.XLARGE : la différence de performance sur les 3 premiers calculs (de 1 à 3 threads) entre les deux instances M1.XLARGE (4 virtual cores) : une des 2 instances a donné des performances moins bonnes sur le même bench qui a tourné deux fois sur chaque machine (les résultats ont été constants). Je n’ai pas trouvé d’explication sur cette différence entre les 2 instances.
• Ce qui n’apparaît pas sur le graphique et que l’on constate, en se connectant directement sur les instances, via top ou htop : on voit à chaque nouveau calcul exécuté et distribué sur un thread supplémentaire un nouveau CPU passer à 100% (calcul sur 2 threads = 2 CPUs à 100%, …) et lorsque l’on atteint « nombre de threads >= nombre de CPUs de l’instance », on voit apparaître un pourcentage de steal sur les CPUs de l’instance.

Le % steal
Pour analyser un peu plus en détail la présence de steal, nous avons effectué un autre test de performance (merci à Yann Le Van pour le graphe !) en monitorant un MongoDB (toujours sur Ubuntu Lucid Lynx) que nous avons maltraité en y injectant par palier de nombreuses requêtes de géolocalisation non bornées avec des critères de recherche sur des attributs supplémentaires (Cf. requêtes géospatiales et indexation composée). Il apparaît de nouveau clairement qu’un pourcentage non négligeable de steal progresse avec l’utilisation des CPUs de l’instance (les 8 coeurs d’une C1.XLARGE dans ce test).

CPU Benchmark MongoDB

CPU Benchmark MongoDB - Legende

Il ne s’agit pas de puissance CPU que l’on nous dérobe honteusement (ce que j’ai lu dans plusieurs articles concernant ce sujet), mais d’une puissance de calcul utilisé par l’hyperviseur qui gère la virtualisation sur laquelle repose notre OS. Ce test le prouve car le % steal progresse (ou décroit) proportionnellement à notre propre sollicitation de l’instance. Si il s’agissait de la sollicitation de « notre » puissance CPU par une autre instance d’un autre utilisateur sur le même hardware, l’évolution de la valeur du % steal ne serait pas directement reliée à notre utilisation (elle pourrait être constante par exemple).

La valeur du % steal n’est cependant pas négligeable et l’hyperviseur est quelque peu gourmand sur une sollicitation importante des ressources CPU de notre instance.

Conclusion
Comme je disais précédemment concernant l’étalon Amazon, l’ECU, il donne une idée de la puissance comparative des instances EC2 entre elles : si vous faites fonctionner une application multi-threadée sur une instances EC2 et que vous avez besoin de plus de puissance CPU, prendre une instance 2 fois plus puissante en termes d’ECUs vous permettra d’aller 2 fois plus vite (à noter qu’en fonction du type d’instance, un coeur à une puissance de 2 à 3.25 ECUs, si on fait abstraction de la Small Instance et de la Micro Instance qui sont moins puissantes).

Sorti du paradigme AWS, l’ECU ne signifie plus rien car la valeur du GHz dépend de l’architecture, de la génération et du fabricant (Intel, AMD, …) du processeur. Un « 1.0-1.2 GHz 2007 Opteron or 2007 Xeon » ne vous donnera pas une indication très précise sur la puissance réelle dont vous allez disposer, à part le fait qu’à GHz égal, votre ordinateur de bureau équipé de la dernière génération de processeurs vous donnera de meilleurs résultats.

La meilleure (et probablement la seule valable) solution afin de constituer votre choix d’instances à déployer pour votre application est de mettre en place quelques tests de performances afin de constater réellement les ressources utilisées dans le paradigme AWS et de sélectionner les instances et de choisir leur nombre (scale-out) en fonction du résultat obtenu.

Frédéric FAURE @Twitter @Ysance

How do you scale an AWS (Amazon Web Services) infrastructure? In Part Two of the article, I describe the architecture model and the underlying technical components you should use in order to implement a scalable infrastructure. We will look in particular at the optimisation of data access in scale-out-type architectures suitable for implementation as a distributed system, as much at the data model level as the lower layers for I/O optimisation. We will also examine the recommended development concepts such as Stateless, in the finest REST tradition. I will end the article with some tips and tricks. My aim is to help you set up and optimise your infrastructure by understanding how Amazon tools operate and to get the most benefit from them.

Scale-out
Scale-out is the opposite of scale-up: the latter means the dynamic expansion on the fly of a given server’s resources (addition of RAM or CPU). Thus, the application continues running on a single machine whose capacity has been increased. Scale-out (the AWS way), on the other hand, offers to increase the number of servers in order to respond to the increased load of an application. Ultimately, the global potential of the infrastructure increases too, but is divided among several servers. This implies that the application supported on the server had been thought out in terms of distribution, that is, it can be executed in parallel on several servers without the risk of corrupting the business logic (think to shared session management or no session, for example) or creating a problem of access to the resources (which must then be available via the network and not locally on any given server, for example).

Scale-out can be likened to Agent Smith in Matrix. As for scale-up, think more along the lines of the Stay Puft Marshmallow Man in Ghostbusters!

Stateless
The best way to obtain an application that is both easy to distribute and high performing, is to plan for it in stateless mode. This means that it’s the client request which must contain all the information enabling the request to be processed by the server, either via a cookie, or else via the URL parameters. Whenever possible you should choose this approach at any price, compared to the stateful mode in which the server must keep a context for each client to be able to respond to the request. The stateless concept is one of the great REST concepts. While we’re on the subject, I strongly recommend you read this excellent article on REST (in French) by Jean-Paul Figer to appreciate the style in all its simplicity and power.

If you have to manage stateful, you will need to use a network cache such as Memcached, to share the contexts among your different servers. Don’t even consider the local cache and sticky session package, as you will have trouble getting even distribution of the load balancing. It’s not a good idea to use a cluster which communicates in multicast either, because the Amazon network does not allow that … Or all the servers could communicate in unicast with a gateway which takes care of redistributing the communications… Are you sure you don’t prefer stateless? ;ob

The implementation of stateless applications did not arrive with Cloud Computing and AWS: on the other hand, if you don’t think along these lines, you won’t be able to make the most of all the energy and flexibility they provide.

Optimisation of data access
Optimising data access requires two elements:

• The data model and software architecture that are found in scalable architecture, whether you are on an AWS infrastructure or not.
• I/O management, which can be optimised in particular by thoroughly exploiting AWS.

The scalable model
This subject deserves an entire article of its own, but the scalable model is in keeping with a rather classic model within the casual gaming-type applications, or more generally linked to applications based on the social graphs, or centred on a distinct business concept in particular.

To summarize, two methods of data storage are:

• Storage of what we’ll call the meta-model, which is not intended for distribution, built on a structured, indexed relational base (even though essentially used in the form of a key-value access), containing the general information of each user (in the case of a social application the following: name, top score, previous day’s wins, etc.), primarily accessed in read and for which it is possible to alleviate the load via a Memcached in front of it. You can therefore carry out SQL-type set-based requests (ensemblist) and thus recover information by using clauses (WHERE). This base can be a MySQL or a PgSQL for example. I suggest you read this very interesting report by Guillaume Plessis, comparing MySQL installed on an EC2 with the Amazon RDS (Relational Database Service). I don’t risk ruining the suspense by telling you that databases are a real bearded geek affair! :o)
• Storage for more volatile data (such as game data etc.), with a heavy write:read ratio, difficult to cache, and for which you must choose a real, structured, non-relational storage solution of a key-value-type (NoSQL / Not only SQL, some would say), thus enabling easy distribution of the data on X servers. I can mention a few names: Redis, Tokyo Tyrant/Tokyo Cabinet, MemcacheDB.  And also the new peer to peer models such as Cassandra.

Tokyo Cabinet

In this case, Tokyo Tyrant / Tokyo Cabinet is a solution that I have implemented, which I find satisfactory (note that a new tool Kyoto Cabinet has come and one of his worthy features is to optimize the management of multi threading and thread concurrency compared to Tokyo Cabinet). Tokyo Tyrant / Tokyo Cabinet is a twosome, managing the requests from distant servers (network interface) and access to the storage system respectively. Six APIs are available for storing the data:

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

Each of them has its own characteristics and responds to particular requirements in terms of performance and practicality.

Regarding performance: apart from its natural capabilities, it has the notable advantage of not managing authentication (which is usual in key-value storage systems – there are exceptions like SimpleDB, for example – ; security is supposed to be guaranteed at the network level for accessing the storage system and at the applications level for access to data – so that you can only retrieve that which concerns you). This reduces the access rate (no need for authentication requests) compared to a classic database. Furthermore, no reconstruction of onerous index management is required (possible however on the Tokyo Team’s API ‘Table’) … It goes without saying that what’s really time-consuming about data access via the network (between the web or application server and Tokyo Tyrant) is… the network! So in all cases, at the client (API) level you should use ‘mget’ (multi get), for example, by positioning a array of keys that you wish to recover in the parameters rather than performing a ‘get’ N times from the client, therefore creating N network accesses. ‘mget’ will be resolved at the Tokyo Tyrant level.

The arguments concerning this tool should be applied to all key-value-type storage.

I/O management
Now we come to the specific characteristics of AWS in terms of storage: EBS (Elastic Block Stores). EBS volumes are network disks optimised for I/Os, easy to use, ensuring the survival of crucial data during an EC2 (volatile) shutdown. On a purely practical note, I did however notice latency variances: not enormous, but on an application that is much in demand, it does get noticed. This is not insurmountable, it’s simply something to bear in mind. If your servers’ Load Average increases, it’s not necessarily the CPU which is to blame … Think I/Os! ;ob

Firstly think striping, therefore RAID0. No need for mirroring (RAID1), as the data safety in EBS is already guaranteed by Amazon, transparently, by network replication: let’s make the most of this service and concentrate on striping. Remember too to spread the writes of the different physical files (data, update logs, etc.) among different disks (for tools using update logs – and this is the case for MySQL and Tokyo Tyrant for example – do remember to set their capacity parameters). This is what allows you the best optimisations. Next, choose your filesystem carefully with regard to the tool (EXT3, XFS, etc.) and consider the mounting options (noatime, nodiratime, etc.) Finally, check the default scheduler on the EC2 instances that you are starting up: it’s the NOOP scheduler by default (I/O requests in a simple FIFO file). Consider something more efficient, such as CFQ (Completely Fair Queuing). Well, I say that, but it always depends on the top software layer, and if and how it manages the priorities: in this example (which is not on EBS) on the MySQL Performance Blog, it appears that the NOOP and DEADLINE schedulers are the best for improving the InnoDB I/O. It just goes to show, it’s always better to test first for your own particular case! ;ob

Logical Volume Management

Another tool I have used with the EBS and which works very well is LVM2 (Logical Volume Management, version 2). I haven’t used it with an architecture with a high number of IOPS (I/O Operations Per Second) and have therefore not tested the striping possibilities (RAID0) offered by the tool. On the other hand, I have used it with an infrastructure which had to be able to tolerate considerable increases in data volume but without interruptions in service. The snapshot and volume re-creation operations of an EBS are too long. LVM provides the solution, because this abstraction layer enables the management of software volumes independent of physical resources: you only need to raise a new EBS resource (a command line), associate it with the EC2 instance (another command line) and add this resource to the LVM resource pool. All that’s needed is to increase the logical volume (still transparent, without service interruption), then extend the file system. That last operation (which is a joint operation with the re-creation of the EBS volume) can necessitate shutting down the service for a few moments (around ten seconds). Note that it is possible to hot-extend your file system with EXT3, personally, I prefer a service interruption of a few seconds on this type of very short but crucial operation. ;ob  And what’s more, it is easy to perform backups on an LVM system offering a snapshot differential option, which you can mount like an independent logical volume: when there is a modification to the origin volume, the initial value is copied in the snapshot volume, so you can snapshot large volumes on a limited space because only the frequency of modification is what counts. You can find further information on LVM2 and EBS by consulting this very good article (in French) by Laurent Roux.

All these examples demonstrate that EBS are a very useful resource: you have to consider them firstly as a means of ensuring the durability of important resources before taking into account the performance aspect. In fact, performance is not necessarily better on an EBS than on the local disks of an EC2 instance (Cf. a simple and interesting test (in French) by Charles-Christian Croix. Or, to see some slightly more complex tests, Google “performance ephemeral disk ebs volume raid”. There are quite a few very interesting cases, and I must confess I find it hard to choose between them ;ob). Nevertheless, when you are committed to ensuring the safety of your data and thus using EBS (which, for those in the know, is comparable to a LUN on a SAN), there are several ways of maximising their performance.

It should be noted that, for a pure performance solution, use them to spread the files (and thus the I/Os) among several EBS disks.

Note however that the EC2 bandwidth is inevitably limiting, once you reach a certain threshold: adding EBS is helpful for smoothing out the variance differentials (in RAID0) or for optimising the throughput, but the fact remains that if you add several EBS to your EC2 instance and they are in great demand… it’s the EC2 bandwidth that jams. You will have to add a new EC2 (scale-out to increase the resources – in this case the bandwidth), attach new EBS to it (don’t forget that an EBS may be attached only to a single EC2 at a time) and partition the data onto it (sharding).

In all cases, handling the EBS is easy and this flexibility is a plus.

Tips & tricks
This last section contains some useful hints.

Aliases & IPs
Remember, on an AWS infrastructure, to position aliases corresponding to your instances’ private IPs in the ‘hosts’ file, which you then deploy via Puppet for greater reactivity, given that the IPs are ‘variable’ (when you shut down one instance and start up another straight away, you will not keep the same IP). By using the the ‘hosts’ file you will avoid provoking internal DNS resolutions for Amazon.

CDN & S3 Headers
For the CDNs (Content Delivery Networks) that you will have to use in a scalable architecture, remember to use S3 in order to provide images and other static content. It’s useless to keep a Web server only for that purpose: that’s what S3 is for, and at minimal cost.

Remember also that in certain cases where your traffic is more moderate and you don’t wish to change over to a CDN (for reasons of cost, for example ;ob), you can always optimise the management of your resources on S3 by using the metadata attributed to the said resources on S3, by positioning, for example, Cache-Control or Expires-type headers. You may visualise the metadata via the new S3 tab of the Amazon management console.

Backups… What else?
S3 is also the solution for backups. I have not found any integrated tools satisfactory for this task: I simply use a command line tool “s3cmd” in order to store my backups. I integrated this tool into Capistrano tasks called by cron. s3cmd is very simple to operate, enables the use of S3 services and offers the possibility of transferring data in HTTPS, and also to store it in encrypted format.

Conclusion
There are many more things to be said on this subject, but the abovementioned points are, in my opinion, the essential ones, in any case with regard to using the services provided by AWS. To sum up:

• Stateless and REST are, generally speaking, better adapted to AWS, since they enable easy sharing of the load on an infrastructure which can adapt to the increased load on a scale-out model.
• Data access always creates a bottleneck in distributed scaling applications. At this level it’s a matter of working on the data model and making good use of the adequate storage systems:
  • SQL technologies for metadata able to necessitate set-based querying (ensemblist) and relational things, while making maximum use of a network cache for information with a high read:write ratio.
  • NoSQL / Not only SQL / key-value technologies for information which can be accessed with a single key, and thereby benefit from the distribution inherent in scale-out.
• Finally, remember the lower layers by selecting an appropriate filesystem and scheduler. You should also consider RAID (striping) and LVM (volume extension and snapshot differential) to get the most out of the EBS’ versatility and allocation of the I/Os on different devices (always being careful with your EC2 bandwidth, which can become restrictive: in that case add one or more EC2 instances to gain bandwidth and partition – shard – the data on new EBS).

I hope you enjoyed this second part of my report on the scalability of AWS infrastructures.

Frédéric FAURE @Twitter @Ysance