# Multi-Site & DR: Hochverfügbarkeit über Raumgrenzen hinweg

TL;DR / Management Summary Ein lokaler Cluster schützt vor dem Ausfall eines Servers, aber nicht vor dem Ausfall eines gesamten Rechenzentrums. Wir nutzen Multi-Site Setups (auch Stretch-Cluster genannt) oder Disaster Recovery Standorte, um den Betrieb bei Brand, Hochwasser oder Stromausfall aufrechtzuerhalten. Ein Senior Admin kombiniert hierfür Storage Replica (Artikel 502) für die Daten-Ebene mit AD-Sites (Artikel 492) für die Identitäts-Ebene.

# 1. Einführung & Architektur-Modelle

Den Ernstfall planen.

Es gibt zwei grundlegende Ansätze:

  1. Stretch Cluster (Aktiv-Aktiv): Ein einziger logischer Cluster über zwei Standorte.
    • Ziel: Automatischer Failover mit RPO=0 (kein Datenverlust).
    • Anforderung: Sehr geringe Latenz (< 5ms RTT) und synchrone Replikation.
  2. Disaster Recovery (Aktiv-Passiv): Getrennte Standorte.
    • Ziel: Manueller oder teilautomatisierter Schwenk bei Totalverlust.
    • Technik: Asynchrone Replikation (RPO > 0).

# Architektur-Übersicht (Mermaid)

graph LR
    subgraph "Site A (Main RZ)"
    Node1[Cluster Node 1]
    Node2[Cluster Node 2]
    end

    subgraph "Site B (Backup RZ)"
    Node3[Cluster Node 3]
    end

    Node1 & Node2 <-->|Sync Storage Replica| Node3
    DC1[DC Site A] <-->|AD Sync| DC2[DC Site B]

# 2. Einrichtung in der Praxis

Die Verbindung schaffen.

# Schritt 1: Storage Replica (SR) konfigurieren

SR ist der Kleber des Multi-Site Clusters.

# Partnerschaft zwischen den Standorten erstellen
New-SRPartnership -SourceComputerName "NODE-RZ1" -SourceRGName "Group01" `
    -SourceVolumeName "D:" -SourceLogVolumeName "L:" `
    -DestinationComputerName "NODE-RZ2" -DestinationRGName "Group02" `
    -DestinationVolumeName "D:" -DestinationLogVolumeName "L:" `
    -ReplicationMode Asynchronous

# Schritt 2: Cluster-Quorum anpassen

In einem Multi-Site Setup ist ein Witness an einem dritten Ort (Cloud Witness, Artikel 508) überlebenswichtig, um Split-Brain zu verhindern.

# 3. Deep Dive: Netzwerk-Latenz & Bandbreite

Die Physik bändigen.

Das größte Problem bei Multi-Site ist die Geschwindigkeit des Lichts.

# 4. Day-2 Operations: Der Failover-Test

Den ‘Big Red Button’ drücken.

Ein DR-Plan ist wertlos, wenn er nie getestet wurde.

# 5. Troubleshooting & “War Stories”

Wenn der Sync-Strom versiegt.

# Top 3 Fehlerbilder

  1. Symptom: VMs am zweiten Standort starten nicht.

    • Ursache: Die IP-Adressen passen nicht zum lokalen Subnetz am DR-Ort.
    • Lösung: Nutzung von Hyper-V Replica Failover IP (Artikel 509) oder SDN (Software Defined Networking).

  2. Symptom: Replikations-Backlog wächst unendlich.

    • Ursache: Die Schreiblast in RZ1 ist höher als die WAN-Bandbreite zu RZ2.
    • Lösung: Log-Volume vergrößern oder asynchronen Modus optimieren.

  3. Symptom: “Flapping” zwischen Standorten bei kurzen Link-Ausfällen.

    • Lösung: Cluster-Eigenschaft SameSubnetDelay und CrossSubnetDelay erhöhen, damit der Cluster kleine Aussetzer toleriert.

# “War Story”: Der “Auto-Failover” Amoklauf

Ein Kunde betrieb einen Stretch-Cluster über zwei Gebäude. Der Glasfaser-Link zwischen den Gebäuden war beschädigt. Das Ergebnis: Der Cluster verlor alle 5 Minuten die Verbindung zum Quorum. Die VMs sprangen wie Ping-Pong-Bälle zwischen den Gebäuden hin und her. Da jeder Start einer Datenbank-VM 10 Minuten dauerte, war der Dienst für 8 Stunden offline – obwohl eigentlich Hardware vorhanden war. Lehre: Automatischer Failover über WAN-Links ist gefährlich. Setzen Sie lieber auf manuelle Bestätigung oder extrem konservative Timeouts.

# 6. Monitoring & Reporting

Dashboard der Fernreplikation.

# Wichtige Metriken

# 7. Fazit & Empfehlung

Multi-Site ist die Königsdisziplin der Administration.

# Anhang: Cheatsheet

Aufgabe Befehl
SR Status Get-SRGroup
Sync-Richtung drehen Set-SRPartnership -NewSource...
WAN Latenz-Test Test-SRTopology
Cluster Site Config (Get-Cluster).CrossSiteDelay = 4000

# Referenzen