Partager via

Déployer des groupes de disponibilité avec DH2i DxEnterprise sur Kubernetes

  • Article

S’applique à : SQL Server - Linux

Ce tutoriel explique comment configurer des groupes de disponibilité Always On SQL Server pour des conteneurs basés sur Linux déployés sur un cluster Kubernetes AKS (Azure Kubernetes Service) à l’aide de DH2i DxEnterprise. Vous pouvez opter pour une configuration side-car (par défaut) ou créer votre propre image conteneur personnalisée.

Remarque

Microsoft prend en charge le déplacement des données, le groupe de disponibilité et les composants SQL Server. DH2i est responsable de la prise en charge du produit DxEnterprise, qui comprend la gestion des clusters et du quorum.

Cet article présente les étapes à suivre pour déployer un StatefulSet et utiliser la solution DH2i DxEnterprise afin de créer et de configurer un groupe de disponibilité. Ce tutoriel comprend les étapes suivantes.

  • Créer une configuration de service sans périphérique de contrôle
  • Créer une configuration StatefulSet avec SQL Server et DxEnterprise dans le même pod qu’un conteneur side-car
  • Créer et configurer un groupe de disponibilité SQL Server en ajoutant les réplicas secondaires
  • Créer une base de données dans le groupe de disponibilité et tester le basculement

Prérequis

Ce tutoriel montre l’exemple d’un groupe de disponibilité avec trois réplicas. Ce dont vous avez besoin :

  • Cluster Azure Kubernetes Service (AKS) ou Kubernetes.
  • Licence DxEnterprise valide avec les fonctionnalités de groupe de disponibilité et les tunnels activés. Pour plus d’informations, consultez l’édition développeur en cas d’utilisation hors production ou le logiciel DxEnterprise pour les charges de travail de production.

Créer le service sans périphérique de contrôle

  1. Dans un cluster Kubernetes, les services sans périphérique de contrôle permettent à vos pods de se connecter les uns aux autres à l’aide de noms d’hôte.

    Pour créer le service sans périphérique de contrôle, créez un fichier YAML appelé headless_services.yaml, avec l’exemple de contenu suivant.

    #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. Exécutez la commande suivante pour appliquer la configuration.

    kubectl apply -f headless_services.yaml

Créer le StatefulSet

  1. Créez un fichier YAML StatefulSet avec l’exemple de contenu suivant et nommez-le dxemssql.yaml.

    Cette configuration StatefulSet crée trois réplicas DxEMSSQL qui utilisent des revendications de volume persistantes pour stocker leurs données. Chaque pod de ce StatefulSet comprend deux conteneurs : un conteneur SQL Server et un conteneur DxEnterprise. Ces conteneurs sont démarrés séparément les uns des autres dans une configuration « side-car ». Toutefois, DxEnterprise gère les réplicas de groupe de disponibilité dans le conteneur 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. Créez un identifiant pour l’instance SQL Server.

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

  3. Appliquez la configuration StatefulSet.

    kubectl apply -f dxemssql.yaml

  4. Vérifiez l’état des pods et passez à l’étape suivante quand l’état du pod passe à running.

    kubectl get pods
kubectl describe pods

Créer un groupe de disponibilité et tester le basculement

Pour plus d’informations sur la création et la configuration du groupe de disponibilité, l’ajout de réplicas et le test de basculement, reportez-vous à Groupes de disponibilité SQL Server dans Kubernetes.

Étapes pour configurer un écouteur de groupe de disponibilité (facultatif)

Vous pouvez également configurer un écouteur AG en suivant les étapes suivantes.

  1. Vérifiez que vous avez créé l’écouteur de groupe de disponibilité en utilisant DxEnterprise, comme indiqué dans l’étape facultative à la fin de la documentation de DH2i.

  2. Dans Kubernetes, si vous le souhaitez, vous pouvez créer des adresses IP statiques. La création d’une adresse IP statique garantit que si le service de l’écouteur est supprimé et recréé, l’adresse IP externe affectée à votre service d’écouteur ne change pas. Suivez les étapes détaillées pour créer une adresse IP statique dans Azure Kubernetes Service (AKS).

  3. Une fois que vous avez créé une adresse IP, vous l’affectez et vous créez le service d’équilibreur de charge, comme illustré dans l’exemple YAML suivant.

    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

Étapes de configuration de la redirection de connexion en lecture/écriture (facultatif)

Une fois que vous avez créé le groupe de disponibilité, vous pouvez activer la redirection de connexion en lecture et en écriture de la base de données secondaire vers la base de données primaire en suivant les étapes ci-dessous. Pour plus d’informations, consultez Redirection de connexion en lecture/écriture depuis un réplica secondaire vers le réplica principal (groupes de 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

Contenu connexe