Implementación de grupos de disponibilidad con DH2i DxEnterprise en Kubernetes

Se aplica a:SQL Server: Linux

En este tutorial se explica cómo configurar grupos de disponibilidad Always On de SQL Server (AG) para contenedores SQL Server basados en Linux implementados en un clúster de Kubernetes de Azure Kubernetes Service (AKS), mediante DH2i DxEnterprise. Puede elegir entre una configuración de Sidecar (preferida) o crear su propia imagen de contenedor personalizada.

Nota:

Microsoft admite los componentes de movimiento de datos, AG y SQL Server. DH2i es responsable del soporte técnico del producto DxEnterprise, que incluye la administración de clústeres y cuórum.

Con los pasos mencionados en este artículo, aprenderá a implementar un elemento StatefulSet y a usar la solución DH2i DxEnterprise para crear y configurar un AG. Este tutorial se compone de los siguientes pasos.

  • Creación de una configuración de servicio sin encabezado
  • Creación de una configuración StatefulSet con SQL Server y DxEnterprise en el mismo pod que un contenedor sidecar
  • Creación y configuración de un grupo de disponibilidad de SQL Server, agregando las réplicas secundarias
  • Creación de una base de datos en el grupo de disponibilidad y prueba de la conmutación por error

Requisitos previos

En este tutorial, se muestra un ejemplo de un grupo de disponibilidad con tres réplicas. Necesita:

  • Un clúster de Kubernetes o Azure Kubernetes Service (AKS).
  • Una licencia de DxEnterprise válida con las características de grupo de disponibilidad y los túneles habilitados. Para obtener más información, consulte la edición para desarrolladores para el uso en entornos que no son de producción o el software DxEnterprise para cargas de trabajo de producción.

Creación del servicio sin encabezado

  1. En un clúster de Kubernetes, los servicios sin encabezado permiten que los pods se conecten entre sí mediante nombres de host.

    Para crear el servicio sin encabezado, cree un archivo YAML llamado headless_services.yaml con el siguiente contenido de muestra.

    #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. Ejecute el comando siguiente para aplicar la configuración.

    kubectl apply -f headless_services.yaml
    

Creación del elemento StatefulSet

  1. Cree un archivo YAML de StatefulSet con el siguiente contenido de ejemplo y el nombre dxemssql.yaml.

    Esta configuración StatefulSet crea tres réplicas de DxEMSSQL que usan notificaciones de volumen persistentes para almacenar sus datos. Cada pod de este elemento StatefulSet consta de dos contenedores: un contenedor de SQL Server y un contenedor de DxEnterprise. Estos contenedores se inician por separado entre sí en una configuración en "sidecar", pero DxEnterprise administra la réplica del grupo de disponibilidad en el contenedor de 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. Cree una credencial para la instancia de SQL Server.

    kubectl create secret generic mssql --from-literal=MSSQL_SA_PASSWORD="<password>"
    
  3. Aplique la configuración StatefulSet.

    kubectl apply -f dxemssql.yaml
    
  4. Compruebe el estado de los pods y continúe con el paso siguiente cuando el estado del pod cambie a running.

    kubectl get pods
    kubectl describe pods
    

Creación de un grupo de disponibilidad y una prueba de conmutación por error

Para más información sobre cómo crear y configurar el grupo de disponibilidad, agregar réplicas y probar la conmutación por error, consulte Grupo de disponibilidad de SQL Server en Kubernetes.

Pasos para configurar un escucha de grupo de disponibilidad (opcional)

También puede configurar un escucha de AG con los pasos siguientes.

  1. Asegúrese de que ha creado el agente de escucha del grupo de disponibilidad mediante DxEnterprise como se describe en el paso opcional cerca del final de la documentación de DH2i.

  2. En Kubernetes, si quiere, puede crear direcciones IP estáticas. Cuando crea direcciones IP estáticas, garantiza que, si se elimina el servicio de escucha y se vuelve a crear, la dirección IP externa asignada a su servicio de escucha no cambiará. Siga los pasos para crear una dirección IP estática en Azure Kubernetes Service (AKS).

  3. Una vez que haya creado una dirección IP, asignará esa dirección y creará el servicio del equilibrador de carga, como en el YAML de ejemplo.

    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
    

Pasos para configurar el redireccionamiento de conexiones de lectura y escritura (opcional)

Después de crear el AG, puede habilitar el redireccionamiento de conexiones de lectura y escritura de la réplica secundaria a la principal si sigue estos pasos. Para obtener más información, consulte Redireccionamiento de la conexión de lectura/escritura de réplicas de secundaria a principal (grupos de disponibilidad 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