Solution 1 :
Je vote pour NFS.
NFSv4.1 a ajouté la fonctionnalité Parallel NFS pNFS, qui rend possible l'accès parallèle aux données. Je me demande quel type de clients utilisent le stockage si seulement de type Unix, alors j'opterais pour NFS en fonction des chiffres de performance.
Solution 2 :
La réponse courte est d'utiliser NFS. D'après cette fusillade et ma propre expérience, c'est plus rapide.
Mais, vous avez plus d'options ! Vous devriez envisager un cluster FS comme GFS, qui est un système de fichiers auquel plusieurs ordinateurs peuvent accéder en même temps. Fondamentalement, vous partagez un périphérique bloc via iSCSI qui est un système de fichiers GFS. Tous les clients (initiateurs dans le jargon iSCSI) peuvent y lire et y écrire. Redhat a un livre blanc. Vous pouvez également utiliser le cluster FS OCFS d'Oracle pour gérer la même chose.
Le document Redhat fait un bon travail en répertoriant les avantages et les inconvénients d'un cluster FS vs NFS. Fondamentalement, si vous voulez beaucoup d'espace pour évoluer, GFS en vaut probablement la peine. De plus, l'exemple GFS utilise un SAN Fibre Channel comme exemple, mais cela pourrait tout aussi bien être un SAN RAID, DAS ou iSCSI.
Enfin, assurez-vous d'examiner les trames Jumbo, et si l'intégrité des données est critique, utilisez la somme de contrôle CRC32 si vous utilisez iSCSI avec des trames Jumbo.
Solution 3 :
Nous disposons d'un cluster Web à 2 serveurs de charge. Nous avons essayé les méthodes suivantes pour synchroniser le contenu entre les serveurs :
- Disques locaux sur chaque serveur synchronisés avec RSYNC toutes les 10 minutes
- Un CIFS central (SAMBA) partager sur les deux serveurs
- Un NFS central partager sur les deux serveurs
- Un lecteur SAN partagé exécutant OCFS2 monté les deux serveurs
Le RSYNC La solution était la plus simple, mais il a fallu 10 minutes pour que les modifications s'affichent et RSYNC a mis tellement de charge sur les serveurs que nous avons dû l'étrangler avec un script personnalisé pour le mettre en pause à chaque seconde. Nous étions également limités à écrire uniquement sur le lecteur source.
Le disque partagé le plus performant était OCFS2 lecteur en cluster jusqu'à ce qu'il devienne fou et plante le cluster. Nous n'avons pas été en mesure de maintenir la stabilité avec OCFS2. Dès que plusieurs serveurs accèdent aux mêmes fichiers, la charge monte en flèche et les serveurs commencent à redémarrer. Il peut s'agir d'un échec de formation de notre part.
Le meilleur suivant était NFS . Il a été extrêmement stable et tolérant aux pannes. Ceci est notre configuration actuelle.
PME (CIFS) avait des problèmes de verrouillage. En particulier, les modifications apportées aux fichiers sur le serveur SMB n'étaient pas vues par les serveurs Web. SMB avait également tendance à se bloquer lors du basculement du serveur SMB
Notre conclusion était que OCFS2 a le plus de potentiel mais nécessite BEAUCOUP d'analyses avant de l'utiliser en production. Si vous voulez quelque chose de simple et fiable, je vous recommande un cluster de serveurs NFS avec Heartbeat pour le basculement.
Solution 4 :
Je vous suggère POHMELFS - il a été créé par le programmeur russe Evgeniy Polyakov et il est vraiment très rapide.
Solution 5 :
En termes de fiabilité et de sécurité, probablement CIFS (alias Samba) mais NFS "semble" beaucoup plus léger, et avec une configuration soignée, il est possible de ne pas exposer complètement vos précieuses données à toutes les autres machines du réseau;-)
Aucune insulte aux trucs FUSE, mais ça semble toujours ... frais, si vous voyez ce que je veux dire. Je ne sais pas si je lui fais encore confiance, mais cela pourrait simplement être le fait que je sois un vieux brouillard, mais le vieux brouillard est parfois justifié lorsqu'il s'agit de données d'entreprise précieuses.
Si vous souhaitez monter en permanence un partage sur plusieurs machines et que vous pouvez jouer avec certaines bizarreries (principalement des problèmes UID/GID), utilisez NFS. Je l'utilise, et ce depuis de nombreuses années.