Freigeben über

Bereitstellen von Verfügbarkeitsgruppen mit DH2i DxEnterprise in Kubernetes

  • Artikel

Gilt für: SQL Server – Linux

In diesem Tutorial wird erläutert, wie Sie mit DH2i DxEnterprise SQL Server-Always On-Verfügbarkeitsgruppen (AGs) für SQL Server-Linux-basierte Container konfigurieren, die in einem Azure Kubernetes Service-Kubernetes-Cluster (AKS) bereitgestellt werden. Sie können eine Sidecar-Konfiguration wählen (bevorzugt), oder Ihr eigenes benutzerdefiniertes Containerimage erstellen.

Hinweis

Microsoft unterstützt Datenverschiebung, AG und SQL Server-Komponenten. DH2i ist für die Unterstützung des DxEnterprise-Produkts verantwortlich, was die Cluster- und Quorumverwaltung umfasst.

Erfahren Sie anhand der in diesem Artikel beschriebenen Schritte, wie Sie ein StatefulSet bereitstellen und mithilfe der DH2i DxEnterprise-Lösung eine AG erstellen und konfigurieren. Dieses Tutorial besteht aus den folgenden Schritten.

  • Erstellen einer monitorlosen Dienstkonfiguration
  • Erstellen einer StatefulSet-Konfiguration mit SQL Server und DxEnterprise im selben Pod, in dem sich auch ein Sidecar-Container befindet
  • Erstellen und Konfigurieren einer SQL Server-Verfügbarkeitsgruppe, Hinzufügen der sekundären Replikate
  • Erstellen einer Datenbank in der Verfügbarkeitsgruppe und Testen eines Failovers

Voraussetzungen

Dieses Tutorial zeigt ein Beispiel für eine Verfügbarkeitsgruppe mit drei Replikaten. Erforderlich:

  • Einen AKS- (Azure Kubernetes Service) oder Kubernetes-Cluster.
  • Eine gültige DxEnterprise-Lizenz mit aktivierten Verfügbarkeitsgruppenfeatures und Tunneln. Weitere Informationen finden Sie in der Entwickleredition für die Nutzung außerhalb der Produktion oder unter DxEnterprise-Software für Produktionsworkloads.

Erstellen des monitorlosen Diensts

  1. In einem Kubernetes-Cluster ermöglichen monitorlose Dienste Ihren Pods das Herstellen gegenseitiger Verbindungen anhand von Hostnamen.

    Erstellen Sie zum Erstellen des monitorlosen Diensts eine YAML-Datei namens headless_services.yaml mit dem folgenden Beispielinhalt.

    #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. Führen Sie den folgenden Befehl aus, um die Konfiguration anzuwenden.

    kubectl apply -f headless_services.yaml

Erstellen des StatefulSet

  1. Erstellen Sie eine StatefulSet-YAML-Datei mit dem folgenden Beispielinhalt, und nennen Sie sie dxemssql.yaml.

    Diese StatefulSet-Konfiguration erstellt drei DxEMSSQL-Replikate, die persistente Volumeansprüche zum Speichern ihrer Daten verwenden. Jeder Pod in diesem StatefulSet besteht aus zwei Containern: einem SQL Server-Container und einem DxEnterprise-Container. Diese Container werden getrennt voneinander in einer Sidecar-Konfiguration gestartet, aber DxEnterprise verwaltet das Verfügbarkeitsgruppenreplikat im SQL Server-Container.

    #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. Erstellen Sie eine Anmeldeinformation für die SQL Server-Instanz.

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

  3. Wenden Sie die StatefulSet-Konfiguration an.

    kubectl apply -f dxemssql.yaml

  4. Überprüfen Sie den Status der Pods, und fahren Sie mit dem nächsten Schritt fort, wenn der Status des Pods in running gewechselt ist.

    kubectl get pods
kubectl describe pods

Erstellen einer Verfügbarkeitsgruppe und Testen eines Failovers

Ausführliche Informationen zum Erstellen und Konfigurieren einer Verfügbarkeitsgruppe, Hinzufügen von Replikaten und Testen des Failovers finden Sie unter SQL Server-Verfügbarkeitsgruppen in Kubernetes.

Schritte zum Konfigurieren von Verfügbarkeitsgruppenlistenern: (optional)

Sie können auch mit den folgenden Schritten einen AG-Listener konfigurieren.

  1. Vergewissern Sie sich, dass Sie den Verfügbarkeitsgruppenlistener, wie im optionalen Schritt am Ende der DH2i-Dokumentation beschrieben, mit DxEnterprise erstellt haben.

  2. In Kubernetes können Sie optional statische IP-Adressen erstellen. Wenn Sie eine statische IP-Adresse erstellen, stellen Sie sicher, dass sich die externe IP-Adresse, die Ihrem Listenerdienst zugewiesen ist, nicht ändert, wenn der Listenerdienst gelöscht und neu erstellt wird. Befolgen Sie die Schritte zum Erstellen einer statischen IP-Adresse in Azure Kubernetes Service (AKS).

  3. Nachdem Sie eine IP-Adresse erstellt haben, weisen Sie diese IP-Adresse zu und erstellen den Lastenausgleichsdienst, wie im folgenden YAML-Beispiel gezeigt.

    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

Schritte zum Konfigurieren der Umleitung der Lese-/Schreibverbindung (optional)

Nachdem Sie die AG erstellt haben, können Sie die Umleitung der Lese-/Schreibverbindung vom sekundären zum primären Replikat aktivieren, indem Sie diese Schritte ausführen. Weitere Informationen finden Sie unter Umleitung von Lese-/Schreibverbindungen vom sekundären zum primären Replikat (Always On-Verfügbarkeitsgruppen).

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

Zugehöriger Inhalt