 Thema: Ausfall von ruri, titan und nagare: 2007-09-0[45] |
|
|
Die Opennet-Server ruri, nagare und titan wurden am Nachmittag vom 2007-09-04 (ca. 16:45) zusammen mit dem ueberwiegenden Teil der Computer-Infrastruktur vom IFI/RZ der Universitaet Rostock (inkl. dns-, mail- und webservern fuer informatik.uni-rostock.de) abgeschaltet.
Es gab dazu meines Wissens nach vorher keinerlei generelle Warnung per mail. In den betroffenen Gebaeuden selbst hingen folgende Zettel aus:
https://www.opennet-initiative.de/galler...ageViewsIndex=1
https://www.opennet-initiative.de/galler...ageViewsIndex=1
Diese wurden anscheinend von keinem Opennet Mitglied ausreichend frueh wahrgenommen, um vor dem Ausfall eine Warnung auszusprechen oder services auf andere Systeme auszulagern.
Durch diesen Ausfall wurden lahmgelegt:
auf nagare:
- einer der zwei zentralen UGW-vpn server
titan:
- ein Internet-gateway an zentralem Standort
- die von alfredi generierten Karten mit LQ-Infos
ruri:
- dieses Forum
- das ON wiki
- die ON mailing-listen
- der ON IRC server
...also alle zentralen Kommunikationsmedien des Opennet.
Alle diese services sollten inzwischen wieder funktionieren.
Auch irgendwann ausgefallen, und bis jetzt nicht funktionsfaehig sind:
- die von der Universitaet zur Verfuegung gestellte Glasfaserleitung zwischen dem IFI und der Opennet-Installation in der Ulmenstrasse
- ein low-packetloss Link zwischen dem IFI und der HG Kirche
|
|
| Thema: 2007-02-23 14:00 - 2007-03-01 17:15 unplanned Titan downtime [Erledigt] |
sh01
| Antworten: |
30 |
| Hits: |
2.919 |
|
|
Titan ist inzwischen wieder weitgehend da. Routing, dsl, openvpn und der httpd sollten richtig funktionieren. Ein named laeuft momentan nicht auf dem System, das sollte aber unkritisch sein; im Zweifelsfall dafuer 139.30.241.8 (nagare) benutzen, das System liegt physisch und topologisch direkt neben titan.
|
|
| Thema: 2007-02-23 14:00 - 2007-03-01 17:15 unplanned Titan downtime [Erledigt] |
sh01
| Antworten: |
30 |
| Hits: |
2.919 |
|
|
Die urspruengliche Installation hat afaict bleibenden Schaden genommen; das System erzeugte bereits waehrend des bootens OOPSes.
Da diese Installation des Weiteren alt und recht chaotisch (Mandrake...) war, hat das System jetzt eine neue (Debian) bekommen. Diese laeuft momentan ok, und remote administration funktioniert auch bereits. Es sollte jetzt mit brauchbarem Aufwand moeglich sein, die Hauptfunktionen des Systems wiederherzustellen; ich arbeite daran.
Die Daten auf der frueheren root-hd sind weitestgehend erhalten geblieben; mit bedeutendem Datenverlust ist nicht zu rechnen.
Der urspruengliche Grund fuer die Probleme ist weiterhin unbekannt. Ich werde die Hardware von der neuen Installation aus einigen Tests unterziehen.
|
|
| Thema: 2007-02-23 14:00 - 2007-03-01 17:15 unplanned Titan downtime [Erledigt] |
sh01
| Antworten: |
30 |
| Hits: |
2.919 |
|
|
Der userspace auf dem System ging um ca. 2007-02-23 14:00 in voellige Katatonie; kurz danach war auch die DSL-Verbindung down. Inzwischen antwortet das System nicht einmal mehr auf ARP requests.
Die Problemursache ist momentan unbekannt; eine Behebung wird aber mindestens einen hardware-Reset erfordern.
|
|
| Thema: 07.01.2007 - VPN-Probleme zu nagare via User-Gateways [Erledigt] |
sh01
| Antworten: |
51 |
| Hits: |
4.380 |
|
|
| Zitat: |
| Was mich hier stoert, ist das !eth2, was offensichtlich ohne Anpassung an die lokalen Bedingungen von Titan uebernomme wurde. |
Wurde es, das ist hier aber nebensaechlich. Der Teil der rule hat nur einige der log messages die beim dropping verursacht wurden, gegagged, weil das uni-netzwerk an titan's eth2 haeufiger matchenden Muell geschickt hatte; nagare hat kein eth2, also werden diese DROPs hier einfach immer gelogged.
Wie man den Regeln ansieht, dropped der sanity-checks Aufbau IP packets, die angeblich von einer non-global IP range kommen, und ueber ein lokales physisches Interface (das ist bei nagare nur eth0) empfangen wurden. Das ganze ist ein rudimentaerer Schutz gegen extreme Varianten von source address spoofing.
Es ist mit an Sicherheit grenzender Wahrscheinlichkeit nicht fuer die aktuellen Probleme verantwortlich; und wenn es verantwortlich waere, wuerde es syslog Eintraege dazu geben.
| Zitat: |
| Jan 7 07:51:35 nagare kernel: [18898818.420000] martian source 192.168.2.27 from 192.168.0.251, on dev tap_pgs |
Der kernel wirft hier aufgrund von internen sanity checks (i.e. separat von dem Zeug, das ich mit netfilter gebaut habe) ein ip-frame weg...src-addr 192.168.0.251, dst-addr 192.168.2.27, auf device tap_pgs. Sehr gut dokumentiert sind diese messages nicht. Anscheinend werden sie messages normalerweise fuer Faelle generiert, in denen das angegebene device input-device des erwaehnten packets ist.
Wenn das hier wirklich der Fall ist, waere das Problem hier wahrscheinlich eine kurzzeitige routing-loop, in der nagare von sich selbst geschickte Packets zurueckgeroutet bekommt.
Wenn tap_pgs nicht das echte input-device ist, ist das Packet wahrscheinlich lokal generiert. Ich habe diesen Fall nicht wirklich durchdacht; lokaler Output von 192.168.0.251 ueber tap_pgs funktioniert normalerweise, wenn diese Addresse erst von der relevanten DNAT rule gesetzt wird - und das ist eigentlich die einzige vernuenftige Moeglichkeit fuer so ein Resultat.
Sniffer logs des fuer die martian-source verantwortlichen Traffics zu haben, wuerde wahrscheinlich etwas bei der Problemisolierung helfen.
Ich habe momentan keine konkrete Vorstellung darueber, wie eins der genannten Probleme fuer die erwaehnten Symptome verantwortlich sein koennte; aber allein als Anomalie ist es wahrscheinlich eine weitere Untersuchung wert.
|
|
| Thema: 25.09.2006 - nagare olsrd Abstürze [Erledigt] |
sh01
| Antworten: |
62 |
| Hits: |
5.124 |
|
|
Habe ich nicht; allerdings laeuft die jetzige olsrd Instanz afaict gut. Bitte nicht ohne guten Grund neustarten, ich will weiter beobachten ob meine fixes funktionieren.
|
|
| Thema: 25.09.2006 - nagare olsrd Abstürze [Erledigt] |
sh01
| Antworten: |
62 |
| Hits: |
5.124 |
|
|
| Zitat: |
| nagare hängt leider schon wieder. |
Dass lag daran, dass der olsrd Prozess nicht wirklich gestorben war, sondern nur unbenutzbar wurde. Dafuer hat er mir dabei einiges an guten debug-Daten hinterlassen.
Mal sehen, ob es noch weitere Probleme gibt.
|
|
| Thema: 25.09.2006 - nagare olsrd Abstürze [Erledigt] |
sh01
| Antworten: |
62 |
| Hits: |
5.124 |
|
|
| Zitat: |
| PS: Ich haenge dieses Thema direkt an den Thread mit dem Nagare-OLSR Problem (das war nun sicher die Ursache). |
Aus aktuellem Anlass, weil es jetzt auch schon titan betrifft, und ich immernoch keine Anmeldung bei olsr-dev hingekriegt habe, hier mal eine kurze Skizze des Problems:
Olsrd hat drei wesentliche und fuer den Bug relevante interne Datenstrukturen: neighbortable, link_set und ein mapping von MID-Addressen auf die main Addressen der jeweiligen Nodes.
Der eigentliche crash findet in create_lq_tc() statt. Die Function geht die neighbortable durch, und sucht sich zu jedem Eintrag den besten direkten link basierend auf der main-address des Nodes. Dabei geht es davon aus, dass zu jedem Node in neighbortable auch ein Eintrag in link_set existiert. Der olsrd code haelt diese Invariante afaict zuverlaessig ein.
Leider kommt es u.U. vor, dass der Eintrag in link_set trotzdem nicht gefunden wird, weil die main address des Nodes (die direkt in der neighbortable steht), inzwischen ebenfalls als sekundaere (MID) addresse in der MID table steht, weil olsrd ein olsr-packet bekommen hat, das sie als solche deklarierte; entweder vom relevanten node selbst (weil es seine main address geaendert hat), oder von einem anderen (mis-config?). In dem geloggten Beispiel war es wohl der node selbst. Die dazugehoerige main address hat dann u.U. trotz dem Verweis auf sie in der MID table keinen Eintrag in link_set.
Zu crashen ist definitiv nicht das richtige Verhalten. Ich bin mir nicht sicher, wo oder wie genau die Situation korrekterweise abgefangen werden sollte. Aufgrund des Endes der vorlesungsfreien Zeit habe ich auch momentan kaum Zeit, mich weiter damit zu beschaeftigen.
|
|
| Thema: 17.10.2006 - GW254 / Titan down 16:04 - 18.10.2006 16:17 [erledigt] |
sh01
| Antworten: |
12 |
| Hits: |
1.683 |
|
|
Laut dem Syslog schien der Host am Anfang der downtime (laut titan's sysclock 15:50) ein regulaeres shutdown durchzufuehren; ein Grossteil der userspace-daemons haben sich nacheinander als Reaktion auf SIGTERMs (zumindest einige von denen kamen wohl von den rc scripts) beendet.
Anscheinend war die ursache dafuer ein 'poweroff' auf einer bash. K.A. welche natuerliche Person das geschickt hat, oder warum.
|
|
| Thema: Wie ist die Leistung von ugws? |
sh01
| Antworten: |
125 |
| Hits: |
10.004 |
|
|
| Zitat: |
| Also direkt mit Nagare hat es wohl nicht zu tun. Wenn man sich außerhalb des ON mit Nagare verbindet bekommt man auch ganz passabele Wert (130-150kb/s) hin. |
Zumindest manchmal. Ralph und ich haben das noch etwas weiter getestet, und Resultate erhalten, die auf ein recht komplexes Problem schliessen lassen.
Die recht klaren Bedingungen fuer ein Auftreten des Performance-Problems sind:
1. Nagare muss den traffic forwarden (Nagare selbst als Endpunkt (auch bei Verbindung durch vpn) zeigt das Problem nicht)
2. Es muss geroutet werden, und wahrscheinlich auch durch openvpn (forwarden durch separate tcp sockets (via socat) zeigt das Problem nicht)
Des Weiteren gibt es gewisse Abhaengigkeiten von der client Verbindung. Ralph sieht auf einer 6mbit Leitung keinen kritischen Performance-Einbruch, ich sehe auf 2mbit downstream ADSL einen...aber nur wirklich hart, wenn der Zielhost ausreichend schnell ist. Von einer Quelle die selbst nur ca. 110kb/s schafft kann ich auch ueber nagare mit ~100kb/s Daten laden, wobei es auch hierbei kurzzeitige aber starke Einbrueche gibt, die nicht in dieser Groessenordnung auftreten sollten - bei Quellen, die bei direkten Verbindungen mein ~231kb/s DSL auslasten, kriege ich ueber Nagare Durchschnittswerte von 63kb/s bei laengeren Verbindungen.
Dieser Faktor koennte "client-downstream ist Flaschenhals bei der Verbindung" sein, aber ich bin mir weiterhin nicht sicher. Es sieht fuer mich inzwischen ein bischen nach einer pathologischen Interaktion des TCP algorithmus zum backoff bei Packetloss mit einem openvpn-endpoint in der Mitte einer TCP-Verbindung aus, aber ich habe noch keine konkrete Theorie dazu.
|
|
| Thema: Wie ist die Leistung von ugws? |
sh01
| Antworten: |
125 |
| Hits: |
10.004 |
|
|
| Zitat: |
| Is vielleicht bei uns ein derartiges Verbose-Level gesetzt??? |
Nein. opennet_users ist auf verb 1, opennet_ugw auf verb 3. Des Weiteren bringt ein download von ap46 durch den ugw tunnel momentan auch ueber 260kb/s.
Ich kenne die Ursache des Problems nicht. Nagare hat definitiv zu einigen hosts (e.g. www.kernel.org; http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.18.tar.bz2 bringt mir konsistent unter 150kb/s) ungewoehnlich niedrige Uebertragungsgeschwindigkeiten, aber das trifft bei weitem nicht auf alle zu.
|
|
| Thema: wieder ein feines gesetz verabschiedet... |
|
|
| Zitat: |
| Es greift ja doch sehr tief in die persönlichen Rechte ein. |
Mehr als das, verursacht es extreme Probleme fuer auch nur geringfuegig volatile content, und die Beispiele in dem Artikel sind dabei noch harmlos.
Wollen die jetzt jede Version von http://titan.www.opennet-initiative.de/s...01__1h_ppp+.png haben? Die Dinger werden einmal pro 15 Minuten erzeugt. Die Alfredi-images eher noch haeufiger. Was ist mit Systemen, die die Resultate von Datenbankabfragen ueber HTTP uebertragen (say, Suchmaschinen)? Muss google jetzt jede einzelne ausgelieferte Resultat-Seite speichern und an diese Instanz schicken? Ich glaube nicht, dass sie das lange aushalten wuerden.
Ich fuehle mich versucht, 1Exabyte an Daten mit extrem geringer Entropie ("german politicians are computer-illiterate" in 27450512014448736er Ausfuehrung waere eine Ueberlegung wert) online zu stellen, und ihnen anzubieten, die abzuliefern (ok, die liegen hier komprimiert, aber ich liefere sie unkomprimiert aus, also...), unter der Bedingung, dass sie die Datentraeger (ob es auffaellt wenn ich da ein paar Petabytes unterschlage und die hw dafuer behalte?) bereitstellen.
|
|
| Thema: 25.09.2006 - nagare olsrd Abstürze [Erledigt] |
sh01
| Antworten: |
62 |
| Hits: |
5.124 |
|
|
Und nach einigen Patzern meinerseits habe ich auch einen traceback mit debug-info. Die letzten Momente vor dem crash sind jetzt ziemlich klar; der Crash ist unmittelbar ein Resultat einer Verletzung einer an die internen Datenstrukturen von olsrd gestellten Annahme (fuer jeden node in neighbortable existieren >0 link-Eintraege in link_set).
Es gibt keine fuer mich offensichtlichen Codepfade, die in diesem Problem resultieren.
Olsrd auf nagare laeuft momentan mit einigen zusaetzlichen debugging statements; evtl. reichen die bereits, um mir beim naechsten Auftreten genug Hinweise auf das Problem zu liefern.
|
|
| Thema: 09.09.2006 - Routingprobleme zum wiki? [Erledigt] |
sh01
| Antworten: |
36 |
| Hits: |
3.087 |
|
|
| Zitat: |
| Ich schließe vielmehr daraus, dass ggf. der Server ein wenig schwach ist und daher die Auslieferung der Seiten ein wenig benötigt. |
Nein. Ruri ist kein sonderlich neues System, und wie beim wiki alles dynamisch zu generieren ist sicher nicht die effizienteste Methode, aber die Leistung ist fuer unsere jetzigen loads trotzdem mehr als ausreichend.
| Zitat: |
| hatte im Chat gelesen, dass es seit einiger Zeit Probleme mit der Verbindung zwischen ruri und titan gibt. Wenn ich das richtig in Erinnerung habe, dann war da mal etwas mit dem Switch, was aber eigentlich längst behoben war. Vieleicht ist es doch noch nicht vollständig behoben. |
Es gab auf der Verbindung vor einiger Zeit ernsthafte Probleme, aber soweit ich sehe sind die weiterhin vollstaendig behoben.
| Zitat: |
| Ist es nicht einfach nur die Weiterleitung zu titan? |
Probleme dort wuerden das wiki nicht betreffen.
Ich habe mir die Situation fuer die Weiterleitung eben im Detail angesehen. Es gab dort systematische Delays von ca. 15 Sekunden; diese lagen darin begruendet, dass ruri's primary dns server (139.30.5.204) down war. Das ding funktionierte wohl mal, aber momentan tut es das nicht, und die timeouts von dem query dauern exakt 5 Sekunden. Der secondary antwortete dann zuverlaessig, und praktisch sofort. Anscheinend gibt es von ruri's Apache 3 DNS lookups (einmal titan, einmal reverse auf die client-ip; k.A. was der dritte ist) fuer ein verbindungs-forwarding auf titan.
Ich habe den defekten dns host in ruri's resolv.conf auskommentiert; diese delays sollten damit nicht mehr auftreten.
Es gab fuer Zugriffe auf andere Seiten von ruri, wie z.B. die im wiki, wahrscheinlich ebenfalls DNS lookups; zumindest macht der apache wahrscheinlich ein reverse-lookup auf die IP des clients. Die delays dort haetten etwas geringer ausfallen sollen, aber werden qualitativ ebenfalls durch das beschriebene Problem erklaert.
Ich habe keine konkreten Messungen der Verzoegerungern beim zugriff auf nicht geforwardete webpages auf ruri vorgenommen.
Feedback dazu, ob das Problem fuer euch jetzt behoben ist, waere gut.
|
|
| Thema: 16.09.2006 - GW Beselin ausgefallen [erledigt] |
sh01
| Antworten: |
16 |
| Hits: |
1.586 |
|
|
| Zitat: |
| der ping vom uninetz aus geht auch - hikaru.opennet...... (stand 18.9. 14.30uhr) |
Unbedeutend. Die IP gehoert inzwischen eventuell (und wahrscheinlich) einem anderen System, das auch auf ICMP ECHO REQUESTs antwortet.
|
|
|
