Pour la deuxieme (seconde j'espere fois), le remplacement d'une carte
RAID défectueuse sur des serveurs D.LL a entrainée une perte totale des
données !
Bon, ,heureusement on vaiat la sauvegarde de J-1 mais ca fait 2 jours
de boulot de perdus : le travail entre la sauvegarde et la panne + le
temps de reconstruire le serveur !
Question : ce type de probleme est il classique ? Est il lié au type de
matériel utilisé (.ELL) ou à l'incompétence des techniciens qui sont
intervenus (et qui nous ont dit "il y a une chance sur deux de perdre
les données" !)
Le raid/scsi n'est pas gratuit et si il offre aussi peu de fiabilité
(ou plus exactement si il intègre un single point of failure aussi
critique), c'est à désespérer de la technique !
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Emmanuel Florac
Le Fri, 20 Jan 2006 17:00:37 +0000, Alain Montfranc a écrit :
Question : ce type de probleme est il classique ? Est il lié au type de matériel utilisé (.ELL) ou à l'incompétence des techniciens qui sont intervenus (et qui nous ont dit "il y a une chance sur deux de perdre les données" !)
J'ai déjà utilisé ce type de RAID (PERC) et d'autres, je n'ai jamais eu de problème pour passer des disques d'un contrôleur à l'autre et récupérer les données. Peut-être qu'ils ont un nouveau matériel "amélioré" ? :)
-- Les défauts n'apparaissent qu'après que le programme a passé (avec succès) la phase d'intégration. Loi de Klipstein.
Le Fri, 20 Jan 2006 17:00:37 +0000, Alain Montfranc a écrit :
Question : ce type de probleme est il classique ? Est il lié au type de
matériel utilisé (.ELL) ou à l'incompétence des techniciens qui sont
intervenus (et qui nous ont dit "il y a une chance sur deux de perdre les
données" !)
J'ai déjà utilisé ce type de RAID (PERC) et d'autres, je n'ai jamais eu
de problème pour passer des disques d'un contrôleur à l'autre et
récupérer les données. Peut-être qu'ils ont un nouveau matériel
"amélioré" ? :)
--
Les défauts n'apparaissent qu'après que le programme a passé (avec
succès) la phase d'intégration.
Loi de Klipstein.
Le Fri, 20 Jan 2006 17:00:37 +0000, Alain Montfranc a écrit :
Question : ce type de probleme est il classique ? Est il lié au type de matériel utilisé (.ELL) ou à l'incompétence des techniciens qui sont intervenus (et qui nous ont dit "il y a une chance sur deux de perdre les données" !)
J'ai déjà utilisé ce type de RAID (PERC) et d'autres, je n'ai jamais eu de problème pour passer des disques d'un contrôleur à l'autre et récupérer les données. Peut-être qu'ils ont un nouveau matériel "amélioré" ? :)
-- Les défauts n'apparaissent qu'après que le programme a passé (avec succès) la phase d'intégration. Loi de Klipstein.
rejoc
Bonjour
Pour la deuxieme (seconde j'espere fois), le remplacement d'une carte RAID défectueuse sur des serveurs D.LL a entrainée une perte totale des données !
Bon, ,heureusement on vaiat la sauvegarde de J-1 mais ca fait 2 jours de boulot de perdus : le travail entre la sauvegarde et la panne + le temps de reconstruire le serveur !
Question : ce type de probleme est il classique ? Est il lié au type de matériel utilisé (.ELL) ou à l'incompétence des techniciens qui sont intervenus (et qui nous ont dit "il y a une chance sur deux de perdre les données" !)
Le raid/scsi n'est pas gratuit et si il offre aussi peu de fiabilité (ou plus exactement si il intègre un single point of failure aussi critique), c'est à désespérer de la technique !
Qu'en pensez vous ? Une carte RAID est un SPOF... N'est-ce pas la carte qui est tombée en
panne qui a fait de la boullie d'octets (classique si la carte a du cache en écriture) ? Ca n'est pas spécifique à un constructeur particulier. C'est intrinsèque à ce genre de cartes. Elles permettent de pallier la perte d'un disque, pas (toujours) de la carte...
Si vous voulez qq chose de plus fiable, il faut "sortir" le controleur RAID de la machine et qu'il soit doublé/redondant. S'il y a du cache, il faut qu'il soit aussi mis en mirroir entre les 2 controleurs redondants et qu'il soit sauvegardé par une batterie qui devra pouvoir durer aussi longtemps que le courant peut être coupé (ou bien que la batterie soit capable d'alimenter les disques, et les controleurs le temps de vider le cache sur les disques). Ca n'est plus le même prix !
Et n'oublions pas que, malgré les filesystems journalisés, la plus part des OS peuvent aussi véroler des données en cas de crash (souvent encore une histoire de cache (en mémoire de la machine cette fois) vidé "de temps en temps...).
Bonjour
Pour la deuxieme (seconde j'espere fois), le remplacement d'une carte
RAID défectueuse sur des serveurs D.LL a entrainée une perte totale des
données !
Bon, ,heureusement on vaiat la sauvegarde de J-1 mais ca fait 2 jours de
boulot de perdus : le travail entre la sauvegarde et la panne + le temps
de reconstruire le serveur !
Question : ce type de probleme est il classique ? Est il lié au type de
matériel utilisé (.ELL) ou à l'incompétence des techniciens qui sont
intervenus (et qui nous ont dit "il y a une chance sur deux de perdre
les données" !)
Le raid/scsi n'est pas gratuit et si il offre aussi peu de fiabilité (ou
plus exactement si il intègre un single point of failure aussi
critique), c'est à désespérer de la technique !
Qu'en pensez vous ?
Une carte RAID est un SPOF... N'est-ce pas la carte qui est tombée en
panne qui a fait de la boullie d'octets (classique si la carte a du
cache en écriture) ?
Ca n'est pas spécifique à un constructeur particulier. C'est intrinsèque
à ce genre de cartes. Elles permettent de pallier la perte d'un disque,
pas (toujours) de la carte...
Si vous voulez qq chose de plus fiable, il faut "sortir" le controleur
RAID de la machine et qu'il soit doublé/redondant. S'il y a du cache, il
faut qu'il soit aussi mis en mirroir entre les 2 controleurs redondants
et qu'il soit sauvegardé par une batterie qui devra pouvoir durer aussi
longtemps que le courant peut être coupé (ou bien que la batterie soit
capable d'alimenter les disques, et les controleurs le temps de vider le
cache sur les disques). Ca n'est plus le même prix !
Et n'oublions pas que, malgré les filesystems journalisés, la plus part
des OS peuvent aussi véroler des données en cas de crash (souvent encore
une histoire de cache (en mémoire de la machine cette fois) vidé "de
temps en temps...).
Pour la deuxieme (seconde j'espere fois), le remplacement d'une carte RAID défectueuse sur des serveurs D.LL a entrainée une perte totale des données !
Bon, ,heureusement on vaiat la sauvegarde de J-1 mais ca fait 2 jours de boulot de perdus : le travail entre la sauvegarde et la panne + le temps de reconstruire le serveur !
Question : ce type de probleme est il classique ? Est il lié au type de matériel utilisé (.ELL) ou à l'incompétence des techniciens qui sont intervenus (et qui nous ont dit "il y a une chance sur deux de perdre les données" !)
Le raid/scsi n'est pas gratuit et si il offre aussi peu de fiabilité (ou plus exactement si il intègre un single point of failure aussi critique), c'est à désespérer de la technique !
Qu'en pensez vous ? Une carte RAID est un SPOF... N'est-ce pas la carte qui est tombée en
panne qui a fait de la boullie d'octets (classique si la carte a du cache en écriture) ? Ca n'est pas spécifique à un constructeur particulier. C'est intrinsèque à ce genre de cartes. Elles permettent de pallier la perte d'un disque, pas (toujours) de la carte...
Si vous voulez qq chose de plus fiable, il faut "sortir" le controleur RAID de la machine et qu'il soit doublé/redondant. S'il y a du cache, il faut qu'il soit aussi mis en mirroir entre les 2 controleurs redondants et qu'il soit sauvegardé par une batterie qui devra pouvoir durer aussi longtemps que le courant peut être coupé (ou bien que la batterie soit capable d'alimenter les disques, et les controleurs le temps de vider le cache sur les disques). Ca n'est plus le même prix !
Et n'oublions pas que, malgré les filesystems journalisés, la plus part des OS peuvent aussi véroler des données en cas de crash (souvent encore une histoire de cache (en mémoire de la machine cette fois) vidé "de temps en temps...).
