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.
Nicolas MICHEL wrote:
Bonjour
Je regarde en ce moment pour un gros espace disque pas cher.
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.
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
Nicolas MICHEL wrote:
Bonjour
Je regarde en ce moment pour un gros espace disque pas cher.
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 wrote:
Bonjour
Je regarde en ce moment pour un gros espace disque pas cher.
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.
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_'
Michel Tatoute wrote:
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
Michel Tatoute <tatoute@gmail.com> wrote:
en attendant le mieux pour un systeme sécurisé est donc de l'implémenter sur
une base open solaris.... en attendant.