Compartir por


Implementación de Clústeres de macrodatos de SQL Server en el entorno local de OpenShift y Red Hat OpenShift en Azure

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

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.

En este artículo se explica cómo implementar un clúster de macrodatos de SQL Server en entornos de OpenShift, en el entorno local o en Red Hat OpenShift en Azure (ARO).

Sugerencia

Si busca una forma rápida de arrancar un entorno de ejemplo mediante ARO y luego tener el BDC implementado en esta plataforma, puede usar el script de Python disponible aquí.

Puede implementar clústeres de macrodatos en OpenShift en el entorno local o en Red Hat OpenShift en Azure (ARO). Valide la versión CRI-O de OpenShifts con las configuraciones probadas en las Notas de la versión de Clústeres de macrodatos de SQL Server. Aunque el flujo de trabajo de implementación es similar a la implementación en otras plataformas basadas en Kubernetes (kubeadm y AKS), existen algunas diferencias. La diferencia que hay está principalmente relacionada con la ejecución de aplicaciones como un usuario no raíz y el contexto de seguridad usado para el espacio de nombres en el que se implementa el BDC.

Para implementar el clúster de OpenShift en el entorno local, vea la Documentación de Red Hat OpenShift. Para las implementaciones de ARO, vea Red Hat OpenShift en Azure.

En este artículo se describen los pasos de implementación específicos de la plataforma OpenShift, se indican las opciones que tiene para acceder al entorno de destino y el espacio de nombres que se usa para implementar el clúster de macrodatos.

Requisitos previos

Importante

Los requisitos previos que se indican a continuación los debe realizar un administrador de clústeres de OpenShift (rol de clúster administrador de clústeres) que tenga permisos suficientes para crear estos objetos de nivel de clúster. Para obtener más información sobre los roles de clúster en OpenShift, vea Usar RBAC para definir y aplicar permisos.

  1. Asegúrese de que el valor pidsLimit de OpenShift se actualiza para adaptarse a las cargas de trabajo de SQL Server. El valor predeterminado de OpenShift es demasiado bajo para cargas de trabajo similares a las de producción. Comience con al menos 4096, aunque el valor óptimo depende del parámetro max worker threads de SQL Server y del número de procesadores de CPU en el nodo de host de OpenShift.

    • A fin de averiguar cómo actualizar pidsLimit para el clúster de OpenShift, use estas instrucciones. Tenga en cuenta que las versiones de OpenShift anteriores a la 4.3.5 tuvieron un defecto que hacía que el valor actualizado no surtiera efecto. Asegúrese de actualizar OpenShift a la versión más reciente.
    • Para ayudarle a calcular el valor óptimo en función de su entorno y de las cargas de trabajo de SQL Server previstas, puede usar la estimación y los ejemplos siguientes:
    Número de procesadores Máximo de subprocesos de trabajo predeterminados Trabajos predeterminados por procesador Valor mínimo de pidsLimit
    64 512 16 512 + (64 *16) = 1536
    128 512 32 512 + (128*32) = 4608

    Nota

    Otros procesos (por ejemplo, copias de seguridad, CLR, Fulltext y SQLAgent) también agregan cierta sobrecarga, por lo que debe agregar un búfer al valor estimado.

  2. Descargue la restricción de contexto de seguridad personalizada (SCC) bdc-scc.yaml:

    curl https://raw.githubusercontent.com/microsoft/sql-server-samples/master/samples/features/sql-big-data-cluster/deployment/openshift/bdc-scc.yaml -o bdc-scc.yaml
    
  3. Aplique dicha restricción al clúster.

    oc apply -f bdc-scc.yaml
    

    Nota

    La SCC personalizada para el BDC se basa en la SCC nonroot integrada en OpenShift, con permisos adicionales. Para obtener más información sobre las restricciones de contexto de seguridad en OpenShift, vea Administrar restricciones de contexto de seguridad. Para obtener información detallada sobre los permisos adicionales necesarios para los clústeres de macrodatos en la SCC nonroot, descargue las notas del producto aquí.

  4. Creación de un espacio de nombres o proyecto:

    oc new-project <namespaceName>
    
  5. Enlace la SCC personalizada a las cuentas de servicio del espacio de nombres en el que se implemente el BDC:

    oc create clusterrole bdc-role --verb=use --resource=scc --resource-name=bdc-scc -n <namespaceName>
    oc create rolebinding bdc-rbac --clusterrole=bdc-role --group=system:serviceaccounts:<namespaceName>
    
  6. Asigne el permiso adecuado al usuario que implementa el BDC. Realice una de las acciones siguientes.

    • Si el usuario que implementa el BDC tiene el rol de administrador de clústeres, continúe en implementación del clúster de macrodatos.

    • Si el usuario que implementa el BDC es un administrador de espacio de nombres, asigne el rol local de administrador de clústeres de usuario para el espacio de nombres creado. Esta es la opción preferida para que el usuario que implementa y administra el clúster de macrodatos tenga permisos de administrador de nivel de espacio de nombres.

    oc create rolebinding bdc-user-rbac --clusterrole=cluster-admin --user=<userName> -n <namespaceName>
    

    El usuario que implementa el clúster de macrodatos debe iniciar sesión en la consola de OpenShift:

    oc login -u <deployingUser> -p <password>
    

Implementación de un clúster de macrodatos

  1. Instalación de la versión más reciente de azdata.

  2. Clone uno de los archivos de configuración integrados para OpenShift, en función del entorno de destino (OpenShift local o ARO) y del escenario de implementación. Vea más abajo la sección Configuración específica de OpenShift en los archivos de configuración de implementación para observar la configuración específica de OpenShift en los archivos de configuración integrados. Para obtener más detalles sobre los archivos de configuración disponibles, vea guía de implementación.

    Enumere todos los archivos de configuración integrados disponibles.

    azdata bdc config list
    

    Para clonar uno de los archivos de configuración integrados, ejecute el siguiente comando (opcionalmente, puede reemplazar el perfil según su plataforma o escenario de destino):

    azdata bdc config init --source openshift-dev-test --target custom-openshift
    

    En el caso de una implementación de ARO, comience con uno de los perfiles aro-, que incluye los valores predeterminados para serviceType y storageClass adecuados para este entorno. Por ejemplo:

    azdata bdc config init --source aro-dev-test --target custom-openshift
    
  3. Personalice los archivos de configuración control.json y bdc.json. Estos son algunos recursos adicionales que le guiarán por las personalizaciones para varios casos de uso:

    Nota:

    No se admite la integración con Microsoft Entra ID (anteriormente llamado Azure Active Directory) para los BDC; por lo tanto, no puedes usar este método de autenticación cuando se implementa en ARO.

  4. Establezca variables de entorno.

  5. Implemente un clúster de macrodatos.

    azdata bdc create --config custom-openshift --accept-eula yes
    
  6. Una vez realizada la implementación correctamente, puede iniciar sesión y enumerar los puntos de conexión del clúster externo:

       azdata login -n mssql-cluster
       azdata bdc endpoint list
    

Configuración específica de OpenShift en los archivos de configuración de implementación

SQL Server 2019 CU5 presenta dos modificadores de características para controlar la recopilación de métricas de pods y nodos. Estos parámetros se establecen en false de manera predeterminada en los perfiles integrados para OpenShift, ya que los contenedores de supervisión requieren contexto de seguridad con privilegios, lo que relajará algunas de las restricciones de seguridad para el espacio de nombres en el que se implementa el BDC.

    "security": {
      "allowNodeMetricsCollection": false,
      "allowPodMetricsCollection": false
}

El nombre de la clase de almacenamiento predeterminada en ARO es Managed-Premium (en lugar de AKS, donde se llama a la clase de almacenamiento predeterminada se llama predeterminada). Lo encontraría en el elemento control.json correspondiente a aro-dev-test y aro-dev-test-ha:

    },
    "storage": {
      "data": {
        "className": "managed-premium",
        "accessMode": "ReadWriteOnce",
        "size": "15Gi"
      },
      "logs": {
        "className": "managed-premium",
        "accessMode": "ReadWriteOnce",
        "size": "10Gi"
      }

Archivo bdc-scc.yaml

El archivo de la SCC para esta implementación es:

allowHostDirVolumePlugin: false
allowHostIPC: false
allowHostNetwork: false
allowHostPID: false
allowHostPorts: false
allowPrivilegeEscalation: true
allowPrivilegedContainer: false
allowedCapabilities:
  - SETUID
  - SETGID
  - CHOWN
  - SYS_PTRACE
apiVersion: security.openshift.io/v1
defaultAddCapabilities: null
fsGroup:
  type: RunAsAny
kind: SecurityContextConstraints
metadata:
  annotations:
    kubernetes.io/description: SQL Server BDC custom scc is based on 'nonroot' scc plus additional capabilities required by BDC.
  generation: 2
  name: bdc-scc
readOnlyRootFilesystem: false
requiredDropCapabilities:
  - KILL
  - MKNOD
runAsUser:
  type: MustRunAsNonRoot
seLinuxContext:
  type: MustRunAs
supplementalGroups:
  type: RunAsAny
volumes:
  - configMap
  - downwardAPI
  - emptyDir
  - persistentVolumeClaim
  - projected
  - secret

Pasos siguientes

Tutorial: Carga de datos de ejemplo en un clúster de macrodatos de SQL Server.