Der "Client" Hyper-V hat per default einen NAT Switch. Da müsste man also vorher Hand anlegen, um später vorzubeugen. Den "default NAT Switch" sollte man im "Client" Hyper-V auf gar keinen Fall anpacken/ändern!
Es sollte hier halt klar sein, dass das "nur" eine Form von "Disaster Recovery" ist. Wenn es um "Verfügbarkeit" gehen sollte, ist das der völlig falsche Ansatz. Egal ob wir hier aber über Disaster Recovery oder Verfügbarkeit reden, will man sich da im Fall der Fälle drauf verlassen können bzw. müssen. Und an der Stelle würde ich pauschal erst einmal Zweifel anmelden.
In dem DR Szenario - sofern ich es jetzt verstanden habe 🙂 - würde ich in eine ähnlich gut ausgestattete Hardware investieren und dort ebenfalls einen Windows Server mit Hyper-V Rolle einsetzen, den Kommunikationsserver virtualisieren und zusätzlich halt Luft für den Fileserver haben. Jetzt könnte man überlegen, das DR über einen klassischen Restore umzusetzen, eine mögliche Replikationslösung der Backupsoftware einzusetzen oder ggfs. mit Hyper-V Replika zu arbeiten. It depends.
Ich würde hier noch zu sehen, auf jeder Hyper-V Instanz dann einen dedizierten Domain Controller zu haben und den DATEV Fileserver ebenfalls dediziert ohne weitere Rollen zu betreiben, um im Fall der Fälle nahezu keine Abhängigkeiten von anderen Services zu haben.
Egal wie man sich entscheidet, sollte das in vorher Ruhe vorbereitet, (regelmäßig) getestet und dokumentiert werden.
Das sind jetzt mal nur schnell ein paar Gedanken / Ansätze. Ohne Details zur bestehenden Infrastruktur würde ich mich da nicht drauf verlassen. 😉
