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)
Important
Le module complémentaire Clusters Big Data Microsoft SQL Server 2019 sera mis hors service. La prise en charge de la plateforme Clusters Big Data Microsoft SQL Server 2019 se terminera le 28 février 2025. Tous les utilisateurs existants de SQL Server 2019 avec Software Assurance seront entièrement pris en charge sur la plateforme, et le logiciel continuera à être maintenu par les mises à jour cumulatives SQL Server jusqu’à ce moment-là. Pour plus d’informations, consultez le billet de blog d’annonce et les Options Big Data sur la plateforme Microsoft SQL Server.
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).
Conseil
Pour amorcer rapidement un exemple d’environnement avec ARO, puis déployer Clusters Big Data sur cette plateforme, vous pouvez utiliser le script Python disponible ici.
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
Important
Les prérequis suivants doivent être suivis par un administrateur de cluster OpenShift (rôle de cluster cluster-admin) disposant d’autorisations suffisantes pour créer ces objets au niveau du cluster. Pour plus d’informations sur les rôles de cluster dans OpenShift, consultez Définition et application d’autorisations à l’aide du contrôle RBAC.
Veillez à ce que le paramètre
pidsLimitsur 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 moins4096, mais la valeur optimale dépend du paramètremax worker threadsdans SQL Server et du nombre de processeurs UC présents sur le nœud hôte OpenShift.- Pour savoir comment mettre à jour
pidsLimitsur votre cluster OpenShift, suivez ces instructions. Notez que les versions de OpenShift antérieures à4.3.5comportaient 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.
- Pour savoir comment mettre à jour
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.yamlAppliquez la SCC au cluster.
oc apply -f bdc-scc.yamlNotes
La contrainte de contexte de sécurité personnalisée de Clusters Big Data s’appuie sur la contrainte
nonrootinté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.Créez un espace de noms/projet :
oc new-project <namespaceName>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>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
Installez la dernière version de azdata.
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 listPour 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-openshiftPour un déploiement sur ARO, démarrez avec l’un des profils
aro-, qui comprend les valeurs par défaut pourserviceTypeetstorageClassadaptées à cet environnement. Par exemple :azdata bdc config init --source aro-dev-test --target custom-openshiftPersonnalisez 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 :
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.
Définissez des variables d’environnement.
Déploiement d’un cluster Big Data
azdata bdc create --config custom-openshift --accept-eula yesUne 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
Commentaires
Bientôt disponible : Tout au long de 2024, nous allons supprimer progressivement GitHub Issues comme mécanisme de commentaires pour le contenu et le remplacer par un nouveau système de commentaires. Pour plus d’informations, consultez https://aka.ms/ContentUserFeedback.
Envoyer et afficher des commentaires pour