Haute-Disponibilite

La mise en place d’un service web reste un processus incrémental et la forte montée en charge est parfois incertaine. En effet les certitudes et les tests sur un échantillon de données ne sont pas forcément valables quand les volumétries sont multipliées par 10, 100 ou 1000.

Au delà des problèmes techniques, disposer d’une architecture solide est un véritable avantage concurrentiel. Car les coûts de croissance peuvent exploser si le design de base n’a pas été pensé correctement.

Dessiner les plans et les protocoles de mise à jour des informations demandent, dès la phase de conception, de se projeter vers des architectures distribuées. Le cas des sites web, de type média est aujourd’hui bien connu et il existe un certain nombre de techniques qui permettent de gérer la croissance de manière quasi linéaire.

Mais dans le cas des nouveaux applicatifs web les choses sont différentes car il ne s’agit pas simplement d’afficher une page web. Il s’agit de rendre un service, de manière immédiate et cela indépendamment de la charge de ce service et du nombre d’utilisateurs du service.

Le partitionnement des tâches et des services est ici indispensable. Car il permettra de calculer le coefficient de rendement de votre architecture.

A ce titre je vous conseille d’étudier la loi de Amdahl. Elle permet de prévoir le gain obtenu par l’ajout de ressource dans un système. Elle nous montre aussi que le design de l’application est LE composant le plus important.

Prenons un exemple : Lire la suite »

Garantir une disponibilité de 100% quelque soit le nombre d’utilisateurs d’un service et sans pouvoir être sûr de l’ensemble des ressources disponibles est impossible. Il convient donc de mettre en place des stratégies de communications et d’actions pour gérer les périodes d’interruptions.

L’actualité récente nous prouve que personne n’est à l’abri des incidents. En quelques jours ce en sont pas moins de cinq services qui sont tombés  : Le nouveau service d’Apple : Mobile Me, mais aussi de Facebook (de nouveau tombé cette semaine), Google Docs, 37signals et enfin LiveSide.

Personne n’est donc à l’abri de problème technique, dépendant ou non de sa volonté d’ailleurs (un incident sur un datacenter est très pénalisant et il est difficile de s’en prémunir)

C’est pour cette raison qu’il faut mettre en place un plan d’action permettant de communiquer rapidement avec vos utilisateurs. Cela vous permettra de leur montrer que même pendant l’incident vous maitrisez en partie la situation.

Voici un modèle, à adapter en fonction de votre service, qui vous permettra de bâtir un plan d’action : Lire la suite »

Quelle est la différence entre le Grid et le Cloud Computing ? C’est la question que j’ai reçu il y a quelques jours. En fait même si certains concepts sont proches (grand nombre de serveurs, communication réseau très importante, stockage généralement distribué, etc…) ces deux techniques sont assez différentes.

En fait elles différent surtout par le mode d’utilisation de ces clusters de serveurs.

Dans le cas du Grid Computing il s’agit surtout de mettre à disposition de quelques équipes des ressources informatiques très puissantes pour des périodes de temps donnés (et généralement planifiés). En France il existe par exemple le projet Grid5000 (INRIA, CNRS, Universités, … ). Ce cluster est en général utilisé pour faire des calculs parallèles sur de très gros volumes de données.

Alors que dans le cas du Cloud Computing on note souvent une notion d’instantanéité, d’élasticité de la ressource, de disponibilité et de virtualisation.

Lire la suite »

La montée en charge d’un service web peut être traitée de multiple façons. Mise en place d’un CDN (pour les vidéos ou les contenus éditoriaux), ajout de serveurs (si les applicatifs ont été conçus pour pouvoir fonctionner sous forme de cluster), appel à un prestataire pour lui demander de gérer son trafic, etc…

Bref, il existe de multiples solutions, elles ont toutes comme point commun un coût de mise en place assez important. Mais attention il ne faut pas que les coûts progressent plus vite que le trafic…

Malgré tout il existe des solutions open source pour gérer en partie cette problématique. Je ne reviendrais pas ici sur les coûts d’intégration des logiciels open source (ils sont loin d’être nuls, surtout pour des utilisateurs non expérimentés). Mais quand les équipes sont compétentes ou que les logiciels sont simples à mettre en place ces outils peuvent être d’un grand secours, pour un coût relativement faibles.

C’est justement le cas des applicatifs distribués par DANGA Interactive.

Lire la suite »

Un datacenter, aussi sécurisé soit-il n’est pas infaillible. Nous le voyons régulièrement, le dernier incident date du mois dernier. La première chose à faire pour vraiment sécuriser son infrastructure consiste donc à isoler géographiquement les équipements. C’est l’une des contraintes de la norme TIER-4.

Les centres de données répondant à cette norme sont rares, le dernier sorti est celui de Marcoussis. Il est exploité et commercialisé par Alcatel-Lucent. Son but premier est de consolider les différents centres des deux entreprises (centres existants avant la fusion).

Cette consolidation doit se faire dans des Datacenters extrêmement fiables et denses (cela permettra d’en réduire le nombre). Les centres de données de classe 4 doivent garantir une disponibilité de 99,995%. Pour cela ils doivent être munis de multiples sources d’alimentation et de climatisation, de plus elles doivent toutes être redondantes. Ces multiples sécurités doivent permettre une maintenance sans interruption et une tolérance aux défaillances à toutes épreuves. Lire la suite »

Il ne se passe pas un semestre sans qu’un incident majeur se produise dans un centre de données. Ce mois-ci c’est Cogent Grenoble qui a été victime d’un incident dans son système de climatisation.

Cet événement nous rappelle que la mise en place d’une architecture disponible repose obligatoirement sur plusieurs centres de données.

Cette redondance physique et géographique coûte chère mais la mise en place de ses équipements dans plusieurs datacenters est un des premiers points à prendre en compte pour ne pas être dépendant d’un seul prestataire. Lire la suite »

La mise en place d’un espace de stockage partagé est généralement effectué via un partage simple (comme NFS) mais pour le rendre et distribué et gérer des milliers de serveurs, cette architecture n’est plus adaptée.

C’est pour ce type d’architecture hautement distribuée que Lustre à été crée. Lustre est un système de fichier robuste, hautement disponible et sécurisé. Ce système est aujourd’hui maintenu par Sun Microsystems dont l’un des objectifs est de l’inclure dans Solaris (via ZFS), en France il est par exemple utilisé par le CEA.

Il n’est bien sûr pas question d’utiliser ce type de système pour une architecture Web ’simple’ mais dans le cas d’un système de type Clouds, Lustre peut être une alternative à des NAS relativement couteux.

Lire la suite »

Pour rendre une application hautement disponible, il est possible de mettre en place des clusters de serveurs et de répartir ces clusters dans plusieurs datacenters. De nombreux articles de ce site font références à ce type de technique. En général les solutions libres permettent de construire des clusters (web ou BDD) assez facilement. De la même manière certaines solutions sont nativement conçues pour être mise en cluster (comme certaines version d’Oracle par exemple). Enfin dans le cas d’un développement propriétaire il est possible de construire une architecture intégrant cette contrainte dès le départ.

Mais quand l’application est basée sur les logiciels propriétaires qui ne supportent pas de multiples instances en parallèle la mise en place de cluster est plus difficile. De la même manière les logiciels ‘historiques‘ fonctionnent souvent sur un OS ancien. Et il n’est pas facile de mettre en cluster ces logiciels sur des serveurs récents (alors que DELL ou IBM proposent l’intégration des solutions VMWare quasiment en natif dans leurs offres).

Pour protéger ces applications en cas incident les solutions de virtualisation peuvent donc offrir une alternative rapide et efficace (si la charge de votre application n’est pas trop importante). Lire la suite »

Choisir un hébergeur n’est pas une chose simple. Le nombre de paramètre à prendre en compte est important et la durée de l’engagement l’est aussi. En effet choisir un hébergeur pour les 6/12 premiers mois d’activité ne se fait pas de la même manière pour le choix d’un partenaire qui accompagnera sa croissance sur plusieurs années. Il est assez rare que le même prestataire soit idéal sur ces deux phases d’ailleurs.

L’exemple de YouTube est assez intéressant de ce point de vue. A l’époque du lancement il n’existait pas de service de type Amazon ou Google Apps les fondateurs de YouTube ont donc opté pour la location de serveurs managés par un prestataire (le coût et la rapidité de mise en place étaient prioritaires).

Bonne idée car ils n’étaient pas expert dans ce domaine et souhaitaient se concentrer sur le cÅ“ur du système : l’application Python permettant l’upload et le stockage sur Clusters des vidéos. Avec la croissance exponentielle du trafic la location de serveurs n’était plus économiquement viable. De plus l’hébergeur en question avait une architecture réseau qui ne correspondait plus vraiment aux flux qui devaient transiter entre les machines. Enfin le besoin en bande passante, problème n°1 devait se régler directement avec des opérateurs.

C’est pour cette raison qu’ils ont décidé de migrer vers la location d’un espace privé dans un Datacenter. Les principaux avantages ont été : Lire la suite »

Wikipédia fonctionne grace à un logiciel open source: MediaWiki. C’est un logiciel PHP/MySQL. L’architecture des sites Wikipédia est donc basée sur ce couple de logiciel et hébergée sur des configurations classiques de type LAMP.

Mais pour gérer des pics avec plusieurs dizaines de milliers de connections par seconde il faut booster cette architecture.

L’équipe du site a donc ajouté un certains nombre de composant pour absorber ce trafic colossal.

Dans le désordre nous retrouvons :

• une répartition de charge par DNS
• LVS pour le load balancing
• Squid pour le cache
• Memcached, Lucene, Lighttpd,
• etc…

Et comme un schéma est souvent bien plus clair qu’une longue explication voilà à quoi ressemble l’infrastructure du site :

Concernant les volumétries les 3 datacenters de Wikipédia utilise quelques 400 serveurs (du P4 au double Xeon Quad Core avec 16Gb de RAM). Le détail se trouve dans le document en bas de page mais le plus impressionnant reste Squid car il gère ici des pointes à 2500 requêtes/sec sur UN SERVEUR !!

Lire la suite »