Dans cette partie, nous nous intéressons au modèle de fédération qui résout en partie les problèmes liés la concentration des ressources de calcul dans quelques mégas centres de données.
Dans la section1.3, il été montré que l’informatique utilitaire venait d’une analogie entre ressources électriques et ressources de calcul : des utilisateurs consomment la de- mande des ressources de calcul produites par des fournisseurs d’infrastructure de Cloud Computing. Ce modèle a inspiré les grilles de calcul et les infrastructures de Cloud Com- puting : dans le modèle électrique, les centrales électriques sont fédérées au sein d’un réseau électrique et quand la demande devient supérieure à la capacité de production d’une seule centrale électrique, la demande non satisfaite est déléguée aux autres cen- trales électriques. Les grilles de calcul sont allées au bout de cette analogie : pour offrir le plus de ressources de calcul à leurs utilisateurs, celles-ci ont très tôt été fédérées. En ce qui concerne le Cloud Computing, la fédération d’infrastructures IaaS été un sujet de recherche qui a émergé en 2009 avec en Europe les travaux autour du projet RESERVOIR [39], tandis qu’en parallèle l’équipe de Nimbus proposait de faire des infrastructures de Sky computing fédérées autour de son gestionnaire Nimbus [40].
La fédération d’infrastructures de Cloud Computing, ou fédération de nuages, est une technique permettant à un fournisseur d’étendre son infrastructure en lui ajoutant des ressources issues d’autres fournisseurs, dont les infrastructures ne sont pas surchargées. La connectivité entre les ressources issues de différents fournisseurs est assurée au moyen d’un lien réseau privé ou du réseau Internet. Cette approche est la première étape pour offrir une gestion plus raisonnable des pics de consommation. En effet, sans technique de fédération, les fournisseurs habituellement surdimensionnent leurs infrastructures afin d’éviter de se trouver en défaut de ressources comme lors des pics de consommation [41]. Ce surdimensionnement baisse l’efficacité économique de l’infrastructure, car en dehors des pics de consommation une partie de l’infrastructure est inutilisée et donc coûte de l’argent sans en rapporter. À l’inverse, la fédération permet de garder une infrastructure de taille suffisante pour une consommation normale en dehors des pics de consommation et de déléguer à des fournisseurs externes une partie de la charge induite lors d’un pic de consommation. Enfin, la fédération d’infrastructures permet d’agréger des ressources de plusieurs infrastructures, ce qui permet aux services qui y sont hébergés d’avoir accès à une plus grande quantité et variété de ressources qui deviennent virtuellement infinies dans le cas de fédérations impliquant de gros fournisseurs tels qu’Amazon ou Microsoft. Ce mythe de la ressource infinie est un des piliers du Cloud Computing.
Le paysage du Cloud Computing est assez varié et on peut trouver de nombreuses technologies de gestionnaire IaaS ainsi que de nombreux acteurs de tailles diverses. Cette variété explique les nombreuses architectures de fédérations d’infrastructures de Cloud Computing qui ont émergé. Les auteurs de [25] se sont intéressés à la définition des
3.2. Fédérations de nuages 45 grandes tendances architecturales pour la fédération d’infrastructures de Cloud Compu- ting, et ont mis en évidence que les fédérations pouvaient être classées selon deux critères : • Degré de couplage entre les infrastructures composant la fédération. Le couplage peut être assimilé au degré de contrôle qu’une infrastructure a sur les autres infra- structures de la fédération. Ainsi, plus le couplage sera fort, plus le contrôle d’une infrastructure sur les autres infrastructures de la fédération pourra être intrusif. À l’inverse, un couplage faible signifie que les infrastructures n’ont qu’un accès limité sur les ressources externes.
• Nombre d’organisations impliquées dans la fédération. Une fédération d’infra- structures appartenant à des entreprises différentes impliquera l’établissement de contrats régulant la consommation par un des partenaires des ressources des autres partenaires, ce qui ne sera pas forcément le cas d’une fédération d’infrastructures appartenant à une unique organisation.
À partir de ces critères, quatre modèles de fédération ont été dégagés : Bursting, Bro- ker, Aggregated et Multitier. La suite de cette partie traite de ces modes de fédération, s’intéressant à leur description ainsi que leurs caractéristiques mises en évidence par [25].
3.2.1
Bursting (Cloud hybride)
Cloud public 1 Cloud public 2 Centre de données
Cloud d’entreprise
Ges4onnaire IaaS
FIGURE3.2 : Schématisation d’une fédération reposant sur une architecture de type Burs- ting([25]).
46 Chapitre 3. Paysage des infrastructures IaaS et Edge Computing Dans ce modèle de fédération d’infrastructures IaaS, un fournisseur combine son in- frastructure avec des ressources issues d’autres fournisseurs, afin de proposer à ses utili- sateurs de consommer une agrégation de ses ressources avec des ressources issues d’in- frastructures externes. Le Bursting est généralement utilisé pour faire face à des pics de consommation. Ainsi plutôt que de surdimensionner son infrastructure pour faire face à de rares pics de consommation, le fournisseur va ponctuellement déléguer une partie de la charge de travail excédentaire à des fournisseurs tiers. Comme illustré dans la figure 3.2, le fournisseur initial a cependant une visibilité limitée sur les ressources appartenant aux fournisseurs externes, car il n’appartient pas à la même organisation que les autres fournisseurs et a une visibilité identique à celle des clients de ces derniers. En ce qui concerne l’organisation de la fédération, c’est l’infrastructure du fournisseur initial qui est en charge d’exploiter la fédération, les autres infrastructures n’ayant pas conscience de cette fédération.
3.2.2
Broker
Cloud public 2 Cloud public 3 Cloud public 1 Intermédiaire IaaS (Broker)FIGURE3.3 : Schématisation d’une fédération reposant sur une architecture de type Bro- ker([25]).
Ce modèle de fédération est le plus courant, et comme le montre la figure3.3, un com- posant central (Broker) sert d’intermédiaire entre les utilisateurs d’une fédération d’infra- structures IaaS et les infrastructures qui la composent. Le Broker reçoit les requêtes des utilisateurs et s’occupe de les satisfaire en déployant des ressources au sein des infra- structures impliquées dans la fédération. Les Brokers les plus avancés sont capables de
3.2. Fédérations de nuages 47 prendre des décisions de placement des ressources qui optimisent les coûts financiers, énergétiques, et certains peuvent même faire varier le degré de distribution des ressources en les répartissant sur plusieurs infrastructures pour des questions de tolérance aux pannes notamment.
Cependant le Broker n’a qu’une vision réduite des infrastructures impliquées dans la fédération, ce qui limite les possibilités de la fédération au plus petit commun dénomina- teur des fonctions offertes par celles-ci. Enfin, il est courant que le Broker soit un com- posant centralisé, ce qui signifie qu’en cas de panne de ce dernier les utilisateurs perdent l’accès à l’infrastructure fédérée. L’infrastructure se met alors à fonctionner de manière dégradée. Une solution consiste alors de distribuer le Broker avec des mécanismes de tolérance aux pannes.
3.2.3
Aggregated
Centre de données Cloud d’entreprise A Ges,onnaire IaaS Centre de données Cloud d’entreprise B Ges,onnaire IaaSFIGURE 3.4 : Schématisation d’une fédération reposant sur une architecture de type Ag- gregated([25]).
L’agrégation d’infrastructures de Cloud Computing est un modèle où plusieurs four- nisseurs s’accordent pour combiner leurs infrastructures afin d’offrir à leurs utilisateurs une plus grande quantité de ressources de Cloud Computing. Avec ce mode de fédération, on observe un couplage variable entre les infrastructures, selon qu’elles appartiennent ou non à la même organisation :
Dans le cas où les fournisseurs appartiendraient à des organisations différentes, la coopération se fait dans le cadre d’un contrat définissant dans un premier temps les condi-
48 Chapitre 3. Paysage des infrastructures IaaS et Edge Computing tions de l’accès que les utilisateurs d’une organisation vont avoir sur les infrastructures des autres organisations (afin de garantir qu’une infrastructure ne vampirisera pas les autres), et dans un deuxième temps le degré d’intrusion d’une organisation sur les infrastructures tierces (comme en autorisant un certain contrôle sur les politiques d’ordonnancement en forçant le placement de machines virtuelles sur le même cluster). Ce cas correspond à un cas de couplage faible entre les infrastructures.
À l’inverse, si l’agrégation se fait entre des infrastructures appartenant à une même organisation, l’intrusion d’une infrastructure sur les autres infrastructures sera plus faci- lement tolérée, aboutissant à une situation de couplage fort entre les infrastructures.
3.2.4
Multitier
Centre de données Site 1 Ges,onnaire IaaS X Centre de données Site 2 Ges,onnaire IaaS Y Ges,onnaire IaaS ZFIGURE 3.5 : Schématisation d’une fédération reposant sur une architecture Multitier ([25]).
Ce modèle de fédération s’intéresse à la mise en place d’une infrastructure de Cloud Computing distribuée sur plusieurs sites géographiques (multisite), où chaque site géo- graphique héberge une infrastructure IaaS complète. Celles-ci sont regroupées au travers d’une infrastructure hiérarchique où au niveau supérieur se trouve un gestionnaire IaaS en charge de piloter les gestionnaires IaaS situés sur chacun des sites. Ce gestionnaire IaaS supérieur sert d’intermédiaire avec les utilisateurs sur un modèle proche de la fédération à base de Broker introduite dans la section3.2.2.
En général, les infrastructures appartiennent toutes à une même organisation, ce qui autorise un degré d’intrusion maximal du gestionnaire IaaS supérieur dans les infrastruc-
3.3. Du modèle d’Edge Computing au Fog Computing 49