PROXMOX

Le terme datacenter signifie centre de données.

L’abréviation « VM » (pour Virtual Machine) signifie machine virtuelle.

Le terme datastore est traduisible par espace de stockage

Les différents termes ci-dessus seront utilisés tant en français qu’en anglais, l’usage de la version anglophone étant répandu aussi bien dans les produits utilisés qu’entre informaticiens.

Dans Proxmox, le terme « machine virtuelle » peut désigner des machines virtuelles comme des conteneurs.

Un nœud, au sens réseau, va être une machine connectée. Au sens centre de données, un nœud va être un ordinateur faisant partie du centre.

Au moment de l'écriture de ce tutoriel, l'ISO permettant l'installation de Proxmox est téléchargeable ici. Celui-ci est basé sur Debian BookWorm.

Voici l'écran de démarrage :

Après avoir démarré, nous aurons l’écran d’acceptation de licence :

Puis l’écran de sélection des options de disque de destination :

Si vous avez plusieurs disques durs, vous pourrez sélectionner celui où installer Proxmox

Si vous sélectionnez le bouton « options », vous pourrez personnaliser les partitions :

Les types de partitions disponibles étant :

• ext4 ;
• xfs ;
• ZFS (voir chapitre sur ZFSStockage ZFS pour plus d’informations) ;
• BTRFS (avec éventuellement RAID 1, RAID 10).

L'écran suivant permettra de sélectionner votre pays, le choix du pays remplissant automatiquement les champs « timezone » et la disposition des touches du clavier (que vous pouvez aussi personnaliser à votre guise). Il suffit de taper le début du nom du pays.

Il faudra ensuite renseigner le mot de passe (minimum 8 caractères) et l'adresse mail de l'administrateur (adresse mail obligatoire pour passer à l’écran suivant) :

Vous pourrez ensuite personnaliser le nom de machine (FQDN obligatoire ) ainsi que les réglages réseau :

Vous aurez enfin un résumé des préréglages. L’installation démarrera une fois le bouton « install » cliqué.

L’installation s’effectue ensuite automatiquement :

Vous aurez l'écran suivant vous rappelant l'URL d'accès à l'interface d'administration (https://adresse_ip:8006), suivi d’un redémarrage après quelques secondes si vous n’avez pas décoché l’option redémarrage automatique.

Vous aurez enfin l’écran GRUB standard avant le démarrage automatique :

Une fois le démarrage effectué, vous aurez une demande de login standard dans la console :

Le message affiché redonne l’URL d’accès à l’interface d’administration Web.

2-1-1. Port par défaut▲

En prérequis pour l’installation, vous devrez avoir les fichiers /etc/hosts et /etc/hostname positionnés correctement.

Proxmox propose à ce jour des dépôts pour Debian Wheezy (version 7, pour les anciennes versions de Proxmox) jusqu’à Debian BookWorm (version 12).

Il faudra commencer par récupérer la clef de sécurité du dépôt pour BookWorm :

wget http://download.proxmox.com/debian/proxmox-release-bookworm.gpg

Nous intégrons la clef :

apt-key add proxmox-release-bookworm.gpg

Nous ajoutons le dépôt dans /etc/apt/sources.list :

deb http://download.proxmox.com/debian/pve bookworm pve-no-subscription

deb http://download.proxmox.com/debian/pve bookworm pvetest

Nous installons les paquets Proxmox ainsi que Postfix pour les mails :

apt-get install proxmox-ve postfix open-iscsi

Après le téléchargement des paquets, vous aurez en premier les écrans de configuration de postfix. Pour une installation standard, laissez sur « Internet ». Comme Proxmox installe un nouveau noyau (pour le support de la virtualisation), un redémarrage est donc nécessaire.

Une fois le redémarrage effectué, vous pourrez supprimer votre ancien noyau.

Après démarrage, vous aurez l’URL de connexion à l’interface web de Proxmox dans le prompt de la console :

L'installation sur un système existant n'écrase pas celui-ci. Il change le fichier /etc/issue, installe un noyau avec support de KVM, les outils Proxmox et son interface Web.

Ce que l’on nomme le « Cloud » est un regroupement de services accessibles à distance. Ces services sont mis à disposition par un ensemble d’équipements hébergés dans des centres de données (datacenters).

Les principaux services utilisables proposés sur le cloud vont être du plus bas vers le plus haut niveau :

• Infrastructure as a Service (IaaS) : l’utilisateur gère son infrastructure, la gestion et la maintenance des équipements physique sont à la charge du fournisseur de service, la gestion des ressources fournies est à la charge de l’utilisateur du service. Les ressources disponibles (nombre de machines physiques pour supporter l’infrastructure, l’espace disque, la configuration des machines en matière de CPU et RAM) vont dépendre de l’offre et de la tarification ;
• Platform as a Service (PaaS) : le fournisseur met à disposition et maintient un environnement d’exécution (machine et système d‘exploitation). L’utilisateur gère et maintient les applications dans cet environnement. Cette solution est peu courante, en général on utilisera soit du IaaS, soit du SaaS. Hors gestion d’infrastructure, si vous prenez un serveur chez un hébergeur, celui-ci vous fournira une installation de base, à votre charge d’effectuer la configuration. En cas de problème, vous pourrez automatiquement repartir sur une installation de base en écrasant la machine d’origine. Le fournisseur de service n’interviendra pas sur votre instance (sauf contrat spécifique), il fera en sorte de la maintenir en conditions opérationnelles sur son infrastructure ;
• Software as a Service (SaaS) : le fournisseur fournit et maintient un logiciel au sens large et donc tout ce qui en découle (machine, contrôle d’accès à celle-ci, système d’exploitation, éventuellement la base de données utilisée par le logiciel). Un exemple de cette configuration est la mise en service d’un logiciel de comptabilité, d’un CRM/ERP, ou encore, d’un CMS.

À cela vont se rajouter d’autres dénominations « as a service » qui sont des sous-ensembles des dénominations ci-dessus telles que :

• Storage as a Service (STaaS) : concerne de l’espace de stockage normalement redondant et extensible, et en général accessible via une API et éventuellement une interface Web, qui comprend trois sous-ensembles :

  • File Storage : l’espace de stockage est accessible comme n’importe quel système de fichiers,
  • Bloc Storage : accès par blocs comme le fait un système de fichiers sur un disque dur. L’analogie la plus proche étant l’utilisation d’un SAN,
  • Object Storage ou stockage objet : un ensemble de clefs/valeurs, par exemple, le service Amazon S3 (un fichier dans ce cas peut être un objet) ;
• Desktop as a Service (DaaS) : l’utilisateur se connecte à un bureau à distance. Ces fonctionnalités existaient avant le cloud avec par exemple RDS de Microsoft ou les produits Citrix.

• Database as a Service(DBaaS) : le fournisseur met à disposition et maintient un système de base de données. Ces bases de données peuvent être SQL (MySQL, PostGRESQL, SQL-Server) ou NoSQL (MongoDB, Cassandra) ;

  Les sauvegardes ne sont pas forcément à la charge du fournisseur.

• Backup as a service (BaaS) : comme le nom l’indique, il s’agit ici d’une solution de sauvegarde managée. La solution proposée va répondre de ce qui doit être sauvegardé (simples fichiers, base de données, machine virtuelle complète). La rétention des données va dépendre de la solution et de la tarification proposées.
  Cette liste n’est pas exhaustive.

La gestion de ces différents services peut s’effectuer :

• par l’intermédiaire d’une interface Web ;
• par l’intermédiaire d’API ;
• depuis des commandes en terminal.

Selon le prestataire et l’offre choisi(e), vous aurez accès à ces trois possibilités ou au moins une et avec un accès partiel ou complet.

Au niveau des interfaces de gestion, l’interaction avec l’infrastructure s’effectue en différentes parties standardisées :

• Compute : regroupe la création et la gestion des VM ou conteneurs ;
• Storage : regroupe la gestion du stockage. Il peut être séparé ou non de la partie compute, du stockage peut également être utilisé en cloud sans Compute ;
• Network : regroupe tout ce qui est gestion réseau de la solution utilisée avec souvent une partie publique et une partie privée (exemple pour la partie privée : réseau interne accessible uniquement aux machines gérées dans la partie compute) ;
• Identity : que l’ont peut maintenant trouver sous la dénomination IAM (Identity and Access Management). Cela concerne la gestion des droits d’accès : comptes utilisateurs, clefs API, etc. ;
• Data ou database : partie dédiée à la gestion de base de données.

Cette liste peut varier selon la solution proposée.

Un datacenter, ou centre de données, est une infrastructure industrielle regroupant dans un ou plusieurs bâtiments des ressources informatiques composées de serveurs, d’équipements réseau, d’un groupe électrogène et de dispositifs de sécurité (incendie, intrusion).

Un datacenter peut appartenir à une grosse entreprise, il sera alors privatif ; ou il peut appartenir à un hébergeur/fournisseur de services Cloud.

Du point de vue de Proxmox, vous allez gérer un datacenter virtuel, avec un seul ou plusieurs serveurs et avec un point unique d’accès aux réglages.

Les ressources gérées seront :

• un ou plusieurs serveurs ;
• des espaces de stockage : répartis ou non sur plusieurs machines, partagé ou non entre les différentes ressources, des NAS externes, des systèmes de fichiers distribués, etc. ;
• des modèles de création de VM ou de conteneurs ;
• des ressources réseau (switch virtuel ou vswitch) ;
• des pools de ressources (regroupement de différentes ressources sous une même entité, comme une vue) ;
• des machines virtuelles ;
• des conteneurs.

Il s’agit ici du point d’entrée principal pour la gestion du datacenter virtuel.

• Résumé : va afficher le nombre de nœuds, de VM, de conteneurs, va donner également un état de la charge du matériel :

• Notes : zone où vous pouvez enregistrer le texte de votre choix.

• Grappe de serveurs : permet de créer/rejoindre un cluster.

• Ceph : accès à la partie gestion d’un espace de stockage Ceph.

• Options : réglages tels que la disposition du clavier ou l'adresse mail de l'administrateur.

• Stockage : permet d'ajouter, supprimer, éditer les stockages disponibles (ce point sera étudié au chapitre suivantLe stockage dans Proxmox).

• Sauvegarde : sera vu en détail au chapitre sauvegardeSauvegarde.

• Réplication : sera vu au chapitre réplicationGestion d'un datacenter.

• Permissions : ceci permet de gérer les autorisations d’accès à des ressources pour des utilisateurs ou par des API. Cet aspect sera étudié ultérieurement.

• HA : pour le contrôle de la haute disponibilité (fonction avancée et nécessitant plusieurs serveurs).

• SDN : acronyme de Sofware Defined Networking, nouveau modèle d’architecture réseau gérant l’abstraction de fonctionnalités.

• ACME : pour la gestion de certificat SSL avec Let’s Encrypt.

• Pare-feu : permet l'ajout de règles IPTables (un champ commentaire est également présent).

• Serveur de métrique : permet l’installation de Graphite, ou InfluxDB, permettant un suivi de l’utilisation des ressources.

• Correspondance de ressource : permet l’accès au PCI ou à l’USB Passthrough. Pour le PCI Passthrough, votre processeur doit gérer l’IOMMU, la fonctionnalité Intel VT-d ou IOMMU doit être activée au niveau du BIOS.

• Support : disponible uniquement dans la version payante.

L’accès dans notre cas de figure se fera par un clic sur srv1, le nom de notre unique serveur. En cas de présence de plusieurs serveurs, ils auront chacun le même menu.

• Résumé : détail sur le serveur proprement dit, plus précis que le résumé général du datastore et filtrant au niveau serveur dans le cas où il y en a plusieurs.

• Notes : un espace dédié à ce serveur où vous pouvez inscrire ce que vous souhaitez.

• Shell : ouvre une console sur ce serveur :

• Système : le clic sur système affiche les différents services qu’il est possible de stopper ou redémarrer. Ci-dessous le détail du sous-menu de système :

  • réseau : permet la gestion des cartes réseau en interface graphique,
  • certificats : le chargement de vos propres certificats via l’icône « upload » vous permettra de ne plus avoir l'avertissement « connexion non sécurisée » dans votre navigateur,
  • DNS : les serveurs DNS pour l'accès externe,
  • hôtes : permet la visualisation et la modification du fichier /etc/hosts,
  • options : accès au décalage du démarrage automatique et à l’adresse MAC pour le wake-on-lan. Vous ne devriez pas avoir besoin de modifier ces réglages,
  • heure : permet le réglage du fuseau horaire,

  • system log: accès au contenu de syslog avec possibilité de filtrage par date ;

• Mise à jour : permet la mise à jour des paquets de l'OS.

• Pare-feu : accès à l’ajout de règles iptables.

• Disques : affiche les différents disques et partitions physiques du serveur (accès aux registres S.M.A.R.T.) :

  • LVM : accès à la gestion des Volume Group LVM (si LVM présent) ;
  • LVM-Thin : Accès aux Thinpools ;
  • répertoire : va permettre de créer un répertoire à l’usage du stockage d’images disque pour les VM ;

  • ZFS : partie gestion d’un espace de stockage ZFS.

• Ceph : accès à la gestion d’un espace de stockage CEPH.

• Réplication : accès au service de réplication en cas de présence de plusieurs serveurs.

• Historique des tâches : l’historique des opérations effectuées sur le serveur.
• Abonnement : endroit ou entrer la clef d’enregistrement en cas de souscription à un abonnement auprès de Proxmox.

Dans cette partie, vous aurez accès aux différents VMNets et à leurs permissions :

Cette partie contiendra les images ISO ou modèles de conteneurs dont vous aurez besoin pour créer vos VM/conteneurs. La zone va également contenir les sauvegardes de machines générées :

Cette partie vous donne accès aux images disques des VM et conteneurs :

Avant de créer une VM, nous allons commencer par télécharger un fichier ISO qui nous permettra de procéder à l’installation de notre OS virtualisé depuis un média d'installation.

Pour pouvoir télécharger un ISO, il faut se rendre depuis le menu de gauche dans datacenter → srv1 → le stockage concerné, puis contenu, et enfin cliquer sur «téléverser» :

Une boite de dialogue vous demandera de sélectionner le fichier (soit un fichier ISO, soit un fichier de conteneur).

Il est également possible de télécharger le fichier depuis une URL.

Si vous allez dans le stockage local-lvm, les boutons upload et templates seront grisés, car vous ne pouvez pas stocker d'ISO ni de templates de conteneurs dans un volume LVM.

L'ISO sera alors disponible et visible.

Plus d'informations sur le stockage Proxmox ici.

Les données sont stockées dans /var/lib/vz/template/iso pour les fichiers ISO et dans /var/lib/vz/template/cache pour les templates de conteneurs ou dans les dossiers équivalents du magasin de données.

Les fichiers de définitions des VM sont dans /etc/pve/qemu-server/[id].conf.

Nous pouvons passer ensuite à la création de notre VM proprement dite en cliquant sur « Créer VM » dans la barre en haut ou grâce au bouton droit sur le nom de votre serveur à gauche.

8-2-1. Nom et emplacement de la VM▲

8-2-2. Choix du système d’exploitation▲

8-2-3. Onglet système▲

8-2-4. Disque▲

8-2-5. Processeur▲

8-2-6. Mémoire▲

8-2-7. Réseau▲

8-2-8. Confirmation▲

Il n’y a pas de réel écran sur une machine virtuelle. Le contenu de l’écran virtuel est affiché au travers d’un serveur VNC. Promox propose par défaut un client VNC écrit en JavaScript et donc à utiliser dans un navigateur et nommé noVNC. Proxmox propose en alternative SPICE et Xterm.js, qui sont un terminal dans un navigateur. La suite présente l’usage de noVNC.

Pour la démarrer, il suffit de se placer sur la VM apparaissant à gauche et de cliquer bouton de droite « démarrer » :

Vous pourrez aussi la démarrer en cliquant « démarrer » en haut à gauche une fois la VM sélectionnée :

Une fois celle-ci démarrée, vous pourrez voir son contenu, sa console, en cliquant « console » et lançant noVNC.

Ceci va ouvrir la console de la VM dans une fenêtre secondaire du navigateur :

En cliquant sur la flèche grise à gauche, vous aurez les options VNC :

Ci-dessous les options proposées :

• Touches supplémentaires

  • touche Contrôle,
  • touche Alt,
  • touche Windows,
  • touche tabulation,
  • touche échap,
  • envoi du combo Contrôle – Alt – Suppr ;
• mode plein écran ;

• paramètres, va ouvrir la fenêtre ci-dessous :

• Le mode mise à l’échelle permet d’adapter l’image lors de l’agrandissement de la fenêtre.
  L’option « Afficher uniquement » bloque les interactions clavier-souris et ne fait qu’afficher l’écran de la VM ;

• commandes :

  • Start : démarrage de la VM si elle est éteinte,
  • Arrêter : arrêt ACPI de la VM, équivalent à une extinction par le menu démarrer sous Windows,
  • Hard stop : équivalent à un arrêt de l’alimentation sur une machine physique,
  • Hard reset : même effet que l’appui sur la touche reset d’une tour,

  • Suspend : mise en pause, la VM est figée

    Si le serveur est éteint ou redémarré, une VM suspendue est éteinte.

  • Resume : reprise après pause,

  • Reload VNC : recharge VNC.

Ces options sont également partiellement disponibles dans le menu Arrêter en haut juste à côté de démarrer dans la fenêtre NoVNC.

Les additions invitées sont des pilotes de périphériques à installer dans la VM concernée de façon à optimiser leur fonctionnement. Les additions invitées vont également apporter des fonctionnalités telles que le glisser-déplacer ou la fonction de dossier partagé entre l’hôte et la VM. Ce sont des fonctions présentes dans les hyperviseurs de type 2. Il s’agit donc de paravirtualisation. Les autres hyperviseurs ont en général ces fonctionnalités.

Pour installer les additions invitées, sous Windows, il vous faudra télécharger l’ISO « Windows VirtIO Driver» et l’installer dans la VM.

Sous une VM Linux, il vous faudra installer le paquet qemu-guest-agent.

Pour les bases Debian :

apt install qemu-guest-agent

Pour les bases Fedora :

yum install qemu-guest-agent
# urpmi install devrait fonctionner également

Je vais présenter ci-dessous l’installation dans une VM Windows 8.

Comme déjà vu aux chapitres précédents, il vous faudra tout d’abord charger l’ISO dans un datastore disponible.

Il faudra ensuite lier cet ISO au CD-ROM virtuel de la VM. Nous allons à cet effet aller dans le menu de la VM, onglet « Matériel » :

Puis en cliquant dessus, sélectionner l’ISO à monter :

Une fois l’option enregistrée, le CD virtuel sera immédiatement disponible dans la VM. Les additions invitées s’installent comme n’importe quelle application en lançant le setup :

Nous avons déjà vu cette opération lors de la création de la VMChoix du système d’exploitation. Pour rappel, il est possible de monter un ISO ou de directement utiliser le lecteur CD de l’hôte. Il est possible également d’ajouter un lecteur CD virtuel supplémentaire depuis l’onglet matériel.

Pour utiliser une clef ou un disque USB installé dans l’hôte, il faudra aller dans les options « matériel » de la VM et sélectionner « Ajouter un périphérique USB » :

Il faudra ensuite sélectionner le périphérique USB après avoir coché « Utiliser le port USB » :

La clef apparaîtra automatiquement dans la VM.

Avec la configuration par défaut, si la VM comporte une carte réseau avec l’option « déconnecter » décochée, la VM aura accès au réseau comme n’importe quelle machine du réseau.

En cas de configuration réseau personnalisée (comme l’utilisation de VLAN par exemple), l’accès aux autres machines du réseau sera possible en conséquence des réglages présents.

Proxmox est fourni avec un BIOS SeaBIOS, une implémentation de BIOS x86 opensource.

Il ne vous est cependant pas possible d’accéder au menu de celui-ci comme avec VirtualBox par exemple.

Au démarrage d’une VM, vous pourrez sélectionner le média de démarrage en appuyant sur la touche « echap » :

Pour utiliser l’UEFI, il faut utiliser le BIOS « OVMF » (UEFI) au lieu de SeaBIOS :

Vous aurez un message d’avertissement demandant l’ajout d’un disque UEFI :

L’ajout de ce disque UEFI se fera dans l’onglet matériel.

Contrairement à SeaBIOS, en UEFI, vous pourrez accéder au menu du BIOS UEFI :

Les options se limitent cependant à la gestion du volume de démarrage et aux options de Secureboot, qui ne seront pas traitées ici : le secureboot ayant été désactivé sur l’hôte.

Dialogue permettant le réglage d’une carte réseau :

Pour ajouter ou retirer un élément, cela se passe dans la ligne au-dessus des éléments de la VM :

Pour ajouter un disque à la VM, il faudra aller dans le menu de la machine → « matériel » :

Vous aurez alors l'écran de création de disques comme déjà vu dans la partie création d'une VM :

Vous pourrez alors voir le disque supplémentaire dans l'onglet « local-lvm » du serveur :

Pour agrandir un disque, il faudra aller dans les options « Matériel » de la VM concernée, sélectionner le disque concerné, puis dans le menu en haut « action disque », cliquer sur redimensionner :

Il vous sera ensuite demandé le nombre de Giga-octets à ajouter :

Pour un conteneur, le principe sera le même, en allant dans le menu « ressource », choix « disque racine » :

Pour les VM, une fois le disque dur agrandi, il faudra agrandir la partition et le système de fichiers à l’intérieur de celle-ci. La possibilité de le faire à chaud dépendra du système d’exploitation et du système de fichiers utilisé.

Proxmox étant un hyperviseur de type 1, il n’a pas pour but que ses VM utilisent du son.

Les VM n’auront pas de carte son par défaut, mais il est possible d’en ajouter une. Cependant, noVNC ne permet pas d’obtenir le son émis depuis une VM (le son ne fait pas partie du protocole VNC).

Le son fonctionnera par contre avec RDP ou un logiciel de contrôle à distance tel qu’Anydesk ou noMachine.

Cette fonctionnalité, également appelée « PCI passthrough » permet d’affecter un périphérique de l’hôte à une VM. Ce périphérique est alors indisponible pour l’hôte, il n’est pas partagé.

Pour cela, dans les options « matériel » de la VM concernée, il faudra ajouter un périphérique PCI, vous aurez alors la liste des périphériques disponibles sur le bus PCI :

Un cliché ou snapshot est une photographie à un instant T d'une VM. Après la création d'un snapshot, le ou les disque(s) de la VM est/sont figé(s) et un disque secondaire par disque présent est créé. Ce disque secondaire correspondra au delta des modifications disque effectuées après cliché par rapport au disque d’origine.

Le snapshot d’une VM va également intégrer une sauvegarde de l’état mémoire au moment de celui-ci. Les réglages de la VM sont également sauvegardés.

11-1-1. Création d’un cliché▲

11-1-2. Restauration cliché▲

11-1-3. Suppression de cliché▲

Cloner une VM permet d'en faire une copie. Cette copie sera alors autonome par rapport à sa source. Celle-ci aura sa propre vie et les mêmes réglages, les mêmes données que la VM source, du moins tant qu’aucune des VM n’est modifiée.

Pour cloner une VM, il faudra cliquer sur le bouton droit sur le nom de la VM :

Vous aurez ensuite l'écran suivant :

Il vous faudra choisir le stockage cible, le nom de la VM et éventuellement le nœud si vous avez plusieurs hyperviseurs en cluster et que souhaitez effectuer la copie sur un autre nœud.

Le numéro d’id sera incrémenté.

Pendant la création du clone, la VM source reste opérationnelle et utilisable.

Ci-dessous, une copie d’écran du tableau de bord lors d’un clonage :

Le cadenas indique que la VM n’est pas utilisable, le clonage n’étant pas terminé. Le cadenas disparaîtra une fois le clonage terminé.

Qu'est-ce qu'un template et à quoi cela va vous servir ? Un template, aussi appelé appliance, est une VM qui servira de modèle. Cela peut être utile pour préparer un modèle de VM qui sera ensuite dupliqué.

Si vous souhaitez transformer une VM (ou un conteneur) en template, il faudra cliquer dessus avec le bouton droit et sélectionner « convertir en modèle » :

Vous aurez une demande de confirmation.

La conversion d'une VM va changer son icône en icône .

La conversion d'un conteneur va changer son icône en icône .

Quand vous accéderez à « cloner » sur cet icône, vous aurez une option différente :

Vous pourrez sélectionner deux modes :

• clonage lié : un snapshot est créé sur la VM source (le template). La VM destination utilisera son propre snapshot dépendant du disque d'origine de la VM source. Les deux VM vont avoir leur propre existence, mais la VM destination est dépendante de la VM source du fait que son disque est un snapshot de celui de la VM source ;
• clonage intégral : la VM est clonée intégralement.

Avant de pouvoir créer un conteneur, il vous faut un modèle, appelé template, qui servira de modèle.

L’accès aux templates mis à disposition se fait par le clic sur le datastore les contenant, local(srv1) dans notre cas de figure-→ modèle de conteneurs :

Vous pourrez en récupérer en cliquant sur « modèles ».

Les templates proposés sont divisés en trois sections :

• la section mail ;
• la section system ;
• la section turnkeylinux.

Les templates « turnkeylinux » ne sont pas visibles sur l’écran ci-dessus, sauf à cliquer sur le « – » à côté de « section: system » pour réduire l’arborescence system.

La section « mail » va contenir deux versions du conteneur Proxmox mail gateway, autre produit proposé par Proxmox.

La section « system » va contenir des images pour la plupart des distributions Linux principales (Ubuntu, Debian, Fedora, Archlinux, ainsi que Alpine Linux, distribution très légère servant souvent de base aux conteneurs Docker).

La section « turnkeylinux » va contenir des images telles que Owncloud, Prestashop, NodeJS, c'est-à-dire des templates avec des services prêts à être utilisés. TurnKey Linuxdésigne une bibliothèque d’appliances

Les templates téléchargés seront stockés dans /var/lib/vz/template/cache ou dans le dossier template/cache de l'espace de stockage.

Si vous avez votre propre template au format tar.xz, celui-ci sera téléversable en cliquant sur « Téléversez », vous pouvez également télécharger un template depuis une URL en cliquant sur « Télécharger depuis l’URL ».

Une fois le template téléchargé, vous pourrez le voir et éventuellement le supprimer depuis l'espace de stockage local → contenu, dans la section « Templates de conteneurs » :

pveam update

La création du conteneur se fera par le clic en haut à droite à côté de créer VM.

12-2-1. 1er écran▲

12-2-2. Modèle▲

12-2-3. Disque▲

12-2-4. Processeur▲

12-2-5. Mémoire▲

12-2-6. Réseau▲

12-2-7. Finalisation▲

Pour faire une sauvegarde sur un support externe, il va falloir que le volume soit monté dans un point de montage.

Ce point de montage devra être mis à disposition dans les stockages Proxmox en créant un espace de stockage dans le dossier correspondant au point de montage, comme vu dans le chapitre sur les espaces de stockageDécouverte de l’interface d’administration.

Le fait que le support soit externe n'aura, à ce stade, pas d'importance.

La sauvegarde que nous avons vue ci-dessus concerne le déclenchement d’une sauvegarde ponctuelle. Pour planifier des sauvegardes, il faudra se rendre dans « datacenter » → « sauvegardes » :

Vous créerez alors un job de sauvegarde en cliquant sur « ajouter ».

Vous aurez alors un écran avec les réglages semblables à ceux d’une sauvegarde ponctuelle.

Il vous faudra alors cocher les VM ou conteneurs à sauvegarder, ainsi que la fréquence de sauvegarde :

Avant de valider la tâche, vous pourrez passer sur l’écran « rétention » vous permettant de gérer les sauvegardes conservées :

Ci-dessous l’écran avec la tâche créée :

Vous pourrez lancer la tâche au moment de votre choix en cliquant « lancer maintenant », et modifier les réglages de rétention en cliquant sur « Editer ».

Les sauvegardes effectuées seront disponibles dans le datastore concerné :

Les sauvegardes incrémentales ne sont pas gérées au sein de Proxmox. Les sauvegardes sont donc toujours complètes. Toutefois, il existe une solution pour répondre à cet usage, disponible sous la forme d’un produit annexe ; Proxmox Backup Server,Proxmox Backup Server produit que nous étudierons ultérieurement..

Pour restaurer une sauvegarde antérieure d’une VM, il faudra cliquer sur « Restaurer » depuis le menu de celle-ci :

Vous ne pourrez changer aucun réglage :

Pour restaurer une machine non présente, il faudra aller dans le datastore contenant la sauvegarde, onglet « sauvegarde », puis restaurer. Exemple ci-dessous avec le conteneur numéro 101 :

Proxmox fournit en plus de Proxmox Virtual Environnement (Proxmox VE) un produit nommé Proxmox Backup Server.

La version disponible et utilisée au moment de la rédaction de ce tutoriel est la version 3.2.

Proxmox Backup Server permet de faire des sauvegardes incrémentales et gère la déduplication (technique permettant de stocker les blocs de fichiers non modifiés une seule fois dans une sauvegarde incrémentale).

13-5-1. Installation depuis ISO▲

13-5-2. Installation sur système existant▲

wget https://enterprise.proxmox.com/debian/proxmox-release-bookworm.gpg

apt-key add proxmox-release-bookworm.gpg
mv proxmox-release-bookworm.gpg /etc/apt/trusted.gpg.d

deb http://download.proxmox.com/debian/pbs bookworm pbs-no-subscription

apt update
apt install proxmox-backup

13-5-3. Ajout d’un datastore sur le serveur de sauvegarde ProxMox▲

13-5-4. Ajout d’un datastore de sauvegarde aux serveurs à sauvegarder▲

13-5-5. Visualisation des sauvegardes▲

13-5-6. Visualisation depuis Proxmox Backup Server▲

Vous ne pourrez pas importer directement une appliance au format .ova depuis l’interface de Proxmox.

Il vous faudra commencer par télécharger le fichier .ova sur le serveur et décompacter l'archive tar (ou télécharger directement le contenu de celle-ci).

~# tar -xvf fichier.ova

Il existe une commande permettant l'import d'un fichier .ovf :

~# qm importovf <vmid> <fichier ovf> <datastore>

Exemple avec une appliance Alpine Linux exportée depuis VirtualBox, fichier .ova préalablement désarchivé :

~# qm importovf 110 alpine.ovf local-lvm
warning: unable to parse the VM name in this OVF manifest, generating a default value

transferred 1.5 GiB of 50.0 GiB (3.00%)
transferred 2.0 GiB of 50.0 GiB (4.00%)
transferred 2.5 GiB of 50.0 GiB (5.00%)

...

root@proxmox:~#

Une autre commande qm permet l'importation de disques :

~# qm importdisk <vmid> <source> <datastore> <option>

L'import dans un datastore LVM créera automatiquement le volume logique LVM contenant les données du disque virtuel.

Les réglages de carte réseau seront à revoir (sélection de la carte ou du bridge intégré à votre hôte).

Une fois l'opération effectuée, la machine virtuelle démarre sans difficulté.

Proxmox vient de récemment intégrer un assistant pour importer des VM depuis VMWare ESXi.

Pour cela, il vous faudra intégrer le datastore de l’ESXi dans Proxmox depuis le menu :

Il vous faudra entrer les informations de connexion (IP, nom d’utilisateur, mot de passe) :

Une fois connecté au datastore VMWare, vous pourrez voir les VM présentes et les importer :

Il existe une commande nommée virt-v2v contenue dans le paquet libguestfs qui permet de faciliter l'import de VM vers l'hyperviseur KVM. virvt-v2v s’appuie sur l'API libvirt qui permet de contrôler en ligne de commande les hyperviseurs les plus répandus.

La commande qm que nous avons utilisée pour importer un fichier .ovf ne permet pas l'export.

De façon à pouvoir exporter une VM, il va falloir :

• exporter les disques ;
• récupérer la définition de la VM.

L'export des disques pourra être fait avec la commande qemu qemu-img sous la forme :

qemu-img convert -f qcow2 -O vmdk source.qcow2 destination.vmdk

qemu-img gère les formats raw, vmdk, vdi, vhd.

Le format vmdk de VMWare sera le plus supporté.

Vous pouvez récupérer le fichier de définition de la VM dans /etc/pve/qemu-server/[id_vm].conf, qui contient les différents réglages de celle-ci et qui vous servira à créer la définition d'une nouvelle VM dans un autre hyperviseur que KVM.

Un cluster est un groupement de machines dédié à une tache. Cet ensemble peut être consacré au calcul, à la fourniture d’un système de fichiers distribué ou à la fourniture d’une base de données distribuée. Dans le cadre d’un datacenter, il s’agira de l’ensemble des machines participant à celui-ci.

Comme un cluster est un ensemble de machines ; nous allons préparer un hyperviseur supplémentaire.

Une fois le second serveur préparé, il vous faudra aller sur « centre de données » → « Grappe de serveurs » puis « créer une grappe de serveurs » sur le premier nœud :

Il vous sera demandé le nom du cluster :

Ce sera la seule information nécessaire à la création du cluster.

Après rafraîchissement de la page, le nom de votre cluster apparaîtra entre parenthèses à côté de datacenter :

Intégrons maintenant notre second serveur après sa préparation depuis son menu centre de données → Grappe de serveurs, en cliquant sur « rejoindre la grappe de serveur »  :

Il vous sera demandé les informations d’identification que vous trouverez sur le premier nœud en cliquant sur informations de jonction (juste à droite de « créer une grappe de serveurs ») :

Il faudra copier le champ information obtenu depuis le premier serveur dans la fenêtre de demande de jonction :

Une fois le copier-coller effectué, le détail des informations s’affichera, et il vous faudra entrer le mot de passe du serveur qui va être joint :

Jonction en cours :

Nous voyons ensuite les deux serveurs dans le cluster depuis n'importe lequel des hyperviseurs (dans la liste des nœuds du menu « cluster » et dans la partie gauche) :

L’ouverture d’une console de la VM de srv1 depuis srv2 ne pose pas de problème. La fenêtre de console comportant l’adresse IP de srv2 dans l’URL démontrant que l’ouverture se fait bien depuis celui-ci. Il sera également possible de modifier les réglages d’une VM présente sur srv1 depuis srv2 et vice-versa.

Pour gérer le cluster, Proxmox utilise Corosync. Les fichiers de configuration seront partagés entre les nœuds du cluster grâce au Proxmox Cluster File System (pmxcfs).

15-1-1. Contourner l'impossibilité de joindre à un cluster un hyperviseur avec des VM▲

lvrename pve vm-100-disk-0 vm-200-disk-0

ps -ef | grep qemu

Un autre intérêt d'avoir une gestion centralisée de plusieurs hyperviseurs est la possibilité de migrer une VM ou un conteneur d'un hyperviseur à un autre, que ce soit pour des questions de maintenance ou d'équilibrage de charge.

Migrer une VM (ou un conteneur) consistera à cloner celle-ci vers un autre nœud (un autre hyperviseur du datacenter) en activant celui-ci et supprimant la VM du nœud source. Ceci peut se faire à chaud c'est-à-dire avec la VM en activité.

qm migrate [id VM][destination] --online --with-local-disks

Pour migrer une VM, il faudra faire un clic droit sur celle-ci, puis choisir « Migrer » :

Il vous restera à sélectionner le nœud de destination :

Au bout d’un certain temps, le message « VM 100 - Migration » apparaît dans la liste des tâches, suivi d’un affichage dans le terminal :

Il est également possible d’effectuer une migration en ligne de commande avec la commande qm :

qm migrate 100 srv2 --online --with-local-disks

Les paramètres fournis dans l'exemple ci-dessus :

• 100 : identifiant de la VM ;
• srv2 : serveur de destination ;
• --online : permet la migration d'une VM active ;
• --with local-disks : permet de migrer également les disques locaux.

Exemple d’état d'une migration depuis la console :

root@srv1:~# qm migrate 100 srv2 --online --with-local-disks
2019-03-16 20:49:34 starting migration of VM 100 to node 'srv2' (192.168.1.201)
2019-03-16 20:49:36 found local disk 'local-lvm:vm-100-disk-0' (in current VM config)
2019-03-16 20:49:36 copying disk images
2019-03-16 20:49:36 starting VM 100 on remote node 'srv2'
2019-03-16 20:50:24 start remote tunnel
2019-03-16 20:50:32 ssh tunnel ver 1
2019-03-16 20:50:32 starting storage migration
2019-03-16 20:50:32 scsi0: start migration to nbd:192.168.1.201:60000:exportname=drive-scsi0
drive mirror is starting for drive-scsi0
drive-scsi0: transferred: 0 bytes remaining: 4294967296 bytes total: 4294967296 bytes progression: 0.00 % busy: 1 ready: 0
drive-scsi0: transferred: 33554432 bytes remaining: 4261412864 bytes total: 4294967296 bytes progression: 0.78 % busy: 1 ready: 0
…
drive-scsi0: transferred: 4243587072 bytes remaining: 51380224 bytes total: 4294967296 bytes progression: 98.80 % busy: 1 ready: 0
drive-scsi0: transferred: 4294967296 bytes remaining: 0 bytes total: 4294967296 bytes progression: 100.00 % busy: 1 ready: 0
all mirroring jobs are ready
2019-03-16 20:58:09 starting online/live migration on unix:/run/qemu-server/100.migrate
2019-03-16 20:58:09 migrate_set_speed: 8589934592
2019-03-16 20:58:09 migrate_set_downtime: 0.1
2019-03-16 20:58:09 set migration_caps
2019-03-16 20:58:09 set cachesize: 33554432
2019-03-16 20:58:09 start migrate command to unix:/run/qemu-server/100.migrate
2019-03-16 20:58:11 migration status: active (transferred 1178472, remaining 284626944), total 286072832)
2019-03-16 20:58:11 migration xbzrle cachesize: 33554432 transferred 0 pages 0 cachemiss 0 overflow 0
...

2019-03-16 21:00:37 migration xbzrle cachesize: 33554432 transferred 0 pages 0 cachemiss 1043 overflow 0
2019-03-16 21:00:38 migration status: active (transferred 255186967, remaining 163840), total 286072832)
2019-03-16 21:00:38 migration xbzrle cachesize: 33554432 transferred 408212 pages 438 cachemiss 1754 overflow 6
2019-03-16 21:00:41 migration speed: 0.42 MB/s - downtime 2817 ms
2019-03-16 21:00:41 migration status: completed
drive-scsi0: transferred: 4294967296 bytes remaining: 0 bytes total: 4294967296 bytes progression: 100.00 % busy: 0 ready: 1
all mirroring jobs are ready
drive-scsi0: Completing block job...
drive-scsi0: Completed successfully.
drive-scsi0: transferred: 4294967296 bytes remaining: 0 bytes total: 4294967296 bytes progression: 100.00 % busy: 1 ready: 1
all mirroring jobs are ready
drive-scsi0: Completing block job...
drive-scsi0: Block job cannot be completed, try again.
drive-scsi0: transferred: 4294967296 bytes remaining: 0 bytes total: 4294967296 bytes progression: 100.00 % busy: 1 ready: 1
all mirroring jobs are ready
drive-scsi0: Completing block job...
drive-scsi0: Block job cannot be completed, try again.
drive-scsi0: transferred: 4294967296 bytes remaining: 0 bytes total: 4294967296 bytes progression: 100.00 % busy: 1 ready: 1
all mirroring jobs are ready
drive-scsi0: Completing block job...
drive-scsi0: Block job cannot be completed, try again.
drive-scsi0 : finished

2019-03-16 21:03:07 ERROR: command '/usr/bin/ssh -e none -o 'BatchMode=yes' -o 'HostKeyAlias=srv2' root@192.168.1.201 qm nbdstop 100' failed: exit code 255
  Logical volume "vm-100-disk-0" successfully removed

Pour plus d'informations sur la commande qm, cliquez ici.

15-2-1. Migration d’une VM de LVM vers ZFS▲

La réplication sera la base pour pouvoir faire de la haute disponibilité.

La réplication permet d'avoir une copie d'une VM (ou d’un conteneur) prête à remplacer celle en cours d’exécution en cas de problème.

L’accès à la réplication sera possible soit dans les options de la VM ou du conteneur concerné :

Soit depuis le menu du datacenter :

La différence étant qu’avec accès depuis une VM ou un conteneur, elle ou il sera présélectionné dans le menu de création du job. Restera à sélectionner un serveur de destination et la fréquence de réplication depuis la sélection possible dans le menu déroulant :

Un job de réplication sera alors créé, accessible depuis « centre de données » → « réplication », depuis l’un des serveurs → « réplication », ou depuis le menu « réplication » de la machine concernée.

Il faudra créer un job de réplication par machine à répliquer.

Vous sectionnerez :

• la VM à répliquer ;
• la destination de la réplique (target) ;
• la fréquence (toutes les 15 min, 30 min, toutes les 2 heures, chaque jour à 02:30, 22:30, les options sont en dur).

Il est possible de faire la réplication d'une VM sur plusieurs autres nœuds (une réplique par nœud, un job par réplication)

Le message suivant apparaît si votre espace de stockage n’est pas compatible avec la réplication :

Vous pourrez déclencher une réplication immédiate depuis la liste des réplications de la machine. L’option ne sera logiquement pas disponible depuis la liste des réplications niveau datacenter.

Le temps de la première réplication dépendra du volume des disques à répliquer et du débit réseau disponible pour le transfert. Les réplications suivantes seront plus rapides, car elles ne prendront que le delta depuis la réplication précédente.

Il est possible de gérer les réplications en ligne de commande avec la commande pvesr.

Pour activer la haute disponibilité pour une VM, il vous faudra, depuis celle-ci, cliquer sur le menu « Plus », puis « Gérer la haute disponibilité » :

Vous aurez l'écran suivant :

Éléments à renseigner :

• nombre maximal de redémarrages : nombre maximal d'essais de redémarrages après échec ;
• nombre max de déménagements : nombre maximal d'essais de déplacements après échec de démarrage ;
• groupe : sera vu dans la section suivante ;

• état de la demande : état attendu, déclenchement de traitement si l'état n'est pas adéquat :

  • started : le système va tenter de garder la VM à l'état démarré,
  • stopped : le système va tenter de garder la VM à l'état stoppé,
  • disabled :le système va tenter de garder la VM à l'état stoppé sans tenter de déplacement,
  • ignored : le système va ignorer la VM pour le traitement de la haute disponibilité.

La gestion globale de la haute disponibilité s'effectuera dans « datacenter » → « HA » (il faut descendre dans le menu) :

Dans l'écran ci-dessus, nous voyons qu'il y a un quorum (Quorum OK), que le serveur maître (master) est srv2, que le LRM (Local Ressource Manager) est actif sur srv2 et idle (en attente) sur srv2 et srv3.

La partie « Ressource » présente les VM intégrées à la gestion de la haute disponibilité. L’état du conteneur et le nœud où il se trouve sont visibles ici.

J’ai simulé la perte d’un nœud en débranchant le réseau sur srv1. Après quelques instants, celui-ci a redémarré et les informations de haute disponibilité ont changé (visibles depuis srv2 et srv3) :

À ce stade, srv1 apparaît déconnecté. L’état LRM a changé pour srv1.

Au bout de quelques instants, le conteneur apparaît disponible sur srv2 :

srv2 est passé en actif et srv3 en idle au niveau du LRM.

Une fois le srv1 reconnecté, il réapparaît visible, le conteneur restant sur srv2, son LRM rebascule en idle à la place de « dead ».

Il reste possible de migrer le conteneur vers srv1 pour le remettre à son emplacement d’origine (mais vous pouvez très bien le laisser sur srv2) :

Une fois la fenêtre fermée, le conteneur réapparaît sur srv1 :

16-4-1. Suppression définitive d’un nœud perdu▲

pvecm nodes

pvecm delnode <nom du noeud>

rm -rf /etc/pve/nodes/<nom du noeud>

La notion de groupe va faciliter l'administration. La gestion de groupe se fera en allant dans le menu sous HA :

Ces réglages vous permettront par exemple de restreindre des VM à pouvoir se trouver sur deux serveurs parmi trois, de gérer prioritairement sur quel serveur elles doivent se trouver, de gérer les accès.

Restricted : cette option va justement servir à restreindre la présence de VM dans les nœuds sélectionnés. L'option devient une contrainte.

Nofailback : va empêcher la migration automatique vers le nœud à plus haute priorité.

Ces fonctions permettent d'affiner les réglages et d'ajouter la répartition de charge à la disponibilité garantie.

Le Fencing est le mécanisme permettant de s'assurer qu'une VM ne puisse pas être démarrée sur deux nœuds.

Ceci peut se présenter sous forme d'un dispositif matériel nommé watchdog. Si vous n'en avez pas, Proxmox utilisera par défaut le linux kernel softdog, un watchdog logiciel disponible en userland. Vous n’aurez dans ce cas aucune option dans le menu.

En général, un watchdog fonctionne de la façon suivante : si un compteur n'est pas mis à jour, le watchdog va déclencher une réinitialisation de la machine, ceci afin de détecter un éventuel blocage.

Les options de permissions peuvent être intéressantes. Vous pourrez donner des rôles prédéfinis sur des objets du pool à des utilisateurs précis pour leur déléguer l'administration de celui-ci.

Il va falloir créer l’utilisateur dans Proxmox. Pour cela il faudra aller dans « centre de données » → « Permissions » → « Utilisateurs » :

Le mot de passe devra ensuite être fixé en cliquant sur « mot de passe » :

Une fois l’utilisateur créé, il va falloir lui attribuer les droits dans le pool concerné :

Je lui attribue ici le droit PVEVMUser :

Je donne le rôle PVEVMUser à l’utilisateur « gestion ».

Dans le menu déroulant, la liste des rôles est accessible et explicitée.

Après connexion avec l’utilisateur « gestion » nouvellement créé, je peux voir qu’il n’a accès qu’au conteneur « WordPress », unique conteneur du pool dont « gestion » est membre.

Je peux arrêter le conteneur, mais je ne peux pas le supprimer ni modifier les réglages de sauvegarde ou de réplication, mon niveau de droits ne le permettant pas. Le rôle PVEVMUser permet de faire des sauvegardes sous réserve que vous ayez les droits sur les datastores concernés.

J’ai pu accéder au déclenchement d’une sauvegarde en donnant la permission d’accès sur le datastore (serveur → nom du datastore → permissions).

ZFS et un système de fichiers intégrant toutes les fonctionnalités attendues pour un FS moderne et puissant :

• intégrité des données forte ;
• gestion de volume intégré ;
• gestion de snapshots ;
• intégration de RAID logiciel ;
• ZFS over ISCSI ;
• système de copy-on-write permettant un rollback sur les données.

C’est un système de fichiers encore peu répandu par rapport à la famille ext, mais avec de puissantes fonctionnalités.

Pour créer un volume ZFS, il faudra aller dans « serveur » → « disques » → « ZFS » :

Le pool ZFS rpool visible est le pool créé par l’installation standard depuis l’ISO Proxmox.

Vous pourrez créer un volume ZFS multidisque avec support RAID ou à disque unique (RAID-0).

Choix des niveaux de RAID :

• disque unique (RAID0) ;
• mirror : RAID-1 deux disques en miroir ;
• RAID-10 : RAID 1 encapsulé dans un RAID-0 ;
• RAIDZ : RAID non standard équivalent au RAID-5 (un disque de parité) résistant à la perte d’un disque : deux disques minimum ;
• RAIDZ2 : RAID non standard équivalent au RAID-6 (deux disques de parité)  : quatre disques minimum ;
• RAIDZ3 : RAID non standard équivalent avec trois disques de parité. Cinq disques minimum ;
• dRAID : variante de ZRAID distribuant différemment les données de parité.

Les RAIDZ sont très compliqués à récupérer en cas d’incident.

La documentation officielle donne plus de précision sur ZFS.

Pour pouvoir utiliser le volume ZFS pour la réplication, il faudra lui donner le rôle de « backup » au niveau de l'espace de stockage.

Il est possible de supprimer un pool ZFS en cliquant sur le menu plus à droite après sélection du pool.

Ceph est une solution de stockage distribué ayant l’avantage de fonctionner sur du matériel standard. Ceph est notamment utilisé par OpenStack.

Ceph vous permettra d’avoir un espace de stockage distribué et répliqué.

Il s’agit d’un stockage en mode bloc ou objet compatible S3. CephFS est une surcouche permettant de gérer un système de fichiers par dessus Ceph.

Pour l’exploiter, il vous faudra trois nœuds (l’espace de stockage Ceph pouvant être hors machines Proxmox) pour garantir son quorum avec au minimum un disque dur libre par nœud pour y créer des OSD (Object Storage Device dans la terminologie Ceph).

Ceph est composé de plusieurs démons, répartis sur plusieurs machines. Il est possible d'avoir plusieurs types de démons sur la même machine, mais cela n'a pas d’intérêt, car ne fournit pas de redondance et c’est même contre-productif sur un cluster important.

• Mon : monitor. Ce sont les chefs d’orchestre du cluster Ceph. S’il n'y a pas de moniteur disponible, il n'y a pas d’accès au cluster Ceph. Pour assurer la pérennité du cluster, les moniteurs doivent être sur des machines indépendantes et en nombre impair. Un minimum de trois moniteurs est recommandé.
• OSD : démon OSD (Object Storage Device). Il y a un démon OSD par volume OSD. Ce démon est en charge du stockage, de la réplication et de la redistribution des données en cas de défaillance. Il fournit les informations de monitoring aux monitors. Un serveur peut contenir plusieurs OSD, mais n’est pas recommandable sur le plan de la redondance.
• MDS : Meta Data Service. Nécessaire à l’utilisation de CephFS. Va stocker les métadonnées de tous les fichiers et permettre le support de POSIX.
• Cephfs : filesystem POSIX fourni avec Ceph et s’appuyant sur le stockage Ceph (objet ou bloc). C’est la couche de plus haut niveau.

Les paquets Ceph ne sont pas installés par défaut. Si vous cliquez sur « serveur- »→ « Ceph », leur installation vous sera proposée :

Deux versions de Ceph vous seront proposées, la 18.2 Reef et la 17.2 Quincy. Si vous n’avez pas de licence Proxmox, il faudra choisir le dépôt « sans abonnement » :

Un écran de terminal va s’ouvrir et lancer la commande apt :

Dans l’écran suivant, vous devrez sélectionner l’adresse publique (Public Network) et l’adresse privée (Cluster Network) du cluster Ceph (mis à l’identique dans l’exemple).

Le réseau public est le réseau par lequel le client Ceph va dialoguer avec le cluster, l’adresse privée est l’adresse interne de communication entre les différents démons.

Message d’installation terminée :

L’écran Ceph indique l’état du cluster, en alerte ici vu qu’il n’y a aucun OSD.

L’installation a initialisé un premier moniteur, visible dans l’onglet Moniteur :

Nous allons ensuite procéder à la création d’un OSD dans ceph → osd :

Ceph utilise une partition pour son journal qui peut être sur un autre disque (à sélectionner dans le menu déroulant disque de BDD). Il est conseillé d'utiliser des disques SSD pour les journaux pour des questions de performances.

Une option permet de chiffrer l’OSD.

Ci-dessous l’écran présentant l’OSD nouvellement créé :

À ce stade, le cluster Ceph est toujours en alerte, vu qu’il nécessite trois OSD au minimum :

Il n’est donc pas possible de créer de CephFS.

Après installation de Ceph sur le second serveur srv2, celui-ci repère bien le moniteur sur srv1 :

J’ai ensuite ajouté des OSD sur trois nœuds différents.Ci-dessous : écran avec quatre OSD présents (un sur srv1, deux sur srv2, un sur srv3) :

Le cluster est maintenant opérationnel :

Nous allons ensuite pouvoir créer le CephFS, en commençant par créer un serveur de métadonnées (MDS) :

Une fois le MDS créé, vous pourrez créer le CephFS.

L’option Placement Group (PG) permettra l’optimisation de l’autoscaling et ne sera pas abordée ici.

Nous pouvons ensuite voir la présence du CephFS  sur tous les nœuds.

Nous ajoutons un MDS et un moniteur sur srv2 pour la redondance.

GlusterFS est un système de fichiers qui permet d'être distribué, répliqué ou distribué et répliqué. Il est plus facile à gérer que Ceph , qui lui est plutôt adapté à de grosses infrastructures. GlusterFS vient se greffer dans un point de montage sur le système de fichiers local existant. Il permet de facilement « concaténer » plusieurs volumes locaux de plusieurs machines en un seul volume.

Mode distribué :

Dans ce mode, les fichiers sont répartis entre les différentes machines du volume. Il n'y a pas de redondance. Vous devez donc vous assurer de la sauvegarde des données.

Mode répliqué :

Ce mode de fonctionnement réplique les fichiers sur les différents nœuds du volume. Il s'agit là uniquement de l'aspect redondance, les fichiers ne sont pas répartis sur les différentes machines, ils sont répliqués.

Mode distribué-répliqué :

Ce mode cumule la répartition et la redondance. Chaque nœud du volume distribué est redondé sur une autre machine. Il vous faut donc au minimum X machines multiplié par deux pour un volume consistant, X représentant le nombre de nœuds répartis.

18-3-1. Création d’un volume GlusterFS▲

systemctl enable glusterd
systemctl start glusterd

gluster peer probe srv2

peer probe: success

gluster volume create mygluster srv1:/glusterfs_srv1 srv2:/glusterfs_srv2 force

volume create: mygluster: success: please start the volume to access data

gluster volume info

Volume Name: mygluster
Type: Distribute
Volume ID: f1a0859d-4835-4987-bd1c-57b1645144f3
Status: Created
Snapshot Count: 0
Number of Bricks: 2
Transport-type: tcp
Bricks:
Brick1: srv1:/glusterfs_srv1
Brick2: srv2:/glusterfs_srv2
Options Reconfigured:
storage.fips-mode-rchecksum: on
transport.address-family: inet
nfs.disable: on

gluster volume start mygluster

volume start: mygluster: success

Zabbix est un outil de supervision open source. Les autres produits équivalents les plus connus sont Nagios et Centreon.

Je vais présenter ici un aperçu du fonctionnement de celui-ci

20-1-1. Installation serveur de Zabbix▲

wget https://repo.zabbix.com/zabbix/7.0/debian/pool/main/z/zabbix-release/zabbix-release_7.0-2%2Bdebian12_all.deb

dpkg -i zabbix-release_7.0-2%2Bdebian12_all.deb

apt update

apt install zabbix-server-mysql zabbix-frontend-php zabbix-apache-conf zabbix-sql-scripts zabbix-agent mariadb-server

mysql_secure_installation

~# mySQL

create database zabbix character set utf8mb4 collate utf8mb4_bin;
grant all on zabbix.* to zabbix@localhost identified by 'mot_de_passe';

zcat /usr/share/zabbix-sql-scripts/mysql/server.sql.gz | mysql --default-character-set=utf8mb4 -uzabbix -p zabbix

DBPassword=

systemctl restart zabbix-server zabbix-agent 
systemctl enable zabbix-server zabbix-agent

service apache2 restart

20-1-2. Installation du client Zabbix sous Linux▲

apt install zabbix-agent

service zabbix-agent restart

20-1-3. Installation du client Zabbix sous Windows▲

Grafana est une plateforme de représentation de données sous forme graphique. Associé avec InfluxDB ou Graphite, Grafana est souvent utilisé pour faire de la supervision.

Promox intègre l’envoi d’informations de supervision vers une base InfluxDB ou Graphite.

20-2-1. Installation InfluxDB▲

apt install gnupg2 apt-transport-https

wget https://repos.influxdata.com/influxdata-archive_compat.key

cp influxdata-archive_compat.key /etc/apt/trusted.gpg.d/

deb https://repos.influxdata.com/debian stable main

apt update
apt install influxdb2

service influxdb start

20-2-2. Paramétrage du serveur de métrique dans proxmox▲

20-2-3. Installation Grafana▲

wget https://dl.grafana.com/oss/release/grafana_11.1.0_amd64.deb
dpkg -i grafana_11.1.0_amd64.deb

apt-get install -f

systemctl daemon-reload
systemctl start grafana-server
systemctl enable grafana-server

La perte d’un nœud peut empêcher le démarrage d’une VM d’un autre nœud si le quorum (nombre minimum de nœuds pour le fonctionnement du cluster) n’est pas atteint. D’où l’intérêt d’avoir un nombre suffisant de nœuds.

Avant de pouvoir réintégrer un nouveau serveur avec un même nom, il va falloir supprimer l’ancien du cluster. Il n’y a pas d’options dans l’interface graphique pour sortir un nœud du datacenter, il va falloir le faire en ligne de commande.

Cette opération sera effectuée avec la commande :

pvecm delnode [nom du serveur à sortir]

pvecm expected 1

Le nombre est à adapter à votre configuration si vous avez plus de deux nœuds (bien que la commande devrait fonctionner, quel que soit le nombre de nœuds).

Une fois le serveur perdu supprimé, vous pourrez intégrer son remplaçant avec l’option « Rejoindre la grappe de serveur » comme vu au chapitre gestion d’un datacenterGestion d'un datacenter.

Les manipulations ci-dessous concernent l’aspect cluster Ceph.

La commande ceph status vous retournera un message comme celui-ci en cas de perte du nœud :

root@srv1:~# ceph status

  cluster:
    id:     dab25c59-b552-42a4-b6f1-9327f0a055a8
    health: HEALTH_WARN
            insufficient standby MDS daemons available
            Degraded data redundancy: 47/141 objects degraded (33.333%), 30 pgs degraded, 80 pgs undersized
            1/3 mons down, quorum srv1,srv3

  services:
    mon: 3 daemons, quorum srv1,srv3, out of quorum: srv2
    mgr: srv1(active), standbys: srv3
    mds: cephfs-1/1/1 up  {0=srv1=up:active}
    osd: 3 osds: 2 up, 2 in

  data:
    pools:   2 pools, 80 pgs
    objects: 47 objects, 103MiB
    usage:   2.22GiB used, 37.6GiB / 39.8GiB avail
    pgs:     47/141 objects degraded (33.333%)
             50 active+undersized
             30 active+undersized+degraded

root@srv1:~#

Nous pouvons voir que le moniteur de srv2 est out. Nous voyons la présence de trois OSD dont deux « up » et « in » (donc par définition un HS).

Nous retirons le monitor de srv2 :

root@srv1:~# ceph mon remove srv2
removing mon.srv2 at 192.168.1.201:6789/0, there will be 2 monitors

Il va nous falloir retirer le(s) OSD de srv2. Commençons par voir ce qu’il en est :

root@srv1:~# ceph osd tree
ID CLASS WEIGHT  TYPE NAME     STATUS REWEIGHT PRI-AFF
-1       0.05818 root default
-3       0.01939     host srv1
 0   hdd 0.01939         osd.0     up  1.00000 1.00000
-5       0.01939     host srv2
 1   hdd 0.01939         osd.1   down        0 1.00000
-7       0.01939     host srv3
 2   hdd 0.01939         osd.2     up  1.00000 1.00000

Nous voyons que osd.1 sur srv2 est down. Il n’y a qu’un OSD sur le serveur HS (srv2), nous le supprimons :

root@srv1:~# ceph osd rm osd.1
removed osd.1

Nous supprimons ensuite l’OSD de la crush map :

root@srv1:~# ceph osd crush remove osd.1
removed item id 1 name 'osd.1' from crush map

Puis les informations d’authentification :

root@srv1:~# ceph auth del osd.1
updated

Voyons ce que donne maintenant la commande ceph osd tree :

root@srv1:~# ceph osd tree
ID CLASS WEIGHT  TYPE NAME     STATUS REWEIGHT PRI-AFF
-1       0.03879 root default
-3       0.01939     host srv1
 0   hdd 0.01939         osd.0     up  1.00000 1.00000
-5             0     host srv2
-7       0.01939     host srv3
 2   hdd 0.01939         osd.2     up  1.00000 1.00000

Il nous reste ensuite à retirer les dernières traces de srv2 :

root@srv1:~# ceph osd crush remove srv2
removed item id -5 name 'srv2' from crush map

Résultat :

root@srv1:~# ceph osd tree
ID CLASS WEIGHT  TYPE NAME     STATUS REWEIGHT PRI-AFF
-1       0.03879 root default
-3       0.01939     host srv1
 0   hdd 0.01939         osd.0     up  1.00000 1.00000
-7       0.01939     host srv3
 2   hdd 0.01939         osd.2     up  1.00000 1.00000
root@srv1:~#

Il m’a fallu ensuite supprimer les entrées dans le fichier /etc/pve/ceph.conf et redémarrer le service cluster :

systemctl pve-cluster restart

Une fois le nœud réinstallé, il suffira de joindre le cluster comme déjà vu.

Pour la partie Ceph, il faudra recréer un monitor sur srv2 depuis l’un des autres serveurs, recréer l’OSD et rajouter un MDS si vous le souhaitez.

Le cluster Ceph devrait se réparer automatiquement. Une fois la réparation effectuée, vous devrez voir « health_ok » après avoir tapé la commande ceph status. Dans le cas contraire, il faudra tenter un ceph health. En cas de problème, les commandes devraient vous donner des informations concernant celui-ci.

Il est possible de monter une image disque d'une VM hors de celle-ci sous réserve que l’hôte puisse gérer le système de fichiers de celle-ci et que la VM soit arrêtée.

23-1-1. Image disque contenue dans un volume LVM▲

kpartx -av /dev/mapper/pve-vm--100--disk--0

add map pve-vm--100--disk--0p1 (253:7) : 0 67106816 linear 253:6 2048

mount /dev/mapper/pve--vm--100--disk--0p1 /mnt

23-1-2. Montage d’une image disque au format KVM qcow2▲

qemu-nbd --connect=/dev/nbd0 /var/lib/vz/images/[id]/[nom_disque].qcow2

modprobe nbd

fdisk /dev/nbd0 -l

mount /dev/nbd0p2 /mnt

umount /mnt
qemu-nbd --disconnect /dev/nbd0

23-1-3. Montage d'une image VMDK▲

23-1-4. Montage hors ligne du disque d'un conteneur▲

losetup: [fichier_image].raw: failed to set up loop device: Device or ressource buzy

losetup -f

/dev/loop0

losetup /dev/loop0 fichier_image.raw
mount /dev/loop0 /mnt

umount /mnt
losetup -d /dev/loop0

Un certificat valide sera nécessaire pour accéder à l’interface d’administration Promox en HTTPS sans message d’avertissement. Comme déjà spécifié, pour des questions de sécurité, je déconseillerais l’accès à l’interface d’administration Proxmox via Internet.

Pour gérer les certificats d'un serveur, il faudra aller dans son menu (srv1 dans notre exemple) → « système » → « certificats » :

Vous pouvez voir ci-dessus les certificats autosignés.

Vous pourrez importer les certificats générés par une autorité de certification depuis «Téléverser un certificat personnalisé ». Vous pourrez alors télécharger la clef privée et la chaîne de certificats ou faire un copier-coller.

Vous pourrez utiliser le service de certificats gratuits Let's Encrypt. Il vous faudra alors, dans la partie en bas (ACME), renseigner les domaines à certifier (éditer les domaines) et l'adresse mail qui sera liée aux certificats (compte d'enregistrement).

Proxmox permet l'authentification via un serveur LDAP ou Active Directory. Pour cela, il faudra aller dans « centre de données » → « Permissions » → « Authentification », « ajouter ».

Cet aspect n’a pas été testé.

Il est possible de restreindre les IP pouvant accéder à l'interface en écrivant dans le fichier /etc/default/pveproxy :

ALLOW_FROM="192.168.1.15"
DENY_FROM="all"
POLICY="allow"

Il faudra ensuite redémarrer le service :

service pveproxy restart

pveproxy utilise la syntaxe Apache2. L'exemple précédent autorise uniquement l’accès à l'interface depuis l'adresse IP 192.168.1.15.

Si votre hôte possède plusieurs cartes réseau, vous pouvez en dédier une pour l’accès à l’interface d’administration sur un réseau autonome.

23-4-1. Authentification à deux facteurs▲

pveum user tfa list

gestion@pam:
    recovery: recovery


    totp:     d61a2939-2f12-46a6-ae3d-e0a94dfe11cb
        totp

root@pam:
    recovery: recovery

pveum user tfa delete root@pam

/# pveum user tfa list
gestion@pam:
    recovery: recovery


    totp:     d61a2939-2f12-46a6-ae3d-e0a94dfe11cb
        totp

Lors de la connexion, vous avez un message « Aucune clef d'enregistrement valide » :

Le message est désactivable en modifiant le code dans le fichier /usr/share/javascript/proxmox-wideget-toolkit/proxmoxlib.js.

Recherchez la chaîne « Ext.Msg.show » qui devrait se trouver dans un test « if … .data.status.toLowerCase()!=’active’ commentez le bloc Ext.Msg.show jusqu’au else.

Il faudra redémarrer les service pveproxy avec la commande :

systemctl restart pveproxy.service

Vous n’aurez alors plus le message.

La suppression du message est également possible en achetant une licence, pensez à le faire si vous le pouvez, vous aurez accès à des mises à jour et du support et contribuerez à faire perdurer et évoluer le produit.

Je remercie LittleWhite pour ses relectures techniques ainsi que ClaudeLELOUP et escartefigue pour leur relecture orthographique.