Megosztás a következőn keresztül:

Rendelkezésre állási csoportok üzembe helyezése a DH2i DxEnterprise használatával a Kubernetesen

A következőkre vonatkozik:SQL Server Linux rendszeren

Ez az oktatóanyag bemutatja, hogyan konfigurálhatja az SQL Server Always On rendelkezésre állási csoportjait (AG-ket) az Azure Kubernetes Service (AKS) Kubernetes-fürtön üzembe helyezett SQL Server Linux-alapú tárolókhoz a DH2i DxEnterprise használatával. Választhat egy oldalkocsi konfigurációt (előnyben részesített), vagy létrehozhat saját egyéni konténerképet.

Jegyzet

A Microsoft támogatja az adatáthelyezést, az AG-t és az SQL Server-összetevőket. A DH2i felelős a DxEnterprise termék támogatásáért, amely magában foglalja a klaszter- és kvórumkezelést.

A cikkben ismertetett lépések segítségével megtudhatja, hogyan helyezhet üzembe StatefulSetet, és hogyan használhatja a DH2i DxEnterprise megoldást egy AG létrehozásához és konfigurálásához. Ez az oktatóanyag a következő lépésekből áll.

  • Fej nélküli szolgáltatáskonfiguráció létrehozása
  • StatefulSet-konfiguráció létrehozása egy olyan podban, amely SQL Servert és DxEnterprise-t tartalmaz mellékkonténerként.
  • SQL Server AG létrehozása és konfigurálása a másodlagos replikák hozzáadásával
  • Adatbázis létrehozása az AG-ben, és az átállás tesztelése.

Előfeltételek

Ez az oktatóanyag egy három replikával rendelkező AG-példát mutat be. Szükséged van:

  • Azure Kubernetes Service (AKS) vagy Kubernetes-fürt.
  • Érvényes DxEnterprise-licenc, amelyen engedélyezve van az AG-funkciók és az alagutak. További információ: fejlesztői kiadás tesztelési célokra, vagy DxEnterprise szoftver termelési munkaterheléshez.

A fej nélküli szolgáltatás létrehozása

  1. A Kubernetes-fürtökben a fej nélküli szolgáltatások lehetővé teszik, hogy a podok gazdagépnevek használatával csatlakozzanak egymáshoz.

    A fej nélküli szolgáltatás létrehozásához hozzon létre egy headless_services.yamlnevű YAML-fájlt az alábbi mintatartalommal.

    #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. Futtassa a következő parancsot a konfiguráció alkalmazásához.

    kubectl apply -f headless_services.yaml

A StatefulSet létrehozása

  1. Hozzon létre egy StatefulSet YAML-fájlt a következő mintatartalommal, és nevezze el dxemssql.yaml.

    Ez a StatefulSet-konfiguráció három DxEMSSQL-replikát hoz létre, amelyek állandó kötetjogcímeket használnak az adataik tárolásához. A StatefulSet minden podja két tárolóból áll: egy SQL Server-tárolóból és egy DxEnterprise-tárolóból. Ezek a tárolók külön indulnak el egymástól egy "sidecar" konfigurációban, de a DxEnterprise kezeli az AG-replikát az SQL Server-tárolóban.

    #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. Hozzon létre egy hitelesítő adatot az SQL Server-példányhoz.

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

    A jelszónak az SQL Server alapértelmezett jelszóházirendetkell követnie. Alapértelmezés szerint a jelszónak legalább nyolc karakter hosszúnak kell lennie, és a következő négy készletből három karakterből kell állnia: nagybetűk, kisbetűk, 10 számjegyből és szimbólumokból. A jelszavak legfeljebb 128 karakter hosszúak lehetnek. Használjon olyan jelszavakat, amelyek a lehető legkomplexebbek és hosszúak.

  3. Alkalmazza a StatefulSet konfigurációt.

    kubectl apply -f dxemssql.yaml

  4. Ellenőrizze a podok állapotát, és folytassa a következő lépésekkel, amikor a pod állapota runninglesz.

    kubectl get pods
kubectl describe pods

Rendelkezésre állási csoport létrehozása és hibatűrés tesztelése

Az AG létrehozásáról és konfigurálásáról, a replikák hozzáadásáról és a feladatátvétel teszteléséről a KubernetesSQL Server rendelkezésre állási csoportjairól olvashat.

A rendelkezésre állási csoport figyelőjének konfigurálásához szükséges lépések (nem kötelező)

Az AG-figyelőt az alábbi lépésekkel is konfigurálhatja.

  1. Győződjön meg arról, hogy a DxEnterprise használatával hozta létre az AG-figyelőt, az DH2i dokumentációjának végén található opcionális lépés szerint.

  2. A Kubernetesben igény szerint létrehozhat statikus IP-címeket. Statikus IP-cím létrehozásakor győződjön meg arról, hogy a figyelőszolgáltatás törlése és újbóli létrehozása esetén a figyelőszolgáltatáshoz rendelt külső IP-cím nem változik. Kövesse a lépéseket egy statikus IP-cím létrehozásához az Azure Kubernetes Service-ben (AKS).

  3. Az IP-cím létrehozása után hozzárendeli ezt az IP-címet, és létrehozza a terheléselosztó szolgáltatást az alábbi YAML-mintában látható módon.

    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

Az olvasási/írási kapcsolat átirányításának konfigurálásához szükséges lépések (nem kötelező)

Az AG létrehozása után az alábbi lépések végrehajtásával engedélyezheti az olvasási/írási kapcsolatok átirányítását a másodlagosról az elsődlegesre. További információ: Másodlagosról elsődlegesre történő replika olvasási/írási kapcsolat átirányítása (Always On rendelkezésre állási csoportok).

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

Kapcsolódó tartalom

  • Last updated on