Le Grid sur Amazon EC2

Je ne peux m'empêcher d'immédiatement imaginer des scénarios relatifs à l'utilisation du Grid Computing, dans le cadre d'orchestration de tâches/jobs de type bash.

D'une part, si nous utilisons l'infrastructure Amazon EC2 de façon statique (un ensemble de noeuds définis, comme n'importe quel système on-demand), nous pourrions simplement utiliser un scheduler pour ordonnancer et organiser les jobs. Pas besoin de Grid dans ce cas, il me semble.

Au contraire, si l'on considère l'utilisation de l'auto-scaling, l'utilisation de middleware permettrait de mettre en oeuvre facilement la découverte et mise à jour de la topologie des noeuds disponibles.

Mais l'Elastic Load Balancing ne permet-elle pas de se passer de découvrir les ressources, le Cloud d'Amazon EC2 se chargeant lui même de balancer les tâches "là où il y a de la place" et d'augmenter le Cloud si besoin. Les noeuds reçoivent donc les jobs, les exécutent et envoient les résultats au workflow ou à l'application sensées collecter les résultats.

Premières impressions sur Amazon EC2

Vous avez dit Grid ?

Amazon EC2 est avant-tout un service de fourniture de ressources à la demande (on-demand computing, ou utility computing). C'est à dire un grand parc informatique dont on loue les ressources à la demande.

Amazon EC2 utilise des techniques de virtualisation permettant de créer facilement des instances de ressources utilisables très rapidemment.

En outre, Amazon EC2 offre également quelques fonctions avancées bien pratique :

• Auto-scaling : selon des critères quantitatif relatif par exemple au traffic ou à la charge CPU, Amazon peut dynamiquement créer des instances de ressources supplémentaires (basées sur une configuration définie par l'utilisateur)
• Elastic Load Balancing: Amazon EC2 est capable de distribuer le traffic sur plusieurs machines et d'augmenter le nombre de machine

Par contre, Amazon EC2 ne fait en rien du scheduling, ni de la parallélisation d'application, il offre uniquement une infrastructure utile pour le faire.

Cloud Computing: informatique dans les nuages

Les clés du cloud computing (en construction) dit "informatique dans les nuages"

La mission du GRID était de proposer une solution de virtualisation de ressources mutualisées délocalisées et hétérogènes.

L'objectif du Cloud Computing est de proposer, reposant sur une infrastructure virtuelle, des services d'utilisation des ressources selon différent niveau d'abstraction (infrastructure, plateforme, application).

- Similitudes avec l'utility computing: les ressources/l'infrastucture est gérée par un fournisseur de ressources (provider). Ainsi, plutôt que de virtualiser en un tout des ressources de plusieurs organisations (GRID), le Cloud Computing Provider mutualise son grand parc de ressources gigantesques pour fournir un grand nombre d'utilisateurs. "Le Cloud Computing nécessite d'énormes data centers, Tous les fournisseurs qui se lancent dans le Cloud Computing nécessitent des infrastructures gigantesques. C'est le cas de Google, Yahoo, Amazon et bien d'autres..." (ITR Manager)

- XaaS (x as a service) : fournir les ressources/applications/plateforme comme on fournit un service (service de stockage, service de calcul, service de gestion de documents, ...). Cela inclut souvent un modèle économique de paiement d'application à la demande plutôt que par licence. Ainsi on pourrait commande une application et commande l'espace disque nécessaire pour l'application, ainsi que de la puissance de calcul pour faire tourner l'application.

- Similitude avec le GRID : l'infrastructure sous-jacente est un nuage (Cloud) composé d'un certain nombre de serveurs distants interconnectés au moyen d'une excellente bande passante indispensable à la fluidité du système

Divergences :

- La philosophie du Cloud n'est plus de proposer une solution middleware pour virtualiser un parc de ressources disponibles dans les entreprises. Il s'agit de proposer directement un service de ressources/plateformes/applications disponible directement. Economiquement, on imagine qu'actuellement ce n'est pas plus cher car le parc est mutualisé (ce qui est très rentable) et d'autres part les ressources en elle-même sont bcp moins chères qu'avant.

- Le Cloud veut rompre avec la notion de scheduling et de file d'attente. Le parc (pool) de ressources doit pouvoir supporter tout pic de demande. Finalement, le Cloud s'affranchit de ces questions...

- Le Cloud ne s'attaque pas à la fédération inter-infrastructure sous l'API. Ceci pouvant conduire à des comportements non déterministes et des instabilités. C'est directement intégré dans l'API (---> euh voir ce qu'il veut exactement dire par là)

La philosophie du Cloud Computing est-elle la suivante: plutôt que de réserver X To de données d'espace, l'utilisateur souscrit à un espace disque infini. Il paie ce qu'il utilise. Abstraction donc totale de la taille d'espace disque.