Unwahrscheinliche Hardwaredefektmeldung auf versch. Hosts

[k0kett]

Hallo, ich habe folgendes Problem mit unseren Servern:

Erst einmal zum Aufbau, wir haben 3 Hostserver auf welchen ESXi 5.0.0 läuft. Auf diesen Servern laufen diverse VMs die unterschiedliche Anforderungen haben.
Seit kurzer Zeit haben wir nun aber das Problem, dass ein Hostserver über Nacht in unregelmäßigen Abständen ausfällt. Wir haben zuerst auf ein Hardwaredefekt spekuliert, da der Host dies auch immer ausgab, wenn ich morgens im Serverraum nach dem Problem gesehen habe. Daraufhin haben wird die VMs von dem Host gezogen und vorübergehend auf die anderen beiden verteilt. Leider musste ich heute feststellen, dass auch dieses Blade heute Nach ausgefallen ist, mit der selben Nachricht (Hardwaredefekt). Einen Hardwaredefekt auf beiden Blades kann ich mir eigentlich nicht vorstellen, sodass der Fehler eigentlich irgendwo anders liegen müsste.

Kann mir da jemand einen Tipp geben, wo ich am besten nachsehen kann, was genau zu dem defekt geführt hat, wann es aufgetreten ist und was davor passiert ist?

[MarcelMertens]

Wie wäre es denn wenn du uns erzählst was für eine Art Hardwaredefekt das Problem ist und wie sich dieser Bemerkbar macht.

[kastlr]

Hallo und willkommen im Forum,

ein paar mehr Informationen dürften es schon sein.

Du kannst ja mal mit folgendem Befehl versuchen, den "Fehlerspeicher" deiner Blades auszulesen (sofern dies unterstützt wird)
localcli hardware ipmi sel list -r -i -n all

Alternativ kannst du ja mal in den vmkernel Logs stöbern, ob die/der Server vor dem Crash ein Problem gemeldet hat.

Gruß,
Ralf

[k0kett]

Ich merke es daran, dass die Server nicht erreichbar sind und spätestens dann wenn ich im Serverraum bin und mir der pinke Bildschirm entgegen lächelt mit dem Hinweis, dass es einen Hardwaredefekt am Mainboard gab. Aber dies auf 2 von 3 Hosts? Meiner Meinung eher unwahrscheinlich.
Leider sind beide Logs nicht wirklich aussagekräftig und der Befehl wird aufgrund von fehlendem IPMI nicht unterstützt.

[Supi]

Dann schreibe doch mal was zu den technische Details der Blades und der Version des ESXi 5. Da gibt es ja auch schon einige Updateversionen.

[k0kett]

Es sind 3 HP ProLiant BL400c Server Blades mit jeweils zwei Quadcores von Intel, 32 GB RAM und Anbindung an ein iSCSI NAS, auf welchem die VMs liegen.
ESXi 5.0.0 (469512) läuft derzeit darauf und wie gesagt, besteht das Problem erst seit kurzem, häuft sich mittlerweile aber.

[Supi]

Am besten dann wenigstens mal den PSOD "abfotografieren". Und 469512 ist ja auch nicht gerade die aktuellste Version.

[skneo]

Also wenn es plötzlich kommt und dann auch auf den anderen Blades kann man schon von einen Hardware Defekt ausgehen, an der Software wurde ja nichts geändert wenn ich dich richtig verstanden habe.

Bei HP gibt es doch so Spezial Diagnose Software für die Teile einfach mal durchlaufen lassen.

Was sagt denn das Management vom Blade steht da etwas im LOG. Wurde im NAS oder im Switch was gefunden.

http://kb.vmware.com/selfservice/micros ... Id=1004250

Am besten mal den Fehler Posten

[weigeltchen]

Switches und/oder NAS sollten mal unter die Lupe genommen werden. iSCSI ist sehr empfindlich, was die Verbindung angeht. Mgl. heftiger Traffic des Nachts wegen backup? Mir sind LUN's auch schon weggeflogen und haben einen POSD produziert.
Da der TE nichts von einem vCenter erwähnt, nehme ich an, daß der Hypervisor zum Einsatz kommt. Ansonsten ohne genauere Fehlerbeschreibung bleibt es beim Kaffeesatzlesen.

[k0kett]

Richtig, über die Nacht werden von allen VMs Backups mittels VDR gezogen. vCenter ist auch im Einsatz.

[Supi]

und an dem Backup-Job oder der VDR Version wurde nichts geändert? Läuft das VDR sauber durch?

[k0kett]

Es wurde an den Maschinen und deren Einstellungen seit längerem nichts mehr geändert, daher steh ich ein wenig aufm Schlauch.
Die VDR Version ist ebenfalls die selbe, läuft aber zur Zeit nicht immer ganz rund und spuckt desöfteren Integritätsfehler, die dann aber wieder behoben werden können.
Hier noch die Logs von der Zeit vor dem Crash: http://pastie.org/pastes/8003990/text?k ... wpazvvoeuq

[Supi]

VDR ist leider eine kleine Diva. Ist Version 2.0 oder 2.01 im Einsatz?

https://www.vmware.com/support/vdr/doc/ ... lvedissues

Resolved Issues:
Recatalog/Integrity Check Fails Frequently
Allow the CleanHouse process to clear orphaned data nodes that have data check issues

Nach meiner Erfahrung mit VDR half bei den gehäuften Integritätscheck's nur ein kompletter "Reset" sprich neuaufbau des Repository. Also alles auf de CIFS? Share löschen und neu anlegen lassen. Wobei der erste Lauf dann durchaus Tage? dauern kann. > WE.

Zumindest ist im Log auch viel von CBT zu lesen, und das nutzt das VDR intensiv. Trotz allem würde ich ebenso die Host + das Vcenter zumindest auf U2 hochziehen.

Was für ein ISCSI NAS ist das nun eigentlich?

Und auf welche Größe ist der VDR Speicher begrenzt? Denn bei z.B. möglichen 1TB Speicher wächst das Repository auch so groß an und dafür ist es dann wohl nicht ausgelegt. Daher kann es auch eine weile gut gelaufen sein und erst nach einer weile Probleme geben.

[weigeltchen]

Mich würde nicht wundern, wenn als nächste Info kommt, daß die backup-repositories ebenfalls auf dem NAS liegen.

[k0kett]

Das neu aufsetzen, des VDRs hatte ich schon eine ganze Weile vor, jedoch kam ich bisher noch nicht dazu und hab es immer wieder vor mich hingeschoben, da es dann doch wieder lief.
Ein Wocheende zum allgemeinen Update ist schon in Planung, da auch ein paar der Server geupdatet werden sollten.
Soweit ich das sehe, liegen die Backups auf einem anderen NAS, leider hab ich die Konfiguration der ganzen Geschichte nicht selbst vorgenommen und das ganze System mehr oder weniger im laufenden Betrieb von heut auf morgen übernommen und mir bisher nur einen groben Überblick verschafft, was sich wohl rückwirkend als Fehler herausstellt.
Nach einer Migration der VMs zum Lastausgleich und Sicherstellung des verfügbaren Speichers, kann nun leider das VDR nicht mehr auf seine zweite Festplatte via Direktzugriffs-LUN nicht mehr zugreifen, was natürlich für weitere Nachforschungen und Arbeiten ein wenig kontraproduktiv ist. Der Host hat definitv Zugriff auf die vmdk, jedoch die VM scheinbar nicht wirklich, was den Start unmöglich macht.
Der Speicher des VDRs ist in der Tat schon sehr groß geworden und nimm mittlerweile scheinbar schon knapp 1TB ein, könnte dadurch eine Überlastung des Servers beim Backup-Job auftreten, welcher den Crash verursacht haben könnte?

[Supi]

Deine Infos sind nicht gerade zielführend:
Also nochmal :
- HW des Storage wo die VM's liegen.
- VDR scheibt auf CIFS oder VMDK? (CIFS max 500GB nach Vmware, VMDK 1TB)
- Welche genaue VDR Version? Bei 2.01 müsste die VM 4GB Ram haben.

siehe Releasenotes 2.01:

VDR Virtual Appliance Did Not Have Enough Memory

VDR 2.0 had the following default memory settings in the virtual appliance:

Memory – 2GB
Open fd ulimit – 1024

This was causing file opens to fail and operations to run slower in large backup configurations. In VDR 2.0.1, these settings have been revised to:

Memory – 4GB
Open fd ulimit – 8192