bobbele66
Goto Top

VMware oder Hyper-V, Tipps bei der Virtualisierung

Hallo Community,
ich benötige Tipps/Vorschläge bei der Virtualisierung mehrerer phys. Server. Ich habe noch wenig Erfahrung mit VM, außer dass mit der VM Workstation einige VMs zu Lernzwecken am Laufen habe.
Ich beschreibe hier mal den Ist-Zustand und anschließend was geplant ist:

1 phys. Server 8 GB RAM mit SBS 2008 Premium (= AD, SQL, Fileserver, Acronis Backup Software für Server und f. SQL)
1 phys. Server 16 GB RAM mit Server 2008 als Terminalserver für externe Filiale (Zyxel site to site VPN mit SDSL 6 MBit)
1 phys. Server 16 GB RAM mit Server 2008 Std. für Avaya Telefonanlage
1 phys. PC mit Windows 7 Prof. x64 für Videoaufzeichnungen

Es melden sich ca. 25 Clients mit Windows 7 Prof. an der Domäne an (SBS 2008)
Es melden sich ca. 20 Clients am Terminalserver an, die auf den SQL auf dem SBS zugreifen

Bevor jetzt (berechtigt) gemeckert wird, dass das völlig unzureichende Hardware ist, das ist mir bewusst. Das Ganze ist gewachsen, angefangen vor 6 Jahren mit dem SBS und 3 Clients mit Windows XP. Die Geschäftsleitung wollte die IT bewusst klein halten, als ich einen „größeren“ Server vorgeschlagen hatte, kam die Antwort „wir wollen nicht mit Kanonen auf Spatzen schießen“.
Und – es läuft seit Jahren zufriedenstellend.

Nun sollte noch ein weiterer phys. Server angeschafft werden für einen Webserver.

Ich möchte der Geschäftsleitung jetzt die Virtualisierung vorschlagen, also 2 (als Redundanz) vernünftige Kisten mit genügend RAM anschaffen und die diversen Server und Anwendungen virtualisieren.

Meine Vorstellung: 2 leistungsfähige HP Server mit je 2 QuadCore CPUs, 36 GB RAM und SAS HD´s anschaffen, evtl. ein gemeinsames SAN und darauf entweder den vSphere oder den Hyper-V installieren.

Was spricht für VMware, bzw. für Hyper-V? Welche Vor- /Nachteile haben die genannten? Wie ist das mit den Lizenzierungskosten? Kann man bei Hyper-V eine VM ebenso mal auf den anderen Server schieben wie bei VM?
Das Ganze sollte hochverfügbar sein, ein Ausfall von mehreren Stunden wäre eine kleine Katastrophe und kam bis jetzt mit oben genannter Hardware noch nicht vor.

Bitte erspart Euch Kommentare, „wenn man keine Ahnung hat, soll man sich professionelle Hilfe holen“ etc. Lest dann einfach im nächsten Thread weiter face-smile

Danke für konstruktive Vorschläge.

Grüße, bobbele

Content-Key: 245863

Url: https://administrator.de/contentid/245863

Ausgedruckt am: 19.03.2024 um 07:03 Uhr

Mitglied: Dani
Dani 07.08.2014 um 16:35:39 Uhr
Goto Top
Hallo,
ich versuche es kurz zu halten...

Meine Vorstellung: 2 leistungsfähige HP Server mit je 2 QuadCore CPUs, 36 GB RAM und SAS HD´s anschaffen,
Hört sich erstmal nicht schlecht an. Aber... wenn du nur Hypervisor auf den Kisten installierst ohne Nutzdaten, empfehle ich dir SSD-Festplatten im RAID1. Gerade Installation von Updates (egal ob Microsoft oder VMWare) gehen zack zack durch. Somit wird das Wartungsfenster kurz gehalten.

evtl. ein gemeinsames SAN und darauf entweder den vSphere oder den Hyper-V installieren.
Der Ansatz ist der Richtige. Achte bitte darauf, dass das SAN zwei Controller verbaut hat. Sonst bringt dir die Redudanz Server kaum bis gar nichts.
Als SAN würde ich dir primär Netapp FAS-Systeme empfehlen. Aber auch EMC ist ein Blick wert. Bei solchen Anschaffungen musst du weit über den Tellerrand schauen, da die beiden Anbieter inzwischen viele Software-Plugins für Datensicherung und Optimierung anbieten. Aus meiner Sicht sind Funktionen wie Datendeduplizierung auf VM-Ebene und Thin Provisioning ein muss. Des Weiteren ist die Frage, wie du in Zukunft die CIFS/SAN-Freigaben regelmäßig und zuverlässig sicherst? Das ist natürlich abhängig von den Datenmengen, der Datensicherungsvariante und das Zeitfenster in dem die Sicherung fertig sein muss.

Bei Herstellern wie DELL, IBM, etc... ist meist Netapp oder EMC darunter.

Genauso wichtig ist das Netzwerk:
Achte bitte drauf, dass du für iSCSI/NFS seperate Netzwerkkarten in den Servern nutzt und auch dedizierte (virtualisierte) Switches, die für beide Protokolle ausgelegt sind (Stichwort Puffer Size). In deinem Fall würde ich behaupten, dass 2x1GBit für die nächsten 4 Jahre locker reichen wird. Somit brauchst du für eine Hochverfügbarkeit an den Servern vier Netzwerkschnittstellen (2x SAN, 2xLAN).

Wie ist das mit den Lizenzierungskosten?
ESXi ist in der Grundversion kostenlos. Funktionen wie HA, FT, DRS ist ab der Standardedition aufwärts enthalten, Link. Lizensiert wird bei VMWare pro CPU. In deinem Fall wäre es vier Lizenzen + Subscrition wenn du Support und Produktupdates kostenlos erhalten möchtest.

Oben drauf kommen noch die Microsoftlizenzenkosten. Das hängt davon ab, welche Funktionen du von VMWare nutzen möchtest. DRS zum Beispiel sorgt dafür, dass beide Hypervisor Hosts ungefähr gleich ausgelastet sind. D.h. das vCenter schiebt vollautomatisch die VMs hin und her. Eine Microsoft Server Standardlizenz muss aber immer an einem Hypervisor-Host gebunden werden. Somit brauchst in deinem Fall weitere Server 2008 Standardlizenzen. Das liegt daran, dass Standardlizenzen nicht per CPU sondern pro VM lizensiert wird. Anders ist es bei Windows Server Datacenter-Lizenzen. Dort wird pro CPU lizensiert. Ist ein schweres Thema...

Hyper-V ist ebenfalls kostenlos. Auch hier ist es so, dass erst mit System Center entsprechend Funktionen hinzukommen. Im Vergleich zu VMWare sind für deinen Fall die Unterschiede kaum bemerkbar. Wenn du es richtig nutzen möchtest, brauchst du auch hier weitere Lizenzen. Wenn du zwei Server 2012R2 Standard kaufst, werden pro Server die beiden CPUs lizenzrechtlich abgedeckt und du darfst noch zwei VMs installieren. Vorausgesetzt du installierst ausschließlich die Rolle Hyper-V!

Kann man bei Hyper-V eine VM ebenso mal auf den anderen Server schieben wie bei VM?
Geht natürlich... ist eher eine lizenzrechtliche Frage. face-smile

Um einen Vergleich anstreben zu können, schau dir erst einmal beide Produkte an, wie was funktioniert. Oft ist es so, dass man schnell damit klar kommt.
Falls du Spezialanwendungen hast, kann es gut sein das der Hersteller z.B. nur VMWare supportet (kein Scherz). Dann ist die Überlegung, muss dich evtl. Dongel o.ä. an eine VM durchschleifen. Auch das ist nicht selbstverständlich. usw...

Ich könnte den ganzen Nachmittag weiterschreiben... ich denke das reicht dir für's Erste. face-smile


Gruß,
Dani
Mitglied: bobbele66
bobbele66 07.08.2014 um 17:42:50 Uhr
Goto Top
Hallo Dani,
erstmal riesigen Dank für die superschnelle und ausführliche Antwort. Ich habe mich mittlerweile etwas in den Hyper-V eingelesen und muss sagen, hört sich auch nicht schlecht an. Ich habe mir einen gebrauchten HP ProLiant DL380 mit 16 GB RAM und 6 x 146 GB SAS HDDs zum Üben und Erfahrungen sammeln gekauft. Hab da drauf schon mal die Testversion von vSphere 5.5 installiert, denke jetzt aber ernsthaft drüber nach, den Hyper-V zu installieren und mit dem zu Üben, statt mit VM.
Die Virtualisierung oben genannter Hardware wird erst im Januar realisiert, für dieses Jahr ist das IT-Budget bereits erschöpft.
Gruß, bobbele
Mitglied: chiefteddy
chiefteddy 07.08.2014 um 17:44:45 Uhr
Goto Top
Hallo,

ich setzt seit 3 Jahren VMware (vSphere) ein. Kam auch von der Destop-Variante mit VMware-Server. Planung und Projektmanagement kamen von mir. Realisierung und erste Inbetriebnahme durch Fachfirma. Inbetriebnahme war gleichzeitig eine Art Workshop für mich. Einrichtung der VMs und das tägliche Management (Datensicherung, Patchmanagement usw.) mache ich alleine. Bei größeren Änderungen und wenn es mal ein Problem gibt, steht mir die Fachfirma zur Verfügung.

Einen solchen Weg kann ich Dir nur empfehlen (unabhängig von VMware oder Hyper-V).

Bei VMware gib es eine "Small Business Lösung" für max. 3 VMware-Server. Damit halten sich die Lizenzkosten im Rahmen.

Für das SAN muß es keine Fibre Channel-Variante sein, Es geht auch preiswerter in einer kleinen Umgebung, Mein Storage ist mit redundantem 6GB SAS an jeden der 3 Server angebunden.

Jeder Server ist mit 4 GB-Ethernet-Links an den zentralen L3-Switch angebunden. Theoretisch könnte ich hier noch auf 10GB aufrüsten, dann entfällt aber leider die Redundanz.

Für das Management und das Backup gibt es ein separates Netzwerk

Ich bin zufrieden und möchte die Virtualisierung nicht mehr missen.

Jürgen

PS: In reinen MS-Umgebungen mit AD und Management-Server ist Hyper-V sicher eine gute Lösung. In heterogenen Umgebungen (wir haben Novell eDirectory auf SLES im Einsatz, neben einigen MS-Servern) ist VNware nicht zu schlagen.
Mitglied: Pjordorf
Pjordorf 07.08.2014 um 19:32:17 Uhr
Goto Top
Hallo,

Zitat von @bobbele66:
1 phys. Server 8 GB RAM mit SBS 2008 Premium (= AD, SQL, Fileserver, Acronis Backup Software für Server und f. SQL)
Warum hat der nur 8 GB RAM. Erst mit 32 GB RAM wird der SBS vernünftige Antwortzeiten liefern. Und warum liegt dort noch der SQL Server für dein Haupt Applikation und wurde nicht schon längst auf einen eigenen Server gelegt?

1 phys. Server 16 GB RAM mit Server 2008 als Terminalserver für externe Filiale (Zyxel site to site VPN mit SDSL 6 MBit)
Alle haben ein Upload von 6 MBit/s möglich, gerade die TS Benutzer?

1 phys. Server 16 GB RAM mit Server 2008 Std. für Avaya Telefonanlage
16 GB RAM für eine Telefonanlage? face-smile

gewachsen, angefangen vor 6 Jahren mit dem SBS
Deshalb hättest du die SQL Datenbank trotzdem vom SBS umziehen können nachdem ihr größer geworden seid. z.B. auf den "Telefonanlagen Server". Welche Platten hat dein SBS den heute drin?

mit genügend RAM
Meine Vorstellung: 2 leistungsfähige HP Server mit je 2 QuadCore CPUs, 36 GB RAM
Hast du nicht vorhin etwas von genügend RAM erzählt? Der SBS alleine will schon 32 GB haben (Ohne SQL)

evtl. ein gemeinsames SAN
Nicht doch 2 (wegen Redundanz welche ja von dir gefordert) Oder wie soll dieser SPOF (Single Point of Failure) in dein Redundantes Konzept aufgehen?

und darauf entweder den vSphere oder den Hyper-V installieren.
MS könnte preiswerte sein. Nein, nicht die Rolle Hyper-V oder Hyper-V Core, die sind Kostenlos.

Kann man bei Hyper-V eine VM ebenso mal auf den anderen Server schieben wie bei VM?
Technisch Ja, klar geht das. Aber ob da deine Lizenzierung mitspielt. Redundanz oder HA hat auch Auswirkung auf die Lizenzen.

Das Ganze sollte hochverfügbar sein, ein Ausfall von mehreren Stunden wäre eine kleine Katastrophe
Dann kannst du auch sicherlich das Budget schon überblicken. An welche Kosten hast du denn gedacht?

Bitte erspart Euch Kommentare, „wenn man keine Ahnung hat, soll man sich professionelle Hilfe holen“ etc. Lest dann einfach im nächsten Thread weiter face-smile
Ich habe mir deine anderen Thread mal zuerst durchgelesen face-smile

Und es macht keinen Sinn ein Airbus 797 zu planen solange nicht absehbar ist das du die Kosten tragen kannst oder willens bist. Dein Projekt hier wird eine gute 5 Stellige Zahl werden. Wenn du also mit einen Budget von 5.000 EUR planst dann .....

Gruß,
Peter
Mitglied: bobbele66
bobbele66 07.08.2014 um 19:55:51 Uhr
Goto Top
Hallo,
auch dir vielen Dank für die Antworten. Der SBS hat deshalb nur 8 GB, weil das Mainboard nicht mehr erlaubt. Das war, wie oben beschrieben, vor Jahren für 3 Clients an einem Standort gedacht. Das andere kam kleckerlweise hinzu und sollte immer schnell mal über Nacht realisiert werden. Das jetzt ausführlich zu erklären warum und wieso wäre zu aufwendig.
Jedenfalls ist der Geschäftsleitung jetzt bewusst, dass es Zeit ist, was vernünftiges aufzubauen und sich von dem viel zu schwachen Servern zu verabschieden. Die Hardware wird komplett neu samt Switche, Festplatten usw. Ich sollte das virtualisiert aufbauen und wenn alles läuft, an einem Wochenende in Betrieb nehmen.
Die Kosten spielen eher eine untergeordnete Rolle, es wurde zwar nicht direkt über ein Budget besprochen, dass es aber an die 20 k gehen wird, ist der GL bekannt.
Grüße,
bobbele
Mitglied: Dani
Dani 07.08.2014 aktualisiert um 23:36:29 Uhr
Goto Top
Guten Abend,
was ich vergessen habe: Auf jeden Fall einen DC auf Blech installieren. Bei Hyper-V sowieso Pflicht und bei VMWare inzwischen auch.
Hier kannst du nachlesen, warum.

Hab da drauf schon mal die Testversion von vSphere 5.5 installiert, denke jetzt aber ernsthaft drüber nach, den Hyper-V zu installieren und mit dem zu Üben, statt mit VM.
Nimm dir genügend Zeit für beide HV's. Du bist später dafür verantwortlich und wenn es hinten und vorne nicht passt, geht's um deinen Kopf.

Das Ganze sollte hochverfügbar sein, ein Ausfall von mehreren Stunden wäre eine kleine Katastrophe und kam bis jetzt mit oben genannter Hardware noch nicht vor.
Hab aktuell ein ähnliches Konstrukt zur Überarbeitung am Hals. Die IT einer Tochter von uns hat in 10 Wochen eine Hyper-V Umgebung geplant, installiert und in Betrieb genommen. Letzte Woche Stromausfall gehabt, trotz USV flog ein ein iSCSI/NFS - Switch weg. Redundanz zwischen Hypervisor und SAN hat nicht gepasst. Der Schaden ist im 6stelligen Bereich. Da wird die Luft ziemlich dünn...

Die Kosten spielen eher eine untergeordnete Rolle, es wurde zwar nicht direkt über ein Budget besprochen, dass es aber an die 20 k gehen wird, ist der GL bekannt.
Ich würde minimum mit 30.000,00€ Netto rechnen.

@chiefteddy
Bei VMware gib es eine "Small Business Lösung" für max. 3 VMware-Server. Damit halten sich die Lizenzkosten im Rahmen.
Hängt davon ab, welche Funktionen er nutzen möchte.

Ich bin zufrieden und möchte die Virtualisierung nicht mehr missen.
Die Komplexität sind keine Grenzen gesetzt. Das bricht vielen Admins das Genick. Es hört sich alles damit einfach an aber man muss damit umgehen und wissen was man tut. Sonst versenkt man im Worst Case nicht nur einen Server sondern die ganze Plattform.


Gruß,
Dani
Mitglied: bobbele66
bobbele66 08.08.2014 um 00:19:51 Uhr
Goto Top
Hallo Dani,
du bist ja immer noch unterwegs, ich sehe schon, ich werde die nächsten Wochen mit Lesen, Üben, Lesen... verbringen. Dass man den DC nicht virtualisieren soll, habe ich noch nicht gewusst. Aber dafür könnte man ja einen der vorhandenen Server nehmen, der muss ja keine Leistung bringen. Wenn ich selbst ein wenig mehr Erfahrung gesammelt habe, werde ich mich vermutlich an ein Systemhaus wenden, die sollen mir ein Angebot machen und dann schaun wir mal, was die GL dazu sagt.
Gute Nacht für heute face-smile
bobbele
Mitglied: Pjordorf
Pjordorf 08.08.2014 um 01:00:06 Uhr
Goto Top
Hallo,

Zitat von @bobbele66:
Dass man den DC nicht virtualisieren soll, habe ich noch nicht gewusst.
Das hast du falsch verstanden. Einen DC kannst du schon als eine VM betreiben, es sollte nur nicht der einzige DC dann sein. Du solltest dann noch einen weiteren DC las Blech haben. Startet deine Hypervisor Typ I hast du nämlich weder DC, DNS usw. Ist ein DC noch auf ein Blech. ist dieser jedenfalls erreichbar. Und ja, ein reiner DC mit DNS auf ein Blech kann schon ein Atom mit 1 GB RAM sein.

Gruß,
Peter
Mitglied: chiefteddy
chiefteddy 08.08.2014 um 08:46:22 Uhr
Goto Top
Zitat von @bobbele66:


Jedenfalls ist der Geschäftsleitung jetzt bewusst, dass es Zeit ist, was vernünftiges aufzubauen und sich von dem viel
zu schwachen Servern zu verabschieden. Die Hardware wird komplett neu samt Switche, Festplatten usw. Ich sollte das virtualisiert
aufbauen und wenn alles läuft, an einem Wochenende in Betrieb nehmen.


Das WE wird wohl nicht reichen! Neben dem physischen Aufbau des Systems mußt Du ja auch noch die VMs einrichten. Egal ob Du die Server neu aufsetzt oder die vorhandenen migrierst. Das kostet Zeit.

Ich hatte bei meinem Projekt den Vorteil, dass auch der Serverraum ein neuer wurde. So konnte ich, nachdem der neue Backbone-L3-Switch und das VMware-System lief, "in Ruhe" einen Server nach dem anderen umziehen.

Jürgen
Mitglied: chiefteddy
chiefteddy 08.08.2014 um 09:41:42 Uhr
Goto Top
Hallo,

hole Dir nicht nur ein Angebot ein, sondern ein Paar mehr! Auch von unterschiedlichen Systempartnern. Jedes Systemhaus hat seinen Partner, die einen liefern IBM-Technik, die anderen von HP usw. Auch Dell hat eine eigene Projektabteilung, die solche Anfragen bearbeitet und nicht nur das "Blech" liefert.

(Bitte keine Diskussion über Dell, ich arbeite mit denen schon über 10 Jahre zusammen un bin voll zufrieden, sowohl mit der Qualität als auch dem Sevice.)

Zitat von Pjordorf

MS könnte preiswerte sein. Nein, nicht die Rolle Hyper-V oder Hyper-V Core, die sind Kostenlos.


Der ESXi-Server ist ebenfalls kostenlos, Nur für das Management (vSpehre) und die damit realisierbaren Funktionen (zB HA) mußt du zahlen. Bei MS brauchst du zwingend AD und dann den Management-Server. Ob das in der Summe dann wirklich preiswerter ist, wage ich zu bezweifeln.

Zitat von Dani

Auf jeden Fall einen DC auf Blech installieren. Bei Hyper-V sowieso Pflicht und bei VMWare inzwischen auch.


Wieso braucht vSphere eine AD-Umgebung? Ich betreibe mein vSphere 5.5 ohne AD.

Zu den Kosten:

vSphere 5 Essential Plus incl. 3 Jahre Mainenance - etwas über 6T€

2 Server (2x Xeon E5645 - 6C; 64GB RAM) incl. 2 USV - 8,6TT€

Storage (4,8TB SAS 10.000 und 8TB SAS 7.200; 8 Bays noch frei) - 8,6T€

Das macht zusammen incl. der Arbeitsleistung des Technikers etwas unter 30T€.

Dazu kommt noch der L3-Switch (ca. 5,5T€ für 96 Ports).


Jürgen
Mitglied: Dani
Dani 08.08.2014, aktualisiert am 12.08.2014 um 10:21:23 Uhr
Goto Top
Moin Jürgen,
Wieso braucht vSphere eine AD-Umgebung? Ich betreibe mein vSphere 5.5 ohne AD.
Ich meine damit nicht den Betrieb der Hypervisors sondern den Betrieb des DCs auf Blech. Es gibt/gab einen Bug in VMWare 5.1 der dafür sorgte, dass ein Sysprep bei jedem Einschalten einer VM durchgeführt wird. So, wenn du nur einen DC hast, schaltest diesen aus und wieder ein, hast den Bugfix nicht drauf, ist die VM samt AD defekt.

Der ESXi-Server ist ebenfalls kostenlos, Nur für das Management (vSpehre) und die damit realisierbaren Funktionen (zB HA) mußt du zahlen. Bei MS brauchst du zwingend AD und dann den Management-Server. Ob das in der Summe dann wirklich preiswerter ist, wage ich zu bezweifeln.
Das ist auf den Blick nicht eindeutig. DAs hängt von vielen Faktoren (Anzahl VMs, welche Funktionen benötigt er von VMWare/Microsoft, schließt er einen Subscription Support ab, welche Microsoft Lizenzen werden genutzt, etc.... Da kann auch schnell Hyper-V vorne liegen.

Jedes Systemhaus hat seinen Partner, die einen liefern IBM-Technik, die anderen von HP usw. Auch Dell hat eine eigene Projektabteilung, die solche Anfragen bearbeitet und nicht nur das "Blech" liefert.
Projektabteilung sind recht und gut aber auf Schwächen in ihren Produkten weisen die nicht hin. Du als Kunde musst wissen, was du für Anfoderunge an Hardware und Technik hast. Ich lass mir ungern einen Bären aufbinden... face-wink

Nachtrag:
Anbei ein Blogeintrag (Die NO-GOs und Empfehlungen zu virtuellen DCs) von Yusufs zum Thema virtuelle DCs. Inzwischen Microsoft PFE, früher MVP.
Die Virtualisierung hat längst Einzug in vielen Unternehmen genommen. Sei es Dateiserver, Druckserver oder Applikationsserver, Dank der Virtualisierung lassen sich alle Serverrollen virtualisieren. Nicht nur das dadurch in Bezug auf Green IT Rechnung getragen wird, durch die Virtualisierung lassen sich auch die Hardwarekosten deutlich senken.

Welche Dienste unter welchem Hypervisor supportet werden, kann man hier in Erfahrung bringen:

Windows Server Catalog

Grundsätzlich lassen sich auch die Infrastrukturserver wie Domänencontroller (DC), Exchange Server und SQL Server virtualisieren. Doch gerade bei diesen Serverrollen und insbesondere bei virtuellen DCs (vDCs), gibt es einiges mehr im Betrieb zu beachten als bei physikalischen Servern. Sonst kann es unter Umständen und je nach Größe der Umgebung im Extremfall, in einem Desaster enden! Bei vDCs muss man die Stolperfallen kennen, alleine schon aus dem Grund, da bei physikalischen Servern viele Möglichkeiten erst gar nicht zur Verfügung stehen. Dabei spielt es keine Rolle, welcher Hypervisor (Hyper-V, ESX…) sich im Einsatz befindet.

Die Virtualisierung von DCs hat aber auch, neben Green IT und der Hardwareersparnis, weitere Vorteile. Sichert man einen vDC auf einer anderen Hardware zurück, kann man sich die Hardware-Abstraktion zunutze machen, da man weniger Treiberprobleme hat, als wenn man einen physikalischen DC auf einer anderen Hardware rücksichert. Auch bei der Rollentrennung hilft die Virtualisierung.

 


Die GOs und NO-GOs bei virtuellen DCs
* Die Zeit: Die Zeitsynchronisation innerhalb einer AD Umgebung ist von großer Bedeutung! Denn Microsoft setzt in einer AD Umgebung seit Windows 2000 das Authentifizierungsprotokoll Kerberos in der Version 5 ein und dieses toleriert standardmäßig eine Zeitdifferenz von gerade einmal fünf Minuten. Weicht die Zeit mehr als fünf Minuten ab, verliert das Kerberos Ticket Granting Ticket (kurz TGT) seine Gültigkeit.

* Der für die Zeit verantwortliche DC einer Gesamtstruktur ist der DC, der die FSMO-Rolle des PDC-Emulators in der Root-Domäne innehat! Man sollte den PDC-Emulator der Root-Domäne gegen eine externe Quelle (entweder aus dem Internet oder Hardware-Uhr) abgleichen lassen. Auf der Firewall muss dazu der Port 123 offen sein, wenn mit einer Quelle aus dem Internet abgeglichen werden soll. Der PDC-Emulator muss aber nicht seine Zeit mit einer externen Quelle abgleichen. Die tatsächliche Zeit ist nicht zwingend notwendig. Sie muss nur innerhalb einer Gesamtstruktur synchron sein!

* Alle DCs holen sich ihre Zeit dann vom PDC-Emulator. Die Clients sowie Mitgliedsserver synchronisieren sich ihre Zeit mit ihrem Anmeldeserver, also von dem DC, bei dem sich der Client bzw. Mitgliedsserver authentisiert. Dieser muss nicht zwingend der PDC-Emulator sein.

* Die PDC-Emulatoren der Subdomänen holen sich wiederum ihre Zeit, vom PDC-Emulator der Root-Domäne. Der PDC-Emulator der Root-Domäne ist die maßgebliche Zeitquelle für die Gesamtstruktur.

* Die Zeitsynchronisation mit einer Quelle aus dem Internet, wird auf dem PDC-Emulator der Root-Domäne mit dem folgenden Befehl eingerichtet:

* w32tm /config /update /manualpeerlist:de.pool.ntp.org /syncfromflags:MANUAL /reliable:YES

* Wenn an W32time nichts verstellt wurde (per GPO), hat man anschließend eine funktionierende Zeitsynchronisation!
*
Es sollte darauf geachtet werden, dass virtuelle Maschinen und gerade vDCs ihre Zeit nicht vom Hostsystem (was zum Beispiel unter Hyper-V in den Integrationsdiensten der VM standardmäßig der Fall ist), sondern von der Domäne übernehmen. Oder wenn es gewünscht ist das die vDCs ihre Zeit vom Hostsystem übernehmen, so sollte darauf geachtet werden das auf dem Hostsystem derselbe Zeitserver konfiguriert ist, der auch auf dem PDC-Emulator konfiguriert wurde.


* Kein AD in der Hyper-V Parent Partition: Das Ausführen von DCPROMO auf einem Hyper-V Host ist ein NO-GO, erst recht nicht wenn bereits VMs auf dem Host in Betrieb sind! Auch wenn es technisch möglich ist in der Parent Partition zusätzliche Dienste auszuführen, ist es mitnichten empfohlen dies zu tun. Da unter Hyper-V sich die Treiber für die Hardware in der Parent Partition befinden und der gesamte I/O für den Speicher- sowie Netzwerkzugriff von und zu den VMs durch die Parent Partition verläuft, sollte man den Hyper-V Host nicht unnötig noch mit weiteren Diensten an seine Leistungsgrenzen bringen. Deshalb sollte der Hyper-V Host ausschließlich zur Verwaltung der VMs dienen und keineswegs zum DC gestuft werden!

* Befinden sich alle in der Domäne verfügbaren vDCs auf demselben Host, wäre da noch bei einem Neustart des Hosts das Henne-Ei Problem. Ist der Host ein vDC und würden alle in der Domäne verfügbaren vDCs auf demselben Host betrieben werden, würde der Neustart des Hosts länger dauern. Denn nach einem Neustart des Hosts muss zuerst das AD-integrierte DNS auf den vDCs zur Verfügung stehen. Da bei einem Neustart aber kein DC der die DNS-Zone zur Verfügung stellt bereitsteht, kommt es zu erheblichen Verzögerungen während eines Neustarts.

* Wenn es sich um einen Hyper-V Cluster handelt und alle in der Domäne verfügbaren vDCs befinden sich auf dem Cluster, so hat man bei einem Neustart größere Probleme, da der Cluster ohne einen DC nicht startet!

* Die Ausfallsicherheit: Die Ausfallsicherheit beim AD ist bereits dann gewährleistet, wenn mindestens zwei DCs innerhalb einer Domäne existieren. Natürlich sollten in einer virtualisierten Umgebung nicht alle in der Domäne verfügbaren vDCs auf demselben Host betrieben werden, sonst hat man einen Single Point of Failure (SPoF). Die Erklärung dürfte selbsterklärend sein, denn wenn der einzig verfügbare Host beispielsweise wegen einem Hardwaredefekt ausfallen sollte, würde kein vDC mehr zur Verfügung stehen und die Domäne wäre erst mal verloren. Daher ist es ratsam vDCs mindestens auf mehrere Hosts zu verteilen, wenn nicht noch zusätzlich ein physikalischer DC existiert (was zu empfehlen ist!).

    Wie immer gilt, in jeder Domäne sollten sich mindestens zwei DCs befinden!
    Wie viele DCs pro Domäne werden benötigt?


* Mindestens ein physikalischer DC: Es ist empfehlenswert mindestens einen physikalischen DC in der Domäne zu betreiben. Denn wenn alle DCs einer Domäne virtuell wären, ist man gegen einen Ausfall des Hypervisors (beispielsweise durch ein Windows Update) nicht geschützt. Fällt der Hypervisor aus und existieren ausschließlich vDCs, wäre die Domäne verloren. Des Weiteren ist es empfehlenswert, dass der physikalische DC die Rolle des PDC-Emulators wegen der Zeitsynchronisation innehat. Empfehlenswert ist es auch, neben dem PDC-Emulator noch die beiden gesamtstrukturweiten FSMO-Rollen Schemamaster sowie Domänennamenmaster auf den physikalischen DC zu verschieben.
    Die FSMO-Rollen verschieben


    Kein Snapshot von vDCs erstellen: Allgemein ist das Erstellen eines Snapshots eine nützliche Funktion. Ein Snapshot ist eine Momentaufnahme einer VM. Vor einer Konfigurationsänderung einer VM, kann man einen Snapshot erstellen und nach einer fehlgeschlagenen Konfigurationsänderung, zum vorherigen Zustand Dank des Snapshots zurückkehren. Diese Funktion sollte aber mit Bedacht und nur auf supporteten VMs eingesetzt werden!

    Da es sich beim AD um ein verteiltes Datenbanksystem handelt, darf das Snapshotfeature zum Sichern und Wiederherstellen eines vDCs keineswegs verwendet werden (nicht zu verwechseln mit dem NTDSUTIL-Snapshot)! Erst recht nicht in einer AD Umgebung mit mehr als einem DC! Ein Snapshot ist auf einem vDC, egal welcher Hypervisor eingesetzt wird, stets zu 100% nicht supportet(!) und ist ein striktes NO-GO! Denn damit verursacht man in einer AD Umgebung mit mehr als einem DC ein USN Rollback und gefährdet somit die Datenkonsistenz. Sichert man einen Snapshot zurück, wird das Betriebssystem und die AD Datenbank in einen früheren Zustand versetzt und genau durch diese Vorgehensweise, erzeugt man ein USN Rollback. Wurde ein vDC mit einem Shapshot zu einem vorherigen Stand rückgesichert, stellen ab sofort die Replikationspartner die AD-Replikation zu und von diesem vDC ein. Des Weiteren richtet das Rücksichern eines Snapshots auf einem vDC unter Umständen (RID-Master) einen erheblichen Schaden an.

    Auch wenn man vorher alle DCs einer Domäne herunterfährt und danach von einem vDC ein Snapshot erstellt, bleibt die Problematik dieselbe. Sobald man einen Snapshot auf einem vDC in einer AD Umgebung mit mehr als einem DC zurücksichert, entsteht ein USN Rollback. Dabei ist es irrelevant, ob die vDCs online oder offline sind. Wenn ein Snapshot auf einem vDC zurückgesichert wird, ist mindestens der rückgesicherte vDC zerstört.
    Snapshots dienen auch keineswegs als Datensicherung! Auf virtuellen DCs sollte so wie auf physikalischen DCs, regelmäßig auf mindestens zwei vDCs eine System State Sicherung durchgeführt werden.


    Kein Klon erstellen: Das Klonen eines vDCs, im Form von Duplizieren der virtuellen Festplatte (z.B. VHD), ist weder supportet und genauso wie ein SnapShot, ein striktes NO-GO! Denn wenn ein Klon in derselben Gesamtstruktur wie das Original online geht, sind die Folgen Katastrophal! Lediglich den Computernamen und die IP-Adresse zu ändern, bringt überhaupt nichts. Denn entscheidend ist der Directory Service Agent-GUID (kurz DSA-GUID), auch bekannt als objectGUID. Dieser lässt sich nicht ändern und ist in der Gesamtstruktur eindeutig.

    Ferner existieren doppelte RIDs (Relative Identifiers) und doppelte SIDs. Handelt es sich bei dem geklonten vDC auch noch um den FSMO-Rolleninhaber und speziell um den RID-Master bzw. PDC-Emulator, sind die Probleme viel schlimmer! Der Anruf beim Microsoft Produkt Support Service (MSPSS) ist jedenfalls sicher.

    Der RID-Master und sein RID-Pool

    Zu Sicherungszwecken ist ein Klon so wie ein Snapshot, ebenfalls ganz und gar nicht geeignet und ist auch nicht supportet! Denn die Problematik ist dieselbe wie beim Rücksichern eines Snapshots. Wird ein Klon wiederhergestellt, versetzt man den vDC zu einem früheren Zustand. Auch hierbei entsteht ein USN Rollback und in einer Umgebung mit mehr als einem DC, stellen die Replikationspartner umgehend die AD-Replikation ein.

    Es sollte auch vermieden werden, einen Klon in einer angeblich abgeschotteten Testumgebung zu starten, um verschiedene Tests durchzuführen. Denn das Risiko ist zu groß, das irgendwann einmal die Testumgebung aus welchen Gründen auch immer, doch Verbindung zur Produktivumgebung erhält.
    Möchte man sich eine Template-VM erstellen, sollte unbedingt nach der Betriebssysteminstallation SYSPREP (und nicht NEWSID!) ausgeführt werden. Denn erst wenn Sysprep (unter Windows Server 2008 R2 im Verzeichnis %windir%\System32\sysprep) ausgeführt wurde, wird die VM anonymisiert. Erst danach darf das Template geklont werden.


    Keine Image-basierte Sicherung durchführen: Eine Image-basierte Sicherung kann beispielsweise sein, wenn ein vDC automatisiert heruntergefahren, danach kopiert und anschließend automatisiert hochgefahren wird. Oder wenn mit einem Drittanbieter Werkzeug ein Image eines vDCs erstellt wird. Die Wiederherstellung durch solch eine Sicherungsart ist ebenfalls nicht supportet und ist zugleich ein striktes NO-GO! Denn bei einer Wiederherstellung würde man so wie bei einem Snapshot oder Klon, dass Betriebssystem und die AD Datenbank in einen früheren Zustand versetzen. Die USN Rollback Problematik und vor allem der Schaden, mindestens an dem zurück geimageten vDC, ist sicher!

    Deshalb gilt hier das gleiche wie bei einem Snapshot und bei einem Klon: Finger weg von dieser nicht supporteten Sicherungsart!
    Images als Sicherung?


    Die vDC-Sicherung: Wie bei physikalischen DCs, sollte auf mindestens zwei vDCs das System State regelmäßig gesichert werden.

    Es gibt aber noch zwei weitere Methoden, die zum Sichern und Wiederherstellen eines vDCs unterstützt werden:

    1. Das Ausführen der Windows Server-Sicherung im Gastbetriebssystem ist supportet.
    2. Das Ausführen der Windows Server-Sicherung auf dem Hyper-V Host ist supportet. Denn dadurch wird der VSS Writer (Volume Shadow Copy Service, Volumeschattenkopie-Dienst) des Gastbetriebssystems aufgerufen, um sicherzustellen, dass die Sicherung ordnungsgemäß durchgeführt wird.

    Durch diese beiden Methoden, genauso wie beim Wiederherstellen einer System State-Sicherung, wird die invocationId der AD-Datenbank im Gast-vDC zurückgesetzt. Das ist zwingend notwendig, damit in einer AD Umgebung mit mehreren DCs die Replikationspartner bei einer Wiederherstellung eines DCs erkennen, dass ein DC ordnungsgemäß (supportet!) wiederhergestellt wurde. Die AD-Replikation wird dann ab dem Zeitpunkt des Sicherungsdatums, mit dem wiederhergestellten vDC neu aufgebaut.

    Das elementare für die erfolgreiche Wiederherstellung eines DCs ist, dass die invocationId der AD-Datenbank zurückgesetzt werden muss! Denn nur so ist sichergestellt, dass der Neuaufbau der AD-Replikation in einer AD Umgebung mit mehreren DCs erfolgreich verläuft. Das ist auch der Grund, warum ein Snapshot, Klon oder Image eines DCs nicht supportet ist, da bei diesen Methoden die invocationId nicht zurückgesetzt wird!
    Zwei wichtige IDs eines DCs: DC GUID und InvocationId


    Virenscanner auf dem Host: Ist auf dem Hostsystem (Hyper-V, KVM…) ein Virenscanner installiert, sollten die Verzeichnisse in denen sich zum einen die Virtuellen Festplatten (VHD…) und zum anderen die Konfigurationsdateien befinden, vom Echtzeitscanner (On-Access) des Virenscanners ausgeschlossen werden. Unter Hyper-V sind das standardmäßig die beiden Verzeichnisse C\Users\Public\Documents\Hyper-V\Virtual Hard Disks und C:\ProgramData\Microsoft\Windows\Hyper-V. Wurden andere Verzeichnisse festgelegt, sollten diese vom Echtzeitscanner ausgeschlossen werden.

    Natürlich sollten auch in den VMs bestimmte Verzeichnisse vom Echtzeitscanner ausgeschlossen werden. Welche das sind, steht hier:
    Antivirenprogramm


    DCs offline konvertieren (P2V): Das online Konvertieren (Physical-to-Virtual, kurz P2V) eines DCs ist nicht supportet! Wenn man einen physikalischen DC konvertieren möchte, muss der DC ausgeschaltet (heruntergefahren, nicht angehalten oder ausgesetzt) und offline konvertiert werden! Denn ausschließlich die offline Konvertierung eines DCs (unter Hyper-V z.B. mit dem System Center Virtual Machine Manager, kurz VMM) ist der einzige Weg, welcher auch von Microsoft supportet wird. Nach der offline Konvertierung darf der physikalische DC nie mehr in der Domäne gestartet werden!
    Aber ein P2V ist bei einem DC ohnehin nicht empfehlenswert. Empfohlen ist es auf dem Host einen zusätzlichen DC zu installieren und den physikalischen DC herunterzustufen.


    Die VM-Sicherheit: Bei dem Thema „Sicherheit“ gelten für einen vDC mindestens die gleichen Sicherheitsregeln, wie für physikalische DCs. Weiterhin muss klar definiert sein, wer beispielsweise unter Hyper-V den Host administrieren darf. Denn wer Zugriff auf die virtuellen Festplatten (und somit auf die vDCs) hat, könnte diese kopieren und hätte prinzipiell Zugriff auf alle Kennwörter! Deshalb muss der Zugriff auf die virtuellen Festplatten von vDCs genauso eingeschränkt sein, wie der Zugriff auf physikalische DCs!


* Einen virtuellen DC niemals anhalten und niemals den Status speichern: Ein virtueller DC sollte niemals angehalten (pausiert) und es sollte niemals der Status gespeichert werden! Denn wenn ein vDC angehalten oder der Status gespeichert wird, friert man de facto die Uhrzeit und das Datum des vDCs ein. Genau das kann aber beim Wiedereinschalten des vDCs zum Problem werden, so dass die Replikationspartner die AD-Replikation mit diesem vDC einstellen und dadurch Lingering Objects (zu Deutsch, herumlungernde Objekte) entstehen. Ein vDC sollte stets heruntergefahren werden.
    Lingering Objects (veraltete Objekte)


* Virtuelle Festplatten mit fixer Größe konfigurieren: Es ist empfehlenswert, eine virtuelle Festplatte mit einer festen Größe zu konfigurieren. Konfiguriert man eine dynamische virtuelle Festplatte, muss man beim sizing des Hosts ohnehin die maximale Größe, die man bei einer dynamischen virtuellen Festplatte angegeben hat kalkulieren.


* Keine differenzierende virtuelle Festplatte konfigurieren: Man sollte es tunlichst vermeiden, eine differenzierende virtuelle Festplatte für einen vDC zu implementieren! Dadurch ist es zu einfach, den vDC in einen früheren Zustand zu versetzen.


* Nicht einen vDC unter Hyper-V exportieren: Das Exportieren eines vDCs unter Hyper-V sollte nicht durchgeführt werden.

Gruß,
Dani
Mitglied: chiefteddy
chiefteddy 08.08.2014 um 11:30:15 Uhr
Goto Top
Hallo Dani,

deshalb sagte ich ja auch, mehere Angebote einholen. Vor-Ort-Besichtigung vereinbaren, Vorschlag ausarbeiten lassen, mit eigenen Vorstellungen vergleichen, Vorschlag diskutieren, Änderunge / Anpassungen einarbeiten und zum Schluß dann das Angebot abfordern. Wenn man das mit 2-3 Anbietern macht, erhält man einen ganz guten Überblick über die Thematik und kann auch seine eigenen Vorstellungen gegebenennfalls korrigieren. Und bei einem Auftragsvolumen von 30-40T€ (bei mir kam noch eine Backup-Lösung hinzu) legen die sich auch richtig in Zeug.

Jürgen