Es gibt zwei verschiedene Aspekte von Anycast, die verstanden werden müssen, um Ihre spezielle Anfrage zu beantworten. Der erste Teil ist, wie Anycast-Adressen angekündigt und weitergeleitet werden. Die zweite ist, welche Herausforderungen TCP an eine Anycast-Adresse stellt und wie sie möglicherweise angegangen werden.
Ankündigung und Weiterleitung
Um die BGP-Tabelle auf einer akzeptablen Größe zu halten, filtert der meiste AS eingehende Ansagen, wenn die Präfixe zu lang sind. Für IPv4 ist der Schwellenwert in der Regel ein / 24-Präfix, was 256 Adressen bedeutet. Dies bedeutet, dass Sie für die Übertragung im öffentlichen Internet mindestens 256 Adressen benötigen.
Wenn Sie bereits ein eigenes / 24-Präfix haben, hindert ein Hosting-Anbieter nicht viel daran, es in Ihrem Namen anzukündigen. In diesem Fall könnte Anycasting für Sie so einfach sein, als würden Sie eine Reihe verschiedener Hosting-Anbieter finden, die bereit sind, diesen Service zum richtigen Preis anzubieten. Dann müssen Sie nur noch alle das Präfix in Ihrem Namen bekannt geben.
Sie können öffentlich zugängliche Informationen zu beworbenen Routen einsehen, um Anbieter zu finden, die bereits Präfixe im Namen ihrer Kunden ankündigen, um Sie zu Anbietern zu führen, die diese Art von Service wahrscheinlich anbieten. Ein Tool, um dies in Routing-Tabellen nachzuschlagen, ist bgp.he.net .
Wenn Sie kein eigenes Präfix haben und eines von einem Anbieter wünschen, ist es wichtig zu verstehen, was die oben genannten Einschränkungen für diesen Anbieter bedeuten.
Der Anbieter verfügt über genügend IP-Adressen, um ein Anycast-Präfix konfigurieren zu können. Sobald sie dies tun, verpflichten sie sich jedoch, alle 256 Adressen als Anycast zu verwenden. Alle 256 Adressen müssen an genau denselben Standorten gehostet werden.
Aus diesem Grund werden manchmal 256 Adressen zugewiesen, um nur eine davon für einen Anycast-Dienst zu verwenden. Dies könnte die erste Gelegenheit für Sie sein. Ein Anbieter, der bereits ein Präfix sendet, verfügt möglicherweise über 250 nicht verwendete Anycast-Adressen. Wenn Ihr Service für einen Anbieter "interessant" genug ist, ist er möglicherweise bereit, Sie als Hosting an einer dieser verbleibenden Adressen zu mieten. Eine wichtige Einschränkung ist, dass Sie genau an den gleichen Orten wie der primäre Anycast-Dienst gehostet werden müssen. Und wahrscheinlich wäre eine Vereinbarung erforderlich, in der sie Ihren Dienst nach eigenem Ermessen verschieben, da es ihr primärer, nicht übertragener Dienst ist, der entscheidet, wo Hosting benötigt wird.
Bei den meisten der oben genannten Punkte wird ungefähr eine 1: 1-Entsprechung zwischen dem Hosting eines Dienstes durch den Anbieter und der Ankündigung der Präfixe angenommen.
Wenn der Hosting-Anbieter über ein eigenes redundantes Backbone und eigene Rechenzentren verfügt, kann er ein Präfix an einer anderen Gruppe von Standorten ankündigen, an denen er es hostet. Darüber hinaus können sie intern längere Präfixe als Unicast oder Anycast weiterleiten.
Wenn der Anbieter beispielsweise eine / 22 in vier verschiedenen POPs ankündigt und zwischen diesen ein redundantes Netzwerk besteht (z. B. ein Ring aus vier Verbindungen), kann er intern eine / 24 oder / 25 an jede POP weiterleiten und möglicherweise eine beiseite legen / 28, die an alle POPs gesendet werden sollen (was effektiv bedeutet, dass sie vom POP bedient werden, wo die Pakete zuerst in ihr Netzwerk gelangen).
Wenn Sie einen Anbieter finden, der sowohl über das redundante Backbone als auch über Rechenzentren verfügt, ist es für einen solchen Anbieter einfach viel einfacher, eine seiner eigenen IP-Adressen für Ihren Dienst zu übertragen. Beachten Sie jedoch, dass Ihr Dienst dabei einen CAM-Tabelleneintrag in jedem seiner Backbone-Router belegt. Und dafür müsstest du bezahlen.
TCP und Anycast
Wie einige der Kommentare gezeigt haben, ist TCP ein Stateful-Protokoll. Selbst wenn Sie Ihren Webdienst als zustandslos betrachten, hat er auf der TCP-Ebene immer noch den Status. Dies hat zur Folge, dass beim naiven Anycasting eines TCP-basierten Dienstes die Benutzer sehr häufig die Verbindung zurücksetzen.
Dieses Problem kann behoben werden, indem eine weitere Ebene vor den eigentlichen Webservern platziert wird. Was benötigt wird, ist eine Schicht von Knoten, die empfangene TCP-Pakete an den richtigen Webserver weiterleiten können und dies konsistent über eine Verbindung hinweg. Bisher beschreibt dies ziemlich genau einen Standard-DSR-basierten Load Balancer.
Da es jedoch mehrere Instanzen dieses Load Balancers gibt, müssen sie den Status gemeinsam nutzen. Eine verteilte Hash-Tabelle ist eine Datenstruktur, die für diese Schicht verwendet werden kann.
Darüber hinaus müssen Pakete aus der Lastausgleichsschicht unverändert an das Backend weitergeleitet werden. IP-Routing basierend auf der Ziel-IP des ursprünglichen Pakets löst dieses Problem nicht, da diese Zieladresse immer noch die Anycast-Adresse ist, sodass das Paket niemals zum Backend gelangen würde, sondern einfach zum Load Balancer zurückspringen und bis zum TTL abgelaufen.
Typische Load Balancer beheben dies, indem sie die Ziel-MAC-Adresse ändern und weiterleiten, wodurch das IP-Routing umgangen wird. Dies funktioniert nur, wenn sich Ihr Load Balancer und Ihre Backends an einem einzigen Standort befinden und das Netzwerk zwischen ihnen vollständig ohne Router zwischen Load Balancer und Backends geschaltet ist.
Es gibt jedoch einen anderen Ansatz zur Lösung dieses Problems. Pakete vom Load Balancer zum Backend können über einen IP-Tunnel gesendet werden. Der äußere IP-Header enthält eine Zieladresse, bei der es sich um eine Unicast-Adresse handelt, die auf ein Backend verweist. Der innere IP-Header ist unverändert und enthält die Client-IP als Quell- und Anycast-IP als Ziel.
In diesem Setup wird die Quell-IP des äußeren Headers größtenteils nicht verwendet. Im Prinzip soll es eine Unicast-Adresse des Load Balancers sein, der das Paket empfängt. Einige Dienste (z. B. Facebook) kopieren jedoch die Client-IP aus dem inneren Header als Quell-IP in den äußeren Header. Dieser Fehler von Facebook kann von außen erkannt werden, da die getunnelten Pakete manchmal einen ICMP-Fehler auslösen, der direkt an den Client zurückgesendet wird.
Es ist nicht erforderlich, dass der innere und der äußere Header dieselbe IP-Version verwenden. Die Unicast-Adressen, die für Load Balancer und Backends benötigt werden, können alle IPv6 sein, sodass die Anzahl der Load Balancer und Backends nicht durch die Verfügbarkeit von IPv4-Adressen begrenzt ist.
Die Verwendung eines Entwurfs wie oben skizziert hat den zusätzlichen Vorteil, dass die Load Balancer in diesem Setup normalerweise nur einen kleinen Teil der Hardware benötigen und nur die Load Balancer über die Anycast-Adresse erreicht werden müssen. Dies bedeutet, dass es weniger problematisch ist, wenn Ihre Anycast-Adresse aufgrund des Huckepacks auf ein Anycast-Präfix, das hauptsächlich einem anderen Dienst zugewiesen ist, mit einer kurzen Warnung verschoben werden muss.
Tücken
Offensichtlich ist das oben skizzierte Setup komplizierter als die einfache Bereitstellung einer Reihe von eigenständigen Webservern. Komplizierte Setups sind in der Regel eine Quelle der Nichtverfügbarkeit. Daher muss ein gewisser Arbeitsaufwand in ein solches System gesteckt werden, damit es robust genug ist, um zuverlässiger als die Alternative zu sein. Dies bedeutet, dass dies eher als Teil eines CDN-Dienstes als für einen einzelnen Webdienst bereitgestellt werden sollte.
Wenn Sie versuchen, Anycast-TCP mit etwas zu betreiben, das einfacher ist als das oben beschriebene Setup, kann es sehr gut zu Problemen mit Routen kommen, die sich während der Verbindung ändern, und infolgedessen werden Benutzer zurückgesetzt.
Anycast kann die Verfügbarkeit, Latenz und den Lastausgleich verbessern. Es ist jedoch keine Silberkugel. Anycast gleicht die Last aus, und Sie können mit der Last skalieren, indem Sie weitere Knoten hinzufügen. Erwarten Sie jedoch keine annähernd perfekt ausgeglichene Last über die von anycast erreichten Knoten. In dem oben beschriebenen Setup mit einer verteilten Lastausgleichsschicht erhalten die Lastausgleicher selbst möglicherweise keine gleichmäßige Last, können jedoch die Last gleichmäßig auf die Backends verteilen.
Verlassen Sie sich für die Verfügbarkeit nicht auf eine einzige Anycast-IP. Wenn einer Ihrer Knoten ausfällt, wird er vom Routing möglicherweise nicht automatisch erkannt. Dies betrifft nicht alle Clients, aber bei einer Teilmenge von Clients werden die Pakete möglicherweise an einen Knoten weitergeleitet, der inaktiv ist. Daher ist für diese Clients Ihre Anycast-IP-Adresse nicht verfügbar. Wenn Sie Redundanz wünschen, benötigen Sie mehrere Anycast-IP-Adressen.
Die Latenz kann gut sein, solange sich die Routen während einer Verbindung nicht ändern. Sobald der TCP-Handshake abgeschlossen ist, müssen Sie für die Dauer der TCP-Verbindung ein bestimmtes Backend verwenden. Pakete müssen vom Client zum Load Balancer zum Backend und zum Client gehen. Dieses dreieckige Routing kann die Latenz erhöhen. Es gibt eine Verringerung der Latenz durch Anycasts und die Möglichkeit, das nächstgelegene Backend auszuwählen. Wenn Sie jedoch nicht nur zwei, sondern drei Beine auf dem Roundtrip haben, kann dies die Latenz erhöhen. Nur das Sammeln vieler realer Messungen zeigt Ihnen, welcher der beiden Faktoren mehr wiegt.