Jump to content

WIN2003 + VMWare


Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Empfohlene Beiträge

Moin Fankurve,

 

ich möchte bei uns nen neuen Server aufsetzen mit WIN 2003 , AD, DNS und Terminalserver.

Auf dem Server läuft dann ein Oracle10 , alle User sollen per Thin-Clients auf dem Server in der Oracle-DB arbeiten.

Jetzt meinte unser Oracle-Spezi, das es besser wäre den Terminalserver vom AD zu trennen (also nicht auf der selben Maschine laufen zu lassen). Da ich mir aber keinen zweiten Server hinstellen will, kam der Gedanke auf das mittels VMWare zu realisieren.

 

Nun meine Fragen:

Ist o.g. Aussage prinzipiell richtig? (AD + TS trennen, wenn ja warum?)

Wo bekomme ich ne kurze Anleitung her wie ich das am besten realisiere (ich habe bisher noch nie mit VMWare zu tun gehabt).

 

Besten Dank für Eure Tipps im Vorraus...

 

oso

Link zu diesem Kommentar

AD und Terminalserver sollte man tunlichst von einander trennen, denn hat einer Deinen TS korrumpiert und dieser ist ein Domain Controller, hat er im schlimmsten Fall vollen Zugriff auf Dein AD ..... das würde mir schon reichen.

 

Eine DB würde ich ebensowenig auf einem Domain Controller laufen lassen, allein wegen der Last, die durch DB und hier geplantem TS auftritt.

 

Lieber eine kleinere Serverhardware für den Domain Controller und eine dickere Serverhardware für DB und TS.

 

Grüsse

 

Gulp

Link zu diesem Kommentar

Buenos dias,

 

Nun meine Fragen:

Ist o.g. Aussage prinzipiell richtig? (AD + TS trennen, wenn ja warum?)

 

ja, die Aussage ist korrekt. Man lässt die Benutzer aus sicherheitsgründen nicht auf einem DC drauf.

 

Wo bekomme ich ne kurze Anleitung her wie ich das am besten realisiere (ich habe bisher noch nie mit VMWare zu tun gehabt).

 

Wie wäre es auf der VMWare Seite...

Es ist nicht schwierig. Einfach mal ausprobieren und die Hilfe lesen, dann klappt das schon.

Es kommt darauf an, auf welcher Maschine du die VM laufen lässt und vorallem, welche Hardware dahinter steckt.

Link zu diesem Kommentar

Es kommt darauf an, auf welcher Maschine du die VM laufen lässt und vorallem, welche Hardware dahinter steckt.

 

Olá,

 

Die Kiste ist ein Dual Xeon (5300) mit RAID1 (System) + RAID5 (Daten) und 4GB RAM.

ich hoffe mal, dass das für das o.g. Szenario (für bis zu 10 User) reicht :-)

 

Also mal anders gefragt:

Der TS und Oracle-DB wird "normal" auf dem Server installiert. Das AD unter VMWare, oder eher anders herum?

 

oso

Link zu diesem Kommentar

Hallo Zusammen

 

Weder noch.

 

Ein Domain controller ist das Herz aller Zugriffe und jeder Sicherheit. Aus Disaster Recovery Gründen sollte in DC niemals produktiv als VM laufen. Stell Dir einfach vor der Vmhost selbst ist Domainmember und muss sich auf dem VMclient (als Domain controller) authentifizieren ... dabei wird mir übel ... auch dass die Resource einen DNS Server benötigt ...

 

TerminalServer und Domaincontroller sind aus security Gründen immer zu trennen.

 

Nun noch etwas Datenbankserver (sei das Oracle oder SQL) auf vmware laufen zwar, sind aber wenns in die Tiefe geht, weder von Microsoft, Oracle noch vmware offiziell empfohlen. Hatten da mal was lustges mit ORacle 10g und einer 8 GB grossen dB. Bootzeit des Vms mit der ORacle DB bei 10-12 Minuten .... und 100% CPU Linie des Hosts. Hatten da Cases s bei Oracle und vmware eröffnet mit dem Resultat Produkt is nit gemacht dafür ... :-(

 

Falls Du ein einigermassen vernünftiges Environment hinstellen willst kommst Du um zwei verschiedene physikalische Geräte nicht herum. (Ein ML110 von HP kostet keine 500 € ...) und würde als Domain controller absolut reichen. ...

 

Gruss,

Matthias

Link zu diesem Kommentar
Aus den von dir genannten Gründen sollte sowieso nie ein DC allein eine Domain verantworten, jedenfalls nicht im produktiven Umfeld... Es spricht aber nichts dagegen, einen der DCs als VM zu betreiben.

Christoph

 

Das ist richtig. Sehe ich aus so. Es tuts auch einen AltenKisten PC. Dann jedoch tunlichst keine FSMO Rollen zuweisen.

 

Gruss

Matthias

Link zu diesem Kommentar
Das ist richtig. Sehe ich aus so. Es tuts auch einen AltenKisten PC. Dann jedoch tunlichst keine FSMO Rollen zuweisen.

 

Natürlich sollte man möglichst auf physikalische Maschinen setzen, aber wie du selbst hier einräumst, tut es z.B. auch eine ältere Hardware. Um die Domäne zu "sichern" reicht das dicke aus. Aber bevor ich nur einen DC in der Domäne habe, setze ich in der VM einen weiteren DC auf!

 

Die Aussage "...tunlichst keine FSMO Rollen zuweisen" stimmt so aber auch nicht.

Es kommt auf die Umgebung an. Wenn in der Domäne etliche Maschinen, ein riesen Forest existiert oder viele Änderungen im AD vorgenommen werden, dann schon. Aber es stellt kein Problem bei einer überschaubaren Größe dar.

Link zu diesem Kommentar

Äh Leute,

 

wir reden hier von 10 Usern. Da will ich doch den PC jünger als 5 Jahre sehen, der das als DC nicht verpackt, selbst wenn er alle FSMOs hat und der einzige GC ist.

 

Mit dem DC als VM hätte ich keine Probleme, aber der SQL ist da nicht so gut aufgehoben. Wenn ein DC in der VM läuft, sollte das Hostsystem aber auf keinen Fall in dieser Domäne sein, das kann unschön enden.

 

Wir haben bei uns für manche Zwecke nen W2k3 mit VMWare in ner eigenen Workgroup. Darauf läuft dann ein DC, ein Fileserver/DHCP, ein WSUS und ein NetInstall Server in jeweils getrennten Maschinen. Tut einwandfrei.

 

In dem hier beschriebenen Szenario würde ich aber eher noch ne Pizzabox kaufen, da reicht ein Single P IV, da muss kein Xeon rein, und darauf würde ich den DC installieren.

Link zu diesem Kommentar

@Daim

Ich bin da anderer Meinung und bleibe meiner treu :) . Wenn Du einen Forest hast der grösser ist und nach ITIL arbeitest, hast Du garantiert das Geld für physikalische DCs da diese als "Hosting Service" o.ä. verkauft werden sonst stimmt was anderes nit :cool:

 

Für Klein Domains schliesse ich mich jedoch gerne Deiner Meinung an.

 

Und wenn ich den Post von Woiza lese, schliesse ich mich auch dem an.

 

Gruss,

Matthias

Link zu diesem Kommentar
Hallo Zusammen

 

Ein Domain controller ist das Herz aller Zugriffe und jeder Sicherheit. Aus Disaster Recovery Gründen sollte in DC niemals produktiv als VM laufen. Stell Dir einfach vor der Vmhost selbst ist Domainmember und muss sich auf dem VMclient (als Domain controller) authentifizieren ... dabei wird mir übel ... auch dass die Resource einen DNS Server benötigt ...

 

ist kein besonderes problem, der server kommt einwandfrei hoch. ein dc sollte aus sicherheitsgründen immer "alleine" laufen und kommt daher erst recht in eine eigene vm.

Link zu diesem Kommentar
@Daim

Ich bin da anderer Meinung und bleibe meiner treu :) .

 

Das kannst du gerne tun (wirst schon sehen was du davon hast ;) ).

 

Wenn Du einen Forest hast der grösser ist und nach ITIL arbeitest, hast Du garantiert das Geld für physikalische DCs da diese als "Hosting Service" o.ä. verkauft werden sonst stimmt was anderes nit :cool:

 

Für Klein Domains schliesse ich mich jedoch gerne Deiner Meinung an.

 

Was ziehen wir daraus für eine Lehre? Man muss dann bei seinen Aussagen die IST-Situation bzw. die Angaben eines Klein- oder Groß-Betriebs mit einbeziehen/erwähnen.

Link zu diesem Kommentar

gysinma hat Recht. In diesem Szenario wäre der DC in ner VM ungut. Auf dem Server soll ein TS laufen. Dieser wird wohl Mitglied der Domäne. Und die Domäne lebt virtuell auf diesem Server? Da hätte ich Bauchschmerzen.

 

Wenn die VM spinnt, kann ich mich je nach Policy mit meinem Domain Account nicht mehr am Server anmelden, weil er keinen DC findet. Und den DC krieg ich nicht ans laufen, weil ich mich nicht anmelden kann.

 

Klar gäbe es da auch noch lokale Accounts, aber mir würde es nicht gefallen.

Link zu diesem Kommentar
Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Schreibe einen Kommentar

Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.

Gast
Auf dieses Thema antworten...

×   Du hast formatierten Text eingefügt.   Formatierung jetzt entfernen

  Only 75 emoji are allowed.

×   Dein Link wurde automatisch eingebettet.   Einbetten rückgängig machen und als Link darstellen

×   Dein vorheriger Inhalt wurde wiederhergestellt.   Editor-Fenster leeren

×   Du kannst Bilder nicht direkt einfügen. Lade Bilder hoch oder lade sie von einer URL.

×
×
  • Neu erstellen...