Bereitstellen von Verfügbarkeitsgruppen mit DH2i DxEnterprise in Kubernetes

Gilt für:SQL Server unter Linux

Dieses Tutorial erklärt, wie man SQL Server Always On Verfügbarkeitsgruppen (AGs) mit DH2i DxEnterprise für SQL Server Linux-basierte Container konfiguriert, die auf einem Azure Kubernetes Service (AKS) Kubernetes-Cluster bereitgestellt werden. Sie können eine Sidecar-Konfiguration wählen (bevorzugt), oder Ihr eigenes benutzerdefiniertes Containerimage erstellen.

Note

Microsoft unterstützt Datenverschiebung, AG und SQL Server-Komponenten. DH2i unterstützt das Produkt DxEnterprise, das Cluster- und Quorum-Management umfasst.

Lerne, wie man ein StatefulSet bereitstellt und DH2i DxEnterprise verwendet, um eine AG-Anlage zu erstellen und zu 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 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.

Erstellen des monitorlosen Diensts

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

    Um den headlosen Dienst zu erstellen, erstelle eine YAML-Datei mit headless_services.yaml 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 erzeugt drei DxEMSSQL-Replikate, die persistente Volumenansprüche verwenden, um ihre Daten zu speichern. Jeder Pod in diesem StatefulSet besteht aus zwei Containern: einem SQL Server-Container und einem DxEnterprise-Container. Diese Container starten separat in einer Sidecar-Konfiguration, aber DxEnterprise verwaltet die AG-Replik 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

Details zur Erstellung und Konfiguration von AG, zum Hinzufügen von Repliken und zum Testen von Failover finden Sie unter SQL Server Availability Groups in Kubernetes.

Schritte zum Konfigurieren von Verfügbarkeitsgruppenlistenern: (optional)

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

  1. Stellen Sie sicher, dass Sie den AG-Listener mit DxEnterprise erstellt haben, indem Sie den optionalen Schritt am Ende der DH2i-Dokumentation folgen.

  2. In Kubernetes können Sie optional statische IP-Adressen erstellen. Eine statische IP-Adresse stellt sicher, dass sich beim Löschen und Neuerstellen des Listener-Dienstes die externe IP-Adresse Ihres Listener-Dienstes nicht ändert. 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 zu und erstellen den Load Balancer-Dienst mit folgendem YAML-Beispiel.

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

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

Nachdem du die AG erstellt hast, aktiviere die Lese-/Schreibverbindungsumleitung von der sekundären zur primären. 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 [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

Verwandte Inhalte

  • Last updated on