Anforderungen an einen vSAN Stretched Cluster: Witness, Latenz, Bandbreite und was beim Ausfall eines Standorts passiert

Anforderungen an einen vSAN Stretched Cluster im Überblick

Ein vSAN Stretched Cluster braucht zwei Datenstandorte, normalerweise mit gleich vielen Hosts, und einen Witness-Host an einem dritten Standort. Broadcoms Dokumentation zu VCF 9.1, aktualisiert am 5. Oktober 2026, hält fest, dass die Datenstandorte „eine Netzwerklatenz von höchstens fünf Millisekunden (5 ms) Round Trip (RTT) haben müssen“, und die Seiten zu vSAN 8.0 nennen dieselbe Grenze. Zwischen dem Witness und den Datenstandorten müssen weniger als 200 ms RTT liegen. Broadcoms vSAN Stretched Cluster Guide zu 9.1 vom 5. Mai 2026 ergänzt die Werte für die Bandbreite und eine Größenspanne von 1+1+1 bis 20+20+1 Hosts.

Broadcom TechDocs zu VCF 9.1 (2. September bis 5. Oktober 2026) und vSAN 8.0 (9. September 2026); vSAN Stretched Cluster Guide zu 9.1, der sich auf ESA konzentriert (5. Mai 2026).

Der Witness-Host und die vSAN-Witness-Appliance

Ein Stretched Cluster hat drei Fehlerdomänen: den bevorzugten Standort, den sekundären Standort und den Witness. Der Witness speichert „nur Metadaten wie Witness-Komponenten“ und dient als Tie-Breaker, wenn das Netzwerk zwischen den Datenstandorten partitioniert wird. Er kann ein physischer Host oder ein ESX-Host in einer VM sein, führt keine virtuellen Maschinen aus und bedient nur einen einzigen Stretched Cluster, während sich Zwei-Knoten-Cluster einen Witness teilen können. Die Appliance gehört an „einen dritten Standort, unabhängig von den beiden Standorten“, teilt mit keinem von beiden physische Ressourcen, und es gibt sie in getrennten Versionen für ESA und OSA (Dokumentation zu 9.1).

Broadcom TechDocs, „Deploying a vSAN Witness Appliance“ zu VCF 9.1 (10. September 2026) und vSAN 8.0 (9. September 2026); je Größe gibt es nur eine Komponentengrenze, über beiden Tabellen aufgeführt und für Standard-VM-Konfigurationen geschätzt; in der OSA-Tabelle heißt die mittlere Größe Normal.

Erstellen Sie vom Witness-Host keine Snapshots und kein Backup, und ersetzen Sie ihn, wenn er ausfällt (Designüberlegungen zu vSAN 8.0). In 9.x muss ein physischer Host, der selbst der Witness ist oder die Witness-Appliance ausführt, mit esxcli vsan witness license set und der Option --enable true gekennzeichnet und danach neu gestartet werden, bevor er ins vCenter-Inventar aufgenommen wird, auch nach einem Upgrade von 8.x; andernfalls erhält er die Witness-Lizenz nicht (KB 401072).

Latenz, Bandbreite und Netzwerkdesign zwischen den Standorten

Bei der Spiegelung zwischen den Standorten werden die Daten jedes Objekts synchron an beide Standorte geschrieben, jeder Schreibvorgang wartet also auf den anderen Datenstandort. Der Stretched-Cluster-Leitfaden nennt 10 Gbit/s zwischen den Datenstandorten „das unterstützte Minimum“. Ist „Site read locality“ aktiviert, wie es der Leitfaden verlangt, „kommen Lesevorgänge immer von dem Standort der VM-Instanz, die den Lesevorgang anfordert“; dimensionieren Sie die Verbindung daher nach der Schreibrate der gespiegelten VMs in Spitzenzeiten, zuzüglich der Resynchronisierung nach einem Ausfall. Zum Witness ergeben etwa 2 Mbit/s je 1.000 Komponenten nach unserer Rechnung rund 44 Mbit/s für einen Witness mit den 21.833 Komponenten der Größe Medium.

Broadcoms Netzwerkdesign für 9.1 unterstützt zwischen den Datenstandorten ein gestrecktes Layer-2-Netz oder ein geroutetes Layer-3-Netz und empfiehlt Layer 3 „für Fehlerisolierung und einfachere Fehlerbehebung“. Wie weit die Standorte bei 5 ms auseinanderliegen können und welche regionalen Risiken sie dennoch teilen, steht in unserem Leitfaden dazu, wie weit ein Ausweichstandort vom primären Rechenzentrum entfernt sein sollte.

Speicherrichtlinien, Standortaffinität und Rohkapazität

Den Schutz auf Standortebene legen Sie je VM in der Speicherrichtlinie fest. „Site disaster tolerance“ bietet „Site mirroring - stretched cluster“, das die Objektdaten an beide Standorte repliziert, oder die Optionen „None - keep data on Preferred“ und „None - keep data on Secondary“, die ein Objekt an einem einzigen Standort halten; „Failures to tolerate“ legt dann „die Anzahl der zu tolerierenden Ausfälle innerhalb jedes Standorts“ fest. Wenn VCF einen Cluster streckt, stellt SDDC Manager dessen Richtlinie auf „Site mirroring - stretched cluster“ um.

Für ESA mit der Auto-RAID-Regel von 9.1 beschreibt Broadcoms Designleitfaden vom 5. Mai 2026 eine Spiegelung zwischen den Standorten plus RAID-5 innerhalb jedes Standorts bei 3 bis 5 Hosts je Standort oder RAID-6 bei 6 oder mehr, beides mit dem 3,0-Fachen der Objektgröße an Rohkapazität. Unter drei Hosts je Standort gibt es keinen Schutz innerhalb eines Standorts (das 2,0-Fache), sodass nach dem Ausfall eines Hosts für die betroffenen Objekte nur noch die Kopie am anderen Standort bleibt. Auto-RAID ist nur für ESA dokumentiert; unter OSA legen Sie „Failures to tolerate“ selbst fest, und der Stretched-Cluster-Leitfaden zu 9.1 verweist OSA-Anwender auf seine früheren Ausgaben. Das Whitepaper zur Speichereffizienz vom 11. Mai 2026 hält fest, dass Stretched Cluster gegenüber einem Cluster an einem einzigen Standort „die effektive Kapazität halbieren“, und die globale Deduplizierung in 9.1 unterstützt sie nicht. RAID-Regeln je Architektur stehen in unserem Vergleich von vSAN ESA und OSA.

„Must“-Regeln von DRS halten eine VM an einem Standort, und der Leitfaden nennt sie für VMs, die „keine Resilienz auf Standortebene benötigen oder für ihre Resilienz eine eigene Replikation auf Anwendungsebene nutzen“; dort passen Richtlinien, die die Daten an einem Standort halten, etwa für Domänencontroller mit je einem an jedem Standort.

Einstellungen für vSphere HA und DRS in einem Stretched Cluster

Broadcoms Stretched-Cluster-Leitfaden und die Designüberlegungen zu vSAN 8.0 nennen diese Einstellungen:

1. Aktivieren Sie vSphere HA und setzen Sie Admission Control für CPU und Arbeitsspeicher auf 50 %, damit der verbleibende Standort jede VM des ausgefallenen neu starten kann.
2. Setzen Sie die Reaktion auf Hostisolierung auf „Power off and restart VMs“.
3. Setzen Sie das.isolationaddress0 und das.isolationaddress1 auf je eine IP-Adresse im vSAN-Netzwerk jedes Standorts und das.usedefaultisolationaddress auf „false“.
4. Deaktivieren Sie die Datastore-Heartbeats von HA, sofern kein Datastore außerhalb von vSAN verfügbar ist.
5. Aktivieren Sie DRS, legen Sie Host- und VM-Gruppen an, jeweils eine pro Standort, und verknüpfen Sie sie durch VM-Host-Regeln vom Typ „should“.
6. Lassen Sie „Site read locality“ aktiviert.

„Should“-Regeln halten VMs im Normalbetrieb an ihrem Standort und erlauben ihnen, „bei einem HA-Ereignis wie einem Standortausfall am anderen Standort zu laufen“. Seit vSAN 7.0 Update 2 kann DRS vollautomatisiert laufen, und kehrt ein ausgefallener Standort zurück, verschiebt DRS eine VM erst dann zurück, wenn ihre Daten vollständig resynchronisiert sind. Laut den Designüberlegungen zu vSAN 8.0 funktioniert vSphere Fault Tolerance in einem Stretched Cluster nur für VMs, deren Richtlinie die Daten an einem Standort hält.

Was passiert, wenn ein Standort, die Verbindung oder der Witness ausfällt

Broadcom TechDocs zu VCF 9.1 und vSAN 8.0 (September und Oktober 2026); vSAN Stretched Cluster Guide zu 9.1 (5. Mai 2026).

VMs eines ausgefallenen Standorts starten am anderen Standort neu, wie nach einem Stromausfall, und kein Schreibvorgang, der auf einem gespiegelten Objekt bestätigt wurde, geht verloren. Adaptive Quorum Control, ab vSAN 7 Update 3, berechnet die Stimmen nach einem Standortausfall innerhalb von „wenigen Sekunden bis wenigen Minuten“ neu und „schützt nicht vor einem gleichzeitigen Doppelausfall eines Datenstandorts und eines Witness“.

Standort-Wartungsmodus und Site Takeover in VCF 9.1

VCF 9.1 ergänzt einen Wartungsmodus für ganze Standorte in Stretched Clustern unter ESA und OSA, mit vCenter und ESX-Hosts ab 9.1. Ein Beitrag im VCF-Blog vom 1. August 2025 hatte ihn zusammen mit dem manuellen Site Takeover für VCF 9.0 angekündigt, den Takeover zunächst in eingeschränkter Verfügbarkeit über einen Technical Qualification Request. Die Release Notes zu 9.1 führen die Wartung ganzer Standorte als neu auf, und Broadcoms Whitepaper zur Verfügbarkeit vom 23. September 2026 bezeichnet beide Funktionen als neu in 9.1. Werden alle Hosts eines Standorts Host für Host in den Wartungsmodus versetzt, „kann dies zur Unzugänglichkeit von Objekten führen, wenn der aktive Standort ausfällt“, warnt Broadcom. Der Wartungsvorgang für den Standort bringt dessen Komponenten auf einen einheitlichen Zeitpunkt, schaltet VMs aus, deren Daten lokal an diesem Standort liegen, und migriert Workloads an den aktiven Standort. Fällt danach der aktive Standort aus und lässt sich nicht wiederherstellen, stellt Site Takeover die Objekte „auf einen älteren Zeitpunkt“ wieder her, nach unserer Lesart auf den Beginn der Wartung, sodass spätere Schreibvorgänge verloren sind. Laut Broadcoms Leitfaden steht der manuelle Site Takeover in 9.1 für alle Stretched Cluster zur Verfügung, während die Dokumentation zu 9.1 vSAN-Storage-Cluster davon ausnimmt.

Unsere VMware-Optimierung umfasst Versions- und Architektur-Updates von vSphere, vSAN, NSX und VCF in vereinbarten Wartungsfenstern mit Rollback-Plan. Schicken Sie uns Ihre Hosts je Standort, die gemessene RTT und Ihre vSAN-Version über das Formular unten.

Einrichtung des Clusters und was VVF und VCF enthalten

Ohne SDDC Manager richten Sie den Stretched Cluster im vSphere Client unter „Configure“, „vSAN“, „Fault Domains“, „Configure Stretched Cluster“ ein, mit einem Witness-Host außerhalb des Clusters. In VCF werden Cluster über die API von SDDC Manager gestreckt, mit gleich vielen Hosts in beiden Availability Zones, und der Standard-Cluster der Management-Domain muss vor jedem Cluster einer Workload-Domain gestreckt werden. VCF kann keine Cluster strecken, die eine vSAN-Speicherrichtlinie mit anderen Clustern teilen, DPU-gestützte Hosts enthalten, innerhalb einer Availability Zone Subnetze mischen oder unter ESA die globale Deduplizierung nutzen. Stretched Cluster unter ESA werden laut den Release Notes zu vSAN 8.0 Update 3 (Juni 2024) seit VCF 5.2 vollständig unterstützt.

Broadcoms Funktionsvergleich zu 9.1.1 (30. September 2026) markiert Stretched Cluster für vSphere Foundation (VVF), VCF Edge und VMware Cloud Foundation (VCF). Die Programmdokumentationen vom Juni 2026 enthalten 0,25 TiB vSAN je VVF-Kern und 1 TiB je VCF-Kern, mit Add-on-TiB darüber hinaus. Die Programmdokumentation zu vSAN vom Mai 2026 zählt „den gesamten rohen physischen Speicher, der von der Software auf allen Servern im vSAN-Cluster beansprucht wird“, was in einem Stretched Cluster beide Standorte einschließt. Beim Faktor 3,0 von Auto-RAID unter ESA brauchen 10 TiB VM-Daten nach unserer Rechnung 30 TiB lizenzierte Rohkapazität, vor Komprimierung und Reservekapazität. Weitere Unterschiede zwischen den Produkten stehen in unserem Vergleich von VVF und VCF.

Wann ein Stretched Cluster passt und wann asynchrone DR genügt

Ein Stretched Cluster eignet sich für Systeme, die beim Ausfall eines Standorts keinen bestätigten Schreibvorgang verlieren dürfen und innerhalb von Minuten wieder laufen müssen, über einen Neustart durch HA. Unsere Seite zu Cloud Disaster Recovery nennt für einen Aktiv-aktiv-Synchron-Cluster einen RPO von etwa null und einen RTO von Minuten als typische Werte und vermerkt, dass er Infrastruktur und Budget verdoppelt. Standorte, die höchstens 5 ms auseinanderliegen, können regionale Risiken teilen, und die Spiegelung kopiert einen beschädigten oder verschlüsselten Block sofort mit, daher bleiben Backups und eine entfernte asynchrone Kopie notwendig. Für Systeme, die einen Datenverlust von Minuten und ein bis zwei Stunden bis zur Wiederherstellung verkraften, genügt asynchrone Replikation; wie Sie die Systeme in Stufen einteilen, steht in unserem Leitfaden zur Wahl von RPO und RTO.

Unser Service Cloud Disaster Recovery repliziert virtuelle Maschinen mit Veeam ab einem 15-Minuten-Intervall an einen Ausweichstandort in Baltnetas Tier-3-Rechenzentren in Litauen. Nennen Sie uns, welche Systeme einen Wiederherstellungspunkt von null brauchen und welche warten können.

Was wir tun

Eurokommerz hält den Vertrag und liefert die Hardware sowie die VMware/Broadcom-Lizenzen; die technische Umsetzung kommt von unserem Engineering-Partner Vixen.UNO, alles unter einem europäischen Vertrag. Im Rahmen der VMware-Optimierung auditiert Vixen.UNO die Umgebung und ihre Lizenzen und führt Versions- und Architektur-Updates von vSphere, vSAN, NSX und VCF in vereinbarten Wartungsfenstern durch, mit einem Rollback-Plan für jede Etappe; danach folgt Support unter einem vereinbarten SLA. Unser Service Cloud Disaster Recovery ist für kritische Systeme ohne das Budget für ein zweites Rechenzentrum ausgelegt, mit RPO und RTO im SLA fixiert; braucht ein System einen RPO von null, ist das Aktiv-aktiv-Synchron-Clustering, eine andere Lösungs- und Budgetklasse, und das sagen wir im ersten Gespräch. Das erste Gespräch ist kostenlos; der Preis des technischen Assessments steht vor Beginn fest.

FAQ