Поделиться через


Развертывание групп доступности с помощью DH2i DxEnterprise в Kubernetes

Область применения: SQL Server — Linux

В этом руководстве объясняется, как настроить группы доступности Sql Server AlwaysOn для контейнеров на основе SQL Server Linux, развернутых в кластере Kubernetes Служба Azure Kubernetes (AKS), с помощью DH2i DxEnterprise. Можно выбрать конфигурацию бокового автомобиля (предпочтительную) или создать собственный пользовательский образ контейнера.

Примечание.

Корпорация Майкрософт поддерживает компоненты перемещения данных, группы доступности и SQL Server. DH2i отвечает за поддержку продукта DxEnterprise, который включает в себя управление кластером и кворумом.

Выполнив действия, описанные в этой статье, узнайте, как развернуть StatefulSet и использовать решение DH2i DxEnterprise для создания и настройки группы доступности. Это руководство состоит из следующих шагов.

  • Создание конфигурации службы без головы
  • Создание конфигурации StatefulSet с помощью SQL Server и DxEnterprise в том же модуле pod, что и контейнер бокового контейнера
  • Создание и настройка группы доступности SQL Server, добавление вторичных реплик
  • Создание базы данных в группе доступности и тестовая отработка отказа

Необходимые компоненты

В этом руководстве показан пример группы доступности с тремя репликами. Необходимые компоненты:

  • Кластер Служба Azure Kubernetes (AKS) или Kubernetes.
  • Допустимая лицензия DxEnterprise с включенными функциями и туннелями группы доступности. Дополнительные сведения см. в выпуске разработчика для непроизводственных рабочих нагрузок или программного обеспечения DxEnterprise для рабочих нагрузок.

Создание службы без головы

  1. В кластере Kubernetes службы без головы позволяют модулям pod подключаться друг к другу с помощью имен узлов.

    Чтобы создать службу без головы, создайте вызываемую headless_services.yamlyamL-файл со следующим примером содержимого.

    #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. Выполните следующую команду, чтобы применить конфигурацию.

    kubectl apply -f headless_services.yaml
    

Создание StatefulSet

  1. Создайте YAML-файл StatefulSet со следующим примером содержимого и присвойте ему dxemssql.yamlимя.

    Эта конфигурация StatefulSet создает три реплики DxEMSSQL, которые используют утверждения постоянного тома для хранения данных. Каждый модуль pod в этом StatefulSet состоит из двух контейнеров: контейнера SQL Server и контейнера DxEnterprise. Эти контейнеры запускаются отдельно друг от друга в конфигурации "боковика", но DxEnterprise управляет репликой группы доступности в контейнере 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. Создайте учетные данные для экземпляра SQL Server.

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

    Пароль должен соответствовать политике паролей по умолчанию SQL Server. По умолчанию пароль должен быть не короче восьми символов и содержать три вида символов из следующих: прописные буквы, строчные буквы, десятичные цифры, специальные символы. Пароли могут иметь длину до 128 символов. Рекомендуется использовать максимально длинные и сложные пароли.

  3. Примените конфигурацию StatefulSet.

    kubectl apply -f dxemssql.yaml
    
  4. Проверьте состояние модулей pod и перейдите к следующему шагу, когда состояние pod становится running.

    kubectl get pods
    kubectl describe pods
    

Создание группы доступности и тестовая отработка отказа

Дополнительные сведения о создании и настройке группы доступности, добавлении реплик и тестировании отработки отказа см . в группах доступности SQL Server в Kubernetes.

Действия по настройке прослушивателя группы доступности (необязательно)

Вы также можете настроить прослушиватель группы доступности, выполнив следующие действия.

  1. Убедитесь, что вы создали прослушиватель группы доступности с помощью DxEnterprise, как описано в необязательном шаге в конце документации по DH2i.

  2. В Kubernetes можно при необходимости создавать статические IP-адреса. При создании статического IP-адреса убедитесь, что при удалении и повторном создании службы прослушивателя внешний IP-адрес, назначенный службе прослушивателя, не изменяется. Выполните действия, чтобы создать статический IP-адрес в Служба Azure Kubernetes (AKS).

  3. После создания IP-адреса назначьте этот IP-адрес и создадите службу подсистемы балансировки нагрузки, как показано в следующем примере YAML.

    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
    

Действия по настройке перенаправления подключений для чтения и записи (необязательно)

После создания группы доступности можно включить перенаправление подключения чтения и записи из вторичного в основной, выполнив следующие действия. Дополнительные сведения см. в статье Перенаправление подключения с правами на чтение и запись с вторичной на первичную реплику (группы доступности AlwaysOn).

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