Implementación del clúster de macrodatos de SQL Server en el modo de Active Directory

  • Artículo

En este artículo se describe cómo implementar el clúster de macrodatos de SQL Server en el modo de Active Directory. Para hacer los pasos descritos en este artículo se necesita acceso a un dominio de Active Directory. Antes de continuar, debe completar los requisitos descritos en Implementar clústeres de macrodatos de SQL Server en el modo 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.

Preparación de la implementación

Para la implementación de un clúster de macrodatos con integración de AD, hay cierta información adicional que se debe proporcionar para la creación de los objetos relacionados con el clúster de macrodatos en AD.

Con el uso del perfil kubeadm-prod, (o openshift-prod a partir de la versión CU5), tendrá automáticamente los marcadores de posición para la información relacionada con la seguridad y con el punto de conexión que se necesitan para la integración de AD.

Además, debe proporcionar las credenciales que los clústeres de macrodatos usarán para crear los objetos necesarios en AD. Estas credenciales se proporcionan como variables de entorno.

Tráfico y puertos

Compruebe que los firewalls o aplicaciones de terceros permiten los puertos necesarios para la comunicación de Active Directory.

Diagrama de tráfico entre el clúster de macrodatos y Active Directory. El controlador, el servicio de soporte técnico de seguridad y otros servicios de clúster se comunican a través de LDAP o Kerberos con los controladores de dominio. El servicio de proxy DNS de los clústeres de macrodatos servicio se comunica a través de DNS con los servidores DNS.

Las solicitudes se realizan en estos protocolos hacia y desde los servicios del clúster de Kubernetes al dominio de Active Directory, por lo que se debe permitir la entrada y salida en cualquier firewall o aplicación de terceros que escuche en los puertos necesarios tanto para TCP como para UDP. Los números de puerto estándar que usa Active Directory:

Servicio Port
DNS 53
LDAP
LDAPS		 389
636
Kerberos 88
Protocolo de cambio de contraseña de Kerberos/AD 464
Puerto de catálogo global
mediante LDAP
mediante LDAPS
3268
3269

Establecimiento de variables de entorno de seguridad

Las siguientes variables de entorno proporcionan las credenciales para la cuenta de servicio de dominio de Clústeres de macrodatos, que se usarán para configurar la integración de AD. Clústeres de macrodatos también usa esta cuenta para mantener en el futuro los objetos de AD relacionados.

export DOMAIN_SERVICE_ACCOUNT_USERNAME=<AD principal account name>
export DOMAIN_SERVICE_ACCOUNT_PASSWORD=<AD principal password>

Suministro de seguridad y parámetros de punto de conexión

Además de las variables de entorno para las credenciales, también debe proporcionar información de seguridad y de punto de conexión para que la integración de AD funcione. Los parámetros necesarios forman parte automáticamente del perfil de implementación de kubeadm-prod/openshift-prod.

La integración de AD necesita los parámetros siguientes. Agregue estos parámetros a los archivos control.json y bdc.json con los comandos config replace que se muestran más adelante en este artículo. Todos los ejemplos siguientes utilizan contoso.local de dominio de ejemplo.

  • security.activeDirectory.ouDistinguishedName: nombre distintivo de una unidad organizativa (UO) en la que se agregarán todas las cuentas de AD que cree la implementación del clúster. Si se llama al dominio contoso.local, el nombre distintivo de la UO será OU=BDC,DC=contoso,DC=local.

  • security.activeDirectory.dnsIpAddresses: contiene la lista de direcciones IP de los servidores DNS del dominio.

  • security.activeDirectory.domainControllerFullyQualifiedDns: lista de FQDN del controlador de dominio. El FQDN contiene el nombre de host o de la máquina del controlador de dominio. Si tiene varios controladores de dominio, aquí se puede proporcionar una lista. Ejemplo: HOSTNAME.CONTOSO.LOCAL.

    Importante

    Cuando hay varios controladores de dominio que atienden a un dominio, utilice el controlador de dominio principal (PDC) como primera entrada en la lista de domainControllerFullyQualifiedDns de la configuración de seguridad. Para obtener el nombre del PDC, escriba netdom query fsmo en el símbolo del sistema y luego presione Entrar.

  • security.activeDirectory.realmParámetro opcional: en la mayoría de casos, el dominio es igual al nombre de dominio. En los casos en los que no sean iguales, use este parámetro para definir el nombre del dominio kerberos (por ejemplo, CONTOSO.LOCAL). El valor proporcionado para este parámetro debe ser completo.

  • security.activeDirectory.netbiosDomainNameParámetro opcional: este es el nombre NETBIOS del dominio de AD. En la mayoría de los casos, será la primera etiqueta del nombre de dominio de AD. En caso contrario, use este parámetro para definir el nombre de dominio NETBIOS. Este valor no debe contener puntos. Normalmente, este nombre se usa para calificar las cuentas de usuario del dominio. Por ejemplo, CONTOSO\user, donde CONTOSO es el nombre de dominio NETBIOS.

    Nota:

    A partir de SQL Server 2019 CU9, se ha habilitado compatibilidad con una configuración en la que el nombre de dominio de Active Directory es diferente del nombre NETBIOS del dominio de Active Directory mediante el uso de security.activeDirectory.netbiosDomainName.

  • security.activeDirectory.domainDnsName: nombre del dominio DNS que se usará para el clúster (por ejemplo, contoso.local).

  • security.activeDirectory.clusterAdmins: este parámetro toma un grupo de AD. El ámbito del grupo de AD debe ser universal o global. Los miembros de este grupo tendrán el rol de clúster bdcAdmin, que les concederá permisos de administrador en el clúster. Esto significa que tendrán permisos de sysadmin en SQL Server, permisos de superuser en HDFS y permisos de administrador cuando se conecten al punto de conexión del controlador.

    Importante

    Cree este grupo en AD antes de comenzar la implementación. Si el ámbito de este grupo de AD es el dominio local, se produce un error en la implementación.

  • security.activeDirectory.clusterUsers: lista de los grupos de AD que son usuarios normales (sin permisos de administrador) en el clúster de macrodatos. La lista puede incluir grupos de AD cuyo ámbito sean grupos universales o globales. No pueden ser grupos de dominio local.

Los grupos de AD de esta lista se asignan al rol de clúster de macrodatos bdcUser y se les debe conceder acceso a SQL Server (vea Permisos de SQL Server) o a HDFS (vea Guía de permisos de HDFS). Al conectarse al punto de conexión del controlador, estos usuarios solo pueden mostrar los puntos de conexión disponibles en el clúster mediante el comando azdata bdc endpoint list.

A fin de obtener información detallada sobre cómo actualizar los grupos de AD para esta configuración, consulte Administración del acceso al clúster de macrodatos en el modo de Active Directory.

Sugerencia

Para habilitar la experiencia de exploración de HDFS cuando se conecta a SQL Server maestro en Azure Data Studio, se debe conceder a un usuario con el rol bdcUser permisos VIEW SERVER STATE, ya que Azure Data Studio usa la DMV sys.dm_cluster_endpoints para obtener el punto de conexión de la puerta de enlace de Knox requerido para conectarse a HDFS.

Importante

Cree estos grupos en AD antes de comenzar la implementación. Si el ámbito de cualquiera de estos grupos de AD es el dominio local, se produce un error en la implementación.

Importante

Si los usuarios del dominio cuentan con muchas pertenencias a grupos, debe ajustar los valores de la configuración de puerta de enlace httpserver.requestHeaderBuffer (el valor predeterminado es 8192) y la configuración de HDFS hadoop.security.group.mapping.ldap.search.group.hierarchy.levels (el valor predeterminado es 10), mediante el archivo de configuración personalizado de implementación bdc.json. Se trata de un procedimiento recomendado para evitar los tiempos de espera de conexión a las respuestas de puerta de enlace o HTTP con un código de estado 431 (Campos del encabezado de solicitud demasiado grandes). Esta es una sección del archivo de configuración que muestra cómo definir los valores de esta configuración y cuáles son los valores recomendados para un número mayor de pertenencias de grupo:

{
    ...
    "spec": {
        "resources": {
            ...
            "gateway": {
                "spec": {
                    "replicas": 1,
                    "endpoints": [{...}],
                    "settings": {
                        "gateway-site.gateway.httpserver.requestHeaderBuffer": "65536"
                    }
                }
            },
            ...
        },
        "services": {
            ...
            "hdfs": {
                "resources": [...],
                "settings": {
                  "core-site.hadoop.security.group.mapping.ldap.search.group.hierarchy.levels": "4"
                }
            },
            ...
        }
    }
}
  • security.activeDirectory.enableAES Optional parameterParámetro opcional: valor booleano que indica si AES 128 y AES 256 deben habilitarse en las cuentas de AD generadas automáticamente. El valor predeterminado es false. Cuando este parámetro se establece en true, las siguientes marcas "Esta cuenta admite cifrado AES de Kerberos de 128 bits" y "Esta cuenta admite cifrado AES de Kerberos de 256 bits" se comprobarán en los objetos de AD generados automáticamente durante la implementación del clúster de macrodatos.

Nota:

El parámetro security.activeDirectory.enableAES está disponible a partir de los clústeres de macrodatos de la CU13 de SQL Server Clústeres de macrodatos. Si el clúster de macrodatos tiene una versión anterior a la CU13, se requieren los pasos siguientes:

  1. Ejecute el comando azdata bdc rotate -n <your-cluster-name>, que rotará las keytabs en el clúster, lo que es necesario para asegurarse de que las entradas de AES en keytabs son correctas. Para más información, vea azdata bdc. Además, azdata bdc rotate rotará las contraseñas de los objetos de AD que se generaron automáticamente durante la implementación inicial en la unidad organizativa especificada.
  2. Establezca las siguientes marcas "Esta cuenta admite cifrado AES de Kerberos de 128 bits" y "Esta cuenta admite cifrado AES de Kerberos de 256 bits" en cada objeto de AD generado automáticamente en la unidad organizativa que proporcionó durante la implementación inicial del clúster de macrodatos. Esto se puede lograr mediante la ejecución del siguiente script Get-ADUser -Filter * -SearchBase '<OU Path>' | Set-ADUser -replace @{ 'msDS-SupportedEncryptionTypes' = '24' } de PowerShell en el controlador de dominio, que establece los campos de AES en cada cuenta de la unidad organizativa especificada en el parámetro <OU Path>.

Importante

Cree los grupos proporcionados para la configuración siguiente en AD antes de comenzar la implementación. Si el ámbito de cualquiera de estos grupos de AD es el dominio local, se produce un error en la implementación.

  • security.activeDirectory.appOwnersParámetro opcional: lista de grupos de AD que tienen permisos para crear, eliminar y ejecutar cualquier aplicación. La lista puede incluir grupos de AD cuyo ámbito sean grupos universales o globales. No pueden ser grupos de dominio local.

  • security.activeDirectory.appReadersParámetro opcional: lista de grupos de AD que tienen permisos para ejecutar cualquier aplicación. La lista puede incluir grupos de AD cuyo ámbito sean grupos universales o globales. No pueden ser grupos de dominio local.

En la tabla siguiente se muestra el modelo de autorización para la administración de aplicaciones:

Roles autorizados Comando de la CLI de datos de Azure (azdata)
appOwner azdata app create
appOwner azdata app update
appOwner, appReader azdata app list
appOwner, appReader azdata app describe
appOwner azdata app delete
appOwner, appReader azdata app run

  • security.activeDirectory.subdomain: Parámetro opcional Este parámetro se incluye en la versión SQL Server 2019 CU5 para admitir la implementación de varios clústeres de macrodatos en el mismo dominio. Con esta opción, puede especificar nombres DNS diferentes para cada uno de los clústeres de macrodatos implementados. Si el valor de este parámetro no se especifica en la sección Active Directory del archivo control.json, de forma predeterminada se usará el nombre del clúster de macrodatos (igual que el nombre del espacio de nombres de Kubernetes) para calcular el valor de la configuración de subdominio.

    Nota:

    El valor que se pasa mediante la configuración de subdominio no es un nuevo dominio de AD, sino solo un dominio DNS que el clúster de macrodatos usa de forma interna.

    Importante

    Debe instalar o actualizar la versión más reciente de la CLI de datos de Azure (azdata) a partir de la versión SQL Server 2019 CU5 para aprovechar estas capacidades nuevas e implementar varios clústeres de macrodatos en el mismo dominio.

    Vea Concepto: Implementación de clústeres de macrodatos de SQL Server en modo de Active Directory para obtener más información sobre la implementación de varios clústeres de macrodatos en el mismo dominio de Active Directory.

  • security.activeDirectory.accountPrefix: Parámetro opcional Este parámetro se incluye en la versión SQL Server 2019 CU5 para admitir la implementación de varios clústeres de macrodatos en el mismo dominio. Esta configuración garantiza la exclusividad de los nombres de cuenta de varios servicios de clúster de macrodatos, que deben ser diferentes entre cualquier par de clústeres. La personalización del nombre del prefijo de la cuenta es opcional; de forma predeterminada, el nombre del subdominio se usa como prefijo de la cuenta. Si el nombre de subdominio es mayor de 12 caracteres, los primeros 12 caracteres del nombre de subdominio se usan como el prefijo de la cuenta. 

    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 nos deja 12 caracteres como límite para el prefijo de la cuenta.

Compruebe el ámbito del grupo de AD, para determinar si es DomainLocal.

Si aún no ha inicializado el archivo de configuración de la implementación, puede ejecutar este comando para obtener una copia de la configuración. En los ejemplos siguientes se usa el perfil de kubeadm-prod y lo mismo se aplica a openshift-prod.

azdata bdc config init --source kubeadm-prod  --target custom-prod-kubeadm

Para establecer los parámetros anteriores en el archivo control.json, use los siguientes comandos de la CLI de datos de Azure (azdata). Los comandos reemplazan la configuración y proporcionan sus propios valores antes de que se realice la implementación.

Importante

En la versión SQL Server 2019 CU2, la estructura de la sección de configuración de seguridad del perfil de implementación ha cambiado ligeramente y todos los valores relacionados con Active Directory están en el nuevo directorio activeDirectory en el árbol de JSON, bajo security, en el archivo control.json.

Nota:

Además de proporcionar valores diferentes para el subdominio como se describe en esta sección, también debe usar otros números de puerto para los puntos de conexión de Clústeres de macrodatos al implementar varios clústeres de macrodatos en el mismo clúster de Kubernetes. Estos números de puerto son configurables en el momento de la implementación a través de los perfiles de configuración de implementación.

El ejemplo siguiente se basa en el uso de SQL Server 2019 CU2. Se muestra cómo reemplazar los valores de parámetros relacionados con AD en la configuración de implementación. Los detalles del dominio siguientes son valores de ejemplo.

azdata bdc config replace -c custom-prod-kubeadm/control.json -j "$.security.activeDirectory.ouDistinguishedName=OU\=bdc\,DC\=contoso\,DC\=local"
azdata bdc config replace -c custom-prod-kubeadm/control.json -j "$.security.activeDirectory.dnsIpAddresses=[\"10.100.10.100\"]"
azdata bdc config replace -c custom-prod-kubeadm/control.json -j "$.security.activeDirectory.domainControllerFullyQualifiedDns=[\"HOSTNAME.CONTOSO.LOCAL\"]"
azdata bdc config replace -c custom-prod-kubeadm/control.json -j "$.security.activeDirectory.domainDnsName=contoso.local"
azdata bdc config replace -c custom-prod-kubeadm/control.json -j "$.security.activeDirectory.clusterAdmins=[\"bdcadminsgroup\"]"
azdata bdc config replace -c custom-prod-kubeadm/control.json -j "$.security.activeDirectory.clusterUsers=[\"bdcusersgroup\"]"
#Example for providing multiple clusterUser groups: [\"bdcusergroup1\",\"bdcusergroup2\"]

Opcionalmente, solo a partir de la versión SQL Server 2019 CU5, puede invalidar los valores predeterminados para la configuración de subdomain y accountPrefix.

azdata bdc config replace -c custom-prod-kubeadm/control.json -j "$.security.activeDirectory.subdomain=[\"bdctest\"]"
azdata bdc config replace -c custom-prod-kubeadm/control.json -j "$.security.activeDirectory.accountPrefix=[\"bdctest\"]"

Del mismo modo, en las versiones anteriores a SQL Server 2019 CU2, puede ejecutar lo siguiente:

azdata bdc config replace -c custom-prod-kubeadm/control.json -j "$.security.ouDistinguishedName=OU\=bdc\,DC\=contoso\,DC\=local"
azdata bdc config replace -c custom-prod-kubeadm/control.json -j "$.security.dnsIpAddresses=[\"10.100.10.100\"]"
azdata bdc config replace -c custom-prod-kubeadm/control.json -j "$.security.domainControllerFullyQualifiedDns=[\"HOSTNAME.CONTOSO.LOCAL\"]"
azdata bdc config replace -c custom-prod-kubeadm/control.json -j "$.security.domainDnsName=contoso.local"
azdata bdc config replace -c custom-prod-kubeadm/control.json -j "$.security.clusterAdmins=[\"bdcadminsgroup\"]"
azdata bdc config replace -c custom-prod-kubeadm/control.json -j "$.security.clusterUsers=[\"bdcusersgroup\"]"
#Example for providing multiple clusterUser groups: [\"bdcusergroup1\",\"bdcusergroup2\"]

Además de la información anterior, también debe proporcionar nombres de DNS para los distintos puntos de conexión del clúster. Las entradas DNS que usan los nombres de DNS proporcionados se crearán automáticamente en el servidor DNS tras la implementación. Usará estos nombres al conectarse a los diferentes puntos de conexión del clúster. Por ejemplo, si el nombre DNS de la instancia maestra de SQL es mastersql y se tiene en cuenta que el subdominio usará el valor predeterminado del nombre del clúster en control.json, usará mastersql.contoso.local,31433 o mastersql.mssql-cluster.contoso.local,31433 (en función de los valores que se han proporcionado en los archivos de configuración de implementación para los nombres DNS del punto de conexión) a fin de conectarse a la instancia maestra desde las herramientas.

# DNS names for Big Data Clusters services
azdata bdc config replace -c custom-prod-kubeadm/control.json -j "$.spec.endpoints[0].dnsName=<controller DNS name>.contoso.local"
azdata bdc config replace -c custom-prod-kubeadm/control.json -j "$.spec.endpoints[1].dnsName=<monitoring services DNS name>.<Domain name. e.g. contoso.local>"
azdata bdc config replace -c custom-prod-kubeadm/bdc.json -j "$.spec.resources.master.spec.endpoints[0].dnsName=<SQL Master Primary DNS name>.<Domain name. e.g. contoso.local>"
azdata bdc config replace -c custom-prod-kubeadm/bdc.json -j "$.spec.resources.master.spec.endpoints[1].dnsName=<SQL Master Secondary DNS name>.<Domain name. e.g. contoso.local>"
azdata bdc config replace -c custom-prod-kubeadm/bdc.json -j "$.spec.resources.gateway.spec.endpoints[0].dnsName=<Gateway (Knox) DNS name>.<Domain name. e.g. contoso.local>"
azdata bdc config replace -c custom-prod-kubeadm/bdc.json -j "$.spec.resources.appproxy.spec.endpoints[0].dnsName=<app proxy DNS name>.<Domain name. e.g. contoso.local>"

Importante

Puede usar los nombres DNS del punto de conexión que prefiera, siempre y cuando estén completos y no entren en conflicto entre dos clústeres de macrodatos implementados en el mismo dominio. Opcionalmente, puede usar el valor del parámetro subdomain para garantizar que los nombres DNS son diferentes en los clústeres. Por ejemplo:

# DNS names for Big Data Clusters services
azdata bdc config replace -c custom-prod-kubeadm/control.json -j "$.spec.endpoints[0].dnsName=<controller DNS name>.<subdomain e.g. mssql-cluster>.contoso.local"

Puede encontrar un script de ejemplo aquí para la implementación de un clúster de macrodatos de SQL Server en un clúster de Kubernetes de un solo nodo (kubeadm) con integración de AD.

Nota:

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 la 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 Active Directory de control.json. Este es el comando para hacerlo:

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

Ahora debe haber establecido todos los parámetros necesarios para una implementación de Clústeres de macrodatos con la integración de Active Directory.

Ya puede implementar el clúster de macrodatos integrado con Active Directory mediante el comando de la CLI de datos de Azure (azdata) y el perfil de implementación kubeadm-prod. Para obtener la documentación completa sobre cómo implementar clústeres de macrodatos, consulte Procedimientos para implementar Clústeres de macrodatos de SQL Server en Kubernetes.

Comprobación de la entrada de DNS inverso para el controlador de dominio

Asegúrese de que haya una entrada de DNS inverso (registro PTR) para el propio controlador de dominio registrada en el servidor DNS. Puede ejecutar el elemento nslookup de la dirección IP del controlador de dominio para comprobar que se pueda resolver en la dirección FQDN del controlador de dominio.

Limitaciones y problemas conocidos

Limitaciones que deben tenerse en cuenta en SQL Server 2019 CU5

  • Actualmente, los paneles Búsqueda de registros y Métricas no admiten la autenticación de AD. El nombre de usuario y la contraseña básicos establecidos tras la implementación se pueden usar para la autenticación en estos paneles. El resto de puntos de conexión del clúster admiten la autenticación de AD.

  • El modo de AD seguro solo funcionará en entornos de implementación de kubeadm y openshift, pero no en AKS o en ARO por el momento. Los perfiles de implementación de kubeadm-prod y openshift-prod incluyen las secciones de seguridad de forma predeterminada.

  • Antes de la versión SQL Server 2019 CU5 solo se permitía un clúster de macrodatos por dominio (Active Directory). La habilitación de varios clústeres de macrodatos por dominio está disponible a partir de la versión CU5.

  • Ninguno de los grupos de AD especificados en las configuraciones de seguridad puede tener definido el ámbito DomainLocal. Puede comprobar el ámbito de un grupo de AD siguiendo estas instrucciones.

  • Las cuentas de AD que se pueden usar para iniciar sesión en el clúster de macrodatos se permiten desde el mismo dominio que se ha configurado para Clústeres de macrodatos de SQL Server. No se admite la habilitación de inicios de sesión desde otro dominio de confianza.

Pasos siguientes

Conexión de Clústeres de macrodatos de SQL Server: Modo de Active Directory

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

Concepto: Implementación de Clústeres de macrodatos de SQL Server en modo de Active Directory