On y voit que les recherches sont corrélées avec la décroissance de celle concernant le grid computing et qu’elles suivent l’augmentation des requêtes concernant la virtualisation.

Bien entendu les intervenants historiques de l’informatique  (Oracle, HP…)  minimisent le côté novateur du Cloud (voire en discute carrément l’existence)  en prétendant ne pas voir de nouveauté dans ces concepts. “Un buzz marketing” sur d’anciennes technologies déjà en oeuvre pour les uns, de multiples définitions sans cohérence pour les autres. Rien d’étonnant me direz-vous, surtout lorsqu’on voit les constructeurs à la peine pour suivre cette nouvelle tendance. En effet, ces derniers tentent toujours de vendre des baies de stockage, des serveurs surpuissant ou des logiciels. dont les  coûts de licences sont calculés par core , a des prix élevés. Parallèlement  de nouveaux entrants se basent sur des paradigmes assez différents des éditeurs et constructeurs actuels, profitant des matériels bon marchés et des logiciels open sources gratuits.

La fin des modèles traditionnels : Pourquoi ?

Cette opposition tant technologique que culturelle semble marquer la fin des modèles traditionnels (ou tout au moins une évolution très notable) qui régissent l’informatique depuis l’avènement des plateforme open (*NIX, windows) alors que les plateformes mainframes régnaient sans partage sur l’informatique. Pour illustrer ce propos, prenons l’exemple du stockage de données, l’un des domaines de prédilection du cloud.

Rappelons l’image courante dans ce domaine : “Chaque année, sont produites autant de données que le cumul des données produites jusqu’à l’année précédente“.  Plus actuellement, en 2008 l’IDC affirme qu’en 2009 40 exabytes de données seront produites. On constate que ces données sont de plus en plus non structurées. Dématérialisation et explosions du multimédia poussent au stockage de vidéo, audio et autre PDF.  Par ailleurs, les exigences des départements commerciaux renforcent également les notions de tracking et de profiling des utilisateurs, afin d’améliorer les performances des différents produits commerciaux. Comment dans ces conditions recueillir, stocker et gérer ces données.

En amont de ce problème de gestion se pose celui des taux transactionnels dans les environnements sécurisés. En effet, dans un contexte mutlicanal, comment garantir le maintien de ces taux transactionnels dans des environnements devant prendre en compte des exigences de hautes disponibilités, de Plan de reprise d’activité… Les réplications standards sont de plus en plus compliquées à mettre en œuvre, exploiter et à garder synchrone (ou tout simplement a en garantir un déphasage minimum). Les problématiques de temps de latences sont par ailleurs elles aussi de plus en plus dures à contenir.

Une fois les données recueillies il faut le gérer. Les gérer oui, parce que les stocker n’est pas suffisant. Vos données doivent être exploitées, retraitées, archivées pour leur donner du sens. Le problème est que ces workflows doivent être de plus en plus rapides (tous les 60 jours sont produits 7 exabytes), alors même que les temps de traitement nécessaires à ces volumétries explosent.

Enfin, parallèlement aux temps de traitement, les coûts de gestion et de stockage de ces données deviennent peu à peu des freins ; certains projet n’étant tout simplement plus rentables du fait des contraintes exposées ci-dessus.

Toutes ces évolutions forcent les entreprises à trouver des solutions quitte à s’éloigner des chemins traditionnels

La fin des modèles traditionnels : Comment ?

Si les offres des constructeurs ne semblent que peu évoluer sur le marché (de grosses baies, avec beaucoup de cache…) de nouveaux entrants sur le marché du stockage font leur apparition, Amazon à leur tête. Amazon vous propose tout simplement de ne pas conserver vos données ou vos traitements dans votre propre SI mais de les lui confier (avec les clauses de confidentialités adaptées) et d’en disposer, dès lors,  via internet.  Le tout a des prix ultra compétitifs !

Cette offre ne fait que repousser la question : comment ces prix peuvent ils être atteints ? C’est qu’Amazon se base sur des technologies fort différentes, tout comme un Google, un Yahoo! ou un Facebook. Le paradigme de départ est totalement différent. On ne parle plus ici de concentrer les données dans des baie hyper protégées et de faire appel à des serveur très haut de gamme pour exécuter les traitements mais bien de répartir données et traitements sur un trés grand nombre de machines d’entrée de gamme (commodity hardware). Cela assure tant la haute disponibilité et que de très bon temps de réponse, le tout à des couts largement en baisse (serveurs très standards, disques SATA, et surtout, économies d’échelles, les commandes auprès des constructeurs étant titanesques), et une scalabilité remarquable. Parce qu’en fin de compte c’est de cela qu’il s’agit : répondre de manière aussi linéaire que possible a la charge, quel que soit le volume de données le tout pour un coût aussi réduit que possible.

En regardant dans le passé de ces géants internet, on se rend compte que tous ont commencé par des offres standard de type LAMP, mais que, la charge augmentant ils ont du développer leurs propres outils pour faire face (en se basant sur des projets, et donc des technologies et protocoles, open source et gratuits). Certains  n’ont publié que des white paper sur leur manière de gérer cette charge (c’est le cas de Google : Big Table et GFS) alors que d’autres ont carrément créé ou contribué très fortement à des initiatives open source et grauite (Facebook : Thrift , Yahoo! : Hadoop …)

Il se développe depuis quelques années des offres de virtualisation (Xen), de cache (memcached développé pour LiveJournal.com) , de File Systems distribués (Caringo, MogileFS, GlusterFS, HDFS) dont la vocation n’est plus de concentrer les données mais bien au contraire de les répartir et de les répliquer sur des matériels a bas prix (commodity hardware), afin d’en exploiter au mieux les ressources.

Une rupture technologique mais surtout culturelle est bien en train d’avoir lieu quoi que puissent en dire certains géants.

Attention, peinture fraîche

Etrangement les offres d’un Amazon semblent elles assez au point. Depuis Janvier 2008, d’ailleurs, la bande passante utilisée pour les web service d’Amazon (AWS, les offres de cloud) est supérieure à la bande passante utilisée par le reste des sites web Amazon. Cela indique le nombre de leur client augmente très rapidement et que les données stockées par eux explosent. On est donc passé de la commercialisation de capacité inutilisée a un véritable business, qui , pour avoir rencontré les personnes d’Amazon semble être organisé avec une rigueur martiale. Et la, au contraire, si les noms des clients sont assez durs à avoir (on le comprend aisément) Amazon affiche néanmoins des références solides (NASDAQ, Wall Street Journal, …), et le recul est certains, ces offres étant la base du business d’Amazon depuis un moment déjà.

Alors certes les constructeurs tendent a se rapprocher de ce modèle, mais leurs offres commerciales sont-elles encore adaptées. Je ne parle pas seulement des technologies qui sortent de leurs laboratoires (pas de soucis pour ces dernières qui sont issues en droite ligne des technologies open source qui font la gloire des géants internet) mais surtout des offres commerciales avancées par leur commerciaux ? Assez étrangement, malgré toutes les annonces faites par les constructeurs majeurs, sur l’importance du Cloud et de ses implications, ces commerciaux tardent toujours à proposer des solutions « modernes », ils se font même un peu prier. On les comprend ces offres paraissent bien récentes et « pas encore sèche ». Pas ou peu de recul, très peu de clients et un supports dont la qualité semble faible, tant l’évangélisation dans ces société même semble en retard.

• BigTable (Google)
• Dynamo (Amazon)
• Cassandra (Facebook)
• Voldemort (tres rapidement)
• memcached
• Tokyo Cabinet
• Redis
• CouchDB
• MongoDB
• Vertica
• Hadoop (Evoqué en 3 secondes dans les questions et réponses)

1. La vision logique/physique
2. La vision par groupe de composants informatiques (logicielle, matérielle, middleware, réseau…)
3. La vision par technologie informatique (multicouche, web, EAI, CRM, ERP…)
4. La vision par contraintes (Architecture haute disponibilité : faible taux de pannes,
5. Architecture massivement parallèle : forte capacité de calcul, Architecture sécurisée : contrainte de sécurité)

Face à cette pluralité de point de vue des cadres d’architecture sont communément employés dans la gouvernance ((Le critère essentiel d’une bonne gouvernance est que les mécanismes de fonctionnement de l’institution soient organisés de façon à éviter que les intérêts des mandatés prennent le pas sur ceux de leurs mandants .)) des technologies de l’information et des systèmes d’information. Une organisation peut souhaiter que certains modèles soient obligatoires pour la validation d’une conception de systèmes. De même, elle peut souhaiter spécifier que certaines vues soient employées dans la documentation des systèmes achetés.

C’est un produits EMC² permettant de répliquer les données entre plusieurs sites, et ne fonctionne donc a priori que sur des baies EMC². C’est mécanisme hardware, qui ne se préoccupe pas de la nature des informations qui sont stockées sur les disques.

Il est possible de faire du SRDF synchrone sur des cluster geospan (surcouche applicative windows) entre des sites distants de 10-15 km. Pour des sites plus distants on utilise le SRDF asynchrone, ce qui permet de faire de la sauvegarde a J-1. On pourrait faire des fréquences plsu rapprochées mais généralement cete solution n’est utilisée que pour des sauvegardes de la veille.

Les BCV

Phase 1 : Un serveur voit un disque (le STD, standard). Pour lancer le procesus de réplication, à ce jour on gèle les IO, soit par surcouche applicative, soit généralement on fait un arrêt applicatif. Une fois cela fait, on génère un ordre de ‘establish BCV’. Cet establish compare le STD et le BCV (jeu de disque dédié pour etre miroir du STD) pour connaître les différences (en terme de piste physique). Il recopie ces différences du STD vers le BCV.

Le BCV (sur le site primaire) peut être appelé R1 (premier réplicat).

Il faut noter que le gel des IO n’est pas obligatoire, cependant il permet à la synchronisation du BCV de se faire beaucoup plus rapidement.

Phase 2 : le split : On doit figer l’image BCV lorsqu’elle est complètement conforme a la source. A ce moment du process, le gel IO est obligatoire (souvent obtenu par un arrêt applicatif).

Phase 3 : Entrée en jeu de SRDF : Une fois que le BCV est cohérent avec le STD, on utilise le même mécanisme distant. Le R1 est recopié sur le R2 (image disque sur le site distant), par un establish (réplication des pistes modifiée) puis un split quand les deux volumes sont équivalents.

Il est toujours possible de rajouter un BCV au R2, afin d’être plus secure dans le cas de PRA. En effet lorsque ,sur le site 1, la baie pète lors de l’establish R1-R2, il est toujours possible d’avoir un R2 incohérent.

Le process le plus sur pour etre couvert dans tous les cas est donc le suivant :

1 - establish R2-BCV du R2
2 - gel des IO prod
3 - establish prod
4 - split BCV R1
5 - relance des IO prod
6 - lancement establish SRDF R1-R2
7 - split image SRDF R1-R2

Ce cycle permet de s’assurer dans tous les cas qu’on aura soit R2 ok soit BCV R2 ok : on a toujours une image qui permettra de répartir.

Généralement du fait des problématiques de budget le BCV de R2 est rarement fait.

Si on fait du fil de l’eau sur le SRDF R1 R2, on augmente le risque d’avoir un R2 incohérent.

En cas de problème sur le site principal

On peut utiliser l’image BCV pour autant qu’on ne se trouve pasdans la phase 3. On peut alors réattacher les BCV sur le serveur primaire, afin de pouvoir les accéder en lecture. On peut également utiliser un autre serveur pour y atacher les BCV (ce qui permet soit de relancer l’appli soit de faire les sauvegardes), ou (au pire) ecraser les STD avec le R1.

Il faut prévoir des le départ le R1 le STD et le R2 , car ce paramétrage prend beaucoup de temps et implique nécessairement une intervention de la part d’EMC².

Il existe d’autre mécanismes qui font que ce sont les baies qui gèrent ces réplication et plus les serveurs comme c’est le cas aujoud’hui