pour ceux que ça intéresse : une intervention de Kroll Ontrack pour l’otan :
blog.ontrack.fr…
il faut lire la fin pour y voir un bon conseil… 
je ne les oublie pas, j’ai simplement constaté que le logiciel pouvait avoir plus de couac que du matériel. Si on parle de fiabilité, le matériel est accompagné de logiciel (firmware, etc…) dont la configuration a été faite par des pros.
le problèmes des logiciels c’est que leur configuration et leur maintenance est, trop souvent, laissé aux mains pas toujours expertes du personnel de l’entreprise.
car, souvent, le logiciel doit être vérifié, ce que ne font que très rarement les personnes qui sont en charge.
en tout cas, uniquement se reposé sur du niveau de RAID si on cherche réellement de la haute disponibilité, ça reste problématique.
le logiciel, de toute façon, a en optique la volonté de se substituer au cluster, en utilisant peu ou prou les mêmes techno…
pour éviter les baies on peut aussi utiliser ce que MS appelle le “share nothing” permettant de ne pas utiliser de baies mais on se retrouve avec toujours le même problème de la donnée.
je prends un exemple, si tu veux du HA pour ton stockage, et que tu écris beaucoup de données par seconde, ton logiciel est-il paramétrer pour faire de la synchro en live ?
sinon, cela signifie alors que tu peux perdre la donnée entre 2 synchros.
comme dit dans le lien vers Kroll Ontrack , tout dépend du niveau de perte acceptable ET comprise…
la perte de données pouvant couter bien plus cher que le prix du matériel.
tu as surtout 2 cas : le(s) informations qu’on ne peut pas récupérer autrement, celles qui nécessiteraient énormément de temps pour la récupérer (en somme travail en double plus temps imparti)
du coup, si tu as 2000 employés, que tu perds 3 jours de travail, ce n’est pas “très” grave, “suffit” de retravailler 3 jours pour récupérer ce qui a été perdu.
maintenant, si tes 2000 employés sont des ingénieurs, combien vont te couter tes 3 jours… ?
pour l’avoir vécu de nombreuse fois, le logiciel c’est bien lorsqu’il est bien configuré (et parfois entre la configuration par défaut et celle optimale, il y a peu) mais cela peut être une catastrophe s’il ne l’est pas.
ex : un logiciel de surveillance de suppression de fichiers en réseau avait été mis en cluster, malgré que celui-ci n’était pas prévu pour.
la procédure mise en place ne permettait un switch que manuel d’un noeud sur un autre. je suis intervenu pour permettre qu’il soit switchable automatiquement. De ce fait, lorsque des switchs de noeuds se sont produit pendant la nuit, le matin, les fichiers restaient protégés. Alors que ce n’était pas le cas auparavant.
car il fallait que l’équipe informatique arrive, puis constate qu’il y avait eut un switch de noeud pendant la nuit et, qu’enfin, ils corrigent le problème…
les premiers employés arrivant vers 7h/7h30, l’équipe info arrivant vers 8h30 (environ) le problème n’était pas corrigé avant 9h/9h30.
2h pendant lesquels les fichiers n’étaient pas protégés… si c’est acceptable, no souci. dans le cas présent, ça ne l’était pas.
Pourtant il était possible de le faire avec ce logiciel. Il était juste mal configuré.
Par ailleurs, il y a des baies de stockage moyen de gamme sur ce site, n’étant pas dans les attributions du service info de les configurer, cela a toujours été fait conjointement entre des personnes dont c’est le métier (experts) et le constructeur.
tu vois donc pourquoi j’oppose matériel et logiciel ?
Et puis immobiliser un serveur rien que pour la sauvegarde, là pour le coup je trouve que ça tient pas trop la route. Quitte à acheter un autre serveur, faut au moins qu’il puisse devenir actif dans les 5 minutes et le mirroring VSS c’est loin d’être infaillible (pour les bases de données déjà, c’est mort 