Ubuntu Server für Minuten nicht erreichbar

    Quote from teneco

    snip_20170614191616.png


    Also je kürzer das externe Monitoring Intervall desto kürzer ist die SMTP Response Time!?

    Solange ich den Server jede Minute Abfrage liegt die Zeit unter 0,4s. Ab Mittags habe ich das Intervall auf 30 min gesetzt und seitdem klettert die Response Time auf Werte über 7s! Ab 10s treten die Probleme auf. Woran könnte das liegen?

    Ein Schuss ins Blaue: Wird der Dienst häufig abgefragt, ist er im Ram. Bei den längeren Intervallen landet der Prozess im Swap und braucht entsprechend lange, um "aufzuwachen".


    Eine mögliche Erklärung wäre auch, dass bei den kürzeren Intervallen DNS-Abfragen (PTR, …) noch im Cache liegen und es deshalb zu keiner Verzögerung kommt.



    MfG Christian


    PS: Den Rest vom Thread habe ich nur überflogen, ich beziehe mich also ausschließlich auf diese Subfrage.

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)

    Hallo Christian,

    danke für Deinen Schuss ins Blaue, ich bin wirklich für jede Anregung dankbar. Postfix beantwortet ja diese smtp Anfragen. Gegen Deine These spricht, dass zu den Zeiten in denen die Antwortzeiten so hoch gehen auch keine anderen Prozesse so wirklich funktionieren - so setzt ja auch das munin polling in diesen Zeiten aus (von einem anderen "root Server")

    Ich werte das Verhalten von postfix und dovecot aus - aber es sind keine Merkwürdigkeiten zu beobachten. Allerdings läuft der Rechner jetzt auch seit zwei Tagen stabil, die SMTP Response Time liegt zwischen 0,3 und 2s bei einem Abfrageintervall von 30 min, es gibt derzeit auch keine Lücken in den Munin reports.

    Stefan

    Nach mehreren Tagen Ruhe gab es jetzt wieder Probleme. Sowohl das externe Monitoring schlug an als auch der interne Verkehr zwischen zwei vServern auf unterschiedlichen Hosts stockte. Zuerst zum externen Monitoring:


    22.06.2017 01:55:02 Socket timeout after 11 seconds von 212.72.183.125 (Hamburg)

    22.06.2017 01:56:02 Socket timeout after 11 seconds von 193.164.132.46 (München)

    22.06.2017 01:57:02 Socket timeout after 11 seconds von 5.83.128.154 (Frankfurt)

    Um 1:58 kommen wieder Anfragen durch und werden im syslog protokolliert; zwischen 1:55 und 1:58 gibt es im syslog keine Einträge.


    Ähnliches spielt sich um 22.06.2017 02:10:02 ab. Um 2:10:53 gibt es im syslog einen Eintrag der FW, danach ist für 2min Stille.


    Dann um 22.06.2017 02:55:02 für drei Minuten. In der Zeit wurde eine Mail von einem anderen vServer bei NC entgegengenommen, die FW wies Anfragen an die Ports 22 und 23 zurück. Rechner und Netzwerk müssen da eigentlich oben gewesen sein.


    22.06.2017 05:04:02 - nichts besonderes im logfile; cron-jobs werden abgearbeitet


    22.06.2017 08:25:02 - nichts besonderes im logfile; cron-jobs werden abgearbeitet


    Jetzt die missglückten Munin Abfragen zu dem anderen vserver auf einem anderen host:

    00:25

    00:35

    01:05

    01:55 da klemmte auch das ext Mon

    02:10

    02:35

    02:40

    02:50

    02:55

    04:00

    04:10

    05:05

    ....

    08:25 letzter Fehler für heute


    Wie schon weiter oben beschrieben treten die Fehler während eins laufenden MTR (zwischen den vServern oder einem PC und dem Server) nicht auf. Bei wenig Auslastung scheint irgendein Prozess im Swap zu landen - aber welcher und wo? Könnte nicht auch der Host an dem Dilemma beteiligt sein?

    Es widerstrebt mir auch den Rechner permanent zu beschäftigen, nur damit das Problem nicht auftritt.

    Also ich fasse noch einmal zusammen: wenn man meinen "RS500SAS G7" bzw. den Host beschäftigt, z.b. mit einem dauerhaft laufenden MTR funktioniert alles tadellos. Bei Unterbeschäftigung scheint etwas beim Host stehen zu bleiben. Meine Maschine läuft in der Zeit weiter, triggert in der Zeit z.B. ein Cron-Job die Munin-Server SW und versucht diese dann Daten von einem anderen "RS500SAS G7" auf einem anderen Host zu pollen kommt keine Verbindung zustande. Auch externe SMTP- oder HTTP-Anfragen werden zu dieser Zeit nicht beantwortet (erreichen gar nicht den vServer). Diese Blackout-Phasen dauern etwa eine bis drei Minuten - dann kommen Anfragen wieder durch.

    Der zweite "RS500SAS G7", auf einem anderen Host hat diese Probleme nicht.

    Meine Idee wäre es noch einen MTR zu einer anderen virtuellen Maschine auf dem selben Host laufen zu lassen. Wenn dann auch die Probleme in meiner virtuellen Maschine weg wären - dann läge es am Host, oder?

    Guten Abend,

    ich habe seit etwa 1-2 Monaten immer wieder solche Probleme mit meinem "RS 4000 SAS G7S" gehabt.
    Daraufhin habe ich (auch wegen dem Release von Debian 9) gestern den kompletten Server neu aufgesetzt (mit Debian 9 Minimal) und "standardmäßig" eingerichtet. Zudem läuft nur zusätzlich ein kleiner TeamSpeak3-Server.


    Trotzdem hatte ich über die zwei Tage immer wieder zufällige "Ausfälle" von im Schnitt fast einer Minute gehabt. Bemerkbar hat sich das, wie bei Dir gemacht, dass dementsprechend der TeamSpeak-Server nicht erreichbar war bzw. wir alle rausgeworfen wurden und kurz warten mussten bis wir uns wieder verbinden konnten.


    Die Umgebung zeigt sich da relativ ähnlich:

    Sowohl IPv4 als auch IPv6 ist aktiviert, nur etwa 200 MB Arbeitsspeicher werden gebraucht der Load ist im Schnitt auf 0.05, es wird kein Swap gebraucht und Fehler in den Logs sucht man auch vergeblich.


    Ich habe es leider noch nicht geschafft weiterführende Monitoring-Tools einzusetzen, werde das aber noch nachholen und dann noch meine Logs beisteuern.

    Ich weiß jetzt nicht, ob das hier tatsächlich Analogien sind oder ob ich hier nur im falschen Beitrag gelandet bin. Ich wollte nur nicht unbedingt bei bereits ähnlichen Problemen einen weiteren Thread aufmachen.

    Guten Morgen monst12,


    also bei mir läuft die Sache seit dem 29.6. 18:56 stabil ohne weitere Aussetzer. Du kannst ja einfach prüfen ob Du das gleiche Problem hast wie ich: z.B. von dem heimischen PC aus ein MTR (oder winMTR bei Windows) zu Deinem Root-Server. Bei mir reichte auch ein MTR von einem Root-Server zum anderen - während so ein Trace lief gab es bei mir nie Aussetzer.

    Vielleicht habe ich aber auch eine besonders "ruhige IP-Adresse" erwischt: im syslog gibt es tatsächlich Pausen in denen 2 bis 3 Minuten nichts protokolliert wird; bei meinen anderen Root-Servern liefert da alle paar Sekunden die FW irgendwelche Einträge.

    A pro pos Ubuntu syslog: zum Thema PowerManagement findet sich da ein Eintrag: "acpi PNP0A03:00: _OSC failed (AE_NOT_FOUND); disabling ASPM"

    Kann man die Produkte von netcup (KVM-Server) bei solche Problemen überhaupt produktiv einsetzen?

    Es scheint wohl eher an der Infrastruktur von netcup zu liegen, so wie ich es beim Überfliegen der Beiträge interpretiere?

    Ich betreibe seit Jahren mehrere Server bei Netcup, und hatte bisher immer eine hervorragende Erreichbarkeit und keinerlei Probleme dieser Art. Trotzdem frage ich mich natürlich, was ich tun würde, hätte ich auch auf einmal solch unerklärliche Probleme.

    Quote from forum-netcup

    Kann man die Produkte von netcup (KVM-Server) bei solche Problemen überhaupt produktiv einsetzen?


    Es scheint wohl eher an der Infrastruktur von netcup zu liegen, so wie ich es beim Überfliegen der Beiträge interpretiere?

    Also man kann die Produkte von Netcup natürlich produktiv einsetzen!

    Bei der Frage vServer vs. Root muss man sich halt im klaren sein, dass ein vServer eine geringere mind. Verfügbarkeit hat und bedingt durch andere Nutzer evtl. Leistungsengpässe haben kann und das die Systeme halt in der eigenen Verantwortung liegen.

    Sollte es aber Probleme geben kann man diese auch meist mit dem Support lösen.


    Natürlich ist das hier beschriebene Problem nicht gerade trivial und es bisher keine Lösung gefunden aber deswegen die kompletten (v)Serverprodukte von netcup in Frage zu stellen?


    Ich hatte auch schon eimal Probleme mit einem der vServer von Netcup aber diese hielten genau an bis zum Anruf beim Support, dieser hat sofort reagiert und die VM auf einen anderen Node geschoben seitdem bin ich 100% zufrieden mit der KVM...

    Hallo,

    es handelt sich nicht um einen vServer (auch wenn ich ihn so nennen würde) sondern um, wie NETCUP sie nennt, Root-Server (RS500SAS G7). Der Support hat mich ermuntert hier im Forum zu posten; nachdem ich ins Rettungssystem booten konnte und ein MTR problemlos lief war die Antwort vom Support:

    Code
    Ein Netzwerkfehler kann somit ausgeschlossen werden. Am Host-System konnten wir keinerlei Auffälligkeiten feststellen.

Sie besitzen bei uns einen Server. Wir stellen Ihnen die Laufzeitumgebung bereit. Zu individueller Software und zur Einrichtung können wir keinen Support geben. Nach Einrichtung haben wir keinen Zugriff mehr auf Ihr System. Die Einrichtung und Konfiguration Ihrer Dienste und Pflege obliegt Ihrer Verantwortung.

Hilfreiche Tipps finden Sie online und in Fachliteratur. Auch ist für Ihre Fragen unser Kundenforum ein guter Anlaufpunkt, in welchem sich unsere Kunden gegenseitig unterstützen.

    Es ist ein schwer zu findender Fehler. Das ist dummerweise mein Produktivsystem; ich werde jetzt einen anderen Rechner als produktiven neu aufsetzen und dann kann ich auch weitergehende Untersuchung in dem Rettungssystem machen.

    Einen ähnlichen Effekt habe ich auch: So zwischen 0:00 und 4:00 Uhr wir ca. 1 bis 2 Mal jeder Teamspeak-Nutzer vom Server geworfen.


    Ich habe schon den Server komplett von Ubuntu 14 auf 16 portiert (Neuinstallation),

    Ich habe sämtliche Dienste einzeln deaktiviert, das brachte nichts.

    Netcup war so freundlichen, den Knoten auf einen anderen Node umzuziehen - Das Problem bleibt.

    Der Support meinte, dass der Node keinerlei Paketloss verzeichnet, dass scheint also ein Phänomen der Virtualisierungssoftware zu sein...

    Ich nutze IPv4 und IPv6 im Dual Stack, und v6 scheint einwandfrei zu funktionieren.


    Aktuell probiere ich, ob das Problem auch dann auftritt, wenn man nur eine IP verwendet (vorher waren es 2)

    Erstaunlicherweise konnte ich das Problem verstärken, wenn sich zwei Server mittels MTR gegenseitig überprüfen. Dann tritt der Fehler wesentlich häufiger auf...

    Quote from Ringelnatz

    Ich betreibe seit Jahren mehrere Server bei Netcup, und hatte bisher immer eine hervorragende Erreichbarkeit und keinerlei Probleme dieser Art. Trotzdem frage ich mich natürlich, was ich tun würde, hätte ich auch auf einmal solch unerklärliche Probleme.

    Nun hat es auch mich getroffen ... weiteren Server bestellt, letzte Nacht Stretch installiert und einige Dienste migriert. Seit heute morgen dann immer mal wieder kompletter Netzwerkausfall auf der Haupt-IP sowie Failover.

    Code
    64 bytes from xx.xx.xx.xx: icmp_seq=208 ttl=58 time=28.906 ms
64 bytes from xx.xx.xx.xx: icmp_seq=209 ttl=58 time=28.770 ms
64 bytes from xx.xx.xx.xx: icmp_seq=210 ttl=58 time=28.882 ms
64 bytes from xx.xx.xx.xx: icmp_seq=211 ttl=58 time=29.535 ms
Request timeout for icmp_seq 212
[...]
Request timeout for icmp_seq 226
64 bytes from xx.xx.xx.xx: icmp_seq=227 ttl=58 time=28.805 ms
64 bytes from xx.xx.xx.xx: icmp_seq=228 ttl=58 time=28.993 ms
64 bytes from xx.xx.xx.xx: icmp_seq=229 ttl=58 time=28.703 ms

    Die Antwort vom Support ist natürlich "ab ins Rettungssystem und MTR anfertigen" was nicht geht, da die Dienste erreichbar sein müssen. Wird man denn einfach so auf Wunsch auf einen anderen Node umgezogen oder wie habt ihr das gemacht?

    Quote from Ringelnatz

    Die Antwort vom Support ist natürlich "ab ins Rettungssystem und MTR anfertigen" was nicht geht, da die Dienste erreichbar sein müssen. Wird man denn einfach so auf Wunsch auf einen anderen Node umgezogen oder wie habt ihr das gemacht?

    Einfach so geschieht das nicht.

    Ich habe zuerst die Logbücher meines Servers untersucht und versucht, Fehler einzukreisen. Damit konnte ich "beweisen", dass der Server komplette Aussetzer hat, und nicht nur ein Dienst spinnt.

    Danach habe ich eine Anfrage an den Support gestellt, ob sie erkennen könnten, dass der Server Aussetzer hätte, oder ob ich testweise auf einen anderen Node portiert werden könnte. --> Da die Netzwerkverbindung zu 100% ok war, wurde ich dann auf einen anderen Node umgezogen --> Das Problem blieb bestehen.


    Testweise habe ich nun alle IP-Adressen bis auf die Haupt-IP entfernt, den Server neu gestartet, und seitdem läuft der Server ohne Ausfälle.

    Es scheint also eine Inkompatibilität zwischen der Virtualisierungsumgebung und Ubuntu (14 und 16, egal) zu sein...


    Es scheint auch keinen Unterschied zu machen, ob man die mehrfachen IPs per Alias (ens3:1) oder direkt an die Netzwerkkarte (ip address add ip/32 dev ens) bindet -> Die Fehler treten bei mir mit mtr Recht schnell auf, sobald eine zusätzliche IP verwendet wird...

    Seit ich mtr laufen lasse gab es bei mir seltsamerweise keine Ausfälle mehr. Die Failover-IP, die ich neben der Haupt-IP auf dem Server habe, kann ich leider nicht entfernen. Aber ähnliches Verhalten haben hier ja schon Mehrere beschrieben, wäre echt interessant zu wissen ob es einen Zusammenhang gibt und weshalb.

    Ich pinge den betroffenen Server aktuell von meinem heimischen Rechner aus (das gibt mir direkt ein akustisches Signal wenn er nicht erreichbar ist). Dabei ist gerade folgendes aufgetreten:

    Code
    64 bytes from xx.xx.xx.xx: icmp_seq=716 ttl=58 time=29.293 ms
64 bytes from xx.xx.xx.xx: icmp_seq=717 ttl=58 time=29.172 ms
36 bytes from gw01.netcup.net (46.38.224.33): Time to live exceeded
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst
 4  5  00 5400 94c6   0 0000  01  01 4d24 192.168.2.108  xx.xx.xx.xx

Request timeout for icmp_seq 718
Request timeout for icmp_seq 719