Zusammenfassung

  • RIPE NCC meldete am 3. November um 15:55:39 Uhr MEZ eine Untersuchung wegen zeitweise gestörten Zugriffs auf Ressourceninformationen im LIR Portal. Um 16:50:45 Uhr wurde der Vorfall als behoben markiert. Die veröffentlichten Meldungen liegen rund 55 Minuten auseinander.
  • Der um 17:17 Uhr veröffentlichte Bericht nennt ein Failover des Lastverteilers und veraltete Datenbankverbindungen in betroffenen Anwendungen. Das Löschen dieser Verbindungen half sofort; Verbindungspool und Überwachung sollen überprüft werden.

Der Ausdruck „Failover“ klingt nach erledigter Arbeit. Ein Ersatzpfad übernimmt, das Häkchen erscheint. RIPE NCCs Vorfallbericht zeigt, wo dieses Häkchen zu früh gesetzt werden kann. Nach der Umschaltung des Lastverteilers blieben in datenbanknutzenden Anwendungen alte Verbindungen bestehen. Erst als das Team sie entfernte, war das Problem mit dem Zugriff auf Ressourceninformationen beseitigt. Die Ersatzstrecke war vorhanden; die Anwendung hatte den alten Weg noch im Adressbuch.

Die offizielle API hält die Reihenfolge fest: Beginn der Untersuchung um 15:55:39.649 Uhr, Behebung um 16:50:45.437 Uhr mitteleuropäischer Zeit. Zwischen den öffentlichen Einträgen liegen 55 Minuten und knapp sechs Sekunden. Eine Aufstellung fehlgeschlagener Anfragen oder der betroffenen Mitglieder wurde nicht veröffentlicht. Die Zahl bezeichnet deshalb den Zeitraum zwischen Meldungen, keine gemessene Ausfallzeit je Nutzer.

Es ging um die Einsicht in Ressourcen, nicht um ein dekoratives Portalmodul. Mitglieder benötigen den Zugang, um IPv4- und IPv6-Bestände und AS-Nummern nachzuschlagen. RIPE NCCs Beschreibung einer im Oktober noch entwickelten My-Resources-Ansicht nennt die Aufgaben: Zuteilungshierarchien verstehen, Registrierungen und Nutzung prüfen, Datenbankobjekte und Routinginformationen abgleichen. Der dort vorgestellte Baum und die automatischen Prüfungen waren noch Gegenstand von Entwicklung und Mitgliedertests. Die Aufgabe, verlässliche Ressourceninformationen zu erhalten, war es nicht.

Ein Register kann einen Datensatz aufbewahren und zugleich beim Zugang zu ihm stolpern. Die Nachbesprechung benennt den technischen Übergang, an dem die beiden Leistungen auseinanderliefen. Das Failover veränderte den Infrastrukturpfad; die Anwendungen hingen an nicht mehr brauchbaren Verbindungen. Das Team musste die Verbindungen aktiv aufräumen. Daraus folgt eine prüfbare Frage für den Betreiber: Wie schnell wird aus einem gesunden Datenbankpfad wieder eine erfolgreiche Abfrage im Browser eines Mitglieds? Die Farbe einer Komponente auf der Statusseite beantwortet sie allein nicht.

RIPE NCC plant zwei unterschiedliche Arbeiten. Eine Prüfung der Verbindungspool-Konfiguration betrifft das Verhalten nach einer Umschaltung. Bessere Überwachung der Verbindungsnutzung soll erkennen, wenn Anwendungen an alten Sitzungen festhalten. Verhalten und Sichtbarkeit sind nicht dasselbe. Der Bericht nennt weder den Auslöser des Failovers noch eine Frist für die Verbesserungen. Der Auslöser, die Zahl gescheiterter Anfragen und ein späterer Mitgliedertest würden Reichweite und Reparatur genauer belegen.

Der feststehende Ausgang ist klar: Veraltete Verbindungen wurden entfernt, das Portalproblem als behoben gemeldet. Die nächste Umschaltung muss mehr liefern als ein grünes Feld im Maschinenraum.

Originalquellen von RIPE NCC