Anforderungsprofil: Hyper-V Cluster
Herstellerneutrales technisches Anforderungs- und Beschaffungspaket zum Entscheidungspaket „Hyper-V Cluster“.
Am Ende steht ein validierter Hyper-V-Pilot mit reproduzierbarem Host-Failover, Live Migration, Storage-/Netztrennung, Backup/Restore und dokumentiertem Lizenz-/DR-Modell.
Thema: hyperv · Stand 2026-09-21Welle 3 · Compute, Recovery & Observability
Server, Virtualisierung, Backup/Restore und Monitoring als gemeinsame Betriebsplattform dimensionieren und abnehmen.
Vor jeder Punktebewertung nachweisen
Diese Kriterien sind als technische Mindestnachweise formuliert. Nicht erfüllte Muss-Kriterien sollten nicht durch Komfort- oder Preisvorteile kompensiert werden.
| ID | Kriterium | Geforderter Nachweis |
|---|---|---|
| M01 | Clusterfähige Hardware, Firmwarestände, AD/DNS/Zeitdienst und Microsoft-Cluster-Validierung für das konkrete Design prüfen. | Hersteller-/Angebotsnachweis plus Pilot- oder Betriebsnachweis. |
| M02 | CSV-/Storage-Spaces-Direct-/SAN-Design inklusive Redundanz, Quorum und Ausfallverhalten festlegen und testen. | Hersteller-/Angebotsnachweis plus Pilot- oder Betriebsnachweis. |
| M03 | vSwitch-/SET-, VLAN-, Management-, Storage- und Live-Migration-Netze mit ausreichender Redundanz und Bandbreite planen. | Hersteller-/Angebotsnachweis plus Pilot- oder Betriebsnachweis. |
| M04 | Windows-Server-Edition, Core-Lizenzierung und Virtualisierungsrechte je Host anhand des finalen VM-Mobilitätsmodells verifizieren. | Hersteller-/Angebotsnachweis plus Pilot- oder Betriebsnachweis. |
| M05 | Backup, Application Consistency, Replica/DR und dokumentierten Failover-/Failback-Test in den Betriebsprozess aufnehmen. | Hersteller-/Angebotsnachweis plus Pilot- oder Betriebsnachweis. |
Mehrwert nur mit realem Betriebsnutzen bewerten
| ID | Kriterium | Bewertungshinweis |
|---|---|---|
| K01 | Cluster-Aware Updating oder vergleichbare Orchestrierung reduziert manuelle Wartungsschritte. | Als Mehrwert nur bewerten, wenn die Funktion für den Zielbetrieb nachweisbar nutzbar ist. |
| K02 | Replica-/DR-Funktionen lassen sich mit definierten RPO/RTO und geplantem Failback betreiben. | Als Mehrwert nur bewerten, wenn die Funktion für den Zielbetrieb nachweisbar nutzbar ist. |
| K03 | Automatisierbare Host-/VM-Bereitstellung und Konfigurationsprüfung reduzieren Drift. | Als Mehrwert nur bewerten, wenn die Funktion für den Zielbetrieb nachweisbar nutzbar ist. |
| K04 | Offene Backup-, Monitoring- und Managementschnittstellen vermeiden unnötige Toolbindung. | Als Mehrwert nur bewerten, wenn die Funktion für den Zielbetrieb nachweisbar nutzbar ist. |
Fragen für Angebot, Workshop und technische Klärung
Sind Hardware, Firmware, AD/DNS/Zeit und Cluster Validation ohne ungeklärte produktionskritische Befunde?
Sind CSV/S2D/SAN, Quorum und Storage-Fehlerdomänen passend zu Verfügbarkeit und Performance ausgelegt?
Sind Management, VM, Storage und Live Migration mit vSwitch/SET/VLAN und ausreichender Redundanz sauber getrennt?
Passen Edition, Core-Lizenzierung und Virtualisierungsrechte zur finalen Host- und Mobilitätsarchitektur?
Funktionieren Backup, anwendungskonsistenter Restore, Host-Failover und optional Replica/DR reproduzierbar?
Sind Patchen, Drain, Monitoring, Firmware und Failback als wiederholbare Betriebsprozesse dokumentiert?
Gates als objektive Abnahmekriterien verwenden
Cluster Validation und Infrastrukturabhängigkeiten zeigen keine ungeklärten produktionskritischen Befunde.
Storage- und Netzpfade bleiben bei einem definierten Einzelfehler verfügbar und konkurrieren nicht unkontrolliert um kritische Bandbreite.
Das Lizenzmodell bildet die endgültige Hostzahl, Core-Anzahl und erlaubte VM-Mobilität nachvollziehbar ab.
Repräsentative VMs überstehen Wartung und Hostausfall innerhalb definierter Grenzen und lassen sich konsistent wiederherstellen.
Failover und Failback sind dokumentiert, getestet und haben klare Owner; Clusterwartung hängt nicht von Einzelwissen ab.
Vor Produktivsetzung klären
- Cluster-, Node-, CSV/Storage- und Netzstatus inklusive Live-Migration-Pfade überwachen.
- Patches und Firmware über Drain, Migration, Abnahme und Rollback kontrolliert betreiben.
- Backup/Restore sowie Replica-/DR-Failover und Failback regelmäßig testen.
- Kapazität, VM-Dichte, Quorum und Cluster-Validation nach relevanten Änderungen überprüfen.
Vor Vertragsbindung nachweisen
- VMs, Daten und Konfigurationen mit dokumentiertem Migrationspfad auf eine Folgelösung überführen können.
- Backup-/DR-Abhängigkeiten sowie virtuelle Netz- und Storage-Konfigurationen reproduzierbar dokumentieren.
- Koexistenz, Cutover und Rückfall für repräsentative VMs vor Abschaltung des Altclusters testen.
Gewichtete Bewertung erst nach den Muss-Kriterien
Die Gewichte ergeben zusammen 100 %. Die Skala bewertet nachgewiesene Eignung – nicht Herstellergröße oder Markenpräferenz.
| Kategorie | Gewicht | Skala | Dokumentation |
|---|---|---|---|
| Availability & Failover | 25 % | 0 = nicht nachgewiesen · 1 = teilweise · 2 = erfüllt · 3 = übertroffen | Nachweis/Kommentar |
| Storage & Network | 20 % | 0 = nicht nachgewiesen · 1 = teilweise · 2 = erfüllt · 3 = übertroffen | Nachweis/Kommentar |
| Operations & Recovery | 20 % | 0 = nicht nachgewiesen · 1 = teilweise · 2 = erfüllt · 3 = übertroffen | Nachweis/Kommentar |
| Licensing & Capacity | 20 % | 0 = nicht nachgewiesen · 1 = teilweise · 2 = erfüllt · 3 = übertroffen | Nachweis/Kommentar |
| Commercial & Exit | 15 % | 0 = nicht nachgewiesen · 1 = teilweise · 2 = erfüllt · 3 = übertroffen | Nachweis/Kommentar |
Für Pilot, Entscheidung und Vertrag dokumentieren
- Cluster-Validation-Report
- Node-/Firmware-Matrix
- Storage-Design
- Quorum-Konzept
- vSwitch-/Netzmatrix
- Lizenzmodell
- Failover-Test
- Backup-/Restore-Nachweis
- DR-Test
- Betriebs-Runbook