Zusammenfassung

  • Cloudflare hat für HKG eine Wartung von 17:00 UTC am 19. August bis 12:00 UTC am 20. August angesetzt. Beim Quellen-Freeze um 05:54 UTC war das Ereignis weiterhin geplant und die Hongkong-Komponente betriebsbereit.
  • Laut Cloudflare kann Verkehr umgeleitet werden; PNI/CNI-Kunden sollen mit einem Failover rechnen, weil Schnittstellen am Standort zeitweise ausfallen können. Ob der Ersatzpfad einen anderen Ausfallbereich bildet, bleibt kundenspezifisch.

Zwei Leitungen sind nicht automatisch zwei Ausfallbereiche. Sie können auf unterschiedlichen Routerports beginnen und trotzdem im selben Gebäude, auf demselben Transportanbieter oder in derselben Faserstrecke zusammenlaufen.

Cloudflares offizieller Eintrag kündigt für das Rechenzentrum HKG ein 19-stündiges Wartungsfenster an: vom 19. August um 17:00 UTC bis zum 20. August um 12:00 UTC. Verkehr könne von diesem Standort weggeführt werden; für Nutzer in der Region sei eine leichte Latenzerhöhung möglich. PNI- und CNI-Kunden sollen ausdrücklich ein Failover an einen anderen Ort erwarten, da Netzwerkschnittstellen im Rechenzentrum vorübergehend nicht verfügbar sein könnten.

Um 05:54 UTC führte der Wartungsfeed my45g1324mkk noch als scheduled und HKG als operational. Der eingefrorene Stand belegt somit weder Ausfall noch Paketverlust, Routenzurückziehung oder höhere Latenz. Er belegt ein angekündigtes Risiko vor Beginn der Arbeiten.

Für den allgemeinen Dienst greift zunächst Cloudflares verteilte Architektur. Die CDN-Referenz beschreibt Anycast: Mehrere Standorte kündigen denselben Adressraum an, und BGP führt eine Anfrage zu einem erreichbaren Knoten. Fällt ein Standort weg, kann ein anderer die Anfrage übernehmen. Erreichbarkeit und niedrige Latenz sind dabei nicht identisch; der Ersatzweg kann länger sein.

Private Interconnection erzeugt eine zweite Abhängigkeit. Die Network-Interconnect-Dokumentation beschreibt CNI als private Punkt-zu-Punkt-IP-Verbindung. Beim Peering entsteht Konnektivität an jedem einzelnen PoP. Wird die HKG-Schnittstelle unbenutzbar, braucht der Kunde einen anderen Anschluss oder einen Internet-Backupweg sowie eine BGP-Policy, die den Verkehr tatsächlich dorthin lenkt.

Der gemeinsame Ausfallbereich kann an mehreren Stellen verborgen sein. Eine alternative BGP-Sitzung empfängt womöglich nicht alle benötigten Präfixe oder verliert aufgrund der Präferenz. Filter und Max-Prefix-Limits können den Lastwechsel verhindern. Die Leitung kann nach der Auswahl überlastet sein. Primär- und Ersatzverbindung können zudem dasselbe Gerät, dieselbe Stromdomäne, denselben Carrier, dieselbe Cross-Connect-Infrastruktur oder denselben physischen Trassenabschnitt teilen.

Cloudflare legt die Verantwortungsgrenze in der eigenen CNI-Anleitung offen. Die verfügbare Diversität variiert je Standort. Verbindungen zu getrennten Geräten können während Wartung erreichbar bleiben, sofern der Standort Gerätevielfalt unterstützt; eine Installation an nur einem Gerät kann vollständig unterbrochen werden. Alternative Internet-Konnektivität ist als Backup vorgeschrieben, und der Kunde trägt die Verantwortung für die Kapazitätsplanung über seine verfügbaren Links.

Diese Regeln sind keine Prognose eines Hongkonger Ausfalls. Der Hinweis nennt weder Gebäude noch Gerät, Leitung, Kunden oder Ersatzstandort. Er veröffentlicht keine Verkehrsmengen, freie Kapazität, Konvergenzzeit oder Rollback-Grenze. Die Formulierungen bleiben bedingt: Schnittstellen könnten ausfallen, Verkehr könnte umgeleitet werden.

Vor 17:00 UTC können Betreiber ihren Teil prüfen: Portstatus, BGP-Nachbarn, empfangene und angekündigte Präfixe, Filter, Max-Prefix, Local Preference, Communities, Auslastung und Reserve. Für Anwendungslatenz und Paketverlust ist ein Vorher-Wert nötig. Bei extern bereitgestellten Leitungen sollte der Betreiber die physische Trennung vom Primärpfad ausdrücklich bestätigen lassen.

Der Geltungsbereich bleibt ein einzelner HKG-Standort, nicht Cloudflares gesamtes Netz. Anycast soll den gemeinsam genutzten Dienst gerade von einem einzelnen Standort entkoppeln. Stärker konzentriert ist das Risiko für Kunden, deren private Verbindung, bevorzugter Ursprungspfad oder regionale Architektur an Hongkong hängt und deshalb im globalen Statuslicht nicht vollständig sichtbar ist.

Ein späterer Status „completed“ beweist, dass Cloudflare seine Arbeit beendet hat. Er beweist nicht, dass jeder Ersatzpfad unabhängig war. Dafür braucht es Zeitstempel von Schnittstellen, Routenbewegungen, Konvergenzdauer, Ersatzlink-Auslastung sowie Latenz und Verlust gegenüber der Ausgangslage. Erst diese Daten zeigen, ob aus zwei eingezeichneten Wegen zwei belastbare Ausfallbereiche wurden.

Quellen