OpenNebula : le cloud privé plus simple qu'OpenStack

OpenStack fait tourner des dizaines de millions de cœurs en production, et c'est précisément le problème quand on n'en a pas autant. La plateforme découpe le cloud en une vingtaine de sous-projets : Nova pour le compute, Neutron pour le réseau, Keystone pour l'identité, Cinder pour le stockage bloc, Glance pour les images, et la liste continue. Chaque brique a sa base de données, sa file de messages, ses workers, ses dépendances. Sur le papier c'est modulaire et puissant. Sur le terrain, ça veut dire une équipe dédiée pour installer, maintenir, surveiller et faire monter de version cet assemblage, avec une chaîne de dépendances longue où chaque upgrade devient un chantier. La majorité des organisations qui veulent un cloud privé n'ont ni cette équipe ni ce besoin.

OpenNebula prend le problème par l'autre bout. Au lieu d'orchestrer une constellation de services indépendants, c'est une plateforme intégrée unique qui couvre la gestion compute, réseau et stockage d'un cloud privé ou hybride. La différence de surface de code résume tout : OpenStack embarque historiquement de l'ordre de dix fois plus de lignes de code qu'OpenNebula. Moins de code à lire, moins de variables à régler, moins de pièces qui peuvent casser. C'est conçu pour qu'un seul administrateur installe, exploite et diagnostique la plateforme, là où OpenStack suppose une équipe.

OpenNebula sépare le plan de gestion et l'infrastructure de workload, et c'est tout. D'un côté le Cloud Management Cluster, avec un ou plusieurs nœuds frontend qui portent le démon principal, l'ordonnanceur, les API et l'interface. De l'autre, un ou plusieurs clusters de workload composés de nœuds hyperviseurs et du stockage.

Sur les nœuds, OpenNebula pilote directement KVM pour la virtualisation pleine et LXC pour les conteneurs système. Pas de surcouche d'abstraction qui réinvente l'hyperviseur : le frontend orchestre, les nœuds exécutent. Le stockage passe par des datastores qui contiennent les images disque, avec un éventail de backends qui couvre le local, le NFS ou NAS, le SAN, l'iSCSI et Ceph pour le distribué. Côté réseau, les réseaux virtuels s'organisent en catalogues et s'isolent les uns des autres, avec le choix entre VLAN 802.1Q, Open vSwitch ou VXLAN selon la topologie. Une image disque, un réseau virtuel, un template de VM : les objets sont peu nombreux et leur assemblage reste lisible.

Ce qui change tout pour l'exploitation, c'est que cette mécanique tient sur une poignée de concepts. Quand un nœud part en vrille à 3 h du matin, comprendre où regarder ne demande pas de cartographier vingt microservices et leurs interactions. La chaîne est courte : frontend, nœud, datastore, réseau virtuel.

OpenNebula gère le multi-tenant nativement. Le modèle expose des utilisateurs, des groupes et des rôles, avec des quotas par tenant et des interfaces différenciées selon le niveau d'accès. Un administrateur d'infrastructure, un administrateur de groupe et un utilisateur final ne voient pas la même chose et ne peuvent pas faire les mêmes actions. C'est ce modèle utilisateurs, quotas et API cloud qui fait la différence entre un simple cluster de virtualisation et une vraie plateforme cloud.

La répartition géographique suit la même logique de simplicité. Les clusters de workload se distribuent sur plusieurs sites, avec des configurations et des technologies différentes selon les besoins de chaque emplacement. Le modèle Edge Cluster pousse cette idée jusqu'au déploiement à la demande sur des ressources distantes, on premise comme chez un fournisseur public ou edge, pour étendre le cloud privé vers l'hybride sans changer d'outil. Un frontend, plusieurs clusters répartis, une seule console.

La comparaison qui revient en premier, c'est OpenStack. Les deux montent un cloud privé multi-tenant avec API et self-service, mais ils ne visent pas la même cible. OpenStack s'adresse au fournisseur d'infrastructure qui construit un cloud à très grande échelle et accepte le coût d'exploitation correspondant. OpenNebula vise le cloud d'entreprise : la même capacité multi-tenant, mais avec une complexité d'exploitation taillée pour de petites équipes. Le projet annonce des coûts d'abonnement de 33 à 80 % inférieurs aux offres OpenStack commerciales de Canonical et Red Hat, mais le vrai écart se mesure ailleurs : dans le temps homme passé à opérer la plateforme. Une procédure d'upgrade automatisée et simple contre une chaîne de dépendances et de points de défaillance à dérouler à chaque montée de version, c'est là que se joue le coût réel sur plusieurs années.

La deuxième comparaison est plus subtile, parce que les outils se ressemblent moins qu'on ne le croit. Proxmox VE est un cluster de virtualisation : excellent pour faire tourner des VM et des conteneurs sur un groupe de nœuds, avec une interface directe et une prise en main rapide. Mais Proxmox raisonne en cluster, pas en cloud. OpenNebula raisonne en orchestration cloud multi-sites, avec ce modèle d'utilisateurs, de quotas et d'API cloud qui manque par construction à un outil de virtualisation. La règle qu'on applique pour trancher : si le besoin est de virtualiser un parc sur un site, Proxmox suffit et c'est même le meilleur choix. Si le besoin est d'exposer un cloud self-service à plusieurs équipes ou clients, avec des quotas, des rôles et plusieurs sites, on passe à OpenNebula. Pour qui sort de VMware, la bascule vers un cluster Proxmox couvre la virtualisation pure ; OpenNebula prend le relais quand il faut en plus le modèle cloud par-dessus. La frontière entre Proxmox et VMware reste celle de l'hyperviseur, pendant qu'OpenNebula joue dans la cour de l'orchestration cloud.

OpenNebula expose un portail web, Sunstone, pour l'administration et l'usage courant : créer des VM, gérer les réseaux, suivre les quotas, administrer les utilisateurs. Au-dessus, FireEdge sert les interfaces plus récentes et l'orchestration de services multi-VM. Pour l'automatisation, la plateforme offre des API et la compatibilité avec des interfaces cloud standard, ce qui permet de scripter le provisioning et de brancher de l'infrastructure as code sans passer par le clic. Le tandem console pour l'humain, API pour la machine, couvre les deux usages sans imposer l'un ou l'autre.

Le scénario type, c'est l'organisation qui veut son cloud privé maîtrisé sans hériter de l'usine OpenStack. Une DSI qui doit offrir du self-service à plusieurs équipes internes, avec isolation et quotas, mais qui ne va pas monter une équipe cloud de cinq personnes pour ça. Un hébergeur ou un infogérant qui expose des tenants à ses clients sur plusieurs sites France, sans payer le ticket d'entrée OpenStack en heures d'exploitation. Une entreprise qui sort de VMware et veut un cloud souverain sur son propre matériel, opéré par une petite équipe.

Dans tous ces cas, le critère décisif n'est pas la fonctionnalité brute. OpenStack et OpenNebula font globalement le même travail de surface. Le critère, c'est le coût d'exploitation rapporté à la taille de l'équipe. Quand on opère une infra pour le compte de clients, chaque heure passée à déboguer une stack OpenStack est une heure non facturable et un risque de panne supplémentaire. La simplicité d'OpenNebula n'est pas un confort, c'est une variable économique et un facteur de résilience.

Le verdict est net : si vous construisez un cloud public à l'échelle d'un hyperscaler avec une équipe d'ingénieurs cloud dédiée, OpenStack reste la référence et OpenNebula n'a pas le périmètre. Pour absolument tout le reste, c'est-à-dire un cloud privé ou hybride multi-tenant opéré par une équipe de taille raisonnable, OpenNebula livre la même promesse cloud sans le coût d'exploitation qui plombe OpenStack.

Reste une vérité que l'éditeur ne met pas en avant : OpenNebula est plus simple, mais opérer un cloud privé en production demande quand même de tenir le stockage, le réseau, la sauvegarde des datastores et un PRA testé. La simplicité de la plateforme ne dispense pas du métier d'ops. C'est exactement le terrain qu'on couvre : on déploie et on opère ce genre de cloud privé sur de l'infra France, du frontend OpenNebula jusqu'au stockage Ceph et à la restauration testée. Si vous voulez un cloud privé maîtrisé sans recruter une équipe cloud entière, on peut opérer la plateforme et la stack au-dessus.

Pour situer OpenNebula dans le reste du paysage cloud privé et souverain, voir aussi notre comparatif sur la migration de VMware vers Proxmox, notre analyse de Harvester pour l'hyperconvergence sous Rancher, le guide OpenStack en cloud privé open source et notre dossier sur le cloud souverain.

• OpenNebula vs OpenStack for the Enterprise : comparaison lignes de code, coûts et modèle d'exploitation par l'éditeur.
• Cloud Architecture Design, documentation OpenNebula : architecture frontend, clusters de workload, datastores et réseaux.
• Open Alternative to OpenStack : positionnement comme alternative légère pour remplacer VMware sans la complexité OpenStack.
• Discover OpenNebula : support KVM et LXC, multi-tenant, edge et déploiement hybride.