Notre documentation:

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.

Contents

  1. Software Raid sous linux
    1. Afficher une vue d'ensemble des disques/partitions/crypto/lvm
    2. Est-ce que ca vaut la peine de crypter /boot
    3. Copier les partitions de sda vers sdb
    4. Wiper la table de partitions
    5. Reconstruire un RAID
      1. Avec un nouveau disque
      2. Changer un disque dans un raid qui fonctionne déjà
    6. Grossir un array RAID-1
    7. Réduire un array RAID
      1. Un des disques est trop petit pour l'array, comment on trouve la taille à laquelle réduire?
    8. Renommer un array
    9. Remplacement complet des disques et ajout d'un array
    10. Construire un nouvel array
    11. Eviter les resync mensuels via un "write-intent" bitmap
    12. démarrer un resync pour un array qui ne contient encore pas de données
    13. complètement supprimer un array
    14. Cas d'usage mixtes/complexes
      1. get a server that has physical partitions in raid to be resized in LVM
      2. Grossir un array LVM avec un nouveau raid (comme sur le serveur de backup)
      3. pogner un vg qui était sur un array pas encrypté et le mettre sur un encrypté
      4. Kekun voulait une machines ak centos installé sur 2x1tb en raid, on avait juste un 3tb pi 1x1tb, mais c'est en lvm
      5. enlever un raid d'un vg, pi enlever le raid en général
    15. Troubleshooting
        1. Deux arrays ont des noms qui sont en conflit
        2. S'assurer que les arrays soient reconstruit automatiquement pendant le boot
        3. Nouveau comportement du raid dans Jessie | En raid1 degraded, on boot pas on tombe dans initramfs
      1. Raid setup backup
      2. Brisé suite à un cold reboot
        1. Reconstruire l'array
      3. "Failure" d'un des disques scénario 1
      4. "Failure" d'un des disques scénario 2
        1. Tentative de remise en fonction du raid1 (marche pas)
      5. Conflit avec le raid hardware
      6. Problèmes de performance
      7. Fermer d'urgence un resync mensuel
      8. Des mails parlent de SparesMissing mais l'array en question a pas de spares
      9. 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
      10. Guillaume's way
        1. its all fucked
      11. mdadm stops in the middle of rebuilding the array, as there is read error on the remaining drive :S
      12. That failed, I'm really fucked
      13. ext4 is pissing blood in dmesg
        1. run fsck
    16. References
  2. Software Raid sous freebsd
  3. Hardware Raid
    1. LSI Logic
    2. LSI Logic (non-mpt)
    3. Adaptec ASR-2405
    4. SAS1078
    5. Surveillance
    6. References
  4. Le timing

Software Raid sous linux

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 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.

Est-ce que ca vaut la peine de crypter /boot

Si tu cryptes /boot, faut que tu tappes le passphrase pour que grub parte, pi après une autre fois pour initramfs... Ca rend l'affaire 2 fois plus compliquée, et il faut vraiment que la console série fonctionne sur le menu grub.

Copier les partitions de sda vers sdb

  1. Pour les disques de moins de 2Tb: Copier la table des partitions sur le disque qu'on veut incorporer dans l'array raid.

    • sfdisk -d /dev/sda | sfdisk --no-reread --force /dev/sdd
  2. Sur les gros disques (2Tb+), fdisk/sfdisk capote, il faut utiliser gdisk. 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:

    • DESTINATION=sdb
      ORIGINE=sda
      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

Wiper la table de partitions

Cette opération détruit les informations de la table de partition d'un disque, il faut donc faire très attention de ne pas rouler la commande sur le mauvais disque!

En cas d'erreur il est possible de rétablir la table de partitions. TODO comment faire ça?

Effacer une table de partition entière peut être utile pour éviter la "polution" de namespace d'arrays raid. Par exemple si on plug un disque qui a déjà été utilisé pour autre chose, il avait p-e des partitions qui faisaient partie d'un array raid, et peut-être même que les noms des arrays clashent avec ceux déjà utilisés par la machine.

Par conséquent, c'est une bonne pratique de toujours wiper les disques (au moins remettre à 0) avant de les plugger dans quoi que ce soit d'autre! Ça évite les situations où on a besoin d'une commande aussi destructrice.

L'opération détaillée ici ne signale pas au kernel que la table de partition a changée pour un disque et donc les fichiers device des partitions ne disparaîssent pas. Apparemment, partprobe n'est pas capable de voir la disparition des partitions non plus.

Il faut utiliser sfdisk /dev/sdf et sauvegarder pour que l'OS puisse voir les changements.

Si on trouve une meilleure méthode qui est moins disruptive, il faudrait remplacer l'opération dans cette section.

La table de partitions d'un disque est le premier bloc de 512 bytes sur un disque, donc on peut simplement faire:

dd if=/dev/zero of=/dev/sdb bs=512 count=1

Reconstruire un RAID

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

Avec 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à

  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

    • 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

On ne doit pas oublier d'installer le bootloader!

Voir GrubConfiguration.

Grossir un array RAID-1

Pour effectuer cette opération, il est important qu'il n'y ait plus d'activité sur l'array.

Donc si c'est l'espace qui retient les partitions de VMs, il faut stopper toutes les VMs avant de faire quoi que ce soit.

Si c'est l'array qui contient le système d'exploitation qui roule sur la machine, il faut redémarrer dans un OS live (par exemple dans stressant) et s'assurer de remettre l'array online, et si nécessaire les volumes LVM aussi.

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. 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.

  6. grossir le LVM:
    • pvresize /dev/md2

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

Réduire un array RAID

Pour effectuer cette opération, il est important qu'il n'y ait plus d'activité sur l'array.

Donc si c'est l'espace qui retient les partitions de VMs, il faut stopper toutes les VMs avant de faire quoi que ce soit.

Si c'est l'array qui contient le système d'exploitation qui roule sur la machine, il faut redémarrer dans un OS live (par exemple dans stressant) et s'assurer de remettre l'array online, et si nécessaire les volumes LVM aussi.

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

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

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
    • l'ajouter dans la définition des array.
      # mdadm --detail --scan | grep md2 >> /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.

Construire un nouvel array

  1. Partitioner le premier disque avec gdisk 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. Formater le nouvel array.
     # mkfs.ext4 /dev/md3 
  5. Ajouter la configuration du nouvel array à /etc/mdadm/mdam.conf
     # mdadm --detail --scan | grep md3 >> /etc/mdadm/mdadm.conf
  6. C'est pas une mauvaise idée de faire un redémarrage du serveur pour être sur que l'array s'active au démarrage.
  7. 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 un exemple d'ajout au fichier /etc/fstab
     UUID=fcecd711-924d-4193-8533-3f7b3ae8bcc7      /home   ext4    defaults        0       2
  8. 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.

  • Si l'array est "désactivé" suite à un redémarrage, on l'active avec la commande suivante:
     # mdadm --assemble /dev/md3 /dev/sdc1 /dev/sdd1

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

Le concept à 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é:

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:

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

complètement supprimer un array

Desfois, il y a des arrays qui se réactive sur les vieux 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.

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

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

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.

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 -av /tmp /tmp2
umount /tmp /tmp2
mount /dev/mapper/data-tmp /tmp
rsync -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)

# 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.

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

# pvcreate /dev/mapper/data_crypt3

# vgextend data /dev/mapper/data_crypt3

# lvextend -rl 100%VG data/srv

# mdadm --detail --scan | grep md5 >> /etc/mdadm/mdadm.conf

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

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  mdadm --detail --scan > /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.

Si vous êtes en mode rescue dans debian le mdadm et situé dans /tmp/mdadm.conf et non pas dans /etc/mdadm/mdadm.conf

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.

Raid setup backup

Le fichier /etc/mdadm.conf peut aider a reconstruire l'array lors de crashes.

Ces configs ont été créées avec:

# echo 'DEVICE /dev/hd*[0-9] /dev/sd*[0-9]' > mdadm.conf
# mdadm --detail --scan >> mdadm.conf 

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:

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:

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:

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é.

References

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:

Hardware Raid

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

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

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

Surveillance

Voir aussi:

References

Le timing

Sur un partition de 10téra:


CategoryDebug CategoryFreebsd

RaidMaintenance (last edited 2019-10-08 10:53:50 by gabriel)