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

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.

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.

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:

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.realm Parámetro opcional: en la mayoría de casos, el dominio kerberos 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.

• Parámetro opcional security.activeDirectory.netbiosDomainName: 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.

{
    ...
    "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"
                }
            },
            ...
        }
    }
}

• Parámetro opcional security.activeDirectory.enableAES Optional parameter: 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.

• security.activeDirectory.appOwners Pará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.appReaders Pará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:

• 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.

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>"

# 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.

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