Mon serveur proxmox fait maison: épisode 3 - Carmagnole

Carmagnole

Soyez résolus de ne servir plus et vous voilà libres

Mon serveur proxmox fait maison: épisode 3

Rédigé par propositionjoe 2 commentaires

Optimisation de la configuration de départ

Nous allons voir comment j'ai fait au mieux pour optimiser ma configuration de départ sur fond d'avarie surprise d'un disque.

Précédemment dans l’épisode 2 :

Je vous avais dit que le choix de recourir à une vm openmediavault entrainait des débits d’écriture sur les disques trop faible pour que cela me conviennent vraiment. Et cela même en donnant des disques virtuels en virtio, comme j’ai lu que cela est recommandé pour avoir de meilleurs performances.

J’ai donc chercher des solutions pour obtenir le Graal du transfert en réseau ethernet : l’affichage du 100 mo/s dans la fenêtre de transfert. Deux idées semblaient se détacher :

- Faire de mon serveur un nas de luxe sous Nasforfree, c’est à dire rebrancher mon nuc pour avoir une instance proxmox… Pas vraiment FEAF (Facture edf acceptance factor).
- Un apt install nfs-server dans proxmox… Aisé à réaliser, mais ajouter un soft à la configuration de proxmox ne me semblait pas vraiment propre (incompatibilité futur, mises à jour, bidouillage dans le cœur de proxmox…).

De plus je me suis aperçu que je ne disposais pas de solution pour sauvegarder cette vm openmediavault de manière fiable. En effet mon choix de lui donner des disques virtuels de plusieurs to était une vraie mauvais idée. Je faisais donc des rsync:

~$ rsync -a --progress --delete --ignore-errors --force /répertoire/de/départ /répertoire/de/destination

 Cela me permettait de sauvegarder le contenu de ces disques virtuels (mes films de vacances, documents pro…) sur mon pc du bureau, mais les débits là aussi ne me convenaient pas.

 

Entre temps, les choses vont se compliquer :

 

Un des disques de mon pool va décidé de s’initier à la construction de secteurs illisibles ; heureusement il a pris sa décision deux mois avant la fin de sa garantie, ce dont je lui ai été grandement reconnaissant. Chose importante pour la suite, il me faut vous parler du choix de raid que j’avais faite.

Lors de l’installation de proxmox, j’avais opté pour la création d’un seul pool, contenant l’os et l’espace de stockage (sur 4 dd de 4to), restait à choisir le type de raid :

Pour simplifier ZFS a sa propre déclinaisons de raid (que les puristes contesterons, et ils auront raison) :

Zraid1 qui correspond au raid5 (défaillance d’un disque possible sans perte de donnée et maintient de leur disponibilité, mais la reconstruction du volume lors du remplacement du dd est très trop sollicitant, le risque est donc grand de perdre un autre disque pendant cet étape. En conséquence de quoi, il est déconseillé d’y avoir recours pour des dd de plus de 1to. En conséquence de quoi ce format est considéré par beaucoup désormais comme obsolète)
Avec 4 dd de 4 to le volume disponible est ici de 10 to
 
Zraid2 qui correspond au raid6 (similaire au raid5, mais il est possible de perdre 2 dd)
Avec 4 dd de 4 to le volume disponible est ici de 7 to
 
Zraid3, cette fois vont pouvez perdre 3 dd
Avec 4 dd de 4 to le volume disponible est ici de 0 to (il faut au moins 5 dd pour vous initier à ce type de raid)

Cette courte analyse m’a conduit à choisir le zraid2, afin de ne pas risquer de tout perdre en cas de reconstruction qui finirait mal d’un Zraid1.

(Remarque importante : le raid n’est pas une solution de backup, il faut toujours avoir ses données à un autre endroit, voir à deux autres endroits, voir le bon papier de genma : Sauvegarde la règle des 3-2-1).

Sauf que dans cette configuration, si les données sont relativement en sécurité, il y a un problème. En effet puisque le boot, l’os et les données sont installés sur le même pool, si ce dernier à un problème, la machine ne fonctionne plus et les vm non plus. Ce qui veut dire interruption des services web…

Je vous déconseille donc ce choix - histoire vécu - mieux vaut créer deux pools, voir trois : un pour les données, l’autre pour l’os, un dernier (optionnel mais recommandé) pour les vm.

 

Il allait donc me falloir me remettre au boulot !
 
En effet j’étais face à deux problèmes :
- des débits faibles dans le cas d’une virtualisation pour avoir les services nas
- la défaillance prochaine d’un disque, avec en cas de fausse manip, une indisponibilité complète de mon serveur.

D’après la doc d’Oracle si le disque est fatigué mais encore fonctionnel, son remplacement est aisé. Il suffit de dire à zfs quel disque doit remplacer l’autre avec la commande :

~$ zpool replace rpool sda sdx
(commande) (action) (nom du pool) (dd défaillant) (dd de remplacement)

C’est clair et c’est bien fichu. Zfs se chargeant de toutes les étapes nécessaires. La seule chose que vous avez à faire et de taper :

~$ Zpool status -v

 

Pour suivre l’avancée du processus de reconstruction.

 

Au passage, il est possible que zfs refuse de reconnaître les disques sous cette forme (sdx), une solution est de faire :

~$ cd /dev/disk/by-id/
~$ ls -l

Et de remplacer sdx par l’id du disque.

Confiant j’ai alors contacté le service client de seagate pour remplacer mon disque; il me donne une adresse pour renvoyer le défaillant et m’informe qu’il l’attende pour m’envoyer le nouveau... Cette procédure ne sera donc pas possible pour moi. Il allait donc me falloir procéder autrement, et de manière plus complexe, surtout quand on commet des erreurs… Que je vous détaillerai très bientôt.

2 commentaires

#1  - genma a dit :

Merci pour la mise en avant de mon billet sur les sauvegardes :) Je m'y attendais pas (je commençais à voir que ça parlait de RAID, je me suis dit "et les sauvegardes". J'ai été médisant en pensée, pardon). Très bon billet technique, j'en suis pas encore là / pas à ce niveau donc j'ai appris des choses. Merci.

#2  - propositionjoe a dit :

Ton papier est intéressant, c'est normal de le partager.
À bientôt

Les commentaires sont fermés.

Fil RSS des commentaires de cet article