4
Hyper-V fuer PDC, TS, SQL- und Exchange-Server
Für ein kleines Netz möchte ich einen physikalischen Server einrichten und mit Hyper-V den Primary Domain Controll, einen Terminalserver (Remote Desktop Sitzungshost), einen SQL-Server und einen Exchange-Server sinnvoll verteilen.
Auf Grund der Hardwarekonstellation wäre es mir möglich, drei virtuelle Maschinen einzurichten und diesen je ein physikalische Volume zuzuweisen. Falls ich mehr virtuelle Maschinen einsetzen wollte, müsste ich auf Disk-Images (VHD) zurückgreifen, was natürlich Geschwindigkeitseinbußen bedeuten würde.
Im Fall von drei virtuellen Maschinen hätte ich somit:
Erste Maschine: Primary Domain Controller
Zweite Maschine: Terminal Services (Remote Desktop Sitzungshost)
Dritte Maschine: noch frei
Zu verteilen hätte ich nun noch einen SQL Server für eine kleine Datenbank und einen Exchange Server für geringes Nutzungsvolumen und diverse kleinere Dienste wie WSUS, das Backend eines Versionskontrollsystems (VisualSVN) und natürlich die Userdaten, mal abgesehen davon, dass ich keine zusätzlichen Serverdienste auf dem Terminal Server installieren werde.
Wie würdet ihr das sinnvoll verteilen? Jedem Service eine eigene Hyper-V-Instanz zu spendieren hat natürlich einen gewissen Charme, aber führt schnell zu inflationär vielen Instanzen. Und man müsste auf die Möglichkeit verzichten, ganzes physikalische Disks an die Instanzen durchzureichen.
Ich tendiere derzeit zu:
Erste Maschine: Primary Domain Controller, File- und Print-Services
Zweite Maschine: Terminal Services (Remote Desktop Sitzungshost)
Dritte Maschine: SQL Server, Exchange Server und kleine weitere Services
Für Ideen, Tipps, Anmerkungen etc. bin ich dankbar.
Auf Grund der Hardwarekonstellation wäre es mir möglich, drei virtuelle Maschinen einzurichten und diesen je ein physikalische Volume zuzuweisen. Falls ich mehr virtuelle Maschinen einsetzen wollte, müsste ich auf Disk-Images (VHD) zurückgreifen, was natürlich Geschwindigkeitseinbußen bedeuten würde.
Im Fall von drei virtuellen Maschinen hätte ich somit:
Erste Maschine: Primary Domain Controller
Zweite Maschine: Terminal Services (Remote Desktop Sitzungshost)
Dritte Maschine: noch frei
Zu verteilen hätte ich nun noch einen SQL Server für eine kleine Datenbank und einen Exchange Server für geringes Nutzungsvolumen und diverse kleinere Dienste wie WSUS, das Backend eines Versionskontrollsystems (VisualSVN) und natürlich die Userdaten, mal abgesehen davon, dass ich keine zusätzlichen Serverdienste auf dem Terminal Server installieren werde.
Wie würdet ihr das sinnvoll verteilen? Jedem Service eine eigene Hyper-V-Instanz zu spendieren hat natürlich einen gewissen Charme, aber führt schnell zu inflationär vielen Instanzen. Und man müsste auf die Möglichkeit verzichten, ganzes physikalische Disks an die Instanzen durchzureichen.
Ich tendiere derzeit zu:
Erste Maschine: Primary Domain Controller, File- und Print-Services
Zweite Maschine: Terminal Services (Remote Desktop Sitzungshost)
Dritte Maschine: SQL Server, Exchange Server und kleine weitere Services
Für Ideen, Tipps, Anmerkungen etc. bin ich dankbar.
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 150005
Url: https://administrator.de/forum/hyper-v-fuer-pdc-ts-sql-und-exchange-server-150005.html
Ausgedruckt am: 14.04.2025 um 00:04 Uhr
4 Kommentare
Neuester Kommentar
Servus,
ein vernünftiger HOST verkraftet es, wenn du jede Technologie in einer eigenen VM laufen lässt. SQL und Exchange in der gleichen VM zu installieren, ist überhaupt keine gute Idee.
Beides sind aufwändige Technologien und beide Technologien benötigen in einem Recovery Szenario besondere Aufmerksamkeit. Wenn man beides zur gleichen Zeit rücksichern muss,
erleichtert es dem Admin keinesfalls die Arbeit. Aber was machst du, wenn der HOST crasht und irreparabel defekt ist?
Denn eine professionelle Virtualisierung fängt mit min. zwei HOSTs an.
Und in jeder Domäne sollten wegen der Ausfallsicherheit, mindestens zwei DCs betrieben werden.
Viele Grüße
/ > Yusuf Dikmenoglu
ein vernünftiger HOST verkraftet es, wenn du jede Technologie in einer eigenen VM laufen lässt. SQL und Exchange in der gleichen VM zu installieren, ist überhaupt keine gute Idee.
Beides sind aufwändige Technologien und beide Technologien benötigen in einem Recovery Szenario besondere Aufmerksamkeit. Wenn man beides zur gleichen Zeit rücksichern muss,
erleichtert es dem Admin keinesfalls die Arbeit. Aber was machst du, wenn der HOST crasht und irreparabel defekt ist?
Denn eine professionelle Virtualisierung fängt mit min. zwei HOSTs an.
Und in jeder Domäne sollten wegen der Ausfallsicherheit, mindestens zwei DCs betrieben werden.
Viele Grüße
/ > Yusuf Dikmenoglu
Es geht hierbei um ein Szenario in einem Kleinstunternehmen, das bislang ohnehin nur einen Server einsetzt. Damit hat man natürlich keinerlei Redundanz, richtig. Ohne Virtualisierung hätte man abgesehen vom Terminalserver dann wohl alles in einen physikalischen Host gestopft, was sicherlich nicht besser wäre.
Den Hinweis "ein vernünftiger HOST verkraftet es, wenn du jede Technologie in einer eigenen VM laufen lässt." verstehe ich so, dass man auf den Luxus eine physikalischen Volumes pro VM verzichten sollte und stattdessen VHDs nutzen sollte? Oder ist damit gemeint, dass man die Hardware so auslegen sollte, dass für jede VM ein physikalischen Volume bereit steht?
(Zwei Server und Storage über iSCSI sind hier wirklich oversized.)
Den Hinweis "ein vernünftiger HOST verkraftet es, wenn du jede Technologie in einer eigenen VM laufen lässt." verstehe ich so, dass man auf den Luxus eine physikalischen Volumes pro VM verzichten sollte und stattdessen VHDs nutzen sollte? Oder ist damit gemeint, dass man die Hardware so auslegen sollte, dass für jede VM ein physikalischen Volume bereit steht?
(Zwei Server und Storage über iSCSI sind hier wirklich oversized.)
Es geht hierbei um ein Szenario in einem Kleinstunternehmen
Der SBS stellt keine Alternative dar? Und trotzdem sollte man einen zweiten DC wegen der Ausfallsicherheit installieren.
Das kann schon eine noch funktionierende Client-Hardware sein. Dann wird /lediglich/ eine Serverlizenz benötigt.
Das lässt sich gegenüber dem Kunden plausibel erklären.
Den Hinweis...
Nein, erstmal bezog ich mich darauf, dass man auf einem HOST mit genügend Ressourcen *jede* Technologie in einer eigenen VM installieren kann.
Guß, Yusuf Dikmenoglu
Warum soll eig. die Geschwindigkeit eines physikalischen Volumens deutlisch schneller zur VHD sein?
Die VHD befindet sich ja auch auf dem physikalischen Volumen?
Die VHD befindet sich ja auch auf dem physikalischen Volumen?
(Zwei Server und Storage über iSCSI sind hier wirklich oversized.)
Naja, kommt drauf an wieviel dem Geschäft durch die Lappen gehen, wenn dein HOST crasht und du z.B. 24h oder noch länger benötigst um alles wiederherzustellen.
