Decrypt

Varnish est un outil fabuleux à bien des égards. C’est une boite à outils qui permet de simplifier, harmoniser, sécuriser et accélérer les architectures web. Nous allons aborder dans cet article certaines fonctionnalités de Varnish pour commencer à en tirer le maximum. Il se positionne comme un reverse proxy cache. En gros nous allons le placer en amont des serveurs Web pour intercepter les requêtes, mettre en cache ce qui est généré par les backends et resservir le contenu généré depuis son cache. Mais son fonctionnement peut aller plus loin.

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.

[...]

Dans le monde élastique du Cloud et plus précisément en ce qui concerne l’IaaS, nous nous heurtons souvent au problème : “quelle est l’adresse de telle machine, quel est son mode d’accès…”. A ces questions peuvent s’ajouter la problématique du tout automatique via un Capistrano par exemple. Vous me direz qu’il existe une console Web et des API. Oui mais la console n’est pas réellement exploitable pour l’automatisation et les API ont besoin de crédentials que l’on ne préfère pas disséminer partout sur les serveurs.

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.

[...]

Bonjour à tous ! Je mets à disposition sur Decrypt les slides de ma présentation lors de la Web Conférence Tendances Cloud 2011. Vous y trouverez ma définition du Cloud Computing, ainsi que les 7 tendances de la fin de cette année qui, à mon sens, marqueront la direction du Cloud au niveau des entreprises :

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 !

[...]

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.

[...]

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.

[...]

J’ai écrit une première version de cet article au sujet des modèles de cohérence il y a environ un an, mais je n’en étais jamais très content, car il a été rédigé à la hâte, et le sujet est suffisamment important pour mériter un traitement plus approfondi. ACM Queue m’a demandé de réviser l’article afin de le publier dans leur revue, et j’ai profité de cette occasion pour l’améliorer. La nouvelle version suit :

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.

[...]

Voici la suite de l’article présentant les hypothèses de notre comparatif ainsi qu’un bref descriptif de chacun des outils comparés. Je vais maintenant établir une matrice contenant les éléments principaux de décision, selon mon expérience, afin de comparer les outils proposés et d’évaluer la réponse qu’ils apportent sur chacun de ces critères. Pour rappel, les candidats sont des outils opensource gratuits : Zabbix, Centreon, Nagios, Cacti et Munin.

[...]

Cet article a pour objectif de comparer quelques solutions de monitoring (métrologie et supervision) que j’ai eues l’occasion d’intégrer dans des infrastructures de production. Les candidats sont des outils opensource gratuits et de grands classiques : Zabbix, Centreon, Nagios, Cacti et Munin. Le but n’est pas de mettre en avant un produit en particulier, car il n’y a pas de mauvais choix dans la liste précitée, mais plutôt de vous fournir les éléments pour choisir celui qui vous conviendra le mieux dans votre cas d’utilisation. Le sujet sera en fait constitué de 2 articles : un premier va poser les hypothèses de cette comparaison et expliquer le fonctionnement de ces outils ou simplement les présenter afin de vous permettre de mieux aborder le comparatif. Le second article va synthétiser les éléments principaux de décision, selon mon expérience, dans un tableau afin de comparer les outils proposés et d’évaluer la réponse qu’ils apportent sur chacun de ces critères.

[...]

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.

[...]

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.

[...]