SMB afirmou ser "lento"

A rede de nossa empresa (que acredito ser um domínio do Windows executado no servidor 2008) é dolorosamente lenta. Um excelente exemplo disso é a cópia de arquivos em SMB - as listagens demoram minutos e a cópia de arquivos de tamanho modesto leva ainda mais tempo. Quando abordado sobre o assunto, o gerente de TI (que, apesar de quaisquer outros méritos que ele possa ter, é uma pessoa muito teimosa e não muito técnica) joga as mãos para cima, fica muito defensivo e dá desculpas em vez de ouvir e tentar descobrir a causa raiz do problema.

Agora, reconhecendo que o elemento humano desse problema levará algum tempo e esforço para ser resolvido, fiquei sem saber exatamente como refutar tecnicamente suas desculpas. Nesse caso, ele afirma que o SMB é o problema e que é um protocolo "lento". Existe alguma evidência para esta afirmação (eu só tenho contra-evidência anedótica)? Qual é a melhor maneira de avançar nesse argumento?

O SMB pode muito bem ser mais lento que alguns outros protocolos de compartilhamento de arquivos e pode ser mais rápido do que alguns outros. Mas essa não é a parte importante.

Em vez de fazer dessa a pergunta / argumento, você pode encontrar uma maneira de seguir em frente e perguntar se o SMB é tão rápido (ou tão lento!) Quanto deveria ser. Por exemplo, você pode transferir um arquivo usando FTP entre o servidor e uma estação de trabalho que sofre com a lentidão e vê um salto acentuado no desempenho?

O fornecedor pode apontar para análises do hardware, com o Windows instalado, que fala sobre o desempenho do servidor de arquivos.

Na minha experiência, o SMB é mais do que "rápido o suficiente" na minha rede. Estamos executando uma rede de 10 Gb entre os servidores e estamos muito felizes com o desempenho do servidor de arquivos usando SMB e medimos bons saltos de desempenho no mesmo hardware, dependendo se usamos a NIC de 1 Gb ou 10 Gb. SMB não é um problema para nós.

Certamente, eu observaria outras coisas na sua rede - a infraestrutura está desatualizada, está configurada da melhor maneira (por exemplo, placas de rede de servidor configuradas corretamente para os drivers mais recentes, funcionando corretamente na melhor velocidade possível), são coisas como DNS e em tudo configurado corretamente, há muito tráfego "indesejado" na rede, causando um abrandamento, o antivírus está configurado de uma maneira excessivamente paranóica (eu já vi isso causar algumas lentidões chocantes ).

Muita coisa pode causar um desempenho ruim do servidor de arquivos e muito pouco é a escolha do protocolo.

Embora existam protocolos mais rápidos que o SMB, ele não é inerentemente lento.

No entanto, talvez seja um pouco mais suscetível a influências externas do que outros protocolos, sendo servidores saturados, segmentos saturados etc.

Se eu fosse um jogador de apostas, suspeitaria que sua rede poderia fazer um redesenho ou algum investimento, já que muitas redes de escritórios regulares da empresa não foram atualizadas para levar em conta o enorme aumento no tráfego da Internet e da intranet visto nos últimos anos. Também há uma chance razoável de que os servidores precisem ser substituídos ou retrabalhados para obter o melhor deles.

De qualquer maneira, eu não colocaria muita ênfase no fato de o SMB ser o culpado direto, é mais do que provável que seja o capricho do kit de rede e servidor ruim / antigo.

Ele tem mais sobrecarga (para transferência) do que coisas como NFS ou FTP. A listagem de arquivos de diretórios grandes pode demorar um pouco - parte disso é devido ao SMB, outro devido ao NTFS, outros devido a coisas estúpidas que as várias versões do Explorer e o software instalado podem fazer do lado do cliente. Algumas coisas, como bancos de dados baseados em arquivo (arquivos Access, PST), não devem ser abertos através de links lentos (WAN) porque não lidam bem com a latência.

Dito isto, as operações que você descreve não devem demorar muito. Talvez o servidor de arquivos esteja com pouca potência. Talvez a empresa tenha algum software como parte da instalação padrão que atrasa as coisas. Talvez haja um antivírus mal configurado. Talvez haja um vírus. Talvez haja um link WAN que você não conheça entre você e o servidor.

1. A listagem de arquivos é mais rápida se você fizer isso em uma linha de comando em vez do Explorer?
2. Que tal copiar?
3. Faça ping no servidor em questão na sua área de trabalho - qual é a latência?
4. Faça um traceroute - quantos saltos existem entre você e o servidor?

Infelizmente, Nate, não podemos lidar diretamente com PHBs. Sua primeira linha de defesa aqui são métricas reais, como em comparações entre transferência SMB e NFS, por exemplo.

Depois de ter números ou estatísticas reais para respaldar seus argumentos, você não precisará lidar tanto com o elemento humano. As estatísticas dizem "aqui é onde está o problema, e aqui está a prova". Esse é o seu argumento.

Você pode reduzi-lo? Uma transferência de servidor para servidor na mesma sub-rede tem melhores resultados? Que tal transferir de um cliente para outro ( \\client\c$→ \\client\d$)?

Você pode encontrar algo tão simples como incompatibilidade duplex.

Sei que isso é antigo, mas um fator muito importante a ser levado em consideração é a E / S do disco. Se o desempenho de gravação do disco for incrivelmente lento devido ao RAID de software / placa-mãe, em oposição a uma placa RAID baseada em hardware com memória dedicada.

A carga da rede é um fator, mas a melhor coisa a fazer como administrador do sistema é examinar o Monitor de Recursos e inspecionar a origem dos gargalos - inspecionando a guia Visão geral para mostrar a CPU, a rede, a E / S de disco, a memória, etc. A partir dessa vantagem, é possível ver se há um processo ou conjunto de processos culpados na E / S de disco ou um vazamento de memória (SQLServer.exe - instância do SBSMonitoring) etc. Se houver um processo de rede usando muitas largura de banda, verifique esse processo e inspecione quantos e quais hosts estão vinculados a esse processo. Poderia haver muitas tentativas de invasão para entrar no RDP no 3389. Já vi isso antes e nossa solução foi remover o acesso direto ao RDP e transferir os usuários remotos finais para a VPN.

Espero que isto ajude!