Quel protocole de partage de fichiers réseau offre les meilleures performances et fiabilité?
Nous avons une configuration avec quelques serveurs Web à équilibrage de charge. Nous voulons avoir une sorte de stockage partagé en réseau auquel tous les serveurs Web peuvent accéder. Il sera utilisé comme un endroit pour stocker les fichiers téléchargés par les utilisateurs. Tout tourne sous Linux.
Faut-il utiliser NFS, CIFS, SMB, Fuse + sftp, Fuse + ftp? Il existe tellement de choix pour les protocoles de partage de fichiers réseau, il est très difficile d'en choisir un. Nous souhaitons simplement monter de façon permanente ce partage sur plusieurs machines. Les fonctionnalités de sécurité sont moins préoccupantes car elles ne seront pas accessibles sur le réseau ailleurs que sur les serveurs qui les montent. Nous voulons juste qu'il fonctionne de manière fiable et rapide.
Lequel devrions-nous utiliser?
Je vote pour NFS.
NFSv4.1 a ajouté la capacité 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 comme Unix, je choisirais NFS en fonction des performances.
La réponse courte est d'utiliser NFS. D'après cela shootout et ma propre expérience, c'est plus rapide.
Mais, vous avez plus d'options! Vous devriez considérer un cluster FS comme GFS, qui est un système de fichiers auquel plusieurs ordinateurs peuvent accéder à la fois. Fondamentalement, vous partagez un périphérique de bloc via iSCSI qui est un système de fichiers GFS. Tous les clients (initiateurs dans iSCSI langage) peut lire et écrire dessus. Redhat a un livre blanc . Vous pouvez également utiliser le cluster d'Oracle FS OCFS pour gérer la même chose.
Le document redhat fait un bon travail répertoriant les avantages et les inconvénients d'un cluster FS vs NFS. Fondamentalement, si vous voulez beaucoup d'espace à l'échelle, GFS en vaut probablement la peine. En outre, le GFS exemple utilise un Fibre Channel SAN comme exemple, mais qui pourrait tout aussi bien être un RAID, DAS ou iSCSI SAN.
Enfin, assurez-vous de regarder dans 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 les trames Jumbo.
Nous avons un cluster Web à répartition de charge sur 2 serveurs. Nous avons essayé les méthodes suivantes pour synchroniser le contenu entre les serveurs:
- Les disques locaux sur chaque serveur synchronisés avec RSYNC toutes les 10 minutes
- Un partage central CIFS (SAMBA) sur les deux serveurs
- Un partage central NFS sur les deux serveurs
- Un lecteur partagé SAN exécutant OCFS2 a monté les deux serveurs
La solution RSYNC était la plus simple, mais il a fallu 10 minutes pour que les modifications apparaissent et RSYNC a mis tellement de charge sur les serveurs que nous avons dû l'accélérer avec la personnalisation script pour le mettre en pause chaque seconde. Nous étions également limités à écrire uniquement sur le lecteur source.
Le lecteur partagé le plus performant était le lecteur en cluster OCFS2 jusqu'à ce qu'il devienne fou et plante le cluster. Nous n'avons pas pu maintenir la stabilité avec OCFS2. Dès que plusieurs serveurs accèdent aux mêmes fichiers, la charge monte à travers le toit et les serveurs commencent à redémarrer. Cela peut être 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.
SMB (CIFS) a eu quelques 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 SMB
Notre conclusion était qu'OCFS2 a le plus de potentiel mais nécessite BEAUCOUP d'analyse avant de l'utiliser en production. Si vous voulez quelque chose de simple et fiable, je recommanderais un cluster de serveurs NFS avec Heartbeat pour le basculement.
Je vous suggère POHMELFS - il a été créé par le programmeur russe Evgeniy Polyakov et c'est vraiment, très rapide.
En termes de fiabilité et de sécurité, probablement CIFS (aka 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 quand même ... frais, si vous voyez ce que je veux dire. Je ne sais pas si je lui fais encore confiance, mais cela pourrait simplement être moi étant un vieux fogy, mais le vieux fogeyism est parfois justifié quand il s'agit de données d'entreprise précieuses.
Si vous souhaitez monter de façon permanente 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 l'ai depuis de nombreuses années.
NFS. C'est essayé et vrai, et vous pouvez avoir une configuration solide comme le roc. Les performances GFS sont généralement horribles, en particulier sur les systèmes de fichiers avec un grand nombre de petits fichiers. Je n'ai pas utilisé OCFS, mais je désapprouve généralement le concept de système de fichiers de cluster. Ensuite, il y a Lustre, mais c'est une autre boîte de vers ...
Je pourrais être un peu en retard, nous utilisons un stockage Dell MD3220 qui a un double port de cluster, notre unité a 2 contrôleurs au cas où un descendrait en deuxième le maintiendra en marche jusqu'à ce que nous résolvions ce problème. Puisque le disque dur, le ventilateur, l'alimentation et le contrôleur sont tous des Hotswap, nous remplaçons les pièces à l'intérieur et à l'extérieur. Depuis Format, nous utilisons NFS.
Je déconseille NFS. Autrement dit, nous avions une batterie de serveurs Web, avec JBoss, Apache, Tomcat et Oracle utilisant tous des partages NFS pour les fichiers de configuration courants et la journalisation.
Lorsque la part NFS a disparu (certes, une occurrence rare), le tout s'est effondré (vraiment prévisible, et j'ai déconseillé aux "devlopers" ce raccourci de temps de configuration).
Il semble y avoir un problème avec la version de NFS que nous utilisions, si la cible disparaissait pendant une écriture, le client tomberait dans une boucle d'attente sans fin, en attendant que la cible NFS revienne. Même si la boîte NFS a été rattachée - la boucle ne s'est toujours pas terminée.
Nous utilisions un mélange de RHEL 3,4,5. Le stockage était sur RHEL4, les serveurs étaient sur RHEL5, le réseau de stockage était un lan séparé et ne fonctionnait pas sur les réseaux locaux virtuels.
S'il y a un frontal équilibré en charge, vérifiant le stockage unique - cela ne gênerait-il pas votre système?
Avez-vous envisagé une connexion iSCSI en lecture seule à votre stockage, avec un script événementiel pour déplacer le fichier téléchargé vers le stockage via ftp/scp lorsqu'un fichier est téléchargé?
La seule fois où j'ai implémenté un stockage centralisé réussi pour plusieurs têtes de lecture était sur une baie de stockage EMC ... Toutes les autres tentatives rentables avaient leurs inconvénients.
Considéré comme GFS? GFS est un système de fichiers en cluster, et d'après mon expérience, il est assez fiable. Il peut avoir plus d'un journal, il évolue assez bien
Mais vous auriez besoin d'installer certains services de cluster et GFS n'est pas exactement connu pour sa rapidité. Otoh, ça a toujours été assez rapide pour moi, mais ymmv.
Vous seriez fou de penser à un FS FS distribué comme GFS, et iSCSI est exagéré.
Si vous voulez aller simple avec NFS. C'est simple et rapide, et avec des supports souples assez robustes. Pensez également à désactiver tous les fichiers de verrouillage qui vont avec. J'ai des bureaux Linux qui récupèrent tous leurs répertoires personnels et applications à partir de NFS, cela fonctionne très bien.
Si vous voulez une vitesse scandaleuse, optez pour Luster, qui est beaucoup plus facile à configurer que GFS et ressemble beaucoup à RAID NFS. Nous utilisons Lustre pour nos clusters.
Réponse simple +1 pour NFS. J'ai des partages NFS qui ont été montés pendant des années sans problème.
Si vous recherchez une super fiabilité, envisagez de lancer DRBD dans le mélange pour un système de fichiers NFS à basculement automatique distribué.
La seule autre option (que je connais) est iSCSI mais cela peut être pénible à l'arrière pour configurer ...
Sur une grande batterie de serveurs, nous avions plusieurs millions de pages HTML créées par les utilisateurs. NFS ne fonctionnait pas si bien, nous avons donc fini par les mettre dans une table mysql. La surcharge par rapport à la traversée d'une arborescence de répertoires était à peu près la même.
Je ferais écho à l'avertissement que certains ont donné contre NFS - bien que NFS soit probablement votre meilleur pari (aussi étrange que cela puisse paraître).
J'avais un client NFS que je devais déconnecter de AC pour éteindre car le serveur NFS avait disparu et le client refusait (dans le noyau) de déverrouiller ou d'arrêter car le serveur NFS était parti.
Pour bien faire les choses, j'insisterais sur NFSv4 tout au long, je m'en tiendrai aux connexions TCP, utiliser des trames jumbo et utiliser un cluster NFS. Vous ne pouvez pas vous permettre de faire disparaître votre serveur NFS.
Vous avez un tas d'options, avec une variété de coûts. Partagé SAN avec FC, iSCSI ou l'un des ajouts les plus récents. Dans tous les cas, leur configuration peut être coûteuse et vous devez toujours exécuter un système de fichiers compatible avec les clusters. Les systèmes de fichiers en cluster sont un monde Pour tout espoir de succès, vous avez besoin de réseaux séparés à haute vitesse et à faible latence pour la communication et les données du cluster. Même avec cela, vous risquez de rencontrer des problèmes qui entraînent la fermeture et l'annulation d'un nœud.
Le seul système de fichiers de cluster que j'ai rencontré qui fonctionne sans tracas est VMFS. Mais c'est tellement spécialisé, il ne servirait à rien même s'il était disponible pour un usage général.
NFS est probablement le chemin à parcourir pour votre configuration. Si vous vous inquiétez de la résilience, vous devez obtenir une boîte NFS en cluster appropriée. Vous pouvez faire une configuration homebrew, mais vous rencontreriez le problème ci-dessus. Le meilleur pari (si vous avez l'argent), ce sont les filers NetApp en cluster. C'est une option coûteuse, mais le clustering fonctionne réellement sans tracas. Non seulement cela, ils sont très rapides.
GFS est un vaudou vraiment noir. La quantité de travail requise pour faire fonctionner un simple cluster à deux clients est stupéfiante par rapport aux alternatives. OCFS2 est beaucoup plus simple à déployer mais est très pointilleux en ce qui concerne les versions du module du noyau impliquées sur tous les serveurs connectés - et ce n'est que le début.
Sauf si vous avez vraiment besoin du type d'accès de bas niveau qu'offre un système de fichiers de cluster, NFS ou CIFS est probablement tout ce dont vous avez besoin.
Si vous avez déjà des serveurs Web partout et que vous savez les faire fonctionner, pourquoi ne pas envisager WebDAV?