Différences

Ci-dessous, les différences entre deux révisions de la page.

--- public:un_serveur_de_secours [2021/09/07 07:35] – pcouderc
+++ public:un_serveur_de_secours [2022/02/21 10:56] (Version actuelle) – [btrfs] pcouderc
@@ Ligne 1: / Ligne 1: @@
-(EN COURS DE REDACTION!!!!)
 ===== Un serveur de secours =====
-Si on désire maîtriser l'informatique d'une TPE (ou même domestique indépendante), il faut se protéger de diverses défaillances, la plus critique étant celle du lien internet. En effet à moins de payer chez orange des prix conséquents, chez tout autre opérateur, une simple panne de DSLAM, ou pire un câble décroché, peut couper internet pendant plusieurs jours, ce qui n'est en général pas acceptable pour une TPE.
+Si on désire maîtriser l'informatique d'une TPE (ou même simplement une informatique domestique "indépendante"), il faut se protéger de diverses défaillances, la plus critique étant celle du lien internet. En effet à moins de payer chez orange des prix conséquents, chez tout autre opérateur, une simple panne de DSLAM, ou pire un câble rompu, peut couper internet pendant plusieurs jours, ce qui n'est en général pas acceptable pour une TPE.
 Autant le lien entrant (download) peut être recréé avec un simple smartphone, autant le lien sortant (upload) nécessite des solutions plus radicales. Celle abordée ici consiste en un "petit" serveur de secours situé dans un autre lieu, et chargé de prendre le relais en cas de défaillance du serveur principal quelle qu'en soit la raison, serveur lui-même ou lien internet.
-==== Le serveur principal ====
+===== Le serveur principal =====
 Avant de présenter le serveur de secours, il faut décrire le serveur principal.
-Celui-ci contient plusieurs foncions, serveur web, courriel, pabx... gérés dans autant de serveurs lxd.
+Celui-ci contient plusieurs fonctions, serveur web, courriel, pabx... gérés dans autant de "containers" lxd.
 === Un petit mot sur lxd ===
-lxd est un système de machines virtuelles qui permets de créer des serveurs spécialisés isolés les uns des autres. Par exemple, on veut mettre à jour un serveur www, par exemple, on sauve l'ancien serveur par une simple commande, et on commence la mise à jour. Pendant ce temps, le serveur mail continue à tourner. Et en cas de catastrophe une simple commande de quelques secondes permet de revenir à l'ancien serveur www et de réfléchir. Et le serveur mail n'a pas arrêté de fonctionner...
+lxd est un système de machines virtuelles - plus exactement de containers - qui permet de créer des serveurs spécialisés isolés les uns des autres. Par exemple, on veut mettre à jour un serveur www : on sauve l'ancien serveur par une simple commande, et on commence la mise à jour. Pendant ce temps, le serveur mail continue à tourner. Et en cas de catastrophe une simple commande de quelques secondes permet de revenir à l'ancien serveur www et de réfléchir. Et le serveur mail n'a pas arrêté de fonctionner...
 lxd est magique.
@@ Ligne 21: / Ligne 21: @@
 === Les données du serveur ===
-On a donc des machines virtuelles(vm) lxd, avec leur paramètres, associées à des données. Chaque vm (www, mail, sip,...) a donc une fonction précise, une zone de paramètres, rangée dans server:/var/sauve/etc et une zone de data souvent dans server:/srv/. Le lien est fait par lxd, qui par exemple dans la machine www va "mapper" server:/var/www sur le répertoire www:/var/www de la vm www. Des liens judicieux complètent le dispositif de sorte que tous les paramètres importants de toutes les vms soient concentrés dans server:/var/sauve/etc.
+On a donc des containers lxd dans un hôte, le serveur principal. Chaque container (www, mail, sip,...) a donc une fonction précise, une zone de paramètres, et une zone de données. Caque zone de paramètres est rangée dans l'hôte dans : /var/sauve/etc et chaque zone de données dans l'hôte dans /srv/. Le lien est fait par lxd, qui par exemple dans la machine www va "mapper" la zone /srv/www de l'hôte sur le répertoire www : /var/www du container www. Des liens judicieux complètent le dispositif de sorte que tous les paramètres importants de tous les containers soient concentrés dans l'hôte  en /var/sauve/etc.
-==== Le serveur de secours ====
+===== Le serveur de secours =====
-=== Matériel ===
+==== Matériel ====
 Le plus économique, mais aussi le plus discret et silencieux - par exemple dans un domicile privé près d'une box - , est basé sur un raspberry pi 4 tel que celui proposé par [[https://www.freva.com/fr/product/raspberry-pi-4b-avec-120-go-ssd-starter-kit/|freva]], ici dans une version sans ventilateur mais avec 8G de RAM et un SSD de 1T et avec la version [[https://www.raspberrypi.org/software/operating-systems/#raspberry-pi-os-32-bit|lite]] de Raspberry Pi OS, que freva fournit tout installé.
-=== Logiciel ===
+==== Logiciel ====
 L'architecture logiciel du serveur de secours est identique à celle du serveur principal. Il assure seulement la fonction de serveur DHCPD, et lxd. Il n'assure pas le routage, faite par la "box", mais il le pourrait...
-==== Préparation ====
+===== Préparation =====
-=== Réseau ===
+==== Réseau ====
 Pour ce type d'usage, sans utilisateur humain, avec seulement des connexions ssh en vue d'opérations de maintenance, on va travailler toujours en root, avec certificats (avec comme filet un mot de passe à rallonge pour l'utilisateur pi). Toute la suite est donc sous root.
@@ Ligne 64: / Ligne 64: @@
 ifup eth0
 </code>
-(Il peut apparaitre une "too few arguments" inexpliquée, mais semble-t-il sans conséquence).
+(Il peut apparaître un "too few arguments" inexpliqué, mais semble-t-il sans conséquence).
 La nouvelle ainsi que l'ancienne adresse IP doivent répondre au ping...
-=== btrfs ===
+==== btrfs ====
 On va utiliser le système de fichier [[https://fr.wikipedia.org/wiki/Btrfs|btrfs]] qui se coordonne très bien avec lxd. Ce n'est pas trivial sur Raspberry OS...On utilise la [[https://raspberrypi.stackexchange.com/questions/8265/btrfs-root-filesystem-on-raspbian|procédure décrite par " Piskvor left the building"]].
@@ Ligne 74: / Ligne 74: @@
 On va charger le module btrfs dans la partition boot du disque dans un initramfs :
 <code>
-apt install btrfs-tools initramfs-tools
+apt install btrfs-progs initramfs-tools
 echo 'btrfs' | sudo tee -a /etc/initramfs-tools/modules
 mkdir -p /etc/initramfs-tools/hooks
@@ Ligne 93: / Ligne 93: @@
 initramfs initrd.img-5.10.60-v7l+  followkernel
 </code>
-Le système est prêt, mais ne fonctionnera que jusqu'au prochain changement de kernel. Il faut automatiser la mise à jour avec les scripts suivants :
+Le système tel quel ne fonctionnera que jusqu'au prochain changement de kernel. Il faut automatiser la mise à jour avec les scripts et opérations suivants :
+   * {{ :public:rpi-initramfs-tools.zip |rpi-initramfs-tools}} à dézipper et à mettre dans /etc/kernel/postinst.d/ et à rendre exécutable (chmod 755).
+   * delete /etc/kernel/postinst.d/initramfs-tools
+   * décommenter INITRD=Yes dans /etc/default/raspberrypi-kernel
-Le serveur de secours est prêt. On le met à jour (apt update upgrade...). Il faut lui mettre la même adresse IP que le serveur principal - en remplaçant le 251 ci-dessus par la bonne valeur -,afin d'avoir la même structure de réseau sur le site de secours que sur le site principal. Puis on le transporte sur le site distant où on programme le router pour utiliser les mêmes adresses IPs locales  que le site principal (192.168.163.XXX).
+A ce point là on peut rebooter avant d'aller plus loin, pour vérifier qu'on n'a rien cassé...
-==== Mise en route à distance ====
+On va maintenant migrer la partition de root en btrfs. On fait cela sur un PC linux, en connectant le SSD sur une prise USB. On repère la partition par lsblk : c'est la grande, pas le boot... Chez moi, c'est /dev/sda2. Puis toujours sous root, on va sauver la partition, la formater en btrfs et la restaurer :
+<code>
+mount /dev/sda2 /media/usb
+cd /media/usb
+tar -czvf ~/rpi-rootfs-backup.tgz *
+cd ~
+umount /media/usb
+mkfs.btrfs /dev/sda2
+partprobe
+mount /dev/sda2 /media/usb
+cd /media/usb
+tar -xzvf ~/rpi-rootfs-backup.tgz
+vim etc/fstab
+</code>
+On recherche la partition en ext4 et on remplace ce type par "btrfs" avec les paramètres suivants le mot "bttrfs" comme ci-dessous comme parametre  :
+<code>
+PARTUUID=abcdef01234-02  /               btrfs    defaults  0       1
+</code>
+On peut maintenant démonter la partition, et monter la partition boot (/dev/sda1?).
+On va avoir besoin de l'UUID de la partition, on le trouve avec un blkid. Note : un UUID, pas un PARTUUID ou un UUID_SUB... Cela ressemble à UUID="cafebeef-0000-1234-aaaa-12346589". On va mettre à jour dans la partition boot à la racine le fichier cmdline.txt et on remplace les deux parametres :
+<code>
+root=PARTUUID=1234-5678 rootfstype=ext4
+</code>
+avec :
+<code>
+root=UUID=cafebeef-0000-1234-aaaa-12346589 rootfstype=btrfs
+</code>
+On démonte, on remonte le cable USB du SSD sur le Raspberry pi.
+Et on boote !
+N'est-il pas vrai que ce n'est pas trivial...
+==== Et maintenant...====
+Le serveur de secours est prêt. On le met à jour (apt update upgrade...) et on fait une première sauvegarde (voir plus loin). Il faut maintenant l'éteindre après lui mis la même adresse IP que le serveur principal - en remplaçant le 251 ci-dessus par la bonne valeur -, afin d'avoir la même structure de réseau sur le site de secours que sur le site principal. Puis on le transporte sur le site distant où on programme le routeur pour utiliser les mêmes adresses IPs locales  que le site principal (192.168.163.XXX).
+===== Mise en route à distance =====
 Une fois le serveur à destination, on peut y accéder de n’importe où par ssh. Et en particulier de son pc préféré.
-=== Sauvegarde ===
+==== Sauvegarde ====
-On va copier les données sur le serveur de secours avec un script basé sur rsync :
+On va copier les données sur le serveur de secours avec un script basé sur rsync (dans le serveur principal !):
 <code>
@@ Ligne 115: / Ligne 157: @@
 	rsync $1  -az --del -e 'ssh -p 1433' /srv/www/* sauve.couderc.eu:/srv/www
 	rsync $1  -az --del -e 'ssh -p 1433' /srv/photos/* sauve.couderc.eu:/srv/photos
+...
 	echo End Saving
 	sleep 5m
@@ Ligne 140: / Ligne 183: @@
 Note : le port 1433 est utilisé pour différencier le trafic de sauvegarde à très basse priorité sur ce port, du trafic ssh normal, il est routé sur le port 22 à l'arrivée. Un système de contrôle de QoS est indispensable pour que ce script ne sature pas le débit montant de la ligne internet. Sinon,il faut le lancer à des heures tranquilles...
-Si la sauvegarde a été décrite ici dans un ordre logique, on peut cependant faire une première sauvegarde en local pendant la phase de préparation avant de déplacer le serveur de secours sur site...
+Si la sauvegarde a été décrite ici dans un ordre logique, on peut - euh, on doit absolument - cependant faire une première sauvegarde en local pendant la phase de préparation avant de déplacer le serveur de secours sur site...
-=== Installation ===
+==== Installation ====
-Le serveur de secours est en place a des données mais aucun programme. On procède aux installations, du serveur DHCP:
+==== DHCP ====
+Le serveur de secours est en place, a des données mais aucun programme. On procède aux installations, du serveur DHCP:
 <code>
 apt update
@@ Ligne 150: / Ligne 195: @@
 apt install isc-dhcp-server
 </code>
-Les paramètres du serveur DHCP sont dans /var/sauve/etc/dhcp
+Les paramètres du serveur DHCP sont dans /var/sauve/etc/dhcp. En plus des adresses variables, le serveur DHCP est chargé d'attribuer les mêmes adresses fixes à certains systèmes et en particulier aux containers  lxd.
-On ne va pas ici gérer de serveur DHCP en IPV6 et donc on commente la ligne INTERFACEV6="" dans /etc/default/isc-dhcp-server. On remplace les paramètres par défaut du serveur DHCP par ceux de /var/sauve/etc/dhcp au moins d'un lien.
+On ne va pas ici gérer de serveur DHCP en IPV6 et donc on commente la ligne INTERFACEV6="" dans /etc/default/isc-dhcp-server. On remplace les paramètres par défaut du serveur DHCP par ceux de /var/sauve/etc/dhcp au moyen d'un lien.
+==== lxd ====
+Il nécessite snap (je HAIS snap, mais il n'y a pas d'alternative sous debian) et ses fantaisies :
+<code>
+apt install snapd
+snap install core
+snap refresh
+snap install lxd
+reboot
+lxd init
+</code>
+Note : en cas d'erreurs avec "libarmmem", arreter lxd (ctrl-c), commenter d'un # la ligne correspondante dans  /etc/ld.so.preload et relancer lxd init.
+Garder les valeurs par défaut de lxd init sauf :
+<code>
+Would you like to create a new local network bridge? (yes/no) [default=yes]: no
+Would you like to configure LXD to use an existing bridge or host interface? (yes/no) [default=no]: yes
+Name of the existing bridge or host interface: eth0
+</code>
+On va utiliser un "bridge" externe pour pouvoir accéder de l'extérieur aux différents serveurs de l'extérieur, la suite de cette procédure de préparation de lxd est décrite [[public:a_perfect_btrfs_server#prepare_the_bridge|ici ]].
+Une fois lxd installé, chacun des "mini-serveurs" (containers lxd) doit être paramétré pour être prêt à prendre le relais...
+==== La panne ====
+En cas de panne, on ne sera pas prêt...
+Si c'est possible, fermer les services au mieux, et essayer de mettre au propre la dernière sauvegarde par la procédure ci-dessus au besoin avec un lien de fortune (smartphone...).
+Puis lancer les containers sur le serveur de secours.
+Des répétitions s'imposent : par exmple, on éteint le routeur principal et on mesure en combien de temps les serveurs de secours sont en fonction...