Tous les serveurs sans exception sont configurés en RAID pour palier à un bris de disque dur. Ça nous a déjà sauvé plusieurs fois.

La grande majorité des serveurs utilisent du sofware RAID quelques-uns utilisent du hardware RAID, ils sont listés plus bas.

Pour faire la maintenance régulière d'arrays RAID, il est important de connaître certains détails et certaines commandes.

Software Raid sous linux

Afficher l'état actuel de la réplication des arrays

Pour voir l'état des arrays RAID, on peut consulter le contenu du fichier /proc/mdstat:

# cat /proc/mdstat
Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10] 
md0 : active raid1 sda2[2] sdb2[0]
      3905833984 blocks super 1.2 [2/2] [UU]
      bitmap: 2/30 pages [8KB], 65536KB chunk

unused devices: <none>

Dans l'exemple au dessus, on voit un array nommé md0 qui est actif et en mode "raid1" (donc mirroir des données sur les deux disques). Les deux partitions qui font partie de l'array sont sda2 et sdb2. sur la 2ème ligne d'information, on peut voir à la fin de la ligne que les deux disques sont présent et à jour (chaque disque, en ordre présenté sur la première ligne, a l'état U pour "Up to date").

Si un disque est manquant parce qu'il n'a pas encore été inséré dans un nouvel array en construction ou encore parce qu'il a été manuellement retiré, l'état du disque absent sera alors _.

Si un disque a manifesté des erreurs que mdadm a détectées comme étant problématiques pour la réplication, l'état du disque avec des erreurs sera F pour "Failed".

Un disque en cours de synchronisation a également l'état _ mais une ligne additionnelle est affichée pour montrer le progrès de la synchronisation et sa vitesse de copie de données. Par exemple dans l'extrait suivant la partition sda5 (dans l'état _) est en train de recevoir les données provenant de sdb5 (dans l'état U):

md1 : active raid1 sdb5[2] sda5[0]
      9767424 blocks [2/1] [U_]
      [>....................]  recovery =  1.4% (144128/9767424) finish=3.3min speed=48042K/sec

Afficher une vue d'ensemble des disques/partitions/crypto/lvm

Un outil superbe pour bien voir ce qui se passe au niveau du setup des disques en relation avec les autres niveaux d'abstraction et/ou de formattage de données est la commande suivante:

lsblk --fs

Elle permet de voir quel disque a combien de partitions de quelle taille, quelles partitions font partie d'un array RAID, et aussi s'il y a de la crypto sous ou au dessus de l'array.

Sinon, pour sortir les # de série des disques dans un format convivial:

lshw -c DISK | tr '\n' ' ' | sed -e 's/*-/\n*-/g'  |  sed 's/\*-.*logical name: \([^ ]*\) .*serial: \([^ ]*\).*/\1: \2\n/g' | sed '/^\s*$/d' | sort

Gestion des disques dans les arrays

Avec un raid1, on doit avoir au moins un "device" et en fait, on veut en pratique avoir 2 devices sinon, on n'a pas de mirroir! Mais on peut ajouter plus de device en mirroir. c'est bien pratique quand on veut changer des disques sur une machine sans aller avec 1 device (degraded raid1).

Copier les partitions de sda vers sdb

Avant d'ajouter un disque dans un array qui existe déjà, il faut s'assurer de le partitionner en conséquence. Pour faciliter les choses et éviter les catastrophes liées à la complexité inutile, on a généralement tendance à complètement copier la table de partitions pour que les deux disques soient identiques.

1. Sur les disques avec partitions GPT: ATTENTION à l'ordre des disques dans les commandes! Le disque donné à l'option -R est la destination où la table de partition sera écrasée mais doit être placé en premier dans la commande! Ici on copie la table de sda sur le nouveau disque sdb, et pour mettre ça en évidence on utilise des variables pour que la sémentique des paramètres soit la plus explicite possible:

   • ORIGINE=sda
     DESTINATION=sdb
     sgdisk "/dev/$ORIGINE" --replicate="/dev/$DESTINATION"
     # important pour générer un nouveau GUID sur le disque de destination
     sgdisk --randomize-guids "/dev/$DESTINATION"
     

     ref: source

2. (SVP ne plus utiliser de partitions de type MBR. On garde la commande ici seulement pour référence pour les vieux systèmes) Pour les disques avec une table de partition MBR: Copier la table des partitions sur le disque qu'on veut incorporer dans l'array raid.

   • sfdisk -d "/dev/$ORIGINE" | sfdisk --no-reread --force "/dev/$DESTINATION"
     

Ajouter des devices à un array

Pour ajouter une partition sdb2 dans un array md0:

mdadm /dev/md0 --add /dev/sdb2

Ajouter des devices additionnels

pour passer de 2 à 4 device

# mdadm /dev/md0 -G -n 4

On se retrouve avec ça quand on fait cat /proc/mdadm

...
[UUUU]

Retirer des devices d'un array

Pour retirer une partition sdb2 d'un array md0, il faut en premier marquer la partition comme étant en échec pour stopper la réplication et ensuite on peut la retirer de l'array:

mdadm /dev/md0 --fail /dev/sdb2  # on peut raccourcir l'option à -f
mdadm /dev/md0 --remove /dev/sdb2  # on peut raccourcir l'option à -r

Retirer les devices additionnels d'une array

On peut passer à de 4 à 2:

# mdadm /dev/md0 -G -n 2

Construire un nouvel array

1. Partitioner le premier disque en respectant notre politique qui limite la taill au ratio 930GB/1To (voir DiskMaintenance). Utiliser gdisk (ou autre si tu veux) et configurer le format de la partition comme "linux raid autodetect" (fd00)

2. Copier la table de partition vers le deuxième disque. Suivre la procédure plus haut

3. Créer le nouvel array raid à partir des 2 partitions.

    # mdadm --create --verbose /dev/md3 --level=1 --raid-devices=2  /dev/sdc1 /dev/sdd1

   Si vous avez seulement un disque, on peut créer l'array en mode degraded. Le deuxième disque sera ajouté plus tard...

    # mdadm --create --verbose /dev/md3 --level=mirror --raid-devices=2 /dev/sdc1 missing

4. S'il y a un système de fichier et pas de crypto, formater le nouvel array.

    # mkfs.ext4 /dev/md3 

5. rafraîchir /etc/mdadm/mdam.conf et s'assurer que tout est en place (git rapporte rien de perdu, et md3 est bien là)

    # /usr/share/mdadm/mkconf > /etc/mdadm/mdadm.conf

6. Si on va avoir un point de montage direct sur md3, ajouter le point de montage dans le fichier /etc/fstab avec le bon UUID

    # blkid | grep md3
    /dev/md3: UUID="fcecd711-924d-4193-8533-3f7b3ae8bcc7" TYPE="ext4" 

   Voici des exemples d'ajout au fichier /etc/fstab

    UUID=fcecd711-924d-4193-8533-3f7b3ae8bcc7      /home   ext4    defaults        0       2

    UUID=9bce2c08-44fb-4483-a698-6d9dd556710b      /boot   ext4    defaults        0       2

7. C'est pas une mauvaise idée de faire un redémarrage du serveur pour être sur que l'array et le nouveau point de montage sont actifs au démarrage.

Arrêter/suspendre un resync d'array

Desfois, le premier sync de l'array prend trop de jus de la machine! Comment peut-on le suspendre? oui.

# echo 0 > /proc/sys/dev/raid/speed_limit_max

complètement supprimer un array

Des fois, il y a des arrays qui se réactivent sur les vieux disques qu'on déplace de serveur. C'est pratique de completement supprimer un array sinon, ca peut dire que le device est utilisé quand on veut faire des partitions dessus ou bien envoyer des mails comme s'il y avait un array en mode "degraded" même si on n'est pas intéressés à cet array là.

# mdadm --stop /dev/mdX
# mdadm --zero-superblock /dev/sdX

On veut faire --zero-superblock sur chacun des disques qu'on veut effacer l'array.

Reconstruire un RAID

Il est utile de reconstruire un array RAID pour plusieurs raisons:

• copier un disque
• remplacer un disque brisé
• suite à un cold reboot l'array est brisé.

Disque manquant: intégrer un nouveau disque

Quand un disque brise, il faut le remplacer le plus vite possible! Une fois le nouveau disque dans l'ordinateur, on doit l'ajouter à l'array pour le "reconstruire" (donc copier les données sur le nouveau disque et ensuite le maintenir à jour). Au début de cette procédure on se trouve dans l'état suivant:

# cat /proc/mdstat
Personalities : [raid0] [raid1] [raid5] 
md2 : active raid1 sda6[0]
      183630848 blocks [2/1] [U_]
      
md1 : active raid1 sda5[0]
      9767424 blocks [2/1] [U_]

md0 : active raid1 sda2[0]
      489856 blocks [2/1] [U_]

1. Copier la table de partition. Suivre la procédure plus haut

2. Reconstruire l'array
   • Il faut par la suite dire a mdadm que les nouvelles partitions sont en ligne pour reconstruire l'array. Pour ça, on veut ajouter les partitions dans l'array raid:

     # mdadm --add /dev/md0 /dev/sdb2
     # mdadm --add /dev/md1 /dev/sdb5
     # mdadm --add /dev/md2 /dev/sdb6
     # cat /proc/mdstat
     Personalities : [raid0] [raid1] [raid5] 
     md2 : active raid1 sda6[0]
           183630848 blocks [2/1] [U_]
           
     md1 : active raid1 sdb5[2] sda5[0]
           9767424 blocks [2/1] [U_]
           [>....................]  recovery =  1.4% (144128/9767424) finish=3.3min speed=48042K/sec
     md0 : active raid1 sdb2[1] sda2[0]
           489856 blocks [2/2] [UU]

3. Ne pas oublier d'installer grub sur le nouveau disque dans l'array, sinon le disque ne bootera pas encas de perte du premier disque!

   • Suivre les commandes sur GrubConfiguration. En cas d'erreur, se référer à cette page là aussi!

Changer un disque dans un raid qui fonctionne déjà

Vérifications avant de commencer

Un disque de plus de 2TB va avoir besoin d'une partition de type GPT. Si on remplace un disque de moins de 2TB par un disque de plus de 2TB, il est possible qu'il faille changer le type de partition de MBR à GPT. On peut voir le type de partition avec gdisk -l /dev/sdX où X est le disque à remplacer.

Notez que si le remplacement implique le Raid utilisé pour le démarrage, le passage de MBR à GPT doit inclure l'ajout d'une mini-partition dans les premiers 2TB pour Grub : https://wiki.koumbit.net/GrubConfiguration#Grub_et_GPT Voir 45402 à partir de la note 45 pour plusse de détails.

Procédure de remplacement d'un dique

1. On a 3 disques dans une machine (2 nouveaux et 1 vieux). On a un array fonctionnel sur un nouveau disque et on veut remplacer le vieux disque par le nouveau.

   • ceres:~# cat /proc/mdstat 
     Personalities : [raid1] 
     md1 : active raid1 sdb1[0] sda1[1]
           995904 blocks [2/2] [UU]
           
     md0 : active raid1 sdb2[0] sda2[1]
           487379904 blocks [2/2] [UU]

2. On doit sortir le vieux disque de l'array qui fonctionne. On doit mettre les arrays des partitions comme failed

   • ceres:~# mdadm /dev/md0 -f /dev/sdb2
     mdadm: set /dev/sdb2 faulty in /dev/md0
     ceres:~# mdadm /dev/md1 -f /dev/sdb1
     mdadm: set /dev/sdb1 faulty in /dev/md1
     ceres:~# cat /proc/mdstat 
     Personalities : [raid1] 
     md1 : active raid1 sdb1[2](F) sda1[1]
           995904 blocks [2/1] [_U]
           
     md0 : active raid1 sdb2[2](F) sda2[1]
           487379904 blocks [2/1] [_U]

3. On veut maintenant retirer complètement les partitions des arrays.

   • ceres:~# mdadm /dev/md1 -r /dev/sdb1
     mdadm: hot removed /dev/sdb1 from /dev/md1
     ceres:~# mdadm /dev/md0 -r /dev/sdb2
     mdadm: hot removed /dev/sdb2 from /dev/md0
     ceres:~# cat /proc/mdstat 
     Personalities : [raid1] 
     md1 : active raid1 sda1[1]
           995904 blocks [2/1] [_U]
           
     md0 : active raid1 sda2[1]
           487379904 blocks [2/1] [_U]

     • Pour hotswapper un disque, voir HotSwap.

4. On veut maintenant créer la table de partition sur le nouveau disque (sdc), on fait ça à partir du disque sda

   • Si la table de partition est en format GPT, il faut utiliser sgdisk voir dans cette page la commande

   • Voir ici: RaidMaintenance#Copier_les_partitions_de_sda_vers_sdb

     Anciennement, on faisait ceci: ceres:~# sfdisk -d /dev/sda | sfdisk --no-reread /dev/sdc --force

5. On va maintenant ajouter les partitions du nouveau disque sdc dans les arrays.

   • ceres:~# mdadm /dev/md0 -a /dev/sdc2
     mdadm: added /dev/sdc2
     ceres:~# mdadm /dev/md1 -a /dev/sdc1
     mdadm: added /dev/sdc1
     ceres:~# cat /proc/mdstat 
     Personalities : [raid1] 
     md1 : active raid1 sdc1[0] sda1[1]
           995904 blocks [2/2] [UU]
           
     md0 : active raid1 sdc2[2] sda2[1]
           487379904 blocks [2/1] [_U]
           [>....................]  recovery =  0.0% (338560/487379904) finish=119.8min speed=67712K/sec

Système qui boot avec un disque manquant mais qui n'était pas marqué comme "fautif"

Quand un ordi boot avec un disque en moins alors que le disque n'avait pas été retiré de l'array (soit manuellement, soit parce qu'il s'était fait éjecter à cause d'un trouble matériel), on va avoir un message pendant le boot comme quoi le système attend après un device pour l'array et après un bout de temps ça va nous relâcher dans un shell (initramfs):

Loading Linux 4.19.0-17-amd64 ...Loading Linux 4.19.0-17-amd64 ...

Loading initial ramdisk ...Loading initial ramdisk ...

  Volume group "data" not found
  Cannot process volume group data
  Volume group "data" not found
  Cannot process volume group data
cryptsetup: Waiting for encrypted source device UUID=e8ae13a6-3593-478a-84de-ef0fa30f7295...
        ALERT! encrypted source device UUID=e8ae13a6-3593-478a-84de-ef0fa30f7295 does not exist, can't unlock md1_crypt.
        Check cryptopts=source= bootarg: cat /proc/cmdline
        or missing modules, devices: cat /proc/modules; ls /dev
Dropping to a shell.

(initramfs) 

Cette situation là arrive parce que selon les metadata de l'array, les deux disques seraient supposés être fonctionnels et comme un est manquant, ça évite de démarrer pour qu'on ne soit pas en situation où les données changent sur un seul des disques.

Donc:

1. Soit il y a bien effectivement un disque manquant -- p-e par erreur de manipulation -- et il faut s'assurer de le brancher dans le système
2. Soit on veut vraiment démarrer avec un seul disque et remplacer celui qui manque par un autre dans l'array.

Si vous êtes dans le 2ème cas, vous pouvez donc procéder en assemblant le ou les array(s) où il manque un disque mais en utilisant seulement un disque:

(initramfs) mdadm --assemble --run /dev/md1 /dev/sdc2
mdadm: /dev/md1 has been started with 1 drive (out of 2).

Une fois que tous les arrays nécessaires sont assemblés sur une seule patte (un seul disque), vous pouvez alors quitter le shell initramfs en appuyant sur CTRL-D pour que le boot normal continue.

Une fois que le boot est terminé, assurez-vous d'ajouter un disque aux arrays le plus vite possible pour ne pas risquer de complètement perdre les données!

Et comme pour tous les autres scénarios de remplacement de disque:

Ajout d'une mini-partition pour Grub

Bon, vous avez remplacé des disques, vous avez passé le type de partition de MBR à GPT, mais vous avez oublié de laisser une mini-partition pour Grub ? Oups ! Mais on peut réparer le problème : 45402 à partir de la note 45. En bref :

• 1. Vérification qu'il y a un backup du /boot qui a été fait le matin.

• 2. umount /boot

• 3. il faut mettre la mini-partition dans les premiers 2T, donc c'est une bonne idée d'aller voir l'état actuel des partitions avec gdisk -l /dev/sda où 'a' est le disque à vérifier

• 4. si possible choisir un Raid qui n'a pas de crypto, pas de lvm, donc qui a moins de couches à gérer (dans notre cas md0). Pour diminuer la taille de la partition on va du haut vers le bas : filesystem -> ... -> partition -> ... -> disque

• 5. e2fsck -fy /dev/md0 : ext2/ext3/ext4 filesystem check, direct sur le raid parce qu'il n'y a pas de LVM ici. Nécessaire parce que certaines commandes ne fonctionneront pas sans ça.

• 6. resize2fs /dev/md0 600M parce qu'on veut se laisser une marge de manoeuvre. Originellement, le raid faisait 1007M. Il faut s'assurer que 600M c'est assez pour ce qui est déjà dans le /boot. Dans notre cas ça, le /boot possède ~140M de contenu.

• 7. mdadm --grow /dev/md0 --size=1044480 contre-intuitif mais le --grow peut servir pour la réduction. La taille originale était "--size=1047552" (size en kilobytes) donc on réduit de 3072k (donc 3M). On a besoin de 1Mo, mais on se laisse une marge importante parce que certaines commandes utilisent des kilobytes et d'autres des kibibytes et que sinon ça ne fitte pas. 2048k n'était pas assez grand, par exemple.

• 8. resize2fs /dev/md0 et mount -a pour qu'il prenne tout l'espace disponible, et remonter le /boot. Un df -h montre que la partition est passée de 1007M à 1005M, donc ça fonctionne.

• 9. mettre un downtime dans icinga sur le RAID des disques

• 10. mdadm -f /dev/md0 /dev/sda1 et mdadm -r /dev/md0 /dev/sda1 et donc l'autre disque en pair se retrouve seul.

• 11. refaire les partitions avec gdisk /dev/sda :

état des partitions au début :

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048         2099199   1024.0 MiB  FD00  Linux RAID
   2         2099200        33556479   15.0 GiB    FD00  Linux RAID
   3        33556480      8001573518   3.7 TiB     FD00  Linux RAID

Et les commandes :

• d : pour effacer une partition
• 1 : pour effacer la partition sda1
• n : pour créer une nouvelle partition
• 2048 : valeur par défaut est correcte
• 1046528K : pour lui donner la taille désirée en Ko (on rajoute 1024 pour se laisse une marge)
• n : pour créer encore une autre partition
• 2095104 : valeur par défaut correcte
• 2099199 : valeur par défaut correcte
• va demander ensuite le code de type de partition, on met : EF02 - BIOS boot partition
• w : pour écrire les partition

• 12. partprobe

• 13. madadm -a /dev/md0 /dev/sda1

Et on obtient à la fin la situation suivante :

root@server:~# gdisk -l /dev/sda
...
...
Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048         2093056   1021.0 MiB  FD00  Linux RAID
   2         2099200        33556479   15.0 GiB    FD00  Linux RAID
   3        33556480      8001573518   3.7 TiB     FD00  Linux RAID
   4         2095104         2099199   2.0 MiB     EF02  BIOS boot partition

Si ça donne une erreur "mdadm: /dev/sda1 not large enough to join array" c'est que la partition créée est trop petite. Il faut revoir les étapes précédentes.

• 14. grub-install /dev/sda et grub-install /dev/sdc en supposant que sda est en paire avec sdc

• 15. dpkg-reconfigure grub-pc

Gestion de la taille des partitions RAID

Grossir un array RAID-1

L'idée ici est de grossir un array existant sans avoir à ajouter un deuxième array de trop. Le principe est qu'on resize les tables de partitions hors de l'array, puis on les rajoute et on grossis l'array et le PV.

Cette technique est similaire que la section suivante, qui consiste à créer un nouvel array et l'ajouter dans le VG (???), mais implique de débarquer les disques un à un de l'array, donc est plus risquée, mais donne des résultats plus cleans.

1. sortir la partition de l'array:

   • mdadm /dev/md2 -f /dev/sdb6
     mdadm /dev/md2 -r /dev/sdb6

2. grossir la partition:

   • # parted /dev/sdb
     GNU Parted 2.3
     Using /dev/sdb
     Welcome to GNU Parted! Type 'help' to view a list of commands.
     (parted) unit b
     (parted) print
     Model: ATA Samsung SSD 850 (scsi)
     Disk /dev/sdb: 1024209543168B
     Sector size (logical/physical): 512B/512B
     Partition Table: msdos
     
     Number  Start        End             Size            Type      File system  Flags
      1      32256B       5000970239B     5000937984B     primary                boot, raid
      2      5000970240B  1024209543167B  1019208572928B  extended
      5      5001002496B  6999713279B     1998710784B     logical                raid
      6      6999745536B  512105932799B   505106187264B   logical                raid
     (parted) rm 6
     (parted) mkpart logical 6999745536B 1024209543167B

   • Le dernier chiffre est la taille totale du disque moins un.
3. réajouter les partitions dans l'array et attendre qu'il soit reconstruit:

   • mdadm /dev/md2 -a /dev/sdb6
     mdadm --wait /dev/md2

4. refaire les étapes 1-3 pour le disque /dev/sda

5. avertir l'OS que les partitions ont changées avec la commande :

   • partprobe

6. grossir l'array RAID:

   • mdadm --grow /dev/md2 --bitmap none
     mdadm --grow /dev/md2 --size=max
     mdadm --wait /dev/md2
     mdadm --grow /dev/md2 --bitmap internal

     Noter comment on désactive puis réactive les bitmaps pour éviter un crash. Voir cette documentation pour les détails.

7. Agrandir le device de crypto:

   • cryptsetup resize /dev/mapper/md2_crypt

     Si on n'a pas de crypto sur le device, on doit sauter par dessus cette étape et agrandir le PV comme à la prochaine étape mais direct sur le device /dev/md2 à la place.

8. grossir le LVM:

   • pvresize /dev/mapper/md2_crypt

Source: https://raid.wiki.kernel.org/index.php/Growing

Exemple: 45164

Réduire un array RAID

Pour réduire un array RAID, il faut tout d'abord réduire tout ce qui se trouve dessus en ordre d'abstraction "du plus proche des données jusqu'au plus proche du disque" (par exemple commencer par réduire les filesystems s'il le faut, ensuite réduire la taille du volume LVM, réduire le volume de crypto s'il y en a, et finalement réduire la taille de l'array).

Pour notre exemple, on réduit un volume LVM sur lequel il y a encore assez de place de libre pour ne pas avoir à toucher aux filesystems. Il n'y a également pas de crypto sous les LVM dans cet exemple:

root@ganymede:/srv# pvresize --setphysicalvolumesize 493141184K /dev/md2
  Physical volume "/dev/md2" changed
  1 physical volume(s) resized / 0 physical volume(s) not resized
root@ganymede:/srv# mdadm --grow /dev/md2 --size=493141184
mdadm: component size of /dev/md2 has been set to 493141184K

réf: https://www.howtoforge.com/how-to-resize-raid-partitions-shrink-and-grow-software-raid

Exemple: 42980

Un des disques est trop petit pour l'array, comment on trouve la taille à laquelle réduire?

Pour trouver la taille qu'on peut utiliser pour un array avec un des deux disques qui est trop petit, on peut essayer de créer l'array raid pour savoir la bonne taille. ici la taille complete de sda3 etait trop petite! bien faire attention de ne pas créer l'array pour de vrai! on veut seulement obtenir l'information de taille pour pouvoir suivre les étapes dans la section précédente.

root@ganymede:/srv# mdadm --create --verbose /dev/md3 --level=1 --raid-devices=2  /dev/sda3 /dev/sdb3
mdadm: /dev/sda3 appears to be part of a raid array:
    level=raid1 devices=2 ctime=Thu Dec 18 14:59:49 2014
mdadm: partition table exists on /dev/sda3 but will be lost or
       meaningless after creating array
mdadm: Note: this array has metadata at the start and
    may not be suitable as a boot device.  If you plan to
    store '/boot' on this device please ensure that
    your boot-loader understands md/v1.x metadata, or use
    --metadata=0.90
mdadm: /dev/sdb3 appears to be part of a raid array:
    level=raid1 devices=2 ctime=Thu Dec 18 14:59:49 2014
mdadm: partition table exists on /dev/sdb3 but will be lost or
       meaningless after creating array
mdadm: size set to 493141184K
Continue creating array? ^C

Renommer un array

Si on veut donner un autre nom à un array, par exemple de "visite51:1" à "md7" on peut utiliser la séquence de commandes suivante:

mdadm --stop /dev/md/visite51\:1
mdadm --assemble /dev/md7 /dev/sd[ik]3 --update=name

À quoi sert le "write-intent bitmap"

C'est un mécanisme qui sert à éviter de resynchroniser un disque complet en cas de panne d'un disque :

12:26 < taggart> the bitmap is a "write intent bitmap" which is just a map of the array where before writing to an area of 
                 the array it flips the bit for that area, does the write, and then once complete unsets it
12:27 < tracteur> taggart: it affects sync performance i think? I mean without bitmap sync is slower?
12:27 < taggart> so if you have a power failure when it brings back up the array it scans the bitmap and only has to do the 
                 expensive recovery for the areas that were being written to at the time
12:28 < tracteur> ah ! neat
12:28 < taggart> so while a resync is in process the bitmap is getting used a lot, so it locks you out of making any changes 
                 to it
12:29 < taggart> it used to be you couldn't grow the device at all with a bitmap active, you always had to remove it
12:29 < taggart> but I think the code has improved and it's able to handle it in normal cases, but not while a resync is 
                 happening
12:30 < taggart> so this feature vastly speeds up recovery, but as you mention there are potential performance implications 
                 in the HDD space
12:31 < taggart> because if the bitmap is on the same device it's keeping track of, the HDD drive head will need to seek 
                 between the bitmap and the data for _every_ write
12:32 < taggart> that's why external bitmaps exist, you put the bitmap for the HDD on an SSD somewhere

Donc :

* Pour un SSD on peut utiliser un bitmap internal. * Pour un HDD il *faut* utiliser un bitmap external.

Eviter les resync mensuels via un "write-intent" bitmap

Lorsqu'un array RAID n'a pas de bitmap, une resynchronisation totale des données est ammorcée à chaque premier dimanche du mois, ce qui provoque un état des arrays qui est vu comme un problème (généralement un état de "warning") par le monitoring.

Le concept du "write-intent bitmap" à la base est simple mais pour pouvoir en faire la gestion (ou plutôt, décider de la grosseur du "chunk size"), il faut comprendre qu'est-ce qu'il fait exactement.

Grosso-modo, le disque va être divisés en secteurs (chunks) d'une certaine grosseur. Un bitmap est alloué sur disque (peut être "interne" -- donc sur le même disque -- ou "externe" -- donc dans un fichier sur un autre disque) où chaque bit correspond à un chunk du disque.

A chaque fois qu'on écrit à l'intérieur d'un chunk, mdadm va setter le bit correspondant au chunk dans le bitarray à 1, écrire sur disque, attendre un peu, puis s'il n'y a plus d'activité d'écriture dans le chunk, setter le bit à 0. Donc si les chunks sont plus gros, on va écrire moins souvent dans le bitarray.

Si un crash se produit, mdadm va demander un resync pour tous les chunks qui ont un 1 dans leur bit dans le bitmap. Donc plus les chunks sont gros, plus on va devoir resync de données en cas de crash.

Pour activer, une seule commande. Par exemple pour un disque de 3Tb:

mdadm --grow --bitmap=internal --bitmap-chunk=1G /dev/md1

On peut vérifier que c'est bien activé selon la présence de la ligne "bitmap" dans mdstat:

cat /proc/mdstat
Personalities : [raid1] 
md1 : active raid1 sda3[0] sdb3[2]
      2929060672 blocks super 1.2 [2/2] [UU]
      bitmap: 1/2 pages [4KB], 1048576KB chunk

md0 : active raid1 sda2[0] sdb2[2]
      976320 blocks super 1.2 [2/2] [UU]
      
unused devices: <none>

Si jamais on veut désactiver le bitmap:

mdadm --grow --bitmap=none /dev/mdX

Pour plus d'info:

• http://www.gentoo-wiki.info/HOWTO_Install_on_Software_RAID#To_turn_on_write-intent_bitmapping

démarrer un resync pour un array qui ne contient encore pas de données

Quand on construit un nouvel array et qu'il ne contient aucune données, le resync ne démarre pas automatiquement et on peut voir l'état "PENDING" sur l'array:

root@ganymede:~# cat /proc/mdstat 
Personalities : [raid1] 
md3 : active (auto-read-only) raid1 sdc1[0] sdb1[1]
      499975360 blocks super 1.2 [2/2] [UU]
        resync=PENDING
      
md2 : active raid1 sdd3[2] sda3[3]
      493141184 blocks super 1.2 [2/2] [UU]
      
md1 : active raid1 sdd2[3] sda2[2]
      1950656 blocks super 1.2 [2/2] [UU]
      
md0 : active raid1 sdd1[3] sda1[2]
      4877248 blocks super 1.2 [2/2] [UU]
      
unused devices: <none>

Certaines fois on veut démarrer un resync avant d'introduire des données dans l'array pour qu'il n'y ait pas un gros ralentissement quand on a besoin de l'utiliser. Pour faire ça, on peut utiliser la commande suivante:

mdadm --readwrite /dev/md3

référence: https://unix.stackexchange.com/questions/101072/new-md-array-is-auto-read-only-and-has-resync-pending

Générer mdadm.conf

Le fichier /etc/mdadm/mdadm.conf est utilisé pour rebâtir les arrays automatiquement au boot et on peut également s'en servir pour reconstruire reconstruire des arrays lors de crashes.

Le fichier de configuration est généré avec la commande suivante pendant que les arrays sont actifs sur la machine:

# /usr/share/mdadm/mkconf > mdadm.conf 

Cas d'usage mixtes/complexes

Voilà quelques exemples de comment combiner les commandes documentées plus haut pour obtenir certains objectifs complexes. Dans certains cas, on combine aussi des commandes de LvmMaintenance et des commandes pour le setup de crypto, qui sont en en dehors de la portée de cette page wiki.

Remplacement complet des disques et ajout d'un array

On a utilisé cette procédure, pour passer certains serveurs dom0 installés sur des disques SATA vers des disques SSD. On ne pouvait pas simplement remplacer les disques SATA par des SSD parce que les tailles des disques n'étaient pas équivalentes.

Dans le cas où on remplace complètement les disques par du SSD (on ne veut plus de SATA après dans la machine), cette procédure nous occasionne 3 courts downtimes. Dans le cas où les SATA restent dans le serveur, ca nous occasionne 2 courts downtimes.

Voilà, on a une machine avec 2 disques SATA en raid1 et on veut avoir au finale 2 disques SATA en raid1 avec seulement les données et 2 disques SSD en raid1 avec le dom0.

En fait, on veut migrer l'array /dev/md0 des SATA vers les SSD

Au préalable, on veut avoir le bios configurer avec l'option AHCImode, ça assure en autre que les noms de devices sont dans le bon ordre.

Aussi, on doit s'assurer que les disques SSD ont absolument rien dessus, pas d'ancien système, de table de partition. Sinon, ça peut compliquer les manœuvres.

1. installation matériel
   • On veut mettre le branchement suivante sur les 6 ports SATA disponible :
     • port0 un disque ssd
     • port1 un disque ssd
     • port2 le disque SATA (raid1 avec le suivant)
     • port3 le disque SATA
   • On s'assure que la machine redémarre bien sur le disque SATA et que les arrays raid sont bien monté.
2. création de la table de partition
   • Créer une partition avec fdisk sur /dev/sda (ssd) de la même grandeur que la partition /dev/sdc1 (SATA avec présentement md0). Utiliser le type "fd" linux autoraid.
   • En profiter pour créer aussi, une deuxième partition en utilisant le reste de l'espace disponible sur le disque "/dev/sda"
   • Copier la table de partition de sda (SSD) vers sdb (SSD)

     sfdisk -d /dev/sda | sfdisk --no-reread /dev/sdb --force

3. première modification des arrays
   • On veut sortir un disque SATA /dev/sdd de l'array /dev/md0

     # mdadm /dev/md0 -f /dev/sdd1
     mdadm: set /dev/sdd1 faulty in /dev/md0
     # mdadm /dev/md0 -r /dev/sdd1
     mdadm: hot removed /dev/sdd1 from /dev/md0

4. On veut maintenant y ajouter la parition /dev/sda1

   • # mdadm /dev/md0 -a /dev/sda1

5. Vérifier l'état du sync avec la commande

   • # cat /proc/mdstat 
     Personalities : [raid1] 
     md1 : active raid1 sdb2[0] sdd2[1]
           966994808 blocks super 1.2 [2/2] [UU]
           
     md0 : active raid1 sda1[2] sdb1[0]
           9763768 blocks super 1.2 [2/1] [U_]
           [>....................]  recovery =  3.2% (317440/9763768) finish=2.4min speed=63488K/sec

6. installation de grub sur sda (ssd)

   • # grub-install /dev/sda --recheck

7. redémarrer sur sda (SSD)
   • Une fois que l'array est bien syncronisé, on peut redémarrer la machine.
   • Prendre soins de passer par le bios pour vérifier l'ordre des disques pour assurer que ça démarre bien.
   • Vérifier l'état des arrays suite au reboot. Vous allez avoir /dev/md0 sur sda1 et sdc1 normalement.
8. deuxième modification des arrays
   • On veut maintenant sortir sdc1 (sata) de md0 et y ajouter sdb1 (SSD)

     # mdadm /dev/md0 -f /dev/sdc1
     mdadm: set /dev/sdc1 faulty in /dev/md0
     # mdadm /dev/md0 -r /dev/sdc1
     mdadm: hot removed /dev/sdc1 from /dev/md0

9. On veut maintenant y ajouter la parition /dev/sdb1

   • # mdadm /dev/md0 -a /dev/sdb1

10. installation de grub sur sdb (ssd)

    • # grub-install /dev/sdb --recheck

11. ajout d'un nouvel array (md2)
    • Maintenant qu'on a md0 sur les ssd, md1 sur les SATA et qu'on a sda2 et sdb2 de disponible, on veut contruire un array sur ceux-ci.

      # mdadm --create --verbose /dev/md2 --level=1 --raid-devices=2  /dev/sda2 /dev/sdb2

    • rafraîchir le fichier de configuration de mdadm et s'assurer que rien n'a disparu (avec git)

      # /usr/share/mdadm/mkconf > /etc/mdadm/mdadm.conf

    • On en profite pour initialiser lvm sur l'array

      # pvcreate /dev/md2

    • Avant de redémarrer, on veut configurer le package grub pour qu'il sache où s'installer (e.g. sur les deux disques SSD):

      # dpkg-reconfigure grub-pc
      ## dans les prompts, ne rien changer sauf pour la sélection des disques: choisir sda et sdb seulement
      # update-grub

12. redémarrer sur sda (SSD)
13. Une fois que l'array est bien synchronisé, on peut redémarrer la machine.
14. Prendre soin de passer par le bios pour vérifier l'ordre des disques pour assurer que ça démarre bien.

Vérifier l'état des arrays suite au reboot. Vous allez avoir /dev/md0 sur sda1 et sdb1 normalement et /dev/md2 va aussi être présent.

Une fois rebooté sur les deux SSD si on a besoin de tranférer les partitions de VM aussi, on peut suivre la procédure de déplacement via LVM telle que documentée dans LvmMaintenance

Si on veut sortir les SATA complètement, on peut transférer les données avec la procédure LVM plus haut avant le dernier reboot, durant lequel on peut en profiter pour sortir les disques SATA.

Un serveur qui boot sur un disque pas de RAID doit maintenant booter à partir d'un array RAID

Dans cette mise en situation là, on a une machine qui a été installée directement sur un seul disque sans RAID alors qu'on avait deux disques identiques dans la machine (et évidemment le deuxième disque n'a pas été utilisé du tout). On voudrait changer le setup pour avoir du RAID sur la machine mais conserver l'installation et les données qui sont déjà là.

Pour l'exemple, on n'a qu'une seule partition sda2 qui va devenir un array RAID md0, mais s'il y en a plusieurs, on peut répéter la première et la deuxième étape pour chaque array nécessaire. Les étapes suivantes ne concernent que la partition qui contiendra /boot.

Créer des arrays RAID sur le deuxième disque

Pour le partitionnement du deuxième disque, on peut utiliser #Copier_les_partitions_de_sda_vers_sdb pour avoir les mêmes subdivisions que sur le premier disque et ensuite changer le type de partition avec fdisk de celle qui deviendra un array pour le type "Linux RAID".

Suivre la procédure déjà décrite sous #Construire_un_nouvel_array en choisissant la commande pour quand on n'a qu'un seul device à mettre dans l'array. Formatter le nouvel array comme on veut que ça soit en bout de ligne (e.g. probablement un pv LVM dans sont propre vg + au moins un volume ext4).

Copier les données du premier disque dans l'array du deuxième

On va utiliser data comme nom de Volume Group et le volume qui contient les données s'appellera root.

# rendre le FS du nouvel array disponible pour qu'on puisse y copier les choses
mount /dev/mapper/data-root /mnt
# Copier toutes les données (rappelez-vous on n'a qu'une seule partition dans l'exemple.
# ajustez la source des données si vous avez plusieurs partitions à transférer sur des arrays RAID
rsync -x --info=progress2 -avHAX / /mnt/

S'arranger pour booter sur le RAID

Machine qui boot en mode BIOS:

1. Utiliser GrubConfiguration#Installation_de_GRUB_sur_un_disque_manuellement pour installer grub dans le MBR sur le deuxième disque

2. Redémarrer la machine
   • pendant le boot, utiliser la feature du BIOS de "choix de device de boot" pour démarrer explicitement du deuxième disque -- si le BIOS est trop merdique et permet pas ça, aller dans le menu de setup du BIOS et modifier l'ordre du boot pour que ça soit le deuxième disque qui soit considéré en premier
   • NB: avec BIOS, c'est impossible de savoir après coup c'était quel disque qui a été utilisé pour booter la machine. Pour être vraiment certain que le deuxième disque fonctionne bien pour le boot, on peut débrancher le premier disque ou le désactiver dans le BIOS -- par contre il faudra le réactiver après ça pour pouvoir continuer les prochaines étapes

Machine qui boot en mode EFI:

1. Suivre GrubConfiguration#Installer_grub_sur_les_disques pour le deuxième disque

2. Utiliser GrubConfiguration#Choisir_quel_disque_doit_assurer_le_boot pour créer une entrée qui permet de booter sur le deuxième disque (donc sur la partition EFI du deuxième disque) et ensuite changer l'ordre de boot pour que le deuxième disque soit choisi d'abord.

3. Redémarrer la machine

4. Vérifier avec efibootmgr que l'option de boot choisie était bien celle qui bootait sur le deuxième disque

rentrer le premier disque dans l'array RAID

Maintenant qu'on sait qu'on peut booter la machine sur le RAID, on veut détruire les données du premier disque pour pouvoir le rentrer dans l'array.

1. avec fdisk changer le type de partition de sda2 pour "Linux RAID"

2. ajouter sda2 dans l'array md0 (voir #Ajouter_des_devices_.2BAOA_un_array)

3. attendre que les données soient finies de synchroniser vers sda2

S'assurer qu'on peut bien booter sur le RAID sur le premier disque aussi

Machine qui boot en mode BIOS:

1. Utiliser GrubConfiguration#Installer_grub_sur_les_disques_via_la_configuration_du_package pour installer grub sur le MBR du premier disque (en fait on veut choisir les deux disques dans le menu)

2. Redémarrer la machine
   • pendant le boot, utiliser la feature du BIOS de "choix de device de boot" pour démarrer explicitement du deuxième disque -- si le BIOS est trop merdique et permet pas ça, aller dans le menu de setup du BIOS et modifier l'ordre du boot pour que ça soit le deuxième disque qui soit considéré en premier

Machinue qui boot en mode EFI:

1. Suivre GrubConfiguration#Installer_grub_sur_les_disques pour le premier disque

2. (normalement ici on a déjà une option de boot qui permet de démarrer à partir de sda vu que c'était déjà là avant) Utiliser GrubConfiguration#Choisir_quel_disque_doit_assurer_le_boot pour changer l'ordre de boot et mettre l'option qui démarre sda en premier. On va conserver l'option pour booter sur le deuxième disque, mais en dernière priorité

3. Redémarer la machine

4. Vérifier avec efibootmgr que l'option de boot choisie était bien celle qui bootait sur le premier disque

get a server that has physical partitions in raid to be resized in LVM

cat /proc/mdstat # check which partitions are in which arrays
df -h # check which partitions are mounted where
# check the size of both disks. Some machines are fucked up. You'll bite your fingers if you dont
# Here we have /home on md5 with sd[ab]9 and /tmp on md4 with sd[ab]8
mdadm /dev/md4 --fail /dev/sdb8
mdadm /dev/md4 --remove /dev/sdb8
mdadm /dev/md5 --fail /dev/sdb9
mdadm /dev/md5 --remove /dev/sdb9
# okay, we need to merge those two partitions
parted /dev/sdb
unit b
print
rm 9
rm 8
# here you just bullshit, as it will give you " the closest suitable location". As long as the last byte is the last byte of the disk and the first one is after the last one of the last partition (anyou should be fine 
mkpart logical 59346255872B 320072933375B
fdisk /dev/sdb
t # modify part type 
8  # part 8
fd # type fd, linux raid
w # write and fuck off
mdadm --create /dev/md6 --level=1 -n 1 -f /dev/sdb8 # create raid ; kill nagios alarm 
apt-get install lvm2 # you know you're deep in the hole when...
pvcreate /dev/md6
df # just to be sure not to fuck it up too too bad
lvcreate data -L 50G -n tmp
lvcreate data -L 50G -n home
mkdir /tmp2
mkdir /home2
mkfs.ext4 /dev/mapper/data-home
mkfs.ext4 /dev/mapper/data-tmp
mount /dev/mapper/data-tmp /tmp2
rsync --info=progress2 -av /tmp /tmp2
umount /tmp /tmp2
mount /dev/mapper/data-tmp /tmp
rsync --info=progress2 -av /home /home2
umount /home /home2
mount /dev/mapper/data-home /home
# okay, we swapped over, now we bring back the old drives in the game
mdadm --stop /dev/md5
mdadm --stop /dev/md4
rm -fr home2 tmp2 # old crap
# redo the same steps for the previous disk w/ parted, fdisk and al.
mdadm /dev/md6 --add /dev/sda8 
# if its monday, and you didn't check disk size you'll likely get mdadm: /dev/sda8 not large enough to join array
mdadm --create /dev/md7 --level=1 -n 1 -f /dev/sda8 # create new array on the small disk
vgextend data /dev/md7 # add md7 in the data vg
pvmove /dev/md6 /dev/md7 # now, at least we got fucking lvm so we can move without fucking rsync !
# Left as exercise to the user: delete the old raid part on sdb, put the new one same size, and rebuild the array 

You might have made orphans ! If LVM is whining: Couldn't find device with uuid XXXXXX-XXX-X-XX-XXX-XXX ; you can shut it up via:  vgreduce data --removemissing 

Grossir un array LVM avec un nouveau raid (comme sur le serveur de backup)

• Créer un raid sur les disques. Dans ce example c'est sur partitions 1 de sdc et sdd, mais c'est aussi possible de le mettre directement sur les disques, sans partitions.

# mdadm --create --verbose /dev/md5 --level=1 --raid-devices=2  /dev/sdc1 /dev/sdd1

Attention, vous ne voulez probablement pas copier des partitions comme /boot, vous voulez utilisez tout les disques pour les backups.

• Y-a-t-il de la crypto ? Si oui, mettez de la crypto sur cet array aussi.

# cryptsetup luksFormat /dev/md5
# cryptsetup luksOpen /dev/md5 data_crypt3

• pvcreate sur le device de crypto

# pvcreate /dev/mapper/data_crypt3

• vgextend le vg sur le nouveau pv

# vgextend data /dev/mapper/data_crypt3

• lvextend (l'option -r est nouveau et ca resize le volume et FS tout à la fois sans downtime!)

# lvextend -rl 100%VG data/srv

• check size avec vgs et lsblk -i
• rewrite raid arrays config

# /usr/share/mdadm/mkconf > /etc/mdadm/mdadm.conf

• Mettre une ligne dans /etc/crypttab pour le nouveau crypt aussi.

pogner un vg qui était sur un array pas encrypté et le mettre sur un encrypté

• /dev/md2: le md original
  • md2 est un PV dans le VG "data" et un LV nommé "dummy" a été créé par le FAI pour prendre toute la place dans le VG
• /dev/sdb6: un drive de md2 original
• /dev/sda6: l'autre drive de md2 original
• /dev/md3 le nouveau md

mdadm --manage /dev/md2 --fail /dev/sdb6
mdadm /dev/md2 --remove /dev/sdb6
mdadm --create /dev/md3 --level=1 -n 1 -f /dev/sdb6
cryptsetup luksFormat /dev/md3
cryptsetup luksOpen /dev/md3 data-crypt
pvcreate /dev/mapper/data-crypt
vgextend data /dev/mapper/data-crypt
lvremove data/dummy
vgreduce data /dev/md2
mdadm --manage /dev/md2  --stop
mdadm /dev/md3 -G -n 2 --add /dev/sda6

On veut l'option noauto pour pas avoir à mettre le passphrase lors du boot sur la console mais avoir une trace dans le /etc/crypttab comme quoi on n'a bien de la crypto sur la machine. On va entrer le passphrase quand on va avoir confortablement booté la machine, par ssh. (ici, les opinions peuvent diverger )

cat >> /etc/crypttab << EOF
data-crypt    /dev/md3                none            luks,noauto
EOF

Après faut faire la swap:

swapoff /dev/md1
mkswap -f -L swap /dev/md1
#ajouter l'entré dans /etc/crypttab
echo "crypto_swap UUID=$(blkid -o full /dev/md1 | cut -d '"' -f 4) /dev/urandom swap,offset=8,cipher=aes-cbc-essiv:sha256" >> /etc/crypttab
service cryptdisks force-start
# crisser ca dans fstab
cat /etc/fstab | grep -v swap | sed "$ a/dev/mapper/crypto_swap none swap sw 0 0" > /etc/fstab_new
mv /etc/fstab_new /etc/fstab
swapon /dev/mapper/crypto_swap

Kekun voulait une machines ak centos installé sur 2x1tb en raid, on avait juste un 3tb pi 1x1tb, mais c'est en lvm

sfdisk -d /dev/sdb | sfdisk --no-reread --force /dev/sda # on avait installé sur le 1tb
fdisk /dev/sda # t 1 fd t 2 fd ; changer le type de partitions de LVM => raid, mais on garde la même taille (pi on est pas en gpt)
mdadm --create /dev/md0 --metadata=0.90 --level=1 -n 1 -f /dev/sda1  # /boot gets --metadata funkies
mdadm --create /dev/md1 --level=1 -n 1 -f /dev/sda2  # where the lvm goes
pvcreate /dev/md1
vgextend data /dev/md1
pvmove -n LogVol00 /dev/sdb2 /dev/md1 # that should be called swap, but centos is pile of wank
pvmove -n LogVol01 /dev/sdb2 /dev/md1 # that should be called slash, but centos is pile of wank
vgreduce data /dev/sdb2
umount /boot # surprisingly, you can sfdisk before this one without having a garbage full of kittens thrown in a wood chipper
sfdisk -d /dev/sda | sfdisk --no-reread --force /dev/sdb # we swap over the partitions, yeah, double read that one... the drives are mounted

enlever un raid d'un vg, pi enlever le raid en général

Aller voir LvmMaintenance ; après avoir fait  vgreduce -v data /dev/md1  vous pourrez faire  mdadm --stop md1 , on backup l'ancien mdadm.conf  cp /etc/mdadm/mdadm.conf /etc/mdadm/mdadm.conf_before_removing_md1  pi on pitche la nouvelle config dans l'mdadm.conf  /usr/share/mdadm/mkconf > /etc/mdadm/mdadm.conf . R'rajouter les lignes importantes de mdadm.conf, genre toute ce qui est pas la définition des arrays.

Faites un ticket pour enlever le disques pi assurez vous que vous aillez pas à y'aller :D.

Troubleshooting

Voir InitramfsGuide quand vous tomber dans le initramfs au boot.

Deux arrays ont des noms qui sont en conflit

Si jamais deux arrays ont le même nom, ça bloque le démarrage des arrays.

Une chose qui pourrait causer ça c'est un mdadm.conf qui n'est pas bon. Si un nom d'array est en double dans mdadm.conf, mdadm va respecter la config avant tout.

Donc une façon d'essayer de surmonter le problème, c'est de renommer le fichier de conf pour que mdadm ne le voit plus. par exemple:

(initramfs) mv /etc/mdadm/mdadm.conf /etc/mdadm/mdadm.conf.bkp

ensuite réessayer mdadm --scan --assemble, ou encore mdadm -I /dev/sdXY comme dans la section précédente.

S'assurer que les arrays soient reconstruit automatiquement pendant le boot

Une fois que la machine est revenue en ligne (ou bien à chaque fois qu'on fait un changement qui créé ou retire un array), il est important de s'assurer que les prochains boots se passent bien.

Reconstruire le fichier mdadm.conf:

/usr/share/mdadm/mkconf > /etc/mdadm/mdadm.conf

Finalement, pour que le boot fonctionne, il faut mettre à jour le initramfs (pour que les nouvelles lignes dans mdadm.conf soient copiées dans l'image utilisée pour le boot).

# update-initramfs -u
update-initramfs: Generating /boot/initrd.img-3.2.0-4-amd64

et on reboot la machine pour vérifier que tout revient en fonction automatiquement.

Nouveau comportement du raid dans Jessie | En raid1 degraded, on boot pas on tombe dans initramfs

Dans Debian Jessie, il y a plusieurs rapports de bug à propos de la difficulté de redémarrer un serveur en avec un array en mode degraded. 784070 784823 . Quand il manque un disque à l'array lors du premier reboot, on tombe dans le prompt du initramfs... un peu déroutant. C'est que l'array n'est pas activé, en l'activant on peut ensuite continuer le redémarrage en mode degraded. Noter que les redémarrages subséquents n'auront pas ce problème, le système démarre directement en mode degraded...

Est-ce un bug où une feature...? Ça reste à suivre.

• Utiliser la procédure décrite plus haut pour réassembler les arrays et continuer et boot.
• S'assurer de corriger le mdadm.conf si nécessaire, et mettre à jour le initramfs comme décrit plus haut.

Brisé suite à un cold reboot

Suite à cold reboot, 4 des 6 arrays sont en mode "degraded". J'ai reçu le mail qui suit:

This is an automatically generated mail message from mdadm
running on che

A DegradedArray event had been detected on md device /dev/md4.

Faithfully yours, etc.

Voyons voir d'un peu plus près.

# cat /proc/mdstat
Personalities : [raid1] 
md5 : active raid1 sda7[0]
      234910336 blocks [2/1] [U_]
      
md4 : active raid1 sda6[0]
      2931712 blocks [2/1] [U_]
      
md3 : active raid1 sda5[0]
      2931712 blocks [2/1] [U_]
      
md2 : active raid1 sda3[0] sdb3[1]
      979840 blocks [2/2] [UU]
      
md1 : active raid1 sdb2[0] sda2[1]
      1951808 blocks [2/2] [UU]
      
md0 : active raid1 sda1[1]
      489856 blocks [2/1] [_U]
      
unused devices: <none>

Reconstruire l'array

Il faut dire a mdadm que les partitions sont en ligne, pour reconstruire l'array:

Pour ajouter les partitions dans l'array raid.

# mdadm /dev/md0 -a /dev/sdb1
# mdadm /dev/md3 -a /dev/sdb5
# mdadm /dev/md4 -a /dev/sdb6
# mdadm /dev/md5 -a /dev/sdb7

# cat /proc/mdstat 
Personalities : [raid1] 
md5 : active raid1 sdb7[2] sda7[0]
      234910336 blocks [2/1] [U_]
      [>....................]  recovery =  0.1% (299392/234910336) finish=78.3min speed=49898K/sec
      
md4 : active raid1 sdb6[1] sda6[0]
      2931712 blocks [2/2] [UU]
      
md3 : active raid1 sdb5[1] sda5[0]
      2931712 blocks [2/2] [UU]
      
md2 : active raid1 sda3[0] sdb3[1]
      979840 blocks [2/2] [UU]
      
md1 : active raid1 sdb2[0] sda2[1]
      1951808 blocks [2/2] [UU]
      
md0 : active raid1 sdb1[0] sda1[1]
      489856 blocks [2/2] [UU]
      
unused devices: <none>

"Failure" d'un des disques scénario 1

Les arrays d'un des disques ont état de "failed"

# cat /proc/mdstat 
Personalities : [raid1] 
md3 : active raid1 sdb5[2](F) sda5[1]
      302311040 blocks [2/1] [_U]
      
md2 : active raid1 sdb3[2](F) sda3[1]
      7815552 blocks [2/1] [_U]
      
md1 : active raid1 sdb2[2](F) sda2[1]
      1951808 blocks [2/1] [_U]
      
md0 : active raid1 sdb1[2](F) sda1[1]
      489856 blocks [2/1] [_U]
      
unused devices: <none>

On doit les retirer de l'array avec la commande -r (remove)

# mdadm /dev/md0 -r /dev/sdb1
mdadm: hot removed /dev/sdb1
# mdadm /dev/md1 -r /dev/sdb2
mdadm: hot removed /dev/sdb2
# mdadm /dev/md2 -r /dev/sdb3
mdadm: hot removed /dev/sdb3
# mdadm /dev/md3 -r /dev/sdb5
mdadm: hot removed /dev/sdb5

Mais sur un array, on se retrouve avec un "device busy" ou "drive busy". Ça veut rien savoir même avec --force

On va voir les détails de l'array et on se retrouve avec ça....

mdadm --detail /dev/md3: faulty spare rebuilding

voici ce qu'on devrait avoir.

....
   Number   Major   Minor   RaidDevice State
       0       0        0        0      removed
       1       8        6        1      active sync   /dev/sda6

Comme on ne sait pas trop quoi faire avec ça, on reboot la machine....

"Failure" d'un des disques scénario 2

Les arrays d'un des disques sont identifiés comme défaillant.

Sep 10 17:49:42 platon kernel: ata2: port is slow to respond, please be patient
Sep 10 17:49:42 platon kernel: ata2: soft resetting port
Sep 10 17:49:42 platon kernel: ATA: abnormal status 0xD0 on port 0x30C7
Sep 10 17:49:42 platon last message repeated 3 times
Sep 10 17:49:42 platon kernel: ata2.00: qc timeout (cmd 0xec)
Sep 10 17:49:42 platon kernel: ata2.00: failed to IDENTIFY (I/O error, err_mask=0x4)
Sep 10 17:49:42 platon kernel: ata2: failed to recover some devices, retrying in 5 secs
Sep 10 17:49:42 platon kernel: ata2: port is slow to respond, please be patient
Sep 10 17:49:42 platon kernel: ata2: soft resetting port
Sep 10 17:49:42 platon kernel: ATA: abnormal status 0xD0 on port 0x30C7
Sep 10 17:49:42 platon last message repeated 3 times
Sep 10 17:49:42 platon kernel: ata2.00: qc timeout (cmd 0xec)
Sep 10 17:49:42 platon kernel: ata2.00: failed to IDENTIFY (I/O error, err_mask=0x4)
Sep 10 17:49:42 platon kernel: ata2: failed to recover some devices, retrying in 5 secs
Sep 10 17:49:42 platon kernel: ata2: port is slow to respond, please be patient
Sep 10 17:49:42 platon kernel: ata2: soft resetting port
Sep 10 17:49:42 platon kernel: ATA: abnormal status 0xD0 on port 0x30C7
Sep 10 17:49:42 platon last message repeated 3 times
Sep 10 17:49:42 platon kernel: ata2.00: qc timeout (cmd 0xec)
Sep 10 17:49:42 platon kernel: ata2.00: failed to IDENTIFY (I/O error, err_mask=0x4)
Sep 10 17:49:42 platon kernel: ata2.00: disabled
Sep 10 17:49:42 platon kernel: ata2: EH complete
Sep 10 17:49:42 platon kernel: sd 1:0:0:0: SCSI error: return code = 0x00040000
Sep 10 17:49:42 platon kernel: end_request: I/O error, dev sdb, sector 568848068
Sep 10 17:49:42 platon kernel: ^IOperation continuing on 1 devices
Sep 10 17:49:42 platon kernel: sd 1:0:0:0: SCSI error: return code = 0x00040000
Sep 10 17:49:42 platon kernel: end_request: I/O error, dev sdb, sector 568848100
Sep 10 17:49:42 platon kernel: sd 1:0:0:0: SCSI error: return code = 0x00040000
Sep 10 17:49:42 platon kernel: end_request: I/O error, dev sdb, sector 568848124

État du raid1

# cat /proc/mdstat 
Personalities : [raid1] 
md3 : active raid1 sdb5[2](F) sda5[1]
      302311040 blocks [2/1] [_U]
      
md2 : active raid1 sdb3[2](F) sda3[1]
      7815552 blocks [2/1] [_U]
      
md1 : active raid1 sdb2[2](F) sda2[1]
      1951808 blocks [2/1] [_U]
      
md0 : active raid1 sdb1[2](F) sda1[1]
      489856 blocks [2/1] [_U]
      
unused devices: <none>

Tentative de remise en fonction du raid1 (marche pas)

On doit premièrement enlever les arrays défaillants et ensuite les réajouter.

# mdadm /dev/md0 -r /dev/sdb1
mdadm: hot removed /dev/sdb1
# mdadm /dev/md1 -r /dev/sdb2
mdadm: hot removed /dev/sdb2
# mdadm /dev/md2 -r /dev/sdb3
mdadm: hot removed /dev/sdb3
# mdadm /dev/md3 -r /dev/sdb5
mdadm: hot removed /dev/sdb5

État du raid

Personalities : [raid1]
md3 : active raid1 sda5[1]
      302311040 blocks [2/1] [_U]

md2 : active raid1 sda3[1]
      7815552 blocks [2/1] [_U]

md1 : active raid1 sda2[1]
      1951808 blocks [2/1] [_U]

md0 : active raid1 sda1[1]
      489856 blocks [2/1] [_U]

On essaye de réajouter l'array mais ça ne fonctionne pas.

# mdadm /dev/md0 -a /dev/sdb1
mdadm: add new device failed for /dev/sdb1 as 2: Invalid argument

Examinons la partition plus en détail...

# mdadm -E /dev/sdb1
mdadm: No md superblock detected on /dev/sdb1.

Ça va pas bien, on va devoir redémmarrer le serveur pour voir si c'est toujours possible d'ajouter l'array du deuxième disque (sdb).

Réf:

• http://xtronics.com/reference/SATA-RAID-debian-for-2.6.html

• http://marc.info/?l=linux-raid&m=115320108924249&w=2

• http://linux.derkeiler.com/Mailing-Lists/SuSE/2007-06/msg01960.html

Conflit avec le raid hardware

Lors du retour de hesiode.koumbit.net chez le manufacturier, le réparateur a réactivé par erreur le RAID hardware, et commencé le mirror. Ceci a provoqué des problèmes de synchronisation sur le RAID software (mdadm) qui se plaignait que les partitions avaient les mêmes "superblocks" et refusait de reconstruire l'array, en innondant la console de messages d'erreurs (ce qui semble un bug de mdadm). Il a semblé alors impossible de récupérer la situation directement et il a fallu booter avec un cd d'install de debian en mode rescue. Voici la procédure de récupération:

mdadm -A /dev/md0 /dev/sda1 --run

--run force l'array à se reconstruire avec seulement un disque. On doit ensuite ajouter la partition du second disque normalement:

mdadm -a /dev/md0 /dev/sdb1

À répéter pour chaque partie de l'array.

Notez bien la différence entre -A (majuscule, --assemble) et -a (minuscule, --add) entre les deux commandes.

Voir aussi RapportsIntervention/2009-01-15.

Problèmes de performance

On a eu des problèmes de performance en recovery des disques sur remus et romulus. On pourrait probablement tuner ça avec:

/proc/sys/dev/raid/speed_limit_min

• A readable and writable file that reflects the current goal rebuild speed for times when non-rebuild activity is current on an array. The speed is in Kibibytes per second, and is a per-device rate, not a per-array rate (which means that an array with more disc will shuffle more data for a given speed). The default is 100.

/proc/sys/dev/raid/speed_limit_max

• A readable and writable file that reflects the current goal rebuild speed for times when no non-rebuild activity is current on an array. The default is 100,000.

Les problèmes:

• on a 3 device raid sur le même disque. Puisque le plus gros (md2, 180G) n'est pas vraiment utilisé pour l'instant, md pense que c'est OK de le maxer, alors que le md2 partage le disque avec un autre device

• le max était de 200,000, je l'ai descendu à 3,500KiB/s (3,5MiB/s) avec echo 3500 > /proc/sys/dev/raid/speed_limit_max. Il faut inscrire cette config dans /etc/sysctl.conf pour qu'elle survive aux reboots: echo dev.raid.speed_limit_max=3500 >> /etc/sysctl.conf.

Fermer d'urgence un resync mensuel

Cette commande arrête l'opération en cours de "scrubbing" mensuel sur /dev/md1:

echo idle > /sys/block/md1/md/sync_action

Normalement, /usr/share/mdadm/checkarray -x devrait arrêter le check, mais ça n'a pas fonctionné de mon côté. -- TheAnarcat 2015-05-06 16:02:58

Des mails parlent de SparesMissing mais l'array en question a pas de spares

Si jamais ça arrive, c'est p-e que dans mdadm.conf il y a un argument pour l'array qui dit qu'il devrait y avoir un spare: il faut enlever cet argument. Par exemple ici c'est md3 qui crie au meurtre pour son spare:

# definitions of existing MD arrays
ARRAY /dev/md/0 metadata=1.2 name=host229:0 UUID=f0d39bbd:8939b282:f54858a2:95f9f09c
ARRAY /dev/md/1 metadata=1.2 name=host229:1 UUID=573f5e13:249b703d:44e4dbaa:375ff827
ARRAY /dev/md3 metadata=1.2 spares=1 name=host229:3 UUID=397867aa:e6921279:ff41a7cd:04a2706e

on veut que la ligne de md3 devienne:

ARRAY /dev/md3 metadata=1.2 name=host229:3 UUID=397867aa:e6921279:ff41a7cd:04a2706e

Après le changement, il faut redémarrer le service mdadm pour que le process qui monitor l'état load le changement de conf:

service mdadm restart

référence: https://unix.stackexchange.com/questions/8511/mdadm-raid5-gives-spares-missing-events#9445

Folks said for years that "we don't need zfs" and you just yolo'edly added more drives in raid arrays in a complete clusterfuck and you don't really know how to fix the fucking server as it has 12 drives installed

Okay, mount to get what is mounted where. Most things mounted should be in lvm aside from /boot. If not, think of a way of bringing it in the situation. Verify /boot is at a nice spot.

If everything is in one vg, shit should be sane. Otherwise vgmerge until sanity. Then you can  pvs , to see what drives are actually used. As in:

 for i in `pvs | sed 's/^[ ]*//' | cut -d ' ' -f 1 | tail -n 3 | cut -d '/' -f3` ; do lsblk -i | grep $i -B3; done 

Obviously, those names don't match the one given to by mdadm:  for i in `mdadm --detail --scan  | cut -d ' ' -f 2` ; do ls -ld $i ; done 

So... grab yourself a drink and a bucket of patience. You rename arrays by changing their definitions in /etc/mdadm/mdadm.conf. The usual  mdadm --detail --scan > /file  can't work here as you have a bunch of arrays with name inherited from the boot process, and arrays you might not want to include because its just someone that tossed a random drive in. Put some comments in that file. Reboot to see if the fucker boot. If not, try again.

Guillaume's way

You want 2 array per 2 drives for raid1:

• The second one, you want crypto on top of it, otherwise you'd have to type two crypto key. Then, on top of shit, you install LVM beause you never ever want to have to resize cryptsetup and raid. You toss swap on that VG, because you want to crypt swap.
• The first one you mount on /boot so you can boot

its all fucked

You start from the root:  pvs  will tell you the physical volumes, to help you find where is the lvm starting on. On linux 3.2.0, you might still get  /dev/dm-0 data lvm2 a-- XXXg XXXg . What the fuck is dm-0 ? Its just mapper odd stuff,  ls -l /dev/mapper  they're all a bunch of links to  /dev/dm* .

mdadm stops in the middle of rebuilding the array, as there is read error on the remaining drive :S

Okay. First of, grep the remaining drive in /var/log/syslog:

Feb 22 22:58:35 skidoo kernel: [10218851.129360] end_request: I/O error, dev sdb, sector 136133082
Feb 22 22:58:35 skidoo kernel: [10218851.129360] Buffer I/O error on device sdb6, logical block 16845728

Hdparm the blocks to see if they're fucked:  hdparm --read-sector 48059863 /dev/sdb . Find the one that says something along "read error".

You can then force-rewriting the sector with:  hdparm –write-sector 1261069669 /dev/sdb  (it will ask you to add an argument, as this damages the data on the drive).

Normally, after that you'll be able read the sector, as the sector has been moved off the drive.

That failed, I'm really fucked

ddrescue --force /dev/sdb6 /dev/sda6 prout.log2

Now, you're gonna have downtime. Stop all the things on the disk, and rebuild the current array with /dev/sda6 instead of sdb6, and then readd sdb6.

ext4 is pissing blood in dmesg

use debugfs ncheck to see what was the file:

debugfs:  ncheck 65551416     

Est-ce qu'un disque est encore bon

Au moins rouler:

badblocks -wvsb 4096 -p 3 /dev/sdc

run fsck

Just fsck it ! On ext4, it only takes 10 minutes, and avoid a lot of bullshit !

remount -o ro, remount /patate
fsck -fy /patate

C'est beau c'est fini mon pitt !

Ca peut valoir la peine de démonter si y'a beaucoup d'erreur, c'est comme si ca ferait pas toute la job quand le fs est monté RO. De toute facon, si ca prend 10 minutes avec RO, ca va prendre 10 minutes démonté.

Cryptsetup ne voit pu les données luks sur un array raid

Ça se peut que t'ai fait une erreur de @dd@ pis que tu t'es mis à pété un disque dans un array raid. Le serveur a planté pis, au boot, il peut pu trouver la partition principale /

Une fois que tu boot en FAI, tu tente d'unlock le device encrypté pis t'as ça:

root@ip-199-58-82-53:/tmp/fai# cryptsetup luksOpen /dev/md127 crypt_md127
Device /dev/md127 is not a valid LUKS device.

Dans ce cas, cryptsetup luksDump /dev/md127 va se plaindre aussi que c'est pas un device LUKS.

Or, le array raid semble bien synced, ce qui laisse croire que les données sont les mêmes sur les deux disques

root@ip-199-58-82-53:/tmp/fai# cat /proc/mdstat 
Personalities : [raid1] 
md126 : active (auto-read-only) raid1 sda1[2] sdb1[3]
      5238784 blocks super 1.2 [2/2] [UU]

md127 : active (auto-read-only) raid1 sdb2[0] sda2[2]
      57246016 blocks super 1.2 [2/2] [UU]

unused devices: <none>

Ait espoir! mdadm se trompe peut-être. dd a juste wiper les données d'une partition, pis là, raid se fourre quand il lit le array et voit juste sweet fuckall. Pour tester si c'est ça et t'éviter le pire, on va retirer la partition qui s'est fait faire un dd dans les dents, pis checker si raid lit bien le array quand ya juste la partition saine, pis re-tenter de voir les header.

root@ip-199-58-82-53:/tmp/fai# mdadm /dev/md127 -f /dev/sdb2
[ 6334.068649] md/raid1:md127: Disk failure on sdb2, disabling device.
[ 6334.068649] md/raid1:md127: Operation continuing on 1 devices.
mdadm: set /dev/sdb2 faulty in /dev/md127
root@ip-199-58-82-53:/tmp/fai# mdadm /dev/md127 -r /dev/sdb2
mdadm: hot removed /dev/sdb2 from /dev/md127

root@ip-199-58-82-53:/tmp/fai# cryptsetup luksDump /dev/md127
LUKS header information for /dev/md127

Version:        1
Cipher name:    aes
Cipher mode:    xts-plain64
Hash spec:      sha512
Payload offset: 4096
MK bits:        512
MK digest:      67 3e e9 69 ca 32 65 f0 d4 2c 59 95 64 5b d2 ea d0 e3 ca 21 
MK salt:        5f 4b ef 5e 46 88 3a 47 5c cf 6d 2d 68 1e 55 4c 
                8d f7 31 bb 8e 23 19 59 fd 53 9c 82 d3 f6 01 13 
MK iterations:  9750
UUID:           a0dd7e61-22aa-4a51-8cce-ac81b497351f

Key Slot 0: DISABLED
Key Slot 1: ENABLED
        Iterations:             313944
        Salt:                   72 b3 83 b4 87 ac b5 3f 4c 6e e7 be de b5 e6 1f 
                                bc a1 c0 3f ed ff 7e 85 97 6a 16 8e bf ef 66 24 
        Key material offset:    512
        AF stripes:             4000
Key Slot 2: DISABLED
Key Slot 3: DISABLED
Key Slot 4: DISABLED
Key Slot 5: DISABLED
Key Slot 6: DISABLED
Key Slot 7: DISABLED

Si tu vois bien un résultat de luksDump c'est que t'as maintenant accès à la partition!

root@ip-199-58-82-53:/tmp/fai# cryptsetup luksOpen /dev/md127 crypt_md127
Enter passphrase for /dev/md127: 
root@ip-199-58-82-53:/tmp/fai# lsblk

Pis c'est toujours une bonne idée de checker le filesystem si tu t'es rendu à un fuck demême

root@ip-199-58-82-53:/tmp/fai# fsck.ext4 -f /dev/mapper/host-slash 

Et on remet le disque meurtri dans le array

199-58-82-53:/tmp/fai# mdadm /dev/md127 -a /dev/sdb2

Attend que ça sync, pis reboot the shit out of his face.

Software Raid sous freebsd

Documentation officiel de freebsd : http://www.freebsd.org/doc/handbook/geom-mirror.html

Il ne semble pas avoir de process qui monitor l'état des arrays pour envoyer un e-mail en cas d'échec de disque. Certaines personnes le font avec des scripts maison. C'est aussi possible de surveiller l'état via Nagios et NRPE avec le script check_gmirror.

Notre documentation:

• FreeBsdConfiguration#RAID

• FreeBsdMaintenance#RAID_maintenance

Hardware Raid

En général on ne veut pas utiliser du hardware raid sur les machines. Ça ajoute beaucoup de complexité à notre setup là où mdadm fait de l'excellent travail.

Par contre, dans certains cas c'est impossible de passer à côté -- surtout sur des machines clients qu'on doit gérer. Donc c'est important de savoir comment interagir avec ça.

Serveurs avec du hardware Raid

Please use a more selective search term instead of search_term="linkto:CategoryServer"

LSI Logic

Pour obtenir le statut du Raid, il faut installer le package 'mpt-status' et ensuite utiliser la commande du même nom:

root@osiris:~# mpt-status 
ioc0 vol_id 0 type IME, 4 phy, 1117 GB, state DEGRADED, flags ENABLED
ioc0 phy 0 scsi_id 10 SEAGATE  ST600MM0026      0001, 558 GB, state ONLINE, flags NONE
ioc0 phy 1 scsi_id 1 SEAGATE  ST9600205SS      0002, 558 GB, state ONLINE, flags NONE
ioc0 phy 2 scsi_id 255   , 558 GB, state MISSING, flags OUT_OF_SYNC
ioc0 phy 3 scsi_id 3 SEAGATE  ST9600205SS      0002, 558 GB, state ONLINE, flags NONE

on voit dans l'exemple plus haut que trois des disques sont marqués dans l'état ONLINE, donc tout est beau, et un disque et MISSING.

Sur osiris, on peut obtenir l'information SMART sur des devices un peu drôlement notés:

root@osiris:~# ls /dev/sg*
/dev/sg0  /dev/sg1  /dev/sg2  /dev/sg3  /dev/sg4

Les quatre premiers devices, de 0 à 3, semblent afficher l'info des 4 disques, tandis que sg4 semble correspondre au disque logique (e.g. l'array raid)

Malheureusement, hdparm sur ces devices ne donne pas d'information, mais smartctl -a nous permet de voir les numéros de série.

LSI Logic (non-mpt)

Certains devices LSI Logic ne sont pas compatibles avec mpt-status (même si juste pour être mélangeant, leur nom de modèle peut contenir "Fusion-MPT").

C'est le cas par exemple pour LSI Logic / Symbios Logic SAS2008 PCI-Express Fusion-MPT SAS-2 (ou Perc H200S selon l'appellation Dell). Pour ces controlleurs, il faut utiliser le binaire propriétaire sas2ircu.

Ce binaire est disponible sous forme de packages debian. Voir: http://hwraid.le-vert.net/wiki/DebianPackages

Une fois les packages sas2ircu et sas2ircu-status installés, on peut obtenir l'état du RAID avec sas2ircu-status:

root@xen11:~# sas2ircu-status 
-- Controller informations --
-- ID | Model
c0 | SAS2008

-- Arrays informations --
-- ID | Type | Size | Status
c0u0 | RAID1 | 152G | Okay (OKY)

-- Disks informations
-- ID | Model | Status
c0u0p0 | INTEL SSDSC2BB16 (BTWL416502VG160MGN) | Optimal (OPT)
c0u0p1 | INTEL SSDSC2BB16 (BTWL418502QH160MGN) | Optimal (OPT)

Les disques sont exposés pour l'info SMART en tant que /dev/sg*. On peut configurer smartmontools pour monitorer les disques. Voir: http://hwraid.le-vert.net/wiki/LSIFusionMPTSAS2

On peut vérifier l'état du RAID via nagios avec le plugin check_sas2ircu.

Adaptec ASR-2405

• Selon cette page, il n'a pas de package dans debian qui permet de faire le suivi des arrays raid https://wiki.debian.org/LinuxRaidForAdmins#aacraid

• Est-ce qu'on va devoir installer du logiciel propriétaire?

  • http://hwraid.le-vert.net/wiki/DebianPackages a un répo qu'on pourrait utiliser...

Après essai, le package pour le logiciel propriétaire qui est présenté dans le lien juste au dessus semble bien fonctionner. Voici les étapes pour installer et configurer le service comme du monde:

wget http://hwraid.le-vert.net/debian/hwraid.le-vert.net.gpg.key
apt-key add hwraid.le-vert.net.gpg.key
echo "deb http://hwraid.le-vert.net/debian squeeze main" > /etc/apt/sources.list.d/hwraid.list
apt-get update
apt-get install aacraid-status
echo "MAILTO=support@koumbit.org" > /etc/default/aacraid-statusd
service aacraid-statusd restart

pour voir l'état du raid, on peut appeler la commande manuellement:

# aacraid-status

pour avoir les détails sur les disques et l'array

# arcconf GETCONFIG 1

SAS1078

• On peut utiliser le package mpt-status

  • echo 'mptctl' >> /etc/modules && modprobe mptctl && mpt-status

comme le script qui roule comme daemon pour vérifier l'état est exactement le même que pour aacraid-stautsd, la configuration est très similaire:

echo "MAILTO=support@koumbit.org" > /etc/default/mpt-statusd
service mpt-statusd restart

References

• Debian repository containing all packages to install proprietary and opensource tools for you RAID card.

• Software-RAID-HOWTO

• définition des RAID levels

• Unix Backup & Recovery

• LVM-HOWTO

• un bon aperçu du support matériel pour le RAID hardware

• RAID backup

• Doc chez riseuplabs

• Doc chez RiseUp pour agrandir raid+luks+lvm+ext4

---

CategoryDebug CategoryFreebsd