• 1To
• 1,5To
• 2To
• 2To

Ce qui me donnait donc en RAID5 : (4-1 disques)*1To = 3To

Le dernier disque de 1To est à remplacer et je me présente donc avec des disques de 1,5To et 2To. On peut donc envisager d’utiliser toute l’espace disponible c’est à dire (4-1 disques)*1,5To=4,5To.

Pourquoi se priver de ces 1,5To supplémentaires sans trop de souci ?

Étapes à suivre pour éviter la perte de données

Voici donc la manip basée en machine virtuelle sur des disques de 10Go, 15Go, et 4 de 20Go. Je change le disque de 10Go pour un 20Go. J’aurai donc 15Go et 5 de 20Go.

1. Vérifier l’état de son raid
2. Vérifier le système de fichier
3. Remplacer le disque dur
4. Augmenter l’array
5. Augmenter le système de fichier

Vérifier l’état de son raid

Vérifier que votre RAID n’a pas de secteur défectueux avant tout!

root@omv:~# cat /sys/block/md0/md/sync_action
idle
root@omv:~# echo check > /sys/block/md0/md/sync_action 
root@omv:~# cat /sys/block/md0/md/sync_action
check

Vous pouvez voir l’état d’avancement du check via mdstat :

root@omv:~# cat /proc/mdstat 
Personalities : [raid6] [raid5] [raid4] 
md0 : active raid5 sdb[6] sdg[5] sdf[4] sde[3] sdd[2] sdc[1]
      52385280 blocks super 1.2 level 5, 512k chunk, algorithm 2 [6/6] [UUUUUU]
      [>....................]  check =  1.0% (108552/10477056) finish=7.9min speed=21710K/sec
      
unused devices: <none>

Les disques du test sont en RAID5 avec 6 disques avec le plus petit de 10Go, donc 50Go sur le RAID.

Vérifier les caractéristiques de votre RAID :

root@omv:~# mdadm --detail /dev/md0
/dev/md0:
        Version : 1.2
  Creation Time : Thu May  7 20:53:42 2015
     Raid Level : raid5
     Array Size : 52385280 (49.96 GiB 53.64 GB)
  Used Dev Size : 10477056 (9.99 GiB 10.73 GB)
   Raid Devices : 6
  Total Devices : 6
    Persistence : Superblock is persistent

    Update Time : Tue May 12 00:14:17 2015
          State : clean 
 Active Devices : 6
Working Devices : 6
 Failed Devices : 0
  Spare Devices : 0

         Layout : left-symmetric
     Chunk Size : 512K

           Name : omv:data  (local to host omv)
           UUID : 66136108:2ba95ce4:6f028202:33e061ea
         Events : 411

    Number   Major   Minor   RaidDevice State
       7       8       96        0      active sync   /dev/sdg
       6       8      112        1      active sync   /dev/sdh
       2       8       32        2      active sync   /dev/sdc
       3       8       48        3      active sync   /dev/sdd
       4       8       64        4      active sync   /dev/sde
       5       8       80        5      active sync   /dev/sdf

Vérifier le système de fichier

Vu que vous aller augmenter le système de fichiers, pensez à le vérifier et corriger les problèmes :

fsck.ext4 -fy /dev/md0

Remplacer le disque dur

Mettez le disque de plus petite taille en fault et retirez le du RAID :

mdadm /dev/md0 -f /dev/sdc
mdadm /dev/md0 -r /dev/sdc

Vous pouvez maintenant retirer physiquement le disque dur pour y mettre le nouveau.

Il ne reste plus qu’à faire un add du nouveau disque et attendre la synchronisation mdadm.

mdadm /dev/md0 -a /dev/sdb

Augmenter l’array RAID mdadm

Une fois que le RAID a été reconstruit suite à l’ajout d’un nouveau disque de 20Go, il reste donc un disque de 15Go et des disques de 20Go. Je peux donc passer de 50Go de RAID à 75Go : 6 disques en RAID5 15Go*5=75Go.

Avec grow on peut soit ajouter un nouveau disque au RAID, soit comme ici prendre en compte que la taille des disques a changé. On peut réduire un array RAID en lui mettant une taille définie, pour supprimer un disque p.e. Mais dans notre cas on veut augmenter au maximum et donc on utilise le mot clé « max » :

root@omv:~# mdadm --grow /dev/md0 --size=max
mdadm: component size of /dev/md0 has been set to 15720448K
root@omv:~# cat /proc/mdstat 
Personalities : [raid6] [raid5] [raid4] 
md0 : active raid5 sdg[7] sdf[5] sde[4] sdd[3] sdc[2] sdh[6]
      78602240 blocks super 1.2 level 5, 512k chunk, algorithm 2 [6/6] [UUUUUU]
      [==============>......]  resync = 73.0% (11488508/15720448) finish=0.9min speed=72246K/sec
      
unused devices: <none>
root@omv:~# cat /proc/mdstat 
Personalities : [raid6] [raid5] [raid4] 
md0 : active raid5 sdg[7] sdf[5] sde[4] sdd[3] sdc[2] sdh[6]
      78602240 blocks super 1.2 level 5, 512k chunk, algorithm 2 [6/6] [UUUUUU]

On voit que l’on passe à 15Go d’espace par disques au lieu de 10Go : 15720448K

On vérifie que l’on dispose bien de 75Go dans notre RAID mdadm :

root@omv:~# mdadm --detail /dev/md0
/dev/md0:
        Version : 1.2
  Creation Time : Thu May  7 20:53:42 2015
     Raid Level : raid5
     Array Size : 78602240 (74.96 GiB 80.49 GB)
  Used Dev Size : 15720448 (14.99 GiB 16.10 GB)
   Raid Devices : 6
  Total Devices : 6
    Persistence : Superblock is persistent

    Update Time : Tue May 12 00:33:14 2015
          State : active 
 Active Devices : 6
Working Devices : 6
 Failed Devices : 0
  Spare Devices : 0

         Layout : left-symmetric
     Chunk Size : 512K

           Name : omv:data  (local to host omv)
           UUID : 66136108:2ba95ce4:6f028202:33e061ea
         Events : 420

    Number   Major   Minor   RaidDevice State
       7       8       96        0      active sync   /dev/sdg
       6       8      112        1      active sync   /dev/sdh
       2       8       32        2      active sync   /dev/sdc
       3       8       48        3      active sync   /dev/sdd
       4       8       64        4      active sync   /dev/sde
       5       8       80        5      active sync   /dev/sdf

Augmenter le système de fichier

On vérifie la taille actuelle avant, ici j’avais 50Go :

root@omv:~# df -h
Sys. fich.                                             Taille Util. Dispo Uti% Monté sur
rootfs                                                   7,6G  1,1G  6,1G  15% /
udev                                                      10M     0   10M   0% /dev
tmpfs                                                    303M  484K  302M   1% /run
/dev/disk/by-uuid/0caa296b-e542-4302-a240-7faaee84af1a   7,6G  1,1G  6,1G  15% /
tmpfs                                                    5,0M     0  5,0M   0% /run/lock
tmpfs                                                    682M     0  682M   0% /run/shm
tmpfs                                                    1,5G     0  1,5G   0% /tmp
/dev/md0                                                  50G  180M   49G   1% /mnt

Et on fait un simple resize2fs et on vérifie que l’on à bien 75Go après.

root@omv:~# resize2fs /dev/md0
resize2fs 1.42.5 (29-Jul-2012)
Le système de fichiers de /dev/md0 est monté sur /mnt ; le changement de taille doit être effectué en ligne
old_desc_blocks = 7, new_desc_blocks = 10
En train d'effectuer un changement de taille en ligne de /dev/md0 vers 19650560 (4k) blocs.
Le système de fichiers /dev/md0 a maintenant une taille de 19650560 blocs.

root@omv:~# df -h
Sys. fich.                                             Taille Util. Dispo Uti% Monté sur
rootfs                                                   7,6G  1,1G  6,1G  15% /
udev                                                      10M     0   10M   0% /dev
tmpfs                                                    303M  484K  302M   1% /run
/dev/disk/by-uuid/0caa296b-e542-4302-a240-7faaee84af1a   7,6G  1,1G  6,1G  15% /
tmpfs                                                    5,0M     0  5,0M   0% /run/lock
tmpfs                                                    682M     0  682M   0% /run/shm
tmpfs                                                    1,5G     0  1,5G   0% /tmp
/dev/md0                                                  74G  180M   74G   1% /mnt

Voilà tout cela a été fait avec le plus de précaution possible afin d’avoir une augmentation de l’espace disque gratuite! Et tout cela en ligne sans interruption de service! Je vous conseille toutefois d’éviter d’avoir de la charge sur le serveur durant l’opération et n’oubliez jamais de faire un backup avant toute modification à votre RAID mdadm!

L’article mdadm augmentation du RAID howto est apparu en premier sur Mon linux.

Un grow mdadm est nécessaire qu’à deux moment. Le premier, vous faite un grow pour remplacer les disques durs existant par ceux de plus grande capacité. Le deuxième, lorsque vous ajouter un nouveau disque dur pour passer de 8To à 10To par exemple et que vous disposer d’un slot libre, chanceux

Mais, l’opération sur le RAID à du être arrêtée par une coupure de courant… Si vous n’êtes pas équipé d’un UPS… Faite le! Mais pour cette fois, voici l’opération :

Voici donc l’état du RAID après redémarrage de la machine :

root@omv:~# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active (auto-read-only) raid5 sdb[0] sdg[5] sdf[4] sde[3] sdd[2] sdc[1]
41908224 blocks super 1.2 level 5, 512k chunk, algorithm 2 [6/6] [UUUUUU]

unused devices: <none>

Pour reprendre le RAID à son état d’augmentation (reshape), voici la commande utilisée :

root@omv:~# mdadm --readwrite /dev/md0
root@omv:~# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 sdb[0] sdg[5] sdf[4] sde[3] sdd[2] sdc[1]
41908224 blocks super 1.2 level 5, 512k chunk, algorithm 2 [6/6] [UUUUUU]
[========>............]  reshape = 40.1% (4207616/10477056) finish=2.2min speed=45568K/sec

Voilà vous êtes sauvé, mais pensez à 3 choses à l’avenir :

• l’utilisation d’un fichier de sauvegarde de l’état du grow mdadm en lisant la suite de l’article
• Équipez vous d’un UPS!
• Mais surtout pensez à sauvegarder vos données essentielles ailleurs! Un RAID n’est en rien une garantie de protection des données! Il permet une tolérance au panne disque, un gain de bande passante, rien de plus.

Source : unix.stackexchange.com

Éviter la perte de données lors d’un grow mdadm

Le reshape lors d’un crash prend du temps et peu ne pas aboutir!

Tout d’abord il faut vérifier l’état de votre RAID mdadm avant de faire un grow! S’il y a un secteur défectueux cela va foirer à tous les coups…

Voici comment vérifier et lancer un check manuel du RAID :

root@omv:~# cat /sys/block/md0/md/sync_action
idle
root@omv:~# echo check > /sys/block/md0/md/sync_action 
root@omv:~# cat /sys/block/md0/md/sync_action
check

Vous pouvez voir l’état d’avancement du check via mdstat :

root@omv:~# cat /proc/mdstat 
Personalities : [raid6] [raid5] [raid4] 
md0 : active raid5 sdb[6] sdg[5] sdf[4] sde[3] sdd[2] sdc[1]
      52385280 blocks super 1.2 level 5, 512k chunk, algorithm 2 [6/6] [UUUUUU]
      [>....................]  check =  1.0% (108552/10477056) finish=7.9min speed=21710K/sec
      
unused devices: <none>

Une fois que c’est vérifié, pour éviter des problèmes lors d’un grow mdadm, le mieux est d’utiliser l’option de fichier de backup :

mdadm --grow --raid-devices=4 --backup-file=/root/grow_md1.bak /dev/md1

Cette option permet de reprendre un grow raid plus surement en cas d’arrêt de la machine.

Source : raid.wiki.kernel.org

Réduire le temps de synchronisation d’un RAID mdadm

Pour réduire le temps de synchronisation d’un RAID5 ou RAID6 mdadm lors d’un resync ou d’un grow, vous pouvez aller vérifier et modifier certains paramètres :

Vitesse min et max de la synchronisation mdadm

# sysctl dev.raid.speed_limit_min
# sysctl dev.raid.speed_limit_max

C’est une valeur en Kio :

• le minimum peut être 50000 pour 50Mo/s
• Le maximum peut être mise à 500000 pour 500Mo/s si votre raid n’est pas utilisé actuellement

Vous gagnez un peu en performance avec ces options :

Façon old school :

echo 50000 > /proc/sys/dev/raid/speed_limit_min
echo 500000 > /proc/sys/dev/raid/speed_limit_max

En utilisant sysctl :

sysctl -w dev.raid.speed_limit_min=50000
sysctl -w dev.raid.speed_limit_max=500000

Vous n’avez qu’à ajouter ces paramètres via le fichier /etc/sysctl.conf pour fixer au redémarrage de la machine.

Augmenter la taille de bloc

Cet option se fait pour chaque périphérique RAID mdadm, donc pour chaque mdX. Il s’agit du paramètre « readahead » qui est défini en bloc de 512 octets :

Pour un bloc de 32Mio :

blockdev --setra 65536 /dev/md0

Augmenter le cache

Pour moi, c’est option qui donne le meilleur résultat : l’optimisation de la taille du cache des tripes mdadm. L’option n’est donc valable que pour les RAID5 et RAID6.

La formule pour la taille est de la forme suivante :

memory_consumed = system_page_size * nr_disks * stripe_cache_size

Un nombre intéressant est 16Mio, si vous ne voulez pas aller plus loin. Voici pour md0 :

# echo 16384 > /sys/block/md0/md/stripe_cache_size

Vous réduirez déjà par 2 le temps de synchronisation comme dans mon cas :

root@omv:~# cat /proc/mdstat 
Personalities : [raid6] [raid5] [raid4] 
md0 : active raid5 sdb[6] sdg[5] sdf[4] sde[3] sdd[2] sdc[1]
      52385280 blocks super 1.2 level 5, 512k chunk, algorithm 2 [6/5] [_UUUUU]
      [======>..............]  recovery = 32.7% (3427852/10477056) finish=9.9min speed=11788K/sec
      
unused devices: <none>
root@omv:~# echo 16384 > /sys/block/md0/md/stripe_cache_size
root@omv:~# cat /proc/mdstat 
Personalities : [raid6] [raid5] [raid4] 
md0 : active raid5 sdb[6] sdg[5] sdf[4] sde[3] sdd[2] sdc[1]
      52385280 blocks super 1.2 level 5, 512k chunk, algorithm 2 [6/5] [_UUUUU]
      [========>............]  recovery = 40.5% (4244444/10477056) finish=4.0min speed=25918K/sec

Source : cyberciti.biz

Avec tout ça, vous êtes sur la bonne voie!

L’article mdadm problème de RAID durant un grow et les optimisations à faire est apparu en premier sur Mon linux.