I. C'est quoi le cloud ?▲
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 :
- IaaS : Infrastructure as a Service. Le principe est de fournir l'infrastructure, donc les machines, comme des services. À grand renfort de virtualisation et d'automatisation, on se contente ici de reproduire les architectures bare-metal standards sur des machines virtuelles. Sur ce segment, nous pouvons identifier les deux principaux fournisseurs que sont Amazon Web Services avec EC2 et Google Cloud Platform avec GCE. S'agissant de solution privée, nous pouvons identifier tout d'abord les éditeurs comme Azure, VMWare, ProxMox et OpenStack pour l'open source.
- PaaS : Platform as a Service. Le principe est de s'abstraire complètement de l'infrastructure en fournissant des plateformes capables d'exécuter les applications dont le code source ou les binaires sont fournis en entrée. La vision idéale de ce type de solution est de nous abstraire non seulement de l'infrastructure, mais aussi des middlewares, bases de données, bus de message, serveurs web, etc. On dénombre dans ce cas des fournisseurs publics comme Amazon EBS, Google AppEngine, Heroku et CleverCloud. Pour des solutions privées, là encore, il faut se tourner vers les éditeurs ou l'open source avec CloudFoundry pour Pivotal, OpenShift pour RedHat, et Stratos chez Apache.
- SaaS: Software as a Service. Dans ce dernier cas, il s'agit de fournir des services logiciels multitenants. Parmi les principaux exemples du marché, nous pouvons lister SalesForce, Google Apps, Office 365. Cette dernière famille regroupe en réalité tout ce que les utilisateurs finals connaissent du cloud à savoir des services logiciels « bout en bout » qui ne nécessitent aucune installation de leur part.
Nous voyons actuellement un nouveau type de solution émerger sur le marché que certains nomment le CAAS pour Container as a service. Il s'agit de fournir des conteneurs légers 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.
II. Et le cloud privé dans tout ça ?▲
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é externalisé).
Ce type de solution s'oppose aux offres de 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 particuliers 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 œuvre d'une solution privée : l'entreprise dispose déjà d'une infrastructure dont l'OPEX ([Operating Expenses : charges d'exploitation] 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érationnelles. 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 cerveau, 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êmes travaillent peu. Dans ce cas, il devient intéressant de dépasser le cap de la virtualisation simple pour tirer parti 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 ladite plateforme 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 deux 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.
III. Quelles sont les premières briques à mettre en place ?▲
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é.
III-A. Virtualisation/Compute▲
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 open source, 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 hyperviseurs faisant tourner de nombreuses machines virtuelles.
À 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 côté des solutions éditeurs, les équipes d'infrastructure pourront s'orienter vers les solutions VSphere de VMWare et HyperV de Microsoft. À 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 (tarification) et du niveau de support fourni par ces deux fournisseurs.
III-B. Réseau/Networking▲
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 serveurs, il n'y a aucune raison pour que votre plateforme de recette puisse voir la plateforme de production. Comme toute autre solution orientée 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 d'un 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.
III-C. Stockage/Storage▲
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'autre 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 parti des disques de vos hyperviseurs, ou reposer sur des baies de stockage ou encore, via des systèmes de fichiers réseau 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 fichiers 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.
IV. Automatisez votre cloud privé▲
Dans le IAAS, l'automatisation doit se jouer à deux niveaux :
- orchestration des briques ;
- automatisation des déploiements.
IV-A. Orchestration des briques▲
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 de les 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é 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és par un grand nombre de contributeurs est largement soutenu par des grandes entreprises du secteur IT parmi lesquelles nous pouvons citer HP, IBM, RedHat et RackSpace. OpenStack est une solution dont on entend beaucoup parler et 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 parti 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.
IV-B. Automatisation des déploiements▲
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 middlewares 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 middlewares 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 tagué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 suffit à 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.
Note de la rédaction Developpez.com▲
Tous nos remerciements à Wescale pour l'autorisation de publication de ce tutoriel.
Nos remerciements également à Winjerome pour la mise au gabarit Developpez.com et Jacques Jean pour la relecture orthographique.