PowerVault MD3220I tiempo de conmutación por fallo

Almacenamiento

Almacenamiento
Soporte, consejos y tutoriales sobre Cabinas de Almacenamiento

PowerVault MD3220I tiempo de conmutación por fallo

Esta pregunta ha sido respondida por David López Anguita

Buenos días,

Tenemos una instalación con 2x PowerEdge 730 y 1x MD3220I en donde cada servidor está conectado directamente (sin switch) a la cabina mediante 4 interfaces (dos interfaces para cada controladora de la cabina) y con multipath configurado.

En la fase de pruebas hemos detectado que si desconectamos dos cables de la red iSCSI del mismo servidor, la comunicación con la cabina se mantiene pausada entre 20 y 60 segundos hasta que la comunicación se restablece por los otros dos enlaces disponibles.

¿Éste es el comportamiento estándar para este modelo de cabina? ¿Hay alguna manera de optimizarlo para reducir el tiempo de espera hasta que la conmutación por error se realice?

Gracias de Antemano.

Un saludo.

Respuesta comprobada
  • Hola,

    Según los logs a nivel de iSCSI la cabina está correctamente configurada y tiene todas las sesiones creadas.

    Lo que hemos podido ver es que los Jumbo Frames no están configurados en la cabina:

    Maximum transmission unit: 1500 bytes/frame

    por lo que tendría que configurarlo correctamente, los Jumbo Frames tienen que estar configurados tanto en el servidor como en la cabina.

    También hay otros puntos que pueden afectar al tiempo de balanceo de las LUNs:

    - Correcta configuración de la red en Windows 2012 R2, por ejemplo, una incorrecta configuración de DNS podría afectar.

    - Cómo está configurado el clúster.

    - Tipo de failover.

    Aún así lo importante sería que no haya una caída de servicio cuando se produce el balanceo.

    Tenga en cuenta que esta respuesta que ha recibido corresponde a una garantía ProSupport y sin embargo su cabina dispone de una garantía Básica que solo cubre el hardware, por lo que si está interesado en continuar recibiendo este tipo de soporte le recomiendo que actualice la garantía a ProSupport, yo mismo le puedo tramitar la actualización si está interesado.

    Un saludo

  • También le puede ser útil el documento sobre Best Practices:

    IP SAN Best Practices

    y la documentación de la cabina:

    Manuales y documentación para su PowerVault MD3200i

    Un saludo

Todas las respuestas
  • Hola,

    Para poder gestionar su consulta ¿nos podría indicar el Service Tag de la cabina y los servidores por mensaje privado por favor?

    Muchas gracias.

     

    Un saludo

  • Buenas tardes,

    Gracias por la respuesta.

    Ya le he enviado por mensaje privado las Service Tags.

    Un saludo.

  • Buenos días David,

    Voy a adjuntar la información que hemos intercambiado en el post público para que otros compañeros puedan estar informados

    • Para poder ofrecerle información referente a su consulta necesitaría:

      1. Fichero de soporte de la cabina, para ello siga los pasos de este artículo: MD32x0(i) + MD36x0i + MD36x0f - Gather Support Information

      2. Si puede indicarme cómo tiene el cableado exactamente así como la versión de los sistemas operativos que tienen los servidores.

      Un saludo

      • 8:52
    • Buenas tardes,

      Ya he subido el fichero. La forma en que lo obtuve fue distinta a la mencionada en el artículo debido a que la pestaña "Support" debe ser que no existe en la nueva versión de MDSM.

      A continuación le detallo cómo están realizadas las conexiones. A la izquierda detallo la IP y la interface del servidor con la nomenclatura de Dell y a la derecha la interface y controladora usada de la cabina con su IP. Las líneas en negrita son las conexiones iSCSI con MTU 9000. Espero que se entienda:

      - (Servidor 1):

      · 192.168.132.21 Slot 5 Port 0 -> SAN C0 P2 192.168.132.101
      · 192.168.133.21 Slot 5 Port 1 -> SAN C1 P3 192.168.133.102
      · NIC1 -> Red Local 192.168.1.21
      · NIC2 -> Cluster dedicada
      · 192.168.130.21 NIC3 -> SAN C0 P0 192.168.130.101
      · 192.168.131.21 NIC4 -> SAN C1 P1 192.168.131.102

      - (Servidor 2):

      · 192.168.132.22 Slot 5 Port 0 -> SAN C1 P2 192.168.132.102
      · 192.168.133.22 Slot 5 Port 1 -> SAN C0 P3 192.168.133.101
      · NIC1 -> Red Local 192.168.1.22
      · NIC2 -> Cluster dedicada
      · 192.168.130.22 NIC3 -> SAN C1 P0 192.168.130.102
      · 192.168.131.22 NIC4 -> SAN C0 P1 192.168.131.101

      Recalco que las conexiones iSCSI se han hecho directamente, sin switch. Las pruebas de fallo las hemos hecho desconectando los cables de red.

      Ambos servidores tienen Windows Server 2012 R2 actualizado a día de hoy.

      Aprovecho para preguntarle si existe algún documento de buenas prácticas en cuanto a la configuración de Windows y su registro (me parece que para Equallogic sí existe) para optimizar y reducir el tiempo de conmutación por fallo.

      Gracias.

      Un saludo.

      • 9:34
    • mar, sep 8 2015
    • Hola,

      ¿Podría confirmar que el MDSM está instalado en ambos servidores?

      Gracias

      • 5:49
    • Correcto, está instalado en los dos servidores.

  • Hola,

    Según los logs a nivel de iSCSI la cabina está correctamente configurada y tiene todas las sesiones creadas.

    Lo que hemos podido ver es que los Jumbo Frames no están configurados en la cabina:

    Maximum transmission unit: 1500 bytes/frame

    por lo que tendría que configurarlo correctamente, los Jumbo Frames tienen que estar configurados tanto en el servidor como en la cabina.

    También hay otros puntos que pueden afectar al tiempo de balanceo de las LUNs:

    - Correcta configuración de la red en Windows 2012 R2, por ejemplo, una incorrecta configuración de DNS podría afectar.

    - Cómo está configurado el clúster.

    - Tipo de failover.

    Aún así lo importante sería que no haya una caída de servicio cuando se produce el balanceo.

    Tenga en cuenta que esta respuesta que ha recibido corresponde a una garantía ProSupport y sin embargo su cabina dispone de una garantía Básica que solo cubre el hardware, por lo que si está interesado en continuar recibiendo este tipo de soporte le recomiendo que actualice la garantía a ProSupport, yo mismo le puedo tramitar la actualización si está interesado.

    Un saludo

  • También le puede ser útil el documento sobre Best Practices:

    IP SAN Best Practices

    y la documentación de la cabina:

    Manuales y documentación para su PowerVault MD3200i

    Un saludo

  • Gracias David,

    Agradezco la respuesta.

    Para hacer pruebas conectamos un switch sin la posibilidad de configurar el parámetro MTU y por eso redujimos el valor de MTU de la cabina a 1500 olvidando el volverlo a aumentar para cuando extrajimos el fichero de soporte de la cabina. Me temo que no es el motivo por el que tiempo de conmutación sea de entre 20 y 60 segundos, en cualquier caso vamos a volver a realizar nuevamente las pruebas esta tarde para estar seguros.

    Sobre las otras cuestiones:

    - Correcta configuración de la red en Windows 2012 R2, por ejemplo, una incorrecta configuración de DNS podría afectar. Ambos servidores sólo tienen establecidos los servidores DNS y puerta de enlace en la interface de la red local.

    - Cómo está configurado el clúster. De momento todavía no hemos montado el cluster hasta resolver esta duda.

    - Tipo de failover. Hemos probado con Round Robin y Least Queue Depth pero el comportamiento es similar en cuanto al tiempo de conmutación.

    Sobre el contratar el servicio ProSupport, lo vamos a valorar, podría ser una buena alternativa. 

    Gracias por la documentación, el manual de la cabina y la documentación ya lo conocemos pero el documento de Best Practices nos será de utilidad.

    Por otro lado, realmente no sufrimos una caída del servicio sino una pausa hasta que se realiza la conmutación. Como ejemplo, podríamos decir que si realizamos una transferencia de un fichero a un volumen de la cabina y durante la transferencia desconectamos dos interfaces de red de las cuatro que dispone el servidor, la transferencia se pausa entre 20 y 60 segundos pero no se corta. Este tiempo es el que precisamente nos extraña y queríamos verificar que fuera normal.

    Gracias por su ayuda.

    Un saludo