Recientemente me encontré con un problema interesante en mi ACI Fabric que fue detectado por el equipo que administra el SQL Server, la falla era en la solución de failover, como no encontré mucha información disponible al respecto, pensé en compartir mi experiencia. Antes de comenzar hablar del escenario debemos comprender varios conceptos básicos de SQL Server que desconocía como Listener.
Visión general de SQL Server Always On Listeners
Voy a tratar de explicar lo mas breve posible este ambiente , como pueden observar en la imagen tenemos 2 placas de red por cada instancia, la primera placa de red vamos a llamarla de pública esta hace la comunicación en todo el dominio y la segunda placa de red tiene el nombre de Heartbeat está placa sirve única e exclusivamente para comunicación entre los servidores que forman parte del CLUSTER con diferentes direcciones IPs, estas placas son encargadas de enviar una señal entre ellas si el Cluster pierde comunicación entenderá que hay un problema de indisponibilidad y como tal deberá llevar toda la sesión de la instancia 1 (donde se ejecula SQL Server ) para la segunda instancia de forma automática. Recordando que el ambiente e SQL Server debe ser instalada dentro de la solución Microsof Windows Server Failover Clustering (WSFC) para poder tener un entorno de alta disponibilidad, como pueden concluir sera necesario de un Controlador de Dominio para poder implementar dicha solución.
Que es una Availability Group (AG) Listener
Un Availability Group Listener es un nombre de red virtual (VNN) al que los clientes pueden conectarse para acceder a una base de datos principal o réplica secundaria de un grupo de alta disponibilidad Always On. Un Listener permite que un cliente se conecte a una réplica sin tener que conocer el nombre de la instancia física de SQL Server. Dado que el listener enruta el tráfico, no es necesario modificar la cadena de conexión del cliente después de que se produzca una conmutación por error.
Un Availability Group Listener consta de un nombre de listener del Sistema de nombres de dominio (DNS), la designación del puerto listener y una o más direcciones IP. Solamente el protocolo TCP soporta Availability Group Listener . El nombre DNS del Listener debe ser único en el dominio y en NetBIOS. Cuando crea un Listener , se convierte en un recurso del clúster asociado a un virtual network name (VNN), una IP virtual (VIP) y una dependencia de Availability Group Listener. Un cliente usa DNS para resolver el VNN en múltiples direcciones IP y luego intenta conectarse a cada dirección, hasta que un la solicitud de conexión tiene éxito o hasta que se agote el tiempo de espera de las solicitudes de conexión.
Si el enrutamiento de solo lectura está configurado para una o más réplicas secundarias legibles, las conexiones de cliente de intento de lectura al Listener se redireccionan automáticamente a una réplica secundaria legible. Este artículo proporciona una descripción general de un availability group Listener. También puede configurar el Listener y luego obtener información sobre cómo conectarse al availability group Listener.
El Availability Group Listener consta de los siguientes objetos
un nombre del sistema de nombres de dominio (DNS)
un puerto Listener
Una o varias direcciones IP (VIP)
Ejemplo:
DNS: salesag.mscorp.com
Puerto: 1433
IP: estática o DHCP
El Listener siempre es propiedad de la instancia de SQL Server donde reside la réplica primaria. En el momento de la conmutación por error, la réplica secundaria será la propietaria del listener.
Ahora que entendemos el porque de la falla en nuestro datacenter vamos a retornar al asunto del ACI jejeje como así es que toda la historia se vuelve un poco mas emocionante puesto que es es lo que veo diariamente, visto el escenario la explicación del lado del ACI seria que la falla provocada en SQL Server esta luego de accionarse el failover, eso quiere decir que el listener envía un ARP gratuito como era de esperarse, pero el switch leaf no muestra ningún GARP siendo recibido y esto llevó a realizar una limpieza de la tabla ARP y la activación de L2 unicast flood y como era de esperar la falla fue solucionada en una primera instancia, leyendo veo que tenemos otra alternativa y es el motivo de este articulo, a continuación explico los cambios a realizar en la herramienta ACI, ya que como todos sabemos la solución se realizó la limpieza de la tabla ARP y la activación L2 unicast Flood.
Antes
Despues
Estas capturas de pantalla son de un APIC Versión 4.2.
Explicación de la nueva solución:
El comportamiento natural de un ACI Fabric es aprender todo por medio de búsquedas UDP únicast en la base de datos de puntos finales (endpoints) ubicada en los Spines y como tal no hay necesidad de difundir o inundar un ARP. Sin embargo, como Microsof Windows Failover Clustering (MWFC), tenemos que aprender basándonos en GARP. Un GARP (Gratuitous ARP) es utilizado por los dispositivos de la red como una forma de actualizar proactivamente la caché ARP para hacer saber a otros dispositivos que la ubicación de una dirección MAC ha cambiado. Para que Fabric aprenda los movimientos de los EPGs a través de GARP, necesitamos habilitar algunas características no predeterminadas en el Bridge Domain (BD) asociado con el Endpoint Group (EPG), estas funciones son de "ARP Flooding" y "EP Move Detection Mode" (Modo de detección GARP).
Conclusión
- Failover es cuando una computadora falla inesperadamente o se apaga deliberadamente, la agrupación de los clústeres garantiza que los procesos y servicios que se ejecutarán se muevan a otra máquina, es decir, "conmuten por error" el clúster. Esto sucede sin interrupción ni necesidad de intervención inmediata del administrador, lo que brinda una solución de alta disponibilidad, lo que significa que los datos críticos siempre están disponibles.
- GARP se utiliza para actualizar la direcciones IP y MAC en dispositivos de red. Es más relevante en el caso de vmotions o VM/servers que se mueven de un host a otro, y la dirección MAC cambia, pero la IP sigue siendo la misma.
- En el contexto de ACI Fabric, los leaf switches pueden detectar el movimiento de direcciones MAC e IP entre puertos leaf switches, bridge domain y EPGs (Endpoint Group), pero no detecta el cambio de una dirección IP asignada a una nueva dirección MAC y si la nueva dirección MAC esta asociada a la dirección IP antigua al mismo modo si ella esta en la misma interfaz y/o EPG de la antigua dirección MAC.
- Cuando activamos la opción de detección basada en GARP (configuración realizada en el Brigde Domain), Cisco ACI activará un cambio en los EPGs basado en paquetes GARP y verificara si esta ocurre en la misma interfaz y/o EPG. Si un paquete GARP proviene de la misma interfaz y/o EPG, el aprendizaje del EPG será activada solo cuando el Unicast Routing, "ARP Flooding" y "GARP" se encuentren todos habilitados en el Bridge Domain.
Bueno amigos espero que este post ayude mucho y decirles que me he imposible traducir algunas palabras por cuestiones obvias y espero su comprensión del asunto. Buen inicio de Semana y deja tu like si quieres que siga escribiendo mas casos sobre el tema.
