SMB afirmó ser "lento"

La red de nuestra empresa (que creo que es un dominio de Windows ejecutado en el servidor 2008) es extremadamente lenta. Un buen ejemplo de esto es copiar archivos a través de SMB: las listas toman minutos, y copiar incluso archivos de tamaño modesto lleva aún más tiempo. Cuando se le preguntó sobre el tema, el gerente de TI (que, a pesar de cualquier otro mérito que pueda tener, es una persona muy terca y no muy técnica) levanta las manos, se pone muy a la defensiva y da excusas en lugar de escuchar e intentar resolver la causa raíz del problema.

Ahora, reconociendo que el elemento humano de este problema tomará un poco de tiempo y esfuerzo para resolverlo, me queda sin saber cómo refutar técnicamente sus excusas. En este caso, afirma que SMB es el problema y que es un protocolo "lento". ¿Hay alguna evidencia de esta afirmación (solo tengo evidencia anecdótica contraria)? ¿Cuál es la mejor manera de avanzar en este argumento?

SMB podría ser más lento que otros protocolos de intercambio de archivos, y podría ser más rápido que otros. Pero esa no es la parte importante.

En lugar de hacer de eso la pregunta / argumento, ¿puede encontrar una manera de pasar de eso y preguntar si SMB es tan rápido (o tan lento) como se supone que es? Por ejemplo, ¿puede transferir un archivo usando FTP entre el servidor y una estación de trabajo que sufre de la lentitud y ver un salto marcado en el rendimiento?

Es posible que el proveedor pueda recomendarle revisiones del hardware, con Windows instalado, que hablen sobre el rendimiento del servidor de archivos.

En mi experiencia, SMB es más que "lo suficientemente rápido" en mi red. Estamos ejecutando una red de 10 Gb entre los servidores y estamos muy contentos con el rendimiento del servidor de archivos usando SMB y hemos medido buenos saltos de rendimiento en el mismo hardware dependiendo de si usamos la NIC de 1 Gb o 10 Gb. SMB no es un problema para nosotros.

Ciertamente estaría mirando otras cosas en su red: la infraestructura está desactualizada, está configurada de manera óptima (por ejemplo, las tarjetas de red del servidor están configuradas correctamente para los controladores más recientes, funcionan correctamente a la mejor velocidad posible), son cosas como DNS y así ... en todos los configurados correctamente, si hay mucho tráfico "basura" en la red que causa una desaceleración, el antivirus está configurado de una manera demasiado paranoica (he visto que esto causa algunas ralentizaciones impactantes ).

Hay muchas cosas que pueden causar un mal rendimiento del servidor de archivos y muy poca de ellas es la elección del protocolo.

Si bien hay protocolos más rápidos que SMB, no es inherentemente lento.

Sin embargo, es quizás un poco más susceptible a las influencias externas que otros protocolos, como servidores saturados, segmentos saturados, etc.

Si yo fuera un jugador de apuestas, sospecharía que su red podría funcionar con un rediseño o alguna inversión, ya que las redes de oficinas regulares de muchas compañías no se han actualizado para tener en cuenta el gran aumento en el tráfico de Internet e intranet visto en los últimos años. También hay una posibilidad razonable de que los servidores necesiten ser reemplazados o reelaborados para obtener lo mejor de ellos.

De cualquier manera, no pondría demasiado énfasis en que SMB sea el culpable directo, es más que probable que solo sea el culpable de la mala / vieja red y el kit de servidor.

Tiene más gastos generales (para transferencia) que cosas como NFS o FTP. La lista de archivos de directorios de gran tamaño puede llevar un tiempo, algo de esto se debe a SMB, algunos a NTFS, otros a cosas estúpidas que las diversas versiones de Explorer y el software instalado pueden hacer desde el extremo del cliente. Ciertas cosas como las bases de datos basadas en archivos (Access, archivos PST) no deben abrirse a través de enlaces lentos (WAN) porque no se ocupan bien de la latencia.

Dicho esto, las operaciones que describas no deberían llevar mucho tiempo. Tal vez el servidor de archivos (s?) Tiene poca potencia. Tal vez la compañía tiene algún software como parte de la instalación estándar que ralentiza las cosas. Tal vez hay un escáner de virus mal configurado. Tal vez hay un virus. Tal vez hay un enlace WAN que no conoce entre usted y el servidor.

1. ¿Listar archivos es más rápido si lo haces desde una línea de comandos en lugar de Explorer?
2. ¿Qué tal copiar?
3. Haga ping al servidor en cuestión desde su escritorio: ¿cuál es la latencia?
4. Haga un traceroute: ¿cuántos saltos hay entre usted y el servidor?

Lamentablemente, Nate, no podemos tratar directamente con PHB. Su primera línea de defensa aquí son las métricas reales, como en las comparaciones entre transferencia SMB y NFS, por ejemplo.

Una vez que tenga números o estadísticas reales para respaldar sus argumentos, no necesitará ocuparse tanto del elemento humano. Las estadísticas dicen "aquí es donde está el problema, y ​​aquí está la prueba". Ese es tu argumento.

¿Puedes reducirlo en absoluto? ¿Una transferencia de servidor a servidor en la misma subred tiene mejores resultados? ¿Qué tal la transferencia de un cliente a otro ( \\client\c$→ \\client\d$)?

Puede encontrar algo tan simple como falta de coincidencia dúplex.

Sé que esto es antiguo, pero un factor muy importante a tener en cuenta es la E / S de disco. Si el rendimiento de escritura del disco es increíblemente lento debido al software / placa base RAID en lugar de una tarjeta RAID basada en hardware con memoria dedicada.

La carga de la red es un factor, pero lo mejor que puede hacer como administrador del sistema es mirar el Monitor de recursos e inspeccionar de dónde pueden originarse los cuellos de botella, inspeccionando la pestaña Descripción general para mostrar la CPU, la red, la E / S de disco, la memoria, etc. Desde este punto de vista, puede ver si hay un proceso culpable o un conjunto de procesos que están consumiendo Disco I / O, o una pérdida de memoria (SQLServer.exe - SBSMonitoring instancia), etc. Si hay un proceso de red que utiliza una gran cantidad de ancho de banda, verifique ese proceso e inspeccione cuántos y cuáles son los hosts que están vinculados a ese proceso. Podría ser una gran cantidad de intentos de pirateo para RDP en 3389. He visto eso antes como el caso y nuestra solución fue eliminar el acceso directo a RDP y transferir a los usuarios remotos finales a VPN.

¡Espero que esto ayude!