Condividi tramite

Distribuire cluster Big Data SQL Server in OpenShift in locale e in Azure Red Hat OpenShift

  • Articolo

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.

  1. Assicurarsi che l'impostazione pidsLimit in 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 almeno 4096, ma il valore ottimale dipende dall'impostazione max worker threads in SQL Server e dal numero di processori CPU nel nodo host OpenShift.

    • Per informazioni su come aggiornare pidsLimit per il cluster OpenShift usare queste istruzioni. Si noti che le versioni di OpenShift precedenti alla 4.3.5 presentano 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.

  2. 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.yaml

  3. Applicare il vincolo del contesto di protezione al cluster.

    oc apply -f bdc-scc.yaml

    Nota

    L’SCC personalizzato per il cluster Big Data è basato sull’SCC nonroot incorporato 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’SCC nonroot, scaricare il white paper qui.

  4. Creare uno spazio dei nomi/progetto:

    oc new-project <namespaceName>

  5. 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>

  6. Assegnare le autorizzazioni appropriate all'utente che distribuisce il cluster Big Data. Effettuare una delle operazioni seguenti.

    • 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

  1. Installare la versione più recente di azdata.

  2. 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 list

    Per 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-openshift

    Per una distribuzione in ARO, iniziare con uno dei profili aro- che include valori predefiniti per serviceType estorageClass appropriati per questo ambiente. Ad esempio:

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

  3. Personalizzare 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.

  4. Impostare le variabili di ambiente

  5. Distribuire il cluster Big Data

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

  6. Al 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