So routen die Systeme von Cloudflare den Traffic dynamisch über den Globus

Stellen Sie sich Folgendes vor: Sie sind am Flughafen und gehen durch eine Sicherheitskontrolle. Vor Ihnen stehen eine Reihe von Mitarbeitenden, die Ihre Bordkarte und Ihren Pass scannen und Sie zu Ihrem Gate schicken. Plötzlich machen einige der Mitarbeitenden eine Pause. Vielleicht gibt es ein Leck in der Decke über der Sicherheitskontrolle. Oder vielleicht gehen gleich mehrere Flüge um 18 Uhr, und eine Reihe von Fluggästen kommt auf einmal. In beiden Fällen kann dieses Ungleichgewicht zwischen lokalem Angebot und Nachfrage zu langen Schlangen und unzufriedenen Reisenden führen, die einfach nur durch die Schlange kommen wollen, um ihren Flug zu erreichen. Wie gehen Flughäfen mit dieser Situation um?

Manche Flughäfen unternehmen gar nichts und lassen Sie einfach länger in der Schlange stehen. Einige Flughäfen bieten kostenpflichtige Schnellabfertigungen („Fast Lanes“) durch die Sicherheitskontrollen an. Die meisten Flughäfen weisen Sie jedoch an, zu einer anderen, etwas weiter entfernten Sicherheitskontrolle zu gehen, damit Sie so schnell wie möglich zu Ihrem Abfluggate gelangen können. Vielleicht gibt es sogar Schilder, die anzeigen, wie lang die einzelnen Warteschlangen sind, so dass Sie sich leichter für eine bestimmte Schlange entscheiden können.

Bei Cloudflare haben wir das gleiche Problem. Wir sind in 300 Städten auf der ganzen Welt präsent, die darauf ausgelegt sind, den Traffic der Endnutzer für alle unsere Produktreihen zu empfangen. Im Idealfall haben wir immer ausreichend Computer und Bandbreite zur Verfügung, um alle Personen an ihrem nächstmöglichen Standort zu bedienen. Allerdings ist das nicht immer möglich; manchmal nehmen wir ein Rechenzentrum wegen Wartungsarbeiten offline, oder eine Verbindung zu einem Rechenzentrum fällt aus, oder einige Geräte fallen aus, und so weiter. Wenn das passiert, haben wir möglicherweise nicht genügend Wächter, um alle Personen, die die Sicherheitskontrolle passieren, an jedem Ort zu versorgen. Das liegt nicht daran, dass wir nicht ausreichend Kioske gebaut haben. In unserem Rechenzentrum ist eben etwas vorgefallen, dass uns davon abhält, alle Kunden zu versorgen.

Deshalb haben wir Traffic Manager entwickelt: ein Tool, das Angebot und Nachfrage in unserem gesamten globalen Netzwerk in Einklang bringt. In diesem Blog geht es um Traffic Manager: wie er entstanden ist, wie wir ihn entwickelt haben und was er jetzt macht.

Traffic Manager übernimmt eine Aufgabe, die früher von den Netzwerktechnikern manuell ausgeführt wurde: Unser Netzwerk funktionierte normal, bis etwas passierte, das den Traffic der Nutzer in einem bestimmten Rechenzentrum beeinträchtigte.

Wenn solche Ereignisse eintraten, schlugen Nutzeranfragen mit 499er- oder 500er-Fehlermeldung fehl, weil es nicht ausreichend Rechner gab, um die Anfragen unserer Nutzer zu verarbeiten. Dies löste eine Meldung an unsere Netzwerktechniker aus, die dann einige Anycast-Routen für dieses Rechenzentrum entfernten. Das Endergebnis: Da diese Präfixe in dem betroffenen Rechenzentrum nicht mehr angekündigt werden, wird der Traffic der Nutzer auf ein anderes Rechenzentrum umgeleitet. So funktioniert Anycast grundsätzlich: Der Traffic eines Nutzers wird zum nächstgelegenen Rechenzentrum umgeleitet, das das Präfix ankündigt, zu dem der Nutzer – wie vom Border Gateway Protocol ermittelt – eine Verbindung herstellen möchte. Eine kurze Erläuterung zu Anycast finden Sie in diesem Referenzartikel.  

Je nachdem, wie schwerwiegend das Problem war, entfernten die Techniker einige oder sogar alle Routen in einem Rechenzentrum. Wenn das Rechenzentrum wieder in der Lage war, den gesamten Traffic zu bewältigen, richteten die Ingenieure die Routen wieder ein und der Traffic kehrte auf natürliche Weise zum Rechenzentrum zurück.

Sie merken es bereits: Für unsere Netzwerktechniker war dies eine unglaublich mühsame Aufgabe. Noch dazu musste sie jedes Mal durchgeführt werden, wenn es in unserem Netzwerk ein Problem mit der Hardware gab. Der Vorgang war nicht skalierbar.

Die manuelle Durchführung war jedoch nicht nur eine Belastung für unser Network Operations-Team. Sie war auch für unsere Kunden nicht optimal, da unsere Techniker Zeit für die Diagnose und die Umleitung des Traffics aufwenden mussten. Um diese beiden Probleme zu lösen, wollten wir einen Service entwickeln, der sofort und automatisch erkennt, wenn Nutzer ein Cloudflare-Rechenzentrum nicht erreichen können, und der Routen aus dem Rechenzentrum herausnimmt, bis die Nutzer keine Probleme mehr haben. Sobald der Service die Benachrichtigung erhielt, dass das betroffene Rechenzentrum den Traffic aufnehmen konnte, konnte er die Routen wieder einrichten und das Rechenzentrum wieder verbinden. Dieser Service heißt Traffic Manager, weil seine Aufgabe (wie Sie bestimmt erkennen konnten) darin besteht, den Traffic zu verwalten, der in das Cloudflare-Netzwerk gelangt.

Wenn ein Netzwerktechniker eine Route von einem Router entfernt, kann er so gut wie möglich abschätzen, wohin die Anfragen der Nutzer weitergeleitet werden, und versuchen sicherzustellen, dass das Failover-Rechenzentrum über ausreichend Ressourcen verfügt, um die Anfragen zu verarbeiten – ist dies nicht der Fall, können die Routen dort entsprechend angepasst werden, bevor die Route im ursprünglichen Rechenzentrum entfernt wird. Um diesen Prozess zu automatisieren, mussten wir vom Ratespiel zu einer Welt der Daten übergehen. Wir mussten genau vorhersagen, wohin sich der Traffic verlagern würde, wenn eine Route entfernt würde, und diese Informationen an den Traffic Manager weitergeben, um sicherzustellen, dass sich die Situation nicht verschlechtert.

Wir können zwar einstellen, welche Rechenzentren eine Route ankündigen, aber wir können nicht beeinflussen, welchen Anteil des Traffics jedes Rechenzentrum erhält. Jedes Mal, wenn wir ein neues Rechenzentrum oder eine neue Peering-Sitzung hinzufügen, ändert sich die Verteilung des Traffics. Und da wir in über 300 Städten und 12.500 Peering-Sitzungen präsent sind, ist es für Menschen mittlerweile sehr schwierig, den Überblick zu behalten oder vorherzusagen, wie sich der Traffic in unserem Netzwerk bewegen wird. Darum benötigt der Traffic Manager einen guten Freund an seiner Seite: den Traffic Predictor.

Damit Traffic Predictor seine Aufgabe erfüllen kann, führt er eine Reihe von Praxistests durch, um festzustellen, wohin sich der Traffic tatsächlich bewegt. Traffic Predictor basiert auf einem Testsystem, das die Abschaltung eines Rechenzentrums simuliert und misst, wohin der Traffic fließen würde, wenn dieses Rechenzentrum nicht mehr für den Traffic zuständig wäre. Um zu verstehen, wie dieses System funktioniert, simulieren wir die Entfernung eines Teilbereichs eines Rechenzentrums in Christchurch, Neuseeland:

• Zunächst erhält Traffic Predictor eine Liste aller IP-Adressen, die sich normalerweise mit Christchurch verbinden. Traffic Predictor sendet eine Ping-Anfrage an Hunderttausende von IPs, die dort kürzlich eine Anfrage gestellt haben.

• Traffic Predictor protokolliert, ob die IP antwortet und ob die Antwort nach Christchurch zurückkehrt, wobei ein spezieller Anycast-IP-Bereich verwendet wird, der speziell für Traffic Predictor konfiguriert wurde.

• Sobald Traffic Predictor eine Liste von IPs hat, die auf Christchurch antworten, entfernt es die Route, die diesen speziellen Bereich enthält, aus Christchurch. Dann wartet es ein paar Minuten, bis die Internet-Routing-Tabelle aktualisiert ist, und führt den Test erneut durch.

• Die Antworten werden nicht nach Christchurch weitergeleitet, sondern an Rechenzentren in der Umgebung von Christchurch. Traffic Predictor verwendet dann das Wissen über die Antworten für jedes Rechenzentrum und zeichnet die Ergebnisse als Failover für Christchurch auf.

So können wir simulieren, dass Christchurch offline geht, ohne dass Christchurch tatsächlich offline genommen wird!

Traffic Predictor führt jedoch nicht nur diesen Vorgang für jedes beliebige Rechenzentrum durch. Um die Ausfallsicherheit weiter zu erhöhen, berechnet Traffic Predictor sogar eine zweite indirekte Ebene: Für jedes Ausfallszenario eines Rechenzentrums berechnet Traffic Predictor auch Ausfallszenarien und erstellt Richtlinien für den Fall, dass umliegende Rechenzentren ausfallen.

In unserem Beispiel von vorhin wird Traffic Predictor beim Test von Christchurch eine Reihe von Tests durchführen, bei denen mehrere umliegende Rechenzentren, darunter auch Christchurch, außer Betrieb genommen werden, um verschiedene Ausfallszenarien zu berechnen. Damit ist sichergestellt, dass wir auch im Falle einer Katastrophe, die mehrere Rechenzentren in einer Region betrifft, in der Lage sind, den Traffic der Nutzer zu verarbeiten. Vielleicht denken Sie sich jetzt: „Dieses Datenmodell hört sich aber kompliziert an.“ Sie haben natürlich recht: Tatsächlich dauert es mehrere Tage, um all diese Fehlerpfade und Richtlinien zu berechnen.

Hier sehen Sie, wie diese Ausfallpfade und Failover-Szenarien für alle unsere Rechenzentren auf der ganzen Welt visualisiert aussehen:

Für das menschliche Auge kann das etwas schwierig zu interpretieren sein, daher wollen wir das obige Szenario für Christchurch, Neuseeland, etwas genauer untersuchen. Wenn wir uns die Failover-Pfade speziell für Christchurch ansehen, sehen sie wie folgt aus:

In diesem Szenario würden sich 99,8 % des Traffics von Christchurch nach Auckland verlagern, das im Falle eines katastrophalen Ausfalls den gesamten Traffic von Christchurch aufnehmen könnte.

Mit Traffic Predictor können wir nicht nur sehen, wohin sich der Traffic bewegt, wenn etwas passiert, sondern wir können auch Traffic Manager-Richtlinien vorkonfigurieren, um Anfragen aus Failover-Rechenzentren zu verlagern und so das „Thundering Herd“-Szenario verhindern, bei dem ein plötzlicher Zustrom von Anfragen zu Ausfällen in einem zweiten Rechenzentrum führen kann, wenn das erste Probleme hat. Mit Traffic Predictor verlagert Traffic Manager nicht nur den Traffic aus einem Rechenzentrum, wenn dieses ausfällt, sondern auch proaktiv aus anderen Rechenzentren, um eine nahtlose Fortsetzung des Services zu gewährleisten.

Mit Traffic Predictor kann Traffic Manager dynamisch Präfixe ankündigen und zurücknehmen und gleichzeitig sicherstellen, dass jedes Rechenzentrum den gesamten Traffic bewältigen kann. Das Zurückziehen von Präfixen als Mittel zur Steuerung des Traffics kann jedoch zuweilen etwas grobschlächtig sein. Einer der Gründe dafür ist, dass die einzige Möglichkeit, Traffic zu einem Rechenzentrum hinzuzufügen oder zu entfernen, über Ankündigungsrouten von unseren Internet-Routern aus bestand. Jede unserer Routen hat Tausende von IP-Adressen, sodass das Entfernen nur einer Adresse immer noch einen großen Teil des Traffics ausmacht.

Insbesondere werden Internetanwendungen Präfixe für das Internet aus einem /24-Subnetz als absolutes Minimum bewerben, aber viele werden Präfixe bewerben, die größer als das sind. Dies geschieht in der Regel, um Phänomene wie Routen-Leaks oder Routen-Hijacks zu verhindern: Viele Anbieter filtern tatsächlich Routen heraus, die spezifischer als ein /24 sind (weitere Informationen dazu finden Sie in diesem Blog-Beitrag hier). Wenn wir davon ausgehen, dass Cloudflare geschützte Websites im Verhältnis 1:1 auf IP-Adressen abbildet, dann könnte jedes /24-Subnetz 256 Kunden servicieren, was der Anzahl der IP-Adressen in einem /24-Subnetz entspricht. Wenn jede IP-Adresse eine Anfrage pro Sekunde sendet, müssten wir 4 /24-Subnetze aus einem Rechenzentrum auslagern, wenn wir 1.000 Anfragen pro Sekunde (RPS) übertragen müssten.

Tatsächlich ordnet Cloudflare aber eine einzige IP-Adresse Hunderttausenden von geschützten Websites zu. Bei Cloudflare könnte ein /24 also 3.000 Anfragen pro Sekunde aufnehmen, aber wenn wir 1.000 RPS auslagern müssten, hätten wir keine andere Wahl, als ein einzelnes /24 auszulagern. Und das nur unter der Annahme, dass wir auf der Ebene von /24 ankündigen. Wenn wir für die Ankündigung /20er verwenden, wird die Menge, die wir abrufen können, weniger präzise: Bei einer 1:1-Zuordnung von Website zu IP-Adresse sind das 4.096 Anfragen pro Sekunde für jedes Präfix, und sogar noch mehr, wenn viele Webseiten auf eine IP-Adresse zugeordnet werden.

Das Zurückziehen der Präfix-Anzeigen kann die Kundenerfahrung für diejenigen Nutzer verbessern, die einen 499- oder 500-Fehler sahen. Womöglich gab es jedoch einen beträchtlichen Anteil von Nutzern, die nicht von einem Problem betroffen gewesen wären, die immer noch von dem Rechenzentrum, an das sie eigentlich weitergeleitet werden sollten, weggebracht wurden, was sie wahrscheinlich verlangsamte (wenn auch nur ein wenig). Dieses Konzept, bei dem mehr Traffic als notwendig verlagert wird, wird als „stranding capacity“ (zu Deutsch in etwa „übriggebliebene“ bzw. „zurückgelassene Kapazität“) bezeichnet: Das Rechenzentrum ist theoretisch in der Lage, mehr Nutzer in einer Region zu unterstützen, der Aufbau des Traffic Managers lässt dies jedoch nicht zu.

Wir wollten den Traffic Manager so verbessern, dass er nur das absolute Minimum an Nutzern aus einem problematischen Rechenzentrum verlagert und nicht noch mehr Kapazitäten blockiert. Um dies zu erreichen, mussten wir den Prozentsatz der Präfixe verschieben, damit wir besonders präzise vorgehen und nur das verlagern konnten, was unbedingt verlagert werden musste. Um dieses Problem zu lösen, haben wir eine Erweiterung unseres Layer-4 Load Balancers Unimog, entwickelt, die wir Plurimog nennen.

Eine kurze Auffrischung zu Unimog und Layer 4 Load Balancing: Jeder einzelne unserer Rechner enthält einen Service, der bestimmt, ob dieser Rechner eine Anfrage eines Nutzers annehmen kann. Wenn der Rechner eine Nutzeranfrage annehmen kann, sendet er die Anfrage an unseren HTTP-Stack, der die Anfrage verarbeitet, bevor er sie an den Nutzer zurückschickt. Wenn der Rechner die Anfrage nicht bearbeiten kann, sendet er sie an einen anderen Rechner im Rechenzentrum, der die Anfrage bearbeiten kann. Die Maschinen können dies, weil sie ständig miteinander kommunizieren, um festzustellen, ob sie Anfragen von Nutzern bearbeiten können.

Plurimog macht das Gleiche, aber anstatt zwischen Maschinen zu vermitteln, vermittelt Plurimog zwischen Rechenzentren und Points of Presence. Wenn eine Anfrage in Philadelphia eingeht und Philadelphia nicht in der Lage ist, die Anfrage zu bearbeiten, leitet Plurimog sie an ein anderes Rechenzentrum weiter, das die Anfrage bearbeiten kann, z. B. Ashburn, wo die Anfrage entschlüsselt und verarbeitet wird. Da Plurimog auf der Ebene-4 arbeitet, kann es einzelne TCP- oder UDP-Anfragen an andere Standorte senden, wodurch es sehr präzise sein kann: Es kann sehr einfach Prozentsätze des Traffics an andere Rechenzentren senden, was bedeutet, dass wir nur so viel Traffic wegschicken müssen, dass jeder so schnell wie möglich serviciert werden kann. Sehen Sie sich an, wie das in unserem Frankfurter Rechenzentrum funktioniert, da wir in der Lage sind, nach und nach immer mehr Traffic zu verlagern, um Probleme in unseren Rechenzentren zu lösen. Dieses Diagramm zeigt die Anzahl der Vorgänge, die für Traffic von Kunden im Free-Tarif durchgeführt wurden und die dazu führen, dass dieser aus Frankfurt herausgeschickt wird:

Doch selbst innerhalb eines Rechenzentrums können wir den Traffic umleiten, um zu verhindern, dass der Traffic das Rechenzentrum überhaupt verlässt. Unsere großen Rechenzentren, die sogenannten Multi-Colo Points of Presence (MCPs), enthalten logische, voneinander getrennte Computing-Bereiche innerhalb eines Rechenzentrums. Diese MCP-Rechenzentren sind mit einer anderen Version von Unimog, Duomog, ausgestattet, die eine automatische Verlagerung des Traffics zwischen logischen Computing-Bereichen ermöglicht. Dies macht MCP-Rechenzentren ausfallsicher, ohne die Performance für unsere Kunden zu beeinträchtigen, sodass der Traffic Manager sowohl innerhalb eines Rechenzentrums als auch zwischen Rechenzentren eingesetzt werden kann.

Bei der Bestimmung, welche Reihe von Anfragen verlagert werden sollen, geht Traffic Manager wie folgt vor:

• Traffic Manager identifiziert den Anteil der Anfragen, die aus einem Rechenzentrum oder einem Teilbereich eines Rechenzentrums entfernt werden müssen, damit alle Anfragen bedient werden können.

• Traffic Manager berechnet dann die aggregierten Bereichsmetriken für jedes Ziel, um festzustellen, wie viele Anfragen jedes Failover-Rechenzentrum aufnehmen kann.

• Traffic Manager ermittelt dann, wie viel Traffic jedes Tarifs verlagert werden muss, und verlagert entweder einen Teil des Tarifs oder den gesamten Tarif durch Plurimog/Duomog, bis genug Traffic verlagert wurde. Zuerst verlagern wir den Traffic von Free-Kunden, und wenn es in einem Rechenzentrum keine Free-Kunden mehr gibt, verlagern wir den Traffic von Pro- und dann Business-Kunden, falls erforderlich.

Nehmen wir zum Beispiel Ashburn, Virginia: eine unserer MCPs. Ashburn verfügt über neun verschiedene Teilbereiche, die jeweils Traffic aufnehmen können. Am 28.8. trat bei einem dieser Teilbereiche, IAD02, ein Problem auf, das die Menge des zu bewältigenden Traffics reduzierte.

Während dieses Zeitraums leitete Duomog mehr Traffic von IAD02 an andere Teilbereiche von Ashburn weiter, wodurch sichergestellt wurde, dass Ashburn immer online war und die Performance während dieses Problems nicht beeinträchtigt wurde. Sobald IAD02 den Traffic wieder aufnehmen konnte, verlagerte Duomog den Traffic automatisch zurück. Diese Maßnahmen werden in der nachstehenden Zeitreihengrafik veranschaulicht, die den prozentualen Anteil des Traffics zeigt, der im Laufe der Zeit zwischen Teilbereichen mit verfügbarer Kapazität innerhalb von IAD02 verlagert wurde (in Grün dargestellt):

Obwohl wir im obigen Beispiel Anfragen pro Sekunde verwendet haben, ist die Messung von Anfragen pro Sekunde nicht genau genug, wenn es darum geht, den Traffic tatsächlich zu bewegen. Der Grund dafür ist, dass die verschiedenen Kunden unterschiedliche Ressourcenkosten für unseren Service haben; eine Website, die hauptsächlich aus dem Cache bedient wird, während die WAF deaktiviert ist, ist in Bezug auf die CPU viel billiger als eine Website, bei der alle WAF-Regeln aktiviert sind und das Caching deaktiviert ist. Deshalb erfassen wir die Zeit, die jede Anfrage in der CPU benötigt. Dann können wir die CPU-Zeit für jeden Tarif aggregieren, um den CPU-Zeitverbrauch pro Tarif zu ermitteln. Wir erfassen die CPU-Zeit in ms und nehmen einen Wert pro Sekunde, was eine Einheit von Millisekunden pro Sekunde ergibt.

Die CPU-Zeit ist eine wichtige Kennzahl, da sie sich auf die Latenzzeit und die Performance beim Kunden auswirken kann. Betrachten Sie zum Beispiel die Zeit, die eine Eyeball-Anfrage benötigt, um die Cloudflare-Frontline-Server vollständig zu durchlaufen: Wir nennen dies die cfcheck-Latenz. Wenn diese Zahl zu hoch ist, werden unsere Kunden das merken und eine schlechtere Nutzererfahrung haben. Wenn die cfcheck-Latenz hoch ist, liegt das in der Regel an der hohen CPU-Auslastung. Das folgende Diagramm zeigt das 95. Perzentil der cfcheck-Latenz im Vergleich zur CPU-Auslastung aller Rechner im selben Rechenzentrum und verdeutlicht die starke Korrelation:

Mit Traffic Manager können wir also die CPU-Zeit in einem Rechenzentrum überwachen und so sicherstellen, dass wir unseren Kunden die beste Erfahrung bieten und keine Probleme verursachen.

Nachdem wir die CPU-Zeit pro Tarif ermittelt haben, müssen wir herausfinden, wie viel von dieser CPU-Zeit in andere Rechenzentren verlagert werden soll. Zu diesem Zweck wird die CPU-Auslastung aller Server aggregiert, um eine einzige CPU-Auslastung für das gesamte Rechenzentrum zu erhalten. Fällt ein Teil der Server im Rechenzentrum aus, z. B. aufgrund eines Netzwerkausfalls oder eines Stromausfalls, werden die Anfragen an diese Server von Duomog automatisch an andere Stellen im Rechenzentrum weitergeleitet. Wenn die Anzahl der Server abnimmt, steigt die generelle CPU-Auslastung des Rechenzentrums. Traffic Manager hat drei Schwellenwerte für jedes Rechenzentrum: den maximalen Schwellenwert, den Zielschwellenwert und den zulässigen Schwellenwert:

• Maximal: die CPU-Stufe, bei der die Performance nachlässt und Traffic Manager eingreift

• Ziel: das Niveau, auf das der Traffic Manager die CPU-Auslastung zu reduzieren versucht, um den Nutzern einen optimalen Service zu bieten

• Zulässig: die Stufe, unterhalb derer ein Rechenzentrum von einem anderen Rechenzentrum weitergeleitete Anfragen empfangen oder aktive Verlagerungen rückgängig machen kann

Wenn ein Rechenzentrum den maximalen Schwellenwert überschreitet, ermittelt Traffic Manager das Verhältnis zwischen der gesamten CPU-Zeit aller Tarife und der aktuellen CPU-Auslastung und wendet es dann auf die Ziel-CPU-Auslastung an, um die Ziel-CPU-Zeit zu ermitteln. So können wir ein Rechenzentrum mit 100 Servern mit einem Rechenzentrum mit 10 Servern vergleichen, ohne dass wir uns Gedanken über die Anzahl der Server in jedem Rechenzentrum machen müssen. Dabei wird davon ausgegangen, dass die Last linear ansteigt, was der Realität so nahe kommt, dass die Annahme für unsere Zwecke gültig ist.

Die Zielquote entspricht der aktuellen Quote:

Darum gilt:

Durch Subtraktion der Ziel-CPU-Zeit von der aktuellen CPU-Zeit erhalten wir die zu verlagernde CPU-Zeit:

Wenn beispielsweise die aktuelle CPU-Auslastung im gesamten Rechenzentrum bei 90 % liegt, das Ziel 85 % beträgt und die CPU-Zeit über alle Tarife hinweg 18.000 beträgt, würde das folgendes Ergebnis bringen:

Dies würde bedeuten, dass Traffic Manager 1.000 CPU-Zeit bewegen müsste:

Da wir nun die gesamte für die Verlagerung benötigte CPU-Zeit kennen, können wir die Tarife durchgehen, bis die für die Verlagerung erforderliche Zeit erreicht ist.

Ein häufiges Problem, mit dem wir konfrontiert waren, war die Bestimmung des Zeitpunkts, an dem Traffic Manager in einem Rechenzentrum aktiv werden sollte – welche Kennzahl sollte überwacht werden, und was ist ein zulässiges Niveau?

Wie bereits erwähnt, haben verschiedene Services unterschiedliche Anforderungen an die CPU-Auslastung, und es gibt viele Fälle von Rechenzentren, die sehr unterschiedliche Nutzungsmuster aufweisen.

Um dieses Problem zu lösen, haben wir auf Machine Learning gesetzt. Wir haben einen Service entwickelt, der die maximalen Schwellenwerte für jedes Rechenzentrum automatisch anhand von kundenorientierten Indikatoren anpasst. Für unseren wichtigsten Service-Level-Indikator (SLI) haben wir uns für die cfcheck-Latenzmetrik entschieden, die wir bereits beschrieben haben.

Wir müssen aber auch ein Service-Level-Ziel (Service Level Objective, SLO) definieren, damit unsere Machine Learning-Anwendung den Schwellenwert anpassen kann. Wir haben den SLO auf 20 ms eingestellt. Vergleicht man unser SLO mit unserem SLI, so sollte unsere 95-prozentige cfcheck-Latenz niemals über 20 ms steigen, und wenn doch, müssen wir etwas unternehmen. Das folgende Diagramm zeigt die 95-prozentige cfcheck-Latenz im Zeitverlauf. Die Kunden werden unzufrieden, wenn die cfcheck-Latenz in den roten Bereich fällt:

Wenn Kunden eine schlechte Erfahrung machen, wenn die CPU zu hoch wird, dann ist das Ziel der maximalen Schwellenwerte von Traffic Manager, sicherzustellen, dass die Kunden-Performance nicht beeinträchtigt wird und den Traffic umzuleiten, bevor die Performance abnimmt. Der Traffic Manager Service ruft in einem geplanten Intervall eine Reihe von Metriken für jedes Rechenzentrum ab und wendet eine Reihe von Machine Learning-Algorithmen an. Nachdem die Daten um Ausreißer bereinigt wurden, wenden wir eine einfache quadratische Kurvenanpassung an, zudem testen wir derzeit einen linearen Regressionsalgorithmus.

Nach der Anpassung der Modelle können wir sie zur Vorhersage der CPU-Nutzung verwenden, wenn der SLI-Wert unserem SLO-Wert entspricht, und ihn dann als maximalen Schwellenwert verwenden. Wenn wir die CPU-Werte gegen die SLI-Werte auftragen, können wir deutlich sehen, warum diese Methoden für unsere Rechenzentren so gut funktionieren. Das können Sie im folgenden Diagramm für Barcelona sehen, das gegen die Kurvenanpassung bzw. die lineare Regressionsanpassung aufgetragen ist.

In diesen Diagrammen ist die vertikale Linie die SLO, und der Schnittpunkt dieser Linie mit dem angepassten Modell stellt den Wert dar, der als maximaler Schwellenwert verwendet wird. Dieses Modell hat sich als sehr genau erwiesen, und wir sind in der Lage, die SLO-Verstöße erheblich zu reduzieren. Werfen wir einen Blick darauf, wann wir mit dem Einsatz dieses Services in Lissabon begonnen haben:

Vor der Änderung war die cfcheck-Latenz ständig in die Höhe geschnellt, Traffic Manager hat jedoch keine Maßnahmen ergriffen, da der maximale Schwellenwert statisch war. Aber nach dem 29. Juli sehen wir, dass die chcheck-Latenz von cfcheck nie die SLO erreicht hat, weil wir ständig messen, um sicherzustellen, dass die Kunden nie von CPU-Erhöhungen betroffen sind.

Da wir nun einen maximalen Schwellenwert haben, müssen wir den dritten Schwellenwert für die CPU-Auslastung finden, der bei der Berechnung des zu verschiebenden Traffics nicht verwendet wird – den zulässigen Schwellenwert. Wenn ein Rechenzentrum unter diesem Schwellenwert liegt, verfügt es über ungenutzte Kapazitäten, die, solange es selbst keinen Traffic weiterleitet, anderen Rechenzentren bei Bedarf zur Verfügung gestellt werden. Um herauszufinden, wie viel jedes Rechenzentrum erhalten kann, verwenden wir dieselbe Methode wie oben, wobei wir den Ziel-Schwellenwert durch den zulässigen Schwellenwert ersetzen:

Darum gilt:

Zieht man die aktuelle CPU-Zeit von der zulässigen CPU-Zeit ab, erhält man die Menge an CPU-Zeit, die ein Rechenzentrum akzeptieren könnte:

Um herauszufinden, wohin der Traffic geschickt werden soll, ermittelt Traffic Manager die verfügbare CPU-Zeit in allen Rechenzentren und ordnet sie dann nach der Latenzzeit zu dem Rechenzentrum, das den Traffic verlagern soll. Er durchläuft jedes der Rechenzentren und nutzt dabei die gesamte verfügbare Kapazität auf der Grundlage der maximalen Schwellenwerte, bevor er zum nächsten weitergeht. Wenn wir herausfinden, welcher Tarif (bzw. der Traffic welches Tarifs) verlagert werden soll, gehen wir vom Tarif mit der niedrigsten Priorität zum Tarif mit der höchsten Priorität. Wollen wir jedoch herausfinden, wohin der Tarif verlagert werden soll, gehen wir in die entgegengesetzte Richtung.

Zur Verdeutlichung ein Beispiel:

Wir müssen 1.000 CPU-Zeiten von Rechenzentrum A verlagern und haben die folgende Nutzung pro Tarif: Free: 500 ms/s, Pro: 400 ms/s, Business: 200 ms/s, Enterprise: 1000 ms/s.

Wir würden 100 % von Free (500 ms/s), 100 % von Pro (400 ms/s), 50 % von Business (100 ms/s) und 0 % von Enterprise verlagern.

Nahegelegene Rechenzentren haben die folgende verfügbare CPU-Zeit: B: 300 ms/s, C: 300 ms/s, D: 1.000 ms/s.

Mit den Latenzzeiten: A-B: 100 ms, A-C: 110 ms, A-D: 120 ms.

Ausgehend von dem Tarif mit der niedrigsten Latenzzeit und der höchsten Priorität, der Maßnahmen erfordert, könnten wir die gesamte CPU-Zeit des Business-Tarifs in Rechenzentrum B und die Hälfte von Pro verlagern. Als Nächstes würden wir zu Rechenzentrum C wechseln und den Rest im Pro-Tarif und 20 % im Free-Tarif verlagern können. Der Rest im Free-Tarif könnte dann an das Rechenzentrum D weitergeleitet werden, was zu folgender Aktion führt: 50 % → Business, Pro: 50 % → B, 50 % → C, Free: 20 % → C, 80 % → D.

Genauso wie Traffic Manager ständig darauf achtet, dass Rechenzentren den Schwellenwert nicht überschreiten, versucht er auch, jeden weitergeleiteten Traffic in ein Rechenzentrum zurückzubringen, das aktiv Traffic weiterleitet.

Oben haben wir gesehen, wie Traffic Manager berechnet, wie viel Traffic ein Rechenzentrum von einem anderen Rechenzentrum empfangen kann – er nennt dies die verfügbare CPU-Zeit. Wenn eine aktive Verlagerung stattfindet, nutzen wir die verfügbare CPU-Zeit, um den Traffic wieder in das Rechenzentrum zu bringen – wir geben der Rückabwicklung einer aktiven Verlagerung immer Vorrang vor der Annahme von Traffic aus einem anderen Rechenzentrum.

Zusammengenommen ergibt dies ein System, das ständig System- und Kundenzustandsdaten für jedes Rechenzentrum misst und den Traffic so verteilt, dass jede Anfrage angesichts des aktuellen Zustands unseres Netzwerks verarbeitet werden kann. Wenn wir alle diese Verlagerungen zwischen den Rechenzentren auf einer Karte darstellen, sieht es ungefähr so aus: eine Karte aller Traffic Manager-Verlagerungen für einen Zeitraum von einer Stunde. Diese Karte zeigt nicht die gesamte Bereitstellung unserer Rechenzentren, aber sie zeigt die Rechenzentren, die während dieses Zeitraums verlagerten Traffic senden oder empfangen:

Rechenzentren in roter oder gelber Farbe sind ausgelastet und verlagern den Traffic auf andere Rechenzentren, bis sie grün werden, was bedeutet, dass alle Metriken als gesund angezeigt werden. Die Größe der Kreise gibt an, wie viele Anfragen von oder zu diesen Rechenzentren verlagert werden. Wo sich der Traffic hinbewegt, wird durch die Bewegung der Linien angezeigt. Auf weltweiter Ebene ist dies nur schwer zu erkennen. Zoomen wir also in die Vereinigten Staaten, um dies für den gleichen Zeitraum in Aktion zu sehen:

Hier sehen Sie, dass Toronto, Detroit, New York und Kansas City aufgrund von Hardware-Problemen nicht in der Lage sind, einige Anfragen zu verarbeiten. Daher werden diese Anfragen an Dallas, Chicago und Ashburn weitergeleitet, bis das Gleichgewicht für Nutzer und Rechenzentren wiederhergestellt ist. Sobald Rechenzentren wie Detroit in der Lage sind, alle eingehenden Anfragen zu bearbeiten, ohne den Traffic wegzuschicken, wird Detroit nach und nach die Weiterleitung von Anfragen an Chicago einstellen, bis alle Probleme im Rechenzentrum vollständig gelöst sind. Dabei sind die Nutzer online und werden nicht durch physische Probleme beeinträchtigt, die in Detroit oder an einem der anderen Standorte auftreten können, die Traffic senden.

Da der Traffic Manager in das Nutzererlebnis eingebunden ist, ist er eine grundlegende Komponente des Cloudflare-Netzwerks: Er sorgt dafür, dass unsere Produkte online bleiben und dass sie so schnell und zuverlässig wie möglich sind. Es ist unser Echtzeit-Load-Balancer, der dazu beiträgt, dass unsere Produkte schnell sind, indem er nur den notwendigen Traffic von den Rechenzentren wegleitet, die Probleme haben. Weil weniger Traffic verlagert wird, bleiben unsere Produkte und Services schnell.

Traffic Manager kann aber auch dazu beitragen, dass unsere Produkte online und zuverlässig bleiben, denn sie ermöglichen es unseren Produkten, vorauszusehen, wo Probleme mit der Zuverlässigkeit auftreten könnten, und die Produkte präventiv an einen anderen Ort zu verlagern. Die Browserisolierung arbeitet beispielsweise direkt mit Traffic Manager zusammen, um die Verfügbarkeit des Produkts zu gewährleisten. Wenn Sie eine Verbindung zu einem Cloudflare-Rechenzentrum herstellen, um eine gehostete Browser-Instanz zu erstellen, fragt Browserisolierung zunächst den Traffic Manager, ob das Rechenzentrum über ausreichend Kapazität verfügt, um die Instanz lokal zu betreiben. Wenn dies der Fall ist, wird die Instanz direkt an Ort und Stelle erstellt. Wenn nicht ausreichend Kapazität zur Verfügung steht, teilt Traffic Manager das nächstgelegene Rechenzentrum mit ausreichender Kapazität mit und hilft Browserisolierung so, dem Nutzer die bestmögliche Nutzererfahrung zu bieten.

Bei Cloudflare betreiben wir dieses riesige Netzwerk, um alle unsere verschiedenen Produkte und Kundenszenarien zu versorgen. Wir haben dieses Netzwerk auf Ausfallsicherheit ausgelegt: Zusätzlich zu unseren MCP-Standorten, die darauf ausgelegt sind, die Auswirkungen eines einzelnen Ausfalls zu reduzieren, verlagern wir den Traffic in unserem Netzwerk ständig, um auf interne und externe Probleme zu reagieren.

Das ist jedoch unser Problem – nicht Ihres.

Als noch Menschen dieses Problem beheben mussten, waren die Kunden und die Endnutzer die Leidtragenden. Um sicherzustellen, dass Sie immer online bleiben, haben wir ein intelligentes System entwickelt, das Hardware-Ausfälle erkennt und den Traffic in unserem Netzwerk präventiv ausbalanciert, um sicherzustellen, dass es online und so schnell wie möglich ist. Dieses System arbeitet schneller als irgendein Mensch – so können nicht nur unsere Netzwerktechniker nachts schlafen; alle unsere Kunden profitieren von einem besseren und schnelleren Service.

Und zu guter Letzt: Wenn Sie solche technischen Herausforderungen spannend finden, dann sollten Sie sich die offene Stelle des Traffic Engineering-Teams auf der Cloudflare Karriere-Seite ansehen!