Le Hadoop Summit arrive en Europe, et pour sa première édition Européenne, c’est la ville d’Amsterdam qui a été choisie.
Beaucoup d’acteurs importants du monde Hadoop étaient présents : LinkedIn, HP, RedHat, Yahoo, HortonWorks, Cloudera, Microsoft, …
L’article qui suit est un retour sur ce qui nous avons de retenu d’un point de vue architecture et technique de ces deux jours riches en conférences.
Une des caractéristiques essentielles d’une infrastructure de cloud est, d’un point de vue du fournisseur de service, la mutualisation des ressources matérielles pour servir plusieurs clients. Ces ressources n’étant pas illimitées, il faut s’assurer qu’elles soient correctement partagées pour assurer les différents niveaux de service envisagés.
Les trois grands types de ressources matérielles à partager sont le CPU, la RAM et les IO (disque et réseau). Pour le CPU, la multiplication des cœurs de processeurs ces dernières années a rendu possible l’affectation de manière dédiée d’un ou plusieurs cœurs à une machine virtuelle. Pour la RAM, il est risqué d’affecter aux VM allumées plus de mémoire que la capacité des serveurs physiques sous-jacents, donc il n’est pas recommandé de faire, au-delà de quelques pourcents du « partage de RAM ». Reste les IO, pour lesquels la mise en place de quota est la solution la plus adaptée. La suite de cet article s’intéresse à la mise en place de quota d’IO disque pour des machines virtuelles.
(Lire la suite…)
Dans l’article Continuous Deployment, nous avons vu comment améliorer le Time To Market, tout en garantissant la qualité des développements.
L’étape suivante est de garantir que ces déploiements fréquents n’impactent pas la disponibilité du site.
Et c’est là qu’intervient le Zero Downtime Deployment (ZDD), qui permet de déployer une nouvelle version d’un système sans interrompre le bon fonctionnement du service.
Mais comment s’assurer d’un déploiement « sans accroc » ?
(Lire la suite…)
Mardi 20 novembre OCTO organisait un petit-déjeuner «Décryptez les secrets des Géants du Web».
Ce petit-déjeuner a eu pour objectif de proposer 10 pratiques pour changer votre entreprise.
« Que vous montiez votre start-up web ou que vous soyez DSI d’un grand groupe, vous trouverez dans ces pages un matériel précieux pour vous hisser sur les épaules des Géants »
Jean-Marc Potdevin, Chief Operations Officer, Viadeo
Dans l’article « Bêta perpétuelle », nous avons vu que les géants du Web améliorent leur produit de façon permanente. Mais comment arrivent-ils à livrer fréquemment ces améliorations alors que dans certaines DSI, la moindre modification peut prendre plusieurs semaines à être déployée en production ?
La plupart du temps, ils ont instauré un processus de déploiement continu (continuous deployment), selon deux modalités possibles :
Evidemment, la mise en place de ce pattern demande certains pré-requis…
Ca y est, vous avez décidé de mettre en place un cluster Hadoop.
Prochaine étape, le dimensionnement… Hadoop étant une solution complexe, plusieurs questions se posent :
C’est ce que nous allons tenter d’éclaircir dans cet article en fournissant des explications sur ces différents points ainsi que des moyens pour calculer vos besoins.
« Everything fails all the time » est l’aphorisme célèbre de Werner Vogels, CTO d’Amazon : il est en effet impossible de prévoir toutes les défaillances qui peuvent se produire sur un système informatique, à toutes les couches : une règle de gestion incohérente, des ressources systèmes non relâchées après une transaction, une panne de disque dur…
Et c’est sur ce principe simple que se basent les architectures techniques des Géants du Web aujourd’hui, rassemblées sous le pattern design for failure, « conçu pour supporter la défaillance » : une application informatique doit être capable de supporter la panne de n’importe quel composant logiciel ou matériel sous-jacent.
À ma gauche, GreenPepper, un outil de tests fonctionnels, destiné aux MOA et leur permettant d’exprimer les spécifications sous forme de tests exécutables.
À ma droite, Team Foundation Server, usine de construction et de livraison de logiciel.
L’idée : lorsqu’un développeur effectue un check-in de son code, les tests GreenPepper sont lancés et le build échoue en cas de problème.
Comment faire ?
Cette épisode sera dédié aux limitations découvertes dans Chef; cet outil, même si je l’adore, n’est pas parfait ! Il est de plus intéressant de constater que les limitations que je vais présenter ici sont souvent aussi présentes dans les outils concurrents.
Le mouvement « DevOps » nous invite à repenser la frontière classique de nos organisations qui séparent d’un côté les études, i.e. ceux qui écrivent le code des applications (les « Dev ») et de l’autre côté la production, i.e. ceux qui déploient et exploitent ces applications (les « Ops »).
Ces réflexions sont certainement aussi anciennes que les DSIs mais elles trouvent un peu de fraîcheur grâce notamment à deux groupes. D’un côté les agilistes qui ont levé la « contrainte » côté développement, et sont maintenant capables de « livrer » beaucoup plus souvent du logiciel valorisé par le client… de l’autre, des experts ou des managers de la « prod » des grands du web (Amazon, Facebook, LinkedIn…) partageant leurs retours d’expérience et la façon qu’ils ont d’aborder la frontière « dev » et « ops ».
