Tutoriel pour apprendre les bases du cloud privé et en construire le vôtre

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.

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.

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.

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.

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.