Implementare gruppi di disponibilità con DH2i DxEnterprise in Kubernetes

Si applica a:SQL Server su Linux

Questa esercitazione illustra come configurare gruppi di disponibilità Always On (AG) di SQL Server per contenitori di SQL Server basati su Linux distribuiti in un cluster Kubernetes con il servizio Azure Kubernetes usando DH2i DxEnterprise. È 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 è responsabile del supporto del prodotto DxEnterprise, che include la gestione del cluster e del quorum.

Seguendo i passaggi descritti in questo articolo, scopri come distribuire uno StatefulSet e usare la soluzione DH2i DxEnterprise per creare e configurare un gruppo di disponibilità (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, creare un file YAML denominato headless_services.yaml, con il contenuto di esempio seguente.

    #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 di StatefulSet crea tre repliche DxEMSSQL che usano attestazioni di volume con salvataggio permanente per archiviare i dati. Ogni pod in questo StatefulSet comprende due contenitori: un contenitore di SQL Server e un contenitore DxEnterprise. Tali contenitori vengono avviati separatamente l'uno dall'altro in una configurazione "sidecar", ma DxEnterprise gestisce la replica del gruppo di disponibilità nel contenitore di 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 informazioni dettagliate sulla creazione e la configurazione del gruppo di disponibilità, sull'aggiunta di repliche e sul test del failover, vedere Gruppi di disponibilità di SQL Server 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. Assicurarsi di aver creato il listener AG tramite DxEnterprise, come indicato nel passaggio facoltativo verso la fine della documentazione di DH2i.

  2. In Kubernetes è possibile creare facoltativamente indirizzi IP statici. Quando si crea un indirizzo IP statico, garantire che, se il servizio listener viene eliminato e ricreato, l'indirizzo IP esterno assegnato a tale servizio non cambi. Seguire i passaggi per creare un indirizzo IP statico nel servizio Azure Kubernetes (AKS).

  3. Dopo aver creato un indirizzo IP, assegnarlo e creare il servizio di bilanciamento del carico, come illustrato nel codice YAML di esempio seguente.

    apiVersion: v1
kind: Service
metadata:
  name: agslistener
spec:
  type: LoadBalancer
  loadBalancerIP: 52.140.117.62
  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, è possibile abilitare il reindirizzamento delle connessioni in lettura/scrittura dalla replica secondaria a quella primaria seguendo questi passaggi. 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 [ag_name] MODIFY REPLICA
    ON N'<name of the primary replica>'
WITH (SECONDARY_ROLE(ALLOW_CONNECTIONS = ALL));
GO

USE [master];
GO

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

USE [master];
GO

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

USE [master];
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

USE [master];
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

USE [master];
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

Contenuti correlati

  • Last updated on