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