4 votos

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

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

Por ejemplo, copié 499 archivos .txt (que suman 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 de dónde se transfieren los datos. Aunque en su momento no lo seguí, más o menos instalé y configuré el servicio como se indica en esta guía. He intentado ajustar algunas configuraciones, pero todas están de vuelta a los valores predeterminados (que yo sepa). He buscado un poco y no he encontrado nada que mencione específicamente un gran problema de rendimiento al usar un clúster de conmutación por error, así que he estado investigando al azar sin mucho éxito.

Algunas cosas sobre la configuración que podrían ser relevantes:

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

Supongo que este es uno de esos casos de "obvio para cualquiera que sepa más que yo". O tal vez solo estoy esperando eso. De cualquier manera, ¡aprecio cualquier orientación! Intenté ser breve, así que por favor avísame si necesitas más información.

Gracias de antemano.

4voto

BaronSamedi1958 Puntos 103

Su primer problema es tener NICs agrupadas para iSCSI. Nunca debes hacer eso a menos que tanto el objetivo como el iniciador admitan múltiples conexiones por sesión y en tu 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: debes desagregar tus NICs y usar MPIO.

Su segundo problema es Synology en sí. No es lo que se debe usar para almacenamiento primario, es una unidad de respaldo en el mejor de los casos.

Solución: copia tu contenido a discos locales y utiliza Synology como repositorio de respaldo o algo por el estilo.

0 votos

Sé que Synology, al menos, admite "Permitir varias sesiones desde uno o más iniciadores iSCSI:". Hay una casilla de verificación y todo. Realmente, eso no viene al caso. Gracias por tu sugerencia. Y simplemente estoy trabajando con los recursos que tengo. ¿Puedes explicar un poco por qué mi configuración actual funcionaría muy bien (en términos de rendimiento) al ser accedida a través de un camino u otro?

3 votos

No dije que necesitas solo UN camino, te dije que debes eliminar LACP porque no funciona con tu objetivo y el iniciador tal como está. Te proporcioné enlaces que podrías leer y entender el POR QUÉ.

3 votos

"Permitir varias sesiones desde uno o más Iniciadores iSCSI:" no tiene relación con su problema actual, es algo que el objetivo debería hacer para que los bloqueos distribuidos sean esenciales para que Hyper-V, VMware, etc. funcione.

0voto

Perilous Puntos 21

Después de quitar el teaming de NIC y colocar las conexiones en el Synology/Servidor en una subred diferente por si acaso, aún no vi ninguna mejora en el rendimiento.

Finalmente encontré la solución. Resulta que el problema era que la Disponibilidad Continua estaba activada (por defecto) en la carpeta compartida. Hay documentación que dice que puede causar una pequeña penalización en el rendimiento (como aquí) debido a la omisión de la caché de escritura, pero parece que en algunos casos esa pequeña penalización en el rendimiento es realmente gigantesca. Aquí tienes un artículo que ofrece una información de fondo bastante útil sobre la Disponibilidad Continua y cuándo podría ser útil (resumiendo, podrías querer desactivarla si tu carpeta compartida está configurada como "Servidor de Archivos de Uso General" y te preocupa el rendimiento).

En resumen, desactivé la Disponibilidad Continua en la carpeta compartida usada por el clúster, reinicié ambos servidores por si acaso, y el problema de rendimiento se resolvió. Aunque preferiría tenerla activada para garantizar la integridad de los datos durante un evento de failover, esos eventos serán tan escasos en mi entorno que no hay duda de que la penalización en rendimiento no valía la pena.

0 votos

CA es E/S no almacenada por diseño, por lo que sí, es normal. blogs.technet.microsoft.com/filecab/2016/03/15/… "Puede habilitar CA en comparticiones no-SOFS en un clúster, y puede usar aplicaciones de usuario final como Word con ellas, pero por diversas razones, no es algo que recomendamos."

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