6 votos

Storage Space Direct : Error SMB

Así que tenemos esto Clúster de 4 nodos Storage Space Direct (S2D) El sistema operativo de la empresa, que funciona desde hace más de un año y medio sin ningún problema. El sistema operativo es Windows Server 2016 .

  • Cortafuegos desactivado para todos los perfiles
  • Sin antivirus instalado, Windows Defender desactivado
  • Delegaciones de Active Directory sin tocar
  • No se ha informado de ningún cambio en la infraestructura de la red
  • RDMA se desactivó hace un año, ya que descubrimos que la NIC no lo soportaba completamente

Hace dos días, nos dimos cuenta de una gran cantidad de mensajes de error en el registro de eventos del clúster, y los trabajos de copia de seguridad de todos los Hyper-V VM alojados en el clúster fallaron (realizados a través de VEEAM).

La investigación demostró rápidamente que hay muchos problemas con las conexiones SMB .

Cualquiera de los 4 anfitriones :

  • puede hacer ping a otros recursos en la red
  • no se puede conectar ninguna carpeta compartida
  • La sincronización NTP falla ( net time \\server falla, también lo es w32tm /monitor )

Obviamente, el File Share Witness falla también, y algún problema con los servicios del Dominio a reportar...

Intentamos reiniciar los nodos por separado, y después de un reinicio las conexiones SMB están bien... durante unos minutos/horas, y luego el problema surge de nuevo .

El impacto en el cluster, junto con el File Share Witness estando fuera de línea, es que no puede realizar fácilmente una migración en vivo de las máquinas virtuales entre los nodos (tiene éxito al azar). Sin embargo, una Migración Rápida sucede como un encanto. Como las conexiones SMB no son posibles, nosotros no se puede mover la VM a otro cluster o un host autónomo.

Tememos que el clúster se vuelva loco si un nodo falla sin control. Aunque las máquinas virtuales son estables, no podemos realizar una copia de seguridad (podríamos realizar una exportación).

¿Alguno de vosotros ha oído hablar de ese problema con S2D o con el rol de cluster de Microsoft Failover? También podría no estar relacionado con el propio cluster...

¿Qué se puede hacer para encontrar la causa de este problema?

Aquí hay muestras de los registros encontrados en el rol de cluster, y en los registros de eventos para SMBCLient :

Desde la consola del Cluster:

El recurso de nombre de red del clúster 'Nombre del clúster' ha encontrado un error al habilitar el nombre de red en este nodo. El motivo del fallo fue: "No se pudo obtener un token de inicio de sesión".

El código de error era "1311".

Puede desconectar el recurso de nombre de red y volver a conectarlo para reintentar.

Evento con ID 30803 :

No se ha podido establecer una conexión de red.

Error: {Tiempo de espera del dispositivo} La operación de E/S especificada en %hs no fue no se completó antes de que expirara el período de tiempo de espera.

Nombre del servidor: servidor.dominio.com

Dirección del servidor: x.x.x.x:445 Tipo de conexión: Wsk

Orientación: Esto indica un problema con la red subyacente o transporte, como por ejemplo con TCP/IP, y no con SMB. Un cortafuegos que bloquea el puerto TCP 445, o el puerto TCP 5445 cuando se utiliza un adaptador iWARP RDMA también puede causar este problema.

Otro, ID 30804 :

Se ha desconectado una conexión de red.

Nombre del servidor: \server.domain.com Dirección del servidor: x.x.x.x:445 Tipo de conexión: Wsk

Orientación: Esto indica que la conexión del cliente con el servidor se ha desconectado.

Desconexiones frecuentes e inesperadas al utilizar un RDMA sobre Converged Ethernet convergente (RoCE) puede indicar una mala configuración de la red. RoCE requiere que se configure el control de flujo prioritario (PFC) para cada host switch y router de la red RoCE. Si no se configura correctamente PFC provocará la pérdida de paquetes, desconexiones frecuentes y un bajo rendimiento.

2 votos

¿Puedes volver a comprobar la fecha/hora en todos los hosts del clúster y del hipervisor?

0 votos

@shodanshok : gracias por tu comentario. Ya comprobado, y comprobado de nuevo : todos los nodos están sincronizados con el dominio, sin desplazamiento.

2voto

Ob1lan Puntos 70

Encontré la solución, fue una estupidez. Los hosts tenían varias NIC para el acceso a la red de diferentes VLANs. Algunas de las NIC estaban asignadas a un Switch Virtual, y otras eran compartidas con el SO (' Permitir que el sistema operativo de gestión comparta este adaptador de red ').

Me di cuenta de que el paquete SMB a menudo utilizaba la interfaz incorrecta (DMZ), y por supuesto la solicitud era denegada.

El comando Powershell que utilicé para identificar la ruta errónea utilizada por el tráfico SMB :

Find-NetRoute -RemoteIPAddress x.x.x.x

(donde x.x.x.x es el recurso remoto en su red)

Esto mostró la interfaz DMZ, en lugar de la interfaz LAN. Al eliminar el botón ' Permitir que el sistema operativo de gestión comparta este adaptador de red ' en el vSwitch DMZ me solucionó el problema.

Todavía no entiendo como este cluster funcionó tan bien durante 1,5 años, con esta configuración. Pero bueno, ahora está resuelto, el FSW y todas las demás operaciones funcionan bien.

Espero que esto pueda ayudar ;)

EnMiMaquinaFunciona.com

EnMiMaquinaFunciona es una comunidad de administradores de sistemas en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros sysadmin, hacer tus propias preguntas o resolver las de los demás.

Powered by:

X