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.
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 menos4096
, aunque el valor óptimo depende del parámetromax 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 la4.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.
- A fin de averiguar cómo actualizar
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
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 SCCnonroot
, descargue las notas del producto aquí.Creación de un espacio de nombres o proyecto:
oc new-project <namespaceName>
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>
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
Instalación de la versión más reciente de azdata.
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 paraserviceType
ystorageClass
adecuados para este entorno. Por ejemplo:azdata bdc config init --source aro-dev-test --target custom-openshift
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.
Establezca variables de entorno.
Implemente un clúster de macrodatos.
azdata bdc create --config custom-openshift --accept-eula yes
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.