Teilen über


Bereitstellen von Verfügbarkeitsgruppen mit DH2i DxEnterprise in Kubernetes

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: 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