Allgemein: nginx Autorestart, Ausfallwahrscheinlichkeit, Erfahrungen

[ServerSide]

Hallo.

Ich habe mir für mein Django Projekt einen vServer geholt und diesen entsprechend konfiguriert (nginx + gunicorn + Postgres + Django auf Python3 in einer virtualenv)

Das ganze läuft auch Alles und ich bin gerade dabei ein bisschen herumzuexperimentieren. Dabei kamen aber ein paar allgemeine (und vielleicht dumme) Fragen auf, die ich hier gern mit Euch diskutieren würde:

Für Gunicorn wird geraten es mit Supervisor(d) zu starten, weil es öfter mal vorkommen kann, dass Gunicorn sich aufhängt und neugestartet werden muss. An sich ja kein Problem.

1. Was aber ist mit Sachen wie nginx und Postgres? Sollte ich diese dann auch mit Supervisor o.ä. verwalten?
2. Wie machen es denn die Profis? nginx einfach starten und hoffen dass er nie abschmiert oder ebenfalls über Supervisor und Konsorten?
3. Was sind denn Eure Erfahrungen? Sind Abstürze überhaupt ein Problem? nginx und Postgres dürften inzwischen ziemlich stabil sein, aber wenn ich mal nen Tag unterwegs bin und nginx abschmiert, sollten schon etwaige Automatiken greifen und den Dienst neustarten, damit der Server wieder erreichbar ist. Oder ist das einfach das Risiko das man als Server-Betreiber hat?

So, das war's erstmal.

Vielen Dank schonmal für Eure Tipps und Ratschläge!

 

[storvi]

PostgreSQL automatisch irgendwie restarten halte ich für eine ganz schlechte Idee. Bei der DB will man eigentlich immer Wissen, warum etwas fehlschlägt. Monitoring ist hier die besser Wahl...

Wir lassen PostgreSQL "einfach laufen" und überwachen mit einem Monitoring-Tool, ob die Datenbank oben ist.
Von selbst schmiert da nichts ab. Wenn du dafür sorgst, dass die Platte nicht volläuft oder irgendwelche anderen Prozesse gegen PostgreSQL schießen ist das "rock solid".

Bei nginx habe ich bisher eigentlich immer nur manuell restarten müssen (nach einem Update, Konfigurationsänderungen...). Wenn du hier eine Überwachung mit automatischem Restart möchtest kann ich dir das Tool monit ans Herz legen. Da kannst du beliebige Tests einbauen und restarts versuchen und zur Not wirst du per E-Mail benachrichtigt.

Gruß
Markus

 

[marce]

Welches OS läuft denn auf dem Server? Sollte da schon systemd verwendet werden wäre ein automatischer Restart von Services AFAIK in den Features enthalten und müsste ggf. nur noch konfiguriert werden - dann kannst Du Dir externe Tools zumindest für den Komplett-Absturz sparen.

Wobei ein gutes Monitoring nicht schadet - es gibt ja auch noch andere Fälle für notwendige Aktionen jenseits von "der Prozess läuft nicht". Ob das nun monit oder ein lokales Shell-Script per crond ist würde ich von den jeweiligen Anforderungen und Möglichkeiten abhängig machen.

 

[ServerSide]

Danke erstmal für Eure Eindrücke.

Im Moment habe ich FreeBSD 10.3 und Debian 8 in meinen VMs und spiele damit rum. Der Unterschied ist ja gar nicht so groß, aber dass ich direkt mit onboard-Mitteln (SystemD) meine Prozesse (durch Restart=Always) automatisch neustarten kann wäre schon nett.

Wenn ich aber pf mit iptables vergleiche, bin ich schnell wieder von FreeBSD begeistert. haha.

Die Tendenz geht jetzt im Moment zu Debian. Dort ist selbst gunicorn in den Repos und wird dann bei Updates auch von den Scripten aktuell gehalten.
Ansonsten sshd absichern, nginx nach den best practices einrichten und dann sollte es eh keine allzugroßen Probleme geben.

Habt Ihr noch spezielle Tipps zu FreeBSD, Debian oder der Thematik allgemein?

 

[elias5000]

Für Gunicorn wird geraten es mit Supervisor(d) zu starten, weil es öfter mal vorkommen kann, dass Gunicorn sich aufhängt und neugestartet werden muss. An sich ja kein Problem.

Bitte was? Kein Problem? Eine Software, die dafür bekannt ist, hin und wieder mal getreten zu werden, damit sie es weiter tut ist ein absolutes No-Go.
Die Services, die du sonst so aufzählst gehören zu der Gattung derer, die man benutzen kann - sie laufen also durch außer sie sind schlimm fehlkonfiguriert. Aber dagegen hilft auch kein Neustarten sondern nur Monitoring und Logging.

 

[ServerSide]

Beim einrichten von Monit ist mir gerade aufgefallen dass es per PID files arbeitet. Funktioniert das denn 100%? Wenn ein Prozess abstürzt und somit keine Gelegenheit mehr hat das PID file zu löschen, wird dann der Prozess in Monit weiter als laufend angezeigt?

Oder ist systemd da schlauer und merkt das ganze und löscht dann die PID file?

 

[PHP-Friends]

Wir nutzen monit ebenfalls exzessiv, da gerade sowas wie ein Apache-Crash alle X Wochen auf einem Shared-Hosting-Server durchaus "mal vorkommen darf" und ein Eingreifen von monit mit 15 Sekunden Prüfintervall einfach schneller ist, als wir es sein könnten, wenngleich wir auf Störungen 24/7 binnen < 2 Minuten reagieren (da ist ja noch nichts *gelöst*). Auf PID-Files verlassen wir uns da nicht, wir benutzen immer die relativ umfangreichen Checkmöglichkeiten die monit bietet. Insbesondere bei einem MySQL bringt es dir noch nicht einmal etwas, den Port TCP-zu-checken, da z.B. die Verbindungen voll sein könnten. Daher sollte immer die eigentliche Applikationsfunktionalität geprüft werden.

(Wobei MySQL ein schlechtes Beispiel ist, da insbesondere das ein Service ist, wo händisches Eingreifen anstelle automatisierten Draufhämmerns gut und gerne größeren Schaden verhindern kann.)


Viele Grüße
Tim

 

[ServerSide]

Ah OK. Vielen Dank für Eure/Deine Antwort. Ich dachte mir schon dass das mit den PID files etwas heikel sein könnte. Hab auch ein wenig gegooglet ob systemd nicht einfach die pid files löscht nachdem ein prozess gecrasht ist. Dazu habe ich aber leider keine Antwort gefunden.

In der offiziellen monit FAQ habe ich aber das hier gefunden:

Q: If a program crashes without removing its pid file, will monit recognize that the program is not running?
A: Yes, Monit will always check that the pid number in a pid file belongs to a running process. If a program crashes and dies in a "normal" manner, then the process ID (pid) will not exist and monit will know that the program is not running and restart it even if a pid file exist. Some servers can crash and leave a zombie process, and appear to run. Monit also test for zombie processes and will raise an alert if a process has become a zombie.