Condividi tramite

Avvio rapido: distribuire un cluster di contenitori SQL Server in Azure

  • Articolo

Si applica a: SQL Server - Linux

Questo avvio rapido illustra come configurare un'istanza di SQL Server a disponibilità elevata in un contenitore con archiviazione permanente nel servizio Azure Kubernetes (AKS) o Red Hat OpenShift. Se l'istanza di SQL Server ha esito negativo, l’agente di orchestrazione la ricrea automaticamente in un nuovo pod. Il servizio cluster offre anche resilienza in caso di errore del nodo.

Questo avvio rapido usa le utilità da riga di comando seguenti per gestire il cluster.

Servizio cluster Strumento da riga di comando
Servizio Azure Kubernetes (AKS) kubectl (interfaccia della riga di comando di Kubernetes)
Azure Red Hat OpenShift oc (interfaccia della riga di comando di OpenShift)

Prerequisiti

Creare una password dell'amministratore di sistema

L'account amministratore di sistema (sa) deve essere protetto con una password complessa. La password deve seguire i criteri password predefiniti di SQL Server. Per impostazione predefinita, la password deve essere composta da almeno otto caratteri e contenere caratteri di tre delle quattro categorie seguenti: lettere maiuscole, lettere minuscole, cifre in base 10 e simboli. Le password possono contenere fino a 128 caratteri. Usare password il più possibile lunghe e complesse.

  1. Creare una sa password nel cluster Kubernetes. Kubernetes può gestire informazioni di configurazione riservate, ad esempio le password come segreti.

  2. Per creare in Kubernetes un segreto denominato mssql che contenga il valore <password> per MSSQL_SA_PASSWORD, eseguire il comando seguente. Sostituire <password> con la password complessa.

    Importante

    La variabile di ambiente SA_PASSWORD è deprecata. Utilizzare invece MSSQL_SA_PASSWORD.

    kubectl create secret generic mssql --from-literal=MSSQL_SA_PASSWORD="<password>"

Creare una risorsa di archiviazione

Per un database in un cluster Kubernetes, è necessario usare l'archiviazione persistente. È possibile configurare un volume persistente e una richiesta di volume persistente nel cluster Kubernetes seguendo questi passaggi:

  1. Creare un manifesto per definire la classe di archiviazione e la richiesta di volume persistente. Il manifesto specifica lo strumento di provisioning di archiviazione, i parametri e i criteri di recupero. Il cluster Kubernetes usa questo manifesto per creare l'archivio permanente.

  2. L'esempio YAML seguente definisce una classe di archiviazione e una richiesta di volume persistente. Lo strumento di provisioning della classe di archiviazione è azure-disk, perché questo cluster Kubernetes è in Azure. Il tipo di account di archiviazione è Standard_LRS. La richiesta di volume persistente è denominata mssql-data. I metadati della richiesta di volume persistente includono un'annotazione che la riconnette alla classe di archiviazione.

    kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
     name: azure-disk
provisioner: kubernetes.io/azure-disk
parameters:
  storageaccounttype: Standard_LRS
  kind: Managed
---
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: mssql-data
  annotations:
    volume.beta.kubernetes.io/storage-class: azure-disk
spec:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 8Gi

    Salva il file (ad esempio, pvc.yaml).

  3. Creare l'attestazione del volume persistente in Kubernetes, dove <path to pvc.yaml file> è il percorso in cui è stato salvato il file:

    kubectl apply -f <path to pvc.yaml file>

    Il volume persistente viene creato automaticamente come account di archiviazione di Azure e associato alla richiesta di volume persistente.

    storageclass "azure-disk" created
persistentvolumeclaim "mssql-data" created

  4. Verificare l'attestazione del volume persistente, dove <persistentVolumeClaim> è il nome dell'attestazione del volume persistente:

    kubectl describe pvc <persistentVolumeClaim>

    Nel passaggio precedente la richiesta di volume persistente è denominata mssql-data. Per visualizzare i metadati relativi alla richiesta di volume persistente, eseguire il comando seguente:

    kubectl describe pvc mssql-data

    I metadati restituiti includono un valore denominato Volume. Questo valore esegue il mapping al nome del BLOB.

    Name:          mssql-data
Namespace:     default
StorageClass:  azure-disk
Status:        Bound
Volume:        pvc-d169b88e-f26d-11e7-bc3e-0a58ac1f09a4
Labels:        ‹none>
Annotations:   kubectl.kubernetes.io/last-applied-configuration-{"apiVersion":"v1","kind":"PersistentVolumeClaim","metadata":{"annotations":{"volume.beta.   kubernetes.io/storage-class":"azure-disk"},"name":"mssq1-data...
               pv.kubernetes.io/bind-completed-yes
               pv.kubernetes.io/bound-by-controller=yes
               volume.beta.kubernetes.io/storage-class=azure-disk
               volume.beta.kubernetes.io/storage-provisioner=kubernetes.io/azure-disk
Capacity:      8Gi
Access Modes:  RWO
Events:        <none>

    Il valore per volume corrisponde a parte del nome del BLOB nel portale di Azure.

  5. Verificare il volume persistente.

    kubectl describe pv

    kubectl restituisce i metadati relativi al volume persistente creato automaticamente e associato alla richiesta di volume persistente.

Creare la distribuzione

Il contenitore che ospita l'istanza di SQL Server viene descritto come oggetto di distribuzione Kubernetes. La distribuzione crea un set di repliche. Il set di repliche crea il pod.

Si creerà un manifesto per descrivere il contenitore in base all'immagine Docker mssql-server-linux per SQL Server.

  • Il manifesto fa riferimento alla richiesta di volume persistente mssql-server e al segreto mssql già applicato al cluster Kubernetes.
  • Il manifesto descrive anche un servizio. Si tratta di un servizio di bilanciamento del carico. Il servizio di bilanciamento del carico garantisce che l'indirizzo IP venga mantenuto anche dopo il ripristino dell'istanza di SQL Server.
  • Il manifesto descrive le richieste e i limiti per le risorse, in base ai requisiti di sistema minimi.

  1. Creare un manifesto (un file YAML) per descrivere la distribuzione. L'esempio seguente descrive una distribuzione, incluso un contenitore basato sull'immagine del contenitore per SQL Server.

    apiVersion: apps/v1
kind: Deployment
metadata:
  name: mssql-deployment
spec:
  replicas: 1
  selector:
     matchLabels:
       app: mssql
  template:
    metadata:
      labels:
        app: mssql
    spec:
      terminationGracePeriodSeconds: 30
      hostname: mssqlinst
      securityContext:
        fsGroup: 10001
      containers:
      - name: mssql
        image: mcr.microsoft.com/mssql/server:2022-latest
        resources:
          requests:
            memory: "2G"
            cpu: "2000m"
          limits:
            memory: "2G"
            cpu: "2000m"
        ports:
        - containerPort: 1433
        env:
        - name: MSSQL_PID
          value: "Developer"
        - name: ACCEPT_EULA
          value: "Y"
        - name: MSSQL_SA_PASSWORD
          valueFrom:
            secretKeyRef:
              name: mssql
              key: MSSQL_SA_PASSWORD
        volumeMounts:
        - name: mssqldb
          mountPath: /var/opt/mssql
      volumes:
      - name: mssqldb
        persistentVolumeClaim:
          claimName: mssql-data
---
apiVersion: v1
kind: Service
metadata:
  name: mssql-deployment
spec:
  selector:
    app: mssql
  ports:
    - protocol: TCP
      port: 1433
      targetPort: 1433
  type: LoadBalancer

    Copiare il codice precedente in un nuovo file, denominato sqldeployment.yaml. Aggiornare i valori seguenti:

    • MSSQL_PID value: "Developer": imposta il contenitore per l'esecuzione dell'edizione SQL Server Developer. L'edizione Developer non è concessa in licenza per i dati di produzione. Se la distribuzione è destinata all'uso in produzione, impostare l'edizione appropriata (Enterprise, Standard o Express). Per altre informazioni, vedere Come ottenere una licenza per SQL Server.

    • persistentVolumeClaim: questo valore richiede una voce per claimName: che esegue il mapping al nome usato per la richiesta di volume persistente. In questa esercitazione viene usato mssql-data.

    • name: MSSQL_SA_PASSWORD: configura l'immagine del contenitore per impostare la sa password, come definito in questa sezione.

      valueFrom:
  secretKeyRef:
    name: mssql
    key: MSSQL_SA_PASSWORD

      Quando Kubernetes distribuisce il contenitore, fa riferimento al segreto denominato mssql per ottenere il valore per la password.

    • securityContext: definisce le impostazioni di privilegio e controllo di accesso per un pod o un contenitore. In questo caso viene specificato a livello di pod, quindi tutti i contenitori rispettano tale contesto di sicurezza. Nel contesto di sicurezza viene definito con il valore fsGroup, ovvero l'ID di gruppo (GID) 10001 per il gruppo mssql. Questo valore significa che tutti i processi del contenitore fanno parte anche dell'ID di gruppo 10001 supplementare (mssql). Il proprietario per il volume /var/opt/mssql e tutti i file creati in tale volume avranno l'ID di gruppo 10001 (il gruppo mssql).

    Avviso

    Usando il tipo di servizio LoadBalancer, l'istanza di SQL Server è accessibile in modalità remota (tramite Internet) sulla porta 1433.

    Salvare il file. Ad esempio: sqldeployment.yaml.

  2. Creare la distribuzione, dove <path to sqldeployment.yaml file> è il percorso in cui è stato salvato il file:

    kubectl apply -f <path to sqldeployment.yaml file>

    Vengono creati la distribuzione e il servizio. L'istanza di SQL Server si trova in un contenitore, connesso a una risorsa di archiviazione permanente.

    deployment "mssql-deployment" created
service "mssql-deployment" created

    Vengono creati la distribuzione e il servizio. L'istanza di SQL Server si trova in un contenitore, connesso a una risorsa di archiviazione permanente.

    Per visualizzare lo stato del pod, digitare kubectl get pod.

    NAME                                READY    STATUS    RESTARTS   AGE
mssql-deployment-3813464711-h312s   1/1      Running   0          17m

    Il pod ha uno stato Running. Questo stato indica che il contenitore è pronto. Dopo aver creato la distribuzione, la visualizzazione del pod potrebbe richiedere alcuni minuti. Il ritardo si verifica perché il cluster esegue il pull dell'immagine mssql-server-linux dal registro artefatti Microsoft. Dopo il primo pull dell'immagine, le distribuzioni successive potrebbero essere più veloci se la distribuzione viene eseguita in un nodo in cui l'immagine è già memorizzata.

  3. Verificare che i servizi siano in esecuzione. Esegui questo comando:

    kubectl get services

    Questo comando restituisce i servizi in esecuzione, nonché gli indirizzi IP interni ed esterni per i servizi. Prendere nota dell'indirizzo IP esterno per il servizio mssql-deployment. Usare questo indirizzo IP per connettersi a SQL Server.

    NAME               TYPE           CLUSTER-IP    EXTERNAL-IP     PORT(S)          AGE
kubernetes         ClusterIP      10.0.0.1      <none>          443/TCP          52m
mssql-deployment   LoadBalancer   10.0.113.96   52.168.26.254   1433:30619/TCP   2m

    Per altre informazioni sullo stato degli oggetti nel cluster Kubernetes, eseguire il comando seguente. Ricordarsi di sostituire <MyResourceGroup> e <MyKubernetesClustername> con il nome del cluster Kubernetes e del gruppo di risorse:

    az aks browse --resource-group <MyResourceGroup> --name <MyKubernetesClustername>

  4. È anche possibile verificare che il contenitore sia in esecuzione non come radice eseguendo il comando seguente, dove <nameOfSqlPod> è il nome del pod SQL Server:

    kubectl.exe exec <nameOfSqlPod> -it -- /bin/bash

    È possibile visualizzare il nome utente come mssql se si esegue whoami. mssql non è un utente radice.

    whoami

Connettersi all'istanza di SQL Server

È possibile connettersi con un'applicazione dall'esterno della rete virtuale di Azure usando l'account sa e l'indirizzo IP esterno per il servizio. Usa la password configurata come segreto di OpenShift.

È possibile usare le applicazioni seguenti per connettersi all'istanza di SQL Server.

Connettersi con sqlcmd

Per connettersi con sqlcmd, eseguire il comando seguente.

sqlcmd -S <External IP address> -U sa -P "<password>"

Sostituire <External IP address> con l'indirizzo IP per il mssql-deployment servizio e <password> con la password complessa.

Attenzione

La password deve seguire i criteri password predefiniti di SQL Server. Per impostazione predefinita, la password deve essere composta da almeno otto caratteri e contenere caratteri di tre delle quattro categorie seguenti: lettere maiuscole, lettere minuscole, cifre in base 10 e simboli. Le password possono contenere fino a 128 caratteri. Usare password il più possibile lunghe e complesse.

Verificare l'errore e il ripristino

Per verificare l'errore e il ripristino, è possibile eliminare il pod con i passaggi seguenti:

  1. Elencare il pod che esegue SQL Server.

    kubectl get pods

    Prendere nota del nome del pod che esegue SQL Server.

  2. Eliminare il pod.

    kubectl delete pod mssql-deployment-0

    mssql-deployment-0 è il valore del nome del pod restituito nel passaggio precedente.

Kubernetes ricrea automaticamente il pod per ripristinare un'istanza di SQL Server e connettersi alla risorsa di archiviazione permanente. Usare kubectl get pods per verificare che venga distribuito un nuovo pod. Usare kubectl get services per verificare che l'indirizzo IP del nuovo contenitore sia lo stesso.

Pulire le risorse

Se non si prevede di eseguire le esercitazioni seguenti, pulire le risorse non necessarie. Usa il comando az group delete per rimuovere il gruppo di risorse, il servizio contenitore e tutte le risorse correlate. Sostituisci <MyResourceGroup> con il nome del gruppo di risorse contenente il cluster.

az group delete --name <MyResourceGroup> --yes --no-wait

Contenuto correlato