Outils pour utilisateurs

Outils du site


infrastructure:proxmox-tests-cluster:proxmox_-_tests_cluster_et_high_availability

Proxmox - tests cluster et High Availability

Nœuds

  1. plmasrv06
    • eno1 → vmbr0 192.168.207.61/24 (admin)
    • eno2 10.10.207.60/24 (data)
  2. plmasrv07
    • eno1 → vmbr0 192.168.207.71/24 (admin)
    • eno2 10.10.207.60/24 (data)
  3. plmasrv08
    • eno1 → vmbr0 192.168.207.81/24 (admin)
    • eno2 10.10.207.60/24 (data)

Cluster

  1. bellebaie
    • plmasrv06
    • plmasrv07
    • plmasrv08

Serveur NFS externe (Debian)

vi /etc/network/interfaces
# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
allow-hotplug enp13s0
iface enp13s0 inet static
        address 192.168.207.100
        netmask 255.255.255.0
        gateway 192.168.207.254

allow-hotplug enp15s0
iface enp15s0 inet static
        address 10.10.207.100
        netmask 255.255.255.0
apt install nfs-kernel-server
mkdir /usr/share/nfs-shared
chmod 757 /usr/share/nfs-shared
vi /etc/exports
/usr/share/nfs-shared/ 10.10.207.60(rw,root_squash)
/usr/share/nfs-shared/ 10.10.207.70(rw,root_squash)
/usr/share/nfs-shared/ 10.10.207.80(rw,root_squash)

# reboot

Création d'une sauvegarde régulière

  1. Datacenter → Backup → Add
    • Storage : local
    • Selection mode : All
    • Mode : Snapshot

Création de VMs

  1. Créer VM Debian Stretch sur plmasrv06
    • ID : 100
    • Name : vm1
    • Hard Disk (scsi0) : NFS:100/vm-100-disk-1.qcow2,size=32G
    • Processors : 2 (1 sockets, 2 cores)
    • Memory : 2.00 GiB
    • → Options → Start at boot → Yes
  2. Full clone de VM 100
    • ID : 101
    • Name : vm2
  3. Attendre que le clone vm2 soit créé - OK
  4. Full clone de VM 100
    • ID : 102
    • Name : vm3
  5. Attendre que le clone vm3 soit créé - OK

Proxmox

  1. → Datacenter
  2. → Storage
  3. → Add
  4. → “NFS”
    • ID : nfs
    • Server : 10.10.207.100
    • Export : /usr/share/nfs-shared
    • Content : tout
    • Nodes : All (No restrictions)
    • Enable : coché
    • Max Backups : 1

Migration à chaud

  • vm1
    • plmasrv06 → plmasrv07 - OK
    • plmasrv07 → plmasrv08 - OK
    • plmasrv08 → plmasrv06 - OK
  • vm2
    • plmasrv06 → plmasrv07 - OK
    • plmasrv07 → plmasrv08 - OK
    • plmasrv08 → plmasrv06 - OK
  • vm3
    • plmasrv06 → plmasrv07 - OK
    • plmasrv07 → plmasrv08 - OK
    • plmasrv08 → plmasrv06 - OK

Toutes les VMs sont de retour sur plmasrv06.

High Availability

  1. Datacenter → HA → Groups → Create
    • ID : g123
    • Tout les nœuds
    • pas d'options cochées
  2. Datacenter → HA → Resources → Add
    • Ajouter chaque VM et les associer dans le groupe “g123”

Status

root@plmasrv06:~# ha-manager status
quorum OK
master plmasrv06 (active, Tue Sep 18 11:31:50 2018)
lrm plmasrv06 (active, Tue Sep 18 11:31:51 2018)
lrm plmasrv07 (active, Tue Sep 18 11:31:54 2018)
lrm plmasrv08 (idle, Tue Sep 18 11:31:56 2018)
service vm:100 (plmasrv06, started)
service vm:101 (plmasrv06, started)
service vm:102 (plmasrv06, started)

Tests

  1. Déconnexion de l'interface d'admin du nœud plmasrv06
    • L'ciône du nœud passe du vert au rouge
    • vm1 et vm3 sont redémarrées sur plmasrv06 et vm2 sur plmasrv07
    • plmasrv06 redémarre au bout de 60s
  2. Reconnexion de l'interface d'admin du nœud plmasrv06
    • plmasrv06 est de retour dans le cluster
    • les VMs restent sur plmasrv06 et plmasrv07
  3. Migration VMs vers plmasrv06 - OK
  4. Retrait des VMs du groupe HA “g123”
    1. → VM
    2. → More
    3. → Manage HA
    4. → Group : effacer “g123”
  5. Suppression des ressources HA et du groupe “g123”
    1. → Datacenter
    2. → HA
    3. → Resources
    4. → sélectionner ressources
    5. → Remove
root@plmasrv06:~# ha-manager status
quorum OK
master plmasrv07 (active, Tue Sep 18 12:00:05 2018)
lrm plmasrv06 (idle, Tue Sep 18 12:00:12 2018)
lrm plmasrv07 (active, Tue Sep 18 12:00:04 2018)
lrm plmasrv08 (active, Tue Sep 18 12:00:05 2018)
  1. Création de groupes HA
    1. g1
      • plmasrv06
      • “restricted” coché
      • “no failback” non coché
    2. g2
      • plmasrv07
      • “restricted” non coché
      • “no failback” coché
    3. g3
      • plmasrv08
      • “restricted” coché
      • “no failback” coché
  2. Création de ressources HA
    • vm1 → g1
    • vm2 → g2
    • vm3 → g3

vm3 se retrouve migrée sur plmasrv08

  1. Déconnexion de l'interface d'admin du nœud plmasrv06
    • L'icône du nœud passe du vert au rouge
    • vm2 est redémarrée sur plmasrv07
    • vm1 reste sur plmasrv06
    • plmasrv06 reboot après 60 secondes
    • vm1 n'est PAS redémarrée sur plmasrv06
  2. Reconnexion de l'interface d'admin du nœud plmasrv0i6
    • plmasrv06 est de retour dans le cluster
    • vm1 est DOWN sur plmasrv06
    • vm2 est UP sur plmasrv07
    • vm3 est UP sur plmasrv08
  3. Démarrage manuel de vm1 sur plmasrv06
Requesting HA start for VM 100
service 'vm:100' in error state, must be disabled and fixed first
TASK ERROR: command 'ha-manager set vm:100 --state started' failed: exit code 255
  1. → vm1
    1. → More
    2. → Manage HA
    3. Request State : disabled
    4. Start

L'option “restricted” restreint la VM dans un groupe. S'il n'y a pas assez de nœuds dans le groupe, le service reste stoppé. On peut utiliser ça pour, par exemple, si l'on aun dongle USB comme clé pour un logiciel (pas besoin de redémarrer la VM sur un autre n&ud sans le dongle).

  1. Déconnexion de l'interface d'admin du nœud plmasrv07
    • L'icône du nœud passe du vert au rouge
    • plmasrv07 reboot après 60 secondes
    • vm2 est redémarrée sur plmasrv06
  2. Reconnexion de l'interface d'admin du nœud plmasrv07
    • plmasrv07 est de retour dans le cluster
    • vm1 est UP sur plmasrv06
    • vm2 est UP sur plmasrv06
    • vm3 est UP sur plmasrv08

L'option “no failback” permet à une VM de redémarrer sur un nœud qui ne fait pas partie de son groupe. Mais dans ce cas, et après qu'un nœud du groupe soit bon, la VM n'est pas migrée de nouveau dans le groupe.
Utile si, par exemple, on veux migrer les VMs à la main si l'on a peur d'une seconde saturation de l'infrastructure.

  1. Migration de la vm2 sur plmasrv07 - OK
    • vm1 est UP sur plmasrv06
    • vm2 est UP sur plmasrv07
    • vm3 est UP sur plmasrv08
  1. Déconnexion de l'interface d'admin du nœud plmasrv08
    • L'icône du nœud passe du vert au rouge
    • plmasrv08 reboot après 60 secondes
    • vm3 reste sur plmasrv08
  2. Reconnexion de l'interface d'admin du nœud pmasrv08
    • plmasrv08 est de retour dans le cluster
    • vm3 est DOWN sur plmasrv08
    • vm1 est UP sur plmasrv06
    • vm2 est UP sur plmasrv07
  3. Démarrage manuel de vm3 sur plmasrv08
Requesting HA start for VM 103
service 'vm:103' in error state, must be disabled and fixed first
TASK ERROR: command 'ha-manager set vm:103 --state started' failed: exit code 255
  1. → vm3
    1. → More
    2. → Manage HA
    3. Request State : disabled
    4. Start

Je ne peux pas imaginer un cas intéressant où “restricted” et “no failback” seraient tout deux cochés.

  1. Suppression de toutes les ressources et groupes HA
  2. Création d'un groupe “g123” contenant les trois nœuds
  3. Ajouter chaque VM dans le groupe “g123”
  4. Migrer vm2 et vm3 sur plmasrv06 - OK
  5. Éteindre plmasrv06
    • L'icône de plmasrv06 passe du vert au rouge
    • vm1 et vm3 sont redémarrées sur plmasrv07
    • vm2 est redémarrée sur plmasrv08
infrastructure/proxmox-tests-cluster/proxmox_-_tests_cluster_et_high_availability.txt · Dernière modification: 2019/01/10 16:28 par rguyader