Zusammenfassung

  • Über PerfGrid liegen mehrere Arten öffentlicher Belege vor: die eigene Unternehmensseite, eine RIPE-Registrierung, ein vom Betreiber gepflegtes PeeringDB-Profil, zeitgebundene RIPEstat-Beobachtungen und vom Unternehmen veröffentlichte Störungsberichte. Jede Ebene beantwortet eine andere Frage; keine beweist allein Eigentum, vollständige Topologie, Leistung oder Zuverlässigkeit.
  • Besonders aufschlussreich ist der Umgang mit Grenzen und Korrekturen. Die Unterlagen unterscheiden deklarierte Profildaten von beobachtetem Routing, beschreiben Eingriffe in DNS- und Cache-Systeme und revidieren eine erste Hardwarehypothese. Für eine belastbare Entscheidung müssen Leser Attribution, Datum und Unsicherheit erhalten und zusätzliche Messwerte direkt anfordern.

Mit der Belegart beginnen, nicht mit einem Gesamturteil

Für einen Kunden besteht Hosting zunächst aus einer Adresse, einem Tarif und der Erwartung, dass eine Anwendung erreichbar bleibt. Hinter dieser Oberfläche wirken zahlreiche Systeme zusammen. Ein Server benötigt Strom, Speicher, ein Betriebssystem und Netzkonnektivität. Das Domain Name System, kurz DNS, muss Anfragen zu einer geeigneten Adresse führen.

Caches können Inhalte näher an Nutzer bringen, Lastverteiler können Verbindungen an andere Systeme leiten, und Routingprotokolle bestimmen, über welche Netze Pakete ihr Ziel erreichen. Schon die Übergabe zwischen zwei Verantwortungsbereichen kann zur Störung werden, obwohl alle übrigen Teile funktionieren.

Öffentliche Unterlagen bilden diese Kette nur ausschnittsweise ab. Eine Unternehmensseite erklärt, wie sich der Betreiber selbst beschreibt. Eine Registerdatenbank hält eine Netzidentität fest. Ein Branchenverzeichnis enthält Angaben, die der Netzbetreiber selbst pflegt. Ein Routingdienst beobachtet, was ausgewählte Messpunkte zu einem bestimmten Zeitpunkt sehen.

Ein Störungsnachbericht wiederum schildert, was der Betreiber während eines Ereignisses vermutete, prüfte und änderte. Der Wert entsteht nicht dadurch, dass alle Dokumente wie eine einzige Autorität behandelt werden. Er entsteht durch die saubere Zuordnung jeder Aussage zu ihrem Ursprung.

Das verhindert zwei typische Fehler. Der erste Fehler besteht darin, dieselbe Kennung in mehreren Dokumenten als mehrfachen Beweis für Qualität zu lesen. Der zweite besteht darin, begrenzte Daten für wertlos zu halten. Eine Registrierung kann sehr wohl die Zuordnung eines Autonomen Systems (AS) erklären, auch wenn sie keine Aussage über Paketverluste trifft. Ein beobachtetes Präfix kann reale Sichtbarkeit belegen, ohne ein vollständiges Inventar zu liefern. Ein Unternehmensbericht kann einen Lernprozess sichtbar machen, obwohl er keine unabhängige Prüfung ist.

Wer PerfGrid beurteilt, sollte deshalb nicht nach einem einzigen Siegel suchen. Sinnvoller ist eine Folge von Fragen: Wer ist die verantwortliche Gegenpartei? Welche Systeme verwaltet sie unmittelbar, welche liegen bei Partnern? Welche Netzidentität ist registriert? Was wurde tatsächlich beobachtet und wann? Welche Reaktion beschreibt der Betreiber nach einem Ausfall? Welche Behauptung wurde später korrigiert? Diese Trennung ist praktischer als ein pauschales positives oder negatives Urteil.

Unternehmensidentität als Ausgangspunkt

PerfGrid identifiziert auf seiner eigenen Unternehmensseite Lucas Rolff als Gründer und nennt eine Registrierungsadresse in Hilversum sowie niederländische Unternehmenskennungen. Das ist eine Selbstdarstellung des Unternehmens und keine unabhängige Quelle für Betriebsleistung. Sie verbindet Marke, benannte Person und Registrierungskontext, belegt aber weder Marktstellung, Größe, Personalbestand, ununterbrochene Eigentümerkontinuität, Servicequalität noch Verfügbarkeit.

Diese enge Aussage ist dennoch nützlich. Bei einer Störung müssen Vertragspartner wissen, an welches Unternehmen eine Eskalation gerichtet wird. Ebenso muss klar sein, dass ein Markenname, eine juristische Anschrift, eine AS-Kennung und eine Rechenzentrumsbeziehung unterschiedliche Dinge sind. Eine Adresse zeigt nicht, wo jeder Server steht. Die Nennung eines Gründers zeigt nicht, wer in einer bestimmten Nacht Bereitschaft hatte. Die Identität bildet den Start der Untersuchung, nicht ihr Ergebnis.

AS59795: Registereintrag und Betreiberprofil sind verschiedene Ebenen

Die RIPE Database verzeichnet im aut-num-Objekt AS59795 den as-name PerfGrid, die Organisation ORG-LRTA3-RIPE und den Status ASSIGNED. Das ist ein Eintrag in einem Register, also eine Zuordnungs- und Koordinationsreferenz. Er ist kein Eigentumstitel für Gebäude oder Leitungen, keine souveräne Erlaubnis und kein Zertifikat für Leistung. Aus ihm folgen weder alle aktuell sichtbaren Routen noch die vollständige Topologie, Routingqualität oder betriebliche Kontinuität.

Ein Autonomes System ist vereinfacht ein administrativer Routingbereich. Die Nummer sorgt dafür, dass andere Netze Richtlinien und beobachtete Pfade einem stabilen Bezeichner zuordnen können. Diese Funktion ist im Alltag wichtig: Ohne eindeutige Kennungen, korrekte Kontakte und gepflegte Sicherheitsinformationen würden Fehleranalyse und Abstimmung schwieriger. Dennoch bleibt die laufende Konfiguration entscheidend. Ein korrekter Registereintrag kann neben einer fehlerhaften Routerkonfiguration bestehen; umgekehrt kann eine Route technisch funktionieren, während ihr Registerkontext veraltet ist.

Das vom Betreiber gepflegte PeeringDB-Profil deklariert für AS59795 unter anderem das Internet Routing Registry Set AS59795:AS-PERFGRID, 30 IPv4- und 30 IPv6-Felder, eine Verkehrskategorie von 1-5 Gbps, einen globalen Umfang und einen Eintrag für AMS-1. Der Profilstand ist mit 2024-12-31T14:22:49Z angegeben. Diese Werte sind deklarierte Verzeichnisfelder, keine unabhängigen Messungen. Sie beweisen weder aktuell sichtbare Origin-Präfixe, gemessenen Durchsatz, öffentliches Peering, physisches Eigentum, Resilienz noch Ende-zu-Ende-Leistung. Auch ein Rechenzentrumseintrag bedeutet nicht, dass PerfGrid die Anlage besitzt.

Die beiden Datensätze ergänzen sich, ohne austauschbar zu sein. RIPE bewahrt die Registeridentität. PeeringDB veröffentlicht vom Betreiber gepflegte Angaben, die für mögliche Netzpartner nützlich sein können. Für einen Geschäftskunden stellt sich danach eine andere Frage: Stimmen diese Angaben noch mit dem laufenden Betrieb überein? Diese Antwort erfordert aktuelle Beobachtung und gegebenenfalls direkte Bestätigung durch die beteiligten Betreiber.

Deklarierte 30/30-Felder und beobachtete 3/3-Präfixe

RIPEstat beobachtete im dynamischen, sichtbarkeitsgefilterten Snapshot vom 10. August 2026 um 16:00 UTC für AS59795 drei sichtbare IPv4-Origin-Präfixe und drei sichtbare IPv6-Origin-Präfixe. Das Verfahren schließt Routen aus, die von weniger als zehn RIS-Full-Feed-Peers gesehen wurden. Die drei IPv4- und drei IPv6-Werte sind deshalb eine zeitgebundene Kollektorsicht. Sie sind weder ein dauerhaftes Präfixinventar noch eine Zuteilungsliste, vollständige Topologie, kommerzielle Beziehungskarte, Auslastungs- oder Leistungsmessung.

Auf den ersten Blick unterscheiden sich die im RIPEstat-Snapshot vom 10. August 2026 um 16:00 UTC sichtbaren drei IPv4- und drei IPv6-Origin-Präfixe deutlich von den in PeeringDB deklarierten 30 IPv4- und 30 IPv6-Feldern. Das RIPEstat-Verfahren schloss dabei Routen unterhalb der Sichtbarkeit bei zehn RIS-Full-Feed-Peers aus. Daraus folgt aber nicht automatisch ein Widerspruch.

Autor, Definition, Zeitraum und Messmethode sind verschieden. Ein Profilfeld kann eine vom Betreiber gewählte Beschreibung sein; RIPEstat zählt in diesem Fall sichtbare Origin-Präfixe oberhalb einer Schwelle. Bevor jemand eine der Zahlen als falsch bezeichnet, muss geklärt werden, was genau PeeringDB mit dem Feld meint und was die Kollektoren erfassen.

Dasselbe gilt für weitere Angaben des sichtbarkeitsgefilterten RIPEstat-Snapshots vom 10. August 2026 um 16:00 UTC: Er nannte 768 IPv4-Adressen und 768 IPv6-/48-Äquivalente sowie drei beobachtete Nachbarn und schloss Routen unterhalb der Sichtbarkeit bei zehn RIS-Full-Feed-Peers aus. Solche Werte dürfen nur mit Adressfamilie, Einheit, Zeitpunkt und Methodengrenze verwendet werden. Sie sind keine Kapazität, keine Zuteilung, keine Auslastung und keine vollständige Liste vertraglicher Beziehungen. Drei beobachtete Nachbarn können weder jede private Sitzung noch jeden Reservepfad abbilden.

Für die Praxis ist die Differenz dennoch wertvoll. Sie liefert konkrete Fragen: Welche Präfixe erwartet der Betreiber? Welche werden von den für den Kunden relevanten Messpunkten gesehen? Gibt es Aggregation, Filterung oder zeitweise zurückgezogene Routen? Stimmen IPv4 und IPv6 in der betrieblichen Überwachung überein? Eine gute Prüfung versucht nicht, verschiedene Kennzahlen künstlich gleichzumachen. Sie dokumentiert ihre Definitionen und untersucht Abweichungen.

Kontrolle über Lieferanten- und Partnerschichten

PerfGrid beschreibt in seiner Datenrichtlinie Dienste über mehrere Lieferanten, Anbieter und Kontinente sowie physische und virtuelle Server, die von PerfGrid oder Partnern verwaltet werden. Das ist eine unternehmenseigene Darstellung von Verarbeitung und Lieferantenbeziehungen. Sie ist keine präzise Topologiekarte und kein vollständiges Anbieterverzeichnis. Vor allem beweist sie weder Eigentum an sämtlicher Ausrüstung noch unabhängige Redundanz, dauerhafte geografische Abdeckung, ein bestimmtes Failover-Design oder messbare Resilienz.

Für einen Käufer ist gerade die von PerfGrid in seiner Datenrichtlinie beschriebene Trennung zwischen direkt und von Partnern kontrollierten Ebenen entscheidend. Bei einem eigenen System kann ein Betreiber Konfiguration, Wartungsfenster und Ersatzteile unmittelbar bestimmen. Bei einem Partner können Vertrag, Eskalationsweg und verfügbare Schnittstellen den Handlungsspielraum begrenzen. Beide Modelle können sinnvoll sein, doch sie erzeugen unterschiedliche Abhängigkeiten. Die dort genannte Mehrzahl von Anbietern ist keine präzise Karte und beweist weder voneinander unabhängige Strom-, Carrier-, Verwaltungs- oder Personalpfade noch Redundanz.

Eine belastbare Servicebeschreibung sollte daher Verantwortungsgrenzen sichtbar machen. Wer beobachtet den physischen Host? Wer erneuert Zertifikate? Wer pflegt DNS-Zonen? Wer darf Routingfilter ändern? Wer besitzt die Messwerte, wenn eine Anwendung langsam ist? Welche Partei kann einen Ersatzserver bereitstellen? Die öffentliche Richtlinie liefert einen Ansatzpunkt, aber die konkrete Antwort gehört in aktuelle Verträge, Architekturunterlagen und Betriebsvereinbarungen.

Ein Nameserver-Vorfall zeigt Nutzen und Grenzen von Redundanz

PerfGrid berichtete am 25. Februar 2025 über den Ausfall eines von vier Nameservern nach einer VM-Hypervisor-Migration und über den Ersatz dieses Systems. Das Unternehmen beschrieb dabei eine Verteilung über vier Netze, den Wechsel in einen Amsterdamer Proxmox-Cluster sowie PowerDNS, LMDB und Lightning Stream. Vor der Umschaltung habe es nach eigener Darstellung DNS- und DNSSEC-Prüfungen durchgeführt.

Das ist ein zeitgebundener Betreiberbericht, keine unabhängige Prüfung. Der Ausfall eines von vier Servern ist nicht mit einem Ausfall des gesamten DNS gleichzusetzen; vier Netze beweisen zudem keine vier unabhängigen Fehlerdomänen oder universelle DNS-Kontinuität.

Der Vorfall ist trotzdem lehrreich. DNS ist eine Steuerungsebene: Wenn Nutzer den richtigen Zielnamen nicht auflösen können, hilft ein gesunder Webserver allein nicht. Mehrere Nameserver können die Abhängigkeit von einem einzelnen System reduzieren. Entscheidend ist jedoch, ob Zonen, Schlüssel, Zeitsteuerung, Netzwerkpfade und Überwachung tatsächlich konsistent sind. Vorabtests sind sinnvoll, aber erst laufende Messung aus verschiedenen Perspektiven zeigt, wie die Namensauflösung für Nutzer funktioniert.

Der von PerfGrid am 25. Februar 2025 berichtete Ausfall eines von vier Nameservern macht auch die VM-Hypervisor-Migration als Risikomoment sichtbar. Eine virtuelle Maschine kann technisch verschoben werden, während sich Netzpfad, Speicher, Zeitsynchronisation oder Automatisierung verändern. Ein gutes Änderungsverfahren benötigt daher nicht nur einen Plan für den normalen Ablauf, sondern auch einen Rückweg. Der Betreiberbericht ist keine unabhängige Prüfung; vier Netze beweisen keine unabhängigen Fehlerdomänen, und aus der Erzählung lässt sich keine universelle DNS-Kontinuität oder Absicherung jeder künftigen Migration ableiten.

Varnish, Zustandsprüfung und Umleitung

In einem Störungsnachbericht vom 4. März 2025 berichtete PerfGrid über einen Varnish-Cache-Fehler nach einem unbeaufsichtigten Update. Nach Darstellung des Unternehmens erkannte eine DNS-Zustandsüberwachung das Problem, entfernte Amsterdam aus dem betreffenden Pfad und leitete Optimierungsverkehr nach Miami um, während der Cache zurückgesetzt wurde. Der Bericht unterscheidet dabei den Optimierungscluster, Cache-Standorte, HAProxy, Varnish und die Rolle der Zustandsprüfungen. Diese geschilderte 2025er Konfiguration ist keine vollständige oder dauerhafte Topologie.

Bei dem von PerfGrid am 4. März 2025 beschriebenen Vorfall liegt die wichtige technische Grenze zwischen Erkennen, Umleiten und dem Ergebnis beim Nutzer. Ein Zustandscheck kann einen Fehler markieren. DNS kann Antworten verändern. HAProxy kann Verbindungen verteilen. Varnish kann Inhalte zwischenspeichern.

Daraus folgt aber noch nicht, dass jede Anfrage ohne Unterbrechung erfolgreich war, dass alle Dienste vom Mechanismus erfasst wurden oder dass die Wiederherstellungszeit gemessen und eingehalten wurde. Die von PerfGrid berichtete Umleitung nach Miami beweist weder null Kundenauswirkung noch vollständige Failover-Abdeckung oder künftige Zuverlässigkeit; sie ist keine unabhängige Messung.

Der PerfGrid-Nachbericht vom 4. März 2025 nennt als Reaktion außerdem die Entfernung beziehungsweise Rücksetzung des betroffenen Varnish-Caches und den Wechsel von unbeaufsichtigten Updates zu kontrollierter Wartung. Das ist eine plausible Veränderung einer Betriebskontrolle: Änderungen werden in ein bewusstes Verfahren verschoben. Ob sie die gewünschten Ergebnisse dauerhaft liefert, muss jedoch anhand späterer Ereignisse, Wartungsprotokolle und Servicekennzahlen geprüft werden. Der Unternehmensnachbericht beschreibt keine vollständige Topologie, null Kundenauswirkung oder künftige Zuverlässigkeit und ist kein unabhängiges Audit.

Die korrigierte Diagnose ist der stärkste Hardwarehinweis

PerfGrid berichtete am 11. März 2025 über Instabilität des Systems nlcp03 und schrieb sie zunächst einer Netzwerkschnittstelle, also einer NIC, zu. Das Unternehmen beschrieb, den Dienst mit Ersatzhardware wiederhergestellt zu haben. Bereits diese Formulierung muss vorläufig bleiben: Die NIC war eine erste Hypothese, keine abschließend festgestellte Ursache, und PerfGrid revidierte sie in einer späteren Nachbetrachtung. Dass ein Austausch den Betrieb wieder ermöglicht, beweist für sich nicht, welches Bauteil den Fehler ausgelöst hat.

In einer Nachbetrachtung vom 13. Mai 2025 revidierte PerfGrid diese erste Vermutung. Die NIC habe in einem anderen System funktioniert, während die Abstürze fortbestanden. Danach seien DIMMs, CPU oder Druck beziehungsweise Sitz am Sockel als mögliche Ursachen betrachtet worden. Auch diese Alternativen blieben nach der veröffentlichten Darstellung vermutet und nicht nachgewiesen. Weder Speichermodule noch Prozessor, Sockel oder Montagedruck dürfen aus diesen Unterlagen als bestätigte Ursache bezeichnet werden.

Diese Korrektur ist kein Zeichen dafür, dass der Bericht nutzlos war. Im Gegenteil: Sie zeigt, warum ein Störungsverlauf zwischen Beobachtung, Hypothese, Wiederherstellungsmaßnahme und Wurzelursache unterscheiden sollte. Der erste Zustand lautete sinngemäß: Das System war instabil, eine NIC wurde verdächtigt, Ersatzhardware stellte den Dienst wieder her. Der spätere Zustand lautete: Der Test in einer anderen Maschine schwächte diese Erklärung, Abstürze blieben, andere Hardwareursachen wurden untersucht. Ein belastbares Betriebswissen hält beide Schritte fest.

Für Kunden ist diese Trennung relevant, weil Wiederherstellung und Ursachenklärung unterschiedliche Ziele haben. Im akuten Moment zählt, den Dienst sicher zurückzubringen. Danach muss die Organisation verhindern, dass ein vorläufiger Erfolg als abschließende Diagnose in Dokumentation, Ersatzteilplanung oder Risikobewertung eingeht. Gute Nachbereitung prüft Hypothesen erneut, bewahrt widersprechende Befunde und kennzeichnet, was offen bleibt.

Migration nach AMS-1: Veränderung ohne Ergebnisgarantie

PerfGrid beschrieb im Bericht vom 11. März 2025 eine Migration verbleibender gemieteter Hostingserver auf neuere, standardisierte Ausrüstung bei Iron Mountain AMS-1. PeeringDB enthält dazu einen vom Betreiber gepflegten AMS-1-Eintrag. Zusammen stützen diese Quellen eine begrenzte Aussage über die beschriebene Migration und einen Verzeichnisbezug. Sie beweisen nicht, dass PerfGrid AMS-1 besitzt, dass sämtliche Ausrüstung oder Adressen dem Unternehmen gehören, dass jeder Server bereits umgezogen war, dass physische Diversität besteht oder dass die neuere Technik die Zuverlässigkeit messbar verbessert hat.

Die von PerfGrid am 11. März 2025 beschriebene Migration gemieteter Hostingserver auf neuere, standardisierte Ausrüstung kann den Betrieb vereinfachen. Gleiche Plattformen können Ersatzteilhaltung, Automatisierung und Fehlersuche vereinheitlichen. Doch der betriebliche Nutzen entsteht erst, wenn Daten, DNS, Routing, Überwachung, Sicherungen und Wiederanlauf auf dem Zielsystem funktionieren. Die Beschreibung beweist weder eine abgeschlossene Migration aller Systeme noch Eigentum an AMS-1, physische Diversität oder eine messbare Zuverlässigkeitsverbesserung; „neu“ ist kein Stabilitätsmesswert.

Vor einer Entscheidung sollten Leser deshalb nach dem Umfang fragen: Welche Dienste waren im damaligen Plan enthalten? Welche blieben bei Partnern? Welche Abnahmekriterien wurden verwendet? Wie wurden IPv4 und IPv6 geprüft? Welche Rückfallmöglichkeit bestand? Welche gemeinsamen Fehlerdomänen bleiben im Gebäude, bei Strom, Transport oder Verwaltung? Die öffentlichen Angaben definieren Fragen, nicht die vollständigen Antworten.

Ein Prüfrahmen für Kunden und Partner

Eine belastbare Prüfung beginnt mit der verantwortlichen Gegenpartei und dem konkreten Service. Danach sollte die Netzidentität mit den aktuellen Register- und Verzeichnisdaten verglichen werden. Für relevante Präfixe braucht es aktuelle Routingbeobachtungen aus geeigneten Perspektiven. Deklarationen und Beobachtungen bleiben getrennt: Die eine Ebene erklärt, was ein Betreiber veröffentlicht hat; die andere zeigt, was ein Messsystem unter seiner Methode sah.

Auf der Hostingseite sollte die Verantwortung pro Schicht dokumentiert werden. Dazu gehören physischer Host, virtuelle Maschine, Speicher, Backup, DNS, Cache, Lastverteilung, Netzpfad, Überwachung und Eskalation. Bei jedem Partner ist zu klären, welche Messwerte und Eingriffsmöglichkeiten PerfGrid selbst besitzt. Redundanz sollte nicht anhand der Anzahl von Namen oder Standorten bewertet werden, sondern anhand gemeinsamer Fehlerdomänen und getesteter Wiederherstellung.

Störungsberichte sollten als Sequenz gelesen werden. Welche Beobachtung lag zuerst vor? Welche Hypothese wurde gebildet? Welche Maßnahme stellte den Dienst wieder her? Welche Messung prüfte den Erfolg? Im von PerfGrid am 11. März 2025 beschriebenen nlcp03-Fall war die NIC nur eine erste Hypothese; die Nachbetrachtung vom 13. Mai 2025 schwächte sie und ließ die Hardwareursache unbewiesen. Beim von PerfGrid am 4. März 2025 beschriebenen Cachevorfall ist die Umleitung ein dokumentierter Steuerungsschritt, aber kein Beweis für null Kundenauswirkung, vollständiges Failover oder gemessene Wiederherstellung.

Schließlich müssen Geschäftsanforderungen in messbare Ziele übersetzt werden. Ein Kunde kann Erreichbarkeit, Latenz, Fehlerquote, DNS-Auflösungszeit, Wiederherstellungsdauer oder Datenverlustgrenze benötigen. Keine dieser Größen folgt automatisch aus AS59795, einem Facility-Eintrag oder der Zahl der Nameserver. Sie benötigt definierte Messpunkte, Zeiträume und Verantwortliche. Genau hier wird aus öffentlicher Infrastrukturinformation eine sachliche Due-Diligence-Frage.

Das begleitende Bild ist ein generierter, realistisch wirkender redaktioneller Kontext und zeigt ausschließlich eine generische Hosting-Umgebung. Es zeigt weder PerfGrid noch einen benannten realen Standort, Mitarbeiter, Geräte, Topologie oder ein tatsächliches Ereignis. Das Bild liefert keine Tatsachen über Eigentum, Kapazität, Leistung, Verfahren oder Störungen des Unternehmens.

Die öffentlichen Unterlagen zu PerfGrid sind nützlich, weil sie verschiedene Steuerungsebenen sichtbar machen und eine spätere Diagnosekorrektur dokumentieren. Ihre Aussagekraft wächst, wenn jede Zahl, jeder Zeitpunkt und jede Hypothese an ihrer Herkunft befestigt bleibt. Register dienen der Koordination, Verzeichnisse enthalten Deklarationen, Kollektoren liefern zeitgebundene Beobachtungen, und Störungsberichte schildern Betreiberentscheidungen. Eine Entscheidung sollte diese Ebenen zusammenführen, ohne ihre Grenzen zu verwischen.