proxmox status

[BigBen]

Hallo,

auf einem Proxmox System habe ich ein Bash Script via Cron-Job regelmäßig aufrufen lassen.

Dieses Script prüft u.a. ob eine gewisse CT-System noch läuft oder nicht. Falls es nichtmehr auf Anfragen reagiert, wird es automatisch gestartet.

Wenn nun aber Proxmox neu gestartet wird, darf das Bash-Script optimaler Weise keine Aktionen mehr unternehmen.

Kennt jemand eine Methode, um via Bash feststellen zu können, ob proxmox aktuell alle VMs und CTs herunterfährt bzw. startet?

LG, BigBen

 

[fireon]

Darf man fragen warum das überhaupt notwendig ist? Vielleicht könnte man es auch anders lösen.

 

[BigBen]

Hallo Fireon,

in der Vergangenheit ist es schon vorgekommen, dass manche CTs nicht mehr reagiert haben. Es betrifft hin und wieder auch andere CT-Systeme. Die Ursachenforschung läuft noch.

In einer CT läuft ein WebProxy. Wenn dieser nicht mehr auf Anfragen von außen reagiert, laufen keine Webseiter mehr. Sämtlich Anfragen zu diversen Subdomains werden vom Webproxy an die entsprechenden Systeme weitergeleitet.

Um eine etwaige Ausfallzeit gering zu halten, wird regelmäßig auf dem Proxmox System via Bash Script getestet, ob das System noch angepingt werden kann. Bei Bedarf wird ein Neustart des CT-Systems durchgeführt.

Nun ist es vorgekommen, dass das Script einen Neustart durchführen wollte, während dessen das Proxmox-System neu gestartet werden sollte. Durch diesen Neustart des CT wurde der Neustart des Proxmox Systems mit einem Fehler abgebrochen.

Erst beim zweiten Anlauf lief der Neustart vom Proxmox-System fehlerfrei durch.

Daher würde ich gerne im Bash-Script den aktuellen Status vom Proxmox-System abfragen wollen.

LG, BigBen

 

[fireon]

Ok, verstehe, ja das ist ein blödes Problem. Ich würde in dem Fall mal zum Support direkt raten. Hab hier doch einige CTs am laufen, superlange Uptime, keine Aussetzter oder ähnliches. Ansonsten viel. doch auf KVM.

 

[BigBen]

Hallo,

bisher betraf es nur einzelne CTs, die einfach mal sporadisch stehen geblieben sind. Nur bei ganz wichtigen CTs, die immer laufen müssen, habe ich eben diese Kontrollfunktion eingebaut.

Eine Lösung wäre, im Crontab die Häufigkeit der Kontroll-Aufrufe zu veringern. Z.B. nur nochalle 5 Minuten. Damit wäre das grundsätzliche Problem noch nicht gelöst,sondern nur etwas hinausgeschoben.

 

[Brawn1]

Hallo,

Ich finde das gar nicht mal so schlecht die Idee von dir.
Vielleicht kannst du es über den derzeitigen Runlevel status erkennen.

z.B.:

if [ "$(runlevel | sed 's/.* //')" = 6 ]; then
  echo "A reboot is in progress"
fi

Dieses Beispiel Testet ob es im Runlevel 6 ist.

Habe es aber selber noch nicht auf Proxmox getestet, da ich gerade unterwegs bin.

LG

 

[BigBen]

Hallo Brawn1,

Dieses Beispiel Testet ob es im Runlevel 6 ist.

das ist eine gute Idee! Darauf bin ich noch gar nicht gekommen.

Habe die Abfrage in das Script eingebaut. Mal sehen, ob dann der ´nächste Neustart fehlerfrei durchläuft.

Werde auf jeden Fall das Ergebnis hier posten. Es kann etwas dauern, bis ein nächster Neustart infolge eines Updates fällig ist.

LG, BigBen

 

[nixmomo]

Nabend,
habt Ihr kein vernünftiges Monitoring?

Wenn ein CT nicht mehr reagiert braucht Ihr doch nicht auf dem Host testen... Macht es doch mit einem vernünftigen Monitoring der prüft ob die Websites noch erreichbar sind und ob die Seite eine bestimmte regex enthält... Bei einem Alarm (Timeout / Status Code aus dem Header) der 3 mal in Folge auftritt kannst du ein Script ausführen lassen was dann den CT neustartet. Wobei ich sicher bin dass ein kompletter CT neustart überflüssig ist.
Habt Ihr mal den Proxy an sich neugestartet wenn dieses Problem auftritt?
Was setzt Ihr als Proxy denn ein?
Und wie äußert sich das "CT reagiert nicht" ?
Ist ein Login via SSH möglich?
Verbrauchen die Kisten einfach mehr Ressourcen als der Host verträgt? HDD defekt?

 

[BigBen]

Hallo nixmomo,

als Proxy wird Apache als CT eingesetzt. Dieses System setzt selten mal aus. Via Bash-Script wird es bei Bard vom Host aus neu gestartet.

Mit diversen Monitoring-Tools (nagios, icinga) habe ich mich bereits befasst. Aktuell Versuche ich check-mk zum Laufen zu bringen. Es soll angeblich automatisch die Systeme finden und viele Sensoren automatisch einrichten können. Bei nagios und icinga ist viel Handarbeit nötig, um alle zu überwachsende Systeme einpflegen zu können.

Die Hardware ist in Ordnung. Es läuft auf dem Host smartmon, der bei Auffälligkeiten sofort eine Mail versendet. Smartmon prüft regelmäßig alle Festplatten auf Auffälligkeiten.

Wenn eine CT-System nicht mehr reagiert, kann es nicht mehr angepingt werden. Auch das aufschalten via SSH funktioniert nicht mehr.

Als Hardware kommt außerdem eine mittlerweile etwas betagte Intel XEON CPU mit einem Server-Mainboard von Asus zum Einsatz. Bei Stromausfällen überbrückt eine APC USV die meistens kurze Zeit, damit das System weiter laufen kann. Hier existiert schon seit langer Zeit eine Baustelle: Bei einem Stromausfall wird Proxmox nicht darüber in Kenntnis gesetzt, um das System herunterfahren zu können. Ursache: APC hat nur ein USB-Anschluß, der an einem Synology-NAS anschlossen ist. Proxmox kann sich leider nicht als Client am USV-Service anmelden, um im Schadensfall über einen Stromausfall informiert zu werden. Rein theoretisch sollte es schon funktionieren. praktisch läuft es allerdings nicht. Eine Problem-Meldung in diversen Foren verlief im Sande. - Abhilfe: Beim nächsten Austausch der USV wird Modell mit LAN-Anschluß genommen, bei dem zuverlässig eine Information versandt werden kann. Diese Modelle sich in der Anschaffung meistens doppelt so teuer, wie vergleichbare Modelle ohne LAN Anschluß.

Nur zur Info: "wir" bestehen aus 1 Mitarbeiter, der ehrenamtlich agiert. Alle Geräte werden von privaten Mitteln gespendet. Kommerzielle Angebote gibt es zwar auch viele, aber diese sind für einen Verein, der sich ausschließlich aus Spendengeldern finanziert, nicht tragbar, da vergleichbare Angebote meist über 130 Euro/Monat kosten.

Auch die Kosten für das Proxmox-Abo wird aus privaten Mitteln beigesteuert, um wenigstens in diesem Forum bei Fehlerfällen eine Unterstützung zu bekommen.

Wenn es eventuell falsch rüber kommen sollte. Trotz aller Probleme mache ich die Arbeit immer noch gerne. Nur ab und zu wünscht man sich einen kompetenten "Mitarbeiter", mit dem man der hier und da mal fachsimpeln und der einen hier und da etwas abnehmen kann. Diesen gibt es aber in unserem Verein leider nicht. So kann ich es nur so gut machen, wie ich es eben kann. Wenn es nicht mehr ausreichen sollte, kann ich immer noch den Ausschalter drücken und alles still legen.

LG, BigBen

 

[BigBen]

Hallo,

wenn das Bash-Script direkt aufgerufen wird, tritt kein Fehler auf.

Sobald es jedoch über einen Cron-Job gestartet wird, kann der Befehl "runlevel" nicht mehr gefunden werden.

Als Abhilfe wurde der Pfad mit angegeben:

/sbin/runlevel

if [ "$(runlevel | sed 's/.* //')" = 6 ]; then
  echo "A reboot is in progress"
fi

LG

 

[robhost]

Das Command "runlevel" ist deprecated und sollte nicht mehr benutzt werden auf Systemen mit systemd.
Die systemd Commands findest du unter https://wiki.archlinux.org/index.php/Systemd#Get_current_targets

 

[BigBen]

Hallo robhost,

vielen Dank für die Info.

 

[nixmomo]

Hallo nixmomo,

als Proxy wird Apache als CT eingesetzt. Dieses System setzt selten mal aus. Via Bash-Script wird es bei Bard vom Host aus neu gestartet.

Ob Apache hier die richtige Software ist?

Aktuell Versuche ich check-mk zum Laufen zu bringen. Es soll angeblich automatisch die Systeme finden und viele Sensoren automatisch einrichten können.

Wo hängt es denn? Check_MK ist very easy und habe ich bei mir nebenbei auch im Einsatz. Es macht allerdings keinen Sinn so ein Monitoring auf dem gleichen Host wie die zu monitorenden Systeme laufen zu lassen. Ein Monitoring kann nicht informieren wenn der Host auch weg ist

Wenn eine CT-System nicht mehr reagiert, kann es nicht mehr angepingt werden. Auch das aufschalten via SSH funktioniert nicht mehr.

Das klingt für mich weniger nach einem CT Problem sondern eher nach einem Host System....
Proxmox ist dann ganz normal verfügbar? Was passiert denn auf dem Host?
Wird hier vielleicht durch ein kurioses Ereignis eine neue Route gesetzt? VPN?

Hier existiert schon seit langer Zeit eine Baustelle: Bei einem Stromausfall wird Proxmox nicht darüber in Kenntnis gesetzt, um das System herunterfahren zu können. Ursache: APC hat nur ein USB-Anschluß, der an einem Synology-NAS anschlossen ist. Proxmox kann sich leider nicht als Client am USV-Service anmelden, um im Schadensfall über einen Stromausfall informiert zu werden.

Braucht man so etwas?

Nur zur Info: "wir" bestehen aus 1 Mitarbeiter, der ehrenamtlich agiert. Alle Geräte werden von privaten Mitteln gespendet. Kommerzielle Angebote gibt es zwar auch viele, aber diese sind für einen Verein, der sich ausschließlich aus Spendengeldern finanziert, nicht tragbar, da vergleichbare Angebote meist über 130 Euro/Monat kosten.

Auch die Kosten für das Proxmox-Abo wird aus privaten Mitteln beigesteuert, um wenigstens in diesem Forum bei Fehlerfällen eine Unterstützung zu bekommen.

Vor so etwas habe ich größten Respekt!! Ich weiß wie hart es ist wenn man sich nur aus Spenden finanziert! Ich möchte hier definitiv gern mehr erfahren und daher wirst du gleich noch eine PN bekommen

LG

 

[fireon]

BTW: Check_MK kann ich auch empfehlen. Wenn man viele Jahre auf Nagios war, ist check_MK ja wirklich sowas von easy

 

[morph027]

Jups, same here. Und ich gebe dir recht, es ist unglaublich sinnvoll, mal mit jemandem über ein Thema zu quatschen. Manchmal verrennt man sich und stellt das dann erst so spät fest, dass wieder ein Haufen Arbeit anfällt, um das aufzuräumen. Aber dafür gibts ja Foren und Chats, etc.

Sind das bei euch schon PVE4 Server und LXC CT's, die da hängen? Wir haben das nämlich auch manchmal (Thread). Es ist besser geworden, aber das Monitoring spuckt immer mal noch rum. Ich nutze aktuell als Indikator (ist nicht die Ursache) die Anzahl der laufen cron Prozesse im Container (Die monitore ich dann mit Check_MK ). Das könntest du bei Gelegenheit mal schauen, wenn wieder was hängt. Ich tippe immer noch auf einen Bug im LXCFS oder irgendsowas, wo dem einfach irgendwelche Handles ausgehen. Denn der Container tut so, als ob er läuft, aber kein Prozess kann noch irgendetwas abschliessen.

 

[BigBen]

Es ist immer besser, eine zweite oder Dritte Meinung einzuholen, bevor man etwas beginnt, wo man sich noch nicht sicher ist, ob es die richtige Lösung ist.
Das eine CT hängt, kommt recht selten vor, aber wenn es vorkommt, dann geht sprichwörtlich nix mehr.

Bislang ist es zum Glück nicht mehr aufgetreten. Scheinbar haben die Entwickler die Ursache zumindest zum Teil beseitigt.