Implementare gruppi di disponibilità con DH2i DxEnterprise in Kubernetes

Si applica a:SQL Server su Linux

Questo tutorial spiega come configurare i gruppi di disponibilità SQL Server Always On (AG) con container basati su DH2i DxEnterprise per SQL Server Linux distribuiti su un cluster Kubernetes Servizio Azure Kubernetes (AKS). È possibile scegliere tra una configurazione sidecar (preferita) o creare un'immagine del contenitore personalizzata.

Note

Microsoft supporta lo spostamento dei dati, il gruppo di disponibilità e i componenti di SQL Server. DH2i supporta il prodotto DxEnterprise, che include la gestione del cluster e del quorum.

Impara a distribuire un StatefulSet e usa DH2i DxEnterprise per creare e configurare un AG. Questo tutorial si compone dei seguenti passaggi.

  • Crea una configurazione del servizio headless
  • Creare una configurazione statefulSet con SQL Server e DxEnterprise nello stesso pod di un contenitore sidecar
  • Creare e configurare un gruppo di disponibilità di SQL Server, con l'aggiunta delle repliche secondarie
  • Creare un database nel gruppo di disponibilità e testare il failover

Prerequisiti

In questa esercitazione viene illustrato un esempio di gruppo di disponibilità con tre repliche. È necessario:

  • Un cluster di Servizio Azure Kubernetes (AKS) o un cluster Kubernetes.
  • Una licenza DxEnterprise valida con funzionalità di gruppi di disponibilità e tunnel abilitati. Per altre informazioni, vedere l'edizione per sviluppatori per l'utilizzo non di produzione o il software DxEnterprise per i carichi di lavoro di produzione.

Creare il servizio headless

  1. In un cluster Kubernetes, i servizi headless consentono ai pod di connettersi tra loro usando nomi host.

    Per creare il servizio headless, si crea un file YAML chiamato headless_services.yaml con il seguente contenuto di esempio.

    #Headless services for local connections/resolution
    apiVersion: v1
    kind: Service
    metadata:
      name: dxemssql-0
    spec:
      clusterIP: None
      selector:
        statefulset.kubernetes.io/pod-name: dxemssql-0
      ports:
        - name: dxl
          protocol: TCP
          port: 7979
        - name: dxc-tcp
          protocol: TCP
          port: 7980
        - name: dxc-udp
          protocol: UDP
          port: 7981
        - name: sql
          protocol: TCP
          port: 1433
        - name: listener
          protocol: TCP
          port: 14033
    ---
    apiVersion: v1
    kind: Service
    metadata:
      name: dxemssql-1
    spec:
      clusterIP: None
      selector:
        statefulset.kubernetes.io/pod-name: dxemssql-1
      ports:
        - name: dxl
          protocol: TCP
          port: 7979
        - name: dxc-tcp
          protocol: TCP
          port: 7980
        - name: dxc-udp
          protocol: UDP
          port: 7981
        - name: sql
          protocol: TCP
          port: 1433
        - name: listener
          protocol: TCP
          port: 14033
    ---
    apiVersion: v1
    kind: Service
    metadata:
      name: dxemssql-2
    spec:
      clusterIP: None
      selector:
        statefulset.kubernetes.io/pod-name: dxemssql-2
      ports:
        - name: dxl
          protocol: TCP
          port: 7979
        - name: dxc-tcp
          protocol: TCP
          port: 7980
        - name: dxc-udp
          protocol: UDP
          port: 7981
        - name: sql
          protocol: TCP
          port: 1433
        - name: listener
          protocol: TCP
          port: 14033
    
  2. Per applicare la configurazione, eseguire il seguente comando.

    kubectl apply -f headless_services.yaml
    

Creare l'oggetto StatefulSet

  1. Creare un file YAML StatefulSet con il contenuto di esempio seguente e denominarlo dxemssql.yaml.

    Questa configurazione StatefulSet crea tre repliche DxEMSSQL che utilizzano reclamazioni di volume persistenti per memorizzare i propri dati. Ogni pod in questo StatefulSet comprende due contenitori: un contenitore di SQL Server e un contenitore DxEnterprise. Questi container partono separatamente in configurazione sidecar, ma DxEnterprise gestisce la replica AG nel container SQL Server.

    #DxEnterprise + MSSQL StatefulSet
    apiVersion: apps/v1
    kind: StatefulSet
    metadata:
      name: dxemssql
    spec:
      serviceName: "dxemssql"
      replicas: 3
      selector:
        matchLabels:
          app: dxemssql
      template:
        metadata:
          labels:
            app: dxemssql
        spec:
          securityContext:
            fsGroup: 10001
          containers:
            - name: sql
              image: mcr.microsoft.com/mssql/server:2022-latest
              env:
                - name: ACCEPT_EULA
                  value: "Y"
                - name: MSSQL_ENABLE_HADR
                  value: "1"
                - name: MSSQL_SA_PASSWORD
                  valueFrom:
                    secretKeyRef:
                      name: mssql
                      key: MSSQL_SA_PASSWORD
              volumeMounts:
                - name: mssql
                  mountPath: "/var/opt/mssql"
            - name: dxe
              image: docker.io/dh2i/dxe
              env:
                - name: MSSQL_SA_PASSWORD
                  valueFrom:
                    secretKeyRef:
                      name: mssql
                      key: MSSQL_SA_PASSWORD
              volumeMounts:
                - name: dxe
                  mountPath: "/etc/dh2i"
      volumeClaimTemplates:
        - metadata:
            name: dxe
          spec:
            accessModes:
              - ReadWriteOnce
            resources:
              requests:
                storage: 1Gi
        - metadata:
            name: mssql
          spec:
            accessModes:
              - ReadWriteOnce
            resources:
              requests:
                storage: 1Gi
    
  2. Creare la credenziale per l’istanza di SQL Server.

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

    La password deve seguire la politica predefinita di SQL Server password. 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.

  3. Applicare la configurazione di StatefulSet.

    kubectl apply -f dxemssql.yaml
    
  4. Verificare lo stato dei pod e procedere al passaggio successivo quando lo stato del pod diventa running.

    kubectl get pods
    kubectl describe pods
    

Creare un gruppo di disponibilità e testare il failover

Per dettagli su come creare e configurare AG, aggiungere repliche e testare il failover, consulta SQL Server Availability Groups in Kubernetes.

Passaggi per configurare un listener del gruppo di disponibilità (facoltativo)

È anche possibile configurare un listener del gruppo di disponibilità attenendosi alla procedura seguente.

  1. Assicurati di aver creato l'ascoltatore AG con DxEnterprise seguendo il passaggio opzionale verso la fine della documentazione DH2i.

  2. In Kubernetes è possibile creare facoltativamente indirizzi IP statici. Un indirizzo IP statico garantisce che, se elimini e ricrei il servizio ascoltatore, l'indirizzo IP esterno assegnato al tuo servizio non cambi. Seguire i passaggi per creare un indirizzo IP statico nel servizio Azure Kubernetes (AKS).

  3. Dopo aver creato un indirizzo IP, assegnalo e crea il servizio di bilanciamento del carico con il seguente esempio YAML.

    apiVersion: v1
    kind: Service
    metadata:
      name: agslistener
    spec:
      type: LoadBalancer
      loadBalancerIP: <static-IP-address>
      selector:
        app: mssql
      ports:
      - protocol: TCP
        port: 44444
        targetPort: 44444
    

Passaggi per configurare il reindirizzamento delle connessioni in lettura/scrittura (facoltativo)

Dopo aver creato l'AG, abilita la reindirizzazione della connessione di lettura/scrittura dal secondario al primario. Per ulteriori informazioni, vedere Reindirizzamento della connessione di lettura/scrittura dalla replica secondaria a quella primaria (Gruppi di disponibilità Always On).

USE master;
GO

ALTER AVAILABILITY GROUP [AGS1]
MODIFY REPLICA ON N'<name of the primary replica>'
WITH (SECONDARY_ROLE(ALLOW_CONNECTIONS = ALL));
GO

ALTER AVAILABILITY GROUP [AGS1]
MODIFY REPLICA ON N'<name of the secondary-0 replica>'
WITH (SECONDARY_ROLE(ALLOW_CONNECTIONS = ALL));
GO

ALTER AVAILABILITY GROUP [AGS1]
MODIFY REPLICA ON N'<name of the secondary-1 replica>'
WITH (SECONDARY_ROLE(ALLOW_CONNECTIONS = ALL));
GO

ALTER AVAILABILITY GROUP [AGS1]
MODIFY REPLICA ON N'<name of the primary replica>'
WITH (PRIMARY_ROLE(
    READ_WRITE_ROUTING_URL = 'TCP://<External IP address of primary -0>:1433'
));
GO

ALTER AVAILABILITY GROUP [AGS1]
MODIFY REPLICA ON N'<name of the secondary-0 replica>'
WITH (PRIMARY_ROLE(
    READ_WRITE_ROUTING_URL = 'TCP://<External IP address of secondary -0>:1433'
));
GO

ALTER AVAILABILITY GROUP [AGS1]
MODIFY REPLICA ON N'<name of the secondary-1 replica>'
WITH (PRIMARY_ROLE(
    READ_WRITE_ROUTING_URL = 'TCP://<External IP address of secondary -1>:1433'
));
GO