Partilhar via

Implantar grupos de disponibilidade com DH2i DxEnterprise no Kubernetes

  • Artigo

Aplica-se a:SQL Server - Linux

Este tutorial explica como configurar grupos de disponibilidade Always On (AGs) do SQL Server para contêineres baseados no SQL Server Linux implantados em um cluster Kubernetes do Serviço Kubernetes do Azure (AKS), usando o DH2i DxEnterprise. Você pode escolher entre um de configuração de sidecar (preferencial) ou criar sua própria imagem de contêiner personalizada.

Observação

A Microsoft oferece suporte a movimentação de dados, AG e componentes do SQL Server. A DH2i é responsável pelo suporte ao produto DxEnterprise, que inclui gerenciamento de cluster e quórum.

Usando as etapas mencionadas neste artigo, saiba como implantar um StatefulSet e usar a solução DH2i DxEnterprise para criar e configurar um AG. Este tutorial consiste nas seguintes etapas.

  • Criar uma configuração de serviço sem cabeça
  • Criar uma configuração StatefulSet com SQL Server e DxEnterprise no mesmo pod que um contêiner sidecar
  • Criar e configurar um SQL Server AG, adicionando as réplicas secundárias
  • Criar um banco de dados no AG e testar o failover

Pré-requisitos

Este tutorial mostra um exemplo de um AG com três réplicas. Precisas:

  • Um Serviço Azure Kubernetes (AKS) ou Kubernetes cluster.
  • Uma licença DxEnterprise válida com recursos AG e túneis ativados. Para obter mais informações, consulte a edição para programadores para uso não produtivo ou o software DxEnterprise para cargas de trabalho de produção.

Crie o serviço headless

  1. Em um cluster Kubernetes, os serviços headless permitem que seus pods se conectem uns aos outros usando nomes de host.

    Para criar o headless service, crie um arquivo YAML chamado headless_services.yaml, com o seguinte conteúdo de exemplo.

    #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. Execute o seguinte comando para aplicar a configuração.

    kubectl apply -f headless_services.yaml

Criar o StatefulSet

  1. Crie um arquivo YAML StatefulSet com o seguinte conteúdo de exemplo e nomeie-o dxemssql.yaml.

    Essa configuração StatefulSet cria três réplicas DxEMSSQL que utilizam declarações de volume persistentes para armazenar seus dados. Cada pod neste StatefulSet compreende dois contêineres: um contêiner SQL Server e um contêiner DxEnterprise. Esses contêineres são iniciados separadamente uns dos outros em uma configuração de "sidecar", mas o DxEnterprise gerencia a réplica AG no contêiner do 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. Crie uma credencial para a instância do SQL Server.

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

    Sua senha deve seguir a política de senha de padrão do SQL Server. Por padrão, a senha deve ter pelo menos oito caracteres e conter caracteres de três dos quatro conjuntos a seguir: letras maiúsculas, letras minúsculas, dígitos de base 10 e símbolos. As palavras-passe podem ter até 128 caracteres. Use senhas tão longas e complexas quanto possível.

  3. Aplique a configuração StatefulSet.

    kubectl apply -f dxemssql.yaml

  4. Verifique o estado dos pods e prossiga para a próxima etapa quando o estado de um pod se tornar running.

    kubectl get pods
kubectl describe pods

Criar grupo de disponibilidade e testar failover

Para obter detalhes sobre como criar e configurar o AG, adicionar réplicas e testar o failover, consulte Grupos de Disponibilidade do SQL Server no Kubernetes.

Etapas para configurar o ouvinte do grupo de disponibilidade (opcional)

Você também pode configurar um ouvinte AG, com as etapas a seguir.

  1. Certifique-se de ter criado a escuta AG usando o DxEnterprise, como descrito na etapa opcional próximo do final da documentação do DH2i .

  2. No Kubernetes, você pode, opcionalmente, criar estáticos endereços IP. Ao criar um endereço IP estático, você garante que, se o serviço de escuta for excluído e recriado, o endereço IP externo atribuído ao serviço de ouvinte não será alterado. Siga as etapas para criar um endereço IP estático no Serviço Kubernetes do Azure (AKS).

  3. Depois de criar um endereço IP, atribua esse endereço IP e crie o serviço de balanceador de carga, conforme mostrado no exemplo de YAML a seguir.

    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

Etapas para configurar o redirecionamento de conexão de leitura/gravação (opcional)

Depois de criar o AG, pode habilitar o redirecionamento de conexão de leitura/escrita do secundário para o primário seguindo estas etapas. Para obter mais informações, consulte redirecionamento da conexão de leitura/gravação de réplica secundária para primária (grupos de disponibilidade 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

Conteúdo relacionado