Archivage pro: bande VS disque
Le
Olivier B.
Salut,
*version courte*
je n'arrive par à trouver de stat me permettant de comparer la
pérénité des donnés entre un support LTO3/4 et une grappe raid6 de 10
disques, merci pour toute aide
*version longue*
En tant que pro nécéssitant d'acquerir des resources d'archivage (on
génère + de 1To/mois) on a établi un CC dans lequel on s'appuie sur du
disque + de la bande, le disque (12To) pour conserver en NOL une
certaine profondeur de médias que l'on sait susceptible d'etre
reutilisé dans les 1 ans apres leur fabrication, la bande (70To
extensibles) pour prolonger à moindre cout sachant que par sécurité
tout ce qui est sur le NOL par immediatement sur la bande.
nous somme un petit peu ennuyés car certains integrateurs et
constructeurs nous proposent une solution totalement disque hors j'ai
toujours pensé que c'etait un bon moyen de perdre beaucoups de données
en une seule fois comme par exemple perte de 2 disques sur une grappe
raid5, cepandant le constructeur s'est voulu rassurant en avancant
comme argument que:
1 - le systeme s'appuie sur des grappe de stockages limitées à 10
disques en raid6 ce qui reduit fortement le risque de perdre une
grappe puisque il faut 3 disque HS sur 10
2 - le systeme virtualise l'ensemble des grappes en un FS segmenté
dont l'intégrité générale est insensible à la perte d'une grappe,
seules les donnés présentes sur le grappe sont perdues
3 - le volume est extentible à volonté par ajout de grappe, le maximum
actuellement gérable est de plusieurs Po.
4 - l'ensemble fonctionne sous Linux et est donc insensibles aux
attaques virales µsoft
5 - l'ensemble est plus fiable qu'un robot car ne présentant pas les
faiblesses mecanisques de ces derniers.
Je repart à l'inverse pour donner mon avis personnel:
le 5 m'est indiférent car l'intégrité des donnés n'est pas impacté par
une panne mécanique, et ce point prime par rapport à la dispo sachant
qu'on a le NOL pour "vivre" en attendant le depannage
le 4 me rassure moyennement, qui peut écarter le scenario d'un code
ciblant spécifiquement les stockages Linux ?
Le 3 présente une évolutivité supérieure à la bande dans la gamme de
produit qui nous est accéssible, sauf à virtualiser plusieurs robots
avec une solution type active circle
Le 2 ne m'apparait pas comme un avantage par rapport à bande
Le point 1 me pose probleme, je n'arrive par à trouver de stat en la
matière me permettant de relativier la pérénité des donnés entre un
support LTO3/4 et une grappe raid6 de 10 disques, hors c'est bien
cette pérénité qui nous importe.
Enfin un point négatif m'apparait, la consommation, la solution bande
est bien moins couteuse en terme energetique (conso/clim).
Je suis donc preneur de tout vos avis éclairés
--
pas de turlututu. apres l'@robase
*version courte*
je n'arrive par à trouver de stat me permettant de comparer la
pérénité des donnés entre un support LTO3/4 et une grappe raid6 de 10
disques, merci pour toute aide
*version longue*
En tant que pro nécéssitant d'acquerir des resources d'archivage (on
génère + de 1To/mois) on a établi un CC dans lequel on s'appuie sur du
disque + de la bande, le disque (12To) pour conserver en NOL une
certaine profondeur de médias que l'on sait susceptible d'etre
reutilisé dans les 1 ans apres leur fabrication, la bande (70To
extensibles) pour prolonger à moindre cout sachant que par sécurité
tout ce qui est sur le NOL par immediatement sur la bande.
nous somme un petit peu ennuyés car certains integrateurs et
constructeurs nous proposent une solution totalement disque hors j'ai
toujours pensé que c'etait un bon moyen de perdre beaucoups de données
en une seule fois comme par exemple perte de 2 disques sur une grappe
raid5, cepandant le constructeur s'est voulu rassurant en avancant
comme argument que:
1 - le systeme s'appuie sur des grappe de stockages limitées à 10
disques en raid6 ce qui reduit fortement le risque de perdre une
grappe puisque il faut 3 disque HS sur 10
2 - le systeme virtualise l'ensemble des grappes en un FS segmenté
dont l'intégrité générale est insensible à la perte d'une grappe,
seules les donnés présentes sur le grappe sont perdues
3 - le volume est extentible à volonté par ajout de grappe, le maximum
actuellement gérable est de plusieurs Po.
4 - l'ensemble fonctionne sous Linux et est donc insensibles aux
attaques virales µsoft
5 - l'ensemble est plus fiable qu'un robot car ne présentant pas les
faiblesses mecanisques de ces derniers.
Je repart à l'inverse pour donner mon avis personnel:
le 5 m'est indiférent car l'intégrité des donnés n'est pas impacté par
une panne mécanique, et ce point prime par rapport à la dispo sachant
qu'on a le NOL pour "vivre" en attendant le depannage
le 4 me rassure moyennement, qui peut écarter le scenario d'un code
ciblant spécifiquement les stockages Linux ?
Le 3 présente une évolutivité supérieure à la bande dans la gamme de
produit qui nous est accéssible, sauf à virtualiser plusieurs robots
avec une solution type active circle
Le 2 ne m'apparait pas comme un avantage par rapport à bande
Le point 1 me pose probleme, je n'arrive par à trouver de stat en la
matière me permettant de relativier la pérénité des donnés entre un
support LTO3/4 et une grappe raid6 de 10 disques, hors c'est bien
cette pérénité qui nous importe.
Enfin un point négatif m'apparait, la consommation, la solution bande
est bien moins couteuse en terme energetique (conso/clim).
Je suis donc preneur de tout vos avis éclairés
--
pas de turlututu. apres l'@robase
Poser une question
'lut,
Perso j'ai déjà restauré des données sur bande de 4 à 5 ans: RAS. En général
il est annoncé 20 ans de tenue, je ne serais pas étonné de pouvoir restaurer
de la bande âgée de 10 ans.
J'ai aussi du disque qui tourne depuis plus de 5 ans sans broncher, mais les
cas de mort entre 5 et 10 risquent de ne pas être symboliques.... (me fait
penser que j'ai un disque de 6 ans dans mon "serveur", il faudrait vraiment
que je le remplace ;-D )
.....
Je me demande jusqu'a quel point un constructeur peut réellement tester son
produit en production .....
Je suis trop habitué à voir des trucs merveilleux en démo qui finalement ne
tiennent pas le choc lors d'une utilisation réelle :-/
.....
.....
C'est clair , car il y aura certainement dans le réseau des machines ayant
un accès aux données et reposant sur des OS soit fragiles, soit non à jour.
Se croire insensible aux virus parce que l'on est sous linux ou sous mac os
est foireux comme raisonnement. Surtout que les virus détruisant les données
on n'en voit plus guère il me semble ?
Combien de fois restaure-t-on des données suite à un pb de virus ? Combien
de fois suite à un soucis de disque ? Et combien de fois pour cause d'erreur
humaine ?
Chez moi le troisième cas est largement en tête dans les stats, et chez toi
? ;-)
.....
C'est vrai qu'on ne pense pas toujours à inclure le cout énergétique dans le
prix de revient .
De toute façon si tu donne une importance prépondérante au budget la bande
est bien partie pour arriver en tête vu tes volumétries .
Je ne suis pas forcément très éclairé, mais je reste persuadé que pour de
l'archivage sur du long terme la bande est plus fiable que le disque. A la
condition de stocker les bandes dans un environnement adapté et contrôlé (tu
ne coupera pas au besoin d'une clim ;-D )
a voté !
PS: CC j'imagine que chez toi c'est comme CdC chez moi ? Mais "NOL" ?? Nas
On Line ?
--
Eric
Reply-to valide, laissez tel quel !
Texte brut vivement conseillé !!
Mouais. C'est quoi cette solution? Ça ressemble à de l'Isilon mais Isilon
c'est du BSD, pas du Linux. XIV utilise plutôt un genre de RAID-10
merdique(*), et Exanet est mort(**), et puis ne supporte pas la perte
d'une grappe. Du DDN? Le S2A10000 est à peine sorti de l'alpha...
douleur.
Évidemment pas. On ne peut surtout pas écarter l'erreur ou la
malveillance : "rm -rf /mnt/grosraid/*"
Active Circle marche assez bien mais pas pour tout. Je ne vois pas en
quoi le disque peut être plus évolutif que la bande, c'est généralement
le contraire; un logiciel d'archivage comporte une base de données qui
indexe l'ensemble des bandes, et si les accès sont rares ou
exceptionnels, tu n'as aucun besoin d'avoir plusieurs robots : un robot
et une armoire fermant à clef suffisent. Par ailleurs un robot 40 slots
coûte moins de 10000 euros, et par exemple tu peux stacker les Tandberg
T40+ par trois, pour faire un T120 (120 x 800Go natifs en LTO4, soit 93
To. Sur un simple serveur aussi d'ailleurs on peut faire 80 To utiles...
Une grappe RAID 6 de 10 disques est très fortement résiliente, néanmoins
il arrive qu'un contrôleur RAID grille et débloque en écrivant de la
bouillie sur les structures du filesystem... Dans tous les cas un RAID de
disques est un système actif, et en tant que tel il présente toujours
plus de risques qu'une bande qui est passive tant qu'elle n'est pas dans
le lecteur, à moins d'être rangée à côté d'un aimant :)
Je considère qu'un RAID-6 bien construit a un taux de panne conduisant à
une indisponibilité de 0% sur 3 ans, et probablement sur 5 ans (mais je
n'ai pas suffisamment de recul pour l'affirmer). Je parle toutefois
uniquement de problèmes matériels; les problèmes logiciels sont bien plus
fréquents, les erreurs humaines encore davantage.
Les bandes sont très sûres si on les écrit en une fois et qu'on ne les
lit qu'une fois. Le taux de panne augmente très rapidement quand le taux
d'utilisation augmente (entre 3 et 5% par an, à peu près comme les
disques). Pour les données sensibles il est impératif de faire deux
bandes en parallèle et de n'en utiliser qu'une seule.
Oui c'est évident, au point de vue énergétique même le disque MAID
consomme beaucoup plus que la bande. Tout dépend de la fréquence
d'utilisation des données.
Bref je résumerais en disant : le débat disques/bandes (ou un mix des
deux) se tranche selon l'utilisation faite des données et le taux de
sûreté demandé. Si les données sont accédées fréquemment, il est bien
plus commode de les avoir sur disques. Mais les données sur disques ne se
substituent en aucun cas à la bande, parce qu'elles sont toujours en
danger, un RAID n'est jamais un backup; si tu veux un backup sur disques,
alors tu dois avoir deux systèmes de disques, un actif et l'autre passif
(contenant une copie des données mais non utilisé).
Si tu veux on peut avoir une discussion sérieuse là dessus demain, en
parlant plus précisément des besoins et des traitements effectués sur les
données, appelle moi en fin d'après-midi au bureau chez intellique (01 78
94 84 00).
(*) J'ai écrit un post très méchant sur XIV mais je ne l'ai jamais
publié :)
(**) faudra que je pense à écrire un post méchant sur exanet, c'est
proche de l'arnaque ce truc :)
--
Désormais, pour les nations et pour les peuples, une goutte de pétrole
a la valeur d'une goutte de sang.
Georges Clémenceau.
hp scalout NAS, blocs de 82 disques, 2 spares + 4 raid 6 sur 10
disques, le tout intégré dans un FS segmenté.
erreur et malveillance sont le dernier de mes soucis, les gens
potentiellement malveillant n'ont pas un acces admin ni physique
certes, coté Nas il faut pouvoir installer l'agent dessus et il faut
que les librairies bandes soient validée avec leur solution, mais cela
nous convient
"dans la gamme de produit qui nous est accessible", voir cout d'un
robot scalable à 5Po...
on veut éviter à tout prix d'externaliser les bandes
oui par exemple
on est bien d'acord
hum, je pense qu'il faut remplacer "considère" par "observe", c'est
ton experience pour autant on ne peut la généraliser, perso apres 6
mois de fonctionnement un nas de 16To (carte Areca) s'est mis à
débloquer, pb d'io sur un disque, puis 2, au 3eme la grappe est passé
offline, on est passé tres proche de la perte de donnés, il a fallu
reconstruire grappe et volumes avec l'option "ne pas toucher aux data"
afin de récupérer l'accès, bilan des courses update de la carte raid
et changement des disques, plus un gros coups de chaud car on a failli
perdre des donnés irremplacables et couteuses.
on y a gouté, j'ai revu singulièrement certains stratégies d'accès.
on y pense, sur un site distant afin d'obtenir de la redondance
geographique.
les donnés frequement accédées resteraient sur des nas NOL (near
online) afin de pouvoir basculer rapidement sur l'espace de prod
(SAN), la bande ne serait pas beaucoups sollicitée
yep
merci pour la proposition mais je prefere que l'on reste ici, il n'y a
pas de traitement spécifique des donnés en archivage, ce sont de gros
fichiers vidéos, par contre en restauration on peut avoir une fonction
partial restore qui nécéssite une implementation spécifique comme chez
diva, ceci étant en roadmap chez certains comme AC
A+
--
pas de turlututu. apres l'@robase
yep
oui c'est une veritable techno pro, je n'ai aucune nostalgie en
pendant au DAT, cepandant je n'ai pas retrouvé dans les solutions qui
nous sont accessibles une fonction présente sur Petasite: scrutation
régulère des bandes, régénération et recopie en cas de montée du taux
d'erreur.
j'ai grosso modo une centaine de disques entre SAN NAS serveurs, il
est vrai que le taux de panne observé est faible, moins de 1 disque
par an malgres quelques coups de chaud pour cause de clims
défaillantes.
hé hé hé, il n'est pas rare de voir dans les salon des démo qui
relèvent plus de l'assemblage powerpoint que d'un process fonctionnel,
c'est une raison pour laquelle je ne tiens pas compte des
fonctionnalité annoncée en roadmap
non, mais le potentiel est là, et en matière de sécurité je prefere
tenir compte de scénarios improbables étant donné qu'il y a gros à
perdre derriere.
aussi, à ceci pres que l'erreur humaine est prévisible, du fait de la
nature humaine d'une part, du fait que l'on connait certains zigoto
avec qui on bosse de l'autre, mais ces erreurs sont hors du périmètre
de mon "dossier archivage" car aucun utilisateur n'aura le droit de
supprimer de l'archive, au pire un média n'y entrera pas mais une fois
qu'il y sera il n'y a pas de scenario de peste massive de donnés par
faute d'un utilisateur.
certes, mais consommant largement moins que pour du disque, sauf
qu'avec la bande on a une contrainte supplementaire d'humidité
merci pour ta contribution
Near Online, autrement dit entre l'espace de production (SAN avec
grosse capacité en I/O) et la bande on place un gros cache (NAS avec
grosse capacité) dans lequel les donnés placées sur bande restent en
fonction de règles.
--
pas de turlututu. apres l'@robase
Si je ne m'abuse c'est du Polyserve? Je ne parierais pas trop sur
l'évolutivité a posteriori réelle du bouzin, enfin, ils l'ont sans doute
amélioré depuis que je l'ai testé en 2006 ou 2007.
Il faut voir, si tu veux acheter un stockage que tu agrandis au fur et à
mesure, il y a un gros surcoût initial par rapport à un stockage plus
"simple" mais moins (ou pas) évolutif.
De mon expérience, aujourd'hui le seul stockage réélement évolutif en
ligne, à chaud, sans limite et sans douleur, c'est Isilon. C'est
verrouillé jusqu'au trognon, c'est cher, c'est très peu dense mais ça
marche. Je dis ça mais ce sont mes pires ennemis :)
Mouais, qui n'a jamais mis un caractère malvenu dans un "rm -rf " ne sait
pas ce qu'est la paranoïa...
La performance d'active circle va de très basse à médiocre. Enfin tout
dépend des besoins...
Personnellement j'ai monté deux clusters de 120 To en exploitation
d'archive pour une très grosse application broadcast depuis deux ans et
ça se passe bien, mais là encore : c'est un cas particulier, ça ne
conviendrai pas forcément à tout le monde...
Comment sécuriser le backup dans ce cas? incendie? inondation?
Certes, cependant j'ai conçu, fabriqué et installé plusieurs centaines de
NAS depuis 5 ans donc je parle sur un recul de plusieurs centaines de
contrôleurs RAID/plusieurs milliers de disques en service.
Oui c'est indispensable.
C'est ce qu'il faut. Après la question est : combien de stockage tu
achètes avec ton budget :)
Une vraie fonction HSM tu veux dire? Il y a ça aussi chez Atempo
apparemment. Quel est le cheminement des données envisagé?
--
The fact that a believer is happier than a sceptic is no more to the
point than the fact that a drunken man is happier than a sober one.
The happiness of credulity is a cheap and dangerous quality.
George Bernard Shaw