Suivant les conseils de Tharyrok, je choisis d'installer Proxmox sur une instalation préalable de Debian.

Pour cette installation de Debian, j'ai utilisé l'ISO net-install de Debian. On peut tout décocher sauf SSH (ou installer tout de même les utilitaires système si on le souhaite).

Pour le moment, je mets de côté le chiffrement et j'ai formaté la partition du système en XFS.

Pourquoi XFS plutôt que BTRFS qui supporterait directement les snapshots ? Lorsqu'on fait des sauvegarde, BTRFS fait une sauvegarde qui tient compte du delta entre les modifications, sauf que dans le cas d'une vm dont le stockage change constamment, ça utilise beaucoup d'espace disque et on ne voit pas toujours bien l'espace restant.

Une fois mon installation de Debian effectuée, je me connecte en ssh à la machine :

ssh 192.168.178.92

Avant d'installer Proxmox, Tharyrok recommande d'installer le paquet ifupdown2, une version améliorée de la gestion de /etc/network/interface.

Avant de l'installer à distance, il faut effectuer une petite modification de /etc/network/interfaces pour remplacer allow hot-plug par auto, ce qui nous donne :

source /etc/network/interfaces.d/*

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
auto enp0s31f6
iface enp0s31f6 inet dhcp

On doit ensuite procéder à l'installation dans un screen car le réseau va redémarrer pendant l'installation.

On installe donc screen :

apt install screen

Puis :

screen
apt install ifupdown2 && ifreload -a

#Attention, si la configuration dans /etc/network/interfaces est en dhcp, le serveur peut changer d'IP

Pour que Proxmox puisse fonctionner, le nom d'hôte de la machine doit être résolvable via /etc/hosts. Cela est indiqué dans la documentation de Proxmox : https://pve.proxmox.com/wiki/Install_Proxmox_VE_on_Debian_11_Bullseye

J'ai modifié mon fichier hosts comme suit :

127.0.0.1       localhost
192.168.178.88  popmox # nom du proxmox

# The following lines are desirable for IPv6 capable hosts
::1     localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters

Il faut que

hostname --ip-address

retourne l'IP retourne l'IP du Proxmox.

Je vais maintenant modifier une nouvelle fois /etc/network/interfaces pour donner sa configuration réseau au Proxmox, avec ses switchs virtuels (config reprise d'une config proposée par Tharyrok et adaptée) :

# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

source /etc/network/interfaces.d/*

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
auto enp0s31f6
iface enp0s31f6 inet manual

auto vmbr0
iface vmbr0 inet static
        address 10.0.0.11/24
        bridge-ports none
        bridge-stp off
        bridge-fd 0
        mtu 9000
# Vswitch Internal

auto vmbr1
iface vmbr1 inet static
        address 192.168.178.88/24
        gateway 192.168.178.1
        bridge-ports enp0s31f6
        bridge-stp off
        bridge-fd 0
# Vswitch External

On préfère donner l'IP WAN du Proxmox à vmbr1 plutôt qu'à vmbr0 pour une raison de commodité : plus tard, dans l'interface graphique de Proxmox, ce sera ce switch virtuel qui est choisi par défaut pour les VMs.

MTU : La taille des paquet est historiquement 1500 octets. Ici, les 9000 octets pour des Jumbo frames.

bridge-ports : none pour ne pas lui associer d'interface, enp0s31f6 pour lui associer l'interface physique de la machine.

bridge-stp : pour le Spanning Tree Protocole, voir : https://wiki.linuxfoundation.org/networking/bridge_stp

Petit tip : on peut commenter certaines lignes de la config réseau et cela apparaît ensuite dans l'interface web de Proxmox

On ajoute les dépôts “no subscription” de Proxmox à notre fichier /etc/apt/sources.list

deb http://ftp.debian.org/debian bullseye main contrib
deb http://ftp.debian.org/debian bullseye-updates main contrib

# PVE pve-no-subscription repository provided by proxmox.com,
# NOT recommended for production use
deb http://download.proxmox.com/debian/pve bullseye pve-no-subscription

# security updates
deb http://security.debian.org/debian-security bullseye-security main contrib

Puis on installe wget et gpg et on récupère la clé de Proxmox :

apt install wget gpg
wget https://enterprise.proxmox.com/debian/proxmox-release-bullseye.gpg -O- | apt-key add -

Puis on met à jour le serveur :

apt update
apt dist-upgrade

Et enfin on installe Proxmox (ici avec opensmtpd au lieu de postfix pour faire comme le recommande Tharyrok) :

apt install proxmox-ve opensmtpd

Une fois Proxmox installé, on va redémarrer pour que Proxmox boot sur son propre kernel :

systemctl reboot

Puis on peut supprimer le ou les noyaux Debian :

apt remove linux-image-amd64 'linux-image-5.10*'
update-grub # en root 

On enlève aussi le paquet os-prober comme le recommande la documentation de Proxmox.

Il s'agit d'un paquet qui scanne toutes les partitions pour en faire des entrées en dans grub (pour un dual boot par exemple) et il pourrait prendre les partitions des machines virtuelles pour des partitions à ajouter au boot (ce qu'on ne veut pas).

apt remove os-prober

A l'issue de l'installation, on peut aussi retirer le dépot de Proxmox Enterprise qui s'est ajouté dans /etc/apt/source.list.d :

rm /etc/apt/sources.list.d/pve-enterprise.list

On peut accéder à l'interface web de Proxmox via :

https://192.168.178.88:8006

Identifiant root / mot de passe Identification Linux PAM.

On peut authoriser un autre utilisateur à se connecter à l'interface web en allant dans : Datacenter → Permissions

Les utilisateurs PAM sont les utilisateurs Gnu/Linux des machines Proxmox. Un même utilisateur peut donc avoir un mot de passe différent selon le node.

Les utilisateurs PVE sont stockés dans la configuration du cluster Proxmox et sont les mêmes sur toutes les machines du cluster.

S'il n'est pas prévu d'utiliser une machine virtuelle comme pare-feu (comme PfSense), il faut indiquer à Proxmox de faire du NAT pour les machines virtuelles puissent avoir accès à internet.

Cela se fait dans mon cas en ajoutant les lignes suivantes à /etc/network/interfaces :

        post-up echo 1 > /proc/sys/net/ipv4/ip_forward
        post-up   iptables -t nat -A POSTROUTING -s '10.0.0.0/24' -o vmbr1 -j MASQUERADE
        post-down iptables -t nat -D POSTROUTING -s '10.0.0.0/24' -o vmbr1 -j MASQUERADE

- où 10.0.0.0/24 est mon réseau interne virtuel de vmbr0

- et vmbr1 l'interface derrière laquelle faire le NAT (celle connectée physiquement à mon réseau local)

Je place ce bout de config un peu en dessous de # Vswitch Internal, sous la config de vmbr0.

Dans le cas où j'utiliserais une configuration sans machine pfSense, il serait sûrement utile de configurer en plus le pare-feu de Proxmox pour des raisons de sécurité.

TODO : à tester.

L'un des avantages de Proxmox est de pouvoir s'associer avec d'autres Proxmox pour réaliser un cluster.

On peut donc installer un second Proxmox.

Dans /etc/network/interfaces, on édite une configuration similaire où on donne le même réseau interne (mais pas la même IP évidemment) à vmbr0.

Si on fait un copier/coller, attention à bien changer les IP et le nom de l'interface à bridger pour vmbr1.

# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

source /etc/network/interfaces.d/*

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
auto eno1
iface eno1 inet manual


auto vmbr0
iface vmbr0 inet static
        address 10.0.0.12/24
        bridge-ports none
        bridge-stp off
        bridge-fd 0
        mtu 9000

# Vswitch Internal


        post-up echo 1 > /proc/sys/net/ipv4/ip_forward
        post-up   iptables -t nat -A POSTROUTING -s '10.0.0.0/24' -o vmbr1 -j MASQUERADE
        post-down iptables -t nat -D POSTROUTING -s '10.0.0.0/24' -o vmbr1 -j MASQUERADE


auto vmbr1
iface vmbr1 inet static
        address 192.168.178.98/24
        gateway 192.168.178.1
        bridge-ports eno1
        bridge-stp off
        bridge-fd 0

Sur les deux Proxmox, on modifie /etc/hosts pour indiquer l'IP du second Proxmox.

Un truc donné par Tharyrok pour avoir le lien le plus direct et les meilleures performances possibles est de dédier une interface au lien entre les Proxmox et d'utiliser l'adresse link local IPv6 entre les différentes interfaces, mais pour le moment, je n'ai qu'une interface réseau physique et je laisse un peu de côté l'IPv6… donc simplement indiqué l'IPv4 de mon réseau local via laquelle les Proxmox vont communiquer.

Ça donne par exemple pour le premier Proxmox popmox :

127.0.0.1       localhost
192.168.178.88  popmox
192.168.178.98  proxcorn

# The following lines are desirable for IPv6 capable hosts
::1     localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters

On peut vérifier que les Proxmox communiquent bien entre eux par un ping :

ping proxcorn
ping popmox

Si tout fonctionne bien, on peut passer à la mise en cluster elle-même avec la commande pvecm.

Il faut commencer par créer le cluster depuis l'un des deux Proxmox en utilisant la commande pvecm create {name_cluster}.

Ici, le cluster formé par popmox et proxcorn s'appellera (subtilement) popcorn :

pvecm create popcorn

Puis, le second Proxmox doit demander à rejoindre le cluster.

Ceci se fait en ajoutant le “node” du premier Proxmox qui a créé le cluster, ici popmox (en utilisant son nom d'hôte - ça marche puisqu'il est associé à une IP dans le hosts du second Proxmox).

La commande est donc effectuée depuis proxcorn sous la forme pvecm add {name_node} :

pvecm add popmox

Au premier abord, il ne m'a pas paru intuitif que ce soit le second Proxmox qui doive ajouter le premier pour entrer dans le cluster. En réalité, cela se passe de cette manière là car le second Proxmox va interroger la configuration cluster du premier.

En créant le cluster, le premier Proxmox se dote en effet d'une configuration que le second Proxmox va venir lire pour entrer dans le cluster. Si le cluster n'a pas été créé par le premier Proxmox en amont, on obtient des erreurs comme celles-ci :

check cluster join API version
No cluster network links passed explicitly, fallback to local node IP '192.168.178.91'
Request addition of this node
An error occurred on the cluster node: invalid corosync.conf
! no nodes found
Cluster join aborted!

Une fois les Proxmox en cluster, tous les fichiers présents dans /etc/pve/ sont automatiquement synchronisés entre les noeuds du cluster.

En principe, l'ajout d'un nouveau noeud à un cluster se fait lorsque la nouvelle machine est encore vide.

Si celle-ci contient déjà VM ou des conteneurs, la commande pvecm add ne fonctionne pas et prévient de la présence de machines sur l'hôte :

root@proxcorn:/# pvecm add popmox
Please enter superuser (root) password for 'popmox': ********
detected the following error(s):
* this host already contains virtual guests
Check if node may join a cluster failed!

On peut néanmoins forcer Proxmox à rejoindre le cluster mais les fichiers de configuration des VMs et des conteneurs présents dans dans /etc/pve/qemu-server/ et /etc/pve/lxc/ seront écrasés et les VM et conteneurs concernés n'apparaîtront pas dans le cluster !

Les espaces de stockage des vms et des conteneurs eux-mêmes ne sont pas affectés car ils ne se trouvent pas dans /etc/pve/ et ce sont uniquement les configurations qui sont concernées.

Avant de lancer la commande, il faut donc backuper ces fichiers de configuration dans un répertoire qui ne sera pas concerné par le cluster.

On peut le faire en faisant par exemple :

cp -r /etc/pve/lxc/ /root/pct-config/ # pour les conteneurs
cp -r /etc/pve/qemu-server/ /root/qm-config/ #pour les VM

On pourra les restaurer par la suite, mais attention… pour que ça marche, il faut que les identifiants des VMs et les conteneurs concernés n'entrent pas en conflit avec ceux du premier Proxmox…

C'est à prévoir en amont, ou alors il faudra renommer différents fichiers (pas encore complètement testé pour la migration des VMs) :

• renommer le nom du fichier de configuration dans /etc/pve/
• dans ce fichier de configuration, éditer la ligne commençant par rootfs et remplacer les deux mentions de l'identifiant par le nouvel identifiant.
• dans l'espace de stockage, se rendre dans le dossier images/ et renommer le dossier avec le nouvel identifiant
• dans le dossier lui-même, renommer le nom du disque virtuel avec le nouvel identifiant

Pour forcer un Proxmox contenant déjà des guests à rejoindre le cluster, on ajoute l'option -force à la commande précédente :

root@proxcorn:/# pvecm add popmox -force
Please enter superuser (root) password for 'popmox': ********
detected the following error(s):
* this host already contains virtual guests

WARNING : detected error but forced to continue!

Establishing API connection with host 'popmox'
The authenticity of host 'popmox' can't be established.
X509 SHA256 key fingerprint is 92:FC:62:6A:E6:E5:99:D8:E4:DD:FC:73:19:A1:C8:FC:AD:82:DB:33:0B:D3:79:D2:CD:1E:92:39:E6:0B:C3:97.
Are you sure you want to continue connecting (yes/no)? yes
Login succeeded.
check cluster join API version
No cluster network links passed explicitly, fallback to local node IP '192.168.178.98'
Request addition of this node
Join request OK, finishing setup locally
stopping pve-cluster service
backup old database to '/var/lib/pve-cluster/backup/config-1656253975.sql.gz'
waiting for quorum...OK
(re)generate node files
generate new node certificate
merge authorized SSH keys and known hosts
generated new node certificate, restart pveproxy and pvedaemon services
successfully added node 'proxcorn' to cluster.

On restaure ensuite les fichiers de configs des conteneurs et des vm qui ont été backupés dans leurs répertoires d'origine.

Comme leurs espaces de stockage sont restent les mêmes ça re-fonctionne.

Pour être retiré du cluster, le proxmox ne doit plus avoir ni de VMs ni de conteneurs. Il doit être arrêté correctement et ne doit pas pouvoir se relancer avec sa configuration actuelle au risque de tout casser.

On enlève ensuite le node à retirer mais il faut d'abord réduire le quorum :

root@popmox:/# pvecm delnode proxcorn
cluster not ready - no quorum?
root@popmox:/# pvecm expected 1
root@popmox:/# pvecm delnode proxcorn
Killing node 2
Could not kill node (error = CS_ERR_NOT_EXIST)

pvecm expected 1 indique dans notre cas que le premier proxmox sera seul dans le quorum.

La doc Proxmox indique qu'on peut ignorer le message d'erreur : “Could not kill node (error = CS_ERR_NOT_EXIST)”.

En effet, pvecm nodes ne renvoit plus qu'un noeud :

root@popmox:/# pvecm nodes

Membership information
----------------------
    Nodeid      Votes Name
         1          1 popmox (local)

Il n'apparait plus non plus dans l'interface web.

On peut alors réinstaller le node et le réinsérer dans le cluster avec un simple pvecm add popmox

Attention, en cas de réinstallation, les stockages associés à l'ancien Proxmox redeviendront visible alors qu'ils ne correspondent plus à rien et devront être supprimés.

On trouve la documentation de Proxmox en suivant ce lien : https://pve.proxmox.com/pve-docs/pve-admin-guide.html#_remove_a_cluster_node

Mais quid si le noeud n'a pas été retiré correctement ?

Dans ce cas, la simulation montre qu'on rencontre certains problèmes.

J'ai simulé une situation ou proxcorn est retiré du cluster alors qu'il possède encore une VM, la VM 113.

Même après avoir fait pvecm expected 1 et pvecm delnode proxcorn, le noeud problématique apparaît toujours dans l'interface de proxmox même si un pvecm nodes ne renvoit qu'un unique node.

On peut suivre ce que propose la documentation de Proxmox : https://pve.proxmox.com/pve-docs/pve-admin-guide.html#_remove_a_cluster_node à la rubrique 5.5.1…

oot@popmox:/# systemctl stop pve-cluster
root@popmox:/# systemctl stop corosync
root@popmox:/# pmxcfs -l
[main] notice: forcing local mode (although corosync.conf exists)
root@popmox:/# rm /etc/pve/corosync.conf
root@popmox:/# rm -r /etc/corosync/*
root@popmox:/# killall pmxcfs
root@popmox:/# systemctl start pve-cluster

Ici, on arrête le cluster et corosync et on force cluster à fonctionner comme s'il était seul en local. Cela permet de retirer les configs contenues dans /etc/pve/corosync.conf et /etc/corosync/* qui sont autrement impossible à éditer (tant que le cluster s'estime en mauvais état, sans quorum, les fichiers sont en lecture seule, même pour root).

On redémarre ensuite le clsuter (mais pas corosync).

root@popmox:/# pvecm delnode proxcorn
Node/IP: proxcorn is not a known host of the cluster.
root@popmox:/# pvecm status
Error: Corosync config '/etc/pve/corosync.conf' does not exist - is this node part of a cluster?
root@popmox:/# reboot

Dans mon cas, ça n'a rien changé à l'affaire et j'ai tenté un reboot… après lequel la situation était toujours la même.

La situation a pu être résolue en réinstallant proxcorn et en recréant le cluster depuis popmox.

En faisant ça, les deux nodes sont à nouveau actifs.

Cependant, la VM 113 apparaît toujours dans l'interface, alors même que proxcorn n'a plus ni sa configuration ni son disque et ne démarre plus.

root@proxcorn:~# qm start 113
volume 'local:113/vm-113-disk-0.qcow2' does not exist

Et on ne sait pas la détruire non plus.

root@proxcorn:~# qm destroy 113
disk image '/var/lib/vz/images/113/vm-113-disk-0.qcow2' does not exist

Or, cette machine fantôme bloque alors la restauration de la VM depuis le PBS (voir plus bas). Tant qu'elle reste visible, elle empêche une restauration avec le même identifiant de VM.

Pour essayer de résoudre le problème, mon idée à été de recréer le fichier 113.conf d'après celui d'une autre VM en enlevant les lignes qui pouvaient faire conflit.

Ainsi, à partir du fichier de configuration de la VM 103.conf :

boot: order=scsi0;ide2;net0
cores: 1
ide2: none,media=cdrom
memory: 2048
meta: creation-qemu=6.2.0,ctime=1656580197
name: Debian2
net0: virtio=62:0F:CB:B9:87:11,bridge=vmbr0,firewall=1
numa: 0
ostype: l26
scsi0: local:103/vm-103-disk-0.qcow2,size=32G
scsihw: virtio-scsi-pci
smbios1: uuid=b994f2af-e0ea-4341-9f05-b08b1ebd6cfd
sockets: 1
vmgenid: 8f567c7f-e3ac-4f87-9815-b54d3968f80a

J'ai créé le fichier 113.conf avec :

boot: order=scsi0;ide2;net0
cores: 1
ide2: none,media=cdrom
memory: 2048
meta: creation-qemu=6.2.0,ctime=1656580197
name: Debian2
net0: virtio=62:0F:CB:B9:87:11,bridge=vmbr0,firewall=1
numa: 0
ostype: l26
scsihw: virtio-scsi-pci
sockets: 1

Proxmox semble détecter la supercherie mais cela fonctionne malgré l'erreur.

root@proxcorn:/etc/pve/qemu-server# qm destroy 113
vm 113 - unable to parse config: /etc/pve/qemu-server# cat 103.conf

Dans cette rubrique, je souhaite indiquer quelques notes / observations concernant le fonctionnement du cluster décrit précédemment.

L'une de mes machines de test ne supporte pas la virtualisation KVM.

Il est possible de la désactiver dans les options des VM… mais c'est très très très lent…

Bref, il me faut utiliser une machine qui supporte la virtualisation KVM pour vraiment pouvoir tester dans de bonnes conditions…

En fait mon processeur supporte bel et bien la virtualisation KVM (l'option était juste cachée dans un sous-sous-menu du BIOS que je n'avais pas vue…)

Une différence importante :

Les VMs peuvent être migrées tout en étant en état de fonctionnement.

Au contraire, les conteneurs doivent être éteints pour être migrés, ce qui entraîne un petit downtime (pas très long, mais il faut le savoir et en tenir compte).

C'est dû aux limitations physiques des conteneurs. Plus légers, ils utilisent les ressources de l'hôte pour fonctionner et ne peuvent donc passer d'un hôte à l'autre à chaud. C'est renseigné dans la doc de Proxmox sur cette page : https://pve.proxmox.com/wiki/Linux_Container

(Une autre limitation est que c'est retreint par conséquent à des systèmes Linux.)

Les VMs, en virtualisant tout un OS, sont plus lourdes, mais permettent en contrepartie le déplacement sans interruption des services.

Note : Si on a du matériel avec une architecture très différente, on peut choisir une architecture qui le plus petit dénominateur commun dans la liste des types de CPU lors de la création d'une VM, comme kvm64 plutôt que host (où la machine prendrait les caractéristiques CPU de l'host).

Les informations concernant le stockage du cluster sont dans : /etc/pve/storage.cfg

On peut formater et ajouter un disque (autre disque SATA ou USB) dans Node → disque

Pour utiliser un disque, il faut commencer par le wiper.

Cela peut aussi se faire en ligne de commande comme on l'a fait à l'atelier Proxmox de Neutrinet :

lsblk -fs
wipefs -a /dev/XX

Une page dans la documentation de Proxmox indique ce que permettent les différents types de stockage : https://pve.proxmox.com/wiki/Storage

Un formatage en XFS comme je l'ai fait ne permet les snapshots que pour les VMs (et moyennant que leur disque soit au format qcow2) et non les conteneurs car le storage local est configuré avec le type “Directory” (on peut le voir dans Datacenter → Storage).

Si l'on souhaite pouvoir prendre des snapshot des conteneurs, ceux-ci doivent être stockés dans un pool ZFS (sur un second disque - ou une seconde partition ?).

Un pool ZFS séparé permet aussi de configurer la réplication.

La réplication n'est pas de la HA, c'est une copie à intervals réguliers (définis par l'utilisateur) vers l'autre Proxmox. Si la machine est déplacée sur le Proxmox où elle est répliquée, la réplications s'inverse (à vérifier).

On peut créer un pool ZFS en allant dans Node → Disk → ZFS.

A l'état actuel du cluster, les VM et les conteneurs peuvent être répliqués sur l'autre noeud, ou être migrés entre les deux machines. Cependant, même dans le cas d'une migtration, ils sont recopiés à chaque fois d'une machine à l'autre, ce qui est lent.

Si les machines ont un second disque dur, celui-ci n'est accessible que localement et les VMs ou CT dont les volumes sont dessus peuvent difficilement être migrés.

On peut néanmoins définir un espace partagé entre les proxmox en utilisant un partage réseau (NFS, CIFS, ISCUSI) ou en utilisant CEPH sur des disques physiques.

Voir la doc Proxmox : https://pve.proxmox.com/pve-docs/chapter-pvesm.html

Avec les configurations réseau ci-dessus, il faut modifier la configuration des VMs et des conteneurs lorsqu'ils passent d'un Proxmox à l'autre car ils ne sont plus relié au même scitch virtuel et n'ont plus la même gateway.

Une possibilité que j'ai trouvé pour remédier au problème est de donner à chacun des Proxmox la même IP supplémentaire sur vmbr0.

auto vmbr0
iface vmbr0 inet static
        address 10.0.0.11/24
        address 10.0.0.1/24
        bridge-ports none
        bridge-stp off
        bridge-fd 0
        mtu 9000

On donne ensuite aux VMs et conteneurs l'IP 10.0.0.1 comme gateway.

Ca n'a pas fonctionné après un systèmectl restart networking.service mais après un redémarrage de chacun des Proxmox.

Penser à cocher le qemu agent lors de la création des VM sinon on ne parvient pas à les commander de puis Proxmox et on obtient l'erreur :

trying to acquire lock...
TASK ERROR: can't lock file '/var/lock/qemu-server/lock-110.conf' - got timeout

L'installation d'un Proxmox Backup Server est similaire à celle d'un Proxmox.

On peut partir d'une ISO mais aussi installer le serveur sur une machine qui a déjà une base Debian.

Ici aussi, il est nécessaire d'avoir ifdown2, on doit donc modifier /etc/network/interfaces en conséquences, veiller à lancer la commande dans un screen et penser à recharger la configuration réseau à l'issue de la manipulation.

screen
apt install ifupdown2 && ifreload -a

On édite aussi le fichier /etc/hosts avant l'installation.

Puis on ajoute la clé Proxmox Backup Server et les dépôts dans /etc/apt/sources.list.

# PBS pbs-no-subscription repository provided by proxmox.com,
# NOT recommended for production use
deb http://download.proxmox.com/debian/pbs bullseye pbs-no-subscription

On télécharge la clé de Promox :

apt install wget gpg
# wget https://enterprise.proxmox.com/debian/proxmox-release-bullseye.gpg -O /etc/apt/trusted.gpg.d/proxmox-release-bullseye.gpg

Et on installe le PBS :

install proxmox-backup

Il existe aussi un paquet proxmox-backup-server qui permet d'installer le serveur de backup par dessus de Debian avec les paquets minimum nécessaires. Le paquet proxmox-backup installe en revanche la même chose qu'installerait l'installateur de l'ISO.

Une fois le PBS installé, la configuration des Backup peut être faite en suivant ce tutoriel : https://notamax.be/proxmox-backup-server-presentation-et-premiers-pas/

Globalement, le fonctionnement est assez intuitif.

Il faut cependant dédier un disque entier pour le pool ZFS du Datacenter. Ce peut-être un disque branché en USB.

La restauration des VMs se fait depuis les Proxmox qui sont “clients” du PBS via le stockage pbs.

On peut restaurer sur popmox une vm qui était sur proxcorn et vice versa. Ca fonctionne bien.

On installe CEPH sur chacun des deux Proxmox :

pveceph install

Sur l'un des Proxmox (ici popmox), on initialise le cluster ceph :

root@popmox:~# pveceph init --network 192.168.178.0/24

Sur chacun des Proxmox, on crée les moniteurs et les managers :

pveceph mon create
pveceph mgr create

Sur le premier Proxmox, le manager est créé en même temps que le moniteur.

root@popmox:~# pveceph mon create
unable to get monitor info from DNS SRV with service name: ceph-mon
creating new monitor keyring
creating /etc/pve/priv/ceph.mon.keyring
importing contents of /etc/pve/priv/ceph.client.admin.keyring into /etc/pve/priv/ceph.mon.keyring
monmaptool: monmap file /tmp/monmap
monmaptool: generated fsid fa0ee8c7-43f0-480f-bd9e-0bc3710b8b10
epoch 0
fsid fa0ee8c7-43f0-480f-bd9e-0bc3710b8b10
last_changed 2022-07-01T14:05:45.303633+0200
created 2022-07-01T14:05:45.303633+0200
min_mon_release 0 (unknown)
election_strategy: 1
0: [v2:192.168.178.96:3300/0,v1:192.168.178.96:6789/0] mon.popmox
monmaptool: writing epoch 0 to /tmp/monmap (1 monitors)
created the first monitor, assume it's safe to disable insecure global ID reclaim for new setup
Created symlink /etc/systemd/system/ceph-mon.target.wants/ceph-mon@popmox.service -> /lib/systemd/system/ceph-mon@.service.
creating manager directory '/var/lib/ceph/mgr/ceph-popmox'
creating keys for 'mgr.popmox'
setting owner for directory
enabling service 'ceph-mgr@popmox.service'
Created symlink /etc/systemd/system/ceph-mgr.target.wants/ceph-mgr@popmox.service -> /lib/systemd/system/ceph-mgr@.service.
starting service 'ceph-mgr@popmox.service'
root@popmox:~# pveceph mgr create
ceph manager directory '/var/lib/ceph/mgr/ceph-popmox' already exists

Sur le second Proxmox, on tape les deux commandes.

Puis on créé les OSD qui sont des unités de stockages de CEPH :

pveceph osd create /dev/sdX

Pour que CEPH puisse fonctionner correctement en cluster, il faut que tout le cluster ait la même heure. On installe timesyncd qui est uniquement la partie cliente (à la différence de ntpd qui est aussi un serveur).

apt install systemd-timesyncd

Sur l'une seule des machines, popmox à nouveau, on créé le pool de stockage auquel on ajoute les OSD créés :

pveceph pool create popceph --add_storages 

CEPH procède par placements de groupes (voir ici : https://docs.ceph.com/en/latest/rados/operations/placement-groups/). Il s'agit de sous-blocs dans les OSD qui vont gérer l'activité de dupliquer ou non une donnée. Cela est géré par un algorithme qui définit dans quel node vont se retrouver les données selon une formule mathématique.

Un calculateur en ligne permet de définir les nombres adéquats selon la situation : https://old.ceph.com/pgcalc/

Mais on peut plus simplement définir un fonctionnement automatique avec la commande :

ceph osd pool set popceph pg_autoscale_mode on