Haute-Disponibilite

Avec plus de 10 000 serveurs, FaceBook continue sa progression. Aujourd’hui nous apprenons (via ce post) que le site gère plus de 10 milliards de photos ! Après le passage du cap des 100 millions d’utilisateurs actifs dans le monde (en Aout dernier) c’est un nouveau record qui vient d’être battu. Dans cette note nous apprenons également que le site gère désormais :

• Plus d’un pétaoctet de stockage pour les photos.
• La livraison de 15 milliards d’images par jour.
• Et tous les jours plus de 2.3 téraoctets de photos sont téléchargées sur le site. Lire la suite »
  

Après avoir étudié les différentes étapes de la vie d’un site Web je vous invite aujourd’hui à découvrir le modèle CMMI. En effet maintenir la haute disponibilité d’un service c’est avant tout mettre en place une architecture et des procédures permettant de gérer les aléas de votre système. Il est composé, à minima, des deux éléments suivants :

• Des équipes compétentes et expérimentées respectant un ensemble de bonnes pratiques.

• Un système complètement redondant et automatique sur lequel les équipes n’agissent qu’en suivant une procédure validée.

Certes, présenté comme ça c’est un peu ‘froid et rigide’ mais l’expérience prouve tous les jours que les incidents ont souvent pour cause le non respect d’une procédure, ou un agissement imprévu et non étudié avant son exécution (souvent en réaction à un autre problème d’ailleurs).

Éliminer les réactions non planifiées est un des points permettant de passer au niveau supérieur du modèle CMMI. C’est pour cette raison que je vous parle de CMMI, parce qu’il regroupe un ensemble de méthodes et de bonnes pratiques vous permettant de passer : 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 »

Deux articles intéressants de la part d’Amazon et de Microsoft Research aujourd’hui. Tous les deux sur la gestion et le traitement des hautes volumétries. Tout d’abord une petite bible à propos des possibilités d’Amazon. Ce document regroupe une description des différents services d’Amazon ainsi que quelques exemples d’utilisations. Tout le monde n’a pas besoin de traiter des Tera de données mais il est toujours intéressant de comprendre comment il est possible de traiter l’impossible…

L’original se trouve directement chez Amazon (et vous pourrez lire une rapide description sur cet excellent résumé)

Le second concerne l’optimisation et le traitement parallèle. Lire la suite »

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 »

A cette heure ce n’est encore qu’une rumeur mais il semblerait que Google soit en train de préparer une offre de service sur sa BigTable (il s’agit d’un service similaire à SimpleDB d’Amazon).

Pas beaucoup plus d’information pour le moment mais si cela se confirme le Clouds Computing va pouvoir réellement commencer. D’autant qu’en terme de disponibilité Google est mieux armé qu’Amazon (qui à connu un incident grave il y a quelques mois, privant ainsi beaucoup de Start’up de leurs services).

Il restera quand même la question des transferts réseau car ce type de service est utilisé pour faire des calculs sur des quantités énormes, et dans ces cas les upload et download de données risque d’être long. Sauf si Google propose d’autres service avec son offre, permettant notamment de récupérer directement des données depuis les caches ou index Google.

A suivre…

Update  : En complément n’oubliez pas de consulter la page de référence des commandes Python

Voici un petit tutorial pour installer ce que je considère comme étant le meilleur couple pour éditer du Python, a savoir :

Eclipse + PyDev.

Pour installer Pydev dans Eclipse vous devez aller dans le menu d’installation :

Selectionner ‘Search for new features for install’

Dans l’écran suivant, cliquez sur ‘new remote site’

Configurer la fenêtre avec cette URL : http://pydev.sourceforge.net/updates/
NOTE: Si vous souhaitez utiliser la version commerciale, vous devez utiliser l’URL suivante : http://www.fabioz.com/pydev/updates

Lire la suite »