Les points à vérifier pour fiabiliser votre architecture

October 28, 2008

Il est parfois utile de faire une pause dans l’exploitation quotidienne pour vérifier que les optimisations et contrôles basiques sont bien en place. C’est ce que propose cette petite liste. Elle vous permettra de vérifier que rien ne vous échappe dans votre architecture. Elle provient du blog www.productionscale.com, et plus précisément de cette note à propos de la planification et du suivi d’un système.

Voici un résumé de cette note qui regroupe un ensemble de bonne pratique  :

  • Gérer le déploiement : Votre système de publication doit intégrer un workflow précis, gérer les versions et le retour en arrière en cas de problème. De plus le déploiement doit être complètement automatique et indépendant du parc matériel.
  • Découpage fonctionnel : Décomposer votre application en silos fonctionnels afin de disposer de composants optimisés par tache.
  • Partitionner vos données : Séparer les requêtes de lecture et d’écriture, et dès le début penser à un moyen de diviser/partitionner vos bases.
  • Séparer les contenus dynamiques et statiques : Vous pourrez plus facilement les gérer grâce à des reverse proxy ou via un CDN. Lire la suite »

La gestion des risques chez Merrill Lynch avec les iDataPlex d’IBM

October 16, 2008

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 »


JADE : 12288 cœurs, 46To de RAM et plus de 500To de disque

September 30, 2008

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 »


Planning des évolutions de votre architecture web

September 25, 2008

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 »


48 milliards de requêtes DNS par jour chez VeriSign

September 8, 2008

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 »


L’architecture du site LinkedIn : Java et hautes volumétries

August 27, 2008

Lors de la dernière conférence JavaOne (organisé par Sun Microsystems) un des membres de Linkedin à donné plusieurs informations à propos de l’architecture du site. Plusieurs points à retenir de cette intervention. Le Java, des statistiques sur les volumétries et la mise en mémoire du graphe.

Le premier point concerne donc les volumétries. Linkedin est un réseau social dont le but principal est la mise en relation professionnelle (en France il existe Viadeo). Actuellement le réseau Linkedin comporte plus de 25 millions de membres, cette communauté génère 40M de PV/jour, 2M de recherche par jour et plus de 50M d’email par mois.

Pour gérer ces volumes les concepteurs utilisent quasiment exclusivement Java (98% du code). Les services fonctionnent sur l’OS Solaris et sur des serveurs Sun x86 et Sparc. Les serveurs applicatifs tournent eux sous Tomcat et Jetty, enfin les bases sont gérées avec Oracle et MySql, le search fonctionne lui directement avec l’API Lucene.

Reste le coeur du système, le graphe des utilisateurs… Lire la suite »


Améliorer les performances d’un site : MemCached ou MySql

August 25, 2008

Si vous devez gérer des pics ou des fortes charges sur vos serveurs la mise en place d’un cache est quasiment obligatoire. Il existe plusieurs techniques pour mettre en place du cache. Historiquement l’outil idéal pour ‘cacher’ une base c’est MemCache. En effet, Memcached est parfait pour aider une base de données sur laquelle les requêtes sont complexes ou dans le cas qu’une base non/mal optimisée.

Néanmoins si vos requêtes et/ou vos pages sont personnalisées la taille du cache va rapidement devenir un problème. Et pour ce type de problématique MySql peut être la solution.

En effet si vos données sont trop importantes ou trop diverses pour tenir en mémoire, vous aurez intérêt à modéliser votre base de manière optimale. Cela parait évident mais malheureusement le temps et les ajouts fonctionnels ne permettent pas toujours d’être dans une situation parfaite. C’est pour cette raison qu’il est parfois important de reposer les bases de votre modèle. Lire la suite »


Croissance et économie d’échelle

July 20, 2008

croissance-serveurLa 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 »


Lustre : Système de fichier hautement distribué

June 30, 2008

lustre systeme de fichier 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 »


VMware HA, Virtualisation et haute disponibilité

June 28, 2008

wmware logoPour 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.

haute disponibilité virtuelle

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 »