Bonjour,
J’envisage d’installer une machine avec 2 grappes RAID 1 : 1 pour le système, 1 pour les data.
Imaginons, par le plus grand des malheurs, que ma grappe système soit HS et que je doive réinstaller mon système from scratch, comment la grappe data pourra être reprise dans la nouvelle installation ?
Merci !
Will
Salut,
Si tu perdais les deux disques RAID du système, tu réinstalles un système sur deux nouveaux disques en raid.
Tu boot ton nouveau système sur ta device de raid /dev/md1 que tu as créé durant l’installation.
Ensuite, si tu veux remonter tes disques de datas (imaginons que ce soient /dev/sdc et /dev/sdd) tu dois recréer ta grappe de raid dans un premier temps.
Puis après tu montes la device de raid que tu viens de créer :
mount /dev/md2 /DATAS
Tu pérennises le montage depuis la fstab.
Salut et merci pour la réponse
Question peut être idiote : la phase de recréation de grappe n’altère en rien les données, n’est-ce pas.
Sinon, en bon usage du RAID, est-il nécessaire de créer une grappe système et une grappe data ?
Ou un RAID 1 avec deux disques sys+data suffit amplement, compte tenu de la fiabilité des disques, et que le risque de les voir tomber en même temps est quasi nul ?
[quote=“will7991”]Salut et merci pour la réponse
Question peut être idiote : la phase de recréation de grappe n’altère en rien les données, n’est-ce pas.
Sinon, en bon usage du RAID, est-il nécessaire de créer une grappe système et une grappe data ?
Ou un RAID 1 avec deux disques sys+data suffit amplement, compte tenu de la fiabilité des disques, et que le risque de les voir tomber en même temps est quasi nul ?[/quote]
Non, heureusement que ça n’altère pas les données 
Personnellement, je ne vois pas l’intérêt d’une grappe data et d’une grappe système surtout au niveau du coût. Si tu veux un peu plus de sécurité, tu peux aussi ajouter un disque de spare à ton raid. C’est-à-dire que ton raid tourne en mirroring sur deux disques. Si l’un des deux disques pète, le disque de spare entre en jeu automatiquement. C’est une solution beaucoup plus intéressante que de mettre 4 disques avec deux grappes système + datas.
Après n’oublie pas que le RAID n’est pas une sauvegarde, pense à faire des backup réguliés
Effectivement, la solution du spare me paraît optimale.
Je laisse le topic ouvert durant cette semaine au cas où il y aurait des avis contradictoires (c’est toujours bon à prendre)
N’oublie pas que tu peux configurer mdadm pour qu’il te prévienne par mail dès qu’il détecte une défaillance du raid. Les tests sont à faire avant la mise en production bien sûr.
J’ai zappé cette option de mdadm durant l’installation, je me repose sur smartmontools pour me prévenir.
mdadm est plus fiable/pertinent à ce niveau?
J’ai zappé cette option de mdadm durant l’installation, je me repose sur smartmontools pour me prévenir.
mdadm est plus fiable/pertinent à ce niveau?[/quote]
Ce sont deux outils différents. Ton raid peut avoir un problème alors que le disque est parfaitement sain…
Smartmontools n’en dira rien car c’est un protocole pour suivre et contrôler l’état des disques durs mais pas l’état de ton raid. Il te permet à la rigueur d’anticiper sur une panne imminente d’un disque dur.
Retire un disque de ta machine, smartmontools ne verra aucun défaut (car le disque restant qu’il contrôle est sain) alors que ton raid, lui, est défaillant car il ne fonctionne plus que sur un disque.
Je te conseille vivement de mettre en place l’alerte mail et de faire un test de défaillance avec l’option “–-set-faulty” de mdadm. Si tu reçois le mail c’est ok .
Pour mettre en place l’alerte mail c’est dans le fichier /etc/mdadm/mdadm.conf que ça se passe :
# instruct the monitoring daemon where to send mail alerts
MAILADDR tonadresse@test.com
Ok merci pour les infos. Je testerai.
Par contre, pour la mise en place du spare, est-ce possible via l’installeur Debian ? Ou uniquement en post install ?
[quote=“will7991”]Ok merci pour les infos. Je testerai.
Par contre, pour la mise en place du spare, est-ce possible via l’installeur Debian ? Ou uniquement en post install ?[/quote]
C’est assez simple en lignes de commandes.
De mémoire (mais vérifie, car je n’en suis pas certains du tout), il me semble que l’installeur te demande un truc du style “Number of spare device(s) for RAID1”.
Je ne comprends pas pourquoi on ne considère pas le RAID comme un système de sauvegardes; j’ai 2 DD en RAID1, si un DD crash, les données sont sur l’autre DD.
Si les 2 DD crash, on perd tout mais cette même chose peut se produire sur une machine dédié à du backup non?
[fr.wikipedia.org/wiki/Sauvegarde ... matique%29](http://fr.wikipedia.org/wiki/Sauvegarde_%28informatique%29)
"Aller mettre en sécurité" un objet, c'est le déplacer pour moi. Idem pour les données.
Le RAID permet de la flexibilité. Si un disque pète c'est transparent pour ton client et ça évite une indisponibilité temporaire de ses données.
Si ton serveur est volé ou s'il brûle tu n'as plus rien. Pour moi, sauvegarde signifie externaliser c'est-à-dire que les données doivent être ailleurs que dans le serveur.
Après chacun son point de vue.fr.wikipedia.org/wiki/Sauvegarde … matique%29
“Aller mettre en sécurité” un objet, c’est le déplacer pour moi. Idem pour les données.
Le RAID permet de la flexibilité. Si un disque pète c’est transparent pour ton client et ça évite une indisponibilité temporaire de ses données.
Si ton serveur est volé ou s’il brûle tu n’as plus rien. Pour moi, sauvegarde signifie externaliser c’est-à-dire que les données doivent être ailleurs que dans le serveur.
Après chacun son point de vue.
On dit plutôt que le RAID fournit de la disponibilité car le système et les données restent disponibles (éventuellement de façon dégradée) en cas de défaillance d’un disque.
Sans aller jusquà des événements aussi extrêmes, le RAID ne protège pas contre les erreurs logiques telles que l’effacement accidentel ou intentionnel, la corruption des données ou du système de fichiers…
Je rejoins mes camarades pour dire que le RAID n’est pas une sauvegarde à proprement parler. Cela permet d’augmenter la disponibilité d’un serveur, données et systèmes. Et de réduire au maximum son indisponibilité due à des pannes disques.
Car ton serveur peut tomber en panne pour d’autres raisons (pb électrique, incendie etc…).
Et les contre les effacements accidentels, seule la sauvegarde te permet d’y remédier.
Par ailleurs, jusque là, je ne fais que des sauvegardes de mes données par scripts shell. Mais j’étudie comment sauvegarder la machine entière.
Qu’utilisez vous pour faire vos sauvegardes, système compris ? Clonezilla ?
[quote=“will7991”]Bonjour,
J’envisage d’installer une machine avec 2 grappes RAID 1 : 1 pour le système, 1 pour les data.
Imaginons, par le plus grand des malheurs, que ma grappe système soit HS et que je doive réinstaller mon système from scratch, comment la grappe data pourra être reprise dans la nouvelle installation ?
Merci !
Will[/quote]
4 disques de disponible, plutôt que monté deux grappes en RAID 1 je verrai plutôt une grappe en RAID 5 et un disque de ‘spare’, tu gagnera en performance et gardera de la disponibilité correct contre la perte de donnée.
Pas sûr que les performances soient meilleures si le système et les données sont sur la même grappe, surtout en écriture avec du RAID 5.
Il semblerait que les meilleures performances soient obtenues en RAID 10 avec miroir+agrégation par bandes.
[quote=“PascalHambourg”]Pas sûr que les performances soient meilleures si le système et les données sont sur la même grappe, surtout en écriture avec du RAID 5.
Il semblerait que les meilleures performances soient obtenues en RAID 10 avec miroir+agrégation par bandes.[/quote]
Je confirme que les performances seront bien meilleur en RAID 10 mais le prix n’est pas le même. malgré tout je pense que les performances tant en lecture qu’en écriture seront acceptables sur du RAID 5.
Les IOP seront bien meilleur sur un RAID 5 adéquat (en SAS en tout cas voir en SSD)
Un petit résumé récupéré pendant une formation sur la virtualisation que j’ai suivi il y a peu :
[quote]Chaque disque peut délivrer un nombre donnée I/O par seconde, en fonction des
parametres suivants:
Raid level Read Write
RAID 0 1 1
RAID 1(10) 1 2
RAID 5 1 4
RAID 6 1 6
Et afin de compliquer encore un peu les choses, la pénalité due au raid ne s’applique
que sur les écritures (voir tableau ci dessus) et le rapport entre nombre d’accès
read/write dépend également de l’usage de chacun.
La formule suivante permet de calculer le nombre d’IOPS réel d’une VM ou d’un
serveur ESX coté baie de stockage:
(Total Workload IOPS * % moyen de Read IO) + (Total Workload IOPS * % moyen de
Write IO * Penalité due au RAID)
disons qu’une VM a une moyenne de 50IOPS , 40% en read 60% en write et que l’on a
une baie en RAID 5 (pénalité 4 en write)
(500.4)+(500.6*4)= 140 IOPS
Donc cette VM générant 50IOPS coté hyperviseur va en réalité en générer 140 coté
baie de stockage!
On comprend donc tout de suite qu’a-fin de maximiser le nombre d’IOPS il convient
plutôt de trouver le juste équilibre entre performance IO individuelle des
disques/taille des disques/niveau de raid , plutot que de se dire simplement qu’il vaut
mieux prendre les plus gros disques possibles, et ceux qui tournent le plus vite.
Ci dessous une table des IOPS généralement constatées par type de disque:
RPM IOPs
SSD 6000
15K 175
10K 125
7200 75
5400 50
Il est donc primordial de connaitre son infrastructure virtuelle et surtout de bien
comprendre ce qui s’y passe au niveau IO, principalement quand on utilise des
disques non SSD. C’est une clé essentielle pour obtenir de bonnes performances
globales.[/quote]
Avec 4 disques dont deux en redondance ou spare, dans les deux cas le prix est le même ainsi que la tolérance. Certes la solution en RAID 5 a un disque de spare mais la reconstruction est plus rapide en RAID 10 car il n’y a pas de recalcul de parité.
Salut à tous,
J’ai modifié mon topic car c’est devenu assez général (et de plus en plus intéressant 
)
A titre perso, j’ai opté pour 3 disques, RAID 1 de deux disques + 1 spare. Ça devrait faire l’affaire. Mais il est vrai, comme indiqué dans une doc que j’ai trouvée sur le net (faut que je retrouve le lien), que beaucoup de serveurs sont maintenant configurés avec 2 disques RAID 1 pour la partie système, et du RAID5 à trois disques pour les data. Intéressant, mais j’aurais été hors budget.
Je poursuis avec une question d’ordre pratique : j’ai constaté que le device raid sur lequel j’ai mis la racine (md7 chez moi) n’apparaît pas comme tel quand je fais un “df”. Au lieu de ça, je vois deux fois “/”, une indiquant “rootfs” et une indiquant “/dev/disk/by-uuid/XXXX”.
Sys. fich. 1K-blocks Util. Disponible Uti% Monté sur
rootfs 194425180 3840020 180708944 3% /
udev 10240 0 10240 0% /dev
tmpfs 787980 788 787192 1% /run
/dev/disk/by-uuid/4f6810a8-45ab-4dca-89be-8ffc3c8445d5 194425180 3840020 180708944 3% /
Un mdadm -D /dev/md7 ne m’indique aucune erreur.
[code]/dev/md7:
Version : 1.2
Creation Time : Mon Nov 24 17:08:11 2014
Raid Level : raid1
Array Size : 197524352 (188.37 GiB 202.26 GB)
Used Dev Size : 197524352 (188.37 GiB 202.26 GB)
Raid Devices : 2
Total Devices : 3
Persistence : Superblock is persistent
Update Time : Tue Nov 25 11:34:35 2014
State : clean
Active Devices : 2
Working Devices : 3
Failed Devices : 0
Spare Devices : 1
Name : Z
UUID : X
Events : 25
Number Major Minor RaidDevice State
0 8 3 0 active sync /dev/sda3
1 8 19 1 active sync /dev/sdb3
2 8 35 - spare /dev/sdc3
[/code]
Ca vous semble normal ?
Oui, si tu veux de la redondance. Mais le coût est élevé puisque seulement un tiers de la capacité totale est disponible.
Pour le même coût tu aurais pu opter pour du RAID 1 avec trois disques actifs, sans spare. Avantage : tolérance immédiate à la perte de deux disques sans attendre la reconstruction sur le spare.
Inconvénient : un disque actif est plus sujet à l’usure et à la panne qu’un disque en spare. Un peu si le RAID sert surtout en lecture (les données ne sont lues que sur un disque à la fois), plus s’il sert beacoup en écriture (les données sont écrites sur tous les disques à la fois).
Tu peux en faire autant avec trois disques sans spare, donc avec le même budget. Et la capacité utile sera supérieure à du RAID 1 seul.
C’est habituel. rootfs est un reste de la racine initiale en RAM (initramfs) montée dans la première phase du démarrage avant la racine finale qui est ensuite montée par dessus. La spécification de la racine et des autres systèmes de fichiers par un identificateur persistant comme l’UUID est devenue la règle depuis que le nommage des disques et des partitions est devenu plus fluctuant. Cf. /etc/fstab. Néanmoins cela ne devrait pas être nécessaire pour les volumes RAID et autres LVM qui ont leurs propres UUID en interne et ne sont donc pas sujets à ce nommage fluctuant.
(Edition pour correction de trop nombreuses fautes)