Distribuire cluster Big Data SQL Server in OpenShift in locale e in Azure Red Hat OpenShift
Si applica a
: SQL Server 2019 (15.x)
Importante
Il componente aggiuntivo per i cluster Big Data di Microsoft SQL Server 2019 verrà ritirato. Il supporto per i cluster Big Data di SQL Server 2019 terminerà il 28 febbraio 2025. Tutti gli utenti esistenti di SQL Server 2019 con Software Assurance saranno completamente supportati nella piattaforma e fino a quel momento il software continuerà a ricevere aggiornamenti cumulativi di SQL Server. Per altre informazioni, vedere il post di blog relativo all'annuncio e Opzioni per i Big Data nella piattaforma Microsoft SQL Server.
Questo articolo illustra come distribuire un cluster Big Data di SQL Server in ambienti OpenShift, in locale o in Azure Red Hat OpenShift (ARO).
Suggerimento
Per un bootstrap rapido di un ambiente di esempio usando ARO e quindi il cluster Big Data distribuito in questa piattaforma, è possibile usare lo script Python disponibile qui.
È possibile distribuire cluster Big Data in OpenShift in locale o in Azure Red Hat OpenShift (ARO). Convalidare la versione CRI-O di OpenShifts rispetto alle configurazioni testate nelle note sulla versione dei cluster Big Data di SQL Server. Anche se il flusso di lavoro di distribuzione è simile alla distribuzione in altre piattaforme basate su Kubernetes (kubeadm e AKS), esistono alcune differenze. La differenza riguarda principalmente l'esecuzione delle applicazioni come utente non ROOT e il contesto di protezione usato per lo spazio dei nomi in cui viene distribuito il cluster Big Data.
Per la distribuzione del cluster OpenShift in locale, vedere la documentazione di Red Hat OpenShift. Per le distribuzioni di ARO, vedere Azure Red Hat OpenShift.
Questo articolo illustra i passaggi di distribuzione specifici della piattaforma OpenShift, indica le opzioni disponibili per accedere all'ambiente di destinazione e lo spazio dei nomi usato per distribuire il cluster Big Data.
Prerequisiti
Importante
Le operazioni seguenti devono essere eseguite da un amministratore del cluster OpenShift (ruolo di amministratore del cluster) con autorizzazioni sufficienti per creare questi oggetti a livello di cluster. Per altre informazioni sui ruoli del cluster in OpenShift, vedere Uso del controllo degli accessi in base al ruolo per definire e applicare le autorizzazioni.
Assicurarsi che l'impostazione
pidsLimitin OpenShift sia aggiornata per gestire i carichi di lavoro di SQL Server. Il valore predefinito in OpenShift è troppo basso per i carichi di lavoro di produzione. Iniziare con almeno4096, ma il valore ottimale dipende dall'impostazionemax worker threadsin SQL Server e dal numero di processori CPU nel nodo host OpenShift.- Per informazioni su come aggiornare
pidsLimitper il cluster OpenShift usare queste istruzioni. Si noti che le versioni di OpenShift precedenti alla4.3.5presentano un problema che fa sì che il valore aggiornato non abbia effetto. Assicurarsi di aggiornare OpenShift alla versione più recente. - Per semplificare il calcolo del valore ottimale a seconda dell'ambiente e dei carichi di lavoro di SQL Server pianificati, è possibile usare la stima e gli esempi seguenti:
Numero di processori Valore predefinito max worker threads Ruoli di lavoro predefiniti per processore Valore minimo pidsLimit 64 512 16 512 + (64 *16) = 1536 128 512 32 512 + (128*32) = 4608 Nota
Anche altri processi, come backup, CLR, Fulltext, SQLAgent, comportano un overhead, quindi aggiungono un buffer al valore stimato.
- Per informazioni su come aggiornare
Scaricare il vincolo del contesto di protezione personalizzato
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.yamlApplicare il vincolo del contesto di protezione al cluster.
oc apply -f bdc-scc.yamlNota
L’SCC personalizzato per il cluster Big Data è basato sull’SCC
nonrootincorporato di OpenShift con autorizzazioni aggiuntive. Per altre informazioni sui vincoli del contesto di protezione in OpenShift, vedere Gestione dei vincoli del contesto di protezione. Per informazioni dettagliate sulle autorizzazioni aggiuntive richieste per i cluster Big Data oltre all’SCCnonroot, scaricare il white paper qui.Creare uno spazio dei nomi/progetto:
oc new-project <namespaceName>Associare il vincolo del contesto di protezione personalizzato agli account del servizio nello spazio dei nomi in cui viene distribuito il cluster Big Data:
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>Assegnare le autorizzazioni appropriate all'utente che distribuisce il cluster Big Data. Effettuare una delle seguenti operazioni.
Se l'utente che distribuisce il cluster Big Data ha un ruolo di amministratore del cluster, procedere con la distribuzione del cluster Big Data.
Se l'utente che distribuisce il cluster Big Data è un amministratore dello spazio dei nomi, assegnare all'utente il ruolo locale di amministratore del cluster per lo spazio dei nomi creato. Questa è l'opzione preferita per l'utente che distribuisce e gestisce il cluster Big Data per avere autorizzazioni di amministratore a livello dello spazio dei nomi.
oc create rolebinding bdc-user-rbac --clusterrole=cluster-admin --user=<userName> -n <namespaceName>L'utente che distribuisce il cluster Big Data deve quindi accedere alla console OpenShift:
oc login -u <deployingUser> -p <password>
Distribuire il cluster Big Data
Installare la versione più recente di azdata.
Clonare uno dei file di configurazione predefiniti per OpenShift, a seconda dell'ambiente di destinazione (OpenShift in locale o ARO) e dello scenario di distribuzione. Vedere la sezione Impostazioni specifiche di OpenShift nei file di configurazione della distribuzione di seguito per le impostazioni specifiche di OpenShift nei file di configurazione predefiniti. Per altre informazioni sui file di configurazione disponibili, vedere le linee guida per la distribuzione.
Elencare tutti i file di configurazione predefiniti disponibili.
azdata bdc config listPer clonare uno dei file di configurazione predefiniti, eseguire il comando seguente (facoltativamente, è possibile sostituire il profilo in base alla piattaforma/scenario di destinazione):
azdata bdc config init --source openshift-dev-test --target custom-openshiftPer una distribuzione in ARO, iniziare con uno dei profili
aro-che include valori predefiniti perserviceTypeestorageClassappropriati per questo ambiente. Ad esempio:azdata bdc config init --source aro-dev-test --target custom-openshiftPersonalizzare i file di configurazione control.json e bdc.json. Di seguito sono riportate alcune risorse aggiuntive che illustrano le personalizzazioni per diversi casi d'uso:
Nota
L'integrazione con Microsoft Entra ID (precedentemente Azure Active Directory) per il cluster Big Data non è supportata, di conseguenza non è possibile usare questo metodo di autenticazione per la distribuzione in ARO.
Impostare le variabili di ambiente
Distribuire il cluster Big Data
azdata bdc create --config custom-openshift --accept-eula yesAl termine della distribuzione, è possibile accedere ed elencare gli endpoint del cluster esterni:
azdata login -n mssql-cluster azdata bdc endpoint list
Impostazioni specifiche di OpenShift nei file di configurazione della distribuzione
SQL Server 2019 CU5 ha introdotto due opzioni di funzionalità per controllare la raccolta di metriche di pod e nodi. Questi parametri sono impostati su false per impostazione predefinita nei profili predefiniti per OpenShift perché i contenitori di monitoraggio richiedono un contesto di protezione con privilegi, cosa che consentirà di ridurre alcuni dei vincoli di protezione per lo spazio dei nomi in cui viene distribuito il cluster Big Data.
"security": {
"allowNodeMetricsCollection": false,
"allowPodMetricsCollection": false
}
Il nome della classe di archiviazione predefinita in ARO è managed-premium (a differenza del servizio Azure Kubernetes in cui la classe di archiviazione predefinita è denominata default). Si trova nel file control.json corrispondente a aro-dev-test e aro-dev-test-ha:
},
"storage": {
"data": {
"className": "managed-premium",
"accessMode": "ReadWriteOnce",
"size": "15Gi"
},
"logs": {
"className": "managed-premium",
"accessMode": "ReadWriteOnce",
"size": "10Gi"
}
File bdc-scc.yaml
Il file del vincolo del contesto di protezione per la distribuzione è:
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
Passaggi successivi
Tutorial: Caricare dati di esempio in un cluster Big Data di SQL Server
Commenti e suggerimenti
Presto disponibile: Nel corso del 2024 verranno gradualmente disattivati i problemi di GitHub come meccanismo di feedback per il contenuto e ciò verrà sostituito con un nuovo sistema di feedback. Per altre informazioni, vedere https://aka.ms/ContentUserFeedback.
Invia e visualizza il feedback per