Oyente de grupo de disponibilidad

Estoy buscando grupos de disponibilidad AlwaysOn. Cuanto más lo miro, más parece que el grupo de escucha de disponibilidad es un único punto de falla. ¿Dónde exactamente corre el oyente? ¿Un servidor separado, el servidor SQL primario, todos ellos?

Digamos que tengo una pila completa de aplicaciones en mi segundo centro de datos. ¿Cómo configuro los oyentes para que se ejecuten en ambos sitios y que las aplicaciones apunten a sus propias copias locales?

Estoy seguro de que me falta algo aquí, pero no sé qué.

sql-server sql-server-2012 availability-groups

— Tim Brigham
fuente

El oyente AG es un nombre de red virtual (VNN) o IP virtual (VIP).

Un oyente de grupo de disponibilidad es un nombre de red virtual (VNN) al que los clientes pueden conectarse para acceder a una base de datos en una réplica primaria o secundaria de un grupo de disponibilidad AlwaysOn.

Apunta las aplicaciones al oyente (que está registrado con DNS) y dirige el tráfico en el AG. Por lo tanto, a menos que todos sus DC caigan al mismo tiempo, su redundancia es la cantidad de servidores DC / DNS.

Una escucha de grupo de disponibilidad consta de un nombre de escucha del Sistema de nombres de dominio (DNS), la designación de puerto de escucha y una o más direcciones IP. Solo el protocolo TCP es compatible con la escucha del grupo de disponibilidad. El nombre DNS del oyente también debe ser único en el dominio y en NetBIOS. Cuando crea un nuevo oyente de grupo de disponibilidad, se convierte en un recurso en un clúster con un nombre de red virtual asociado (VNN), IP virtual (VIP) y dependencia del grupo de disponibilidad. Un cliente usa DNS para resolver el VNN en múltiples direcciones IP y luego intenta conectarse a cada dirección, hasta que una solicitud de conexión tenga éxito o hasta que la conexión solicite el tiempo de espera.

Este artículo de MSDN (del que cité) debería ser un buen punto de partida para lo que es exactamente un oyente AG.

https://msdn.microsoft.com/en-us/library/hh213417.aspx

— Kris Gruttemeyer
fuente

Gracias Kris Por alguna razón, tenía la impresión de que la entrada DNS apuntaba al grupo de disponibilidad, no que en realidad está actuando como tal. No importa cuántas veces leí ese documento, no se encontró. Efectivamente, siempre que tenga un DC en mi segundo centro de datos, estaré bien.

— Tim Brigham

Gracias Kris ¿Cuál es el propósito de tener estas IP de escucha? Posible explicar eso en términos simples

— Manivannan Nagarajan

Es un punto de conexión constante para aplicaciones y servicios. Con tecnologías como la duplicación, debe especificar el servidor secundario en su cadena de conexión si el primario no está disponible. Con el oyente, el nombre nunca cambia, solo los cambios principales debajo de él. Entonces, cuando fallas, el proceso es transparente y transparente (principalmente) para la aplicación.

— Kris Gruttemeyer

¿Cuál es la diferencia entre eso y el clúster ip?

— Edgar Allan Bayron

@EdgarAllanBayron: la IP del clúster es una IP interna utilizada por el propio WSFC. La IP de escucha es una IP diferente que permite la conectividad a SQL Server. Son 2 IP separadas.

— Kris Gruttemeyer

El oyente es un recurso de conmutación por error dentro del WSFC sobre el que se basa el AG. Seguirá la réplica principal a medida que falla, por lo que hay algo de redundancia en esa parte. Como se mencionó, el lado DNS se basa en su infraestructura AD y tiempo de actividad DNS.

En su ejemplo del centro de datos secundario, querrá configurar el WSFC como una configuración de subred múltiple, lo que le permitirá a su oyente mantener una IP en ambas subredes para centros de datos. Si el AG falla en el DC secundario, su escucha se activará en esa subred. Sus aplicaciones solo verán tiempo de inactividad para que la IP se conecte en ese DC secundario, y luego la réplica también se cambiará.