Démonter deux disques RAID1

Support Debian
#1

Bonjour,

Alors, j’ai un server dédié sur le quel j’ai installé Debian grace à un template d’installation « ovh ».
Je me retrouve donc avec 2 disques en RAID1 « j’aurai du prendre mon temps pour l’installation… ».

J’aimerais stopper le miroir entre ces deux disques afin de récupérer de l’espace de stockage sur le second disque.

Alors j’ai bien pensé tout réinstaller pour faire simple… mais le problème est que ce serveur fait tourner plusieurs sites web et api. Donc je vais éviter la case réinstall.

J’ai trouvé pas mal d’infos sur le web concernant le raid « je ne maitrise absolument pas le sujet »
Alors il y a pleins de tuto pour le montage, mais pour l’inverse … et je ne sais pas trop quoi chercher…

Du coup j’ai trouvé ceci pour supprimer un tableau raid:

mdadm  --stop /dev/md2
mdadm  --remove /dev/md2
mdadm --zero-superblock /dev/nvme0n1p2 /dev/nvme1n1p2

Mais que va t’il se passer :cold_face: ?
Est-ce la bonne méthode ?

Merci pour votre lecture.

#2

  • fait une sauvegarde de tes sites et des données. N’oublies pas de récupérer toutes les configurations associées à tes sites et API (apache.conf, sites-available/.conf, vhosts, ports, php.ini, my.cnf pour mariadb etc…

  • fait toi une liste des paquets à installer, avec la commande:
    dpkg --get-selections > liste_paquets.txt
    Ainsi, si tu doit réinstaller, tu pourras faire un diff entre ce qui est installé à la base et ce que du devra ajouter ensuite, et ce d’un seul coup.ensuite, mettre les fichiers de conf où il faut, puis les données, et avoir une plate-forme opérationnelle rapidement.

  • Concernant l’installation du serveur, combien de temps te faut-il? C’est un calcul préalable à faire. car si le sujet est difficile, le temps passé entre les deux peut devenir signifiant.
    dans tous les cas, l’opération comporte beaucoup de risque.

  • faire une réinstallation de sites en production implique de savoir quelle est l’utilisation du site, de savoir combien de temps cela prendrait et donc combien d’indisponibilité tu aurais.

  • Voir aussi s’il est possible de faire le boulot hors heures de services.
    de toutes façon, passer de RAID à sans RAID provoquera obligatoirement une indisponibilité. Mais celle-ci, en cas d’échec ou d’erreur, peut être plus longue que la reinstall, suivant le mode de réinstallation utilisé.

#3

Tu peux essayer de voir avec ce lien debian-facile: https://debian-facile.org/doc:install:supprimer-un-raid-logiciel

fait toi un test sur une VM installée vite fait avec un RAID pour tester.

#4

Merci pour cette réponse rapide Zargos,

Donc je commence à me dire que la réinstalle est sûrement la méthode la plus safe, et surtout ou je me sent à l’aise en cas de problème (vu qu’il ne devrait pas en avoir)… le remontage des sites est très rapide à faire « on utilise plesk » et les backups sont sur un autre server, du coup un clic et c’est bon… config, bdd, données

Pour le serveur c’est different je dirais 3 bonnes heures, mais comme j’ai documenté toutes mes actions au cas ou … je devrais gagner du temps.

la VM est aussi une très bonne idée ! (j’ai tendance à etre impatient)

merci :wink:

#5

Probablement pas ce que tu veux.

Cette commande arrête l’ensemble RAID /dev/md2. Donc son contenu n’est plus disponible. Elle ne fonctionne pas si /dev/md2 est en cours d’utilisation (système de fichiers monté, volume LVM actif…).

Cette commande est incorrecte.

  • il faut spécifier le ou les membres à retirer de l’ensemble
  • ces membres doivent auparavant avoir été déclarés « défaillants » (failed, faulty)
  • je n’ai pas vérifié mais je soupçonne qu’elle ne fonctionne pas avec un ensemble RAID inactif

Et la meilleure de toutes : cette commande efface les méta-données des superblocs RAID. Si les méta-données sont situées à la fin (format 0.9 ou 1.0) alors le contenu des partitions est utilisable tel quel sans RAID. Si les métadonnées sont situées au début (format 1.1 ou 1.2, ce dernier étant par défaut), alors le début des données est décalé et le contenu des partitions est inutilisable tel quel sans tenir compte de ce décalage.

Pour supprimer le miroir sans réinstaller, voici quelques possibilités :

Méthode n° 1 : conserver le RAID en mode dégradé

  • déclarer un des membres comme défaillant et le retirer de l’ensemble
  • effacer le superbloc RAID du membre retiré
  • si format 0.9 ou 1.0, effacer les autres méta-données du membre retiré avec wipefs pour éviter un doublon
  • réutiliser le membre retiré à sa convenance
  • avantage : évite d’arrêter l’ensemble RAID donc assure la disponibilité
  • inconvénient : le RAID reste présent (dégradé)

Méthode n° 2 : supprimer le RAID

  • si format 1.1 ou 1.2, relever l’offset des données avec mdadm --examine
  • le cas échéant, démonter tous les systèmes de fichiers et désactiver tous les volumes logiques contenus dans l’ensemble RAID
  • arrêter l’ensemble RAID
  • effacer les superblocs RAID
  • si format 1.1 ou 1.2, recréer une des partitions (celle qui va conserver les données) en décalant le début de l’offset des données relevé précédemment sans toucher à son contenu
  • si format 0.9 ou 1.0, effacer les autres méta-données de la partition à recycler
  • utiliser la partition recyclée à sa convenance
  • le cas échéant, modifier /etc/fstab pour remplacer toute référence à /dev/md2 par l’UUID du contenu
  • avantage : supprime totalement le RAID
  • inconvénient : délicat si format 1.1 ou 1.2, données inaccessibles pendant l’opération, non applicable si l’ensemble RAID est occupé par le système (racine, /var…)
#6

Merci Pascal pour cette réponse très complete !! il y a plus cas :slight_smile:

#7

Bon je suis en 1.2 et l’ensemble raid est occupé par le système ! comme ca je cumule :grimacing:

#8

C’est-à-dire ? La racine est dedans ?
Dans tous les cas tu peux laisser le RAID en mode dégradé sur une partition et réutiliser l’autre. Ce n’est pas le plus propre, mais c’est le plus simple et le moins risqué et cela ne cause aucune interruption de service.

#9

oui la racine est dedans :

NAME        FSTYPE            LABEL          UUID                                 FSAVAIL FSUSE% MOUNTPOINT
nvme0n1                                                                                          
├─nvme0n1p1 vfat              EFI_SYSPART    B791-8514                             505.6M     1% /boot/efi
├─nvme0n1p2 linux_raid_member md2            2bc80da0-27ce-f2de-aa1c-619bdbe38a9e                
│ └─md2     ext4              root           f42a25e9-01ca-491e-8c87-dd3dbc141315   34.7G    88% /
└─nvme0n1p3 swap              swap-nvme1n1p3 a3ea8f06-0824-47b1-8af9-6f556443e7a4                
[SWAP]
nvme1n1                                                                                          
├─nvme1n1p1 vfat              EFI_SYSPART    B76D-0801                                           
├─nvme1n1p2 linux_raid_member md2            2bc80da0-27ce-f2de-aa1c-619bdbe38a9e                
│ └─md2     ext4              root           f42a25e9-01ca-491e-8c87-dd3dbc141315   34.7G    88% /
├─nvme1n1p3 swap              swap-nvme0n1p3 2fc64955-ad03-4265-ab98-b7dc2b0a54fc                
[SWAP]
└─nvme1n1p4 iso9660           config-2       2021-01-15-21-31-01-00

Dans la méthode 1 je serais dans le cas ou le début des données seront décalées et le contenu des partitions est sera inutilisable et je ne sais pas comment tenir compte de ce décalage.

#10

Quadn on a de la production, il faut toujorus avoir une plateforme d’intégration/test/dev la plus proche possible de la prod; ainsi ça évite de casser la production :slight_smile:

#11

Avec la méthode n°1 on n’a pas à tenir compte du décalage des données puisque le format RAID est conservé sur un disque.

Avis personnel : ce partitionnement est médiocre. Des partitions avec le même LABEL, swap sans redondance (équivalent à du RAID linear ou au mieux du RAID 0), système et données dans le même système de fichiers…

#12

Oui, le problème c’est que je suis en train d’apprendre sur le tas car ovh nous a signalé l’arrêt d’une de leur offre infogéré et on à du migré rapidement sur un dédié … et c’est sur que c’est un métier « qui n’est pas le mien »

je pense qu’une réinstalle propre sans l’utilisation d’un template ovh va etre la meilleur solution :grimacing:

Je vais m’en monter une pour pouvoir tester des choses effectivement.

#13

Pour un serveur, je recommande LVM (ou btrfs). En plus de la flexibilité pour l’allocation de l’espace disque, cela permet entre autres de déplacer les données entre volumes physiques de façon transparente. Par exemple dans ton cas, si l’ensemble RAID avait servi de volume physique LVM pour des volumes logiques, il aurait été possible de :

  • retirer un disque de l’ensemble RAID
  • ajouter le disque retiré comme nouveau volume physique LVM dans le même groupe
  • déplacer tous les volumes logiques du groupe vers le nouveau volume physique
  • retirer l’ensemble RAID du groupe LVM
  • arrêter et supprimer l’ensemble RAID
  • ajouter le second disque comme volume physique LVM dans le même groupe
  • agrandir les volumes logiques existants ou en créer de nouveaux selon les besoins

le tout de façon transparente pour le fonctionnement.

2 J'aime
#14

Merci pour les conseils Pascal,

Je suis donc en train de monter une vm avec les caractéristique les plus proches possible possible de la machine de prod souhaitée.

j’ai donc choisi un partitionnement avec LVM , me conseils tu de séparer /home /var et /tmp sur des partitions différentes ?

Je me pose d’ailleurs beaucoup de questions sur la taille de ces partitions … mais si j’ai bien compris avec LVM rien n’est figé et plus facile à modifier ?

#15

Tout d’abord avec LVM on ne parle pas de partitions mais de volumes logiques.
/home : ça dépend s’il y aura des données dedans
/var : oui, au moins en partie pour tout ce qui peut grossir hors de contrôle (logs, caches, base de données…)
/tmp : ça dépend de l’usage, considérer aussi de le mettre en tmpfs si assez de RAM/swap.

Exact, à condition d’avoir suffisamment d’espace libre dans le groupe de volumes. On créer les volumes avec des tailles initiales suffisantes pour commencer, et on agrandit en fonction des besoins. Contrairement aux partitions, on n’est pas coincé pour agrandir un volume par le volume qui est situé juste après.

#16

Ok :ok_hand:

J’ai passé la matinée sur la doc de LMV je commence à comprendre les volumes physiques, logiques et groupes… je trouve ça d’ailleurs plutôt puissant pour une gestion d’espace scalable et simple… pleins de choses m’échappent encore … mais j’aime bien bricoler!

Dans mon cas j’ai relevé l’espace disque utilisé par les différents “dossiers” et je vais devoirs prioriser /var et stocker la partie média “image vidéo” ailleurs (actuellement dans /var …) car celle-ci est vraiment incontrôlable dans notre activité… et est à l’origine de mon problème… Mais le bon côté est que ce problème m’apprend pleins de nouvelles choses :grinning:

Donc ma solution suite à cette discussion : mettre mes deux disques en raid0, gérer l’utilisation avec LMV et par le suite ajouter 2 disque en raid1 des premiers pour la sécurité et la disponibilité ?

#17

Voilà un projet qui a le mérite d’être clair. J’ai quand même une question sur sa pertinence : pourquoi ajouter les disques pour la redondance « par la suite » et pas immédiatement ?

En attendant la réponse, je prépare quelques notes pour que ce projet puisse être mené à bien sans mauvaise surprise.

  1. Le RAID 0 n’est pas indispensable pour agréger les deux disques. LVM peut lui-même agréger plusieurs volumes physiques (disques, partitions, ensembles RAID…) dans un même groupe de volumes. Le RAID 0 a l’avantage d’augmenter le débit séquentiel, à voir si ça vaut le coup pour ton utilisation.

  2. Avec le RAID logiciel de Linux (md) on ne peut pas « ajouter deux disques en RAID 1 » comme cela. Pour pouvoir ajouter un RAID 1 à un RAID 0 sans tout recréer, je vois plusieurs solutions :

    a) Créer initialement les deux RAID 1 en mode dégradé avec un seul disque puis le RAID 0 par-dessus. Par la suite, ajouter les deux disques aux RAID 1 pour construire la redondance.

    b) Créer initialement un RAID 10 (équivalent à RAID 1+0) en mode dégradé avec deux disques. Par la suite, ajouter les deux disques au RAID 10 pour construire la redondance.

    c) Créer initialement un RAID 0 avec deux disques. Par la suite, convertir le RAID 0 en RAID10 (possible d’après la documentation de mdadm) et ajouter les deux disques pour construire la redondance.

La solution a) est un peu lourde et doit être prévue à l’avance mais marche à coup sûr. Les autres solutions doivent être testées avant d’être mises en place, il ne faut pas attendre le moment d’ajouter la redondance pour découvrir que ça ne marche pas.

  1. LVM a son propre RAID interne où ce sont les volumes logiques qui sont en RAID et non les volumes physiques. Je ne peux pas en dire grand-chose, je l’ai seulement à peine testé. Mais cela peut être une option à considérer comme alternative au RAID classique (md).

  2. Pour l’amorçage UEFI (dont je ne vois pas l’intérêt et qui complique sérieusement la redondance de l’amorçage, donc si possible utiliser l’amorçage BIOS/legacy), il ne faut pas mettre les partitions système EFI en RAID. Elles doivent être des partitions classiques en FAT pour être lisibles par le firmware UEFI.

#18

Oui c’est mieux et en plus il n’y a pas les mêmes paramètres si on veut mieux faire coté durcissement.

/var, /var/log en séparé, avec /var/log/en nossuid, noexec, nodev, les deux en data=ordered, /home en nosuid ( et peu etre nodev , je me souviens plus), data=ordered aussi.

/tmp en nosuid, nodev, et normallement noexec, mais les packages debian utilisent encore beaucoup l’execution dans le repertoire /tmp, donc de fait, il n’est pas pertinent de le mettre, mais ça devrait pourtant à mettre au demeurant sur /var/tmp par exemple).

#19

Sauf que désormais, il y a des machines qui ne boot plus en bios/legacy mais uniquement en EFI. C’est le cas de ma machine par exemple, ou d’un minipc aussi que j’ai.

#20

« data=ordered » est valable uniquement pour ext3 ou ext4, et c’est déjà la valeur par défaut.

Je ne vois pas ce que viendraient faire des fichiers spéciaux de périphériques dans /home, ni où que ce soit ailleurs que dans /dev.

J’en ai conscience, c’est pourquoi j’ai précisé « si possible ».