Déploiement de Clusters Big Data SQL Server sur OpenShift en local et sur Azure Red Hat OpenShift

S’applique à : SQL Server 2019 (15.x)

Cet article explique comment déployer un cluster Big Data SQL Server sur des environnements OpenShift en local et sur Azure Red Hat OpenShift (ARO).

Vous pouvez déployer des clusters Big Data sur OpenShift en local ou sur Azure Red Hat OpenShift (ARO). Validez la version OpenShifts CRI-O par rapport aux configurations testées indiquées dans les Notes de publication sur Clusters Big Data SQL Server. Même si le flux de travail de déploiement est similaire à celui d’autres plateformes basées sur Kubernetes (kubeadm et AKS), il existe quelques différences. Les principales concernent l’exécution d’applications en tant qu’utilisateur non racine et le contexte de sécurité utilisé pour l’espace de noms dans lequel le cluster Big Data est déployé.

Pour déployer le cluster OpenShift en local, consultez la documentation Red Hat OpenShift. Pour les déploiements ARO, consultez Azure Red Hat OpenShift.

Cet article décrit la procédure de déploiement propre à la plateforme OpenShift et détaille les options disponibles pour accéder à l’environnement cible et à l’espace de noms servant à déployer le cluster Big Data.

Conditions préalables

1. Veillez à ce que le paramètre pidsLimit sur OpenShift soit mis à jour pour prendre en charge les charges de travail SQL Server. La valeur par défaut dans OpenShift est trop faible pour les charges de travail de type production. Démarrez avec au moins 4096, mais la valeur optimale dépend du paramètre max worker threads dans SQL Server et du nombre de processeurs UC présents sur le nœud hôte OpenShift.

   • Pour savoir comment mettre à jour pidsLimit sur votre cluster OpenShift, suivez ces instructions. Notez que les versions de OpenShift antérieures à 4.3.5 comportaient un défaut à cause duquel la valeur mise à jour n’était pas prise en compte. Veillez à mettre à niveau OpenShift pour passer à la dernière version.
   • Pour calculer la valeur optimale en fonction de votre environnement et de vos charges de travail SQL Server prévues, vous pouvez utiliser l’estimation et les exemples suivants :

   Nombre de processeurs	Nombre maximal de threads de travail	Nombre de Workers par processeur par défaut	Valeur pidsLimit minimale
   64	512	16	512 + (64 × 16) = 1 536
   128	512	32	512 + (128 × 32) = 4 608

   Notes

   D’autres processus (par exemple, les sauvegardes, CLR, Fulltext et SQLAgent) introduisent également une certaine surcharge. Par conséquent, ajoutez une marge à la valeur estimée.

2. Téléchargez la contrainte de contexte de sécurité (SCC) personnalisée 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. Appliquez la SCC au cluster.

   oc apply -f bdc-scc.yaml
   

   Notes

   La contrainte de contexte de sécurité personnalisée de Clusters Big Data s’appuie sur la contrainte nonroot intégrée dans OpenShift, à laquelle s’ajoutent des autorisations supplémentaires. Pour plus d’informations sur les contraintes de contexte de sécurité dans OpenShift, consultez Gestion des contraintes de contexte de sécurité. Pour des informations détaillées sur les autorisations nécessaires aux clusters Big Data en plus de la contrainte de contexte de sécurité nonroot, téléchargez le livre blanc ici.

4. Créez un espace de noms/projet :

   oc new-project <namespaceName>
   

5. Liez la contrainte de contexte de sécurité personnalisée aux comptes de service dans l’espace de noms où le cluster Big Data est déployé :

   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. Attribuez l’autorisation appropriée à l’utilisateur qui déploie le cluster Big Data. Procédez de l'une des manières suivantes :

   • Si l’utilisateur qui déploie le cluster Big Data possède un rôle d’administrateur de cluster, passez à Déploiement du cluster Big Data.

   • Si l’utilisateur qui déploie le cluster Big Data est administrateur d’espace de noms, attribuez-lui le rôle local d’administrateur de cluster pour l’espace de noms créé. Il s’agit de l’option recommandée pour que l’utilisateur qui déploie et gère le cluster Big Data dispose des autorisations d’administrateur au niveau de l’espace de noms.

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

   L’utilisateur qui déploie le cluster Big Data doit ensuite se connecter à la console OpenShift :

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

Déploiement d’un cluster Big Data

1. Installez la dernière version de azdata.

2. Clonez l’un des fichiers de configuration intégrés pour OpenShift, en fonction de votre environnement cible (OpenShift local ou ARO) et du scénario de déploiement. Pour connaître les paramètres propres à OpenShift dans les fichiers de configuration intégrés, consultez la section Paramètres propres à OpenShift dans les fichiers de configuration de déploiement ci-dessous. Pour plus d’informations sur les fichiers de configuration disponibles, consultez Aide au déploiement.

   Listez tous les fichiers de configuration intégrés disponibles.

   azdata bdc config list
   

   Pour cloner l’un des fichiers de configuration intégrés, exécutez la commande suivante (si vous le souhaitez, vous pouvez remplacer le profil en fonction de votre plateforme/scénario ciblé) :

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

   Pour un déploiement sur ARO, démarrez avec l’un des profils aro-, qui comprend les valeurs par défaut pour serviceType et storageClass adaptées à cet environnement. Par exemple :

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

3. Personnalisez les fichiers de configuration control.json et bdc.json. Voici quelques ressources supplémentaires qui vous guideront à travers les personnalisations pour différents cas d’usage :

   • Stockage
   • Paramètres liés à AD
   • Autres personnalisations

   Remarque

   L’intégration avec Microsoft Entra ID (anciennement Azure Active Directory) pour BDC n’est pas prise en charge. Il n’est donc pas possible d’utiliser cette méthode d’authentification lors du déploiement sur ARO.

4. Définissez des variables d’environnement.

5. Déploiement d’un cluster Big Data

   azdata bdc create --config custom-openshift --accept-eula yes
   

6. Une fois le déploiement réussi, vous pouvez vous connecter et lister les points de terminaison du cluster externe :

      azdata login -n mssql-cluster
      azdata bdc endpoint list
   

Paramètres propres à OpenShift dans les fichiers de configuration de déploiement

SQL Server 2019 CU5 introduit deux commutateurs de fonctionnalités pour contrôler la collecte de métriques sur les pods et les nœuds. Ces paramètres ont la valeur false par défaut dans les profils intégrés pour OpenShift, car la supervision des conteneurs exige un contexte de sécurité privilégié, ce qui assouplit certaines contraintes de sécurité de l’espace de noms sur lequel le BDC de l’espace de noms est déployé.

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

Le nom de la classe de stockage par défaut dans ARO est managed-premium (par opposition à AKS, où elle s’appelle default). Vous la trouverez dans le fichier control.json correspondant à aro-dev-test et à aro-dev-test-ha :

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

Fichier bdc-scc.yaml

Le fichier SCC pour ce déploiement est le suivant :

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

Étapes suivantes

Tutoriel : Chargement d’un exemple de données dans un cluster Big Data SQL Server