91863
12.10.2011, aktualisiert um 18:19:30 Uhr
13437
56
0
Was sindRisiken und Nachteile bei einer Virtualsieriung mit ESX
Hallo Zusammen,
ich möchte mir Gedanken ueber ESX machen. Bisher sehe ich vielen Vorteile. Die NAchteile tauchen dann in der Praxis wohl auf, wenn man sich keine Gedanken über Risiken und Nachteile macht.
Was sind denn die grössten Nachteile und Risiken beim ESX ?
Danke und Gruss
Ralf
ich möchte mir Gedanken ueber ESX machen. Bisher sehe ich vielen Vorteile. Die NAchteile tauchen dann in der Praxis wohl auf, wenn man sich keine Gedanken über Risiken und Nachteile macht.
Was sind denn die grössten Nachteile und Risiken beim ESX ?
Danke und Gruss
Ralf
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 174542
Url: https://administrator.de/forum/was-sindrisiken-und-nachteile-bei-einer-virtualsieriung-mit-esx-174542.html
Ausgedruckt am: 16.02.2025 um 23:02 Uhr
56 Kommentare
Neuester Kommentar
Hallo,
wenn du das ganze nicht Clusterst hast du bei einem Hardware Ausfall alle Server offline
Gruß
wenn du das ganze nicht Clusterst hast du bei einem Hardware Ausfall alle Server offline
Gruß
Hallo,
es wären 2 Server geplant. Einmal sollen Server virtualisiert werden, auf der anderen Seite / Server Desktop Vm Ware View 5.
Ist dann nicht bei einem Serverausfall, das er wenn die Last einbricht, das er VMS automatisch auf den anderen server schiebt ?
Gruss
Ralf
es wären 2 Server geplant. Einmal sollen Server virtualisiert werden, auf der anderen Seite / Server Desktop Vm Ware View 5.
Ist dann nicht bei einem Serverausfall, das er wenn die Last einbricht, das er VMS automatisch auf den anderen server schiebt ?
Gruss
Ralf
Moin,
Wenn der "Vsphere/VIM" dann auch noch das Backup der VMs übernimmt - alles cool und locker.
Und was "noch" ein großer "Nachteil" sein kann: Man "baut" aufeinmal mal eben mehr Server, als man "sonst" machen würde
Ps: Beim Clustern immer dran denken, dass man die Last nicht auf beide Server verteilt, sondern im prinzip nur die Ressourcen nutzt, die einer allein stemmen kann - denn wenn beide Hosts auf Anschlag vvollgedonnert werden, kann die HA nicht funktionieren.
Gruß
Zitat von @Hitman4021:
Hallo,
wenn du das ganze nicht Clusterst hast du bei einem Hardware Ausfall alle Server offline
Yupp und nicht alles ist virtualisierbar. Ein DC; ein Vsphere Client müssen mindestens zu den (2?) ESXxen zusätzlich physikalisch vorhanden sein.Hallo,
wenn du das ganze nicht Clusterst hast du bei einem Hardware Ausfall alle Server offline
Wenn der "Vsphere/VIM" dann auch noch das Backup der VMs übernimmt - alles cool und locker.
Und was "noch" ein großer "Nachteil" sein kann: Man "baut" aufeinmal mal eben mehr Server, als man "sonst" machen würde
Ps: Beim Clustern immer dran denken, dass man die Last nicht auf beide Server verteilt, sondern im prinzip nur die Ressourcen nutzt, die einer allein stemmen kann - denn wenn beide Hosts auf Anschlag vvollgedonnert werden, kann die HA nicht funktionieren.
Gruß
Hi,
also zunächst: man muß sich auch mit ESX auseinandersetzen. Ist auch recht umfangreich.
Viele Nachteile kann ich an der Virtualisierung auch nicht erkennen; Clustern ist sicherlich nötig; da wie gesagt, wenn ein Server ausfällt sind alle Win-Server weg.
Wir haben uns dazu entschieden, das die Server geclustert werden und auf einer SAN im RAID arbeitet; dies aus Kostengründen. Gewisses Risiko besteht halt immer noch durchs SAN; aber für diesen Notfall habe ich ja eine Bandsicherung. (P.S.: Das war nicht meine Idee, aber die GF wollte nicht mehr Geld dafür ausgeben; naja, der Firmenwagen ist ja auch wichtiger. )
Vieles ist schön, wie du bereits gemerkt hast.
Als Nachteile kann man sicherlich anmerken:
Lizenzen (Lizenzserver) werden oft auf einer MAC-Adresse ausgestellt; dies ist bei einigen nicht möglich dafür eine VMWare-MAC-Adresse zu nehmen. Hatte damit Probleme.
Ist ein COM-Anschluß o.ä. nötig siehts schlecht aus. Habe einen physikalischen kleinen Server aufgesetzt, der die COM-Arbeiten sowie Lizenzserver macht (die nicht VM-tauglich sind).
Sicherung der Systeme nur bedingt einfach.
Ansonsten ne super Sache! Alt-System (ab 2003) ist easy abzulösen, alles gut zu managen, wenn man sich etwas damit beschäftigt hat. Je nach Lizenz kannst du Arbeitsspeicher, Festplattenspeicher hin und herschieben wie du magst.
Habs recht neu, und bin immer noch begeistert. Auch wenn kleinere Probleme auftauchten würde ich es immer wieder machen!
Greetz
ravers
P.S.: DC müssen bei 2 ESX-Servern nicht physikalisch vorhanden sein.
Lastverteilung natürlich beachten!
also zunächst: man muß sich auch mit ESX auseinandersetzen. Ist auch recht umfangreich.
Viele Nachteile kann ich an der Virtualisierung auch nicht erkennen; Clustern ist sicherlich nötig; da wie gesagt, wenn ein Server ausfällt sind alle Win-Server weg.
Wir haben uns dazu entschieden, das die Server geclustert werden und auf einer SAN im RAID arbeitet; dies aus Kostengründen. Gewisses Risiko besteht halt immer noch durchs SAN; aber für diesen Notfall habe ich ja eine Bandsicherung. (P.S.: Das war nicht meine Idee, aber die GF wollte nicht mehr Geld dafür ausgeben; naja, der Firmenwagen ist ja auch wichtiger.
)Vieles ist schön, wie du bereits gemerkt hast.
Als Nachteile kann man sicherlich anmerken:
Lizenzen (Lizenzserver) werden oft auf einer MAC-Adresse ausgestellt; dies ist bei einigen nicht möglich dafür eine VMWare-MAC-Adresse zu nehmen. Hatte damit Probleme.
Ist ein COM-Anschluß o.ä. nötig siehts schlecht aus. Habe einen physikalischen kleinen Server aufgesetzt, der die COM-Arbeiten sowie Lizenzserver macht (die nicht VM-tauglich sind).
Sicherung der Systeme nur bedingt einfach.
Ansonsten ne super Sache! Alt-System (ab 2003) ist easy abzulösen, alles gut zu managen, wenn man sich etwas damit beschäftigt hat. Je nach Lizenz kannst du Arbeitsspeicher, Festplattenspeicher hin und herschieben wie du magst.
Habs recht neu, und bin immer noch begeistert. Auch wenn kleinere Probleme auftauchten würde ich es immer wieder machen!
Greetz
ravers
P.S.: DC müssen bei 2 ESX-Servern nicht physikalisch vorhanden sein.
Lastverteilung natürlich beachten!
Hallo,
danke. Warum muss der DC eigentlich pysisch sein ? Ist das sonst ein "Totaler Ausschluss" aus der Umgebung, wenn mal ESX taucht ?
Gruss
Ralf
danke. Warum muss der DC eigentlich pysisch sein ? Ist das sonst ein "Totaler Ausschluss" aus der Umgebung, wenn mal ESX taucht ?
Gruss
Ralf
Hallo!
Also virtualisieren ist die Zukunft! Hauptsächlich wegen der CO²-Einsparung.
Der größte Nachteil ist natürlich die erhöhte Gefahr, verliere ich einen physischen Server, verliere ich X virtuelle Server. (Wenn du das HA-Feature nicht hast)
Ein Weiter "kleiner" Nachteil ist: "Ein Computer im Computer ist immer langsamer als der Computer selbst" hat mein Mentor mal gesagt
. Stimmt natürlich auch! Aber die Ressourcen, die das ESX verbraucht sind extrem niedrig. Also nur ein geringer Verlust. Des weiteren kommt es auf die Verwendung deiner VMs an. Bei Anwendungen im 3d-Grafik-Bereich gibt es auch einen Nachteil: Du kannst nicht so einfach eine 3D-Grafikkarte an die VM "durchreichen". Das geht mir mit bestimmten "bezahl"-ESX-Versionen und nur unter bestimmten Voraussetzungen (U.a. Bandbreite)
Es gibt noch einen Nachteil, den ich mal böse zu spüren bekommen habe:
Die Spnapshot-Funktion ist ja schön und echt gut!! ABER: Wenn du beim erzeugen der VM den Speicherplatz deiner virtuellen Platte nicht von Anfang an komplett allocierst, und einen Snapshot nach dem anderen machst, kann es "irgendwann" (wahrscheinlich wenn du im Urlaub bist ) passieren, dass die physikalische Platte voll ist und ALLE deiner VMs "stehen". Du kannst dann nur versuchen dir die VM runterzuladen und sie auf einem anderen Server der noch freien speicher hat wieder zum laufen zu bekommen. Aber du hast in jedem fall eine riesen Downtime!!! Das liegt daran, dass der verbrauchte Speicher von Snapshots in der verfügbaren Speicherkapazität deines Datastores nicht angezeigt wird. Bedeutet: Es ist mehr Speicher verbraucht als du sehen kannst.
Wenn du aber in deinem Netzwerk diverse Dienste zur Verfügung stellen willst, die sauber von einender getrennt sein sollen, ist es genau das richtige!
Es gibt außerdem viele Möglichkeiten das kostenlose ESXi noch etwas "aufzubohren" um noch mehr rauszuholen (Stichwort: SSH-Consle Commands)
Also ich administriere derzeit ca. 10 ESXi-Server und bin sehr zufrieden!!
Ich hoffe das ist das was du (nicht) hören wolltest
Also virtualisieren ist die Zukunft! Hauptsächlich wegen der CO²-Einsparung.
Der größte Nachteil ist natürlich die erhöhte Gefahr, verliere ich einen physischen Server, verliere ich X virtuelle Server. (Wenn du das HA-Feature nicht hast)
Ein Weiter "kleiner" Nachteil ist: "Ein Computer im Computer ist immer langsamer als der Computer selbst" hat mein Mentor mal gesagt
. Stimmt natürlich auch! Aber die Ressourcen, die das ESX verbraucht sind extrem niedrig. Also nur ein geringer Verlust. Des weiteren kommt es auf die Verwendung deiner VMs an. Bei Anwendungen im 3d-Grafik-Bereich gibt es auch einen Nachteil: Du kannst nicht so einfach eine 3D-Grafikkarte an die VM "durchreichen". Das geht mir mit bestimmten "bezahl"-ESX-Versionen und nur unter bestimmten Voraussetzungen (U.a. Bandbreite)Es gibt noch einen Nachteil, den ich mal böse zu spüren bekommen habe:
Die Spnapshot-Funktion ist ja schön und echt gut!! ABER: Wenn du beim erzeugen der VM den Speicherplatz deiner virtuellen Platte nicht von Anfang an komplett allocierst, und einen Snapshot nach dem anderen machst, kann es "irgendwann" (wahrscheinlich wenn du im Urlaub bist
) passieren, dass die physikalische Platte voll ist und ALLE deiner VMs "stehen". Du kannst dann nur versuchen dir die VM runterzuladen und sie auf einem anderen Server der noch freien speicher hat wieder zum laufen zu bekommen. Aber du hast in jedem fall eine riesen Downtime!!! Das liegt daran, dass der verbrauchte Speicher von Snapshots in der verfügbaren Speicherkapazität deines Datastores nicht angezeigt wird. Bedeutet: Es ist mehr Speicher verbraucht als du sehen kannst.Wenn du aber in deinem Netzwerk diverse Dienste zur Verfügung stellen willst, die sauber von einender getrennt sein sollen, ist es genau das richtige!
Es gibt außerdem viele Möglichkeiten das kostenlose ESXi noch etwas "aufzubohren" um noch mehr rauszuholen (Stichwort: SSH-Consle Commands)
Also ich administriere derzeit ca. 10 ESXi-Server und bin sehr zufrieden!!
Ich hoffe das ist das was du (nicht) hören wolltest
Ohne HA-Feature holt man sich auch kein ESXi
Aber mit den Snpshots verstehe ich nicht ganz. Richtig ist das man die Snapshots nicht in den LUN`s sehen kann, aber wenn kein Platz mehr für die Snaps sind dann macht er Sie einfach nicht. Ist doch OK, Fehlermeldung bekommt man ja. Dann alte Snapshots löschen und gut ist. Oder bin ich irgendwie "falschh" ??
Mein BackupExcec macht vorher n Snapshot, schlägt dieser Fehl läuft der Job nicht durch. Aber OK, man merkt es ja dann.
Und was die Zukunft ist wird die Zukunft zeigen ... vielleicht wirds ja auch die Cloud! ... oder RaversBest-Practise; muß ich nurnoch entwickeln )
Greetz
ravers
Aber mit den Snpshots verstehe ich nicht ganz. Richtig ist das man die Snapshots nicht in den LUN`s sehen kann, aber wenn kein Platz mehr für die Snaps sind dann macht er Sie einfach nicht. Ist doch OK, Fehlermeldung bekommt man ja. Dann alte Snapshots löschen und gut ist. Oder bin ich irgendwie "falschh" ??
Mein BackupExcec macht vorher n Snapshot, schlägt dieser Fehl läuft der Job nicht durch. Aber OK, man merkt es ja dann.
Und was die Zukunft ist wird die Zukunft zeigen
... vielleicht wirds ja auch die Cloud! ... oder RaversBest-Practise; muß ich nurnoch entwickeln )Greetz
ravers
Hallo Zusammen,
danke für die Infos. Wir wollen des ESX und nicht ESXI , muss voll Funktional laufen. Werde mal die positiven und Negativen Punkte rausschreiben.
Bei 2 ESX benötigt, muss der DC nicht pyssich sein, Warum eigentlich ?
Für mehr Input bin ich dankbar , Werde ein Dokument mal mit den Sachen erstellen und publizieren
Gruss
Ralf
danke für die Infos. Wir wollen des ESX und nicht ESXI , muss voll Funktional laufen. Werde mal die positiven und Negativen Punkte rausschreiben.
Bei 2 ESX benötigt, muss der DC nicht pyssich sein, Warum eigentlich ?
Für mehr Input bin ich dankbar
, Werde ein Dokument mal mit den Sachen erstellen und publizierenGruss
Ralf
Hallo,
der DC MUSS nicht physisch sein SOLLTE es aber.
Wenn du den DC auch virtualisieren willst lasse ihn zumindest ein paar Minuten vor allen anderen starten. Sonst braucht alles andere ewig bis es hochfährt.
Gruß
der DC MUSS nicht physisch sein SOLLTE es aber.
Wenn du den DC auch virtualisieren willst lasse ihn zumindest ein paar Minuten vor allen anderen starten. Sonst braucht alles andere ewig bis es hochfährt.
Gruß
Hallo,
was macht das HA - High Availability Feature alles ? Benötigt das den Cluster ?
Habe eben gelesen, startet automautsich Server etc..
Gruss
Ralf
was macht das HA - High Availability Feature alles ? Benötigt das den Cluster ?
Habe eben gelesen, startet automautsich Server etc..
Gruss
Ralf
Servus,
um mal licht ins dunkle zu bringen
"DC"=="muss" - das sehe ich so, denn DNS; Uhrzeit und die ganze DC Nummer ist das wichtigste im ganzen Netz.
Das sehen andere vielleicht anders, aber ich gehe da auf nummer ganz sicher. Heutzutage reicht ein DualAtom als DC vollkommen aus.
Lange rede - kurzer Sinn
Das ist in meinen Augen das mindeste, was man braucht, um wirklich sicher zu sein.
gruß
edit
esx und esxi - nenn den freien bitte hypervisor - es gibt keinen "neuen" ESX mehr - der Zug ist abgelaufen.
/edit
um mal licht ins dunkle zu bringen
"DC"=="muss" - das sehe ich so, denn DNS; Uhrzeit und die ganze DC Nummer ist das wichtigste im ganzen Netz.
Das sehen andere vielleicht anders, aber ich gehe da auf nummer ganz sicher. Heutzutage reicht ein DualAtom als DC vollkommen aus.
- Snapshots sind keine Backups! und sollte man auch nicht als Backup vergewohltätigen.
- Backupprogramme, die nicht für VM gedacht sind - mag ich nicht, dazu gibt es u.a Veem, dass speziell auf VM gezimmert ist und das Sachen kann, die andere allinclusive Tools nicht können und niemals können werden.
Lange rede - kurzer Sinn
- 1 SAN - am liebsten mit 2 Köpfen und FB Anschluß
- 2 VM Hosts
- 1 Vsphereclient mit Veem
- 1 Iomega NAS (für die Backups)
- 1 iomega NAS (für die Replicas)
- 1 physikalischen DC
- einen "ordentlichen" Switch
Das ist in meinen Augen das mindeste, was man braucht, um wirklich sicher zu sein.
gruß
edit
esx und esxi - nenn den freien bitte hypervisor - es gibt keinen "neuen" ESX mehr - der Zug ist abgelaufen.
/edit
Hallo,
ich kenne ESX jetzt nicht so genau.
Aber im Prinzip ist HA immer ein Cluster. Entweder aktiv-aktiv oder aktiv-passiv
Server 1 ------|
| ------------ Shared Storage
Server 2 ----- |
Beide greifen auf einem gemeinsamen Datenspeicher zu um immer den gleichen Stand zu haben.
Unter Linux gibt es noch DRBD damit kannst du dir die Shared Storage sparen, da beide Server auf Blockebene synchronisiert werden.
Unter Windows kannst du das ganze mit Starwind Target und Double Take realisieren
Wie es bei ESX genau ausschaut kann ich dir leider auch nicht sagen
Gruß
ich kenne ESX jetzt nicht so genau.
Aber im Prinzip ist HA immer ein Cluster. Entweder aktiv-aktiv oder aktiv-passiv
Server 1 ------|
| ------------ Shared Storage
Server 2 ----- |
Beide greifen auf einem gemeinsamen Datenspeicher zu um immer den gleichen Stand zu haben.
Unter Linux gibt es noch DRBD damit kannst du dir die Shared Storage sparen, da beide Server auf Blockebene synchronisiert werden.
Unter Windows kannst du das ganze mit Starwind Target und Double Take realisieren
Wie es bei ESX genau ausschaut kann ich dir leider auch nicht sagen
Gruß
Wenn du das HA Feature hast hast du folgendes:
3 Hosts
2 an einer aus
die beiden sind immer synchron
fällt dann einer aus, startet der dritte und wird synchronisiert.
sozusagen ein RAID1 mit Hotspare
3 Hosts
2 an einer aus
die beiden sind immer synchron
fällt dann einer aus, startet der dritte und wird synchronisiert.
sozusagen ein RAID1 mit Hotspare
Ja das HA Feature wird aufjeden benötigt.
Sehe das auch so. Ist auch coole Sache.
Gruss
Ralf
Sehe das auch so. Ist auch coole Sache.
Gruss
Ralf
Zitat von @battl1984:
Wenn du das HA Feature hast hast du folgendes:
3 Hosts
2 an einer aus
die beiden sind immer synchron
fällt dann einer aus, startet der dritte und wird synchronisiert.
sozusagen ein RAID1 mit Hotspare
Wenn du das HA Feature hast hast du folgendes:
3 Hosts
2 an einer aus
die beiden sind immer synchron
fällt dann einer aus, startet der dritte und wird synchronisiert.
sozusagen ein RAID1 mit Hotspare
So, jetzt muss ich doch mal einschreiten nevor das hier zu wild wird
Moin erstmal!
ESX gibt es nicht mehr! Ab vSphere 5.0 gibt es ausschlieslich ESXi - dessen Features werden nur durch den Lizenzkey an-/abgeschaltet.
HA (High availability) bedeutet, wenn ein ESXi ausfällt dessen VMs automatisch auf einem anderen ESXi wieder hochgefahren werden. Ob man da jetzt 2 oder 3 Hosts hat ist erstmal egal. solange die verbleibenden die Last noch packen.
FT (Fault tolerance) bedeutet, das eine VM immer einen Live-"Schatten" auf einem 2ten ESXi hat. Fällt der "Haupt"-ESXi aus, läuft die VM OHNE UNTERBRECHNUNG(!) auf dem verbleibenden weiter.
DPM (Distributed(?) Power Management) fährt ESXi Hosts je nach benötigter CPU/RAM Resourcen autom. hoch und runter und verschiebt mittels vMotion VMs von/zu diesen Hosts.
/EDIT:
DRS (Dsitributed Resource Scheduler) verteilt VMs mittels vMotion auf den laufenden ESXi Hosts und führt so ein Loadbalancing durch.
/EDIT2:
Und ansonsten, hör auf das was Timo geschrieben hat
lg,
Slainte
Hallo Slainte,
wir benötigen ESX und nicht die Gratisversion ESXi, das heisst "vSphere 5.0" ist das Nachfolgeprodukt von ESX ? Ist das so ?
Dankle und Gruss
Ralf
wir benötigen ESX und nicht die Gratisversion ESXi, das heisst "vSphere 5.0" ist das Nachfolgeprodukt von ESX ? Ist das so ?
Dankle und Gruss
Ralf
"vSphere" wird ist die omplette Suite genannt, also ESXi, vCenter und was sonst noch so alles dazugehört.
ESXi ist der Server auf dem die VMs laufen - die Features werden ausschliesslich durch den Lizenzkey bestimmt, Die Lizenzen gibts von "Null €" bis "Sauteuer"
ESXi ist der Server auf dem die VMs laufen - die Features werden ausschliesslich durch den Lizenzkey bestimmt, Die Lizenzen gibts von "Null €" bis "Sauteuer"
Hallo,
vielen Dank. Dann Vsphre = Suite , ESX nun ESXI , funktioninen abhängig vom Key den man gekauft hat
Gruss
Ralf
vielen Dank. Dann Vsphre = Suite , ESX nun ESXI , funktioninen abhängig vom Key den man gekauft hat
Gruss
Ralf
Hallo,
noch eine Frage.
Die FT (Fault tolerance) bedeutet, das eine VM immer einen Live-"Schatten" auf einem 2ten ESXi hat. Fällt der "Haupt"-ESXi aus, läuft die VM OHNE UNTERBRECHNUNG(!) auf dem verbleibenden weiter.
Das geht ja nur mit Cluster ?
Gruss
Ralf
noch eine Frage.
Die FT (Fault tolerance) bedeutet, das eine VM immer einen Live-"Schatten" auf einem 2ten ESXi hat. Fällt der "Haupt"-ESXi aus, läuft die VM OHNE UNTERBRECHNUNG(!) auf dem verbleibenden weiter.
Das geht ja nur mit Cluster ?
Gruss
Ralf
[...FT...]
Das geht ja nur mit Cluster ?
Ja, mit nur einem ESXi Host macht FT ja auch keinen Sinn, oder? Das geht ja nur mit Cluster ?
ja das stimmt
Gruss
Ralf
Gruss
Ralf
Habe mal hier eine Zusammenfassung:
Vorteile
- Alte Systeme einfach abzulösen
- Vereinfachte Verwaltung
- Auf Dauer grosse Kosteneinsparung des Betriebs
- CO²-Einsparung
- FT (Fault tolerance) bedeutet, das eine VM immer einen Live-"Schatten" auf einem 2ten ESXi hat. Fällt der "Haupt"-ESXi aus, läuft die VM OHNE UNTERBRECHNUNG(!) auf dem verbleibenden weiter.
- HA (High availability)
- DPM (Distributed(?) Power Management) fährt ESXi Hosts je nach benötigter CPU/RAM Resourcen autom. hoch und runter und verschiebt mittels vMotion VMs von/zu diesen Hosts.
- /EDIT:
DRS (Dsitributed Resource Scheduler) verteilt VMs mittels vMotion auf den laufenden ESXi Hosts und führt so ein Loadbalancing durch.
Nachteile
- Lizenzen (Lizenzserver), Spezialsoftware werden oft auf einer MAC-Adresse ausgestellt; dies ist bei einigen nicht möglich dafür eine VMWare-MAC-Adresse zu nehmen
- Ist ein COM-Anschluß o.ä. nötig siehts schlecht aus. (die nicht VM-tauglich sind !).
Sicherung der Systeme nur bedingt einfach.
- DC verschiedene Empfehlungen. DC soll physisch sein. Diskussionen vorhanden ab 2 ESX Servern auch Virtuell möglich. (DC MUSS nicht physisch sein SOLLTE es aber.
Wenn man den DC auch virtualisiert sollte man ihn zumindest ein paar Minuten vor allen anderen starten. Sonst braucht alles andere ewig bis es hochfährt.)
- Und was "noch" ein großer "Nachteil" sein kann: Man "baut" auf einmal mal eben mehr Server, als man "sonst" machen würde
Risiken
- Ohne HA Feature (High Avaibility Feature) sollte keine ESX Umgebung betrieben werden
Cluster !
im Prinzip ist HA immer ein Cluster. Entweder aktiv-aktiv oder aktiv-passiv
Server 1 ------|
| ------------ Shared Storage
Server 2 ----- |
Beide greifen auf einem gemeinsamen Datenspeicher zu um immer den gleichen Stand zu haben.
HA (High availability) bedeutet, wenn ein ESXi ausfällt dessen VMs automatisch auf einem anderen ESXi wieder hochgefahren werden. Ob man da jetzt 2 oder 3 Hosts hat ist erstmal egal. solange die verbleibenden die Last noch packen.
Optimal mit 3 Maschinen:
3 Hosts
2 an einer aus
die beiden sind immer synchron fällt dann einer aus, startet der dritte und wird synchronisiert.
Sozusagen ein RAID1 mit Hotspare
Wenn man das ganze nicht Clustert sind bei einem Hardware Ausfall alle Server offline
Beim Clustern immer dran denken, dass man die Last nicht auf beide Server verteilt, sondern im prinzip nur die Ressourcen nutzt, die einer allein stemmen kann - denn wenn beide Hosts auf Anschlag vollgedonnert werden, kann die HA nicht funktionieren.
- Snapshots sind keine Backups! und sollte man auch nicht als Backup ansehen. (Sind natürlich Daten um zurück gehen zu können)
- Backuprogramme, die nicht für VM gedacht sind – sollen nicht eingesetzt werden, dazu gibt es u.a Veem, dass speziell auf VM gezimmert ist und das Sachen kann, die andere allinclusive Tools nicht können und niemals können werden.
Vorteile
- Alte Systeme einfach abzulösen
- Vereinfachte Verwaltung
- Auf Dauer grosse Kosteneinsparung des Betriebs
- CO²-Einsparung
- FT (Fault tolerance) bedeutet, das eine VM immer einen Live-"Schatten" auf einem 2ten ESXi hat. Fällt der "Haupt"-ESXi aus, läuft die VM OHNE UNTERBRECHNUNG(!) auf dem verbleibenden weiter.
- HA (High availability)
- DPM (Distributed(?) Power Management) fährt ESXi Hosts je nach benötigter CPU/RAM Resourcen autom. hoch und runter und verschiebt mittels vMotion VMs von/zu diesen Hosts.
- /EDIT:
DRS (Dsitributed Resource Scheduler) verteilt VMs mittels vMotion auf den laufenden ESXi Hosts und führt so ein Loadbalancing durch.
Nachteile
- Lizenzen (Lizenzserver), Spezialsoftware werden oft auf einer MAC-Adresse ausgestellt; dies ist bei einigen nicht möglich dafür eine VMWare-MAC-Adresse zu nehmen
- Ist ein COM-Anschluß o.ä. nötig siehts schlecht aus. (die nicht VM-tauglich sind !).
Sicherung der Systeme nur bedingt einfach.
- DC verschiedene Empfehlungen. DC soll physisch sein. Diskussionen vorhanden ab 2 ESX Servern auch Virtuell möglich. (DC MUSS nicht physisch sein SOLLTE es aber.
Wenn man den DC auch virtualisiert sollte man ihn zumindest ein paar Minuten vor allen anderen starten. Sonst braucht alles andere ewig bis es hochfährt.)
- Und was "noch" ein großer "Nachteil" sein kann: Man "baut" auf einmal mal eben mehr Server, als man "sonst" machen würde
Risiken
- Ohne HA Feature (High Avaibility Feature) sollte keine ESX Umgebung betrieben werden
Cluster !
im Prinzip ist HA immer ein Cluster. Entweder aktiv-aktiv oder aktiv-passiv
Server 1 ------|
| ------------ Shared Storage
Server 2 ----- |
Beide greifen auf einem gemeinsamen Datenspeicher zu um immer den gleichen Stand zu haben.
HA (High availability) bedeutet, wenn ein ESXi ausfällt dessen VMs automatisch auf einem anderen ESXi wieder hochgefahren werden. Ob man da jetzt 2 oder 3 Hosts hat ist erstmal egal. solange die verbleibenden die Last noch packen.
Optimal mit 3 Maschinen:
3 Hosts
2 an einer aus
die beiden sind immer synchron fällt dann einer aus, startet der dritte und wird synchronisiert.
Sozusagen ein RAID1 mit Hotspare
Wenn man das ganze nicht Clustert sind bei einem Hardware Ausfall alle Server offline
Beim Clustern immer dran denken, dass man die Last nicht auf beide Server verteilt, sondern im prinzip nur die Ressourcen nutzt, die einer allein stemmen kann - denn wenn beide Hosts auf Anschlag vollgedonnert werden, kann die HA nicht funktionieren.
- Snapshots sind keine Backups! und sollte man auch nicht als Backup ansehen. (Sind natürlich Daten um zurück gehen zu können)
- Backuprogramme, die nicht für VM gedacht sind – sollen nicht eingesetzt werden, dazu gibt es u.a Veem, dass speziell auf VM gezimmert ist und das Sachen kann, die andere allinclusive Tools nicht können und niemals können werden.
Hi,
ich möchte auch mal meinen senf dazu geben:
Ich würde sogar 2 physiche (kleine) DCs als Basis setzten und dann in der VMware gar keine DCs laufen lassen - die ganze VMWare umgebung und auch das SAN ist in die AD integriert und wenn die DCs dann innerhalb dieser Umgebungen liegen, ist das schlecht.
achja und du brauchst einen weiteren physischen server +windows server std. lizenz für dem VMware server.
Pass auf beim SAN du verlierst kapazität für HotSpare und Redundante disks, überlege genau wieviel du brauchst und was dein SAN dir Netto liefert.
Exchange und heftige SQL Datenbanken auf schnelle Platten. normale Daten können auch auf 7200 Platten.
Ich verstehe nicht warum hier so oft von einem Cluster gesprochen wird. dein virtueller server ist nur einmal vorhanden und kann zwischen den esxi hosts jeweils hin und her geschoben werden oder aufrecht gehalten werden. aber es bleibt immer noch eine Windows/unix maschine wenn du diesen kaput machst, bringt dir dein HA oder fault tolleranz auch nichts. bei einem "richtigen" cluster (zumindest sehe ich das so) kannst du ein Betriebssystem patchen und neustarten während die User auf dem anderen Clusterpartner arbeiten und dir dann den anderen vornehmen. also hast du wirklich 2 redundante server. das VMware bietet dir in erster linie Hardware ausfallsicherheit, klar darüber hinnaus mit den Snapshots hast du auch software sicherheit aber halt nicht 2 wirklich vollwertige partner wie in einem "cluster"
Achja thema backup und archivierung: am besten besorgst du dir gleich eine vernüftige lösung wie hier schon beschrieben veeem oder so ... ich habe mich auf die vom SAN mit gelieferten Tools verlassen und bin jetzt verlassen
viele grüße
uLmi
ich möchte auch mal meinen senf dazu geben:
Ich würde sogar 2 physiche (kleine) DCs als Basis setzten und dann in der VMware gar keine DCs laufen lassen - die ganze VMWare umgebung und auch das SAN ist in die AD integriert und wenn die DCs dann innerhalb dieser Umgebungen liegen, ist das schlecht.
achja und du brauchst einen weiteren physischen server +windows server std. lizenz für dem VMware server.
Pass auf beim SAN du verlierst kapazität für HotSpare und Redundante disks, überlege genau wieviel du brauchst und was dein SAN dir Netto liefert.
Exchange und heftige SQL Datenbanken auf schnelle Platten. normale Daten können auch auf 7200 Platten.
Ich verstehe nicht warum hier so oft von einem Cluster gesprochen wird. dein virtueller server ist nur einmal vorhanden und kann zwischen den esxi hosts jeweils hin und her geschoben werden oder aufrecht gehalten werden. aber es bleibt immer noch eine Windows/unix maschine wenn du diesen kaput machst, bringt dir dein HA oder fault tolleranz auch nichts. bei einem "richtigen" cluster (zumindest sehe ich das so) kannst du ein Betriebssystem patchen und neustarten während die User auf dem anderen Clusterpartner arbeiten und dir dann den anderen vornehmen. also hast du wirklich 2 redundante server. das VMware bietet dir in erster linie Hardware ausfallsicherheit, klar darüber hinnaus mit den Snapshots hast du auch software sicherheit aber halt nicht 2 wirklich vollwertige partner wie in einem "cluster"
Achja thema backup und archivierung: am besten besorgst du dir gleich eine vernüftige lösung wie hier schon beschrieben veeem oder so ... ich habe mich auf die vom SAN mit gelieferten Tools verlassen und bin jetzt verlassen
viele grüße
uLmi
Hallo,
ja danke für das Feedback. JA das SAN absicherung ist sicher sehr wichtig. Wir sichern auch auf SAN und das dann per Band.
Denke das bei Vspere dann Drittanbieter wie oben zum Beispiel genannt "Veem" , oder andere. Vielleicht gibts aj auch Lösungen die das Symantec Backeup Exec integriert, das wir sowieso im Einsatz haben.
Eben , beim Cluster bin ich mir nun auch nicht ganz sicher, ob ich das Betriebbsystem sozusagen clustere. Oder ob es einfach ein ESXI Verbund ist, der den HA Ausgleich macht.
Habe aber im moment wohl mehr die Windows Cluster Philospohie im Kopf.
Gruss
Ralf
ja danke für das Feedback. JA das SAN absicherung ist sicher sehr wichtig. Wir sichern auch auf SAN und das dann per Band.
Denke das bei Vspere dann Drittanbieter wie oben zum Beispiel genannt "Veem" , oder andere. Vielleicht gibts aj auch Lösungen die das Symantec Backeup Exec integriert, das wir sowieso im Einsatz haben.
Eben , beim Cluster bin ich mir nun auch nicht ganz sicher, ob ich das Betriebbsystem sozusagen clustere. Oder ob es einfach ein ESXI Verbund ist, der den HA Ausgleich macht.
Habe aber im moment wohl mehr die Windows Cluster Philospohie im Kopf.
Gruss
Ralf
@uLmi:
1. Der vCenter kann innerhalb des von ihm verwalteten Clusters laufen
2. Windows lizenz brauchts seit 5.0 nicht mehr zwingend, da es eine Linux Appliance mit vCenter von VMWare gibt.
achja und du brauchst einen weiteren physischen server +windows server std. lizenz für dem VMware server.
Falsch!1. Der vCenter kann innerhalb des von ihm verwalteten Clusters laufen
2. Windows lizenz brauchts seit 5.0 nicht mehr zwingend, da es eine Linux Appliance mit vCenter von VMWare gibt.
Hallo,
ja das mit Linux ist denke ich besser. ESX installation selbst ist ja nicht so schwer. Wenn man hier eine Lizenz sparen kann ist sicher besser,
Gruss
Ralf
ja das mit Linux ist denke ich besser. ESX installation selbst ist ja nicht so schwer. Wenn man hier eine Lizenz sparen kann ist sicher besser,
Gruss
Ralf
Habe aber im moment wohl mehr die Windows Cluster Philospohie im Kopf.
So als Tipp:Ein per HA geschützter Windows-File/Exchange/SQL/Print-Server lässt sich 200x einfacher installieren, warten, updaten als ein "echter" MSCS. Und ein rolling-update/upgrade auf einem Produktiven (2-Node) MSCS würde ich weder für das OS noch für die Apps machen.
Als Backup-Lösung kann ich dir auch noch vRanger von vizioncore/Quwest empfehlen.
du kannst vieles machen aber ob das so gut ist ist die andere sache...
ich bin auch noch relativ neu in dem thema und poste einfach was ich davon halte.
habe kein problem damit korrigiert zu werden !
gruß
uLmi
ich bin auch noch relativ neu in dem thema und poste einfach was ich davon halte.
habe kein problem damit korrigiert zu werden !
gruß
uLmi
Dem ist auch so, Lizenzserver läuft (auch) auf dem eigenen Linux.
Aber ich würde gerne wissen warum ich die DC`s physikalisch vorhalten sollte?
Habe in der virtuellen Welt alle Server, auch die DC`s. Fällt mir ein Server aus, übernimmt a) der andere den DC ; geht dies schief (warum auch immer) ist der DC2 ja auf dem anderen ESX-Host.
Fallen beide Hosts aus, siehts natürlich Essig aus, aber dann geht eh nix mehr. Ob Sie dann noch Anmeldinformationen erhalten oder nicht ist eh dann Wurscht, weiterhin gibts noch TTL.
Klärt mich bitte auf! ;)
greetz
ravers
Aber ich würde gerne wissen warum ich die DC`s physikalisch vorhalten sollte?
Habe in der virtuellen Welt alle Server, auch die DC`s. Fällt mir ein Server aus, übernimmt a) der andere den DC ; geht dies schief (warum auch immer) ist der DC2 ja auf dem anderen ESX-Host.
Fallen beide Hosts aus, siehts natürlich Essig aus, aber dann geht eh nix mehr. Ob Sie dann noch Anmeldinformationen erhalten oder nicht ist eh dann Wurscht, weiterhin gibts noch TTL.
Klärt mich bitte auf! ;)
greetz
ravers
Salü,
"Das" habe ich so nicht geschrieben...
Mindestens ein DC sollte Echtblech sein.
Warum?
Der wichtigste Dienst, nach DNS ist die Zeitsynchronisierung.
Ein Gast holt sich die Zeit üblicherweise über seinen Host, der Host holt sich die Zeit üblicherweise von einem DC.
Läuft der einzige DC nun in einer VM, vergibt der Host dem DC seine eigene Uhrzeit und dann holt sich der Host irgendwann die Zeit vom DC.
(eine Schleife ganz ohne for gebaut)
Einen DC sollte man nicht Imagen, oder eine Schattenkopie davon anlegen. Stichwort u.a USN Rollback
Ein DC braucht ordentlich IO Leistung und Ram - die nimmt er den anderen Gästen weg.
Ist der einizige DC in einer VM gefangen, muß ich jede andere VM deutlich später starten.
Eine zusätzliche Zeitverzögerung, die ich persönlich nicht brauche,
Denn starte ich den Host neu, und die HA greift (aus welchem Grund auch immer) nicht - gibt es Stress und da sind ein paar minuten künstliche pause schlimmer als schlimm.
Ich komme nur über Umwege an den DC.
Alle Vorteile - die eine VM bietet - verliere ich bei dem DC - oder andersherum kann ich so garnicht beim DC nutzen.
Es gibt einen ganz einfachen Grund - man kann mit viel Nachdenken, Umstellen, Erfahrung auch seinen einzigen DC virtualisieren, aber der Aufwand rentiert sich nicht, weil man nix gewinnt.
So eine Büxxse, wo ein DC drin läuft kostet ~800€, hat ein DCF77 Modul, weil man nicht davon ausgehen sollte, dass man immer Internet hat und eine eigene Sicherung.
Nochmal, wir sprechen hier über eine allgemeine Aussage - die auch dem Wissen der hier anwesenden Fragesteller geschuldet ist.
Und ich gehe nicht vom Szenario vom Plüschbärchen alles Tutti mit Mutti aus, sondern vom real zu erwartenden Worstcase.
Wieviele Fragen zu DNS; DHCP; Virtualsierung haben wir denn wo sich die meisten denken:
"Hat der denn kein Buch vom symphatischen Marktführer vor dem aufsetzen der Domain gelesen"?
Gruß
Die Edith war gerade da und hat ne Tüte Tippex und Absatzmarken spendiert
edit²
@Dani: d'accord, aber du weißt ja wie es hier ist:
Zwei managbare Switche die dann auch noch an einer USV hängen... Wollen sich die wenigsten leisten.
(ich hab jeden Switch mit seinen zwei Beinen an je einer und noch ganz anderen Tüdelkram...)
Was man auf jeden Fall dazuschreiben kann:
Nicht jeder beherrscht Adhock das Thema Virtualisierung und jeder, der das vorhat sollte sich jemanden ins Boot holen, der das vorher schonmal gemacht hat.
Jeder hat einen anderen Antrieb das zu tun, bei uns wars mal der "vergeudete" Plattenplatz, weil die DCs, der Printserver und einige andere Kisten auf je einem 146 Raid1 mit Hotspare lief, wovon wir aber nur ~ 20-40 GB genutzt haben und sich die User auf unseren Fileservern um das allerletzte freie Bit gekämpft haben, da kam das SAN und damit der ESX ins Spiel.
"Das" habe ich so nicht geschrieben...
Mindestens ein DC sollte Echtblech sein.
Warum?
Achtung unvollständig....
Der wichtigste Dienst, nach DNS ist die Zeitsynchronisierung.
Ein Gast holt sich die Zeit üblicherweise über seinen Host, der Host holt sich die Zeit üblicherweise von einem DC.
Läuft der einzige DC nun in einer VM, vergibt der Host dem DC seine eigene Uhrzeit und dann holt sich der Host irgendwann die Zeit vom DC.
(eine Schleife ganz ohne for gebaut)
Einen DC sollte man nicht Imagen, oder eine Schattenkopie davon anlegen. Stichwort u.a USN Rollback
Ein DC braucht ordentlich IO Leistung und Ram - die nimmt er den anderen Gästen weg.
Ist der einizige DC in einer VM gefangen, muß ich jede andere VM deutlich später starten.
Eine zusätzliche Zeitverzögerung, die ich persönlich nicht brauche,
Denn starte ich den Host neu, und die HA greift (aus welchem Grund auch immer) nicht - gibt es Stress und da sind ein paar minuten künstliche pause schlimmer als schlimm.
Ich komme nur über Umwege an den DC.
Alle Vorteile - die eine VM bietet - verliere ich bei dem DC - oder andersherum kann ich so garnicht beim DC nutzen.
Fallen beide Hosts aus, siehts natürlich Essig aus
Jein - fällt die einzige SAN aus ist viel wahrscheinlicher. (Daher schrub ich da ganz oben auch was von 2 kleinen Iomega NAS zusätzlich)Es gibt einen ganz einfachen Grund - man kann mit viel Nachdenken, Umstellen, Erfahrung auch seinen einzigen DC virtualisieren, aber der Aufwand rentiert sich nicht, weil man nix gewinnt.
So eine Büxxse, wo ein DC drin läuft kostet ~800€, hat ein DCF77 Modul, weil man nicht davon ausgehen sollte, dass man immer Internet hat und eine eigene Sicherung.
Nochmal, wir sprechen hier über eine allgemeine Aussage - die auch dem Wissen der hier anwesenden Fragesteller geschuldet ist.
Und ich gehe nicht vom Szenario vom Plüschbärchen alles Tutti mit Mutti aus, sondern vom real zu erwartenden Worstcase.
Wieviele Fragen zu DNS; DHCP; Virtualsierung haben wir denn wo sich die meisten denken:
"Hat der denn kein Buch vom symphatischen Marktführer vor dem aufsetzen der Domain gelesen"?
Gruß
Die Edith war gerade da und hat ne Tüte Tippex und Absatzmarken spendiert
edit²
@Dani: d'accord, aber du weißt ja wie es hier ist:
Zwei managbare Switche die dann auch noch an einer USV hängen... Wollen sich die wenigsten leisten.
(ich hab jeden Switch mit seinen zwei Beinen an je einer und noch ganz anderen Tüdelkram...)
Was man auf jeden Fall dazuschreiben kann:
Nicht jeder beherrscht Adhock das Thema Virtualisierung und jeder, der das vorhat sollte sich jemanden ins Boot holen, der das vorher schonmal gemacht hat.
Jeder hat einen anderen Antrieb das zu tun, bei uns wars mal der "vergeudete" Plattenplatz, weil die DCs, der Printserver und einige andere Kisten auf je einem 146 Raid1 mit Hotspare lief, wovon wir aber nur ~ 20-40 GB genutzt haben und sich die User auf unseren Fileservern um das allerletzte freie Bit gekämpft haben, da kam das SAN und damit der ESX ins Spiel.
Moin,
@Ravers
@battl1984
@timobeil
Mach für die SAN-Netzwerk 2 Switches die für iSCSI optimiert sind. Beide hängst du auf USV und gut ist. Somit kann nie eine DB-Verbindung zwischen Storage und vServer abbrechen. Das rettet dir öfters den Arsch...
Grüße,
DAni
@Ravers
ies ist bei einigen nicht möglich dafür eine VMWare-MAC-Adresse zu nehmen. Hatte damit Probleme.
Du kannst aber die MAC-Adresse auf die VMWare NIC übernehmen. DC müssen bei 2 ESX-Servern nicht physikalisch vorhanden sein.
Das ist aber nicht BestPractise von Microsoft. Microsoft Sagt kannst klar, DC soll phyalisch vorhanden sind. Was machst du wenn beide ESX Server ausfallen. Ist deine Umgebung tot! Und versuch dann mal ohne Zeitverlust die ESX, etc.. wieder hochzufahren.@battl1984
Die Spnapshot-Funktion ist ja schön und echt gut!! ABER: Wenn du beim erzeugen der VM den Speicherplatz deiner virtuellen Platte nicht von Anfang an komplett allocierst, und einen Snapshot nach dem anderen machst, kann es "irgendwann
Nach meiner Ansicht muss sowas nicht ESXi abbilden sondern das Storage dahinter. Und da kann ich jedem nur Netapp empfehlen egal welche Version.@timobeil
Mach für die SAN-Netzwerk 2 Switches die für iSCSI optimiert sind. Beide hängst du auf USV und gut ist. Somit kann nie eine DB-Verbindung zwischen Storage und vServer abbrechen. Das rettet dir öfters den Arsch...
Grüße,
DAni
Hallo battl1984,
Was die Snapshots betrifft. Es gibt vom VMware Papers(leider eine ganze Menge) die man auch einhalten sollte wenn man "nur" mit ESXi arbeitet. Dann passiert so etwas nicht. Bevor ich die gelesen hatte habe ich diesen Fall auch fast mal kennengelernt.
grüße vom it-frosch
Ein Weiter "kleiner" Nachteil ist: "Ein Computer im Computer ist immer langsamer als der Computer selbst" hat mein Mentor mal gesagt face-smile. Stimmt natürlich auch!
Boote mal einen physikalischen Server, dann den gleichen Server noch einmal virtualisiert und dann streiche deinen Satz durch. Was die Snapshots betrifft. Es gibt vom VMware Papers(leider eine ganze Menge) die man auch einhalten sollte wenn man "nur" mit ESXi arbeitet. Dann passiert so etwas nicht. Bevor ich die gelesen hatte habe ich diesen Fall auch fast mal kennengelernt.
grüße vom it-frosch
Lizenzserver gibts bei VMWare seit der 3.x nicht mehr
Moinsen,
mein Quark zum Thema "DC als Blech / VM":
Auch wenn Microsoft DCs als VM nicht empfiehlt, betrachte ich das mehr als reine Absicherung seitens Microsoft. Exchange 2007 wurde meines Wissens von Microsoft auch niemals als VM-fähig freigegeben, zumindest nicht für HyperV. Wird trotzdem gemacht. Und was den Server 2008-Nachfolger angeht, wird von MS explizit der Betrieb einer DC-VM in einer HyperV-Umgebung angepriesen.
Was auf jeden Fall zu beachten ist:
- Zeitsynchronisation VM-Host <--> VM deaktivieren! (beliebter Fehler!)
- Tunlichst Snapshots der DC-VM vermeiden (soll bei der nächsten Server-Version von Microsoft mit HyperV auch egal sein)
- Betrieb mehrerer DCs auf verschiedenen VM-Hosts. Wenn die wirklich ALLE ausfallen sollten, hat man ganz andere Probleme
- Für kontinuierliche Online-Sicherung der VMs sorgen
- Ich persönlich würde die VM-Hosts nicht in die "Haupt-Domäne" hängen, auch wenn's im Zweifel mehr Konfigurationsaufwand bedeutet
Aus meiner bescheidenen Sicht ist der Satz "DCs auf keinen Fall alle in einer VM" überholt.
Zu ESXi: Hauptproblem, warum wir es nicht einsetzen, ist die fehlende Möglichkeit zur Sicherung der VMs. Da gibt es was von Veeam, ist aber saulangsam.
mein Quark zum Thema "DC als Blech / VM":
Auch wenn Microsoft DCs als VM nicht empfiehlt, betrachte ich das mehr als reine Absicherung seitens Microsoft. Exchange 2007 wurde meines Wissens von Microsoft auch niemals als VM-fähig freigegeben, zumindest nicht für HyperV. Wird trotzdem gemacht. Und was den Server 2008-Nachfolger angeht, wird von MS explizit der Betrieb einer DC-VM in einer HyperV-Umgebung angepriesen.
Was auf jeden Fall zu beachten ist:
- Zeitsynchronisation VM-Host <--> VM deaktivieren! (beliebter Fehler!)
- Tunlichst Snapshots der DC-VM vermeiden (soll bei der nächsten Server-Version von Microsoft mit HyperV auch egal sein)
- Betrieb mehrerer DCs auf verschiedenen VM-Hosts. Wenn die wirklich ALLE ausfallen sollten, hat man ganz andere Probleme
- Für kontinuierliche Online-Sicherung der VMs sorgen
- Ich persönlich würde die VM-Hosts nicht in die "Haupt-Domäne" hängen, auch wenn's im Zweifel mehr Konfigurationsaufwand bedeutet
Aus meiner bescheidenen Sicht ist der Satz "DCs auf keinen Fall alle in einer VM" überholt.
Zu ESXi: Hauptproblem, warum wir es nicht einsetzen, ist die fehlende Möglichkeit zur Sicherung der VMs. Da gibt es was von Veeam, ist aber saulangsam.
Ich gebe aber die Lizenz in dem ESX-Verwaltung ein.
Wenn ich meine Server neu starte startet ein Linux, dann kann ich über`s Webfrontende die Lizenzen eintragen bzw. ändern.
Also irgendwie gibts da auch eine Art Lizenzserver
Wenn ich meine Server neu starte startet ein Linux, dann kann ich über`s Webfrontende die Lizenzen eintragen bzw. ändern.
Also irgendwie gibts da auch eine Art Lizenzserver
Ich gebe aber die Lizenz in dem ESX-Verwaltung ein.
Also irgendwie gibts da auch eine Art Lizenzserver
Nach der Definition ist mein Office 2007 hier auch ein Lizenzsever Also irgendwie gibts da auch eine Art Lizenzserver
Im Ernst: VSphere hat ab der 4.x keinen Lizenzserver mehr. Es werden lediglich Lizenznummern eingetragen, und das kann ich Notfalls auch am ESXi direkt machen.
Hallo nochmal,
also die Sinnigkeit der DC`s (physikalisch); außer die Aussage von Microsoft (soll nicht); ist mir nicht ganz klar.
Sehe es auch so wie Coreknabe zum Thema Ausfall der VM-Hosts (dritte - ).
Und einen DC macht man eh nicht! Daher immer 2; aufgeteilt auf die beiden Hosts.
Zum Thema DC erst hochfahren, dann die anderen Server wg. Zeitverzögerung
Also zumal startet ein DC recht schnell, meiner ca. 2 Min.; im WorstCase sind die 2 Minuten echt egal.
Jedoch konnte ich auch nicht beobachten, das ein Reboot länger dauert wenn der DC nicht ganz da ist. Da gibbet doch noch TTL
Und das ein DC Arbeitsspeicher und und Prozessor frißt wie sau, nee kann ich auch nicht wirklich bestätigen.
@Dani
Was kann ich?? Ich kannmeine alte MAC-Adresse nehmen und der VM unterschieben?? Wiiieeee ??? (und was würde passieren wenn ich den alten Server dann starten würde im Netzwerk; nur mal intessehalber, das es zu Probs dann führt ist klar)
Oder meinst du das die NIC eine VM-Ware-Macadresse bekommt?
Und wenn mir mein ESX-Server ausfallen, ist meine Umgebung wirklich tot. Da interessiert mich auch ein DC dann erstmal nicht mehr
@Coreknabe
Wieso kann man VM`s nicht sichern? Habe BackupEcxec2010; der kann es sehr wohl. Preis ... naja, nicht geschenkt
Und warum nicht in die Haupt-Domäne?? Obs nun VM`s sind oder physikalische, ist doch Wurscht.
greetz
ravers
also die Sinnigkeit der DC`s (physikalisch); außer die Aussage von Microsoft (soll nicht); ist mir nicht ganz klar.
Sehe es auch so wie Coreknabe zum Thema Ausfall der VM-Hosts (dritte - ).
Und einen DC macht man eh nicht! Daher immer 2; aufgeteilt auf die beiden Hosts.
Zum Thema DC erst hochfahren, dann die anderen Server wg. Zeitverzögerung
Also zumal startet ein DC recht schnell, meiner ca. 2 Min.; im WorstCase sind die 2 Minuten echt egal.
Jedoch konnte ich auch nicht beobachten, das ein Reboot länger dauert wenn der DC nicht ganz da ist. Da gibbet doch noch TTL
Und das ein DC Arbeitsspeicher und und Prozessor frißt wie sau, nee kann ich auch nicht wirklich bestätigen.
@Dani
Was kann ich??
Ich kannmeine alte MAC-Adresse nehmen und der VM unterschieben?? Wiiieeee ??? (und was würde passieren wenn ich den alten Server dann starten würde im Netzwerk; nur mal intessehalber, das es zu Probs dann führt ist klar)Oder meinst du das die NIC eine VM-Ware-Macadresse bekommt?
Und wenn mir mein ESX-Server ausfallen, ist meine Umgebung wirklich tot. Da interessiert mich auch ein DC dann erstmal nicht mehr
@Coreknabe
Wieso kann man VM`s nicht sichern? Habe BackupEcxec2010; der kann es sehr wohl. Preis ... naja, nicht geschenkt
Und warum nicht in die Haupt-Domäne?? Obs nun VM`s sind oder physikalische, ist doch Wurscht.
greetz
ravers
Zum Thema DC erst hochfahren, dann die anderen Server wg. Zeitverzögerung
Nun ja, das kann und sollte man durchaus so machen. Gegenbeweis, wobei ich nur für HyperV sprechen kann: DC-VM und Exchange-VM auf selbem Host. Fahr mal die DC-VM erst runter und danach den Exchange. Habe schon erlebt, dass es bis zu 45 Minuten gedauert hat, dass der Exchange runtergefahren ist. Annahme: Der versucht noch, Netzwerkdinge mit dem DC abzukaspern, der schon weg ist.
Im Gegenzug tut's sicher nicht weh, den DC auch als erste Kiste hochgezogen und einsatzbereit zu haben.
@Coreknabe
Wieso kann man VM`s nicht sichern? Habe BackupEcxec2010; der kann es sehr wohl. Preis ... naja, nicht geschenkt
Wieso kann man VM`s nicht sichern? Habe BackupEcxec2010; der kann es sehr wohl. Preis ... naja, nicht geschenkt
Wir haben BackupExec 12.5, keine Agenten für virtuelle Maschinen dabei. Und nachkaufen können wir die nur, wenn wir auch BEXEC 2010 kaufen. Kein Upgrade mangels Wartung (schwerer Fehler, für Backupsoftware die Wartung nicht zu verlängern, wie ich mittlerweile weiß). Dazu kommt, dass der BEXEC-Müll ein paar Wochen läuft und man dann im Fehlerfall immer wieder lustige Sachen bemerkt. So werden z.B. die Agenten nicht zwingend mit der Serversoftware auf einen neueren Stand hochgezogen. Da testet der blöde Admin also ein paar Mal Sicherung und Rücksicherung und geht dann davon aus, dass es funktioniert. Soll mir keiner erzählen, dass er da regelmäßige Tests machen würde. Jüngstes Beispiel: Ich musste Mails aus einem Exchange-Postfach zurücksichern. Geht nicht, weil der Agent auf dem Exchange nicht auf dem Update-Stand des Servers ist. Also: MANUELL alle Hotfixes auf Exchange nachziehen, sicherheitshalber nach jedem Update ein Reboot. Mahlzeit! Und das ist nur eins von vielen Ärgernissen.
Deshalb bin ich von BackupExec zu Acronis Backup & Recovery gewechselt. Rennt wie blöd, Support ist gut bis sehr gut, kein Aua mehr.
Und warum nicht in die Haupt-Domäne?? Obs nun VM`s sind oder physikalische, ist doch Wurscht.
Da bin ich entgegen meiner sonstigen Meinung paranoid, ist aber eher ein unsinniges persönliches Ding. Weil: DC auf Host weg, wenn ich da an das obengenannte Exchange-Beispiel denke... Hab diese Variante aber im Gegensatz zum Exchange-Ding nie ausprobiert.
Daher mache ich kein aut. Update, sondern kümmere mich darum wenn entweder Probleme auftauchen oder wenn Zeit ist mal ein Update zu fahren (Motto: Dont change a running System). Dann aktualisiere ich auch händisch nochmal den Agent. Zugegeberweise macht der tatsächlich ab und zu Probleme, daher mache ich`s händisch. Der Support von Symantec ist weit besser geworden, wenn auch nicht super. Stimmt schon. Komnmt aber auch drauf an, wen man erwischt, wie so oft.
Zum Thema Zeitverzögerung: Müsste ich mal testen. Bislang war ein DC immer online bei ner An- oder Abmeldung, denk ich. Warum sollten auch beide DC`s down sein.
Greetz
ravers
P.S.: Entscheidung gefallen: beide DC`s bleiben auf den ESX verteilt. Konnte mich nicht überzeugen das dieser Physich sein soll. Nur weil MS es gerne hätte.
Zum Thema Zeitverzögerung: Müsste ich mal testen. Bislang war ein DC immer online bei ner An- oder Abmeldung, denk ich. Warum sollten auch beide DC`s down sein.
Greetz
ravers
P.S.: Entscheidung gefallen: beide DC`s bleiben auf den ESX verteilt. Konnte mich nicht überzeugen das dieser Physich sein soll. Nur weil MS es gerne hätte.
Hallo
auch ich möchte mal was dazu sagen.
wir haben hier bei uns fast alle Server auf VM laufen. Bisher traten keine Probleme auf.
Zu meinem bedauern habe wir das alles auf einem Bladecenter und Blades mit leider nur 2 physikalischen Netzwerkschnittstellen.
Leider habe ich auch meine DC´s und den VMware Server Virtuel bin aber dabei zu versuchen dieses zu ändern.
Also wenn du also FT HA und VMotion nutzen willst solltest du auch auf Netzwerkschnittstellen deiner Hardware achten.
Am besten ist es wenn du für alles einen eigene Netzwerkschnittstelle hast.
Bei nur 2 Netzwerkschnittstellen kannste das mit FT vergessen, HA und Vmotion klappt ganz gut. jedoch könnte es besser sein.
Ich war anfangs auch sehr skeptisch was es angeht zu Virtualiesiren aber heute würde ich es immer wieder machen.
LG
Footy
auch ich möchte mal was dazu sagen.
wir haben hier bei uns fast alle Server auf VM laufen. Bisher traten keine Probleme auf.
Zu meinem bedauern habe wir das alles auf einem Bladecenter und Blades mit leider nur 2 physikalischen Netzwerkschnittstellen.
Leider habe ich auch meine DC´s und den VMware Server Virtuel bin aber dabei zu versuchen dieses zu ändern.
Also wenn du also FT HA und VMotion nutzen willst solltest du auch auf Netzwerkschnittstellen deiner Hardware achten.
Am besten ist es wenn du für alles einen eigene Netzwerkschnittstelle hast.
Bei nur 2 Netzwerkschnittstellen kannste das mit FT vergessen, HA und Vmotion klappt ganz gut. jedoch könnte es besser sein.
Ich war anfangs auch sehr skeptisch was es angeht zu Virtualiesiren aber heute würde ich es immer wieder machen.
LG
Footy
Servus Ravers,
merkst du was?
Aber ist dann der ganze DC komplett einsatzbereit?
Nein
Tja, es gibt aber leute, die das anders sehen mein OWA; FTP, die Citrixumgebung und gaaaanz viel anderer Tüddelkram ist nicht virtuell und die brauchen trotzdem einen DC.
Schau dir auch mal das Grundrauschen an, was der DC veranstaltet, wenn die Stechuhr benutzt wird.
Und dann erzähl mir was vomGipskrieg der DC macht keine Last.
BTW: Schau dir meine Zeile mal genau an - "wenn" denn der DC soooooo viel Last produziert, waruim läuft der dann auf einem Dualatom?
Meinst du die Fragesteller, die hier üblicherweise fragen - haben alle einen VM Host mit 8 Netzwerkkarten?
Im lebbe nedd. Die meisten kennen doch immer noch nicht den Unterschied zwischen ESX und ESXi - bzw, dass es den ESX schon seit xxx Monden nicht mehr gibt.
Und an solche Patienten muß der geneigte Apotheker auch denken, wenns denn heisst "Risiken und Nebenwirkungen"
Gruß
merkst du was?
Also zumal startet ein DC recht schnell, meiner ca. 2 Min.;
yupp in 2 minuten ist mein Anmeldebildschirm auch schon da Aber ist dann der ganze DC komplett einsatzbereit?
Nein
Ich kannmeine alte MAC-Adresse nehmen und der VM unterschieben?? Wiiieeee
"Wenn" -du das wirklich willst - dann frage woanders nach - der Fred heisst Risiken und Nebenwirkungen und nicht unsupportet tricks.Und wenn mir mein ESX-Server ausfallen, ist meine Umgebung wirklich tot. Da interessiert mich auch ein DC dann erstmal nicht mehr.
Tja, es gibt aber leute, die das anders sehen mein OWA; FTP, die Citrixumgebung und gaaaanz viel anderer Tüddelkram ist nicht virtuell und die brauchen trotzdem einen DC.
Schau dir auch mal das Grundrauschen an, was der DC veranstaltet, wenn die Stechuhr benutzt wird.
Und dann erzähl mir was vom
BTW: Schau dir meine Zeile mal genau an - "wenn" denn der DC soooooo viel Last produziert, waruim läuft der dann auf einem Dualatom?
Meinst du die Fragesteller, die hier üblicherweise fragen - haben alle einen VM Host mit 8 Netzwerkkarten?
Im lebbe nedd. Die meisten kennen doch immer noch nicht den Unterschied zwischen ESX und ESXi - bzw, dass es den ESX schon seit xxx Monden nicht mehr gibt.
Und an solche Patienten muß der geneigte Apotheker auch denken, wenns denn heisst "Risiken und Nebenwirkungen"
Gruß
Salve,
konnte keine Probleme feststellen bislang. Computereinstellungen werden vor dem Anmeldebildschirm geladen, daher läuft er soweit. Was nicht heißt das alle Dienste da sind. Habe aber gerade mal den Test gemacht, die Last von CPU und Arbeitsspeicher geht gen 0 nach OK insgesamt etwas unter 5 Minuten. Im WorstCase kein Problem
Zum Thema unsupportet Tricks: Weiß ich denn das es nicht supportet wird? Nö? Kenne es ja garnicht. Hätte es gerne gewußt und versucht (auch unsupportet)! Wenn`s klappt, Supi, hätte viel Geld und evtl sogar noch Zeit sparen können (Lizenz mußte neu ausgestellt werden; kam aus Amerika (und da sind sie seeehr langsam damit); und sau teuer); wenn nicht dann nicht. Habe nichtmal die Frage hier gestellt, da unser Systemhaus meinte, geht nicht. Und das ist kein kleines Systemhaus. Daher habe Ihnen verstraut.
Gerne hätte ich`s versucht! (@Dani )
Bei den Leuten, die nicht alles virtualisiert haben sehe ich DC-Problematik auch anders.
Aber entweder virtualisiere ich oder nicht. Aber 50% virtualisieren und 50% nicht ... ist nicht konsequent. So habe ich wieder normale Kisten dort stehen und habe die altbekannten Problematiken. Warum wird nicht alles virtualisiert?? Server zu klein = größeren, schon allein der CO²- Einsparung! Denke doch immer an meine Kinder und Kindeskinder. Wobei bei Citrix siehts anders natürlich aus, würde ich auch nicht virtualisieren; auch div. COM-Dienste! OWA (weil der Exchange eh da läuft) & Co. gehört sich m.E. virtualisiert.
Gut, wenn ich keine 8 Nics o.ä. habe dann sehe ich ein das ich z.B. DMZ, OWA nicht virtualisiere und dann hat der physikalische DC auch wieder seine Begründung.
Ich bin da lieber konsequent!
Finde auch den Unterschied eher albern: reden wir von ESX oder ESXi? Die sich mit aktueller Technik herumschlagen meinen wohl immer ESXi.
greetz
Ravers
konnte keine Probleme feststellen bislang. Computereinstellungen werden vor dem Anmeldebildschirm geladen, daher läuft er soweit. Was nicht heißt das alle Dienste da sind. Habe aber gerade mal den Test gemacht, die Last von CPU und Arbeitsspeicher geht gen 0 nach OK insgesamt etwas unter 5 Minuten. Im WorstCase kein Problem
Zum Thema unsupportet Tricks: Weiß ich denn das es nicht supportet wird? Nö? Kenne es ja garnicht. Hätte es gerne gewußt und versucht (auch unsupportet)! Wenn`s klappt, Supi, hätte viel Geld und evtl sogar noch Zeit sparen können (Lizenz mußte neu ausgestellt werden; kam aus Amerika (und da sind sie seeehr langsam damit); und sau teuer); wenn nicht dann nicht. Habe nichtmal die Frage hier gestellt, da unser Systemhaus meinte, geht nicht. Und das ist kein kleines Systemhaus. Daher habe Ihnen verstraut.
Gerne hätte ich`s versucht! (@Dani
)Bei den Leuten, die nicht alles virtualisiert haben sehe ich DC-Problematik auch anders.
Aber entweder virtualisiere ich oder nicht. Aber 50% virtualisieren und 50% nicht ... ist nicht konsequent. So habe ich wieder normale Kisten dort stehen und habe die altbekannten Problematiken. Warum wird nicht alles virtualisiert?? Server zu klein = größeren, schon allein der CO²- Einsparung! Denke doch immer an meine Kinder und Kindeskinder. Wobei bei Citrix siehts anders natürlich aus, würde ich auch nicht virtualisieren; auch div. COM-Dienste! OWA (weil der Exchange eh da läuft) & Co. gehört sich m.E. virtualisiert.
Gut, wenn ich keine 8 Nics o.ä. habe dann sehe ich ein das ich z.B. DMZ, OWA nicht virtualisiere und dann hat der physikalische DC auch wieder seine Begründung.
Ich bin da lieber konsequent!
Finde auch den Unterschied eher albern: reden wir von ESX oder ESXi? Die sich mit aktueller Technik herumschlagen meinen wohl immer ESXi.
greetz
Ravers
Moin
@Ravers
Grüße,
Dani
@Ravers
also die Sinnigkeit der DC`s (physikalisch); außer die Aussage von Microsoft (soll nicht); ist mir nicht ganz klar.
Versuch mal den Server wo vCenter drauf hochzufahren nach einem total Ausfall. Du wirst dich wundern wie lange es dauern kann bis du auf einem ESX den ersten DC wieder hochgefahren hast. Wir hatten ganz am Anfang einen Totalausfall und die Domaincontroller waren alle virtuell. Seitdem stehen 2 phy. DC's an zwei anderen Geäuden für den Worstcase. Denn Produktionsausfallzeit können wir uns nicht oft erlauben.Entscheidung gefallen: beide DC`s bleiben auf den ESX verteilt. Konnte mich nicht überzeugen das dieser Physich sein soll. Nur weil MS es gerne hätte.
Die Erfahrung lass ich dich gerne machen... Was kann ich?? Ich kannmeine alte MAC-Adresse nehmen und der VM unterschieben?? Wiiieeee ???
Geht ohne Probleme. Jedoch laut VMWare nicht supported aber geht bisher mit allen Lizenzserver. Schreib mir einfach ne PN dazu, damit ich am Weekend dran denke. Finde auch den Unterschied eher albern: reden wir von ESX oder ESXi? Die sich mit aktueller Technik herumschlagen meinen wohl immer ESXi
Es gibt mit Version 5 kein ESX mehr! -> vmware.comGrüße,
Dani
Zitat von @Dani:
Moin
@Ravers
> also die Sinnigkeit der DC`s (physikalisch); außer die Aussage von Microsoft (soll nicht); ist mir nicht ganz klar.
Versuch mal den Server wo vCenter drauf hochzufahren nach einem total Ausfall. Du wirst dich wundern wie lange es dauern kann bis
du auf einem ESX den ersten DC wieder hochgefahren hast. Wir hatten ganz am Anfang einen Totalausfall und die Domaincontroller
waren alle virtuell. Seitdem stehen 2 phy. DC's an zwei anderen Geäuden für den Worstcase. Denn
Produktionsausfallzeit können wir uns nicht oft erlauben.
[...]Moin
@Ravers
> also die Sinnigkeit der DC`s (physikalisch); außer die Aussage von Microsoft (soll nicht); ist mir nicht ganz klar.
Versuch mal den Server wo vCenter drauf hochzufahren nach einem total Ausfall. Du wirst dich wundern wie lange es dauern kann bis
du auf einem ESX den ersten DC wieder hochgefahren hast. Wir hatten ganz am Anfang einen Totalausfall und die Domaincontroller
waren alle virtuell. Seitdem stehen 2 phy. DC's an zwei anderen Geäuden für den Worstcase. Denn
Produktionsausfallzeit können wir uns nicht oft erlauben.
Grüße,
Dani
Dani
Hi,
sehe ich das richtig das Du einen eigenen Server mit vCenter drauf hast und das dieser Server ewig brauchte um hochzufahren weil die DCs nicht da waren? Und Du erst nach dem Hochfahren des vCenter-Servers die DCs starten konntest?
Gruß,
Andreas
Hi Andreas,
siehst du richtig...
siehst du richtig...
Und warum konntest Du die DCs nicht vor dem vCenter-Server hochfahren?
(OT)
Moin moin,
letzte Beitrag hier von mir zum Thema!
@Dani
Danke erstmal, zunächst fürs Angebot der PN und für den Erfahrungsbericht eures WorstCase! Werde mich bei dir melden bzw. heut vormittag erstmal selbst ausprobieren. Wobei nicht nur unser Systemhaus, sondern auch der Lieferant der Lizenz sagte: es sei nicht möglich. Habe dann auch nicht weitergesucht. Gab genug Sachen, die ich zu tun hatte, klar wenn man von NT4-Domäne direkt auf Win2008 umstellt. Denke beide Häuser kennen sich besser mit ESXi aus als meine Wenigkeit; ich habe es (recht) neu. Mal schaun obs wirklich geht, und nicht irgendwie immuliert ist. Wenn`s geht gibts ne schöne Rückerstattung und mecker von mir an die Häuser.
@timobeil
ich kenn alles ... nee, sicherlich nicht. Sonst hätte ich mir den Job nicht ausgesucht. Genau das war nämlich das Interessante, man lernt immer dazu, weil auch immer was neues kommt. Vorher als Bankkaufmann war alles fest, nur die Zinssätze änderten sich (überspitzt dargestellt), dies war mir zu uninteressant. Jedoch arbeite ich seit ca. 25 Jahren mit PC`s (wenn auch nicht beruflich durchgängig).
Und ich hatte keine Frage, sondern habe nur Überraschend festgestellt, das dies geht. Gerade weil ich Systemhäuser gefragt habe. Mehr nicht!
Soweit so gut! Wünsche ein schönes Arbeitstag und ein sonniges Wochenende!
Moin moin,
letzte Beitrag hier von mir zum Thema!
@Dani
Danke erstmal, zunächst fürs Angebot der PN und für den Erfahrungsbericht eures WorstCase! Werde mich bei dir melden bzw. heut vormittag erstmal selbst ausprobieren. Wobei nicht nur unser Systemhaus, sondern auch der Lieferant der Lizenz sagte: es sei nicht möglich. Habe dann auch nicht weitergesucht. Gab genug Sachen, die ich zu tun hatte, klar wenn man von NT4-Domäne direkt auf Win2008 umstellt. Denke beide Häuser kennen sich besser mit ESXi aus als meine Wenigkeit; ich habe es (recht) neu. Mal schaun obs wirklich geht, und nicht irgendwie immuliert ist. Wenn`s geht gibts ne schöne Rückerstattung und mecker von mir an die Häuser.
@timobeil
ich kenn alles ... nee, sicherlich nicht. Sonst hätte ich mir den Job nicht ausgesucht. Genau das war nämlich das Interessante, man lernt immer dazu, weil auch immer was neues kommt. Vorher als Bankkaufmann war alles fest, nur die Zinssätze änderten sich (überspitzt dargestellt), dies war mir zu uninteressant. Jedoch arbeite ich seit ca. 25 Jahren mit PC`s (wenn auch nicht beruflich durchgängig).
Und ich hatte keine Frage, sondern habe nur Überraschend festgestellt, das dies geht. Gerade weil ich Systemhäuser gefragt habe. Mehr nicht!
Soweit so gut! Wünsche ein schönes Arbeitstag und ein sonniges Wochenende!
Fahr mal ohne VMWare vCenter einen virtuellen DC-Server auf einem ESX-Server hoch...
Back to Topic:
Im Prinzip gibt es keine Probleme, wenn man die Grundfunktionen richtig benutzt und einsetzt.
u.a ein Vorteil (incl. dessen Nachteilen) wurde noch nicht angesprochen.
Das "mitwachsen" der einzelnen Platten.
Ohne eine Virtualiserungslösung gibt es sowas nicht automatisch. Macht man es automatisch kann einem der Strick daraus gedreht werden.
Nehmen wir mal (zwecks einfachem Rechnen) an, wir haben ein SAN mit 1 TB Nutzdaten, darauf kommen 5 Gäste und man weiß nicht - wie groß die Platten sein sollen.
Plattenplatzverschwendung ist out, Pi * Daumen ist in, also 5 Gäste - jeder darf sich 200 GB holen - alles Banane.
(Und dann kommt es anders, als man denkt und ein Gast kommt noch dazu, der bekommt 20 GB - passt ja alles noch rein)
Und wenn dann mal alle Gäste Ihren zugewiesenen Platz in Anspruch nehmen - kommt der große Snapshotknall
Mit anderen Worten: Wenn man die Verteilung aus der Hand gibt, muß man vorher nachdenken und immer wieder nachrechnen, ob es denn immer noch passt.
Da Backups immer auch Nachts passieren, kommt der Worstcase auch Nachts.
Wie geschrieben, wenn man sich einen Plan macht, der gut durchdacht ist (und das ist in meinen Augen überall so und für mich der Grund warum es einen freien Hypervisor als Spielwiese gibt) dann hat man keine Probleme.
Macht man das nicht, denkt nicht an den Worstcase - so landet man logischerweise irgendwann mal in einem Szenario, das dann auch in der Schublade possible Worstcase landet.
Holt man sich jemanden, der Erfahrungen hat - dann sollte einem dessen gefüllte Worstcase Schublade helfen.
Immer frei nach dem Motto, der kluge lernt aus den Fehlern der dummen und der Dumme muß aus seinen eigenen Fehlern lernen.
(Das ist ein Sprichwort und keine Verhonepiepung)
Zitat von @Dani:
Fahr mal ohne VMWare vCenter einen virtuellen DC-Server auf einem ESX-Server hoch...
Du kannst dich mit dem vSphere Client auch direkt mit dem ESX(i) verbinden (und da VMs starten) auch wenn dieser durch einen vCenter Server verwaltet wird.Fahr mal ohne VMWare vCenter einen virtuellen DC-Server auf einem ESX-Server hoch...
Jo richtig, setzt aber a) einen phy. Client vorraus - wir haben VMWare View im Einsatz b) du musst wissen auf welchen ESX der DC befindet. Des Weiteren kannst du nicht ausschließen, dass das AD beschädigt worden ist. Backup hin oder her, aber Disaster Recovery von DC muss ich nicht erlebt haben. Vorallem merkst du den Schaden bei entsprechender Größe nicht gleich.
Warum sich an Vorgaben vom Hersteller zu halten? Ganz einfach: Da stellt sich der Support am wengisten quer! Und mal ehrlich für Backup, vCenter brauchst du sowieso einen phy. Server. Ich weiß man kann vCenter auch virtuell laufen lassen aber nicht auf dem Cluster für das es zuständig ist und wird von VMWare nicht unsupported!
Warum sich also dem Risiko ausetzen und unnötig Nerven und Zeit im Worstcase verlieren.
Grüße,
Dani
Warum sich an Vorgaben vom Hersteller zu halten? Ganz einfach: Da stellt sich der Support am wengisten quer! Und mal ehrlich für Backup, vCenter brauchst du sowieso einen phy. Server. Ich weiß man kann vCenter auch virtuell laufen lassen aber nicht auf dem Cluster für das es zuständig ist und wird von VMWare nicht unsupported!
Warum sich also dem Risiko ausetzen und unnötig Nerven und Zeit im Worstcase verlieren.
Grüße,
Dani
Zitat von @Ravers:
Lizenzen (Lizenzserver) werden oft auf einer MAC-Adresse ausgestellt; dies ist bei einigen nicht möglich dafür eine
VMWare-MAC-Adresse zu nehmen. Hatte damit Probleme.
Lizenzen (Lizenzserver) werden oft auf einer MAC-Adresse ausgestellt; dies ist bei einigen nicht möglich dafür eine
VMWare-MAC-Adresse zu nehmen. Hatte damit Probleme.
Na gottseidank hast Du das Feld noch nicht gefunden, wo man seine MAC selbst vergeben kann...
Ist ein COM-Anschluß o.ä. nötig siehts schlecht aus. Habe einen physikalischen kleinen Server aufgesetzt, der die
COM-Arbeiten sowie Lizenzserver macht (die nicht VM-tauglich sind).
Sicherung der Systeme nur bedingt einfach.
COM-Arbeiten sowie Lizenzserver macht (die nicht VM-tauglich sind).
Sicherung der Systeme nur bedingt einfach.
Was ein Käse.
Sogar USB kann man mit durchschleifen, gewußt wie...
(also nix für die Hobby-Frickler und Handbuch-/Schulungs-Verweigerer...)
Lonesome Walker
Hallo,
wir haben 2 DC's aufgesetzt und beide sind virtuell auf dem ESX Servern verteilt. Wir nutzen jedoch die "kleinere" Lizenz aus Kostengründen, die kein HA hat. 2 große Dell Server, auf jedem läuft ein DC, der natürlich vor allen anderen Maschinen starten muss. Ein weiterer (kleinerer) ESX Server ist auf Standby wenn es mal hakt, können wir Maschinen umziehen. Aber die 2 großen packen die Arbeit locker alleine und haben noch Resourcen frei.
Ebenfalls haben wir den vCenter Server virtualisiert, aber durch Veeam Backup einen Replica auf den anderen beiden Servern erstellt für den Notfall...
Man muss nicht zwingend immer das Teuerste und sicherste nehmen. Je nach Bedarf am Kunden finde ich, sollte man sehen, was wird dort auf den Servern an Anwendungen genutzt, wie ist die Auslastung und die Hardware... usw.
Gruß, Benny
wir haben 2 DC's aufgesetzt und beide sind virtuell auf dem ESX Servern verteilt. Wir nutzen jedoch die "kleinere" Lizenz aus Kostengründen, die kein HA hat. 2 große Dell Server, auf jedem läuft ein DC, der natürlich vor allen anderen Maschinen starten muss. Ein weiterer (kleinerer) ESX Server ist auf Standby wenn es mal hakt, können wir Maschinen umziehen. Aber die 2 großen packen die Arbeit locker alleine und haben noch Resourcen frei.
Ebenfalls haben wir den vCenter Server virtualisiert, aber durch Veeam Backup einen Replica auf den anderen beiden Servern erstellt für den Notfall...
Man muss nicht zwingend immer das Teuerste und sicherste nehmen. Je nach Bedarf am Kunden finde ich, sollte man sehen, was wird dort auf den Servern an Anwendungen genutzt, wie ist die Auslastung und die Hardware... usw.
Gruß, Benny
Zitat von @Dani:
Warum sich an Vorgaben vom Hersteller zu halten? Ganz einfach: Da stellt sich der Support am wengisten quer! Und mal ehrlich
für Backup, vCenter brauchst du sowieso einen phy. Server. Ich weiß man kann vCenter auch virtuell laufen lassen aber
nicht auf dem Cluster für das es zuständig ist und wird von VMWare nicht unsupported!
Warum sich also dem Risiko ausetzen und unnötig Nerven und Zeit im Worstcase verlieren.
Warum sich an Vorgaben vom Hersteller zu halten? Ganz einfach: Da stellt sich der Support am wengisten quer! Und mal ehrlich
für Backup, vCenter brauchst du sowieso einen phy. Server. Ich weiß man kann vCenter auch virtuell laufen lassen aber
nicht auf dem Cluster für das es zuständig ist und wird von VMWare nicht unsupported!
Warum sich also dem Risiko ausetzen und unnötig Nerven und Zeit im Worstcase verlieren.
Für vCenter oder Veeam Backup braucht man keinen physikalischen Server. Meine Meinung. Wir setzen das alles virtuell ein vCenter und eine VM mit 4 Kernen für Veeam Backup.
Zusätzlich haben wir jedoch einen physikalischen Server als Tape Backup Server, der wiederum das NAS (Backup Storage) wegsichert...
Aktuell fahren wir 2 DC's verteilt auf die ESX Server. Ich werde demnächst jedoch den Backup Server als 3. Domain Controller also als "Backup" konfigurieren. Schaden kann es nicht.
Gruß, Benny
Moin,
ähmm - aufgrund unter anderem meiner Bitte - hatten wir hier mal ausgemistet und langsam aber sicher kommen die schon x mal durchgekauten und damals rausgeworfenen "Aberles" wieder (von anderen) raus...
Fakt ist - die Frage ist
Und nicht, welche unspupporteten Tricks funktionieren im Moment bei Euch und falls ja Habt Ihr vom Theaterstück Wörschdkäs alle Szenen durchgekaspert?
Fakt ist auch -Veem/Vcenter braucht selber ordentlich Ramses für die Datenbanken und wenn es sichern soll auch noch Prozessorlast.
Virtualiserung ohne Lastverteilung ist ....
Und durch "sowas" wie du da oben schreibst erzeugst du Last beim Backup und im laufenden Betrieb und du hast nachher den schwarzen Peter, wenn du da mal wirklich ranmußst.
[OT]
Erinnert mich irgendwie an
- und das die meisten Firmen Nachts fakturieren, Ihre Datenbanken reorganisieren, umfangreiche Import/Exportjobs machen - das zeigt doch nur, dass wir hier irgendwie nicht weiterkommen.
Ich dachte eigentlich hätte ich mich klar ausgedrückt, aber nein die Aberle Fraktion....
ähmm - aufgrund unter anderem meiner Bitte - hatten wir hier mal ausgemistet und langsam aber sicher kommen die schon x mal durchgekauten und damals rausgeworfenen "Aberles" wieder (von anderen) raus...
Fakt ist - die Frage ist
Was sindRisiken und Nachteile bei einer Virtualsieriung mit ESX
Fakt ist auch -Veem/Vcenter braucht selber ordentlich Ramses für die Datenbanken und wenn es sichern soll auch noch Prozessorlast.
Virtualiserung ohne Lastverteilung ist ....
Und durch "sowas" wie du da oben schreibst erzeugst du Last beim Backup und im laufenden Betrieb und du hast nachher den schwarzen Peter, wenn du da mal wirklich ranmußst.
[OT]
Erinnert mich irgendwie an
xcopy /s "%userprofile%" "c:\backup\"
[/OT]edit...
Ja, haben wir. Ich sehe eher einen Nachteil beim Gigabit Netz, wenn Veeam Backup auf der extra Blechkiste hockt.
- Egal wohin man sichert - außer man hätte ein eigenes SAN mit Fiberchannel - GB Ethernet ist immer noch schneller, als die meisten Platten...
Richtig. Unsere Server haben 2 Xeons, wovon 4 Kerne in die jeweilige VM gehen...
- hybsch... Und was will uns der Verfasser damit schreiben (nein bitte schreib keinen neuen Kommentar)
Klar steigt die Last, aber das ist nachts doch unwichtig, wenn in Produktion keiner arbeitet.
- Niente
- und das die meisten Firmen Nachts fakturieren, Ihre Datenbanken reorganisieren, umfangreiche Import/Exportjobs machen - das zeigt doch nur, dass wir hier irgendwie nicht weiterkommen.
Ich habe Veeam Backup zur Sicherheit auf der Blechkiste mit drauf, so dass eine Rücksicherung der Backups, die auf dem NAS liegen möglich ist.
- supi - doppelte Lizenskosten für den Fall der Fälle oder Lizensverstoß ?
Ich dachte eigentlich hätte ich mich klar ausgedrückt, aber nein die Aberle Fraktion....
Zitat von @60730:
> Zitat von @BennyTurbo:
> ----
Fakt ist - die Frage ist
>> Was sindRisiken und Nachteile bei einer Virtualsieriung mit ESX
Und nicht, welche unspupporteten Tricks funktionieren im Moment bei Euch und falls ja Habt Ihr vom Theaterstück
Wörschdkäs alle Szenen durchgekaspert?
> Zitat von @BennyTurbo:
> ----
Fakt ist - die Frage ist
>> Was sindRisiken und Nachteile bei einer Virtualsieriung mit ESX
Und nicht, welche unspupporteten Tricks funktionieren im Moment bei Euch und falls ja Habt Ihr vom Theaterstück
Wörschdkäs alle Szenen durchgekaspert?
Ja, haben wir. Ich sehe eher einen Nachteil beim Gigabit Netz, wenn Veeam Backup auf der extra Blechkiste hockt.
Fakt ist auch -Veem/Vcenter braucht selber ordentlich Ramses für die Datenbanken und wenn es sichern soll auch noch
Prozessorlast.
Und durch "sowas" wie du da oben schreibst erzeugst du Last beim Backup und im laufenden Betrieb und du hast nachher den
schwarzen Peter, wenn du da mal wirklich ranmußst.
Prozessorlast.
Und durch "sowas" wie du da oben schreibst erzeugst du Last beim Backup und im laufenden Betrieb und du hast nachher den
schwarzen Peter, wenn du da mal wirklich ranmußst.
Richtig. Unsere Server haben 2 Xeons, wovon 4 Kerne in die jeweilige VM gehen... Klar steigt die Last, aber das ist nachts doch unwichtig, wenn in Produktion keiner arbeitet.
Was genau meinst Du? Ich habe Veeam Backup zur Sicherheit auf der Blechkiste mit drauf, so dass eine Rücksicherung der Backups, die auf dem NAS liegen möglich ist.
[OT]
Erinnert mich irgendwie an
> xcopy /s "%userprofile%" "c:\backup\"
[/OT]
Hmm, ohne das Backup Konzept zu kennen, eine gewagte Aussage... aber gut war ja nur "OT"
