Haute-Disponibilite

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 »

Le choix d’un hébergeur ou d’un centre de traitement des données (datacenter) est un choix difficile. C’est pour cette raison que les entreprises passent beaucoup de temps pour déterminer le centre de données qui correspond le mieux à ses besoins.

Dans la plupart des cas, les entreprises examinent la connectivité, la sécurité physique, les caractéristiques du bâtiment, la stabilité financière de entreprise, etc…

Bien que toutes ces caractéristiques soient importantes lors de l’évaluation des prestataires, les entreprises doivent également se concentrer sur les facteurs qui jouent un rôle important pour assurer la haute disponibilité de la prestation, tels que les processus opérationnels, l’organisation des services, la politique d’entretien et le cycle de vie des équipements.

Le contrôle des procédures et la documentation des processus sont également des taches critiques. Pouvoir connaitre les temps d’arrêt non planifiés ainsi que le journal des derniers incidents est un point très important. De plus, de nombreux incidents sont le résultat d’erreur humaine.
C’est pourquoi documenter et valider les processus est un point très important. Car plus les procédures sont fiables et connues plus il est probable qu’elles seront suivies, et moins il est probable que l’erreur humaine provoque une interruption des services. Il est également important de savoir comment ces procédures sont diffusées et quelles sont les formations associées. Lire la suite »

Quelques semaines après l’ouverture de Google App ce service vient de connaitre son premier problème de disponibilité. Plusieurs applications étaient donc ‘off line’ pendant plusieurs heures. C’est assez surprenant de la part de Google qui nous a plutôt habitué à des taux de disponibilité très proches des 100%.

Amazon à également connu des problèmes de disponibilité, et de la même manière l’ensemble des clients/utilisateurs se sont retrouvés sans hébergement pendant plusieurs heures.

Il est assez dommage que ce type de service hautement distribués soient impactés aussi longtemps par ce type d’incident. Concernant Amazon c’est compréhensible car chaque instance est autonome, mais pour Google le CPU comme les disques sont hautement distribués. C’est assez curieux et j’espère que nous aurons des explications sur cet incident de plusieurs heures. Lire la suite »

La mise en production d’un nouveau site est toujours une opération délicate. Sur les sites à fort trafic l’ajout d’une fonctionnalité peut également réserver des surprises. Pourtant il existe des outils permettant de tester efficacement un site ou une fonction avant son déploiement en simulant des clics et des internautes.

JMeter fait parti de cette série de logiciel. C’est bien sur du GPL et comme pour la plupart des logiciels Apache, c’est stable, simple et très efficace.

Il existe une interface graphique permettant de configurer ses tests, mettre en place les  rapports graphiques, appliquer des filtres et configurer les alertes, bref mettre en place la batterie de tests.

Ensuite vous pouvez lancer les tests depuis votre poste (pour tester la configuration) avant de la déployer sur vos serveurs de tests. Ces serveurs peuvent être répartis sur le net pour simuler au mieux de vrais internautes (temps de réponses, latence, etc..) Lire la suite »

La disponibilité d’un service web est très souvent liée à la mise en place d’un cluster de serveurs. Cet ensemble de serveurs est servi par un Load Balancer. De grand noms du réseau proposent ce type de boitier mais à des coûts souvent importants (quelques dizaines de milliers d’euro) qui arrêtent beaucoup de structures moyenne ne disposant pas d’un tel budget.

En effet les boitiers du type Lucent WebDirector ou Foundry ServerIron dépassent les dix mille euros (sans compter l’intégration, le support et le contrat de maintenance). C’est rentable pour un hébergeur qui va mutualiser cet équipement sur plusieurs clients mais pour le site autonome l’amortissement est plus difficile.

C’est pour répondre à cette cible qu’Excelliance a créer un boitier de répartition de charge. Cette box est basée sur un logiciel libre HAProxy. D’une installation assez simple, le boitier peut être mis en place après quelques écrans de configurations. Lire la suite »

Après le lancement de sa nouvelle gamme de serveur dédiés aux applications web et Cloud Computing, les IBM iDataPlex IBM lance ses Datacenter transportables.

Voici donc un premier aperçu du “Portable Modular Data Center (PMDC)“, la nouvelle version de son conteneur modulaire et transportable. Cette première photo est en fait celle d’un modèle de démonstration (il s’agit de la version 20 pieds, il existe également des versions 40 et 200 pieds ). Avec cette box IBM rejoint Sun Microsystems et Rackable, DELL et HP seraient également en train de préparer des offres similaires.Microsoft semble conquis par ce format puisqu’il prévoit de placer au moins 150 conteneurs de ce type (en version 40 pieds) dans son nouveau centre de données de Chicago.

Il est vrai que ce type de box permettent de mettre en place très rapidement des centres de données haute densité. De plus couplé aux solutions IBM Global Financing il est possible de mettre en place son centre de données ‘Green’, rapidement et sans investissement de départ important.

Je ne sais pas qui utilise encore le moteur Yahoo! mais il est toujours intérressant de suivre leurs travaux sur les hautes volumétries. En effet après leurs communications sur Hadoop c’est cette fois le tour de PostGreSQL, utilisé pour améliorer le ciblage publicitaire.

Selon Waqar Hasan, Directeur des bases de données chez Yahoo : « C’est la première fois, à notre connaissance, que l’on place une base de donnée de plus d’un petabyte en production. Nous l’avons construite pour qu’elle atteigne plusieurs dizaines de pétabytes et nous avons l’intention d’y parvenir en 2009. »

Cette base contient le comportement des visiteurs de leur site web. Le but de cette base est d’effectuer une analyse comportementale fine des habitudes et profils des internautes. La finalité étant bien entendu commerciale, il s’agit de mieux cibler les annonces publicitaires en fonction du profil des internautes.

Techniquement, Yahoo utilise PostgreSQL sur environ 1000 serveurs (soit 2 Tera par serveur!).Le volume des mise à jour est lui aussi impressionnant, le flux des clics internaute représente plus de 24 milliards d’update par jour !

Si le sujet vous intéresse vous trouverez plus d’informations ici et ici, ou directement sur le blog de Josh Berkus d’un des ‘core dev’ de PostGreSQL