Zusammenfassung

  • Im RIS-Plan für das dritte Quartal 2026 erklärt RIPE NCC die Migration der RIS/RIPEstat-Daten auf gemietete Bare-Metal-Systeme für beendet. Im selben Punkt laufen bessere Überwachung der Datenverarbeitung, der Abbau technischer Schulden und die Untersuchung von Speicherarchitekturen mit geringerer HBase-Abhängigkeit weiter.
  • Der Austausch der Kafka-Maschinen und das Upgrade auf eine neue Kafka-Version sind ein eigenes Vorhaben. Es war wegen begrenzter Ressourcen verschoben worden und ist nun in Arbeit. Daraus folgt weder ein Fehlschlag der Datenmigration noch eine Störung des heutigen Kafka-Betriebs.
  • Der archivierte RIPEstat-Plan nennt zusätzliche Latenz zwischen RIPEstat und Backend-Systemen. Das Team prüfte unter anderem parallele Abfragen und beobachtete die Auswirkung; veröffentlicht wurden weder Messwert noch Zielverletzung oder Ausfall.
  • Ein komponentengenauer Migrationsbeleg sollte Datenumfang, technische Generationen, Umschaltfenster, Replay oder Backfill, getrennte Prüfungen von MRT, RIS Live und RIPEstat, bekannte Ausnahmen, Abnahmeverantwortliche und Beobachtungszeitraum verbinden.

Das Prädikat ist richtig, sein Geltungsbereich bleibt flüchtig

Der aktuelle RIS-Quartalsplan sagt nicht einfach, „RIS“ sei fertig. RIPE NCC schreibt, die Migration der RIS/RIPEstat-Daten auf gemietete Bare-Metal-Infrastruktur sei abgeschlossen. Danach folgen ausdrücklich Nacharbeiten: Überwachung der Datenverarbeitung verbessern, technische Schulden bereinigen und alternative Speicherarchitekturen untersuchen, um die Abhängigkeit von HBase zu reduzieren. Der Status lautet „in Bearbeitung“.

Auch Kafka hat einen eigenen Eintrag. Maschinen werden ersetzt, die Version wird aktualisiert. Diese Arbeit war aufgrund knapper Ressourcen verschoben worden und läuft. Die Seite zeigt damit mehrere sachlich verschiedene Uhren.

Wer die offenen Punkte als Widerlegung der abgeschlossenen Datenmigration liest, verlässt die Quelle. Es gibt dort keinen Beleg für Datenverlust, Beschädigung, Ausfall oder einen gescheiterten Cutover. Ebenso verlässt die Quelle, wer dem abgeschlossenen Datentransfer eine Abnahme der gesamten Kette unterstellt.

Ein Datensatz kann vollständig am neuen Ort liegen, während Hardware erneuert wird. Ein Dienst kann alle Daten finden und dennoch einen anderen Latenzverlauf zeigen. Monitoring kann gerade nach der Umschaltung sinnvoller werden. Die eigentliche Governance-Frage lautet: Wie bleibt später nachvollziehbar, welchem Teil das Wort „fertig“ galt?

Routingdaten entstehen unter geteilter Verantwortung

Der Routing Information Service sammelt BGP-Daten über weltweit verteilte Remote Route Collectors, meist an Internetknoten. Freiwillige Netze peeren mit den RRCs; die Kollektoren empfangen Updates und Withdrawals. RIPE NCC speichert und veröffentlicht die Beobachtungen für Betrieb und Forschung.

Schon diese Beschreibung trennt Rollen. Ein Peer liefert seine Sicht. Der RRC erfasst, was die Sitzung sendet. Transport bringt Meldungen zur Verarbeitung. Jobs erzeugen Dateien oder abfragbare Strukturen. Speicher hält Generationen vor. Öffentliche Oberflächen liefern Archiv, Strom oder Antwort. Forschende wählen daraus ihre Stichprobe.

Bei einer Migration wird diese Herkunft selbst zum Beweis. Stammt ein Intervall aus dem alten oder neuen Speicher? Wurde es während einer Überlappung erzeugt? Lief eine Warteschlange erneut? Gehört der Veröffentlichungszeitpunkt zur Beobachtung oder zu einem späteren Backfill? Welche Verarbeitungsversion formte den Datensatz?

Das sind keine Verdachtsmomente. Es sind Bedingungen für Wiederholbarkeit. Ein heute grüner Dienst kann eine historische Herkunft nicht rekonstruieren, wenn die alte Umgebung und ihre Zuordnung längst verschwunden sind.

RIPEstat macht die Verbrauchergrenze sichtbar

Im archivierten RIPEstat-Plan hält RIPE NCC fest, dass die Verlagerung großer, für RIPEstat relevanter Daten zusätzliche Latenz zwischen RIPEstat und Backend-Systemen erzeugte. Das Team unterstützte die Migration, suchte nach Möglichkeiten, die Latenz zu verbergen — darunter parallele Abfragen — und überwachte die Auswirkung sorgfältig. Der Unterstützungspunkt wurde im dritten Quartal 2026 abgeschlossen.

Die Seite beziffert die Latenz nicht. Sie nennt keine betroffene Abfrageklasse, keine verletzte Dienstzusage und keine allgemeine Einführung paralleler Anfragen. Deshalb wäre eine Störungserzählung unbelegt.

Die Feststellung hat dennoch Gewicht: Eine Speicher- oder Datenabnahme misst nicht automatisch die Nutzungsschicht. Eine erfolgreiche Antwort ist kein Latenzprofil. Selbst ein guter Mittelwert kann eine kleine, alte Spitze verbergen. Der Verbraucher braucht eine eigene, begrenzte Abnahme.

Ein öffentlicher Beleg kann Abfrageklassen und Zeitfenster nennen, Median und obere Perzentile ausweisen und den Zustand der Gegenmaßnahme festhalten. Persönliche Abfragen, interne Adressen und Rohprotokolle gehören nicht hinein.

Dateitakt, Livestrom und Abfrage sind drei Zeugen

Die MRT-Dokumentation beschreibt Dateien pro Route Collector. bview hält einen Routingzustand zu einem Zeitpunkt fest; Update-Dateien enthalten Änderungen eines Intervalls. Nach aktueller Dokumentation werden Dumps alle acht Stunden und Updates alle fünf Minuten erzeugt.

Dieser Rhythmus liefert erwartbare Slots für jeden RRC. Die Existenz eines Dateinamens beweist aber weder seinen Inhalt noch die Verarbeitungsgeneration oder andere Ausgabekanäle. Eine Abnahme sollte Größe oder Hash, eine begrenzte Inhaltsprüfung, Ausnahmen und einen möglichen Replay- oder Backfill-Status festhalten.

RIS Live liefert BGP-Nachrichten annähernd in Echtzeit. Ein frischer Strom bescheinigt nicht die Vollständigkeit des historischen MRT-Archivs. Vollständige Dateislots messen nicht die RIPEstat-Latenz. Die geprüften Quellen belegen auch nicht, dass alle drei Oberflächen denselben internen Weg nehmen.

Darum unterschreibt jede Oberfläche nur ihr Feld: MRT die RRC-Intervalle und abgegrenzten Inhalte, RIS Live seine eigene Aktualität, RIPEstat die Verteilung nach Abfrageklasse. Zusammen ergeben sie ein Bild; austauschbar sind sie nicht.

Alte Pläne erklären, warum Generationen nicht verschwinden dürfen

Die archivierten RIS-Pläne berichten für 2023 vom Austausch der Pipeline, die öffentliche MRT-Dumps erzeugt. Die neue Fassung habe deutlich weniger Verzögerung und einige Änderungen an der Dateistruktur gebracht. Zwei gültige historische Intervalle können somit aus verschiedenen Produktionsgenerationen stammen.

Für 2025 nennt RIPE NCC eine behobene Inkonsistenz: Daten eines entfernten IPv6-Peers waren weiterhin in Datensätzen erschienen. Die öffentliche Dokumentation dieses und weiterer kleinerer Artefakte wurde verschoben. Die Zeitform ist entscheidend. Das Datenproblem wird als behoben beschrieben; verschoben wurde die Dokumentation. Ein fortbestehender Fehler lässt sich daraus nicht ableiten.

Frühere Vorhaben für externe Kafka-Verteilung und eine Open-Source-Freigabe von RIS Live wurden bei der Überprüfung der RIS-Strategie nachrangig behandelt. Sie sind keine Beschreibung der heutigen Architektur. Der damalige öffentliche Kafka-Prototyp darf nicht ohne Bindeglied mit den nun auszutauschenden Kafka-Maschinen gleichgesetzt werden.

Ein belastbarer Herkunftsnachweis sagt daher nicht nur, was verbunden ist, sondern auch, wo eine Verbindung nicht gilt.

Inhalt eines begrenzten Migrationsbelegs

Am Anfang steht der Umfang: Datensätze, RRCs, Zeiträume, Verbrauchsoberflächen und ausdrückliche Ausschlüsse. „RIS-Daten“ allein ist zu weit.

Danach folgen Generationen. Erfassungs-, Transport-, Verarbeitungs- und Speichergeneration werden für den jeweiligen Umfang benannt. Wenn Kafka für einen Weg nicht gilt, lautet das Feld „nicht anwendbar“. Eine untersuchte HBase-Alternative wird nicht vor einer Entscheidung als neue Architektur ausgegeben.

Der Cutover wird in Schritte zerlegt: Extraktion, Erstbefüllung, Parallelbetrieb, Lese- oder Schreibumschaltung, Ende der Überlappung und Stilllegung. Das RIPE-88-Protokoll trennt solche Entscheidungen in einer älteren, breiteren Darstellung der Datenplattform. Es ist ein historisches Beispiel für die Reihenfolge, keine aktuelle RIS-Topologie.

Dann folgen die Prüfungen. Vergleichbare RRC-Intervalle vor und nach der Umschaltung werden auf erwartete Fünf-Minuten-Updates und Acht-Stunden-Dumps geprüft. RIS Live erhält eine eigene Aktualitätsprüfung. RIPEstat erhält Perzentile pro Abfrageklasse. Toleranzen und Beobachtungsdauer werden angegeben.

Replay und Backfill bekommen einen eindeutigen Zustand und Zeitraum: nicht nötig, geplant, teilweise oder abgeschlossen. Bekannte Artefakte und Ausschlüsse stehen daneben. Für Speicher, Verarbeitung, Abfrage und Veröffentlichung wird jeweils eine verantwortliche Rolle mit Datum dokumentiert.

Die öffentliche Fassung braucht keine Hostnamen, Zugangsdaten, internen IP-Adressen oder Rohlogs. Zeitbereiche, Builds, Hashes, Zählwerte und aggregierte Latenzen reichen, um den Abschluss prüfbar zu machen.

Ein solcher Beleg schwächt die Aussage von RIPE NCC nicht. Er schützt sie davor, für fremde Komponenten haften zu müssen. Der Datentransfer bleibt abgeschlossen. Kafka, HBase-Entscheidung, Verarbeitungsmonitoring und RIPEstat behalten ihre eigenen Zustände. Aus einem großen, dehnbaren „fertig“ werden mehrere kleinere, belastbare Entscheidungen.

Quellen