Implementare gruppi di disponibilità con DH2i DxEnterprise in Kubernetes
Si applica a: SQL Server - Linux
Questa esercitazione illustra come configurare gruppi di disponibilità Always On (AG) di SQL Server per contenitori di SQL Server basati su Linux distribuiti in un cluster Kubernetes con il servizio Azure Kubernetes usando DH2i DxEnterprise. È possibile scegliere tra una configurazione sidecar (preferita) o creare un'immagine del contenitore personalizzata.
Nota
Microsoft offre supporto per lo spostamento dati, il gruppo di disponibilità e i componenti di SQL Server. DH2i è responsabile del supporto del prodotto DxEnterprise, che include la gestione del cluster e del quorum.
Usando i passaggi descritti in questo articolo, scoprire come implementare un oggetto StatefulSet e usare la soluzione DH2i DxEnterprise per creare e configurare un gruppo di disponibilità (AG). L'esercitazione è costituita dai passaggi seguenti.
- Creare una configurazione del servizio headless
- Creare una configurazione statefulSet con SQL Server e DxEnterprise nello stesso pod di un contenitore sidecar
- Creare e configurare un gruppo di disponibilità di SQL Server, aggiungendo repliche secondarie
- Creare un database nel gruppo di disponibilità e testare il failover
Prerequisiti
Questa esercitazione illustra un esempio di gruppo di disponibilità con tre repliche. È necessario:
- Un cluster del servizio Azure Kubernetes o Kubernetes.
- Una licenza DxEnterprise valida con funzionalità e tunnel del gruppo di disponibilità abilitati. Per altre informazioni, vedere l'edizione per sviluppatori per l'utilizzo non di produzione o il software DxEnterprise per i carichi di lavoro di produzione.
Creare il servizio headless
In un cluster Kubernetes, i servizi headless consentono ai pod di connettersi tra loro usando nomi host.
Per creare il servizio headless, creare un file YAML denominato
headless_services.yaml
, con il contenuto di esempio seguente.#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
Per applicare la configurazione, eseguire il seguente comando.
kubectl apply -f headless_services.yaml
Creare l'oggetto StatefulSet
Creare un file YAML StatefulSet con il contenuto di esempio seguente e denominarlo
dxemssql.yaml
.Questa configurazione di StatefulSet crea tre repliche DxEMSSQL che usano attestazioni di volume con salvataggio permanente per archiviare i dati. Ogni pod in questo StatefulSet comprende due contenitori: un contenitore di SQL Server e un contenitore DxEnterprise. Tali contenitori vengono avviati separatamente l'uno dall'altro in una configurazione "sidecar", ma DxEnterprise gestisce la replica del gruppo di disponibilità nel contenitore di 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
Creare la credenziale per l’istanza di SQL Server.
kubectl create secret generic mssql --from-literal=MSSQL_SA_PASSWORD="<password>"
Applicare la configurazione di StatefulSet.
kubectl apply -f dxemssql.yaml
Verificare lo stato dei pod e procedere al passaggio successivo quando lo stato del pod diventa
running
.kubectl get pods kubectl describe pods
Creare un gruppo di disponibilità e testare il failover
Per informazioni dettagliate sulla creazione e la configurazione del gruppo di disponibilità, l'aggiunta di repliche e il failover di test, vedere Gruppi di disponibilità di SQL Server in Kubernetes.
Passaggi per configurare un listener del gruppo di disponibilità (facoltativo)
È anche possibile configurare un listener del gruppo di disponibilità seguendo queste procedure.
Assicurarsi di aver creato il listener del gruppo di disponibilità usando DxEnterprise come descritto nel passaggio facoltativo riportato verso la fine della documentazione di DH2i.
In Kubernetes è possibile creare facoltativamente indirizzi IP statici. Quando si crea un indirizzo IP statico, garantire che, se il servizio listener viene eliminato e ricreato, l'indirizzo IP esterno assegnato a tale servizio non cambi. Seguire i passaggi per creare un indirizzo IP statico nel servizio Azure Kubernetes (AKS).
Dopo aver creato un indirizzo IP, assegnarlo e creare il servizio di bilanciamento del carico, come illustrato nel codice YAML di esempio seguente.
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
Passaggi per configurare il reindirizzamento delle connessioni in lettura/scrittura (facoltativo)
Dopo aver creato il gruppo di disponibilità, è possibile abilitare il reindirizzamento delle connessioni in lettura/scrittura dalle repliche secondarie alla replica primaria seguendo questa procedura. Per altre informazioni, vedere Reindirizzamento della connessione in lettura/scrittura da replica secondaria a primaria - Gruppi di disponibilità 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
Contenuto correlato
- Distribuire gruppi di disponibilità in Kubernetes con DH2i DxOperator in servizio Azure Kubernetes
- Distribuire contenitori SQL Server nel servizio Azure Kubernetes
- Distribuire contenitori Linux di SQL Server nel servizio Kubernetes con StatefulSets
- Esercitazione: Configurare l'autenticazione di Active Directory tramite i contenitori di SQL Server in Linux