performance – Problema de rendimiento del servidor de archivos del clúster de conmutación por error con Windows Server 2016

Pregunta:

Me encontré con un problema de rendimiento de velocidad de transferencia del servidor de archivos interesante con un clúster de conmutación por error que configuré recientemente en Server 2016. El problema específico es que cuando accedo al recurso compartido de archivos desde la ruta de almacenamiento en clúster (por ejemplo, \\ store01 \ share01), transferencia de archivos la velocidad (escribe en particular, parece) es mucho, mucho más lenta que cuando accedo a ella a través de la ruta local en el nodo propietario actual (por ejemplo, \\ srv04 \ e $ \ Shares \ Share01).

Por ejemplo, copié 499 archivos .txt (con un total de 26.07 MB) usando Robocopy:

  • \\ srv04 \ e $ \ Shares \ Share01: 0: 0: 03 – 635 MB / min

  • \\ store01 \ share01: 0:02:20 – 11.286 MB / min

Este es un problema independientemente del nodo propietario actual o desde dónde se transfieren los datos. Aunque no lo seguí en ese momento, más o menos instalé y configuré el servicio como se indica en esta guía . Intenté jugar con algunas configuraciones, pero todas han vuelto a los valores predeterminados (hasta donde yo sé). He mirado un poco a mi alrededor y no he encontrado nada que mencione específicamente un gran problema de rendimiento con el uso de un clúster de conmutación por error, por lo que he estado haciendo una investigación aleatoria sin mucho que mostrar.

Pocas cosas sobre la configuración que pueden ser relevantes:

  • El clúster tiene actualmente dos nodos. Ambos ejecutan Server 2016 y ambos tienen dos Nic Teams (configurados en Windows, Switch Independent) que constan de dos conexiones de 1 Gbit cada uno.
  • El almacenamiento real que se utiliza es un Synology al que acceden ambas máquinas a través de iSCSI, configurado con estas instrucciones .
  • Todo lo demás parece funcionar bien, en la forma en que funciona la simulación de una conmutación por error y el otro nodo se hace cargo unos segundos más tarde.

Supongo que esta es una de esas situaciones "obvias para cualquiera que sepa más que yo". O tal vez solo estoy esperando eso. De cualquier manera, ¡agradezco cualquier orientación! Traté de ser breve, así que avíseme si necesita más información.

Gracias por adelantado.

Respuesta:

Su primer problema son las NIC combinadas para iSCSI. Nunca haga eso a menos que tanto su objetivo como su iniciador admitan múltiples conexiones por sesión y, en su caso, ninguno de ellos lo hace.

https://www.starwindsoftware.com/blog/lacp-vs-mpio-on-windows-platform-which-one-is-better-in-terms-of-redundancy-and-speed-in-this-case- 2

http://scst.sourceforge.net/mc_s.html

Solución: debe eliminar el equipo de sus NIC y usar MPIO.

Su segundo problema es el propio Synology. No es lo que usa para el almacenamiento primario, es la unidad de respaldo en el mejor de los casos.

Solución: copia su contenido en discos locales y usa Synology como repositorio de respaldo o lo que sea.

Leave a Comment

Your email address will not be published. Required fields are marked *

Scroll to Top

web tasarım