L’idée derrière le cloud est de mettre à disposition sous forme de service à la demande les ressources informatiques (calcul, stockage et réseau). Ainsi, tous les acteurs que l’on rallie au terme “cloud” s’accordent sur une logique “as a service”.
Trois grandes familles de solutions cloud sont distinguables à ce jour :
Nous voyons actuellement un nouveau type de solution émergent sur le marché que certains nomment le CAAS pour Container as a service. Il s’agit de fournir des conteneurs léger linux pour héberger les briques applicatives sur des machines virtuelles ou physiques.
Ces différentes familles sont plus à voir comme des niveaux d’abstraction allant de l’infrastructure à l’application, avec une visibilité de la valeur de plus en plus forte pour l’utilisateur final.
On parle de cloud privé lorsque les ressources cloud sont destinées à l’usage exclusif de l’entreprise. L’infrastructure peut être gérée directement par l’entreprise (cloud privé interne) ou hébergée par un prestataire (cloud privé hosté).
Ce type de solution s’oppose aux offres cloud public comme AWS EC2 ou Google Compute Engine dont les ressources sont mises à la disposition de l’ensemble des clients. Il n’existe pas à ce jour d’offre de type cloud privé directement packagé et installable sur une infrastructure. Cela n’aurait d’ailleurs probablement pas beaucoup de sens car l’avantage principal que l’on tire de ce type de déploiement est la personnalisation. Qu’il s’agisse de déploiement, de supervision, d’architecture logicielle ou réseau, chaque entreprise adresse des besoins différents. Il devient possible d’adresser les problématiques qui sont propres à chacune d’entre elles. Il sera toujours possible de s’orienter vers l’hybridation cloud public / cloud privé pour adresser les débordements de capacité liés à des évènements particulier comme les JO par exemple. Sans oublier qu’en passant vers une offre publique, les systèmes doivent être intégralement repensés pour rentrer dans les normes du fournisseur retenu.
Prenons maintenant un exemple justifiant la mise en oeuvre d’une solution privée : l’entreprise dispose déjà d’une infrastructure dont l’opex (coût courant pour exploiter le produit) ne cesse de croître, chaque nouveau projet nécessite l’achat de nouvelles machines qui devront être à leur tour opérées. Pourtant, toutes ces ressources ne sont pas exploitées au maximum. Tout comme nous ne sollicitons à tout instant qu’une petite partie des capacités de notre cerveaux, la grande majorité des serveurs déployés est, la plus grande partie du temps, inutilisée. Pour optimiser l’utilisation de ces ressources, la virtualisation s’avère nécessaire. Malheureusement, nous reproduisons les schémas de nos infrastructures physiques dans les infrastructures virtualisées. En somme, même nos machines virtuelles ne consomment pas l’intégralité des ressources qui sont à notre disposition. Par conséquent, nous nous retrouvons avec des serveurs physiques qui travaillent principalement à faire tourner des machines virtuelles qui elles-même travaillent peu. Dans ce cas, il devient intéressant de dépasser le cap de la virtualisation simple pour tirer partie au mieux de l’existant grâce à un Cloud privé. Cela permet à terme d’optimiser les coûts d’infrastructure et d’opération tout en affinant le planning capacitaire.
Le cloud privé peut aussi s’avérer être une bonne alternative, si l’on considère la transformation nécessaire des services existants. Si, construire un produit nouveau, sans dépendance particulière à l’existant, sur une offre publique s’avère aisé, migrer un produit existant peut facilement devenir un cauchemar. En imaginant que vous disposez d’un cloud privé, la migration des projets existant vers la-dite plate-forme s’avérera sensiblement plus simple car elle répondra d’emblée à vos besoins. De plus, ces difficultés rencontrées pourront être résolues plus facilement en réalisant des adaptations de votre offre privée plutôt qu’en ouvrant des tickets chez un fournisseur qui n’en a cure.
Outre ces 2 exemples, il existe bien des raisons de s’orienter vers la construction d’un cloud privé allant de la souveraineté de vos solutions à l’avantage concurrentiel non négligeable que cela peut vous apporter.
Les premières briques doivent permettre de construire ce que nous appellerons un système d’exploitation cloud (cloud operating system).
Un tel système se compose de trois solutions indépendantes, qui sont probablement les toutes premières briques dont vous devrez disposer pour édifier votre solution de cloud privé.
Cette partie est responsable de la virtualisation des ressources de mémoire vive et de calcul de votre infrastructure. Il s’agit ici, principalement de bénéficier d’une méthode permettant de virtualiser des serveurs.
Parmi les solutions opensource, nous retiendrons Xen et KVM, Xen étant les leaders incontestés du marché. Parmi les références nous retiendrons Amazon EC2, et Rackspace qui utilisent Xen pour virtualiser les infrastructures. Du côté de KVM, vous pourrez vous orienter vers ProxMox ou Redhat Enterprise Virtualization. Ces solutions de virtualisation permettent de gérer plusieurs hiperviseurs faisant tourner de nombreuses machines virtuelles.
A ce jour, les déploiements Xen et KVM adressent des échelles relativement différentes, Xen est utilisé chez AWS pour des dizaines de milliers de serveurs là où KVM est une solution plus récente et moins largement déployée.
Du coté des solutions éditeurs, les équipes d’infrastructure pourront s’orienter vers les solutions VSphere de VMWare et HyperV de Microsoft. A ce jour, VMWare bénéficie d’un léger avantage sur le marché du fait de la maturité de sa solution. Cela étant dit, les différences techniques sont ténues et tendent à se réduire avec la forte croissance de Microsoft sur ce marché. Nous ne nous pencherons pas ici sur le détail du pricing et du niveau de support fournit par ces deux fournisseurs.
Dans cette partie, nous cherchons une solution permettant d’adresser la connectivité réseau entre les machines virtuelles. Dans l’idéal, cette connectivité doit être isolée par groupe logique de serveur, il n’y aucune raison pour que votre plate-forme de recette puisse voir la plate-forme de production. Comme toutes autres solutions orientées cloud, la couche réseau doit pouvoir être scalable et indépendante de l’architecture du réseau physique. Autrement dit, vous devez facilement pouvoir ajouter des machines et réseaux isolés sans avoir une grande adhérence à l’infrastructure. Outre la fourniture de firewall, votre solution doit aussi vous permettre de gérer la répartition de charge entre les serveurs d’une même application. La technique principale utilisée dans ce cas sera la Virtualisation du réseau ou Network Virtualization. La variété des solutions est telle que nous ne les listerons pas dans cet article. Vous pouvez toutefois noter l’existence d’openVSwitch et OpenContrail en open source, sachant que les éditeurs déjà mentionnés fournissent eux aussi des solutions dans leurs offres.
Dans cette partie, nous souhaitons adresser la problématique de la persistance et du partage des données sur disques entre les machines virtuelles. En effet, elles ne vous serviront à rien si elles ne bénéficient pas d’un disque dur persistant, entre les redémarrages. D’autres part, les serveurs ont régulièrement besoin de partager des ressources sur disque (fichiers images, html, configuration, …). Un cloud privé doit donc bénéficier d’une solution de stockage sur disque qui puisse être gérée globalement pour l’ensemble des machines virtuelles. Vous pourrez alternativement ici, tirer partie des disques de vos hyperviseurs, ou reposer sur des baies de stockage ou encore via des systèmes de fichiers réseaux comme NFS.
Outre la simple gestion des disques de vos machines virtuelles, cette solution doit pouvoir être utilisée comme capacité de stockage à bande large accessible via des API comme le sont les solutions DropBox, Amazon S3, ou Google Drive. En effet, pour votre cloud privé vous pouvez requérir une offre de stockage à distance garantissant vos données. Pour adresser ce dernier besoin, vous aurez besoin d’un système de fichier distribué comme Ceph pour n’en citer qu’un.
Vous connaissez maintenant les premières briques de votre cloud privé mais nous ne sommes pas encore au bout du chemin car il nous manque un point essentiel du cloud, l’automatisation.
Dans le IAAS, l’automatisation doit se jouer à deux niveaux :
Le principe d’une couche d’orchestration cloud est de créer le liant entre les différentes briques que nous avons listées, de façon à fournir une interface unifiée permettant de les administrer et utiliser.
Outre l’interface graphique, la couche d’orchestration va exposer des API permettant de créer des infrastructures de manière programmatique. Dans la plupart des cas, les API sont voulues compatibles avec celles fournies par AWS.
La couche d’orchestration agit donc comme une sorte de chef d’orchestre chargée de mettre en musique les briques d’un cloud privé. Certains mentionnent l’orchestration comme le système d’exploitation du cloud lui même. Cette couche n’est pas essentielle, mais elle simplifie grandement les choses en centralisant tous les outils en un seul. Tout comme un système d’exploitation, elle vous apporte la gestion des utilisateurs et des rôles ainsi que la notion de zone permettant de gérer plusieurs DataCenters.
Un dernier avantage à mettre au crédit des couches d’orchestration est la possibilité de supporter les différents hyperviseurs du marché.
Il existe, sur le marché open source, deux solutions ayant le vent en poupe. La première que nous mentionnerons est OpenStack. Cet ensemble de projets développé par un grand nombre de contributeurs est largement soutenu par des grandes entreprises du secteur IT parmi lesquels nous pouvons citer HP, IBM, RedHat et RackSpace. OpenStack est une solution dont on entend beaucoup parler qui bénéficie d’une communauté déjà très large.
La deuxième offre open source, nommée CloudStack, nous vient de la fondation Apache via un héritage de Cytrix. Cette solution fournit elle aussi à la fois une API et une interface graphique unifiée permettant d’administrer et d’utiliser les différentes briques du cloud privé. Elle bénéficie pourtant d’une communauté moins développée. Cependant, il ne faut pas oublier qu’elle tire partie de la grande expérience de Cytrix en la matière. La société édite d’ailleurs une solution reposant sur CloudStack.
Chez les éditeurs, vous trouverez aussi d’autres couches d’orchestration.
Dans cette dernière étape, notre but est de simplifier encore le provisionnement des infrastructures créées via la couche d’orchestration. L’idée est donc d’automatiser le déploiement des middleware utilisés par vos applications. Pour adresser cette problématique, il faudra se tourner vers les outils de type infrastructure as code. Ces outils permettent de rédiger des recettes de déploiements qui détaillent l’installation et la configuration des middleware via des fichiers de configuration. Par exemple pour déployer un serveur web Apache, on pourra écrire une recette Apache qui pourra être appliquée sur les serveurs retenus pour cette configuration. Dès lors, lorsqu’une nouvelle machine virtuelle taggée Apache sera démarrée sur votre infrastructure, cette dernière se verra appliquer l’installation et la configuration du serveur web apache.
Nous ne rentrerons pas ici, dans le détail des solutions de ce type, sachez néanmoins qu’elles existent et sont nécessaires à la réussite d’un déploiement dans le cloud. Parmi les outils connus que nous pouvons citer nous retiendrons SaltStack et Ansible mais il en existe beaucoup d’autres avec leurs avantages et leurs inconvénients.
Nous avons introduit dans cet article le principe des clouds privés et défini les briques nécessaires à leur réalisation. Lorsque l’on parle de cloud, on pense principalement automatisation et standardisation des environnements. Toutes les techniques décrites ici, peuvent être prises séparément pour répondre à des problématiques qui vous sont propres. Dans bien des cas, l’utilisation d’hyperviseurs en cluster associée à des recettes de déploiements automatisés sufffisent à automatiser et standardiser l’infrastructure. Il sera toujours temps d’enrichir votre infrastructure par la suite. Nous nous sommes limités ici à l’initialisation d’un cloud privé de type IaaS, car c’est une première étape pour pouvoir construire des offres plus riches comme le PaaS et le SaaS.