Share via

Implantar grupos de disponibilidade com o DH2i DxEnterprise no Kubernetes

  • Artigo

Aplica-se a:SQL Server – Linux

Este tutorial explica como configurar os grupos de disponibilidade (AGs) Always On do SQL Server para contêineres baseados no SQL Server Linux implantados em um cluster do Kubernetes do AKS (Serviço de Kubernetes do Azure), usando DH2i DxEnterprise. Você pode escolher entre uma 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, AGs e componentes do SQL Server. O DH2i é responsável pelo suporte do produto DxEnterprise, que inclui o gerenciamento de cluster e quorum.

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

  • Criar uma configuração de serviço sem periféricos
  • Criar uma configuração StatefulSet com SQL Server e DxEnterprise no mesmo pod como um contêiner sidecar
  • Criar e configurar um AG do SQL Server, 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. Você precisa de:

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

Criar o serviço sem periféricos

  1. Em um cluster do Kubernetes, os serviços sem periféricos permitem que os pods se conectem entre si usando nomes de host.

    Para criar o serviço sem periféricos, crie um arquivo YAML chamado headless_services.yaml, com o conteúdo de exemplo a seguir.

    #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 comando a seguir 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 como dxemssql.yaml.

    Essa configuração StatefulSet cria três réplicas DxEMSSQL que usam declarações de volume persistentes para armazenar dados. Cada pod nesse StatefulSet é composto por dois contêineres: um contêiner do SQL Server e um contêiner do DxEnterprise. Esses contêineres são iniciados separadamente em uma configuração de "sidecar", mas o DxEnterprise gerencia a réplica de 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: 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>"

  3. Aplique a configuração StatefulSet.

    kubectl apply -f dxemssql.yaml

  4. Verifique o status dos pods e prossiga para a próxima etapa quando o status do pod se tornar running.

    kubectl get pods
kubectl describe pods

Criar grupo de disponibilidade e failover de teste

Para obter detalhes sobre como criar e configurar o AG, adicionar réplicas e testar o failover, confira 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 de AG por meio das etapas a seguir.

  1. Verifique se você criou o ouvinte do AG com DxEnterprise, conforme descrito na etapa opcional próxima ao final da documentação do DH2i.

  2. No Kubernetes, você tem a opção de criar endereços IP estáticos. Ao criar um endereço IP estático, você garante que, se o serviço de ouvinte for excluído e recriado, o endereço IP externo atribuído a esse serviço permaneça inalterado. Siga as etapas para criar um endereço IP estático no Serviço de Kubernetes do Azure (AKS).

  3. Depois de criar um endereço IP, é preciso atribuí-lo e criar 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, você poderá habilitar o redirecionamento de conexão de leitura/gravação do secundário para o primário ao seguir estas etapas. Confira mais informações em Redirecionamento de conexão 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