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

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

How do you scale an AWS (Amazon Web Services) infrastructure? This article will give you a detailed reply in two parts: the tools you can use to make the most of Amazon’s dynamic approach, and the architectural model you should adopt for a scalable infrastructure. I base my report on my experience gained in several AWS production projects in casual gaming (Facebook), e-commerce infrastructures and within the mainstream GIS (Geographic Information System). It’s true that my experience in gaming (IsCool, The Game) is currently the most representative in terms of scalability, due to the number of users (over 800 thousand DAU – daily active users – at peak usage and over 20 million page views every day), however my experiences in e-commerce and GIS (currently underway :o)) provide a different view of scalability, taking into account the various problems of availability and data management. I will therefore attempt to provide a detailed overview of the factors to take into account in order to optimise the dynamic nature of an infrastructure constructed in a Cloud Computing environment, and in this case, in the AWS environment.

The tools
I will provide examples of tools I used in my various production experiments and which won me over with their efficiency. However, it’s not so much the tools themselves which are emphasised, rather the underlying features that must be installed to fully exploit the AWS.

What is the difference between an AWS and a standard infrastructure?
There are two replies:

• Firstly, the AWS enable the Hardware and Infrastructure components to be handled via the code (through the APIs): this gives them momentum which needs to be intensified by correctly selecting your tools. Amazon also offers a certain number of technical guarantees with their services, which should be used to full advantage in order to concentrate on what is essential.
• The second answer should be: ‘None!’ However, it must be acknowledged that often the cosy aspects of ‘home’-hosted infrastructure can lead to a certain lack of rigor on many issues. The fact that Amazon, with its AWS, offers a dynamic and volatile solution for the EC2s, compels you to install mechanisms which should be standard.

Centralised configuration management
In order to instantiate multiple servers (EC2) on the fly to counter a load peak or perform occasional procedures, we have to use a centralised configuration management tool. This has multiple uses:

• Rapid instantiation of a machine corresponding to a pre-defined type: Web server, cache server, etc.
• Ensuring uniform configuration of the entire set of instances of the same type at all times.
• Capitalising on the expertise: packages, configurations, services etc. for each type of instance are contained within a descriptor. This enables new users (and others) to learn the composition of the servers simply by reading the associated descriptor(s.)

Puppet is a very attractive solution for this task. Puppet architecture comprises:

• A Puppet Master, guardian of configurations. It contains the descriptors of the packages to be installed, configuration files to be pushed and services to be started up for a new EC2 instance in order to prepare it according to the type of node or nodes with which you have associated it, or simply to keep an existing instance updated.
• Multiple Puppet clients installed on EC2 instances. The client regularly polls the master to check that his configuration is up to date. It is also possible to trigger the clients from the master to initiate an urgent update.

It is thus very simple to mount a new instance of a given type, and to be sure that from one server to another, the configuration is identical in every way. It should be noted that the Puppet Master descriptors run on a node system, and a server may reference more than one node. You will therefore obtain a very modular configuration.

Puppet Module Descriptor

The centralised configuration manager is indispensable on a scalable infrastructure, which can have a large number of instances, some of which should be mounted rapidly, in order to reply to user requests during load peak.

‘But’, you may say, ‘you do have to install the client on the new instance, don’t you?’ Oh yes, all the more so as there is a system of certificate request/acceptation between the client and the master, so that not just anybody can access the configurations. ‘There’s nothing simpler!’ I reply. Instead of using an HMI (Human Machine Interface) such as ElasticFox to connect to the Amazon services APIs, you need simply to connect with command lines via a script which instantiates an EC2, creates if necessary an EBS volume and associates it, connects with SSH on the new instance and installs the client, connects on the master and accepts the certificate request, reboots the client and ‘Bingo!’ The instance installs and configures itself. In general, the reactive and dynamic capacities inherent in EC2 and AWS require it, otherwise it would be an under-exploitation, or even a misuse of the tool.

And what about the AMIs (instance-store root devices) or the EBS root devices (note that for the latter there is not yet a great choice of templates)? It is however possible to build an AMI or even an EBS root device with the Puppet client installed on it (and to use, if necessary, the user-data at the launch of the instance in order to set the parameters if a ‘static’ configuration on the AMI is not sufficient). However, in a production environment, the AMI and the EBS root device do not allow you to replace a Puppet: if you have to modify the AMI every time you change the parameters and redeploy the EC2… you’ll never finish. The AMI is a good tool for instantiating a basic template, but not for maintaining a production infrastructure in good working order.

To sum up, it is even possible to envisage auto-scalability (a more complete service than the one offered by Amazon’s Auto Scaling, based on CloudWatch), which would amount to starting up this script when a value on a monitoring graph (metrology) exceeds a threshold, thereby instantiating a new instance to weather the peak period, an instance which would be ‘terminated’ after dipping below another threshold on the aforementioned graph. The possibilities are enormous. However, the cost of the final elements to be installed on a large production infrastructure to access the auto-scalability function is considerable (exponential complexity). If you get the chance, it’s an excellent handiwork, otherwise you’ll have to ‘settle’ for an easily scalable solution whereby you simply launch a script manually (or else at a fixed time based on the study of the metrics produced by the metrology, which is a satisfactory alternative). If necessary, manually adding one or two references in a file is a perfectly reasonable alternative.

Execution of automated tasks in parallel
Because of the variation in the number of instances according to the load of a scalable infrastructure, and particularly in the potentially large number of these instances, you cannot envisage carrying out maintenance and deployment operations on an individual basis for each machine (or manually, which is even worse!). This would not only be too time-consuming, but would also lead to errors. It is therefore essential to use tools specialising in automation and parallel task execution, such as Capistrano, which has numerous advantages:

• Scripting a certain number of tasks, whether complex or not (deliveries, backups, site publication/maintenance, etc.) executing them rapidly in parallel on X instances with a single command.
• Ensuring the reproducibility of a task.
• Capitalise on know-how (Cf. Puppet).

Capistrano Task Descriptor

This tool is very practical and easy to use. It executes tasks in parallel (by connecting with SSH – don’t use the ‘root’ key of your EC2 instances in the tool, it’s classier to use a dedicated key…) on one or a group of servers defined by roles.

This tool should be used as a supplement to Puppet and not a replacement, as they do not have the same targets:

Objective
Puppet - Uniform configuration of the server pool.
Capistrano – Task reproducibility and in-parallel execution.

Operating mode
Puppet – Regular pull requests by clients (or even push from the master).
Capistrano - Occasional tasks (manual request or by cron).

Orientation
Puppet - Pre-defined objects / notions such as ‘Package’, ‘Service’, ‘File’, etc.
Capistrano – Generic commands such as ‘upload’, ‘download’, ‘system’, ‘run’, etc.

Target
Puppet - Infrastructure and services.
Capistrano - Services and applications.

Note that Webistrano is an HMI enabling access to the Capistrano features and introducing the notion of project management by managing access to the tasks according to profile, to trace who deployed what on which server and to send email signals in response to certain actions. I find this joint operation with project management very interesting.

Monitoring
This is one of the crucial elements of a scalable architecture, if not the main one. It is essential to have the metrics to hand, precisely so you know when to scale. This enables you to identify the clogged points of the infrastructure, to analyse your site traffic and to make deductions about user behaviour. It also enables signals to be triggered.

The provision of metrics is more representative of metrology than of supervision. We will see that, in the context of an AWS infrastructure, metrology has greater added value than supervision (even if the latter remains indispensable). Speaking of which, there follows a clarification of the two monitoring disciplines that you need to recognise:

• Supervision verifies the state of a host or a service and sends out an alarm upon detecting any abnormal behaviour (over-long response time, status NOK, etc.) and requires immediate action on the part of the interface partner concerned. An alarm must signify that the host or the service is unusable (critical) or may soon be (warning) and must not send back ‘simple information’ which would obstruct the visibility of real incidents.
• Metrology enables data to be archived, and if necessary, processed or filtered, before it is presented in the form of graphs or reports. This data enables corrections to service development or configuration to be carried out after the event, in order to optimise the aforementioned services, and equally to define the resources to be attributed to them in the most effective way. This aspect of monitoring is just as important, for it will enable the service to be improved (and thereby the users feedback) and also to reduce costs. The metrology results should clearly highlight the improvements to be made by correlating the values recovered.

Quite a number of monitoring tools are available on the market, each with its pros and cons, some more supervision-oriented, others more towards metrology. Among them: Centreon/Nagios, Zabbix, Cacti and Munin. Personally I use Centreon/Nagios mainly for supervision and Cacti for software-oriented metrology with pre-packaged graphs such as for Apache, MySQL, Memcached, etc. I tried Munin, it lacks some of the useful features of Cacti but it is really easy to use and it matchs very well with Puppet (configuration based on descriptors and symlinks). I’ve also heard many good things about Zabbix (comprehensive range of features).

Thread Scoreboard Apache - Yearly - 1 Day Average

It should be noted that these tools operate mostly (Centreon, Cacti and Munin) on RRDtool (Round-Robin Database), a database management tool which also enables a graphic representation of the data contained in the base. The big advantage stems from the fact that the stored data volume is minimal, whether for storage of several months, or even years. This is made possible by calculating the averages of the time periods (from 1 minute to 1 day): the recent data is exact, whereas the older data is approximate.  This is very practical, as you have both the recent exact metrics and you keep the historic, a representation of the evolution of your architecture.  This is excellent for visualising the evolution of the key metrics and understanding the impact of the evolution of the components of the aforementioned infrastructure, or the applications supported as and when the different releases are delivered.

As for Cloud Computing-type infrastructures, metrology is the discipline with the highest added value, as it will enable feedback to your automation tools.

Keep in mind also that it’s interesting to be able to integrate dynamically the new instances installed and configured by Puppet in the monitoring tool. Give priority therefore to monitoring tools with modular configuration or simple access via APIs.

Managing centralised logs
It’s undeniable: the more instances you have, the more scattered logs there’ll be on the various instances. Moreover, sending all the logs to the syslog daemon becomes difficult, as the infrastructure components do not necessarily manage it very well (redirection, respecting the syslog protocol, etc.), not to mention the application(s) / functional block(s) which can log in the various files on the server.

Consider trying a tool such as Syslog-NG: it comprises a server and several clients, in fact it’s the same tool but with different configurations. What’s more, it is capable of regularly checking the log files (of business applications for example) and transmitting only the differential, even if it doesn’t respect the syslog protocol:

• The client recovers the files/pipe/unix-dgram/etc. logs and sends the information to the network (TCP/UDP).
• The server recovers the information from the network (TCP/UDP) and registers it in files, databases, etc.

Syslog-NG Architecture

We’re talking about only minimal differences in terms of configuration. The component can also act as a relay on more complex infrastructures by receiving the network logs from diverse clients and sending them back to the network for a server.

It is possible to apply filters before sending the logs to the network in order to send only the essential ones. Next, filters can also be applied at the server level in order to manage differently the logs coming from clients, according to their urgency, sender program, source host, etc.

It’s a simple and non-intrusive tool able to take into account the logs of scattered applications on a server (even if these logs do not respect the syslog protocol format – there is however an advantage to respecting this protocol: greater accuracy of the facilities and priorities).

Keep in mind, the same as for monitoring, that it is interesting to be able to integrate (and withdraw) dynamically the new instances to be managed at the logs system level.

Conclusion
Over and above the tools presented here, it is the underlying functions and capacities which are important. What stands out are the following:

• Tools such as centralised configuration managers, tools for the execution in parallel of automated tasks and also log managers, will become even more important. Working without them on such infrastructures is no longer conceivable.
• Monitoring is still and will remain a key value, but metrology allows you, with the analysis of key defined metrics in your infrastructure, to sustain the automation tools.
• Automation is indeed the key word promoted by AWS: the accessibility of the Hardware and Infrastructure resources via code allows us to move towards ever more autonomous architectures. However you must always position the cursor correctly, in the knowledge that the final stages of complete automation are the most expensive.

I hope that this technical feedback will interest you as much as I enjoyed working on these infrastructures. I will continue in the second part of this article: Choosing the correct architecture model for scalable infrastructures.

Frédéric FAURE @Twitter @Ysance

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

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

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

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

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

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

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

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

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

Descripteur Module Puppet

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

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

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

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

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

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

Descripteur Tache Capistrano

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

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

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

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

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

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

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

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

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

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

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

Thread Scoreboard Apache - Yearly - 1 Day Average

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

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

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

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

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

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

Architecture Syslog-NG

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

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

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

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

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

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

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

Frédéric FAURE @Twitter @Ysance

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

Version IPhone
Version IPod

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

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

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

Le mot clé est : « automatisation ! »

Frédéric FAURE

Différence avec une infrastructure standard
Tout d’abord il est normal de se poser la question. La réponse devrait être : « aucune ! ». Cependant, force est de constater que bien souvent le côté plus douillet de l’infrastructure hébergé « à la maison » pousse à une certaine forme de laxisme sur un certain nombre de points. Le fait que Amazon, avec ses AWS, propose une solution volatile et dynamique au niveau de ces EC2 oblige à mettre en place des mécanismes qui devraient être standards afin :

• de tirer profit des possibilités, du dynamisme, de la solution,

• de prendre en compte plus sérieusement, du fait de la volatilité de l’outil, les plans de reprise sur incident et identifier les données importantes afin d’assurer leur durabilité.

Le monitoring
Le monitoring est le premier élément à mettre en place. Dans une architecture scalable, il est indispensable d’avoir à disposition des métriques afin de savoir justement quand scaler. C’est le rôle de cet élément. Il permet de plus d’identifier les points d’engorgement de l’infrastructure, analyser l’évolution du trafic sur votre site et en déduire les comportement des utilisateurs et dans le cadre d’un monitoring actif, permet également de déclencher des alertes qui servent de base aux astreintes.

Il n’y a pas d’outil miracle pour le monitoring et un certain nombre existent sur le marché avec leurs avantages et inconvénients. Nous pouvons citer Nagios, Cacti, Zabbix, Munin, … Nous avons choisi Cacti pour notre infrastructure du fait de la qualité des courbes qu’il propose. Il est vrai que le packaging de cet outil manque, à mon avis, de rigueur et que les métriques manquent, sur certains templates, de précision, cependant la qualité des courbes, basées sur RRDtool, et leur diversité permet d’effectuer un suivi complet de notre infrastructure et de comprendre les impacts de l’évolution des composants de ladite infrastructure ou bien des applications supportées au fur et à mesure des livraisons des différentes releases.

Nous avons installé également la « plugin architecture » de Cacti qui nous permet d’installer, comme son nom l’indique, des plugin sur l’outil et notamment « Thold », nous permettant de déclencher des trigger sur l’atteinte d‘une valeur sur une courbe ou bien sur une variation afin d’effectuer du monitoring actif. Bien entendu, cela est le prélude à une gestion des astreintes et à chaque alerte remontée doit correspondre un mode opératoire de reprise sur l’incident mis en lumière via Cacti.

Le monitoring est positionné sur une machine EC2 pour des raisons évidentes de coût (le coût des échanges sur l’IP interne est nul) et de sécurité (inutile d’ouvrir plein de ports et donc autant de failles à l’extérieur).

Cacti - Apache Statistics - Thread scoreboard

La gestion de configuration centralisée
La notion de scalabilité rendue accessible par l’infrastructure des services Amazon, nous oblige à utiliser un outil de gestion centralisé de la configuration. L’utilité est multiple :

• instancier rapidement une machine correspondant à un type prédéfini : serveur SQL, serveur de cache, serveur Web, …

• assurer l’homogénéité de la configuration des instances d’un même type,

• capitaliser un savoir faire.

Nous utilisons Puppet dans notre infrastructure. Nous avons installé le Puppet Master sur le serveur de monitoring. Le Puppet Master contient les descripteurs des installations et configurations à apporter à une nouvelle machine afin de la préparer suivant le type de machine (nœud) auquel on l’a associé. Régulièrement, le client pull le master afin de vérifier que sa configuration est à jour. Il est également possible de faire du push sur les clients à partir du master pour déclencher une mise à jour urgente.

Il est ainsi très simple de monter une nouvelle instance d’un type donné et d’être sûr que, d’une machine à une autre, la configuration est complètement iso, configuration qui est centralisée sur notre machine de monitoring et dispatchée sur les instances de notre infrastructure. Il est à noter que le descripteur du Puppet Master fonctionne sur un système de nodes et donc un type de machine peut faire référence à plusieurs nodes et on obtient une configuration très modulaire. Tous nos types de machine, par exemple, utilisent le module Puppet de configuration, que nous avons décrit, du protocole SNMP, indispensable pour que Cacti monitore une machine, et le module de l’outil s3cmd nous permettant de faire fonctionner notre système de backup sur chaque machine. Ensuite, chaque type de machine a ses installations/configurations spécifiques.

Exemple du descripteur de nœuds « nodes.pp » du Puppet Master :

class web-node {
      include snmp-module
      include s3cmd-module
      include web-module
}

Exemple du descripteur « init.pp » du module « snmp » du Puppet Master :

class snmp {
      package {
            « snmpd »:
            ensure => installed;
      }

      file { « /etc/default/snmpd »:
            ensure => present,
            owner => root,
            group => root,
            mode => 0644,
            source => « puppet:///snmp/snmpd »,
            require => Package["snmpd"],
            notify => Service["snmpd"];
      }

      file { « /etc/snmp/snmpd.conf »:
            ensure => present,
            owner => root,
            group => root,
            mode => 0644,
            source => « puppet:///snmp/snmpd.conf »,
            require => Package["snmpd"],
            notify => Service["snmpd"];
      }

      service { « snmpd »:
            ensure => true,
            hasrestart => true,
            restart => « /etc/init.d/snmpd restart »,
            hasstatus => true;
      }
}

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

L’auto-scalabilité, que nous n’avons pas (pour l’instant ;ob) mise en place dans notre cas, consisterait, par exemple, à déclencher ce script sur le dépassement d’une valeur d’un graphe Cacti, instanciant donc une nouvelle machine pour supporter la période de pic, instance qui serait « terminée » suite au repassage en dessous de ce seuil sur le graphe. Les possibilités sont énormes.

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

• scripter un certain nombre de tâches (livraisons, backups, publication/maintenance du site, …) et de les exécuter en parallèle sur X machines,

• assurer la reproductibilité d’une tâche,

• exécuter rapidement des tâches complexes sur X serveurs en une seule commande,

• capitaliser un savoir faire.

Cet outil est très simple d’utilisation et très pratique et exécute des tâches en parallèle, sur un groupe de serveurs que l’on définit, en se connectant en ssh :

ssh_options[:keys] = « ~/.ssh/la_cle_privee »
ssh_options[:user] = « le_user »

Il suffit de définir une liste de serveurs correspondant à un groupe, « sql » par exemple :

role :sql, « alias_sql1  » , « alias_sql2  » , … , « alias_sqlx »

Et ensuite il reste à définir les tâches, que l’on peut décrire intégralement dans le descripteur…

task :dump_sql, :roles => :sql do
      run « rm -f /mnt/backup/`hostname`.`date +%w`-* »
      run « mysqldump –pmon_pwd -u mon_user ma_base | gzip -cq6 > /mnt/backup/`hostname`.`date +%w-%y%m%d_%H%M`.sql.gz »
end

… ou bien dans un fichier « .sh » que l’on uploade et que l’on exécute sur la machine distante

task :store_sql, :roles => :sql do
      upload « /root/cap-scripts/cap-backup_sql.sh », « /usr/local/sbin », :via => :scp
      run « /usr/local/sbin/cap-backup_sql.sh »
end

Il suffit ensuite d’exécuter la simple commande « cap dump_sql » ou « cap store_sql ».

Backups
Et oui, mettre ses données de base SQL sur EBS (dans le cas où l’on n’utilise pas SimpleDB du fait du besoin d’un minimum de modèle relationnel) ne suffit pas, parce que :

• EBS assure une durabilité très respectable par réplication réseau, mais reste l’équivalent d’un disque dur, même si plus fiable,

• il n’y a pas que les données de base SQL (ou autres) qui sont importantes, il y a également vos logs principaux et les configurations de vos outils (Cacti, Puppet, Capistrano, …).

Nous utilisons l’outil en ligne de commande « s3cmd » afin de stocker nos backups. Cet outil est utilisé dans nos tâches Capistrano appelées par cron. Très simple d’utilisation, il nous permet d’utiliser les API’s S3 et offre la possibilité de transférer les données en HTTPS et également de les stocker sous un format crypté.

Tips and tricks
DNS
Il arrive de rencontrer quelques soucis DNS au niveau du réseau Amazon pour les instances EC2. Un conseil donc, positionner des hostname plus parlant (au lieu des « domu -xxxx») et utilisez le fichier des « hosts » que vous déployez ensuite via Puppet !

CDN
Nous utilisons S3 dans notre architecture afin de mettre à disposition les images et autres statiques de notre application à disposition de notre Content Delivery Network, à savoir Panther. Inutile, en effet, de maintenir un serveur Web à cette seule fin, S3 est là pour ça pour un coût minime.

Gestion des Logs
Il serait, à mon avis intéressant, de gérer également les logs de manière centralisée. Nous ne l’avons pas mis en place et, par conséquent, je ne ferai pas de recommandations sur un sujet que je n’ai pas testé moi-même. Cependant, pour indication, il est possible de mettre en place un système de logs réseaux, sous Linux par exemple, afin de centraliser et de mutualiser les logs, logs qu’il est ensuite possible d’analyser. Ca vaut le coup pour une infrastructure ou une application distribuée de connaître le comportement ou les différences de comportement des éléments qui la constitue.

Webistrano
Webistrano est une IHM permettant d’accéder aux fonctionnalités de Capistrano et introduisant une notion de gestion de projet par la possibilité de gérer les accès aux tâches en fonction de son profil, de tracer qui a déployé quoi sur quel serveur et d’envoyer des alertes mails sur certaines actions. Nous ne l’avons pas testé en production, mais cela peut s’avérer intéressant à prendre en considération.

Conclusion
Le but de ce post n’est pas de faire la publicité de tel ou tel outil, mais de vous inciter à considérer l’automatisation de votre infrastructure qui, si elle devrait déjà être en place dans vos infrastructures actuelles internes, devient indispensable sous AWS pour peu que l’on souhaite faire de la scalabilité, être réactif ou simplement tirer parti de l’outil mis à disposition.

Je dirais que les principes fondamentaux d’une bonne infrastructure sont au nombre de 3 : KISS, DRY et YAGNI.

• KISS pour « Keep It Simple, Stupid », à savoir inutile de chercher à complexifier l’infrastructure, la plus efficace sera la plus simple.

• DRY pour « Don’t Repeat Yourself » , à savoir ce qu’il est possible de scripter et d’automatiser faites-le ! Ca vous prendra un peu plus de temps la première fois, mais vous aurez une tâche réfléchie, reproductible, et vous n’aurez surtout pas besoin de le faire une seconde fois (quoi de plus ennuyeux que de se répéter).

• YAGNI pour « You Ain’t Gonna Need It », à savoir n’installez sur vos machine que ce dont vous avez besoin. Plus vous installerez d’outils inutiles ou one-shot, plus votre infrastructure aura potentiellement des trous de sécurité et pourra introduire des effets de bords. Sans aller forcément jusque là, disons qu’elle sera moins facilement maintenable.

Ces principes vous paraissent drôles pour certains ou peut-être un peu ringard pour d’autres, mais si avant de faire une tâche sur une infrastructure on se demandait si ce que l’on va entreprendre ne rentre pas dans un de ces cas, je pense que les infrastructures, de manière générale, seraient plus fiables, homogènes et performantes.

Frédéric FAURE