Problema del conmutador de latido del clúster de Cisco Catalyst: aumento de los errores de entrada

PROBLEMA: los servidores en dos clústeres siguen perdiendo conectividad de latidos entre sí, lo que provoca interrupciones en la base de datos. Las interrupciones son breves pero perjudiciales.

PREPARAR:

• Hay dos grupos de tres servidores cada uno.
• Cada servidor tiene una NIC conectada a un único conmutador de capa 2 (Catalyst 2950) con los puertos del conmutador codificados a 100Mb / full-duplex.
• Los DBA confirman que cada NIC de latido está codificada en 100Mb / full-duplex.
• Hay dos clústeres configurados en la VLAN 100 y en la misma subred (10.40.60.0/24).
• La dirección IP de administración está en una subred separada (10.40.1.0/24) y su puerto de conmutación está en la VLAN 1.

SINTOMAS:

• Veo un recuento de errores cada vez mayor en los puertos del conmutador. Para los tres servidores en un clúster, los errores de entrada (todos los CRC) son aproximadamente el 3% del total de los paquetes de entrada. No hay errores de salida. El otro clúster tiene aproximadamente el 6% del total de paquetes de entrada.
• La carga de transmisión y recepción en los puertos del conmutador es ligera, inferior a 20/255 en txload y rxload.
• El registro del conmutador muestra los puertos del conmutador rebotando:

  16 de mayo 11:15:31 PDT:% LINEPROTO-5-UPDOWN: Protocolo de línea en la interfaz FastEthernet0 / 13, cambio de estado a inactivo
  16 de mayo 11:15:32 PDT:% LINK-3-UPDOWN: Interfaz FastEthernet0 / 13, cambiado estado hacia abajo
  16 de mayo 11:15:34 PDT:% LINK-3-UPDOWN: Interfaz FastEthernet0 / 13, estado cambiado a arriba
  16 de mayo 11:15:35 PDT:% LINEPROTO-5-UPDOWN: Protocolo de línea en la interfaz FastEthernet0 / 13, cambio de estado a arriba

PASOS PARA LA SOLUCIÓN DE PROBLEMAS REALIZADOS:

• Reemplacé el viejo cableado Cat5 entre la NIC de latido del servidor y el conmutador con el nuevo Cat6, sin efecto.
• Creé una nueva VLAN 200 en una nueva subred (10.40.61.0/24) y los DBA volvieron a IP sus NIC de latido en un clúster, sin efecto.
• Probamos todas las combinaciones de velocidad y dúplex en el puerto del conmutador y la NIC; sin efecto, volvimos a 100Mb / dúplex completo en ambos.
• Los DBA actualizaron los controladores de Broadcom en ambos clústeres al último: caída del porcentaje de error en el clúster del 6% hasta el 4%, el otro clúster todavía está en el 3%.

MIS SIGUIENTES PASOS PROPUESTOS:

• Hay NIC de Intel en los servidores. Intente mover el latido del clúster a una NIC Intel. Tal vez es un problema de Broadcom?
• Cambie el interruptor a un interruptor capaz de conciertos. Hay un Catalayst 3560x disponible, pero tomarlo retrasará un proyecto. ¿Tal vez tocar en el puerto del switch y NIC funcionará mejor?

PENSAMIENTOS

¿Hay algo que pueda configurar en el conmutador 2950 existente para mitigar los errores? ¿Qué pasos adicionales de solución de problemas debo tomar?

Los errores de CRC a menudo son problemas de cableado. Estas son las cosas que comprobaría a continuación antes de cambiar el hardware:

• ¿Los servidores están conectados directamente al conmutador o se conectan a través de algún tipo de cableado de infraestructura? Si es así, vuelva a certificar los cables de infraestructura.
• Si tiene un probador de cable real (no un simple probador de continuidad), probaría los cables.
• Si los cables están hechos a mano, los reemplazaría con cables hechos en fábrica. A menudo se encuentran con este tipo de problemas con cables hechos a mano.
• Verifique si hay alguna fuente de EM cerca de donde corren los cables. Vuelva a colocar los cables si puede, incluso temporalmente, para asegurarse de que se mantengan separados de la alimentación u otras fuentes de EM.

Más allá de eso, comenzaría en las NIC como ya indicó. Podría ser que obtuviste algo de una mala carrera.

Recomendaría probar al pasar a la NIC de Intel como lo ha propuesto. Me he encontrado con problemas similares donde un pequeño porcentaje del tráfico eran errores de entrada. Hemos solucionado el problema colocando un hub tonto entre el servidor (en mi caso eran cámaras) y el interruptor. Si el conmutador ya no ve ningún error de entrada, entonces el problema es la NIC del servidor.

Intenté muchos de los mismos pasos que usted ha propuesto. En mi caso, resultó ser una mala ejecución de fabricación. Lo único que corrigió el problema fue reemplazar la NIC (cámaras).