Broadcoms aktuelle vSAN-Anleitung zum Hardware-Refresh beschreibt zwei grundlegende Wege: Hosts im bestehenden Cluster ersetzen oder einen neuen Cluster aufbauen und Workloads migrieren. Beide führen zu neuer Hardware, erzeugen aber andere Fehlerbereiche. Wird die Beschaffungsliste zum Migrationsplan erklärt, bleibt die eigentliche Entscheidung über Datenbewegung, reduzierte Redundanz und Rückweg unsichtbar.
Bedeutung für den Betrieb
Ein In-place-Refresh erhält die Clusteridentität und kann temporäre Hardware reduzieren. Gleichzeitig erzwingt er wiederholte Evakuierungs-, Rebuild-, Maintenance-Mode- und Kompatibilitätszyklen, während derselbe Produktivcluster unter seinen Workloads verändert wird. Freie Kapazität, Resynchronisationsverkehr, Objektkonformität, Fault-Domain-Aufteilung und Zeit mit verringerter Redundanz müssen für jeden Schritt gemessen werden.
Ein neuer Cluster benötigt zusätzliche Kapazität und Migrationskonnektivität, schafft aber eine klarere Rückfallgrenze. Hardware, Firmware, Netzwerk, Storage Policies, Monitoring, Backup und Betriebsverfahren können vor dem ersten Workload getestet werden. Auch RAID-Layout oder Architektur lassen sich bewusst ändern, statt alte Annahmen allein wegen des unveränderten Clusternamens mitzunehmen.
Die Wahl folgt Belegen: aktuelle Auslastung, Rebuild-Dauer, Fehlertoleranz während der Wartung, Workload-Mobilität, Netzkapazität, Lizenz- und Supportgrenzen sowie Recovery bei Ausfall eines Hosts oder einer Disk Group mitten in der Änderung. Eine repräsentative Evakuierung und Migration wird geprobt; gemessen werden Anwendungsfolgen und nicht nur abgeschlossene vSAN-Tasks.
Praktische Konsequenz
Die praktische Konsequenz: Hardware-Refresh ist ein Datenmigrationsprojekt. Der gewählte Weg braucht ausreichende Restresilienz und einen glaubwürdigen Rückweg; temporäre Kapazität und Fenster werden aus gemessener Bewegung abgeleitet. Servertausch ist die sichtbare Aktion, Kontrolle über Datenlage und Schutz die eigentliche Änderung.