Implementación de varios clústeres de macrodatos de SQL Server en el mismo dominio de Active Directory

  • Artículo

Se aplica a: SQL Server 2019 (15.x)

En este artículo se explican las actualizaciones de SQL Server Actualización acumulativa 5 (CU5) de SQL Server 2019, que permite la configuración de varios Clústeres de macrodatos de SQL Server 2019. Ahora se pueden implementar e integrar varios Clústeres de macrodatos con el mismo Dominio de Active Directory.

Importante

El complemento Clústeres de macrodatos de Microsoft SQL Server 2019 se va a retirar. La compatibilidad con Clústeres de macrodatos de SQL Server 2019 finalizará el 28 de febrero de 2025. Todos los usuarios existentes de SQL Server 2019 con Software Assurance serán totalmente compatibles con la plataforma, y el software se seguirá conservando a través de actualizaciones acumulativas de SQL Server hasta ese momento. Para más información, consulte la entrada de blog sobre el anuncio y Opciones de macrodatos en la plataforma Microsoft SQL Server.

Antes de SQL Server 2019 CU5 dos problemas impedían la implementación de varios Clústeres de macrodatos en dominios AD.

  • Un conflicto de nomenclatura para los nombres de entidades de seguridad de servicio y el dominio DNS
  • Nombre principal de la cuenta de dominio

¿Qué son las colisiones de nombres de objetos?

Conflicto de nombres de entidades de seguridad de servicio(SPN) y nombres de dominio DNS

El nombre de dominio proporcionado en la implementación se utiliza como Dominio DNS Dominio de Active Directory (AD). Esto significa que los pods pueden conectarse entre sí dentro de la red interna utilizando este dominio DNS. Los usuarios también se conectan a los puntos de conexión del clúster de macrodatos utilizando este dominio DNS. Como resultado, cualquier nombre de entidad de seguridad de servicio (SPN) creado para un servicio dentro del clúster de macrodatos tiene el nombre del punto de conexión, servicio o pod de Kubernetes calificado con este dominio DNS de AD. Si un usuario implementa un segundo clúster en el dominio, los SPN generados tienen el mismo FQDN, ya que los nombres de pods así como los nombres de dominio DNS no difieren entre clústeres. Considere un caso en el que el dominio DNS de AD es contoso.local. Uno de los SPN generados para SQL Server del grupo maestro en el pod master-0 es MSSQLSvc/master-0.contoso.local:1433. En el segundo clúster, el usuario intenta realizar la implementación, el nombre del pod de master-0 es el mismo. El usuario proporciona el mismo dominio DNS de AD (contoso.local) lo que da lugar a la misma cadena SPN. Active Directory prohíbe la creación de un SPN en conflicto que condujese a un error de implementación para el segundo clúster.

Nombre principal de la cuenta de dominio

Durante la implementación de un clúster de macrodatos con un dominio de Active Directory, se generan varias entidades de seguridad de cuenta para los servicios que se ejecutan dentro del clúster de macrodatos. Son esencialmente cuentas de usuario de AD. Antes de SQL Server 2019 CU5, los nombres de dichas cuentas no eran únicos entre los clústeres. Este manifiesto intenta crear el mismo nombre de cuenta de usuario para un servicio determinado del clúster de macrodatos en dos clústeres diferentes. El segundo clúster que se implementa experimenta un conflicto en AD y la cuenta no se puede crear.

Cómo resolver colisiones de nombres

Pasos para resolver problemas de dominio de SPN y DNS: SQL Server 2019 CU5

Los SPN deben ser únicos en clústeres. El nombre de dominio DNS introducido en el momento de la implantación también debe ser diferente. Puede especificar diferentes nombres DNS mediante la configuración que acaba de introducir en el archivo de configuración de la implementación: subdomain. Si el subdominio es diferente en dos clústeres y se puede producir una comunicación interna a través de este subdominio, los SPN incluirán el subdominio que consigue la exclusividad necesaria.

Nota

El valor que se pasa a través de la configuración de subdominio no es un nuevo dominio de AD, sino un dominio DNS que se usa internamente.

Volvamos al caso del grupo maestro SQL Server SPN. Si el subdominio es bdc, el SPN discutido se cambia a MSSQLSvc/master-0.bdc.contoso.local:1433.

Se usa el nombre del clúster de macrodatos o del espacio de nombres para calcular el valor de la configuración del subdominio. Opcionalmente, puede personalizar el valor del parámetro de subdominio recién introducido en la especificación de configuración de Active Directory. Cuando los usuarios quieren invalidar el nombre del subdominio, pueden hacerlo mediante el nuevo parámetro de subdominio en la especificación de configuración de Active Directory.

Cómo garantizar la unicidad del nombre de cuenta

Para actualizar los nombres de cuenta y garantizar la unicidad, use los prefijos de cuenta. El prefijo de la cuenta es un segmento del nombre de la cuenta que es único entre dos clústeres cualquiera. El segmento restante del nombre de la cuenta puede ser constante. El nuevo formato de nombre de cuenta tiene el siguiente aspecto: <prefix>-<name>-<podId>.

Nota:

Active Directory requiere que los nombres de cuenta se limiten a 20 caracteres. El clúster de macrodatos debe usar 8 de estos caracteres para distinguir entre pods y StatefulSets. Esto deja 12 caracteres para el prefijo de la cuenta.

Tiene la opción de personalizar el nombre de la cuenta. Use el parámetro accountPrefix en las especificaciones de configuración de Active Directory. SQL Server 2019 CU5 incorpora accountPrefix en las especificaciones de configuración. De forma predeterminada, el nombre del subdominio se usa como prefijo de la cuenta. Si el nombre de subdominio es mayor de 12 caracteres, la subcadena inicial de 12 caracteres del nombre de subdominio se usa como prefijo de una cuenta.

El subdominio solo se aplica al DNS. Por lo tanto, el nombre de la nueva cuenta de usuario de LDAP es bdc-ldap@contoso.local. El nombre de la cuenta no es bdc-ldap@bdc.contoso.local.

Semántica

A continuación, se muestran los parámetros agregados en SQL Server 2019 CU5 para configurar varios clústeres en un dominio:

subdomain

  • Campo opcional
  • Tipo de datos: cadena
  • Definición: un subdominio DNS único que se usará para este clúster de macrodatos. Este valor debe ser diferente para cada clúster que se implemente en el dominio de Active Directory.
  • Valor predeterminado: cuando no se proporciona, se usa el nombre del clúster como valor predeterminado.
  • Longitud máxima: 63 caracteres por etiqueta (siendo la etiqueta cada cadena separada por un punto).
  • Comentarios: los nombres DNS del punto de conexión deben usar el subdominio de su FQDN.

accountPrefix

  • Campo opcional
  • Tipo de datos: cadena
  • Definición: un prefijo único para las cuentas de AD que generará el clúster de macrodatos. Este valor debe ser diferente para cada clúster que se implemente en el dominio de Active Directory.
  • Valor predeterminado: cuando no se proporciona, se usa el nombre del subdominio como valor predeterminado. Cuando no se proporciona el subdominio, se usa el nombre del clúster como el nombre del subdominio y, por tanto, el nombre del clúster también se heredará como accountPrefix. Si se proporciona el subdominio y es un nombre de varias partes (contiene uno o más puntos), el usuario debe proporcionar un accountPrefix.
  • Longitud máxima: 12 caracteres

Ajustes del dominio AD y del servidor DNS

No se necesita ningún cambio en el dominio de AD ni en el controlador de dominio para dar cabida a la implementación de varios clústeres de macrodatos en el mismo dominio de Active Directory. El subdominio DNS se creará automáticamente en el servidor DNS cuando registre los nombres DNS de punto de conexión externos.

Cambios en el archivo de configuración de implementación

La sección activeDirectory de la configuración del plano de control control.json tiene dos nuevos parámetros opcionales: subdomain y accountPrefix. El nombre del clúster se usa para cada uno de estos parámetros. Proporcione nuevos valores para esta configuración si desea invalidar el comportamiento predeterminado. El nombre del clúster es el mismo que el nombre del espacio de nombres.

Tiene la opción de usar cualquier nombre DNS de punto de conexión, siempre y cuando esté completo. Tampoco puede entrar en conflicto con ningún otro clúster de macrodatos implementado en el mismo dominio. Puede usar el valor del parámetro del subdominio para asegurarse de que los nombres DNS son diferentes en todos los clústeres. Considere el punto de conexión de puerta de enlace. Puede usar el nombre gateway del punto de conexión y registrarlo en el servidor DNS automáticamente. Para ello como parte de la implementación del clúster de macrodatos, use gateway.bdc1.contoso.local como nombre DNS. Si bdc1 es el subdominio y contoso.local es el nombre de dominio DNS de AD. Otros valores aceptables son gateway-bdc1.contoso.local o simplemente gateway.contoso.local.

Algunos ejemplos de configuración de seguridad de Active Directory

El siguiente es un ejemplo de configuración de seguridad de Active Directory, en caso de que quiera invalidar subdomain y accountPrefix.

    "security": { 
        "activeDirectory": { 
            "ouDistinguishedName":"OU=contosoou,DC=contoso,DC=local", 
            "dnsIpAddresses": [ "10.10.10.10" ], 
            "domainControllerFullyQualifiedDns": [ "contoso-win2016-dc.contoso.local" ], 
            "domainDnsName":"contoso.local", 
            "subdomain": "bdc", 
            "accountPrefix": "myprefix", 
            "clusterAdmins": [ "contosoadmins" ], 
            "clusterUsers": [ "contosousers1", "contosousers2" ] 
        } 
    }

El siguiente es un ejemplo de especificación del punto de conexión para los puntos de conexión del plano de control. Puede usar cualquier valor para los nombres DNS, siempre que sean únicos y completos:

        "endpoints": [ 
            { 
                "serviceType": "NodePort", 
                "port": 30080, 
                "name": "Controller", 
                "dnsName": "control-bdc1.contoso.local" 
            }, 
            { 
                "serviceType": "NodePort", 
                "port": 30777, 
                "name": "ServiceProxy", 
                "dnsName": "monitor-bdc1.contoso.local" 
            } 
        ]

Preguntas

¿Necesita crear unidades organizativas independientes para diferentes clústeres?

No es necesario, pero es recomendable. Proporcionar unidades organizativas independientes para clústeres independientes ayuda a administrar las cuentas de usuario generadas.

¿Cómo puedo revertir al comportamiento anterior a la versión 5 en SQL Server 2019?

Puede haber escenarios en los que no pueda adaptar el parámetro subdomain recientemente introducido. Por ejemplo, debe implementar una versión anterior a CU5 y ya se ha actualizado CLI de datos de Azure (azdata). Esto es muy improbable, pero si necesita revertir al comportamiento anterior a CU5, puede establecer el parámetro useSubdomain en false en la sección de Active Directory de control.json.

En el siguiente ejemplo se establece useSubdomain en false para este escenario.

azdata bdc config replace -c custom-prod-kubeadm/control.json -j "$.security.activeDirectory.useSubdomain=false"

Pasos siguientes

Solución de problemas de integración de Active Directory de un Clúster de macrodatos de SQL Server