ESX / ESXi - Hilfethread
- Ersteller XTaZY
- Erstellt am
konfetti
Urgestein
Ja, aber Du wirst wohl eher wissen wollen, wie das mit dem "Shut down" funktioniert?
da muss ich leider passen - ich verwende die USV auch primär um die Lastspitzen bei uns etwas zu glätten...
da muss ich leider passen - ich verwende die USV auch primär um die Lastspitzen bei uns etwas zu glätten...
genau, das scheint beim ESXi 4.1 gar nicht so einfach zu sein. Bin gerade dabei ein Script zu schreiben, dass die VMs nacheinander runterfährt und dann den ESXi runterfährt. Das wird dann auf einer Linuxkiste ausgeführt, wenn die USV es sagt.
Glanter
Enthusiast
Greift eine USV nicht nur dann ein, wenn das Netz ausfällt? Ansonsten sollte doch die Netzspannung einfach durchgeschlauft werden.
Oder habt ihr eine erweiterte USV die noch bei Lastspitzen aushilft.
konfetti
Urgestein
Eine USV hat in den meisten Fällen auch einen Überspannungsschutz bzw. korrigiert unter Umständen zu geringe Spannung auf der Eingangsseite.
Wenn ein System bei uns, aus dem "Stand" volle Leistung geben muss - tut, kann es leider vorkommen das die Netzspannung etwas darunter leidet - In dem Gebäudeabschnitt wird es leider auf Absehbare Zeit keine Lösung dafür geben, Umziehen der ganzen Server ist auch nicht möglich. - Die USV kommt damit aber gut klar.
Wenn ein System bei uns, aus dem "Stand" volle Leistung geben muss - tut, kann es leider vorkommen das die Netzspannung etwas darunter leidet - In dem Gebäudeabschnitt wird es leider auf Absehbare Zeit keine Lösung dafür geben, Umziehen der ganzen Server ist auch nicht möglich. - Die USV kommt damit aber gut klar.
end of life? in professionellen umgebungen nimmt man kein ESXi, sondern vSphere aka ESX 4.
ESX mag vom namen her end of life sein, aber das kern-produkt ist es definitiv nicht. der direkte nachfolger ist vSphere (ESX 4), welches sich quasi genau wie ein esx-server installieren und bedienen lässt.
silentbooster
Semiprofi
Wir haben APC USVen. Die haben eine LAN Schnittstelle und senden ein Signal an alle VMs/Rechner. Du musst dann auf jede VM ein kleines Tool intsallieren das diese Signale aufnimmt und dann, abhängig der Einstellungen, den Server herunterfährt, Suspendet,...
Kostet aber pro Host/Client ordentlich Lizenzkosten...
Klapt genau wie bei physischen Hosts. Es soll aber ein Plugin geben, dass dies auch für einen ESX(i) klappen soll.
@ Glanter:
Je nach Modell kannst du es als Glättung, Unterstützung oder Überbrückung nutzen. So wird sie dann auch geladen oder "Online" gehalten. Stichwort aktiv/passiv USV.
H_M_Murdock
Urgestein
Bei Online USVs läuft der Ausgangsstrom dauerhaft durch den Spannungswandler und die Regelelektronik, d.h. egal was vorn rein kommt (zu viel / zu wenig Spannung, falsche Frequenz) es kommt hinten immer das gleiche raus.
Bei Stromausfall dann eben mit Batterieunterstützung.
Dafür liegt der Wirkungsgrad einer Online USV eben nicht bei 100%.
Dass der ESXi EoL ist stimmt so.
Wurde jetzt mit Version 4.1 auch in "vSphere Hypervisor" umbenannt.
Der Hypervisor ist ja ohnehin der selbe, eine ESXi Installation lässt sich auch mit den "großen" Lizenzen vom ESX betreiben.
Nur die Servicekonsole fehlt dem ESXi.
Bei Stromausfall dann eben mit Batterieunterstützung.
Dafür liegt der Wirkungsgrad einer Online USV eben nicht bei 100%.
Dass der ESXi EoL ist stimmt so.
Wurde jetzt mit Version 4.1 auch in "vSphere Hypervisor" umbenannt.
Der Hypervisor ist ja ohnehin der selbe, eine ESXi Installation lässt sich auch mit den "großen" Lizenzen vom ESX betreiben.
Nur die Servicekonsole fehlt dem ESXi.
pheranos
Neuling
dafür gibt es jetzt doch die VMA, wenn ich das richtig verstanden habe.
underclocker2k4
Mr. Alzheimer
Da bist du falsch informiert.
1. der 4.1er vSphere gibt es/enthält als ESX und ESXi Ausführung
2. die ESX 4.1 ist der letzte ESX den es geben wird
3. es macht also durchaus Sinn jetzt auf den ESXi zu gehen.
Zum Lesen.
VMware: VMware vSphere Blog: ESX 4.1 is the Last ESX! What Do I Do Now?
Ich setze @home ne onlineUSV ein, humlock hat die Gründe genannt. Die USV erzeugt einen 1a Strom und gerade wenn man mehr (teure) HW, sollte man in sowas investieren.
Zuletzt bearbeitet:
H_M_Murdock
Urgestein
Mit wie vielen gleichzeitig laufenden VMs hast du das getestet?
Ich geh davon aus dass man den großen Sprung erst bei mind 5 VMs merkt die halbwegs viel auf der Platte rödeln.
Hatte mal ne ESXi Testumgebung mit AD, Virtualcenter und 3 ESX + 3 ESXi Installationen auf VMWare Workstation rennen und das war auf der 640er Caviar Blue schon allmählich etwas träge.
Mehrere VMs gleichzeitig runterfahren oder starten hat man sich besser verkniffen.
Auf ner 15k SAS HDD gings schon ne Ecke besser.
CeeS
Enthusiast
Moin,
hat denn schon einer von euch Erfahrungen mit SSDs im Serverbereich, speziell unter VMware sammeln können?
Bei uns steht nächstes Jahr ein großes Upgrade an, wo wir planen zwei Server + zwei SAS anzuschaffen, um die via Migration und Failover abzusichern.
Da ich bei unseren Clients mittlerweile auch schon einige SSDs einsetze, würde ich diesen Geschwindigkeitsvorteil erst recht gerne bei den virt. Maschninen einsetzen.
Nun habe ich aber noch im Hinterkopf, dass es da bezüglich RAID, TRIM etc. noch zu Problemen kommen kann. Ist dem noch so oder hat sich da mittlerweile was getan?
Gruß
CeeS
hat denn schon einer von euch Erfahrungen mit SSDs im Serverbereich, speziell unter VMware sammeln können?
Bei uns steht nächstes Jahr ein großes Upgrade an, wo wir planen zwei Server + zwei SAS anzuschaffen, um die via Migration und Failover abzusichern.
Da ich bei unseren Clients mittlerweile auch schon einige SSDs einsetze, würde ich diesen Geschwindigkeitsvorteil erst recht gerne bei den virt. Maschninen einsetzen.
Nun habe ich aber noch im Hinterkopf, dass es da bezüglich RAID, TRIM etc. noch zu Problemen kommen kann. Ist dem noch so oder hat sich da mittlerweile was getan?
Gruß
CeeS
mueder joe
Enthusiast
Es waren glaube 2 VMs die da liefen. Sicherlich wird der Performance-Vorteil mit steigender Zahl der Maschinen höher, aber rein subjektiv sind die 15K Platten da doch erste Wahl. Also 7200er S-ATA < SSD < 15K SAS
Aber mal im Ernst (und auf die Frage mit dem Home-Server bezogen), soviel wird doch von der Sys-HDD nicht geladen wenn die Maschinen erstmal alle oben sind und die Dienste laufen. Und die Daten liegen doch eh auf dem RAID oder dem genannten ZFS Dingens. Das Geld für die SSD würd ich mir sparen
Edit: Ich hätt nicht gedacht dass ich mal sowas sagen würde. Sparen
Also SSD und VMs geht eigentlich sehr gut... Mit steigender Anzahl der VMs knickt die Performance nicht so stark ein wie mit den HDDs. Die Frage ist nur, wie macht sich das auf dauer!?
SSDs sind teuer, richtig teuer, wenns groß sein soll. Nachteil ist auch, Sachen wie TRIM und Co. funkionieren nur unter bestimmten Bedingungen und nicht im Raid...
Für die Lebensdauer ist es wohl auch nicht gerade förderlich... Wobei hier SLC SSDs den deutlich besseren Job machen.
Ich würde dahingehend im Moment noch nix investieren... 15k SAS HDDs haben schon ordenltich Bumms
Ansonsten zum Thema shutdown und USV in ESX Umgebungen... Also man kann das scripten. Wir basteln auf Arbeit aktuell sowas.
Wir fragen die Zustände der USV sekündlich ab und überprüfen die Ladezustände der Akkus. Ab einem bestimmten Zeitpunkt wird dann der shutdown eingeleitet. Das ganze geht dann entweder über SSH Zugriff auf den ESX oder per SNMP.
Wenn das script halbwegs intelligent ist, kann man auch Reihenfolgen und Co. beachten usw.
Selbst externe Storage Arrays, welche per SSH oder wie auch immer erreichbar sind, lassen sich damit ausknipsen, wie natürilch auch physische Server.
Das ganze läuft bei uns als Perl Script. Wird schlussendlich verpackt in eine Ausführbare Datei und läuft als Dienst auf unserem VCenter Server...
SSDs sind teuer, richtig teuer, wenns groß sein soll. Nachteil ist auch, Sachen wie TRIM und Co. funkionieren nur unter bestimmten Bedingungen und nicht im Raid...
Für die Lebensdauer ist es wohl auch nicht gerade förderlich... Wobei hier SLC SSDs den deutlich besseren Job machen.
Ich würde dahingehend im Moment noch nix investieren... 15k SAS HDDs haben schon ordenltich Bumms
Ansonsten zum Thema shutdown und USV in ESX Umgebungen... Also man kann das scripten. Wir basteln auf Arbeit aktuell sowas.
Wir fragen die Zustände der USV sekündlich ab und überprüfen die Ladezustände der Akkus. Ab einem bestimmten Zeitpunkt wird dann der shutdown eingeleitet. Das ganze geht dann entweder über SSH Zugriff auf den ESX oder per SNMP.
Wenn das script halbwegs intelligent ist, kann man auch Reihenfolgen und Co. beachten usw.
Selbst externe Storage Arrays, welche per SSH oder wie auch immer erreichbar sind, lassen sich damit ausknipsen, wie natürilch auch physische Server.
Das ganze läuft bei uns als Perl Script. Wird schlussendlich verpackt in eine Ausführbare Datei und läuft als Dienst auf unserem VCenter Server...
H_M_Murdock
Urgestein
Das übers VCenter zu machen klingt für mich vernünftig, dort hast du von einer Stelle die Kontrolle über sowohl alle VMs als auch alle ESXen.
Wenn du das ganze über Agents auf den ESXen machen willst hast du wieder mehrere Stellen an denen gepflegt werden muss.
Und wenn du anfängst auf jeder VM nen Agent zur USV rennen zu lassen wirst du sowieso wahnsinnig.
Wenn du das ganze über Agents auf den ESXen machen willst hast du wieder mehrere Stellen an denen gepflegt werden muss.
Und wenn du anfängst auf jeder VM nen Agent zur USV rennen zu lassen wirst du sowieso wahnsinnig.
special_fx
Enthusiast
Was passiert wenn einer von 8 RAM Riegeln ausfällt in einem Cluster aus 3 Servern die eigentlich mit vmotion und DRS so konfiguriert sind das es auf einem anderem anderen Server weitergehen sollte. => die Verschiebung der vms bleibt aus alle hosts bringen einen Fehler das etwas mit dem Speicher nicht stimmt 
und das vcenter bekommt es nicht mit das der Speicher des server defekt ist...
Soviel zum Thema Ausfallsicherheit unter ESX 3.5
und das vcenter bekommt es nicht mit das der Speicher des server defekt ist... Soviel zum Thema Ausfallsicherheit unter ESX 3.5
CeeS
Enthusiast
Muss man dafür nicht Failover haben?
Jein... Die Frage ist, wie wurde das genau realisiert. VMotion kann die VMs wärend der Fahrt von einem zum anderen Host schieben...
DRS lässt das ganze aber auch automatisch passieren, sprich normal sollten die VMs bei nem Ausfall des Hosts auf ner anderen Kiste weiter tuckern.
Nur sehe ich das Problem bei den Arbeitsspeichern... Wenn der RAM "nur" Fehler bringt, läuft der Server erstmal weiter. Wird aber unter Umständen nicht das machen, was er soll. Das automatische rüberschieben der VM ansich sollte wohl genau dann eintreten, wenn der Server physisch weg ist, sprich für das VCenter sowie die anderen Hosts nicht mehr erreichbar ist, im RAM Fehlerfall ist er das aber noch. Also sieht das System wohl keine notwendigkeit die VM zu migrieren. Oft ist es auch so, das nicht der komplette RAM Riegel das Problem ist, sondern nur ein Teil davon. Und der ESX selbst verhält sich wie ich mitbekommen habe nur dann kritisch, wenn in seinem ihm zugeteilten Speicherbereich was nicht stimmt.
PS:
fx, du solltest die Server vllt so konfigurieren, das diese dir melden, wenn was mit dem Speicher nicht stimmt.
Sofern die ECC Geschichten greifen, kann man idR bei ordentlicher Management Software SNMP Traps lostreten oder über das Wartungsinterface der Server sogar Mails lossenden usw.
Somit beugst du der Geschichte etwas vor, weil du vorher reagieren kannst um den Server leer zu räumen.
DRS lässt das ganze aber auch automatisch passieren, sprich normal sollten die VMs bei nem Ausfall des Hosts auf ner anderen Kiste weiter tuckern.
Nur sehe ich das Problem bei den Arbeitsspeichern... Wenn der RAM "nur" Fehler bringt, läuft der Server erstmal weiter. Wird aber unter Umständen nicht das machen, was er soll. Das automatische rüberschieben der VM ansich sollte wohl genau dann eintreten, wenn der Server physisch weg ist, sprich für das VCenter sowie die anderen Hosts nicht mehr erreichbar ist, im RAM Fehlerfall ist er das aber noch. Also sieht das System wohl keine notwendigkeit die VM zu migrieren. Oft ist es auch so, das nicht der komplette RAM Riegel das Problem ist, sondern nur ein Teil davon. Und der ESX selbst verhält sich wie ich mitbekommen habe nur dann kritisch, wenn in seinem ihm zugeteilten Speicherbereich was nicht stimmt.
PS:
fx, du solltest die Server vllt so konfigurieren, das diese dir melden, wenn was mit dem Speicher nicht stimmt.
Sofern die ECC Geschichten greifen, kann man idR bei ordentlicher Management Software SNMP Traps lostreten oder über das Wartungsinterface der Server sogar Mails lossenden usw.
Somit beugst du der Geschichte etwas vor, weil du vorher reagieren kannst um den Server leer zu räumen.
Zuletzt bearbeitet:
da "migriert" der aber garnix mehr. wenn das VM image auf einer shared storage liegt dann startet er es auf einem anderen cluster node einfach nur neu. im laufenden betrieb kann ers vm image natuerlich nicht mehr migrieren wenn der esx auf dem es rennt schon unerreichbar ist.
anstaendige server haben gegen ramausfaelle 1. ECC und 2. Memory Mirroring.
da hast dann eine sehr hohe sicherheit gegen ram fehler/ausfaelle.
Start neu, wenn der Host weg ist, ja... Aber wenn er erreichbar ist, kann DRS auch aus Lastverteilungsgründen usw. die VMs rüberschieben. Und wenn er nicht weg ist, was bei nem RAM Fehler ja nicht zwingend sein muss, so greift die Geschichte auch nicht. Logisch...
Alternativ Fault Tolerance nutzen... Das geht dann wirklich Live, weil die VM eigentlich auf mindestens zwei Clusterknoten tuckert und bei Fehlern einfach die Arbeit ein anderer Host übernimmt. Quasi Unterbrechungsfrei...
DRS scheint aber auch ein Enterprise Feature zu sein, sprich FT sollte also auch gehen. Sofern genügend Ressourcen frei sind...
Alternativ Fault Tolerance nutzen... Das geht dann wirklich Live, weil die VM eigentlich auf mindestens zwei Clusterknoten tuckert und bei Fehlern einfach die Arbeit ein anderer Host übernimmt. Quasi Unterbrechungsfrei...
DRS scheint aber auch ein Enterprise Feature zu sein, sprich FT sollte also auch gehen. Sofern genügend Ressourcen frei sind...
special_fx
Enthusiast
Ja, die Server werden von HP Insight Diagnostic überwacht im endeffekt arbeitet es ja wie Nagios.
In dem konkreten Fall als der Ausfall passierte habe ich gerade eine VM auf einen anderen VM Host migriert dabei schlug das ganze plötzlich fehl und ein blick auf die anderen VMs offenbarte die Windowsfehlermeldung, dass es Fehler mit dem Arbeitsspeicher gibt. Die VMs liefen aber soweit weiter ohne Neustarts.
Per Mail kamm ein paar Sekunden später die Nachricht das ein RAM-Riegel auf einem HP DL380G5 ausgefallen sei.
DRS ist so konfiguriert das sobald irgendwas Faul ist oder die Resourcen knapp werden die VMs auf einem anderen VM-Host weiterlaufen
Einzig bitter stößt die Tatsache auf das über das VCenter nicht ersichtich ist das etwas mit dem VM Host nicht stimmt, sprich die Rubrik Arbeitsspeicher blieb grün.
In dem konkreten Fall als der Ausfall passierte habe ich gerade eine VM auf einen anderen VM Host migriert dabei schlug das ganze plötzlich fehl und ein blick auf die anderen VMs offenbarte die Windowsfehlermeldung, dass es Fehler mit dem Arbeitsspeicher gibt. Die VMs liefen aber soweit weiter ohne Neustarts.
Per Mail kamm ein paar Sekunden später die Nachricht das ein RAM-Riegel auf einem HP DL380G5 ausgefallen sei.
DRS ist so konfiguriert das sobald irgendwas Faul ist oder die Resourcen knapp werden die VMs auf einem anderen VM-Host weiterlaufen
Einzig bitter stößt die Tatsache auf das über das VCenter nicht ersichtich ist das etwas mit dem VM Host nicht stimmt, sprich die Rubrik Arbeitsspeicher blieb grün.
therealJMC
Enthusiast
- Mitglied seit
- 14.01.2010
- Beiträge
- 3.730
Kurz am Rande: Bei sowas ists sehr gut Fehlercodes abzufangen... In meiner Ausbildung hat ein damaliger Arbeitskollege was ähnliches geschrieben für Windows-Kisten da wir die APC Clients nicht einsetzen konnten... Er hatte allerdings nicht abgefangen, dass ein falscher Login zur USV auch nen Fehler verursacht. Also haben wir ein paar Monate später mal die ganzen Logins auf den USVen geändert und ein paar Minuten später waren ALLE Server aus....
Ich such auch noch nach ner passenden Möglichkeit wenn unsere neue USV sich nem gewissen Wert nähert die Kisten runterfahren zu lassen... Knapp 1,5 Stunden oder 2 Stunden schafft sie momentan... Mangels vCenter muss ich mir aber noch ne passende Kiste suchen auf der wir das laufen lassen...
Sollte ein RAM-Riegel defekt sein und eine VM deswegen einen Bluescreen bekommen und abstürzen bringt dir FT auch nichts, da der Partner dann auch einen Bluescreen hätte.
FT würde nur helfen wenn der ESX mit einem Schlag ausfällt.
Also für Servervirtualisierung würde ich keine SSDs nehmen. Wie schon geschrieben sind 15k-Festplatten schon recht schnell und haben eine gute Reaktionszeit; bei unseren 12x15k kommt es mir schon recht SSD-like vor
Und wenn du das ganze noch redundant auslegen und an die Übertragunsraten von mehreren 15k-Platten anpassen willst, wird das alles viel zu teuer.
Den einzigen Bereich wo ich einen Sinn für SSDs sehe wäre Desktopvirtualisierung; da packst du das Baseimage, das z.B. von 80 Clients gelesen wird drauf und gut ists. (Wobei es da auch schönere Lösungen gibt; z.B. PAMs bei Netapp).
Was passiert wenn einer von 8 RAM Riegeln ausfällt in einem Cluster aus 3 Servern die eigentlich mit vmotion und DRS so konfiguriert sind das es auf einem anderem anderen Server weitergehen sollte. => die Verschiebung der vms bleibt aus alle hosts bringen einen Fehler das etwas mit dem Speicher nicht stimmt
Soviel zum Thema Ausfallsicherheit unter ESX 3.5
Dann gibt es noch HA (läuft auch unabhänig vom vCenter). Bricht ein Host weg, warum auch immer, wird die VM auf einem verfügbaren Host neu gestartet.
What if my VirtualCenter server crashes?
Zuletzt bearbeitet:
Wenn aber die VM direkt crasht, bringt das nix... Ein Unterbruch ist dennoch vorhanden... Und wie er schrieb ist wohl das Gastbetriebssystem mit einer Speicherfehlermeldung abgeschmiert.