config et perf d'une baie disque eSATA

Le
Nicolas-MICHEL'_remove_'
Bonjour

Je regarde en ce moment pour un gros espace disque pas cher.

Que penser de ceci :

<http://www.technoavenue.com/ds1220.html>
<http://www.datoptic.com/cgi-bin/web.cgi?product=RM12_S2P&detail=yes>
<http://www.caloptic.com/rm12s2p.html>
<http://www.macgurus.com/productpages/sata/Burly8RHS.php>

Une fois équipé de gros disques "Hitashi 1To",
est-ce que serait un genre de san 3x moins cher ?

Peut-on le configurer en raid5 software facilement ?

Et avez-vous des retours d'expériance concerant l'install d'une carte
eSATA ?

Mille merci d'avance :)

--
Nicolas
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Michel Tatoute
Le #1895655
Nicolas MICHEL wrote:

Bonjour

Je regarde en ce moment pour un gros espace disque pas cher.

Que penser de ceci :


Une fois équipé de gros disques "Hitashi 1To",
est-ce que serait un genre de san 3x moins cher ?

Peut-on le configurer en raid5 software facilement ?

Et avez-vous des retours d'expériance concerant l'install d'une carte
eSATA ?

Mille merci d'avance :)




La solution optimale au problème du stockage économique, performant, hot
spare et fiable ne se trouve pas du coté de raid5 sur linux mais du coté de
zfs, et d'une rangée de disques e-sata.

En réalité le raid 5 (et 6) souffre d'un défaut mortel: il s'agit du "trou
de copie". Ce problème est fondamental car les raid classiques travaillent
au niveau partition.

Ils sont contraints de respecter l'adressage physique linéaire des blocs
dans la partition. Ils ignorent quelle place est libre et quelle place est
occupée et donc quand on réécrit un bloc, il ne peuvent pas écrire le
nouveau bloc ailleurs que sur la tranche de blocs précédents dispersés sur
les disques.. Il existe donc toujours un moment ou la somme de contrôle qui
permet en raid 5 de reconstituer un bloc perdu est fausse. si un disque
défaille à cet instant le checksum est faux et donc le bloc (qui contient
plus de données que la simple ecriture faite a cette instant) est mort.

Il y a une solution évidente à ce problème (évidente une fois que l'on a
compris que c'est le niveau partitionnement qui pêche), c'est de faire
contribuer le file system a la gestion du raid. Lui sait très bien quelle
place est libre, où, et comment en optimiser l'usage. Il sait éviter les
zones à pb .. etc. (une autre méthode est de faire du raid hardware, ce que
je n'explique pas: je cherche une solution économique)

Mais....

Il y a des tonnes de brevets sur le sujet. Tous très explicites. Il existe
une société qui détient un pool de ces brevets, pool suffisant pour
implementer un mix file system / raid tout à fait performant, qui tient les
promesses du raid 5 mais bien plus encore: non seulement il résiste à la
perte d'un ou plusieurs disques, mais en fait le nombre de disques qu'on
peut perdre est lié au taux de remplissage. la place libre étant utilisée
pour faire des sommes de controles supplémentaires. En plus ce file system
résiste aux bads blocks (ce que aucun raid classique ne fait) et plein
d'autre propriétés surprenantes. Bref... exactement ce que l'on désire et
même ce qu'on avait pas pensé désirer.

La société est sun et le fs est zfs. Celui ci est implémenté sous open
solaris. Sun a ouvert l'utilisation de zfs aux applications open sources
sans avoir a craindre les brevets, mais la présence de ces brevets interdit
(question de licence) l'intégration de zfs dans le kernel linux. Une
implementation "user space" (avec fuse je crois) est en cours mais à ce
jour elle n'est pas utilisable en production pour cause de performances
catastrophiques (ce n'est pas une conséquence du user space néanmoins,
juste que le portage est complexe). Bref un jour on devrait pouvoir
l'utiliser sous linux.

en attendant le mieux pour un systeme sécurisé est donc de l'implémenter sur
une base open solaris.... en attendant.

Michel.

Michel Tatoute
Le #1895654
Nicolas MICHEL wrote:

Bonjour

Je regarde en ce moment pour un gros espace disque pas cher.

Que penser de ceci :


Une fois équipé de gros disques "Hitashi 1To",
est-ce que serait un genre de san 3x moins cher ?

Peut-on le configurer en raid5 software facilement ?

Et avez-vous des retours d'expériance concerant l'install d'une carte
eSATA ?

Mille merci d'avance :)




La solution optimale au problème du stockage économique, performant, hot
spare et fiable ne se trouve pas du coté de raid5 sur linux mais du coté de
zfs, et d'une rangée de disques sata ou e-sata, chacun avec son alimentation
propre.

En réalité le raid 5 (et 6) souffre d'un défaut mortel: il s'agit du "trou
de copie". Ce problème est fondamental car les raid classiques travaillent
au niveau partition.

Ils sont contraints de respecter l'adressage physique linéaire des blocs
dans la partition. Ils ignorent quelle place est libre et quelle place est
occupée et donc quand on réécrit un bloc, il ne peuvent pas écrire le
nouveau bloc ailleurs que sur la tranche de blocs précédents dispersés sur
les disques.. Il existe donc toujours un moment ou la somme de contrôle qui
permet en raid 5 de reconstituer un bloc perdu est fausse. si un disque
défaille à cet instant le checksum est faux et donc le bloc (qui contient
plus de données que la simple ecriture faite a cette instant) est mort.

Il y a une solution évidente à ce problème (évidente une fois que l'on a
compris que c'est le niveau partitionnement qui pêche), c'est de faire
contribuer le file system a la gestion du raid. Lui sait très bien quelle
place est libre, où, et comment en optimiser l'usage. Il sait éviter les
zones à pb .. etc. (une autre méthode est de faire du raid hardware, ce que
je n'explique pas: je cherche une solution économique)

Mais....

Il y a des tonnes de brevets sur le sujet. Tous très explicites. Il existe
une société qui détient un pool de ces brevets, pool suffisant pour
implementer un mix file system / raid tout à fait performant, qui tient les
promesses du raid 5 mais bien plus encore: non seulement il résiste à la
perte d'un ou plusieurs disques, mais en fait le nombre de disques qu'on
peut perdre est lié au taux de remplissage. la place libre étant utilisée
pour faire des sommes de controles supplémentaires. En plus ce file system
résiste aux bads blocks (ce que aucun raid classique ne fait) et plein
d'autre propriétés surprenantes. Bref... exactement ce que l'on désire et
même ce qu'on avait pas pensé désirer.

La société est sun et le fs est zfs. Celui ci est implémenté sous open
solaris. Sun a ouvert l'utilisation de zfs aux applications open sources
sans avoir a craindre les brevets, mais la présence de ces brevets interdit
(question de licence) l'intégration de zfs dans le kernel linux. Une
implementation "user space" (avec fuse je crois) est en cours mais à ce
jour elle n'est pas utilisable en production pour cause de performances
catastrophiques (ce n'est pas une conséquence du user space néanmoins,
juste que le portage est complexe). Bref un jour on devrait pouvoir
l'utiliser sous linux.

en attendant le mieux pour un systeme sécurisé est donc de l'implémenter sur
une base open solaris.... en attendant.

Michel.

Nicolas-MICHEL'_remove_'
Le #1895608
Michel Tatoute
en attendant le mieux pour un systeme sécurisé est donc de l'implémenter sur
une base open solaris.... en attendant.


Merci pour l'explication :)

--
Nicolas

Publicité
Poster une réponse
Anonyme