Condividi tramite

Implementare cluster Big Data di SQL Server in OpenShift in sede e in Azure Red Hat OpenShift

Si applica a:SQL Server 2019 (15.x)

Important

I cluster Big Data di Microsoft SQL Server 2019 sono stati ritirati. Il supporto per i cluster Big Data di SQL Server 2019 è terminato a partire dal 28 febbraio 2025. Per altre informazioni, vedere il post di blog sull'annuncio e le opzioni per 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).

Tip

Per un modo rapido per eseguire il bootstrap di un ambiente di esempio usando ARO e quindi BDC distribuito in questa piattaforma, è possibile usare lo script Python disponibile qui.

È possibile distribuire cluster Big Data in OpenShift locale o in Azure Red Hat OpenShift (ARO). Verificare la versione OpenShifts CRI-O rispetto alle configurazioni testate con le note di rilascio 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 servizio Azure Kubernetes), esistono alcune differenze. La differenza riguarda principalmente l'esecuzione di applicazioni come utente non radice e il contesto di sicurezza usato per lo spazio dei nomi BDC viene distribuito in.

Per la distribuzione del cluster OpenShift in locale, vedere la documentazione di Red Hat OpenShift. Per le distribuzioni ARO, vedere Azure Red Hat OpenShift.

Questo articolo illustra i passaggi di distribuzione specifici della piattaforma OpenShift, evidenzia le opzioni disponibili per accedere all'ambiente di destinazione e allo spazio dei nomi usato per distribuire il cluster Big Data.

Pre-requisites

Important

I prerequisiti seguenti devono essere eseguiti da un amministratore del cluster OpenShift (ruolo cluster-admin) 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 supportare i carichi di lavoro di SQL Server. Il valore predefinito in OpenShift è troppo basso per la produzione, ad esempio i carichi di lavoro. 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 eseguire l'aggiornamento pidsLimit per il cluster OpenShift, usare queste istruzioni. Si noti che le versioni di OpenShift precedenti 4.3.5 avevano un difetto che impediva al valore aggiornato di avere effetto. Assicurarsi di aggiornare OpenShift alla versione più recente.
    • Per calcolare il valore ottimale a seconda dell'ambiente e dei carichi di lavoro pianificati di SQL Server, è possibile usare la stima e gli esempi seguenti:
    Numero di processori Numero massimo di thread di lavoro predefinito Ruoli di lavoro predefiniti per processore Valore minimo per pidsLimit
    64 512 16 512 + (64 *16) = 1536
    128 512 32 512 + (128*32) = 4608

    Note

    Altri processi(ad esempio backup, CLR, Fulltext, SQLAgent) aggiungono anche un sovraccarico, quindi aggiungere un buffer al valore stimato.

  2. Scaricare il vincolo del contesto di sicurezza personalizzato (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

  3. Applicare il codice SCC al cluster.

    oc apply -f bdc-scc.yaml

    Note

    L'SCC personalizzato per BDC si basa su SCC predefinito in nonroot OpenShift, con autorizzazioni aggiuntive. Per altre informazioni sui vincoli del contesto di sicurezza in OpenShift, vedere Gestione dei vincoli del contesto di sicurezza. Per informazioni dettagliate sulle autorizzazioni aggiuntive necessarie per i cluster Big Data sopra SCC nonroot , scaricare il white paper qui.

  4. Creare uno spazio dei nomi o un progetto:

    oc new-project <namespaceName>

  5. Associare il SCC personalizzato agli account di servizio nel namespace dove è distribuito il 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>

  6. Assegnare l'autorizzazione appropriata all'utente che distribuisce BDC. Effettuare una delle operazioni seguenti.

    • Se l'utente che distribuisce BDC ha il ruolo di amministratore del cluster, procedere con la distribuzione del cluster Big Data.

    • Se l'utente che distribuisce BDC è un amministratore dello spazio dei nomi, assegnare all'utente il ruolo cluster-admin locale per lo spazio dei nomi appena creato. Questa è l'opzione preferita per l'utente che distribuisce e gestisce il cluster Big Data in modo che disponga delle autorizzazioni di amministratore a livello di spazio dei nomi.

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

    L'utente che distribuisce un cluster Big Data deve quindi accedere alla console OpenShift:

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

Implementare un cluster di Big Data

  1. Installare azdata più recente.

  2. Clonare uno dei file di configurazione predefiniti per OpenShift, a seconda dell'ambiente di destinazione (OpenShift locale o ARO) e dello scenario di distribuzione. Per le impostazioni specifiche di OpenShift nei file di configurazione della distribuzione , vedere la sezione seguente per le impostazioni specifiche di OpenShift nei file di configurazione predefiniti. Per altri dettagli sui file di configurazione disponibili, vedere 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 aro- profili, che include i valori predefiniti per serviceType e storageClass appropriati per questo ambiente. For example:

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

  3. Personalizzare i file di configurazione control.json e bdc.json. Ecco alcune risorse aggiuntive che illustrano le personalizzazioni per diversi casi d'uso:

    Note

    L'integrazione con Microsoft Entra ID (in precedenza Azure Active Directory) per BDC non è supportata, pertanto non è possibile usare questo metodo di autenticazione durante la distribuzione in ARO.

  4. Impostare le variabili di ambiente

  5. Implementare un cluster di Big Data

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

  6. Al termine della distribuzione, è possibile accedere ed elencare gli endpoint del cluster esterno:

       azdata login -n mssql-cluster
   azdata bdc endpoint list

Impostazioni specifiche di OpenShift nei file di configurazione della distribuzione

SQL Server 2019 CU5 introduce due opzioni di funzionalità per controllare la raccolta di metriche dei pod e dei nodi. Questi parametri sono impostati su false per impostazione predefinita nei profili integrati per OpenShift, poiché i contenitori di monitoraggio richiedono un contesto di sicurezza con privilegi, il che ridurrà alcuni dei vincoli di sicurezza per lo spazio dei nomi su cui è distribuito il BDC.

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

Il nome della classe di archiviazione predefinita in ARO è managed-premium (a differenza di AKS dove la classe di archiviazione predefinita è chiamata default). Questo valore si trova nell'oggetto 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 SCC per questa 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

Next steps

Esercitazione: Caricare dati di esempio in un cluster Big Data di SQL Server

  • Last updated on