Hochverfügbarkeit mit SQL Managed Instance mit Azure Arc-Unterstützung

SQL Managed Instance mit Azure Arc-Unterstützung wird in Kubernetes als containerisierte Anwendung bereitgestellt. Es verwendet Kubernetes-Konstrukte wie StatefulSets und persistenten Speicher, um integrierte Systemüberwachung, Fehlererkennung und Failovermechanismen zur Aufrechterhaltung der Dienstintegrität bereitzustellen. Zur Verbesserung der Zuverlässigkeit können Sie auch eine SQL Managed Instance mit Azure Arc-Unterstützung für die Bereitstellung mit zusätzlichen Replikaten in einer Hochverfügbarkeitskonfiguration konfigurieren. Überwachung, Fehlererkennung und automatisches Failover werden durch den Datencontroller der Arc-Datendienste verwaltet. Der Datendienst mit Azure Arc-Unterstützung stellt diesen Dienst ohne Eingreifen des Benutzers bereit. Der Dienst legt die Verfügbarkeitsgruppe fest, konfiguriert Endpunkte für die Datenbankspiegelung, fügt Datenbanken zur Verfügbarkeitsgruppe hinzu und koordiniert Failover und Upgrade. In diesem Dokument werden beide Arten von Hochverfügbarkeit betrachtet.

SQL Managed Instance mit Azure Arc-Unterstützung bietet unterschiedliche Hochverfügbarkeitsstufen, je nachdem, ob SQL Managed Instance als Dienstebene vom Typ Universell oder Unternehmenskritisch bereitgestellt wurde.

Hochverfügbarkeit auf der Dienstebene „Universell“

Auf der Ebene „Universell“ ist nur ein Replikat verfügbar, und die Hochverfügbarkeit wird über Kubernetes-Orchestrierung erreicht. Wenn z. B. ein Pod oder Knoten, der das Containerimage einer verwalteten Instanz enthält, abstürzt, versucht Kubernetes, einen anderen Pod oder Knoten einzusetzen und an denselben persistenten Speicher anzufügen. Während dieser Zeit ist SQL Managed Instance für die Anwendungen nicht verfügbar. Die Anwendungen müssen die Verbindung wiederherstellen und die Transaktion erneut versuchen, wenn der neue Pod verfügbar ist. Wenn load balancer als Diensttyp verwendet wird, können sich Anwendungen erneut mit demselben primären Endpunkt verbinden, und Kubernetes leitet die Verbindung an den neuen primären Endpunkt weiter. Wenn nodeport als Diensttyp verwendet wird, müssen sich die Anwendungen erneut mit der neuen IP-Adresse verbinden.

Überprüfen der integrierten Hochverfügbarkeit

Um die von Kubernetes erstellte Hochverfügbarkeit zu überprüfen, können Sie den Pod einer vorhandenen verwalteten Instanz löschen und überprüfen, ob sich Kubernetes von dieser Aktion erholt, indem Sie das Bootstrapping für einen anderen Pod durchführen und den persistenten Speicher anfügen.

Voraussetzungen

  • Kubernetes-Cluster mit freigegebenem Remotespeicher
  • Eine SQL Managed Instance mit Azure Arc-Unterstützung, bereitgestellt mit einem einzelnen Replikat (Standard)
  1. Zeigen Sie die Pods an.

    kubectl get pods -n <namespace of data controller>
    
  2. Löschen Sie den Pod der verwalteten Instanz.

    kubectl delete pod <name of managed instance>-0 -n <namespace of data controller>
    

    Beispiel:

    user@pc:/# kubectl delete pod sql1-0 -n arc
    pod "sql1-0" deleted
    
  3. Zeigen Sie die Pods an, um sich zu vergewissern, dass die verwaltete Instanz wiederhergestellt wird.

    kubectl get pods -n <namespace of data controller>
    

    Beispiel:

    user@pc:/# kubectl get pods -n arc
    NAME                 READY   STATUS    RESTARTS   AGE
    sql1-0               2/3     Running   0          22s
    

Nachdem alle Container im Pod wiederhergestellt wurden, können Sie eine Verbindung mit der verwalteten Instanz herstellen.

Hochverfügbarkeit auf der Dienstebene „Unternehmenskritisch“

Auf der Dienstebene vom Typ „Unternehmenskritisch“, zusätzlich zu dem, was die Kubernetes-Orchestrierung nativ bereitstellt, stellt Azure SQL Managed Instance für Azure Arc eine enthaltene Verfügbarkeitsgruppe bereit. Die enthaltene Verfügbarkeitsgruppe basiert auf SQL Server AlwaysOn-Technologie. Sie bietet eine höheres Verfügbarkeitsniveau. Wenn SQL Managed Instance mit Azure Arc-Unterstützung auf der Dienstebene Unternehmenskritisch bereitgestellt wird, kann es mit zwei oder drei Replikaten bereitgestellt werden. Diese Replikate werden stets miteinander synchronisiert. Bei enthaltenen Verfügbarkeitsgruppen sind alle Pods oder Knotenausfälle für die Anwendung transparent, da es mindestens einen anderen Pod mit der Instanz gibt, der über alle Daten des primären Pods verfügt und bereit ist, Verbindungen zu übernehmen.

Enthaltene Verfügbarkeitsgruppen

Eine Verfügbarkeitsgruppe bindet eine oder mehrere Benutzerdatenbanken in eine logische Gruppe ein, sodass bei einem Failover die gesamte Gruppe von Datenbanken als einzelne Einheit auf das sekundäre Replikat übergeht. Eine Verfügbarkeitsgruppe repliziert nur die Daten in den Benutzerdatenbanken, nicht aber die Daten in den Systemdatenbanken, z. B. Anmeldungen, Berechtigungen oder Agent-Aufträge. Eine enthaltene Verfügbarkeitsgruppe umfasst Metadaten aus Systemdatenbanken wie msdb- und master-Datenbanken. Wenn Anmeldungen im primären Replikat erstellt oder geändert werden, werden sie automatisch auch in den sekundären Replikaten erstellt. Wenn ein Auftrag im primären Replikat erstellt oder geändert wird, erhalten auch die sekundären Replikate diese Änderungen.

SQL Managed Instance mit Azure Arc-Unterstützung übernimmt dieses Konzept der enthaltenen Verfügbarkeitsgruppe und fügt einen Kubernetes-Operator hinzu, sodass diese im großen Stil bereitgestellt und verwaltet werden können.

Enthaltene Verfügbarkeitsgruppen ermöglichen Folgendes:

  • Bei der Bereitstellung mit mehreren Replikaten wird eine einzelne Verfügbarkeitsgruppe erstellt, die denselben Namen trägt wie die SQL Managed Instance mit Azure Arc-Unterstützung. Standardmäßig hat die enthaltene Verfügbarkeitsgruppe drei Replikate, einschließlich des primären Replikats. Alle CRUD-Vorgänge für die Verfügbarkeitsgruppe werden intern verwaltet – auch die Erstellung der Verfügbarkeitsgruppe oder die Verknüpfung von Replikaten mit der erstellten Verfügbarkeitsgruppe. In der SQL Managed Instance mit Azure Arc-Unterstützung können keine zusätzlichen Verfügbarkeitsgruppen erstellt werden.

  • Alle Datenbanken werden automatisch zur Verfügbarkeitsgruppe hinzugefügt, einschließlich aller Benutzer- und Systemdatenbanken wie master und msdb. Diese Funktion bietet eine Einzelsystemansicht zu den Replikaten der Verfügbarkeitsgruppen. Beachten die beiden Datenbanken containedag_master und containedag_msdb, wenn Sie eine direkte Verbindung mit der Instanz herstellen. Die containedag_*-Datenbanken repräsentieren die Elemente master und msdb innerhalb der Verfügbarkeitsgruppe.

  • Ein externer Endpunkt wird automatisch für die Verbindung mit Datenbanken innerhalb der Verfügbarkeitsgruppe bereitgestellt. Der Endpunkt <managed_instance_name>-external-svc übernimmt die Rolle des Listeners der Verfügbarkeitsgruppe.

Bereitstellen von SQL Managed Instance mit Azure Arc-Unterstützung mit mehreren Replikaten über das Azure-Portal

Gehen Sie im Azure-Portal auf der Seite für SQL Managed Instance mit Azure Arc-Unterstützung wie folgt vor:

  1. Wählen Sie Compute- + Speicherressourcen konfigurieren unter „Compute + Speicher“ aus. Im Portal werden erweiterte Einstellungen angezeigt.
  2. Wählen Sie unter der Dienstebene die Option Unternehmenskritisch aus.
  3. Aktivieren Sie das Kontrollkästchen „Nur für die Entwicklung“, wenn Sie es für Entwicklungszwecke verwenden.
  4. Wählen Sie unter der Hochverfügbarkeit entweder 2 Replikate oder 3 Replikate aus.

High availability settings

Bereitstellen von SQL Managed Instance mit Azure Arc-Unterstützung mit mehreren Replikaten mithilfe der Azure CLI

Wenn SQL Managed Instance mit Azure Arc-Unterstützung auf der Dienstebene „Unternehmenskritisch“ bereitgestellt wird, können mehrere Replikate erstellt werden. Die Einrichtung und Konfiguration der enthaltenen Verfügbarkeitsgruppen unter diesen Instanzen erfolgt automatisch während der Bereitstellung.

Der folgende Befehl erstellt z. B. eine verwaltete Instanz mit drei Replikaten.

Indirekter Verbindungsmodus:

az sql mi-arc create -n <instanceName> --k8s-namespace <namespace> --use-k8s --tier <tier> --replicas <number of replicas>

Beispiel:

az sql mi-arc create -n sqldemo --k8s-namespace my-namespace --use-k8s --tier BusinessCritical --replicas 3

Direkter Verbindungsmodus:

az sql mi-arc create --name <name> --resource-group <group>  --location <Azure location> –subscription <subscription>  --custom-location <custom-location> --tier <tier> --replicas <number of replicas>

Beispiel:

az sql mi-arc create --name sqldemo --resource-group rg  --location uswest2 –subscription xxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx  --custom-location private-location --tier BusinessCritical --replcias 3

Standardmäßig werden alle Replikate im synchronen Modus konfiguriert. Das bedeutet, dass alle Updates für die primäre Instanz synchron auf jede der sekundären Instanzen repliziert werden.

Anzeigen und Überwachen des Verfügbarkeitsgruppenstatus

Sobald die Bereitstellung abgeschlossen ist, stellen Sie eine Verbindung mit dem primären Endpunkt von SQL Server Management Studio her.

Überprüfen Sie den Endpunkt des primären Replikats, rufen Sie ihn ab und stellen Sie über SQL Server Management Studio eine Verbindung mit ihm her. Wenn die SQL-Instanz beispielsweise mithilfe von service-type=loadbalancer bereitgestellt wurde, führen Sie den folgenden Befehl aus, um den Endpunkt abzurufen, mit dem eine Verbindung hergestellt werden soll:

az sql mi-arc list --k8s-namespace my-namespace --use-k8s

oder

kubectl get sqlmi -A

Abrufen des primären und sekundären Endpunkts und des Verfügbarkeitsgruppenstatus

Verwenden Sie die Befehle kubectl describe sqlmi oder az sql mi-arc show, um die primären und sekundären Endpunkte sowie den Status der Verfügbarkeitsgruppe anzuzeigen.

Beispiel:

kubectl describe sqlmi sqldemo -n my-namespace

oder

az sql mi-arc show sqldemo --k8s-namespace my-namespace --use-k8s

Beispielausgabe:

 "status": {
    "AGStatus": "Healthy",
    "logSearchDashboard": "https://10.120.230.404:5601/app/kibana#/discover?_a=(query:(language:kuery,query:'custom_resource_name:sqldemo'))",
    "metricsDashboard": "https://10.120.230.46:3000/d/40q72HnGk/sql-managed-instance-metrics?var-hostname=sqlmi1-0",
    "mirroringEndpoint": "10.15.100.150:5022",
    "observedGeneration": 1,
    "primaryEndpoint": "10.15.100.150,1433",
    "readyReplicas": "2/2",
    "runningVersion": "v1.2.0_2021-12-15",
    "secondaryEndpoint": "10.15.100.156,1433",
    "state": "Ready"
  }

Sie können mithilfe von SQL Server Management Studio eine Verbindung mit dem oben genannten primären Endpunkt herstellen und DMVs wie folgt zum Überprüfen verwenden:

SELECT * FROM sys.dm_hadr_availability_replica_states

Availability Group

Und das Dashboard für die enthaltene Verfügbarkeit:

Container Availability Group dashboard

Failoverszenarien

Im Gegensatz zu SQL Server AlwaysOn-Verfügbarkeitsgruppen ist die enthaltene Verfügbarkeitsgruppe eine verwaltete Hochverfügbarkeitslösung. Daher sind die Failovermodi im Vergleich zu den typischen Modi, die mit SQL Server AlwaysOn-Verfügbarkeitsgruppen verfügbar sind, begrenzt.

Stellen Sie Dienstebene „Unternehmenskritisch“ für SQL Managed Instance in einer Konfiguration mit zwei oder drei Replikaten bereit. Die Auswirkungen von Ausfällen und die anschließende Wiederherstellbarkeit sind bei jeder Konfiguration unterschiedlich. Eine Instanz mit drei Replikaten bietet ein wesentlich höheres Maß an Verfügbarkeit und Wiederherstellung als eine Instanz mit zwei Replikaten.

In einer Konfiguration mit zwei Replikaten wird das sekundäre Replikat automatisch zum primären Replikat höher gestuft, wenn beide Knotenzustände SYNCHRONIZED sind und das primäre Replikat nicht mehr verfügbar ist. Wenn das ausgefallene Replikat verfügbar wird, wird es mit allen ausstehenden Änderungen aktualisiert. Wenn es Probleme mit der Konnektivität zwischen den Replikaten gibt, kann es sein, dass das primäre Replikat keine Transaktionen festlegt, da jede Transaktion auf beiden Replikaten festgelegt werden muss, bevor ein Erfolg auf dem primären zurückgegeben wird.

In einer Konfiguration mit drei Replikaten muss eine Transaktion mindestens zwei der drei Replikate committen, bevor eine Erfolgsmeldung an die Anwendung zurückgegeben wird. Im Falle eines Ausfalls wird eines der sekundären Replikate automatisch zum primären Replikat höher gestuft, während Kubernetes versucht, das ausgefallene Replikat wiederherzustellen. Wenn das Replikat verfügbar wird, wird es automatisch wieder mit der enthaltenen Verfügbarkeitsgruppe verbunden und ausstehende Änderungen werden synchronisiert. Wenn es Verbindungsprobleme zwischen den Replikaten gibt und mehr als zwei Replikate nicht synchronisiert sind, wird das primäre Replikat keine Transaktionen committen.

Hinweis

Es wird empfohlen, eine SQL Managed Instance mit der Dienstebene „Unternehmenskritisch“ in einer Konfiguration mit drei Replikaten statt mit zwei Replikaten bereitzustellen, um Datenverluste auf ein Minimum zu beschränken.

Um für ein geplantes Ereignis einen Failover vom primären Replikat auf eines der sekundären Replikate durchzuführen, führen Sie den folgenden Befehl aus:

Wenn Sie eine Verbindung mit dem primären Replikat herstellen, können Sie das folgende T-SQL verwenden, um für die SQL-Instanz ein Failover auf eines der sekundären Replikate durchzuführen:

ALTER AVAILABILITY GROUP current SET (ROLE = SECONDARY);

Wenn Sie eine Verbindung mit dem sekundären Replikat herstellen, können Sie folgendes T-SQL verwenden, um das gewünschte sekundäre Replikat zum primären Replikat höherzustufen.

ALTER AVAILABILITY GROUP current SET (ROLE = PRIMARY);

Bevorzugtes primäres Replikat

Sie können auch ein bestimmtes Replikat als primäres Replikat festlegen, indem Sie die Azure CLI wie folgt verwenden:

az sql mi-arc update --name <sqlinstance name> --k8s-namespace <namespace> --use-k8s --preferred-primary-replica <replica>

Beispiel:

az sql mi-arc update --name sqldemo --k8s-namespace my-namespace --use-k8s --preferred-primary-replica sqldemo-3

Hinweis

Kubernetes wird versuchen, das bevorzugte Replikat festzulegen, was jedoch nicht garantiert werden kann.

Wiederherstellen einer Datenbank auf einer Instanz mit mehreren Replikaten

Für die Wiederherstellung einer Datenbank in einer Verfügbarkeitsgruppe müssen zusätzliche Schritte ausgeführt werden. Die folgenden Schritte zeigen, wie Sie eine Datenbank in einer verwalteten Instanz wiederherstellen und einer Verfügbarkeitsgruppe hinzufügen.

  1. Machen Sie den externen Endpunkt der primären Instanz verfügbar, indem Sie einen neuen Kubernetes-Dienst erstellen.

    Bestimmen Sie den Pod, der das primäre Replikat hostet. Stellen Sie eine Verbindung mit der verwalteten Instanz her, und führen Sie Folgendes aus:

    SELECT @@SERVERNAME
    

    Die Abfrage gibt den Pod zurück, der das primäre Replikat hostet.

    Erstellen Sie den Kubernetes-Dienst für die primäre Instanz durch Ausführen des folgenden Befehls, falls von Ihrem Kubernetes-Cluster nodePort-Dienste verwendet werden. Ersetzen Sie podName durch den Namen des im vorherigen Schritt zurückgegebenen Servers und serviceName durch den bevorzugten Namen für den erstellten Kubernetes-Dienst.

    kubectl -n <namespaceName> expose pod <podName> --port=1533  --name=<serviceName> --type=NodePort
    

    Führen Sie für einen Lastenausgleichsdienst den gleichen Befehl aus. In diesem Fall wird jedoch ein Dienst vom Typ LoadBalancer erstellt. Beispiel:

    kubectl -n <namespaceName> expose pod <podName> --port=1533  --name=<serviceName> --type=LoadBalancer
    

    Im Anschluss finden Sie ein Beispiel für diesen Befehl, der für Azure Kubernetes Service ausgeführt wird, wobei sql2-0 der Pod ist, der das primäre Replikat hostet:

    kubectl -n arc-cluster expose pod sql2-0 --port=1533  --name=sql2-0-p --type=LoadBalancer
    

    Rufen Sie die IP-Adresse des erstellten Kubernetes-Diensts ab:

    kubectl get services -n <namespaceName>
    
  2. Stellen Sie die Datenbank am Endpunkt der primären Instanz wieder her.

    Fügen Sie die Datenbanksicherungsdatei dem Container der primären Instanz hinzu.

    kubectl cp <source file location> <pod name>:var/opt/mssql/data/<file name> -c <serviceName> -n <namespaceName>
    

    Beispiel

    kubectl cp /home/WideWorldImporters-Full.bak sql2-1:var/opt/mssql/data/WideWorldImporters-Full.bak -c arc-sqlmi -n arc
    

    Führen Sie den folgenden Befehl aus, um die Datenbanksicherungsdatei wiederherzustellen:

    RESTORE DATABASE test FROM DISK = '/var/opt/mssql/data/<file name>.bak'
    WITH MOVE '<database name>' to '/var/opt/mssql/data/<file name>.mdf'  
    ,MOVE '<database name>' to '/var/opt/mssql/data/<file name>_log.ldf'  
    ,RECOVERY, REPLACE, STATS = 5;  
    GO
    

    Beispiel

    RESTORE Database WideWorldImporters
    FROM DISK = '/var/opt/mssql/data/WideWorldImporters-Full.BAK'
    WITH
    MOVE 'WWI_Primary' TO '/var/opt/mssql/data/WideWorldImporters.mdf',
    MOVE 'WWI_UserData' TO '/var/opt/mssql/data/WideWorldImporters_UserData.ndf',
    MOVE 'WWI_Log' TO '/var/opt/mssql/data/WideWorldImporters.ldf',
    MOVE 'WWI_InMemory_Data_1' TO '/var/opt/mssql/data/WideWorldImporters_InMemory_Data_1',
    RECOVERY, REPLACE, STATS = 5;  
    GO
    
  3. Fügen Sie die Datenbank der Verfügbarkeitsgruppe hinzu.

    Damit die Datenbank der Verfügbarkeitsgruppe hinzugefügt werden kann, muss sie im vollständigen Wiederherstellungsmodus ausgeführt werden, und es muss eine Protokollsicherung durchgeführt werden. Führen Sie die folgenden TSQL-Anweisungen aus, um die wiederhergestellte Datenbank der Verfügbarkeitsgruppe hinzuzufügen:

    ALTER DATABASE <databaseName> SET RECOVERY FULL;
    BACKUP DATABASE <databaseName> TO DISK='<filePath>'
    ALTER AVAILABILITY GROUP containedag ADD DATABASE <databaseName>
    

    Im folgenden Beispiel wird die Datenbank WideWorldImporters hinzugefügt, die auf der Instanz wiederhergestellt wurde:

    ALTER DATABASE WideWorldImporters SET RECOVERY FULL;
    BACKUP DATABASE WideWorldImporters TO DISK='/var/opt/mssql/data/WideWorldImporters.bak'
    ALTER AVAILABILITY GROUP containedag ADD DATABASE WideWorldImporters
    

Wichtig

Als bewährte Methode sollten Sie den oben erstellten Kubernetes-Dienst löschen, indem Sie diesen Befehl ausführen:

kubectl delete svc sql2-0-p -n arc

Einschränkungen

Für SQL Managed Instance-Verfügbarkeitsgruppen mit Azure Arc-Unterstützung gelten die gleichen Einschränkungen wie für Verfügbarkeitsgruppen eines Big Data-Clusters. Weitere Informationen finden Sie unter Bereitstellen von Big Data-Clustern in SQL Server mit Hochverfügbarkeit.

Nächste Schritte

Erfahren Sie mehr über Features und Funktionen von Azure Arc-fähigen SQL Managed Instance-Instanzen