Ldfa Posté(e) le 30 décembre 2019 Posté(e) le 30 décembre 2019 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 De ce fait on voit la carte réseau et on peut la gérer sur Proxmox (pour, à l'avenir, installer pfSense)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 Et dans ce fichier on met : # 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 Comme vous l'aurez compris, la valeur de la directive Name change entre chaque serveur et donc les directives ConnectTo aussi. On génère ensuite la clé privée et la clé publique nécessaires au bon fonctionnement de Tinc tincd -n admin -K4096 vim /etc/tinc/admin/hosts/proxmox3 Au dessus de la ligne -----BEGIN RSA PUBLIC KEY----- on ajoute Address = 5.9.38.80 Subnet = 10.1.0.0/24 Cipher=aes-256-cbc Port = 655 Bien entendu l'adresse change en fonction du serveur. Après avoir installé et modifié ces fichiers sur chacun des serveurs, faites en sorte que chacun possède les trois. Éditez le fichier 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 Éditez le fichier tinc-down #!/bin/sh ifconfig $INTERFACE down Rendez ces fichiers exécutables. Pour le moment vous ne pourrez pas lancer Tinc, l'interface tincadminbr0 sera créée plus bas. 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 Et dans ce fichier on met : # 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 Comme vous l'aurez compris, la valeur de la directive Name change entre chaque serveur et donc les directives ConnectTo aussi. On génère ensuite la clé privée et la clé publique nécessaire au bon fonctionnement de Tinc tincd -n ovps -K4096 vim /etc/tinc/ovps/hosts/proxmox3 Au dessus de la ligne -----BEGIN RSA PUBLIC KEY----- on ajoute Address = 5.9.38.80 Subnet = 10.2.0.0/24 Cipher=aes-256-cbc Port = 656 Bien entendu l'adresse change en fonction du serveur. Après avoir installé et modifié ces fichiers sur chacun des serveurs, faites en sorte que chacuns possèdent ces trois fichiers. Éditez le fichier 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 Éditez le fichier tinc-down #!/bin/sh ifconfig $INTERFACE down Rendez ces fichiers exécutables. Pour le moment vous ne pourrez pas lancer tinc, l'interface tincovpsbr0 sera créée plus bas. 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 Maintenant on modifie le fichier `/etc/network/interfaces` 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 Puis sur le noeud 2 : pveceph mon create --mon-address 10.1.0.2 Sur le noeud 3 : pveceph mon create --mon-address 10.1.0.3 Puis de nouveau sur les trois noeuds : pveceph createmgr pveceph createosd /dev/sdb Voilà, c'est fini :DJ'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 Afficher l’article complet
Messages recommandés
Archivé
Ce sujet est désormais archivé et ne peut plus recevoir de nouvelles réponses.