Quel protocole de partage de fichiers en réseau offre les meilleures performances et fiabilité? [fermé]

Nous avons une configuration avec quelques serveurs Web en équilibre de charge. Nous voulons avoir une sorte de stockage partagé en réseau auquel tous les serveurs Web peuvent accéder. Il servira d’emplacement pour stocker les fichiers téléchargés par les utilisateurs. Tout tourne sous Linux.

Devrions-nous utiliser NFS, CIFS, SMB, fusible + sftp, fusible + ftp? Il y a tellement de choix en matière de protocoles de partage de fichiers en réseau qu'il est très difficile d'en choisir un. En gros, nous souhaitons simplement monter en permanence ce partage sur plusieurs ordinateurs. Les fonctions de sécurité posent moins de problèmes, car le réseau ne sera pas accessible ailleurs que par les serveurs qui le montent. Nous voulons juste que cela fonctionne de manière fiable et rapide.

Lequel devrions-nous utiliser?

Je vote pour NFS.

NFSv4.1 a ajouté la fonctionnalité pNFS parallèle NFS, qui permet un accès parallèle aux données. Je me demande quel type de clients utilisent le stockage si, comme sur Unix, je choisirais NFS en fonction des performances.

La réponse courte est d'utiliser NFS. Selon cette fusillade et ma propre expérience, c'est plus rapide.

Mais vous avez plus d'options! Vous devez envisager un système de fichiers en grappe comme GFS, système de fichiers auquel plusieurs ordinateurs peuvent accéder simultanément. En gros, vous partagez un périphérique en mode bloc via iSCSI, qui est un système de fichiers GFS. Tous les clients (initiateurs dans le jargon iSCSI) peuvent lire et écrire. Redhat a un livre blanc . Vous pouvez également utiliser le cluster FS FS d’ Oracle pour gérer la même chose.

Le document redhat fait un bon travail en énumérant les avantages et les inconvénients d’un groupe FS par rapport à NFS. Fondamentalement, si vous voulez beaucoup d'espace pour évoluer, GFS en vaut probablement la peine. En outre, l'exemple GFS utilise un réseau SAN Fibre Channel à titre d'exemple, mais il pourrait tout aussi bien s'agir d'un réseau SAN RAID, DAS ou iSCSI.

Enfin, assurez-vous de regarder dans Jumbo Frames, et si l'intégrité des données est critique, utilisez CRC32 checksumming si vous utilisez iSCSI avec Jumbo Frames.

Nous avons un cluster Web à chargement sur deux 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 CIFS central (SAMBA) vers les deux serveurs
• Un partage NFS central vers les deux serveurs
• Un lecteur SAN partagé 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 s’affichent et RSYNC a mis une telle charge sur les serveurs que nous avons dû la limiter avec un script personnalisé pour la suspendre à la seconde. Nous étions également limités à écrire uniquement sur le lecteur source.

Le lecteur partagé le plus rapide a été le lecteur en cluster OCFS2 jusqu'à ce qu'il devienne fou et fasse planter 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 et les serveurs redémarrent. Cela peut être un échec de la formation de notre part.

Le prochain meilleur é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 visibles par les serveurs Web. SMB a également tendance à se bloquer lors de l'échec sur le serveur SMB

Notre conclusion était qu'OCFS2 avait le plus de potentiel mais nécessitait 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 il est vraiment, vraiment rapide.

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 à la substance FUSE, mais cela semble toujours ... frais, si vous voyez ce que je veux dire. Je ne sais pas si j'y crois encore, mais il se pourrait que je sois un vieux fogy, mais le vieux fogeyisme est parfois justifié lorsqu'il est question de données d'entreprise précieuses.

Si vous souhaitez monter un partage de façon permanente sur plusieurs machines et que vous pouvez jouer avec certaines bizarreries (principalement des problèmes UID / GID), utilisez NFS. Je l'utilise depuis de nombreuses années.

NFS. C'est essayé et vrai, et vous pouvez avoir une configuration solide comme un roc. Les performances de GFS sont généralement mauvaises, en particulier sur les systèmes de fichiers contenant un grand nombre de petits fichiers. Je n'ai pas utilisé OCFS, mais j'ai généralement mal vu le concept de système de fichiers en cluster. Ensuite, il y a le lustre, mais c'est une autre boîte de Pandore ...

Je déconseillerais NFS. Autrement dit, nous avions une batterie de serveurs Web composée de JBoss, Apache, Tomcat et Oracle, qui utilisaient tous des partages NFS pour les fichiers de configuration courants et la journalisation.

Lorsque le partage NFS a disparu (ce qui est, certes, un événement rare), le tout s'est simplement effondré (vraiment prévisible, et j'ai conseillé les «développeurs» contre ce raccourci de temps de configuration).

Il semble y avoir un problème avec la version de NFS utilisée: si la cible disparaissait au cours d'une écriture, le client entrait dans une boucle d'attente sans fin, dans l'attente du retour de la cible NFS. Même si la boîte NFS était rattachée, la boucle ne finissait toujours pas.

Nous utilisions un mélange de RHEL 3,4,5. Le stockage était sur RHEL4, les serveurs sur RHEL5, le réseau de stockage était un réseau distinct et ne fonctionnait pas sur des réseaux virtuels.

S'il existe une unité frontale à charge équilibrée, vérifiant le stockage unique, cela ne ferait-il pas obstruer votre système?

Avez-vous envisagé une connexion iSCSI en lecture seule à votre stockage, avec un script piloté par événement pour déplacer le fichier téléchargé sur le stockage via ftp / scp lorsqu'un fichier est téléchargé?

La seule fois où j'ai mis en place un stockage centralisé réussi pour plusieurs têtes de lecture, c'était sur une baie de stockage EMC ... Toutes les autres tentatives rentables présentaient des inconvénients.

Considéré comme GFS? GFS est un système de fichiers en cluster, et selon mon expérience, il est assez fiable. Il peut avoir plus d'un journal, il évolue assez bien

Cependant, vous devez installer certains services de cluster et GFS n'est pas connu pour sa rapidité. Otoh, ça a toujours été assez rapide pour moi, mais ymmv.

Vous seriez fou de penser à un système de fichiers distribué, tel que GFS, et iSCSI est excessif.

Si vous voulez simplement aller avec NFS. C'est simple et rapide, et avec des montures souples assez robustes. Pensez également à désactiver tous les fichiers de verrouillage associés. J'ai des bureaux Linux qui récupèrent tous leurs répertoires personnels et leurs applications à partir de NFS, cela fonctionne bien.

Si vous voulez une vitesse démesurée, optez pour Lustre, qui est beaucoup plus facile à configurer que GFS et ressemble beaucoup à RAID NFS. Nous utilisons Lustre pour nos grappes.

Je suis peut-être un peu en retard. Nous utilisons un système de stockage Dell MD3220 doté d’un port double pour le cluster. Étant donné que le disque dur, le ventilateur, l’alimentation et le contrôleur font tous partie de l’échange Hotswap, nous remplaçons les pièces en entrée et en sortie. Au format, nous utilisons NFS.

Si vous avez déjà des serveurs Web partout et que vous les utilisez bien, pourquoi ne pas envisager WebDAV?

Réponse simple +1 pour NFS. J'ai des partages NFS qui sont montés depuis des années sans problème.

Si vous recherchez une fiabilité extrême, envisagez également d'inclure DRBD dans un système de fichiers NFS distribué et à basculement automatique.

La seule autre option (que je connais bien) est l'iSCSI, mais il peut être difficile de configurer à l'arrière ...

Vous avez un tas d'options, avec une variété de coûts. SAN partagé avec FC, iSCSI ou l'un des ajouts les plus récents. Dans tous les cas, leur installation 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 de souffrance. Pour tout espoir de succès, vous avez besoin de réseaux distincts à haut débit et à faible temps de latence pour la communication en cluster et les données. Même avec cela, vous risquez d'avoir des problèmes qui font qu'un noeud est isolé et tué.

VMFS est le seul système de fichiers en cluster que je connaisse qui fonctionne simplement sans tracas. Mais c'est tellement spécialisé que cela ne servirait à rien même s'il était disponible pour un usage général.

NFS est probablement la voie à suivre pour votre configuration. Si vous êtes préoccupé par la résilience, vous devez vous procurer une boîte NFS en cluster appropriée. Vous pouvez faire une configuration homebrew, mais vous posez le problème ci-dessus. Le meilleur pari (si vous avez de l'argent) est de regrouper les serveurs de fichiers NetApp. C'est une option coûteuse, mais le regroupement fonctionne réellement sans problème. Non seulement cela, ils sont très rapides.

Je voudrais faire é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 m'éteindre parce que le serveur NFS avait disparu et que le client avait refusé (dans le noyau) de déverrouiller ou de s'arrêter car le serveur NFS avait disparu.

Pour bien faire les choses, j'insiste sur NFSv4, sur les connexions TCP, sur les trames jumbo et sur un cluster NFS. Vous ne pouvez pas vous permettre de faire disparaître votre serveur NFS.

GFS est un certain vaudou 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 très pointilleux en ce qui concerne les versions de modules du noyau impliquées sur tous les serveurs connectés - et ce n’est que le début.

À moins que vous n'ayez vraiment besoin du type d'accès de bas niveau offert par un système de fichiers en cluster, NFS ou CIFS est probablement tout ce dont vous avez besoin.

Sur une grande batterie de serveurs, plusieurs millions de pages HTML ont été créées par les utilisateurs. NFS ne fonctionnait pas si bien que nous avons fini par les mettre dans une table mysql. La surcharge comparée à la traversée d'une arborescence de répertoires était à peu près la même.

J'ai utilisé SFTP et cela a bien fonctionné. NFS était mon premier recours, mais le côté ludique des identifiants utilisateur / groupe m'a fait chuter assez rapidement.

Il suffit de configurer publickey auth et vous serez en grande partie paramétré. La surcharge du processeur pour le chiffrement SSH est peut-être un peu plus lourde, mais je n'ai jamais rencontré de problème de corruption des données.

FTP pourrait toutefois convenir à vos besoins, car il est plus léger. Vous voulez sans doute que vos serveurs Web effectuent le service Web, pas le travail ssh.