Meurt un autre jour

Dans le cadre du remplacement d'un serveur chez un client, j'ai récupéré un vieux serveur, un honorable ProLiant ML310e Gen8 de pas loin de 8 ans d'âge afin de le débarasser. Un serveur modeste, avec le contrôleur raid intégré qui rend l'âme et un processeur un peu famélique pour du Windows.

L'idée de le mettre à la benne m'apparaissait comme une hérésie, son processeur était tout de même encore potable pour un grand pan d'utilisations diverses et variées, 20 Go de RAM étaient suffisants pour pas mal de choses et je n'aime pas jeter ce qui marche encore. Le contenu du serveur initial ayant été transformé en machine virtuelle, j'avais tout à loisir d'en faire quelque chose à ma guise, juste en faisant attention à ne pas trop me reposer sur le contrôleur raid intégré. En effet, tout ce qui sortait du connecteur principal pour la grappe de disque me renvoyait des erreurs aléatoires, mais par contre, aucun problème avec le contrôleur SATA présent sur la carte mère !

Alors un SSD de branché plus tard, j'avais de nouveau un serveur avec un stockage modeste mais des performances pas trop sales pour une petite infra maison. J'avais envie d'un système de virtualisation, mais les version d'ESX possibles sur ce serveur n'allaient pas très haut, et j'ai du donc chercher une alternative à ce système de virtualisation (non pas Hyper-V), une alternative gratuite. Et quelques recherches plus tard, le nom de Proxmox VE m'apparaissait (VE pour Virtual Environment).

Les problèmes commencent dès l'installation mais ne durent pas.

Proxmox fournit un ISO d'installation permettant de pré-configurer l'environnement sur lequel il tournera. C'est une image d'install comme vous installeriez une distribution Linux. Vous gravez un DVD ou crééz une clé bootable (via un outil comme Rufus ou la commande dd), vous branchez, démarrez votre machine, sélectionnez le périphérique de démarrage et renseignez les informations demandées.

Tout est ok, on redémarre pour finaliser l'installation, et ... rien. Enfin si, un kernel panic, rien qui ne démarre correctement. Pendant un moment, je pensais que le port SATA avait aussi un problème, mais non. Quelques recherches sur les Internets et nous voilà plutôt à installer une débian 11 sur le serveur. Pourquoi une debian ? Et bien parce que Proxmox fournit tout le nécessaire sur leur site pour transformer sa debian en un serveur Proxmox flambant neuf comme s'il sortait d'une install via leur ISO.

Effectivement, à mon plus grand plaisir, le setup pour arriver à ce résultat est plutôt simple :

1. On ajoute le repository de Proxmox VE dans les sources d'APT
2. On ajoute les clés de sécurité du repository
3. On installe le kernel de Proxmox
4. On reboot
5. On install les packages de Proxmox VE
6. On retire les Kernel initiaux de Debian
7. Reboot
8. ???
9. Profit

A l'attaque !

Une fois le serveur redémarré, on peut se connecter via son navigateur web favori (c'est à dire rien qui ne se base sur Chromium) en pointant vers l'ip de notre serveur en utilisant le port 8006. Par défaut, 2 types d'authentification sont proposées :

• Linux PAM standard authentication
• Proxmox VE authentication server

Le premier permet d'utiliser les identifiants de la machine (le compte root quoi) alors que le second permet d'utiliser les informations d'authentification que vous pouvez créer dans Proxmox. Cette liste est non-exhaustive, puisque l'on peut tout à fait y rajouter un LDAP ou un Active Directory en tant que type d'authentification pour permettre à nos utilisateurs ou autres intervenants d'accéder à Proxmox.

Dans notre cas et dans le cadre d'une première utilisation, nous utiliserons donc l'authentification PAM avec nos identifiants root crées à l'installation du serveur debian.

Une fois ici, nous pouvons donc commencer notre travail et créer une VM ou un CT... un quoi?

C'est quoi un CT?

Un CT est un ConTainer. Grosso modo, je connaissais docker, mais là c'est une autre forme de conteneurisation qui n'utilise pas Docker mais LXC pour arriver à ses fins, et j'ai du sortir de ma zone de confort pour y toucher un peu.

La principale différence (sans trop rentrer dans les détails surtout) c'est que là ou Docker fait du conteneur applicatif, LXC fait du conteneur d'un système quasi complet, quasi car des éléments comme le kernel ne sont pas dans un conteneur LXC. Cela se rapproche plus d'une machine virtuelle que d'un conteneur docker, mais l'empreinte d'un conteneur LXC est étonnamment petite comparé à une machine virtuelle classique. En se débarrassant de la partie kernel, on arrive à faire tourner des Containers LXC avec 512 de RAM par exemple. Cependant, cela limite les containers uniquement à des machines Linux, puisque c'est le Kernel de Proxmox qui est utilisé.

Les conteneurs peuvent tourner en mode "Unprivileged", un mode qui va effectuer un mapping des ID d'utilisateurs pour éviter une transition d'un compte utilisé dans un conteneur vers un autre conteneur ou même l'hôte.

Une fois cette différenciation faite, on passe à la création de machines. Et là, c'est ma foi assez simple, et compréhensible pour qui connaît déjà un peu le monde de la virtualisation.

Stockage

Le stockage est géré à deux endroits :

• Sur l'hôte
• Sur le cluster (même si vous n'avez pas de cluster)

L'hôte va gérer les disques locaux, depuis son interface, vous pourrez créer des volume group en LVM et autres joyeusetés.

La même gestion côté cluster va nous amener à définir des partages globaux, un montage en iscsi par exemple, et qui sera disponible sur une partie ou l'ensemble des hôtes joints au cluster.

On peut définir des rôles à chaque type de stockage. Par exemple, mon stockage nommé "local" ne récupérera pas les images ISO et autres templates de conteneur LXC

Réseau

Comme à l'usuelle, on peut créer des cartes réseau virtuelles que l'on pourra présenter aux machines et conteneurs, des VLANs pour dissocier les différents flux, mais aussi des "bonds" (des agrégats entre les cartes réseau qui permettront au choix de démultiplier le débit réseau maximum disponible ou de créer un système de failover). A noter que le tout est disponible en version native, ou en version Open Virtual Switch. N'ayant pas connaissance de ce qu'apporte ce dernier, je ne vais pas écrire dessus, je reviendrai par le biais d'un autre article si besoin est.

Et puis, il y a aussi la partie Firewalling.

Quoi? Un firewall intégré?

Proxmox fournit un pare-feu intégré, que l'on peut mettre en place côté cluster ou hôte, et qui permettra de filtrer complètement les flux réseau sans même avoir besoin de modifier une quelconque configuration sur vos machines. Cela présente l'incroyable avantage de pouvoir centraliser la configuration et de mettre les autorisation d'accès en dehors des machines et des utilisateurs des solutions déployées dans les VM et CT.

Sauvegarde

La sauvegarde est intégrée dans Proxmox, et permet de conserver vos précieuses VM et conteneurs loin d'un vilain crash.

Elle est gérée au niveau du cluster et permet de faire du backup via les agents pour de la sauvegarde snapshot (qemu-guest-agent est disponible dans la plupart des repos Linux de base et est disponible via un setup pour Windows), ou bien par suspension ou arrêt de la VM.

Ici, j'ai créé un pool backup, qui, lorsqu'il sera alimenté par une autre VM ou conteneur, sera automatiquement pris dans ce plan de sauvegarde.

Des rapports sont envoyés automatiquement par mail (une configuration du serveur Postfix sur chaque hôte au préalable est nécessaire), et le tout se fait de manière très efficace. Les quelques problèmes que j'ai pu rencontrer venaient du fait que mon repository de sauvegarde était un partage NFS et que le binding d'identité posait problème.

Les VM sont des plus classiques

C'est d'une simplicité agréable : On sélectionne son fichier ISO, que l'on peut charger directement depuis l'interface web, ou demander à télécharger directement depuis la GUI de Proxmox (il faut que le fichier final soit un iso, pas un gz ou tar).

On choisit ses options en terme de ressources, en terme de stockage et si oui ou non elle doit démarrer au boot. On peut également préciser après quel VM / container la machine doit démarrer (utile pour ne pas démarrer l'applicatif AVANT la base de données).

On valide, et ça tourne.

Les CT sont différents

Les containers sont pour eux gérés depuis des templates, disponibles depuis l'espace que vous avez configuré qui sert aux images des containers. Vous en avez pour tous les gouts, certains préconfigurés avec certaines applications, d'autres vierges avec un OS basique.

Lorsque vous créez un container, vous devez préciser des informations telles qu'une clé SSH et/ou un mot de passe SSH, un nom pour la machine, le template que vous voulez utiliser ainsi que d'autres informations plus standard (le nombre de cœurs, quantité de RAM et espace disque).

Leur impact sur le système est bien plus léger, mais ils souffrent de deux contraintes assez importantes :

• Ils ne peuvent pas être migrés dynamiquement d'un hôte à l'autre : de par leur fonctionnement via le kernel de l'hôte, ils doivent être arrêtés lors d'un process de migration.
• Ils ne peuvent faire tourner QUE du Linux, toujours pour les mêmes raisons : Donc pas de Windows (ce qui fait que ça n'est pas vraiment 2 contraintes, mais plutôt une seule :P )

Qu'est ce que j'en pense de Proxmox ?

Je suis... ravi. Vraiment impressionné de la manière dont Proxmox est utilisé et utilisable en entreprise. Même sans avoir de licence m'ouvrant un accès au support j'arrive à tenir une infrastructure complète, redondante et même s'il y a quelques problèmes arrivant parfois (notamment avec la sauvegarde qui m'a fait quelques petits couacs de temps à autres) j'arrive facile à avoir accès à la connaissance de la communauté pour résoudre ces situations. C'est devenu même mon plaisir de ces derniers temps puisqu'entre le début de la rédaction de cet article et maintenant, j'ai pu récupérer du matériel supplémentaire pour faire un vrai cluster avec du stockage externalisé ET du stockage redondé / distribué... Mais ça sera l'occasion d'un prochain article :)