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

Se aplica a:SQL Server en Linux

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

Note

Microsoft admite el movimiento de datos, el Grupo de Disponibilidad (AG) y los componentes de SQL Server. DH2i es compatible con el producto DxEnterprise, que incluye gestión de clústeres y quórum.

Aprende a desplegar un StatefulSet y usa DH2i DxEnterprise para crear y configurar un AG. Este tutorial se compone de los siguientes pasos.

  • Cree una configuración de un 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

Prerequisites

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

  • Un Azure Kubernetes Service (AKS) o clúster de Kubernetes.
  • Una licencia de DxEnterprise válida que incluya características de AG y túneles habilitados. Para obtener más información, consulte la edición de desarrollador para uso no productivo o el software DxEnterprise para cargas de trabajo de producción.

Crear el servicio sin periféricos

  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 interfaz de usuario, crea un archivo YAML llamado headless_services.yaml con el siguiente contenido de ejemplo.

    #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 DxEMSSQL que utilizan reclamaciones 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 comienzan por separado en una configuración sidecar, pero DxEnterprise gestiona la réplica AG 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: 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. Cree una credencial para la instancia de SQL Server.

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

    La contraseña debe seguir la directiva de contraseña predeterminada de SQL Server. De forma predeterminada, la contraseña debe tener al menos ocho caracteres y contener caracteres de tres de los siguientes cuatro conjuntos: mayúsculas, minúsculas, dígitos en base 10 y símbolos. Las contraseñas pueden tener hasta 128 caracteres. Use contraseñas lo más largas y complejas posible.

  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

Crear un grupo de disponibilidad y probar la conmutación por error

Para detalles sobre la creación y configuración de AG, añadir réplicas y probar el failover, véase SQL Server Availability Groups 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úrate de haber creado el oyente AG con DxEnterprise siguiendo el paso opcional cerca del final de la documentación de DH2i.

  2. En Kubernetes, si quiere, puede crear direcciones IP estáticas. Una dirección IP estática garantiza que si eliminas y recreas el servicio de escucha, la dirección IP externa asignada a tu servicio de escucha no cambie. Siga los pasos para crear una dirección IP estática en Azure Kubernetes Service (AKS).

  3. Después de crear una dirección IP, asignala y crea el servicio de balanceador de carga con la siguiente muestra YAML.

    apiVersion: v1
kind: Service
metadata:
  name: agslistener
spec:
  type: LoadBalancer
  loadBalancerIP: <static-IP-address>
  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, activa la redirección de la conexión de lectura/escritura del secundario al principal. 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 [AGS1]
MODIFY REPLICA ON N'<name of the primary replica>'
WITH (SECONDARY_ROLE(ALLOW_CONNECTIONS = ALL));
GO

ALTER AVAILABILITY GROUP [AGS1]
MODIFY REPLICA ON N'<name of the secondary-0 replica>'
WITH (SECONDARY_ROLE(ALLOW_CONNECTIONS = ALL));
GO

ALTER AVAILABILITY GROUP [AGS1]
MODIFY REPLICA ON N'<name of the secondary-1 replica>'
WITH (SECONDARY_ROLE(ALLOW_CONNECTIONS = ALL));
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

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

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

Contenido relacionado

  • Last updated on