SMB prétend être «lente»

Notre réseau d'entreprise (qui, je crois, est un domaine Windows exécuté sur le serveur 2008) est douloureusement lent. Un bon exemple de cela est la copie de fichiers sur SMB - les listes prennent quelques minutes, et la copie de fichiers même de taille modeste prend encore plus de temps. Lorsqu'il est approché à propos de la question, le responsable informatique (qui, malgré tous les autres mérites qu'il pourrait avoir, est une personne très têtue et pas très technique) lève les mains, devient très défensif et donne des excuses au lieu d'écouter et d'essayer de déterminer la cause profonde du problème.

Maintenant, reconnaissant que l'élément humain de ce problème prendra du temps et des efforts à résoudre, je ne sais pas trop comment réfuter techniquement ses excuses. Dans ce cas, il affirme que SMB est le problème et qu'il s'agit d'un protocole "lent". Y a-t-il des preuves de cette déclaration (je n'ai que des contre-preuves anecdotiques)? Quelle est la meilleure façon de progresser dans cet argument?

SMB pourrait bien être plus lent que certains autres protocoles de partage de fichiers, et il pourrait bien être plus rapide que d'autres. Mais ce n'est pas la partie importante.

Au lieu d'en faire la question / l'argument, pouvez-vous trouver un moyen de passer à autre chose et de demander si SMB est aussi rapide (ou aussi lent!) Qu'il est censé l' être. Par exemple, pouvez-vous transférer un fichier via FTP entre le serveur et un poste de travail qui souffre de la lenteur et voir une nette augmentation des performances?

Le fournisseur peut vous indiquer des avis sur le matériel, avec Windows installé, qui parlent des performances du serveur de fichiers.

D'après mon expérience, SMB est plus que "assez rapide" sur mon réseau. Nous exécutons un réseau de 10 Go entre les serveurs et nous sommes très satisfaits des performances du serveur de fichiers à l'aide de SMB et nous avons mesuré de bons sauts de performances sur le même matériel selon que nous utilisons la carte réseau 1 Go ou 10 Go. SMB n'est pas un problème pour nous.

Je regarderais certainement d'autres choses sur votre réseau - l'infrastructure est-elle obsolète, est-elle configurée de manière optimale (par exemple, les cartes réseau du serveur sont toutes configurées correctement pour les derniers pilotes, fonctionnant correctement à la meilleure vitesse possible), sont des choses comme DNS et ainsi de suite - sur tout correctement configuré, y a-t-il beaucoup de trafic "indésirable" sur le réseau provoquant un ralentissement, l'antivirus est-il configuré de manière trop paranoïaque (j'ai vu cela provoquer des ralentissements choquants ).

Il y a beaucoup de choses qui peuvent entraîner de mauvaises performances du serveur de fichiers et très peu d'entre elles sont le choix du protocole.

Bien qu'il existe des protocoles plus rapides que SMB, il n'est en aucun cas lent par nature.

Il est cependant peut-être un peu plus sensible aux influences extérieures que les autres protocoles, ceux-ci étant des serveurs saturés, des segments saturés etc.

Si j'étais un joueur de jeu, je soupçonnerais que votre réseau pourrait faire l'objet d'une refonte ou d'un investissement, car les réseaux de bureaux réguliers de nombreuses entreprises n'ont pas été mis à niveau pour tenir compte de l'énorme augmentation du trafic Internet et intranet observée ces dernières années. Il y a également une chance raisonnable que le ou les serveurs aient besoin d'être remplacés ou retravaillés pour en tirer le meilleur parti.

Quoi qu'il en soit, je ne mettrais pas trop l'accent sur le fait que SMB soit le coupable direct, il est plus que probable que ce soit le coupable des mauvais / vieux réseaux et kits de serveurs.

Il a plus de frais généraux (pour le transfert) que des choses comme NFS ou FTP. La liste des fichiers de grands répertoires peut prendre un certain temps - en partie à cause de SMB, à cause de NTFS, à cause de choses stupides que les différentes versions d'Explorer et les logiciels installés peuvent faire du côté client. Certaines choses comme les bases de données basées sur des fichiers (fichiers Access, PST) ne doivent pas être ouvertes sur des liaisons lentes (WAN) car elles ne gèrent pas bien la latence.

Cela dit, les opérations que vous décrivez ne devraient pas prendre beaucoup de temps. Peut-être que le ou les serveurs de fichiers sont / sont sous-alimentés. Peut-être que la société a un logiciel dans le cadre de l'installation standard qui ralentit les choses. Il y a peut-être un scanner de virus mal configuré. Peut-être qu'il y a un virus. Il existe peut-être un lien WAN que vous ne connaissez pas entre vous et le serveur.

1. La liste des fichiers est-elle plus rapide si vous le faites à partir d'une ligne de commande au lieu d'Explorer?
2. Que diriez-vous de copier?
3. Envoyez une requête ping au serveur en question depuis votre bureau - quelle est la latence?
4. Faites un traceroute - combien de sauts séparez-vous du serveur?

Malheureusement Nate, nous ne pouvons pas traiter directement avec les PHB. Votre première ligne de défense ici est des mesures réelles, comme dans le cas des comparaisons entre le transfert SMB et NFS, par exemple.

Une fois que vous avez des chiffres ou des statistiques réels pour étayer vos arguments, vous n'aurez plus à vous soucier de l'élément humain. Les statistiques disent "c'est là que se situe le problème, et voici la preuve". Voilà votre argument.

Pouvez-vous le réduire du tout? Un transfert de serveur à serveur sur le même sous-réseau a-t-il de meilleurs résultats? Que diriez-vous d'un transfert d'un client à un autre ( \\client\c$→ \\client\d$)?

Vous pouvez trouver quelque chose d'aussi simple qu'une asymétrie duplex.

Je sais que c'est ancien, mais un facteur très important à prendre en considération est les E / S disque. Si les performances d'écriture du disque sont incroyablement lentes en raison du RAID logiciel / carte mère par opposition à une carte RAID matérielle avec mémoire dédiée.

La charge réseau est un facteur, mais la meilleure chose à faire en tant qu'administrateur système est de regarder le moniteur de ressources et d'inspecter l'origine des goulots d'étranglement - en inspectant l'onglet Présentation pour afficher l'ensemble du processeur, du réseau, des E / S disque, de la mémoire, etc. De cette vue, vous pouvez voir s’il existe un processus coupable ou un ensemble de processus qui rongent les E / S disque, ou une fuite de mémoire (SQLServer.exe - instance SBSMonitoring), etc. S'il existe un processus réseau utilisant beaucoup de bande passante, vérifiez ce processus et inspectez le nombre et les hôtes liés à ce processus. Cela pourrait être beaucoup de tentatives de piratage pour RDP sur 3389. J'ai déjà vu cela comme le cas et notre solution était de supprimer l'accès direct RDP et de déplacer les utilisateurs distants finaux vers VPN.

J'espère que cela t'aides!