Warum Failovergruppen für KMU mit Azure wichtig sind

Wenn Du produktive Daten in der Cloud hast, willst Du Ausfallsicherheit.
Und keine Ausreden bei Ausfällen.

Mit Azure SQL Managed Instance (MI) bekommst Du fast alles aus dem On-Prem-SQL – aber eben als Platform-as-a-Service.
Und: Du kannst mit Auto-Failovergruppen echte Hochverfügbarkeit über Regionen hinweg aufbauen.
Ohne eigenen Cluster. Ohne Storage-Spiegelung. Ohne AlwaysOn-Flickwerk.

Was ist eine Failovergruppe in Azure SQL MI?

Eine Failovergruppe (FOG) ist:

• ein logisches Konstrukt
• über zwei Azure-Regionen hinweg
• mit synchroner oder asynchroner Replikation
• mit automatischem oder manuellem Failover
• inklusive DNS-Routing für Read/Write und Read-Only

Das Ganze funktioniert zwischen zwei Managed Instances.

Architekturüberblick

Einrichtung per Azure CLI (Basis)

az sql mi failover-group create \
  --name ds-fog \
  --mi "mi-primary" \
  --partner-mi "mi-secondary" \
  --partner-resource-group "ds-rg" \
  --add-db "db1" "db2" \
  --failover-policy Automatic \
  --grace-period 1

Der Parameter --grace-period gibt an, wie viele Stunden Azure wartet, bevor automatisch gefailovert wird.

DNS-Ziele nutzen

-- Read/Write DNS
Server = ds-fog.database.windows.net

-- Read-Only DNS
Server = ds-fog.secondary.database.windows.net

Kannst Du in Deiner App direkt eintragen.
Beim Failover aktualisiert Azure das DNS automatisch.
Dauert 30–60 Sekunden.

Status prüfen mit T-SQL

SELECT * 
FROM sys.dm_geo_replication_links;

Oder:

SELECT 
    database_name,
    replication_state_desc,
    partner_server,
    role_desc
FROM sys.dm_database_failover_group_states;

So siehst Du, ob alles synchron ist.
Und ob Deine Instanz noch Primary ist.

Manuelles Failover auslösen

az sql mi failover-group set-primary \
  --name ds-fog \
  --mi "mi-secondary"

Wichtig z. B. bei geplanten Wartungen oder Region-Ausfalltests.

Wichtige Einschränkungen

• Nur zwischen zwei Managed Instances
• Kein Failover von Einzel-DBs (das ist nur bei Azure SQL Database möglich)
• Kein Einfluss auf Backup-Zeitpunkt oder LSN
• Latenz ist bei asynchroner Replikation spürbar
• Du brauchst DNS-fähige Applikationen (keine hart codierten IPs)

Typische Fehlerquellen

Mein Fazit

Wenn Du in Azure arbeitest und Verfügbarkeit wichtig ist, sind Failovergruppen Pflicht.
Gerade für KMU mit hybriden Szenarien – z. B. lokale Produktion + Cloud-Reporting.

Die Technik ist solide.
Die Einrichtung klar.
Und Du bekommst ein Feature, das sonst HA-Cluster + Storage + DNS-Routing bräuchte.