NaoShift prend en charge HPE VM Essentials, OpenShift et Superphenix
HPE Morpheus VM Essentials, Red Hat OpenShift Virtualization et Superphenix rejoignent la console NaoShift, ainsi qu'AWS, OVHcloud Public Cloud et Google Cloud. Ce que chaque connecteur lit, et comment il se branche.
Après VMware, le paysage de la virtualisation se fragmente. Aux côtés de Proxmox VE, de XCP-ng, de Nutanix AHV et de Hyper-V, de nouvelles plateformes s'installent chez les DSI et les hébergeurs : HPE Morpheus VM Essentials, Red Hat OpenShift Virtualization, ou encore Superphenix, la plateforme souveraine de Rayshift. Beaucoup d'organisations en font tourner plusieurs à la fois.
Début novembre, NaoShift ajoute ces trois plateformes à sa console, ainsi que trois clouds publics : AWS, OVHcloud Public Cloud et Google Cloud, à côté de Microsoft Azure. L'objectif ne change pas : tous vos hyperviseurs, dans une seule console.
Ces connecteurs sont en accès anticipé : ils sont livrés et testés, mais n'ont pas encore tourné sur l'infrastructure d'un client. Si vous utilisez l'une de ces plateformes, nous serons heureux d'en faire la première mise en service avec vous.
OpenShift Virtualization et Superphenix : un connecteur KubeVirt
Red Hat OpenShift Virtualization et Superphenix reposent tous deux sur KubeVirt, qui fait tourner des machines virtuelles dans Kubernetes. NaoShift les lit donc avec un même collecteur, par l'API Kubernetes du cluster.
Superphenix, édité par Rayshift, est une plateforme open source destinée aux hébergeurs et aux organisations attentives à la souveraineté. Elle assemble Talos, KubeVirt, Kube-OVN et Rook-Ceph. NaoShift en lit aussi la topologie propre, par région et zone de disponibilité. Le connecteur a été testé sur une installation réelle de Superphenix dans notre laboratoire.
Comment il se branche : un compte de service Kubernetes et un rôle de cluster en lecture seule, qui n'a aucun accès aux secrets. Le collecteur n'interroge qu'une liste fermée de ressources. Il ne lit jamais les annotations ni la configuration cloud-init des machines, qui peuvent contenir des mots de passe.
Ce qu'il remonte :
- les nœuds qui portent des machines virtuelles, les machines elles-mêmes, leurs disques et leurs cartes réseau ;
- les espaces de noms, présentés comme des conteneurs, et les classes de stockage, présentées comme des datastores ;
- la haute disponibilité de chaque machine, déduite de sa stratégie de démarrage ;
- les performances des machines par Prometheus (Thanos sur OpenShift), celles des nœuds par metrics-server.
En cas d'incident, l'analyse de cause racine lit les événements Kubernetes et les migrations à chaud liés à la machine, à son pod, à ses volumes et à son nœud. Ces événements n'étant conservés qu'environ une heure par Kubernetes, l'analyse doit être lancée tôt.
HPE Morpheus VM Essentials
HPE VM Essentials est la plateforme de virtualisation à base de KVM de HPE, pilotée par le VME Manager, qui peut aussi gérer des clusters vCenter.
Comment il se branche : un jeton d'API d'un utilisateur en lecture seule du VME Manager, en HTTPS, avec épinglage possible du certificat. Le collecteur n'interroge qu'une liste fermée de routes, et retire dès la réception les champs sensibles que l'API renvoie (mots de passe de console, clés, données utilisateur).
Ce qu'il remonte : les clusters de VM Essentials, leurs hôtes, leurs machines, leurs datastores avec leur taille et leur espace libre, et les snapshots.
Pas de double compte : les clusters vCenter pilotés par le VME Manager sont écartés et comptés à part, pour ne pas apparaître deux fois si votre vCenter est déjà connecté à NaoShift.
En cas d'incident, l'analyse de cause racine lit l'activité du VME Manager, qui dit qui a fait quoi, l'historique de la machine et du cluster, ainsi que les alarmes de l'appliance.
Et aussi : AWS, OVHcloud Public Cloud et Google Cloud
Les machines virtuelles des clouds publics rejoignent la même console. Pour ces connecteurs, rien n'est à installer : NaoShift interroge l'API du fournisseur, en lecture seule, avec un compte dédié. Chaque compte cloud apparaît comme un datacenter et chaque région comme un cluster. Les machines éphémères (groupes de mise à l'échelle automatique, nœuds Kubernetes) sont écartées et comptées, pour ne pas fausser l'inventaire.
Ce que cela change pour une équipe d'exploitation
Quelle que soit la plateforme, une machine se retrouve dans le même inventaire, avec les mêmes analyses de risques, les mêmes rapports et la même analyse d'incident. Une équipe qui teste OpenShift Virtualization, qui déploie HPE VM Essentials sur ses nouveaux serveurs, ou qui confie une partie de son parc à un hébergeur sous Superphenix, garde une seule vue de l'ensemble.
Comme pour les autres plateformes, la collecte passe par l'agent sortant, en lecture seule par défaut. Les gestes d'écriture sur ces nouvelles plateformes sont prévus dans un second temps, avec la même règle : écriture activée par cible avec un compte dédié, tracée avant exécution.
Questions fréquentes
NaoShift prend-il en charge OpenShift Virtualization ?
Oui, en accès anticipé, au travers de l'API Kubernetes du cluster, avec un compte de service en lecture seule. Le même connecteur couvre Superphenix et les autres plateformes KubeVirt.
Comment NaoShift évite-t-il de compter deux fois les VM d'un vCenter géré par HPE VM Essentials ?
Les clusters vCenter pilotés par le VME Manager sont écartés de la collecte de VM Essentials et comptés à part. Leurs machines restent visibles par le connecteur vCenter.
Qu'est-ce que Superphenix ?
Une plateforme de virtualisation open source éditée par Rayshift, construite sur KubeVirt, Talos, Kube-OVN et Rook-Ceph, et pensée pour les hébergeurs et les clouds souverains.
Pour aller plus loin
La page Intégrations liste toutes les plateformes prises en charge. Pour faire la première mise en service d'un de ces connecteurs avec nous, écrivez-nous, ou démarrez gratuitement.