[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Re: RAID 5 fonctionnel?



(je repèche le post via le waibe : mon doigt a glissé.
 Désolé si le formattage est aléatoire)

Jean-Yves F. Barbier wrote:

> pour plusieurs raisons (d'ailleurs expliquées dans le texte):

Ce n'était pas une question, mais une affirmation. Ceci dit, merci pour
les autres pour le résumé attendu :)


> reste que, quelque soit le système RAID utilisé, cela ne protège pas
> contre des sectors failures (j'ai eu le PB aussi bien en 5 qu'en 10).
> Donc, il *faut* régulièrement sauvegarder les arrays, puis les
> reformater d'une manière sûre (mke2fs -c -c), de façon à éviter un
> kickout de HD parce qu'un secteur aurait un PB (et ça peut être
> TTTlong, surtout avec des HDz 500GB)

Je plussoie. D'autant que badblocks devrait toujours être utilisé avec
un front-end (mke2fs -c -c, comme tu le dis).

>> J'ajouterai même: pourquoi ne pas plutôt envisager une solution
>> *LVM par-dessus des mirroirs RAID1*, _beaucoup_ plus souple ?

> par ce que ça rajoute une couche (logicielle) au RAID, et donc une
> proba de panne plus élevée (j'ai aussi eu le PB: perte de toutes les
> données à cause de LVM au-dessus de RAID).

> Comme d'hab, les meilleures solutions sont toujours les plus simples
> (d'autant que la courbe des probas de pannes a plutôt une tendance
> de type exponentielle que linéaire au fur et à mesure qu'on ajoute des
> couches au bouzin)

Le propos était de remplacer la couche RAID0 par le LVM : il y a plus
de complexité logicielle, mais ajouter / remplacer de l'espace disque,
par exemple lors d'une vérification de disque (=> snapshot, déplacement,
casser le raid1, vérifier les disques, tout remonter dans l'ordre)
devient alors très (enfin, assez) aisé.

Quant à la perte de données citée plus haut, t'es tu interrogé
réellement sur le défaut d'architecture, ou as-tu arrêté l'analyse à
la première cause apparente ?


> LA sécurité restant de toute façon dans une sauvegarde à bande digne
> de ce nom (LTO ou AIT); c'est d'ailleurs le système de plus en plus
> utilisé maintenant: une bandothèque, avec un frontal en HDz (voire
> même, un SSD en frontal des HDz).  Et finalement (à un niveau pro,
> oeuf-corse:), cela n'est pas si cher, ni si lent (~30 sec pour
> charger la bonne bande, et la même chose pour retrouver les données
> avec un LTO).

Ca dépend du fait qu'on utilise ou pas une cochonnerie comme ArcServe :)
Ceci dit, le RAID, c'est pour la continuité de service, pas pour la
sécurité des données, donc les bandes [OUI], avec la rotation
nécessaire. À remplacer par un DD externe si l'usage n'est pas
professionnel.

> Pour le coût, cela met les 800GB (natifs! pas compressés) à ~€45HT;
> et c'est capable de résister aux pires traitements et/ou de partir
> dans un sac à dos pour éviter la perte en cas d'incendie ;-)

Ça, c'est le prix de la LTO, pas selui de l'ensemble...


> SI les fabricants arrivent à péréniser la fiabilité des SSD, tout cela
> ne sera plus qu'un mauvais souvenir à courte échéance.  Mais c'est pas
> gagné d'avance :(

Encore une fois, cela ne remplacera pas les sauvegardes (suppression
accidentelle de fichiers, incendie du site...).

-- 
=== The BOFH Excuse Server ===
Your excuse is: That's a great computer you have there; have you
considered how it would work as a BSD machine?


Reply to: