Haute-Disponibilite

Les équipes de Google viennent d’annoncer qu’ils avaient batu le record du benchmark Terabyte. Ce test consiste à trier un TéraOctet de données le plus rapidement possible. Cela représente le tri de mille millions de lignes, et cette performance a été réalisée en 68 secondes.

Depuis 1998 nous sommes donc passés de plus de 2 heures, à 30 minutes en 2004, 3 minutes en 2007 et enfin 68 secondes cette année. Le précédent record, obtenu par Yahoo en utilisant le couple Java/Hadoop était de 209 secondes sur ce cluster :

Lire la suite »

Pas de commentaires sur les fluctuations boursières ici mais une information sur le déploiement de la dernière série d’IBM : les iDataPlex. Cette gamme est dédiée aux centres de calcul et ils sont optimisés au niveau électrique et énergétique.

C’est justement ce qui est recherché par Merrill Lynch dans cette opération, obtenir de grosses capacités de calcul pour pouvoir modéliser et analyser les risques de leurs produits financiers. L’architecture innovante de cette gamme permet en effet de concentrer dans un petit volume (à partir de deux baies) une centaine de serveurs avec une consommation électrique et un dégagement calorifique très faible. Attention sur ce dernier point, la porte avec fluide de refroidissement est une option, et votre datacenter doit être compatible (arrivée d’eau).
Lire la suite »

Voici un exemple concret d’utilisation du système de fichier Lustre dont je vous parlais dans ce billet. En effet pour gérer de tels volumes il n’existe pas beaucoup de solutions sur le marché. En tout cas c’est celle qui a été retenue par les équipe du CINES (Centre Informatique National de l’Enseignement Supérieur) pour l’élaboration de leur dernier cluster de calcul.

Grâce à ce cluster la recherche française remonte à la 3ieme place mondiale en terme de puissance de calcul, avec un total de 470 Téraflop.

Au niveau technique, ce supercalculateur scalaire parallèle est composé de : Lire la suite »

Lors de la dernière conférence LinuxWorld, John Engales le CTO de Rackspace a présenté les différentes étapes de la vie d’un site web. Et même si chaque site possède sa problématique il est toujours intéressant de voir qu’il existe un schéma général.

En quelques lignes voici donc les différentes versions d’une infrastructure web typique, j’ai simplement changé deux points (en gras et/ou barré) qui sont plus proches de la réalité des cas que je rencontre de ce coté de l’atlantique :

• Etape 1 : Architecture simple, pas de redondance, pas de complexité. Un firewall, un serveur Web et une base de données avec stockage local (load balancer web, rare à ce niveau).

• Etape 2 : La même chose mais avec un load balancer sur deux serveurs web et une base de données un peu plus puissante

• Etape 3 : Mise en place d’un reverse proxy, d’un cache statique et de load balancers sur les bases de données (avec synchro master/slave par exemple). Il faudra prévoir quelques recodage à cette étape.

• Etape 4 : La complexité commence : Ajouter du memcached (ou autre), les réplications entre les bases de données deviennent trop gourmandes en ressources et il va falloir commencer le split horizontal (partitionnement des données, nécessitant un re-design des BDD). A ce niveau la mise en place de serveurs dédiés en fonction du contenu a du sens.

A partir d’ici les choses commencent vraiment à devenir sérieuses, bonne nouvelle pour le trafic du site ou du service mais il va désormais falloir assurer une disponibilité sans faille. Lire la suite »

Le dernier rapport de ViriSign nous apprend que la charge globale de leur infrastructure a de nouveau dépassé un record avec un pic journalier de 48 milliards de requêtes. Cela représentre plus de 500 000 requêtes DNS par seconde sur les TLD (Top Level Domain) .com et .net. Ce chiffre représente un doublement du trafic par rapport à l’année dernière.

C’est pour cette raison que VeriSign investit massivement dans l’amélioration de son infrastructure. Cet investissement de plus de 100 millions de dollars doit permettre le traitement de 4 trillions de requêtes par jours à horizon 2010 (soit quatre milles milliards de requêtes en échelle courte). Lire la suite »

Le choix d’une base de données pour gérer les services vitaux d’une société n’est jamais trivial. Dans le monde de la finance ou des telecom Oracle remporte souvent la mise grâce à ses capacités de clusterisation sur plusieurs serveurs (Oracle RAC).

Cette version offre en effet des mécanismes de répartition de charge et de reprise sur erreur automatique extrêmement robustes. Malheureusement l’addition des coûts nécessaires à la mise en place d’une telle architecture n’est pas toujours compatible avec les budgets des applications et services Web.

Pour répondre à cette problématique il existe une version modifiée de MySql, la version Cluster. Cette version est optimisée pour être extrêmement disponible. 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 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 »