Ein Defekt des Mainboard sollte doch deutlich schneller behoben werden können, wenn das System virtualisiert ist?
Nee, nicht wirklich.
Auf dem Server ist Windows Server 2016 "auf dem Blech" installiert und die Hyper-V Rolle hinzufügt. Dadurch wandelst du den Server in einen Bare-Metal-Hypervisor um. Das ändert aber nicht daran, dass das zugrundeliegende Windows Server Betriebssystem ebenfalls Treiber benötigt.
Geht das Mainboard vom Server hops und wird es 1:1 ersetzt, geht alles ganz normal weiter. Die Treiber sind ja bereits "da" und alles ist richtig konfiguriert.
Geht das Mainboard in ein paar Jahren hops und Ihr könnt ein Ersatzmainboard mit gleichem Sockel, RAM-Unterstützung und Chipsatz eines anderen Herstellers bekommen und steckt dort die Festplatten bzw. den RAID-Controller+Platten drauf, sollte es relativ einfach weitergehen.
Geht das Mainboard in ein paar Jahren hops und Ihr habt Probleme ein Ersatz-Mainboard anzuschaffen, könnt aber noch auf die Daten des Servers zugreifen oder habt ein vernünftiges Backup um daraus die Daten wiederherstellen zu können, könnt Ihr euch ein aktuelles System beschaffen, dort Server 2016 (oder neuer) + Hyper-V Rolle neu aufspielen und die virtuellen Maschinen importieren.
Im Zweifel kann übergangsweise auch ein Windows 10 Pro Rechner herhalten auf dem die VMs laufen, da dort auch Hyper-V in etwas abgespeckter Variante läuft.
Das einzige Ziel der Virtualisierung wäre, die Down Time im Falle eines Hardwaredefekts (Mainboard) zu minimieren.
Um Downtime
wirklich zu minimieren, bräuchtet Ihr mehrere physische Server mit Hyper-V + gegenseitige Replikation, so dass bei Ausfall eines physischen Server das eigentlich wichtige, nämlich die virtuelle Maschine, auf dem anderen physischen Server direkt wieder angefahren werden kann oder bei Ausfallerscheinungen die virtuelle Maschine sauber verschoben werden kann bevor der Server in die Knie geht.
Wie könnte der Server am einfachsten virtualisiert werden (möglichst kleiner Initialaufwand, möglichst wenig periodische Wartung)?
Gibt es leider nicht, da schon ziemlicher Stuss getrieben wurde. Meine Initialreaktion bei einem Netzwerk dieser Größe um es
richtig zu machen:
Die Nutzdaten vom Server runtersichern (alle geteilten Daten, SQL-Datenbanken usw. usf.). Die Sicherung prüfen.
Den Server komplett platt machen & neu aufsetzen, inkl. Hyper-V Rolle. Daran denken zwei Partitionen bzw. Volumes zu bauen:
C:\ für Windows + ggf. "Hypervisor-relevante" Programme
V:\ für den Speicher der VMs*
Zwei (!) virtuelle Maschinen erstellen:**
DC01 - Domänencontroller inkl. DNS + ggf. DHCP (eine kleine C:\)
AS01 - der Produktivserver mit Dateiserverdiensten, SQL-Datenbank + was Ihr sonst noch braucht (also das was euer physischer jetzt macht abzüglich DC/DNS/DHCP)
Auf DC01 wird die neue Domäne hochgezogen + GPOs, DHCP-Scope etc.
Auf AS01 werden die zuvor gesicherten Nutzdaten wiederhergestellt und die Datenbanken usw.
Alle PCs in die neue Domäne aufnehmen & ggf. lokale Profile migrieren.
Das wäre die Variante wie ich es mit genügend Wartungsfenster machen würde.
Ist das Wartungsfenster nicht groß genug, könnte man sich überlegen auf einem zusätzlichen System einen zweiten (virtuellen!) DC aufzustellen der zum "primären" DC gemacht wird bevor der physische Server plattgemacht wird. So bleibt die Domäne erhalten und die Clients bleiben in der Domäne. Kann auf genanntem Win10Pro installiert werden, sollte aber kein Klepper aus'm ARLT sein, ums mal so auszudrücken.
Optionalerweise könnte man auch einen "Aushilfs"-Fileserver bereitstellen der bspw. per robocopy /COPYALL alle Ordner mit Freigaben übertragen bekommt und nach dem Übertragen die Netzlaufwerke mit anderen GPOs umgedreht werden.
Mit der SQL-Datenbank wirds etwas kniffliger, ist aber auch nicht unmöglich. Hier am besten den Softwarehersteller ins Boot nehmen.
Optimalerweise wird der "Aushilfs"-Fileserver direkt zum produktiven AS01 gemacht (inkl. SQL Zeugs), so dass nach dem Neuaufsetzen des Ursprungs-Servers nur noch die VM da drauf verschoben werden muss.
Das ist aber jetzt nichts für Anfänger. Tretet noch mal an euer Systemhaus ran und pocht auf Nacharbeit. Idealerweise habt Ihr es schriftlich, dass virtualisiert werden sollte.
Sollten die sich sperren oder zu doof sein, sucht euch ein anderes Systemhaus die einen zweiten Server für den Übergang bereitstellen können und wissen wie man eine rollierende Dienste-Migration hinbekommt. Das ist recht überschaubar, aber Ihr braucht eine zweite Maschine.
So oder so ist die ganze Geschichte nicht lege artis wenn heutzutage ein Server nicht virtualisiert wird - gerade bei einem Windows, wo es eher nur von Vorteil ist soviele Dienste wie möglich soweit wie möglich voneinander zu trennen (SBS Flashbacks... brrrrr).
möglichst wenig periodische Wartung)
Ihr habt ehr mehr periodische Wartung, da Ihr nicht nur den physischen Server (den Hyper-V) warten müsst, sondern eben auch die virtuellen Maschinen, wobei es sich bei den VMs auf Windows Updates beschränkt.
edit: Ach ja, wie schaut's mit Backup-Software aus? Gerade wenn nicht das Budget für einen dauerhaften zweiten Host da ist, ist es umso wichtiger ein gescheites Backup-Programm zu haben das unkompliziert die virtuellen Maschinen auf einem neuen Host wiederherstellen kann. Möglichst was agentenloses, sondern etwas was auf Hypervisor-Ebene funktioniert.
*hier ggfs. ReFS prüfen da ein paar nette Vorteile ggü. NTFS für VMs
** Wenn es sich um wenigstens Server 2016
Standard handelt; Essentials darf max. 1 VM