Bereitstellen von Verfügbarkeitsgruppen mit DH2i DxEnterprise in Kubernetes

Gilt für:SQL Server unter 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.

Note

Microsoft unterstützt Datenbewegungen, AG- und SQL Server-Komponenten. DH2i ist verantwortlich für die Unterstützung des DxEnterprise-Produkts, das Cluster- und Quorum-Management 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.

  • Headless-Dienstkonfiguration erstellen
  • Erstellen einer StatefulSet-Konfiguration mit SQL Server und DxEnterprise im selben Pod, in dem sich auch ein Sidecar-Container befindet
  • Erstellen und konfigurieren Sie eine SQL Server AG, und fügen Sie die sekundären Replikate hinzu
  • Erstellen einer Datenbank in der Verfügbarkeitsgruppe und Testen eines Failovers

Voraussetzungen

Dieses Tutorial zeigt ein Beispiel für eine AG (Verfügbarkeitsgruppe) mit drei Replikaten. Sie benötigen:

  • Einen AKS- (Azure Kubernetes Service) oder Kubernetes-Cluster.
  • Eine gültige Lizenz für DxEnterprise mit aktivierten AG-Features und Tunneln. Weitere Informationen finden Sie in der Entwickleredition für die Nichtproduktionsverwendung oder dxEnterprise-Software für Produktionsworkloads.

Headless-Service erstellen

  1. In einem Kubernetes-Cluster ermöglichen Headless Services Ihren Pods, sich über Hostnamen miteinander zu verbinden.

    Um den Headless-Service zu erstellen, erstellen Sie eine YAML-Datei namens headless_services.yaml mit folgendem 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 Sie das 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>"

    Ihr Kennwort sollte der standardmäßigen Kennwortrichtlinie von SQL Server folgen. Standardmäßig muss das Kennwort mindestens acht Zeichen lang sein und Zeichen aus drei der folgenden vier Sätze enthalten: Großbuchstaben, Kleinbuchstaben, Basis-10 Ziffern und Symbole. Kennwörter können bis zu 128 Zeichen lang sein. Verwenden Sie möglichst lange und komplexe Kennwörter.

  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 von Lese-/Schreibverbindungen vom sekundären zum primären Knoten aktivieren, indem Sie die folgenden 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

Verwandte Inhalte

  • Last updated on