Installer un cluster hyperconvergé avec Proxmox, Ceph, Tinc, OpenVSwitch

Introduction

Dans le monde de l'informatique il existe des concepts afin de réduire le plus possible les coupures (appelées aussi downtime). Il s'agit de la redondance. Car oui, pour certaines entreprises il est indispensable de ne pas avoir la moindre coupure car c'est un gros manque à gagner.

La redondance, alias le cloud pour certains commerciaux, est un mot magique qui ne doit rien coûter. Cette croyance pousse tout le monde à utiliser des clouds publiques type AWS, Azure, Google Cloud avec comme fausse croyance que les hyperviseurs ne tombe jamais en panne. (Pro tips : si vous ne cocher pas la case « Multi AZ » sur AWS vous n'avez pas de redondance et cocher cette case multiplie la facture par, au minimum, 2).

On peut effectuer cette redondance sur plusieurs niveaux :

• Multiple AS (Autonomous System)
• Multiple localisation (Multiple datacenter)
• Double liens électrique
• Double liens internet
• Les connectiques réseaux (Switch, routeur)
• Au niveau de la baie (double liens électrique) (sorte de grosse armoire où l'on stock les serveurs)
• Le matériel du serveur (double cartes réseau, doubles alimentations, double CPU)
• Double liens vers le stockage
• Double VMs (S'il y a de la virtualisation)

Vous pouvez bien entendu ne pas tout redonder, cela dépend du niveau de criticité d'une coupure ainsi que de votre porte monnaie.

Une autre solution pour réduire les pannes à moindre coût est de mettre en place un cluster hyperconvergé. Bien entendu ce genre de solution n'est pas intégralement redondant si l'AS tombe. Cependant ça réduit drastiquement le coût de l'architecture, moyennant des coupures de 30 secondes si un des noeuds tombe en panne et que l'application derrière n'est pas redondé.

L'hyper-convergence (ou hyperconvergence) est un type d'architecture matérielle informatique qui agrège de façon étroitement liée les composants de traitement, de stockage, de réseau et de virtualisation de plusieurs serveurs physiques. (source Wikipédia (oui, j'ai copié la première ligne, mais c'était bien expliqué :p ))

Avantages et inconvénients des deux solutions

Redondance complète

Avantage

• Haute performance en fonctionnement optimal
• Temps de coupure très faible en cas de dysfonctionnement.

Inconvénient

• Solution très cher
• Obligation technique de mettre cette solution en place sur une infrastructure entièrement gérée par soi

Redondance avec un cluster « hyperconvergé »

Avantage

• Coup relativement faible
• Possibilité de mettre en place cette solution chez n'importe quel hébergeur

Inconvénient

• Une partie des ressources n'est pas utilisable (Par exemple vous avez 3 noeuds, seul 2/3 des ressources sont utilisables, le reste sert si un des trois noeuds tombe)
• Temps de downtime plus long
• Utilisation des ressources pour la gestion du stockage ainsi que le réseau

Explication des choix fait

Comme vous avez pu le voir dans le titre, l'infrastructure finale sera composée de :

• Proxmox pour les hyperviseurs
• Ceph pour la gestion du stockage répliqué
• OpenVSwitch pour le réseau
• Tinc pour génerer des liens entre les machines
• pfSense pour la HA (avec l'IP failover)

Chaque choix a été constitué après mûre réflexion et nombreux tests. Bien entendu il est possible d'utiliser des outils similaires pour effectuer cela.

Pourquoi utiliser :

• Proxmox. L'intégration avec Ceph a été déjà été mise en avant sur la version 5. Sur la version 6, Ceph est intégré à Proxmox au point de voir l'état du cluster ainsi que les IOps dans l'interface Proxmox (onglet « Summary », à côté de l'état du cluster Proxmox). Cette solution de virtualisation intègre aussi OpenVSwitch de façon remarquable.
• Ceph. Pour son intégration avec Proxmox mais aussi pour sa doc et sa facilité de prise en main, ainsi que sa robustesse et ses performances comparé à DRDB ou GlusterFS.
• OpenVSwitch. Pour son intégration à Proxmox mais aussi ses ports utilisant GRE pour communiquer entre chaque machine par une carte spécifique, pour en faire un switch commun aux trois serveurs. Il s'agit d'une implétmentation libre de VSwitch de VMWare.
• Tinc. Ce VPN permet de faire des réseaux dit « maillés » (mesh network (article wikipedia ). En gros il s'agit de l'architecture réseau la plus redondante possible. Sur un réseau de 4 machines et plus, en cas de coupure des liens, l'accès se fera par l'autre lien assurant ainsi l'accès aux données.
• pfSense. Car il s'agit d'un firewall OpenSource (je ne connaissais pas OpenSense). Sa fonctionnalité HA permettait de basculer sur un autre firewall si le noeud portant le firewall tombe.

Le gros soucis que j'ai rencontré c'est qu'avec des disques qui tournent à 7200 tours minutes, Mastodon et PostgreSQL passaient leur temps à écrire sur les disques. Cela était répliqué sur les trois disques avec Ceph et je me suis retrouvé dans la même situation qui m'a poussé à séparer PostgreSQL et Mastodon (les IO étaient tous utilisés par ces deux logiciels).

Techniques !

Prérequis :

Pour cet article nous avons besoin de :

• 3 serveurs dédiés
• 2 disques par serveur, un pour Ceph et un pour le système.
• 1 interface réseau par serveur

Bien entendu, si vous avez plusieurs interfaces réseau physique vous pouvez retirer le VPN qui est mis en place ici uniquement dans le but d'avoir un réseau privé. Si vous avez également plus de deux disques par machine, vous pouvez dédier les autres à Ceph (dans d'autre pool par exemple). Rien ne vous l'empêche ;)

Schéma de l'infrastructure

Bah oui, on ne commence jamais sans avoir d'idée clair de ce qu'on va faire ;)

Voici à quoi va ressembler l'infrastructure après ce tuto.

Installation de Proxmox

N'ayant pas la possibilité d'inserer une clé USB dans le serveur, j'ai choisi d'installer une Debian sur un disque (avec comme taille totale 128Go) puis j'ai installé Proxmox en suivant le tuto prévu pour Stretch mais en remplaçant Stretch par Buster.

echo "deb http://download.proxmox.com/debian/pve buster pve-no-subscription" > /etc/apt/sources.list.d/pve-install-repo.list
gpg --keyserver keyserver.ubuntu.com --recv-keys 7BF2812E8A6E88E0
gpg --armor --export 7BF2812E8A6E88E0 | apt-key add -
apt update && apt dist-upgrade
apt install proxmox-ve postfix open-iscsi
apt remove os-prober
reboot

Configuration de vmbr0

On fait maintenant porter l'adresse IP du serveur par vmbr0 en mode bridge

source /etc/network/interfaces.d/*

auto lo
iface lo inet loopback
iface lo inet6 loopback

iface enp2s0 inet6 static
  address 2a01:4f8:161:2269::2
  netmask 64
  gateway fe80::1

auto enp2s0
iface enp2s0 inet static
	address 5.9.38.80
	netmask 255.255.255.224
	gateway 5.9.38.65
	pointopoint 5.9.38.65
	# route 	148.251.14.32/27 via 148.251.14.33
	up route add -net 5.9.38.64 netmask 255.255.255.224 gw 5.9.38.65 dev enp2s0

auto vmbr0
iface vmbr0 inet static
	address 5.9.38.80
	netmask 255.255.255.255
 	bridge_ports none
 	bridge_stp off
 	bridge_fd 0
	up ip route add 148.251.96.193/32 dev vmbr0

Création des interfaces dummy

Afin de faire détecter les interfaces VPN par Proxmox, on va créer des bridges qui pointeront avec sur des cartes dummy.
Pour cela il faut d'abord activer le module sur Linux.

echo "options dummy numdummies=3" > /etc/modprobe.d/dummy.conf
modprobe dummy

Installation de Tinc VPN

On va maintenant s'attaquer à Tinc avec la création d'un réseau admin pour l'administration (réseau dédié à Ceph et Proxmox) et un réseau pour OpenVSwitch. Vous pouvez ne faire qu'un seul réseau, j'ai préféré faire deux réseaux juste pour séparer les flux.

Configuration du réseau admin

apt install tinc
# On crée les dossiers nécessaires
mkdir -p /etc/tinc/{admin,ovps}/hosts
# On crée les fichiers nécessaires
touch /etc/tinc/{admin,ovps}/{tinc.conf,tinc-up,tinc-down}
# On modifie ce fichier sur tous les serveurs : 
vim /etc/tinc/admin/tinc.conf

# Interface réseau à utiliser. On utilise le protocole TAP ( https://en.wikipedia.org/wiki/TUN/TAP )
Interface = tap0
# Pour activer tap (https://www.tinc-vpn.org/documentation/tinc.conf.5)
Mode=switch
Port = 655
# Pas de caractères spéciaux
Name=proxmox3
AddressFamily=ipv4
ConnectTo=proxmox1
ConnectTo=proxmox2

Name

ConnectTo

tincd -n admin -K4096
vim /etc/tinc/admin/hosts/proxmox3

-----BEGIN RSA PUBLIC KEY-----

Address = 5.9.38.80
Subnet = 10.1.0.0/24
Cipher=aes-256-cbc
Port = 655

tinc-up

#!/bin/sh 
/usr/sbin/ifconfig tincadminbr0 promisc
/usr/sbin/ifconfig $INTERFACE up promisc
/usr/sbin/brctl addif tincadminbr0 $INTERFACE
/usr/sbin/ifconfig $INTERFACE 0

tinc-down

#!/bin/sh 
ifconfig $INTERFACE down

Configuration du réseau dédié à OVPS

On va répétez les étapes du dessus en remplaçant admin par ovps, en mettant comme valeur 10.2.0.0/24 à subnet, tap1 comme valeur à interface et 656 pour le port. Si vous souhaitez allez vite, vous pouvez directement passer à l'étape suivante.

apt install tinc
touch /etc/tinc/{admin,ovps}/{tinc.conf,tinc-up,tinc-down}
# On modifie ce fichier sur tous les serveurs : 
vim /etc/tinc/ovps/tinc.conf

# Interface réseau à utiliser. On utilise le protocole TAP ( https://en.wikipedia.org/wiki/TUN/TAP )
Interface = tap1
# Pour activer tap (https://www.tinc-vpn.org/documentation/tinc.conf.5)
Mode=switch
Port = 656
# Pas de caractères spéciaux
Name=proxmox3
AddressFamily=ipv4
ConnectTo=proxmox1
ConnectTo=proxmox2

Name

ConnectTo

tincd -n ovps -K4096
vim /etc/tinc/ovps/hosts/proxmox3

-----BEGIN RSA PUBLIC KEY-----

Address = 5.9.38.80
Subnet = 10.2.0.0/24
Cipher=aes-256-cbc
Port = 656

tinc-up

#!/bin/sh 
/usr/sbin/ifconfig tincovpsbr0 promisc
/usr/sbin/ifconfig $INTERFACE up promisc
/usr/sbin/brctl addif tincovpsbr0 $INTERFACE
/usr/sbin/ifconfig $INTERFACE 0

tinc-down

#!/bin/sh 
ifconfig $INTERFACE down

Création des cartes réseaux tincovpsbr0 et tincadminbr0

Dans le fichier /etc/network/interfaces ajouter les lignes ci dessous

auto tincadminbr0
iface tincadminbr0 inet static
    address 10.1.0.1
    netmask  255.255.255.0
    broadcast  10.1.0.255
    bridge_ports dummy1
    bridge_stp off
    bridge_fd 0
    
auto tincovpsbr0
iface tincovpsbr0 inet static
    address 10.2.0.1
    netmask  255.255.255.0
    broadcast  10.2.0.255
    bridge_ports dummy2
    bridge_stp off
    bridge_fd 0

Mettez en place cette configuration sur les trois noeuds en faisant en sorte que chaque IP soit unique.

Installation et configuration de OpenVSwitch

Maintenant on va installer OpenVSwitch. L'outil est pas spécialement compliqué à mettre en place ou a configurer. Il faut cependant avoir quelques notions en réseau pour éviter les mauvaises surprises.

apt install openvswitch-switch

auto vmbr1
iface vmbr1 inet manual
        ovs_type OVSBridge
	up ovs-vsctl set Bridge ${IFACE} rstp_enable=true
        up ovs-vsctl --may-exist add-port vmbr1 gre0 -- set interface gre0 type=gre options:remote_ip='10.2.0.2'
        up ovs-vsctl --may-exist add-port vmbr1 gre1 -- set interface gre1 type=gre options:remote_ip='10.2.0.3'
        down ovs-vsctl --if-exists del-port vmbr1 gre0
        down ovs-vsctl --if-exists del-port vmbr1 gre1

L'interface s'appelle vmbr1, elle est de type OVSBridge (compatible avec Proxmox). Au lancement de cette interface on active le spanning-tree qui permet de calculer la meilleur route à prendre et ainsi couper le port du switch pour éviter les boucles réseaux. On connecte sur ce switch deux "interfaces" utilisant le protocole gre permettant ainsi la communication des switchs entre eux au travers du réseau.

Installation et configuration de Ceph

Avec Proxmox, l'installation et la configuration de Ceph se fait très très facilement.

Sur les trois noeuds :

pveceph install
pveceph init --network 10.1.0.0/24

pveceph mon create --mon-address 10.1.0.2

pveceph mon create --mon-address 10.1.0.3

pveceph createmgr
pveceph createosd /dev/sdb

Voilà, c'est fini :D
J'installe trois managers et trois moniteurs dans le cluster Ceph afin d'éviter le split brain, parce que c'est pas cool quand ça arrive.

Installation et configuration de la première VM : pfSense

Ça je vous laisse faire, si vous partez pour faire de l'hyper convergé, je pense que vous savez installer Proxmox.

Il vous faut pour cette machine :

• 20 Go d'espace disque
• 2 vCPU
• 1 Go de RAM
• 3 interfaces réseaux : WAN, LAN, CARP.

Le but de CARP sera de faire en sorte que les deux Proxmox partagent leurs configurations.

L'interface WAN portera l'IP failover.
L'interface LAN sera la gateway de tout le réseau. Elle sera branchée sur l'OpenVswitch.

Petite spécifité Hetzner

L'IP failover chez Hetzner a pour gateway l'IP réel de votre serveur et son adresse MAC.
Pour que cela fonctionne, vous devrez taper :

route add -link -net 5.9.38.64 netmask 255.255.255.255 gw 

À adapter sur chacun de vos serveurs et de vos hébergeurs.

Et voilà c'est fini

C'était pas si compliqué hein ? ;)
Bien entendu, si vous avez des questions, n'hésitez pas.

Photo de couverture : Taylor Vick