Beiträge von teneco

Ist nicht reproduzierbar: jetzt läuft es ohne Änderungen der Regeln auch wieder mit IPV6. Es lief auch schon 2 Tage vorher. Ich melde mich hier wieder sobald es neuerlich auftreten sollte.

manchmal erreicht der eine Ubuntu Root-Server den anderen nicht mehr über IPV6. Bei dem anderen steht dann im Syslog:

Jul 11 15:40:25 mail kernel: [ 2238.307030] [UFW BLOCK] IN=ens3 OUT= MAC=56:37:f7:ed:7a:45:2c:6b:f5:a0:77:c0:86:dd SRC=2a03:4000:0017:yyyy:0000:0000:0000:0001 DST=2a03:4000:0006:xxxx:0000:0000:0000:0001 LEN=80 TC=0 HOPLIMIT=63 FLOWLBL=180741 PROTO=TCP SPT=52948 DPT=1234 WINDOW=28800 RES=0x00 SYN URGP=0

Auch bei abgeschalteter FW kommen die Pakete dann nicht durch. Ein MTR -6 funktioniert in beide Richtungen.

Nehme ich für die Dovecot Replication wieder die IPV4 Adressen ist alles gut.

Also seit Tagen läuft alles stabil. Auch der neue RS 1000 SAS G7SE 15 years.

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:

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.

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"

Also das mit den Neu- und Bestandskunden verstehe ich noch nicht: nehmen wir die Aktion ".de-Domain 15 years". Da müsste ich doch als Bestandskunde mir eine weitere de-domain für 015€/Monat dazu buchen können. Wähle ich das Produkt aus werde ich auch prompt gefragt ob ich bereits Kunde bin und die domain über das CCP dazu buchen möchte - das CCP kennt dann aber den Aktionspreis nicht. Gilt das Angebot also nur für Neukunden? Dann wäre aber die Beschreibung "Mit den zusätzlichen Domains können Sie Ihr Webhostingpaket, Ihren vServer oder dedizierten Server um weitere Domains erweitern." unglücklich gewählt.

Von mir natürlich auch einen herzlichen Glückwunsch und weiter so!

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?

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.

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

In der letzten Nacht gab es keinerlei erkennbare Probleme. Nach meiner These müsste noch ein weiteres Monitoring dazu gekommen sein weil sich jetzt die SMTP Response Time bei etwa 1s eingependelt hat - sicherlich beeinflusst auch der echte Mail-Verkehr die ganze Sache - deswegen traten die Probleme auch eher nachts auf.

Ich würde auch mit meinem betroffenen RS 500 SAS G7 SE 12M auf ein RS 1000 G7 SE (SAS) migrieren; wenn das so einfach möglich wäre.

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?

Gestern Nacht gab es noch 4 Probleme beim Munin polling: um 1:45, 5:25, 7:30 und 8:50.

In dieser Nacht gab es keine Unterbrechung; das einzige, das ich geändert habe, ist die Frequenz des externen Monitorings von alle 5 Minuten auf minütlich. Das war ja auch schon so, als ich vom heimischen PC ein MTR zum Server laufen liess - auch während dieser Zeit traten keine Probleme auf. Ich werde heute Abend das externe Monitoring unterbrechen - mal sehen ob es wieder Probleme gibt. Eine bestehende SSH-Verbindung schützt nicht vor den Problemen - die wird dann gekappt.

2017/06/12 00:40:19, 02:35:05, 03:35:04

Für das externe Monitoring sollten die Server aber auch nicht irgendwo in Übersee stehen - ich möchte ja die Verfügbarkeit des eigenen Servers testen und nicht die Stabilität irgendwelcher Seekabel.

Zurück zum Thema: heute um 8:25, 10:00, 12:05, 14:00, konnte der eine vServer (v22016114011140388) wieder den anderen (v22016124011141793) nicht erreichen, um seine Munin Daten zu pollen. Wenn ich von meinem PC aus zu beiden Servern eine SSH-Verbindung offen habe friert die zu v22016114011140388 dann immer ein.

Heute Nacht gab es um 3:30 Probleme; es gab wieder ein Problem bei der Munin Abfrage und eine eingehende email wurde zum Alternativ-Server, der mit MX 50 in der DNS Zone eingetragen ist gerouted. Vielleicht treten die Probleme häufiger auf - aber mein Abfrageintervall sind halt 5 Minuten.

In dieser Nacht gab es wieder zweimal Probleme: gegen 23:08 und 3:38.

In den letzten 24 h gab es keine Probleme - weder gibt es intern Streifen in Munin oder meckerte das externe Monitoring.

2017/06/08 05:45:04 [FATAL] Socket read from web.domain.de failed. Terminating process. at /usr/share/perl5/Munin/Master/UpdateWorker.pm line 254.

2017/06/08 05:45:04 [ERROR] Munin::Master::UpdateWorker<domain.de;web.domain.de> died with '[FATAL] Socket read from web.domain.de failed. Terminating process. at /usr/share/perl5/Munin/Master/UpdateWorker.pm line 254.

Betroffen ist bei mir die IP 37.120.173.xxx, NICHT betroffen ist 37.120.169.xxx

Heute Nacht (8.6). traten die Probleme zweimal auf: gegen 1:14 und 5:44 (+-3min). Evtl tritt das Problem auch öfter auf - wird nur nicht erkannt. Es sieht so aus als würde manchmal irgendeine Komponente zu langsam antworten.

auch via IPv4.