Plusieurs questions à se poser :
NAS ou SAN :
Le NAS est plus simple à mettre en oeuvre, mais il sera plus limité, plus dur à redonder et surtout à migrer plus tard. Vu que ce stockage devra également porter un datastore, il pourrait donc être plus intéressant d'héberger tes données présentées en NFS via une VM linux (par exemple en Fault Tolerant si tu as un cluster VMWare pour une plus haute dispo), ce qui assure également plus de souplesse à terme.
FC ou iSCSI et performances :
En fonction des performances voulues, le choix de la techno est importante. Ici, vu que tu ne veux qu'héberger de la preprod et tes données avec une faible bande passante, le iSCSI en gigabit semble plus que suffisant (possibilité de passer en 10Gb si tu as déjà le matériel, sinon le surcout est important). Prévoir des ports dédiés dans les serveurs (NFS et ESXi) voir des switchs dédiés, ce qui reviendra toujours bien moins cher que des cartes FC et des switchs FC (et du 10Gb). Penser qu'il est possible de gérer un cache NFS coté clients.
Systeme de fichier réseau ou cluster :
Tu mentionnes ici GlusterFS, ce qui annonce une autre approche. Ca peut apporter une meilleure dispo (meme chose que FT sauf protection contre crash OS en supplément) mais par contre apporte de plus grosses contraintes d'administration. Autre piste, GFS marche également pas mal (option payante sous RHEL). Si les termes corum ou fencing ne te parle pas, je te conseille de ne pas partir dans cette voie, sans parler des contraintes ainsi que de la perte de performances importantes (dans ton cas, 100Mb sont facilement atteignables tout de même). Par exemple, sous vmware, le clustering de FS t'empêche tout vmotion, ce qui est quand même pénalisant.
Un système de fichier cluster apporte également des contraintes, tel que le problème de gestion de lock lorsqu'il est exporté en NFS et CIFS. D'ailleurs, dans certains cas, il peut y avoir corruption de données dans un mix cluster FS + NFS + CIFS (voir site de Redhat qui traite bien le sujet).
Systeme de fichiers et arborescence de données :
En fonction de la répartition de tes données sur le FS partagé (arborescence plutot plate ou profonde), un axe d'amélioration important est le choix du FS. Par exemple, XFS peut dans beaucoup de cas apporter un gain de performances important comparé à de l'ext3 (sans compter sa scalabilité en terme de taille). En NFS v4, possibilité d'utiliser les inode64 de XFS au travers de NFS.
Disponibilité :
La haute disponibilité de tes données se passe à 2 niveaux, le service NFS et le stockage.
Pour la partie NFS, elle peut soit être liée au stockage (NAS), gérée par VMWare si utilisation d'une VM pour servir les données (possibilité de Fault Tolerant pour les environnements critiques, fonctionnalité qui se prête bien a un serveur NFS car limité à 1 vCPU) ou encore cluster NFS, en utilisant le clustering Linux qui gère 2 serveurs en actif/passif. De plus, il ne faut pas oublier de prendre en considération le temps du fsck en cas de crash du serveur NFS, qui avantage encore grandement le XFS pour ce type de volumétrie (par contre il faut mettre au moins 4GB de RAM sur le serveur NFS si partition XFS de plus de 2TB).
Pour le stockage, outre le fait que la baie devrait comporter 2 contrôleurs en double attachement avec du RAID5 ou RAID6 si SATA, il faut comparer le temps de restitution de la sauvegarde des données acceptable comparé au surcout d'une réplication des données (réalisée directement par la baie ou par un produit tiers, ce qui revient à doubler - par exemple en faisant du RAID1 logiciel entre 2 baies - voir tripler le cout du stockage si utilisation d'option de réplication de la baie) ou d'une synchronisation périodique sur un autre espace de stockage (lent et peu couteux via un simple rsync par exemple). Ces 2 dernières méthodes ne remplacent pas la sauvegarde mais permettent un temps de reprise plus court en cas de problème.
, je recherche des avis et/ou expérience sur ces différentes solutions afin de faire le meilleur choix.