SQL Server Always On Availability Groups es la última tecnología de Microsoft para abordar las necesidades de alta disponibilidad y recuperación ante desastres de las organizaciones que usan SQL Server. Una gran ventaja de AlwaysOn es la capacidad de abordar HA y DR en una sola implementación. Experimentamos los siguientes beneficios clave de AlwaysOn:
Podemos agrupar bases de datos relacionadas como parte de un solo grupo de disponibilidad y hacer que se recuperen juntas en caso de que sea necesario. Esto es especialmente útil para aplicaciones que dependen de más de una base de datos, como Microsoft Office SharePoint, Microsoft Lync y Sage.
En comparación con las instancias de clúster de conmutación por error de SQL Server, encontramos que el almacenamiento como punto único de falla se ha eliminado, ya que cada instancia constituye una réplica tiene asignado su propio almacenamiento.
Con AlwaysOn, es posible configurar HA y DR a la vez. Esto se logra mediante la creación de clústeres de conmutación por error de Windows de varios sitios como base de su configuración de AlwaysOn. Realizar un cambio de rol cuando se usa AlwaysOn es significativamente más simple que hacerlo cuando se usa el envío de registros de transacciones.
Objetos de computadora
Active Directory (AD) es un tema muy amplio y no profundizaremos en los detalles en este artículo. Como puede adivinar, Active Directory es el servicio de directorio de Microsoft. En términos de redes informáticas, un servicio de directorio es una instalación que nos permite registrar, identificar y administrar todos los objetos dentro de una red de forma centralizada. Las entradas en los servicios de directorio asignan los nombres de los dispositivos de red a las direcciones IP correspondientes y otras propiedades en el directorio. Los objetos más comunes en un servicio de directorio (y en el AD de Microsoft) son Usuarios y Computadoras. Así como cada usuario en el dominio puede registrarse y administrarse desde Active Directory, cada computadora en el dominio también puede administrarse desde Active Directory. Así como se espera que cada usuario tenga una cuenta única en Active Directory, también lo es cada computadora.
En Active Directory, no todos los objetos de equipo se asignan a un equipo físico. Un objeto de computadora puede representar una computadora física (estación de trabajo o servidor), pero también puede representar algo que actúa como una computadora, como el nombre representativo de un clúster de Windows o el nombre virtual de un servicio de clúster (rol). Dichas representaciones también son únicas en Active Directory, al igual que los nombres de computadora normales.
CNO y VNO en WSFC
Cuando instala un clúster de conmutación por error de Windows, el instalador crea una entidad en Active Directory denominada objeto de nombre de equipo (CNO). Este CNO es la entidad principal creada en Active Directory para el clúster y representa el "Nombre del servidor" de todo el clúster. Posteriormente, otros objetos conocidos como Virtual Name Objects son creados por el CNO cuando realiza actividades tales como la creación de roles de clúster, grupos de disponibilidad o Oyentes del grupo de disponibilidad . Estos CNO y VNO tienen direcciones IP asociadas. Puede especificar estas direcciones al instalar el clúster o crear una nueva función de clúster o un agente de escucha. Para cada clúster, función y agente de escucha que cree, necesita un nombre de equipo único y una dirección IP única. La figura 1 muestra el paso durante el cual especifica el objeto de nombre de clúster y su dirección IP al configurar un clúster.
Los nombres que utiliza al configurar un clúster son completamente arbitrarios. Solo necesitan ser únicos. Sin embargo, se recomienda seguir las convenciones de nomenclatura de su organización para computadoras normales al crear CNO o VNO; esto ayuda a que la administración sea más fácil. También tiene sentido utilizar un bloque específico de direcciones IP que cubrirá todas las necesidades de direccionamiento de todo su clúster:el CNO y todos los VNO (roles) que desee crear.
Fig. 1 Asignación de nombre a dirección en un clúster
Permisos de dominio clave
El DBA o el administrador del sistema que realiza una instalación de clúster debe tener permiso para Crear objetos de computadora en el dominio de Active Directory. A su vez, después de crear el Objeto de nombre de equipo, el administrador del dominio debe otorgar los siguientes permisos al Objeto de nombre de equipo para que los roles (que dan como resultado Objetos de nombre virtual) se puedan crear correctamente en el clúster:
Crear objetos de computadora
Leer todas las propiedades
Sin estos permisos, es probable que reciba mensajes de error similares al siguiente cuando intente crear un rol (en el caso de AlwaysOn FCI ) o un Oyente (en el caso de AlwaysOn AG ):
Error durante la instalación del clúster de MS SQL Server:
El recurso de nombre de red de clúster 'SQL Network Name (EUK-SCCM-01)' no pudo crear su objeto de equipo asociado en el dominio 'domainname.com' por el siguiente motivo:No se pudo crear la cuenta de equipo.
El texto del código de error asociado es:Acceso denegado.
Este mensaje de error se observa en el Visor de eventos ya que no se puede acceder a SQL Server en este momento. También podrá ver esto si navega a los archivos de registro de errores de SQL en la carpeta LOG que se encuentra en el directorio de instalación de SQL Server. La frase clave es “Acceso denegado ”.
Otros requisitos
Debo mencionar el concepto de un controlador de dominio. Un controlador de dominio, o más precisamente, un conjunto de controladores de dominio proporciona servicios clave para Active Directory, como el registro de objetos y la autenticación de usuarios y equipos. Para configurar con éxito un clúster o un agente de escucha AlwaysOn, se debe poder acceder a un controlador de dominio desde la computadora donde está realizando la configuración. Esto significa que la comunicación entre la computadora y el controlador de dominio debe abrirse en un rango de puertos TCP y UDP. Microsoft documenta esto con gran detalle en este artículo . Esto puede ser un hecho en la mayoría de los casos, pero cuando se solucionan problemas de conectividad, es útil saber qué se necesita realmente.
En un artículo anterior , también mencioné que es necesario otorgar permisos al CNO de un clúster al configurar un File Share Quorum.
Fig. 2 Permisos en un recurso compartido de archivos
Una nota sobre la resolución de nombres
Al ser objetos de computadora, los CNO y los VNO dependen del servicio de nombres de dominio para resolver el nombre indicado al instalar el clúster, crear un rol o crear un agente de escucha AlwaysOn. Por lo general, los clientes reciben estos nombres de computadora para establecer una conexión con el clúster. En otras palabras, la dirección IP es transparente para ellos, lo que simplifica la configuración del cliente y abstrae las conmutaciones por error de los usuarios finales.
Fig. 3 Propiedades de agente de escucha AG para agentes de escucha con dos direcciones IP
En un artículo anterior, mencioné un caso en el que este escenario puede causar problemas. En nuestro clúster de sitios múltiples, teníamos un agente de escucha para nuestro grupo de disponibilidad AlwaysOn. Este agente de escucha se configuró para resolverse en dos direcciones IP. Esto es necesario para un clúster de varios sitios que abarca varias subredes. En tal configuración, el servidor de nombres devolverá ambas direcciones IP asignadas al oyente al emitir un nslookup comprobar (ver Fig. 4). Sin embargo, al conectarse, puede acceder solo a una de esas direcciones IP a la vez. Cluster Manager mostrará la otra dirección IP como Fuera de línea (ver Fig. 5).
Fig. 4 Propiedades de agente de escucha AG para agentes de escucha con dos direcciones IP
Fig. 5 propiedades para el rol de clúster con dos direcciones IP en subredes separadas
Esto es normal. Si hay una conmutación por error al sitio alternativo, el servidor DNS comienza a resolver la dirección IP alternativa después de unos minutos. La implicación de esto es que la comunicación de los clientes con el sitio alternativo debe ser posible. La Fig. 6 y la Fig. 7 resaltan esto aún más.
Fig. 6 Ruta de comunicación con la réplica principal en Dakar
Echemos un vistazo a la ruta que recorrerán los paquetes desde las computadoras cliente hasta el clúster. Cuando la réplica principal está en Dakar, el nombre de escucha SQL-SVR-LNR se resuelve en la dirección IP 192.168.1.20 y WFCS, a su vez, dirige la solicitud al servidor 192.168.1.22 (tenga en cuenta que este servidor también tiene su propia nombre de la computadora). En el caso de una conmutación por error a Nairobi, tenemos la ruta de comunicación que pasa por 192.168.2.20 y luego a 192.168.2.22. La implicación es que para una experiencia del cliente perfecta, todos los clientes en todos los centros de datos deben tener comunicación permitida en todos los firewalls involucrados usando el puerto 1433.
Fig. 7 Ruta de comunicación con la réplica principal en Nairobi
Conclusión
Si bien el clúster de conmutación por error de Windows, Active Directory y el servicio de nombres de dominio pueden estar fuera del rol del administrador de la base de datos, vale la pena tener una comprensión básica de cómo funcionan estas tecnologías para poder crear y solucionar problemas de AlwaysOn. Instancias de clúster de conmutación por error y grupos de disponibilidad AlwaysOn. Algunas organizaciones tienen una separación estricta de funciones entre los administradores del sistema y los administradores de bases de datos, pero cuando este no es el caso, el administrador de la base de datos debe poder comprender estos conceptos de Windows para tener éxito como DBA.
Referencias
Descripción general de los grupos de disponibilidad AlwaysOn
Clústeres de conmutación por error de Windows con SQL Server
Descripción general del servicio y requisitos del puerto de red para Windows
Administración de objetos informáticos
