DE202015009264U1

DE202015009264U1 - Anycast-basiertes, wide-area-verteiltes kartierungs- und lastverteilungssystem

Info

Publication number: DE202015009264U1
Application number: DE202015009264.0U
Authority: DE
Original assignee: Google LLC
Current assignee: Google LLC
Priority date: 2014-01-27
Filing date: 2015-01-13
Publication date: 2017-02-15
Anticipated expiration: 2025-01-14
Also published as: US9467506B2; EP3591944B1; WO2015112380A1; US20150215388A1; EP3100438B1; DK3591944T3; EP3100438A1; DK3100438T3; CN106031133A; EP3591944A1; CN106031133B

Abstract

Domain-Name-System (DNS), umfassend: einen DNS-Server, der Folgendes beinhaltet: eines Anycast-Moduls, konfiguriert, um das Annehmen einer Anforderung einer Netzwerkadresse eines Content-Servers, und da Antworten auf die Anforderung mit einer Netzwerkadresse, ausgewählt aus einer Vielzahl von Anycast-Netzwerkadressen, eines Lastverteilungsmoduls, das kommunizierbar mit dem Anycast-Modul gekoppelt ist, konfiguriert ist, um: Lastinformation von zumindest einem einer Vielzahl von Content-Servern zu empfangen, um basierend auf den Lastinformationen einen überlasteten Content-Server zu identifizieren, und den überlasteten Content-Server anzuweisen, das Bekanntmachen einer oder mehrerer der Vielzahl von Anycast-Netzwerk-Adressen einzustellen, und einer Vielzahl von Content-Servern, die in der Lage sind, mit dem DNS-Server zu kommunizieren, wobei jeder der Vielzahl von Content-Servern beinhaltet: ein Bekanntmachungsmodul, das dafür konfiguriert ist, um: Anweisungen von dem DNS-Server zu empfangen, bestimmte der Vielzahl von Anycast-Netzwerkadressen bekanntzumachen und die bestimmten der Vielzahl von Anycast-Netzwerkadressen bekanntzumachen, und ein Lastüberwachungsmodul, das konfiguriert ist, um: mit dem Server verbundene Lastinformationen zu sammeln und die Lastinformationen an den DNS-Server zu kommunizieren.

Description

TECHNISCHES GEBIET
Diese Offenbarung bezieht sich auf das Gebiet von Kommunikationsnetzen und insbesondere verteilte Kartierung und Lastverteilung innerhalb von Kommunikationsnetzen.
BESCHREIBUNG DER VERWANDTEN TECHNOLOGIE
In einigen Systemen, wie zum Beispiel Domain Name Server (DNS) Systemen, kann es schwierig sein, den realen Ort des Benutzers zu bestimmen, der die Anfrage sendet. Wenn ein Benutzer eine DNS-Anfrage sendet, wird die Anfrage zunächst an einen Domain-Name-Resolver gesendet. Der Domain-Name-Resolver sendet wiederum eine Anfrage an einen Domain-Name-Server, um eine mit dem Domänennamen assoziierte Netzwerkadresse (eines Content-Servers) zu erhalten. Diese Netzwerkadresse wird für den Zugriff auf den gewünschten Inhalt an den Benutzer gesendet. Bei einigen verteilten Systemen kann eine einzelne Adresse mehreren geografisch getrennten Servern entsprechen.
KURZDARSTELLUNG
Gemäß einem Aspekt kann der in dieser Offenbarung beschriebene Gegenstand in einem Verfahren für den Lastverteilung über eine Menge von Content-Servern von einem Domain-Name-System-(DNS)Server realisiert werden. Das Verfahren beinhaltet das Empfangen einer Anforderung einer Netzwerkadresse eines Content-Servers, das Antworten auf die Anforderung mit einer Netzwerkadresse, die aus einer Vielzahl von Anycast-Netzwerkadressen ausgewählt wird, Empfangen von Lastinformationen von zumindest einem einer Vielzahl von Content-Servern und Anweisen, basierend auf den empfangenen Lastinformationen, dass ein oder mehrere überlastete Content-Server einstellen, eine oder mehrere einer Vielzahl von Anycast-Netzwerkadressen bekanntzumachen.
Gemäß einem weiteren Aspekt kann der in dieser Offenbarung beschriebene Gegenstand in einem Verfahren für das Antworten auf Kommunikationen, die auf einem Server von einem oder mehreren Client-Computern in einem Netzwerk empfangen werden, implementiert werden. Das Verfahren beinhaltet das Empfangen einer Vielzahl von Anycast-Netzwerkadressen von einem Domain-Name-System-(DNS)Server, Bekanntmachung der Vielzahl von Anycast-Netzwerkadressen an ein Netzwerk, Senden von Lastinformationen an den DNS-Server und Einstellen der Bekanntmachung von einer oder mehreren der Vielzahl von Anycast-Netzwerkadressen auf Basis von Anweisungen, die von dem DNS-Server erhalten wurden.
Gemäß einem weiteren Aspekt kann der in dieser Offenbarung beschriebene Gegenstand in einem Domain-Name-System (DNS) implementiert werden, das einen DNS-Server und eine Vielzahl von Content-Servern beinhaltet, die mit dem DNS-Server kommunizieren. Der DNS-Server beinhaltet ein Anycast-Modul und ein Lastverteilungsmodul. Das Anycast-Modul ist konfiguriert, eine Anforderung einer Netzwerkadresse von einem Content-Server anzunehmen und auf die Anforderung mit einer Netzwerkadresse, ausgewählt aus einer Vielzahl von Anycast-Netzwerkadressen, zu antworten. Die Lastverteilungsmodul, welches kommunizierbar mit dem Anycast-Modul gekoppelt ist, ist konfiguriert, Lastinformation von mindestens einem einer Vielzahl von Content-Servern zu empfangen, einen überladenen Content-Server auf Basis der Lastinformationen zu identifizieren und die überladenen Content-Server anzuweisen, das Bekanntmachen einer oder mehrerer der Vielzahl von Anycast-Netzwerkadressen einzustellen. Jeder der Vielzahl von Content-Servern enthält ein Bekanntmachungsmodul und ein Lastüberwachungsmodul. Das Bekanntmachungsmodul ist konfiguriert, Anweisungen von dem DNS-Server zu empfangen, bestimmte der Vielzahl von Anycast-Netzwerkadressen bekanntzumachen und die bestimmten der Vielzahl von Anycast-Netzwerkadressen bekanntzumachen. Das Lastüberwachungsmodul ist konfiguriert, mit dem Server assoziierte Lastinformation zu sammeln und die Lastinformation an den DNS-Server zu kommunizieren.
Gemäß einem weiteren Aspekt kann der in dieser Offenbarung beschriebene Gegenstand in einem nicht-flüchtigen computerlesbaren Speichermedium mit darauf codierten Anweisungen implementiert werden, welche, wenn sie von einem Prozessor ausgeführt werden, den Prozessor veranlassen, ein Verfahren durchzuführen. Das Verfahren beinhaltet das Empfangen einer Anforderung einer Netzwerkadresse eines Content-Servers, das Antworten auf die Anforderung mit einer Netzwerkadresse, die aus einer Vielzahl von Anycast-Netzwerkadressen ausgewählt wird, Empfangen von Lastinformationen von zumindest einem einer Vielzahl von Content-Servern und Anweisen, basierend auf den empfangenen Lastinformationen, dass ein oder mehrere überlastete Content-Server einstellen, eine oder mehrere einer Vielzahl von Anycast-Netzwerkadressen bekanntzumachen.
Details einer oder mehrerer Implementierungen des in dieser Spezifikation beschriebenen Gegenstands werden in den beigefügten Zeichnungen und in der nachstehenden Beschreibung dargelegt. Andere Funktionen, Aspekte und Vorteile werden durch die Beschreibung, die Zeichnungen und die Ansprüche offensichtlich. Es ist zu beachten, dass die relativen Dimensionen der Figuren möglicherweise nicht maßstabsgetreu sind.
KURZBESCHREIBUNG DER ZEICHNUNGEN
1 zeigt ein beispielhaftes Domain-Name-System.
2 zeigt ein beispielhaftes Netzwerk zur Veranschaulichung von Anycast-basierter Lastverteilung.
3 zeigt ein beispielhaftes Routing von Netzwerkverkehr zwischen Clients und Servern im in 2 dargestellten Netzwerk.
4 zeigt ein weiteres beispielhaftes Routing von Netzwerkverkehr zwischen Clients und Servern im in 2 dargestellten Netzwerk.
5 zeigt einen Ansatz zur Erhaltung des Zustands von laufenden Abfragen.
6 zeigt einen beispielhaften Prozess für Anycast-basierte Lastverteilung, der von einem DNS-Server durchgeführt.
7 zeigt einen beispielhaften Prozess für Anycast-basierte Lastverteilung, der von einem Server durchgeführt.
8 zeigt ein beispielhaftes Blockdiagramm eines DNS-Servers.
9 zeigt ein beispielhaftes Blockdiagramm eines Servers.
Entsprechende Referenznummern und Kennzeichnungen in den verschiedenen Zeichnungen zeigen entsprechende Elemente an.
AUSFÜHRLICHE BESCHREIBUNG
1 zeigt ein beispielhaftes Domain-Name-System 100. Insbesondere zeigt 1 eine Vielzahl von Clients: Client-1 102a, Client-2 102b, Client-3 102c, Client-4 102d, ..., Client-N 102n, die mit einer Vielzahl von Domain-Name-System-(DNS)Resolvern kommunikativ gekoppelt sind: DNS-Resolver-1 104a, DNS-Resolver-2 104b, DNS-Resolver-3 104c, DNS-Resolver-4 104d, ..., DNS-Resolver-N 104n. Jeder DNS-Resolver 104a–104n kann mit einem DNS-Server 106 kommunizieren.
Die Vielzahl von Clients 102a–102n kann eine beliebige Computervorrichtung beinhalten, die über ein Netzwerk kommunizieren kann, wie beispielsweise einen PC, Laptop, ein Smartphone, einen Tablet-Computer usw., ist aber nicht darauf beschränkt. Während jede der Vielzahl von Clients 102a–102n gezeigt wird, wie er mit seinem relativen DNS-Resolver 104a–104n kommuniziert, versteht sich, dass mehr als einer der Vielzahl von Clients 102a–102n mit demselben DNS-Resolver kommunizieren kann. Zum Beispiel kann Client-2 102b, der gezeigt wird, wie er mit dem DNS-Resolver-2 104b kommuniziert, anstatt mit dem DNS-Resolver-4 104d kommunizieren.
Jeder der Vielzahl von Clients 102a–102n kann Domain Name Resolution Anforderungen an seinen jeweiligen DNS-Resolver 104a–104n senden. Zum Beispiel sendet Client-1 102a eine Domain-Name-Adresse „www.beispiel.de” an den DNS-Resolver-1 104a. Die DNS-Resolver 104A 104n können Anwendungen sein, die DNS-Abfragen verwenden, um Informationen über Domain-Names von Servern abzufragen. Zum Beispiel kann der DNS-Resolver-1 104a den DNS-Server 106 nach der IP-Adresse eines mit dem Domain-Namen-Adresse assoziierten Content-Servers, wie beispielsweise „www.beispiel.de”, abfragen. Der DNS-Server 106 wiederum antwortet, indem er dem DNS-Resolver 104a eine oder mehrere IP-Adressen des mit der Domain-Name-Adresse „www.beispiel.de” assoziierten Content-Servers zurückgibt.
In einigen Implementierungen können die DNS-Resolver 104a–104n in geographischer Nähe ihrer jeweiligen Clients 102a–102n stehen. In einigen Implementierungen können sich die DNS-Resolver 104–104n auf ihrem jeweiligen Client 102a–102n befinden. In einigen anderen Implementierungen können sich die DNS-Resolver 104a–104n auf dem Gateway des Internet-Service-Providers des jeweiligen Clients 102a–102n befinden. In einigen Implementierungen kann der DNS-Resolver 104a–104n einen oder mehrere DNS-Server rekursiv abfragen, um die IP-Adresse der von den Clients 102a–102n angeforderten Domain-Name-Adresse zu erhalten. In einigen anderen Implementierungen können die Clients 102a–102n Abfragen direkt an den DNS-Server 106 senden, anstatt die Abfragen über ihre zugehörigen DNS-Resolver 104a–104n zu leiten.
Wie oben erwähnt, antwortet der DNS-Server 106 auf Kommunikationen, wie beispielsweise Domain-Name-Adressen-Abfragen, die von den DNS-Resolvern 104a–104n oder Clients 102a–102n empfangen werden. Der DNS-Server 106 kann antworten, indem er die angeforderten Informationen, d. h. die IP-Adresse des angefragten Domain-Names, bereitstellt, einen Zeiger auf einen anderen Server bereitstellt, der helfen kann, den angefragten Domain-Name aufzulösen, oder mit einer Fehlermeldung antworten, um anzuzeigen, dass der DNS-Server 106 keine der Abfrage zugeordnete Informationen besitzt.
In einigen Implementierungen kann der DNS-Server 106 ein autoritativer DNS-Server für einen fortlaufenden Abschnitt eines DNS-Namespace sein. Ein DNS-Server kann für einen fortlaufenden Abschnitt des DNS-Namespace autoritativ sein, wenn der DNS-Server-Informationen bezüglich dieses Abschnitts des Namespace hat. Zum Beispiel kann in einigen Implementierungen der DNS-Server 106 für den Namespace „www.beispiel.de” autoritativ sein. In solchen Implementierungen kann der DNS-Server 106 Ressourcen-Datensätze in einer DNS-Datenbank enthalten. Die Ressourcen-Datensätze können IP-Adressen von einem oder mehreren mit „www.beispiel.de.” assoziierten Web-Servern mit einschließen.
In einigen anderen Implementierungen kann die vom DNS-Server 106 zurückgegebene IP-Adresse eine IP-Adresse eines anderen DNS-Servers sein. In einigen solchen Implementierungen mag der DNS-Server 106 nicht ein autoritativer Server für den gewünschten Domain-Namen sein und kann eine IP-Adresse eines Forwarder-DNS-Servers zurückgeben, der den Domain-Name für DNS-Server 106 auflöst.
Der Domain-Name-Server kann den Ort des Benutzers auf Basis des Orts des Domain-Namens Resolvers bestimmen und die Netzwerkadresse eines Content-Servers senden, der dem Domain-Name-Resolver am nächsten ist und der die zusätzliche Last verarbeiten kann. Benutzer von deutlich unterschiedlichen geografischen Regionen können aber denselben Domain-Name-Resolver verwenden, um den Domain-Name aufzulösen. Dies bedeutet, dass der Content-Server, deren Netzwerkadresse von dem Domain-Name-Server gesendet wurde, unter Umständen nicht der Content-Server ist, der dem Benutzer am nächsten ist. Während also der Domain-Name-Server in der Lage sein mag, die Last über die Menge von verteilten Content-Servern auszugleichen, stellt der Domain-Name-Server unter Umständen nicht den am besten geeigneten Content-Server für den Benutzer bereit.
Anycast bietet die Möglichkeit, Abfragen von Benutzern an Content-Server zu leiten, die den Benutzern am nächsten sind. Mit Anycast antwortet ein Server, wie beispielsweise ein Domain-Name-Server, auf die Anforderung von dem Domain-Name-Resolver mit einer Anycast-Adresse. Darüber hinaus macht jeder der geographisch verteilten Content-Server die gleiche Anycast-Adresse bekannt. Wenn also der Benutzer die Anycast-Adresse als die Adresse verwendet, wo auf Inhalte zugegriffen werden soll, dann routen Zwischen-Router die Anforderung des Benutzers automatisch zum nächsten (oder kostengünstigsten) Content-Server. Anforderungen von dem Benutzer würden aber zu demselben nächsten Content-Server geroutet werden, unabhängig von der Last auf dem Server. Mit anderen Worten, Anycast ist die Last nicht bekannt. Während also Anycast die Fähigkeit hat, Benutzeranforderungen an den am besten geeigneten Content-Server zu leiten, hat Anycast nicht die Fähigkeit, die Last auf der Menge von verteilten Content Server auszugleichen.
In einigen Implementierungen kann der DNS-Server 106 eine Vielzahl von Anycast-IP-Adressen pflegen, die einer Domain-Name-Adresse zugeordnet sind. Zum Beispiel kann der DNS-Server 106 eine Menge von n Anycast-IP-Adressen {IP1, IP2, IP3, IP4, ..., IPN} verwalten, die der Domain-Name-Adresse „www.beispiel.de” zugeordnet sind. In einigen Implementierungen kann n einen Wert von etwa 100 bis etwa 200 haben. In einigen anderen Implementierungen kann n einen Wert von etwa 10 bis etwa 100, etwa 200 bis etwa 300, oder sogar Werte von mehr als 300 haben. Der DNS-Server 106 gibt für jede empfangene Abfrage für die Domain-Name-Adresse eine Teilmenge von Anycast-IP-Adressen zurück, ausgewählt aus der Vielzahl von Anycast-IP-Adressen. Zum Beispiel kann in einigen Implementierungen als Antwort auf die Anfrage für „www.beispiel.de”, die von dem DNS-Resolver-1 104a erhalten wurde (und von Client-1 102a ausging), der DNS-Server 106 eine Anycast-IP-Adresse zurückgeben: die Anycast-IP-Adresse IP1, ausgewählt aus der Menge von n Anycast-IP-Adressen. Der DNS-Server 106 gibt, wenn die nächste Abfrage für „www.beispiel.de” von dem DNS-Resolver-2 104b empfangen wird, die Anycast-IP-Adresse IP2 zurück. In ähnlicher Weise gibt der DNS-Server 106 auf nachfolgende Abfragen für „www.beispiel.de” von dem DNS-Resolver-3 104c, dem DNS-Resolver-4 104d, dem DNS-Resolver-n 104n die Anycast-IP-Adressen IP3, IP4 bzw. IPn zurück.
In einigen Implementierungen kann der DNS-Server 106, für jede erhaltene Abfrage mehr als eine dem Domain-Namen zugeordnete Anycast-IP-Adresse zurückgeben, ausgewählt aus den n Anycast-IP-Adressen. Zum Beispiel kann der DNS-Server 106 als Antwort auf die Abfrage für „www.beispiel.de” von dem DNS-Resolver-1 104a Anycast-IP-Adressen IP1, IP2, IP3, und IP4 zurückgeben, ausgewählt aus den Anycast-IP-Adressen IP1, IP2, IP3, IP4, IP5, ..., IPN. Der Client kann dann eine Anycast-IP-Adresse aus der empfangenen Teilmenge von Anycast-IP-Adressen wählen, um Inhalt von den Content-Servern abzufragen.
In einigen Implementierungen kann der DNS-Server 106 für jede empfangene Abfrage die Teilmenge der Anycast-IP-Adressen aus der Menge von n Anycast-IP-Adressen in einer Round-Robin-Modell oder einer anderen strukturierten Art und Weise auswählen und auf die Abfrage mit der ausgewählten Anycast-IP-Adresse antworten. In einigen anderen Implementierungen kann der DNS-Server 106 zufällig oder pseudo-zufällig eine Anycast-IP-Adresse aus der Menge von n Anycast-IP-Adressen auswählen.
2 zeigt ein beispielhaftes Netzwerk 200 zur Veranschaulichung von Anycast-basierter Lastverteilung. Insbesondere zeigt 2 vier Clients: Client-1 202a, Client-2 202b, Client-3 202c und Client-4 202d, und drei Server: Server-1 204a, Server-2 204b und Server-3 204c, die über fünf IP-Router: Router-1 206a, Router-2 206b, Router-3 206c, Router-4, 206d und Router-5 206e, kommunizieren. Das Netzwerk 200 beinhaltet auch einen DNS-Server 208, der mit den vier Clients und den drei Servern kommunizieren kann. Es versteht sich, dass andere Netzwerke eine andere Anzahl und Konfiguration von Clients, Servern und Router beinhalten können und dass die Anycast-basierte Lastverteilung, die nachstehend mit Bezug auf das beispielhafte Netzwerk 200 erörtert wird, ohne Weiteres in solchen anderen Netzwerken implementiert werden können.
Der DNS-Server 208 kann ähnlich dem DNS-Server 106 sein, der oben in Bezug auf 1 erörtert wurde. Als solches kann der DNS-Server 208 Anycast-IP-Adressen, ausgewählt aus einer Menge von Anycast-IP-Adressen, Clients bereitstellen, die Auflösung einer Domain-Name-Adresse anfordern. Zum Beispiel kann der DNS-Server 208 mit dem Domain-Name „www.beispiel.de” assoziierte Anycast-IP-Adressen bereitstellen. In einigen Implementierungen können die vom DNS-Server 208 bereitgestellten Anycast-IP-Adressen IP-Adressen von Web-Content-Servern sein. In einigen anderen Implementierungen können die IP-Adressen IP-Adressen anderer DNS-Server sein, die zugewiesen sind, den Domain-Name „www.beispiel.de” für DNS-Server 208 aufzulösen.
Der DNS-Server 208 kommuniziert auch mit jedem der drei Server: Server-1 204a, Server-2 204b und Server-3 204c (explizite Verbindungen aus Gründen der Übersichtlichkeit nicht dargestellt). Der DNS-Server 208 stellt Server-1 204a, Server-2 204b und Server-3 204c eine Menge von Anycast-IP-Adressen, die mit einem Domain-Name assoziiert sind. Zum Beispiel kann der DNS-Server 208 eine Menge von Anycast-IP-Adressen {IP1, IP2, IP3, IP4, ... IPn} für jeden der drei Server: Server-1 204a, Server-2 204b und Server-3 204c, bereitstellen, die mit dem Domain-Name „www.beispiel.de” assoziiert sind. Jeder der drei Server kann dann die komplette Menge von Anycast-IP-Adressen bekanntmachen. In einigen Implementierungen kann der DNS-Server 208 den Servern 204a–204c auch eine Vielzahl von Anycast-IP-Adressen bereitstellen, die anderen Domain-Name-Adressen zugeordnet sind.
Der DNS-Server 208 kann ebenso Lastmetriken von jedem Server empfangen. Die Lastmetriken können zum Beispiel Server-Antwortzeit, Anzahl von Hits, Ressourcenauslastung, Latenz, Server-Status usw. beinhalten. Wie nachstehend im Detail erörtert, kann der DNS-Server 208 auf Basis der von jedem Server empfangenen Lastmetriken den Server anweisen, das Bekanntmachen einer oder mehrerer Anycast-IP-Adressen einzustellen.
Die vier Clients: Client-1 102a, Client-2 102b, Client-3 102c, Client-4 102d können ähnlich den N Clients: Client-1 202a, Client-2 202b, Client-3 202c, Client-4 202d, ..., Client-N 102n, sein, die oben in Bezug auf 1 erörtert wurden. Darüber hinaus wird angenommen, dass jeder der vier Clients eine oder mehrere Anycast-IP-Adressen von dem DNS-Server 208 empfangen hat. Beispielsweise wird angenommen, dass Client-1 202a, Client-2 202b, Client-3 202c und Client-4 202d Anycast-IP-Adressen IP1, IP2, IP3 bzw IP4 von einem DNS-Server 208 erhalten haben.
Wie oben erwähnt, kann jeder der drei Server: Server-1 204a, Server-2 204b und Server-3 204c, eine Menge von Anycast-IP-Adressen bekanntmachen. Durch das Bekanntmachen einer Menge von Anycast-IP-Adressen, zeigt jeder Server 204a–204c an, dass er Client-Anfragen annehmen kann, die mit einer der bekanntgemachten IP-Adressen assoziiert sind. Jeder Server 204a–204d sendet ebenso Lastmetriken an den DNS-Server. Wie oben erwähnt, können die Lastmetriken zum Beispiel Server-Antwortzeit, Anzahl von Hits, Ressourcenauslastung, Latenz, Server-Status usw. beinhalten. Jeder Server 204a–204d empfängt ebenso Anweisungen vom DNS-Server 208, das Bekanntmachen einer oder mehrerer Anycast-IP-Adressen aus der Menge von Anycast-IP-Adressen zu beginnen oder einzustellen.
Router 206a–206e können Netzwerk-Datenverkehr zwischen den Clients 202a–202d, den Servern 204a–204d und dem DNS-Server 208 routen. In einigen Implementierungen können die Router 206a–206e IP-Router sein. Als solche routen die Router 206a–206e IP-Pakete, die an einem ihrer Ports empfangen werden, zu einem anderen ihrer Ports, wobei das Routing zum Teil auf der in dem Header des empfangenen IP-Pakets enthaltenen Ziel-IP-Adresse basiert ist. Die Router 206a–206e können Bekanntmachungen von jedem der Server 204a–204c empfangen. Auf der Grundlage dieser Bekanntmachungen können die Router 206a–206e ihre jeweiligen Routing- und Forwarding-Tabellen aktualisieren. In einigen Implementierungen können die Router 206a–206e das Border-Gateway-Protocol (BGP) verwenden, um Routing-Tabellen aufzubauen und Routing-Informationen auszutauschen. In einigen anderen Implementierungen können die Router 206a–206e das Open-Shortest-Path-First-(OSPF)Protokoll verwenden, um Routing-Tabellen aufzubauen und Routing-Informationen auszutauschen.
3 zeigt ein beispielhaftes Routing von Netzwerkverkehr zwischen Clients 202a–202d und Servern 204a–204c in dem in 2 dargestellten Netzwerk 200. In dem in 3 gezeigten Beispiel wird angenommen, dass Client-1 202a, Client-2 202b, Client-3 202c und Client-4 202d IP-Adressen IP1, IP2, IP3 bzw. IP4 von einem DNS-Server 208 für die jeweiligen Anforderungen für die mit dem Domain-Name „www.beispiel.de” assoziierte IP-Adresse erhalten haben. Darüber hinaus wird angenommen, dass jeder Server 204a–204c die vollständige Menge von Anycast-IP-Adressen {IP1, IP2, IP3, IP4, ..., IPN}, die mit dem Domain-Name „www.beispiel.de” assoziiert sind, den Router 206a–206e bekanntmacht.
Da alle Server 204a–204c die vollständige Menge von Anycast-IP-Adressen bekanntmachen, kann jeder der Server 204a–204c potenziell auf Client-Abfragen nach einer der bekanntgemachten Anycast-IP-Adressen antworten. Mit anderen Worten können Client-Anforderungen potenziell von einem beliebigen der Server 204a–204c verarbeitet werden. Welcher der Server 204a–204c die Client-Anforderung empfängt, kann von dem Routing-Algorithmus abhängen, der von den Router 206a–206e implementiert wird. Zum Beispiel können Anforderungen, die von dem Client-1 202a für die Adresse IP1 ausgehen, über Router-1 206a an den Server-1 204a geroutet werden; Anforderungen, die von dem Client-2 202b für die Adresse IP2 ausgehen, können über Router-2 206b und Router-5 206e an den Server-2 204b geroutet werden; Anforderungen, die von dem Client-3 202c für die Adresse IP3 ausgehen, können über Router-3 206c an den Server-3 204c geroutet werden; und Anforderungen, die von dem Client-4 202d für die Adresse IP4 ausgehen, können ebenso über Router-4 206d und Router-3 206c an den Server-3 204c geroutet werden.
In einigen Implementierungen können, wie in 3 gezeigt ist, Antworten von den Servern 204a–204c auf die Client-Anforderungen denselben Pfad zum Client nehmen, wie der Pfad, den die jeweilige Anforderung an den Server 204a–204c genommen hat. Zum Beispiel kann die Antwort von dem Server-1 204a an den Client-1 202a über den Router-1 206a geroutet werden. In ähnlicher Weise kann die Antwort von dem Server-2 206b an den Client-2 202b über den Router-5 206e und Router-2 206b geroutet werden. Es versteht sich, dass die zwischen den Clients 202a–202d und den Servern 204a–204c etablierten Routen in 3 nur beispielhaft gezeigt sind, und dass diese Routen sich auf Basis von verschiedenen Faktoren im Netzwerk 200, wie beispielsweise Bandbreite, Latenz usw., dynamisch ändern können.
4 zeigt ein weiteres beispielhaftes Routing von Netzwerkverkehr zwischen Clients 202a–202d und Servern 204a–204c in dem in 2 dargestellten Netzwerk 200. Insbesondere zeigt 4 das Routing von Verkehr, wenn der Server-3 204c sich in einem Überlastzustand befindet. Wie oben erwähnt, kommunizieren die Server 204a–204c ihre jeweiligen Lastinformationen an den DNS-Server 208. Der DNS-Server 208 kann basierend auf den empfangenen Lastinformationen bestimmen, dass ein oder mehrere der Server 204a–204c sich in einem Überlastzustand befinden können. In solchen Fällen kann der DNS-Server 208 versuchen, die Last auf dem betroffenen Server zu entlasten, indem er den Server anweist, das Bekanntmachen von einer oder mehrerer der Menge von zuvor bekanntgemachten Anycast-IP-Adressen einzustellen.
Zum Beispiel, unter Bezugnahme auf i4, kann der DNS-Server 208 bestimmen, dass sich Server-3 204c in einem Überlastzustand befindet, und den Server-3 204c anweisen, das Bekanntmachen der Anycast-IP-Adresse IP4 einzustellen. In einigen anderen Ausführungsformen kann die Anycast-Adresse IP4 die Adresse sein, die die höchste Last auf dem Server-3 204c verursacht. In einigen anderen Implementierungen kann der DNS-Server 208 den Server-3 24c anweisen, das Bekanntmachen einer zufällig aus dem Satz von IP-Anycast-Adressen ausgewählten Adresse einzustellen.
Wenn der Server-3 204c das Bekanntmachen IP4 einstellt, können die Router 206a–206e ihre jeweiligen Routing- oder Forwarding-Tabellen neu konfigurieren, so dass IP-Pakete mit einer Zieladresse von IP4 sind nicht mehr an den Server-3 204c geroutet werden. Stattdessen können IP-Pakete mit der Zieladresse von IP4 auf einen anderen Server geroutet werden, der noch die Anycast-Adresse IP4 bekanntmacht. Zum Beispiel, unter Bezugnahme auf 4, werden Anforderungen auf die Anycast-IP-Adresse IP4 von Client-4 202d, die zuvor an den Server-3 204c geroutet wurden, stattdessen an den Server-2 204b geroutet, der die Anycast-IP-Adresse IP4 noch immer bekanntmacht.
Selbst wenn ein neuer Client eine Anfrage an die Adresse IP4 senden würde, würden solche Anfragen nicht an den Server-3 204c geroutet werden. 4 zeigt zum Beispiel auch einen fünften Client: Client-5 202e, der Anfragen an die Anycast-IP-Adresse IP4 sendet. Obwohl Client-5 202e mit demselben Router (Router-3 206c) gekoppelt ist, mit dem Server-3 204c gekoppelt ist, werden vom Client-5 202e ausgehende Anforderungen an IP4 nicht an den Server-3 204c geroutet. Stattdessen werden in diesem Beispiel die Anforderungen an den Server-1 204a geroutet.
Es sollte beachtet werden, dass, während der Server-3 204c das Bekanntmachen der Anycast-Adresse IP IP4 einstellt, er noch weiterhin andere Anycast-IP-Adressen, wie beispielsweise Adresse IP3, bekanntmachen kann. Somit können Anfragen an Adresse IP3, die von Client-3 202c oder eigentlich auch von einem anderen Client ausgehen, weiterhin von Server-3 204c empfangen und verarbeitet werden.
Da die Anforderungen an Anycast-IP-Adresse IP4, die zuvor von Server-3 204c verarbeitet wurden, nicht mehr von Server-3 204c empfangen werden, kann die Last auf Server-3 204c reduziert werden. Auf diese Weise kann der DNS-Server 208 die Last auf dem Server-3 204c regulieren, indem er den Server-3 204c anweist, das Bekanntmachen von einer oder mehrerer aus der Menge von Anycast-IP-Adressen ausgewählten Anycast-IP-Adresse einzustellen. Man nehme beispielsweise an, dass der Server-3 204c 20 Anycast-IP-Adressen bekanntmacht. Es sei ebenfalls angenommen, dass der Server-3 204c sich in einem Überlastzustand befindet und dass die Gesamtlast auf dem Server gleichmäßig über die Verarbeitung von Anforderungen an jede der 20 Anycast-IP-Adressen verteilt ist. Wenn der Server das Bekanntmachen von 2 der 20 Anycast-IP-Adressen einstellen würde, während die verbleibenden Server 204 weiterhin alle 20 Anycast-IP-Adressen bekanntmachen, dann würden die den 2 Anycast-IP-Adressen zugeordneten Kommunikationen, die ansonsten an Server-3 204c gelenkt würden, stattdessen an andere Server 204 gelenkt, welche die Adressen weiterhin bekanntmachen. Das bedeutet, dass der Server-3 204c etwa 10% weniger Kommunikationen zu verarbeiten haben würde. Somit könnte die Gesamtlast auf dem Server möglicherweise um etwa 10% reduziert werden. Somit wird durch Anweisen eines Servers, das Bekanntmachen einer oder mehrerer Anycast-IP-Adressen einzustellen, die Last auf dem Server an andere Server verteilt. In ähnlicher Weise kann der DNS-Server 208 die Lastbedingungen auf den anderen Servern 204a–204b innerhalb des Netzwerks 200 überwachen und kann basierend auf ihren jeweiligen Lastbedingungen einen oder mehrere dieser Server anweisen, Bekanntmachen einer oder mehrerer Anycast-IP-Adressen einzustellen.
Der DNS-Server 208 kann die Lastbedingung auf dem Server-3 204c weiterhin überwachen, um zu bestimmen, ob die aktuellen Lastbedingungen es Server-3 204c erlauben können, die Anycast-IP-Adresse IP4 wieder bekanntzumachen. Wenn zum Beispiel die Lastparameter, wie beispielsweise, aber nicht beschränkt auf, Bandbreite und Latenzzeit eine vorbestimmte Schwelle übertreten, dann kann DNS-Server 208 den Server-3 204c anweisen, IP4 wieder bekanntzumachen. Nach Empfang der Bekanntmachung von Server-3 204c, können die Router 206a–206e ihre Routing- und Forwarding-Tabellen neu konfigurieren, so dass Anfragen an Adresse IP4 wieder an Server-3 204c geroutet werden können.
In einigen Implementierungen können Servern 204a–204c auf Kommunikationen mit einem Client antworten, die sich auf einen Zustand verlassen, der von einem jeweiligen Server auf Basis vorheriger Kommunikationen mit demselben Client gespeichert wurde. Wenn zum Beispiel Server-3 204c eine TCP/IP-Kommunikation auf der Anycast-Adresse IP4 empf#ngt, dann müsste Server-3 204c einen TCP-Zustand beibehalten, während er auf die Kommunikation antwortet. Wie in 4 gezeigt ist, wenn der Server-3 204c aufgrund von Überlastbedingungen einstellt, die Adresse IP4 bekanntzumachen, dann werden in der Zukunft Pakete, die von Client-4 202d an IP4 adressiert sind, an Server-2 204b geroutet. Server-2 204b enthält aber keine Zustandsinformation in Bezug auf Kommunikation mit Client-4 202d. Daher würde jede zustandsabhängige Transaktion, die von Client-4 202d mit dem Server-3 204c etabliert wurde verloren gehen, wenn die Pakete an Server-2 204b geroutet werden.
5 zeigt einen Ansatz zur Erhaltung des Zustands von laufenden Kommunikationen oder Transaktionen. Insbesondere zeigt 5 einen Abschnitt des in 4 gezeigten Netzwerks 200, in dem der Server-3 204c das Bekanntmachen der Anycast-IP-Adresse IP4 eingestellt hat und Anforderungen von Client-4 202d, die an IP4 adressiert sind, an Server-2 204b geroutet werden. Der Server-2 204b unterhält eine Zustandstabelle aller Anforderungen, die von Servern 204a–204c verarbeitet werden. Wenn die weiter geroutete Anfrage von Client-4 202d von Server-2 204b empfangen wird, schlägt Server-2 204b in der Zustandstabelle nach, um zu bestimmen, ob die empfangene Anforderung neu ist, einer bestehenden laufenden Transaktion auf Server-2 204b entspricht oder mit einem anderen Server verbunden ist, der vor kurzem das Bekanntmachen einer Adresse eingestellt hat.
Eine Zustandstabelle kann von jedem der drei Server 204a–204c unterhalten werden. In einigen Implementierungen kann zur Unterhaltung der Zustandstabelle jeder der drei Server 204a–204c Zustands- und Identifizierungsinformationen der laufenden Transaktionen mit ihren jeweiligen Clients zu allen anderen Servern kommunizieren. Nach Erhalt dieser Informationen kann jeder der drei Server 204a–204c seine jeweilige Zustandstabelle aktualisieren. In einigen Implementierungen kann, wenn ein Server das Bekanntmachen einer oder mehrerer Anycast-IP-Adressen einstellt, der Server die eine oder mehreren Anycast-IP-Adressen an die anderen Servern kommunizieren. In einigen Implementierungen kann jeder Server die Informationen seiner jeweiligen laufenden Transaktion mit Clients regelmäßig an alle anderen Server senden. In einigen anderen Implementierungen kann als Antwort auf die Anweisung, das Bekanntmachen einer oder mehrerer Anycast-IP-Adressen einzustellen, ein Server Zustandsinformationen bezüglich laufender Transaktionen unter Verwendung dieser Anycast-IP-Adressen senden.
Da die Anfrage, die von Client-4 202d empfangen wurde, Server-3 204c zugeordnet ist, kapselt der Server-2 204b die Anforderung von Client-4 202d ein und leitet die eingekapselte Anfrage an Server-3 204c weiter. In einigen Implementierungen kann der Server-2 204b die eingekapselte Anforderung an Server-3 204c an einer eindeutigen IP-Adresse senden, die mit dem Server-3 204c assoziiert ist. In einigen Implementierungen kann die eindeutige IP-Adresse die IP-Adresse sein, die der Server-3 204c für das Senden und Empfangen von Server-Wartungs- oder Verwaltungsinformationen verwendet. Der Server-3 204c prüft die eingekapselte Anfrage und schlägt in seiner eigenen Tabelle nach, um zu bestimmen, ob die eingekapselte Anforderung Teil einer laufenden Transaktion zwischen Client-4 202d und Server-3 204c ist. Der Server-3 204c kann dann die Anforderung verarbeiten und eine Antwort an Client-4 202d zurücksenden.
In einigen Implementierungen kann der Server-3 204c die Antwort einkapseln und die eingekapselte Antwort zurück an Server-2 204b senden, welcher die Antwort wiederum zurück an Client-4 202d leitet. Dieser eingekapselte Austausch von laufenden Anfragen und Antworten kann fortfahren bis die Transaktion, von der die Anfragen und Antworten Teil sind, entweder durch Client-4 202d oder Server-3 204c beendet wird.
Somit kann Server-3 204c, obwohl er nicht in der Lage ist, an Anycast-Adresse IP4 adressierte Pakete zu empfangen, weiterhin die laufenden Transaktionen mit Client-4 202d verarbeiten.
6 zeigt einen beispielhaften Prozess 600 für Anycast-basierte Lastverteilung, der von einem DNS-Server durchgeführt. In einigen Implementierungen kann der in 6 gezeigte Prozess 600 von beispielsweise dem in 1 dargestellten DNS-Server 108 ausgeführt werden. In anderen Implementierungen kann der Prozess 600 von beispielsweise dem in 2–5 dargestellten DNS-Server 208 ausgeführt werden. Der Prozess 600 beinhaltet das Empfangen einer Anforderung der Netzwerkadresse eines Servers (Schritt 602), das Antworten auf die Anforderung mit einer oder mehreren Anycast-Netzwerk-Adressen, ausgewählt aus einer Vielzahl von Anycast-Adressen (Schritt 604), Empfangen von Lastinformationen von zumindest einem der Server (Schritt 606) und Anweisen basierend auf den empfangenen Lastinformationen, dass ein oder mehrere der Server einstellen, eine oder mehrere Anycast-Adressen einer Vielzahl von Anycast-Adressen bekanntzumachen (Schritt 608).
Der Prozess 600 beinhaltet das Empfangen einer Anforderung der Netzwerkadresse eines Servers (Schritt 602). Ein Beispiel für diesen Verfahrensschritt wurde im Zusammenhang mit 1 oben erläutert. Insbesondere empfängt der DNS-Server 108 eine Anforderung der mit der Domain-Name-Adresse „www.beispiel.de” assoziierten Netzwerkadresse von Client-1 102a über den DNS-Resolver-1 104a. Der Prozess 600 beinhaltet auch das Antworten auf die Anfrage mit einer oder mehreren Anycast-Netzwerkadressen, ausgewählt aus einer Vielzahl von Anycast-Adressen (Schritt 604). Ein Beispiel für diesen Schritt wurde im Zusammenhang mit 1 oben erläutert. Insbesondere zeigt 1 das Antworten des DNS-Servers 106 auf die Anforderung, die von Client-1 102a erhalten wurde, mit einer Anycast-Adresse IP1. Die Anycast-Adresse IP1 kann aus einer Menge von N Anycast-IP-Adressen ausgewählt werden: {IP1, IP2, IP3, IP4, ..., IPN}. In einigen Implementierungen kann der DNS-Server 106 mit mehr als einer Anycast-Adresse antworten, die aus der Menge von N Anycast-IP-Adressen ausgewählt wurde.
Der Prozess 600 beinhaltet weiter das Empfangen von Lastinformationen von zumindest einem der Server (Schritt 606). Ein Beispiel für diesen Schritt wurde im Zusammenhang mit 3–5 oben erläutert. Zum Beispiel empfängt der DNS-Server 208 in den 3–5 Lastinformationen von jedem der drei Server 204a–204b. Wie oben erwähnt, können die Lastinformation mehrere Metriken enthalten, wie beispielsweise, aber nicht beschränkt auf, Server-Antwortzeit, Anzahl von Hits, Ressourcenauslastung, Latenz, Server-Status usw. Der DNS-Server 208 kann die von den Servern empfangenen Lastinformationen vergleichen und diese mit vorgegebenen Schwellwerten vergleichen. Wenn die empfangene Lastinformationen die Schwellwerte überschreiten, dann kann DNS-Server 208 bestimmen, dass sich der Server in einem Überlastzustand befindet.
Der Prozess 600 beinhaltet ferner das Anweisen, basierend auf den empfangenen Lastinformationen, dass ein oder mehrere der Server das Bekanntmachen einer oder mehrerer Anycast-Adressen aus der Vielzahl von Anycast-Adressen einstellen (Schritt 608). Ein Beispiel für diesen Verfahrensschritt wurde im Zusammenhang mit 4 oben erläutert. Wenn DNS-Server 208 zum Beispiel bestimmt, dass sich Server-3 204c in einem Überlastzustand befindet, weist er Server-3 204c an, das Bekanntmachen der Anycast-Adresse IP4 aus der Menge von N Anycast-Adressen: {IP1, IP2, IP3, IP4, ...,IPN}, die von Server-3 204c bekanntgemacht werden, einzustellen.
7 zeigt einen beispielhaften Prozess 700 für Anycast-basierte Lastverteilung, der von einem Server durchgeführt. In einigen Implementierungen kann der in 7 gezeigte Prozess 700 von den in 3–5 dargestellten DNS-Servern 204a–204c ausgeführt werden. Der Prozess 700 beinhaltet das Bekanntmachen einer Vielzahl von Anycast-Adressen (Schritt 702), Kommunizieren von Lastinformation an einen Server (Schritt 704), Einstellen des Bekanntmachen einer oder mehrerer von dem Server angegebenen Anycast-Adressen (Schritt 706) und Fortfahren des Kommunizieren von Lastinformationen an den Server (Schritt 708).
Der Prozess 700 beinhaltet das Bekanntmachen einer Vielzahl von Anycast-Adressen (Schritt 702). Ein Beispiel für diesen Verfahrensschritt wurde im Zusammenhang mit 3 oben erläutert. Zum Beispiel zeigt 3, wie jeder der drei Server 204a–204c eine Menge von N Anycast-IP-Adressen {IP1, IP2, IP3, IP4, ..., IPN} bekanntmacht. Durch Bekanntmachen der Menge von N Anycast-IP-Adressen, zeigen die Server 204a–204c den Routern 206a–206e an, dass jeder der drei Server 204a–204c Client-Anfragen annehmen kann, die an eine beliebige der N Anycast-IP-Adressen adressiert sind.
Der Prozess 700 beinhaltet auch das Kommunizieren von Lastinformationen an einen Server (Schritt 704). Ein Beispiel für diesen Verfahrensschritt wurde im Zusammenhang mit 4–5 oben erläutert. Zum Beispiel sendet jeder der drei in 4 gezeigten Server 204a–204c Lastinformationen an den DNS-Server 208. Die Lastinformationen können Lastmetriken enthalten, wie beispielsweise, aber nicht beschränkt auf, Server-Antwortzeit, Anzahl von Hits, Ressourcenauslastung, Latenz, Server-Status usw.
Der Prozess 700 beinhaltet ferner das Einstellen des Bekanntmachen einer oder mehrerer Anycast-Adressen, die vom Server angezeigt werden (Schritt 706). Ein Beispiel für diesen Verfahrensschritt wurde im Zusammenhang mit 4–5 oben erläutert. Zum Beispiel, wie in 4 gezeigt, stellt Server-3 204c nach Erhalt von Anweisungen von DNS-Server 208 das Bekanntmachen der Anycast-Adresse IP4 ein. Durch das Einstellen des Bekanntmachen der Anycast-Adresse IP4 zeigt Server-3 204c an, dass Server-3 204c keine Anfragen mehr annimmt, die an Anycast-Adresse IP4 adressiert sind. Das bedeutet, dass Anfragen, und in der Tat Pakete, die an IP4 adressiert sind, die zuvor von Server-3 204c verarbeitet wurden, stattdessen an einen anderen Server geroutet werden.
Der Prozess 700 beinhaltet auch das Fortfahren des Kommunizieren von Lastinformationen an den Server (Schritt 708). Ein Beispiel für diesen Verfahrensschritt wurde im Zusammenhang mit 4–5 oben erläutert. Zum Beispiel, wie oben erwähnt, fährt Server-3 204c fort, Lastinformationen an DNS-Server 208 zu senden, selbst nachdem er das Bekanntmachen der Anycast-Adresse IP4 eingestellt hat. Wenn der DNS-Sever auf Basis der aktuell empfangen Lastinformation bestimmt, dass Server-3 204c nicht mehr überlastet ist, dann kann Server-3 204c Anweisungen von DNS-Server 208 erhalten, die Anycast-Adresse IP4 wieder bekanntzumachen. Auf diese Weise kann der Server-3 204c wieder beginnen an die Anycast-Adresse IP4 adressierte Anfragen zu akzeptieren und darauf zu antworten.
8 zeigt ein beispielhaftes Blockdiagramm eines DNS-Servers 800. In einigen Implementierungen kann der DNS-Server 800 beispielsweise als der in 1 gezeigte DNS-Server 106 und/oder der in den 2–4 gezeigte DNS-Server 208 verwendet werden. In einigen Implementierungen kann der DNS-Server 800 zum Ausführen des in 6 gezeigten beispielhaften Prozesses 600 verwendet werden.
Der DNS-Server 800 beinhaltet einen Prozessor 802, einen Speicher 804 und eine Netzwerkschnittstelle 806. Der Prozessor 802 kann einen beliebigen Logikschaltkreis, der Prozessanweisungen ausführt, beinhalten wie beispielsweise, jedoch nicht beschränkt auf, Mikroprozessoren, Mikrocontroller, programmierbare Logikarrays usw., der als anwendungsspezifische integrierte Schaltungen (engl. application specific integrated circuits, ASICs), feldprogrammierbare Gate-Arrays (engl. field programmable gate arrays, FPGAs) usw. implementiert ist. In einigen Implementierungen kann der Prozessor 802 mehrere Prozessoren beinhalten. Der Prozessor 802 kann zu Multi-Processing, Multi-Tasking, Multi-Threading fähig sein und allgemein in der Lage sein, mehr als eine Anwendung gleichzeitig auszuführen. Der Prozessor 802 kann mit dem Speicher 804 und der Netzwerkschnittstelle 806 über Daten und Steuerbusse kommunizieren (nicht gezeigt).
Der Speicher 804 kann eine beliebige Einrichtung sein, die in der Lage ist, computerlesbare Daten zu speichern. Der Speicher 804 kann eine Einrichtung mit festem Speicher oder eine Einrichtung zum Lesen von Wechselspeichermedien sein. Beispiele beinhalten alle Formen von nichtflüchtigem Speicher, nichtflüchtigen Medien und Speichereinrichtungen, Halbleiterspeichereinrichtungen (beispielsweise EPROM, EEPROM und Flash-Speichereinrichtungen), Magnetplatten, magnetooptische Platten und optische Platten (beispielsweise CD-ROM-, DVD-ROM- und Blu-Ray^®-Disks). Der DNS-Server 800 kann eine beliebige Anzahl von Einrichtungen haben, die Speicher 804 implementieren. In einigen Implementierungen kann der Speicher 804 einen Redundant Array of Independent Disks (RAID) beinhalten, um Fehlertoleranz, Verfügbarkeit und Zuverlässigkeit zu verbessern.
Der DNS-Server 800 kann die Netzwerk-Schnittstelle 806 zum Kommunizieren von Daten mit anderen Geräten über ein Netzwerk nutzen. Zum Beispiel kann die Netzwerkschnittstelle verwendet werden, um mit Clients 102a–102n und/oder DNS-Resolvern 104a–104n zu kommunizieren, die in 1 gezeigt sind. Der DNS-Server 800 kann auch die Netzwerk-Schnittstelle 804 nutzen, um mit in den 2–5 gezeigten Servern 201a–201c zu kommunizieren. Die Netzwerkschnittstelle 806 kann eine oder mehrere Netzwerk-Ports zur physischen Verbindung mit einem oder mehreren Netzwerken über Netzwerkkabel beinhalten. Die Netzwerkschnittstelle 806 kann auch einen Schnittstellen-Controller zum Kommunizieren von Daten zwischen den Netzwerk-Ports und dem Prozessor 802 und zur allgemeinen Steuerung des Betriebs der Netzwerkschnittstelle 806 beinhalten. In einigen Implementierungen kann die Netzwerkschnittstelle 804 mehrere Netzwerk-Layer des Open Systems Interconnection (OSI) Netzwerkmodells implementieren. Zum Beispiel kann die Netzwerkschnittstelle Ethernet-Ports mit zugeordneten Ethernet-Adressen zur Implementierung eines Datenlik-Layers implementieren.
In einigen Implementierungen kann der Speicher 804 eine DNS-Datenbank 808 speichern. Die DNS-Datenbank 808 kann ähnlich der DNS-Datenbank sein, die oben in Bezug auf den 1 gezeigten DNS-Server 106 erörtert wurde. Zum Beispiel kann die DNS-Datenbank 808 Ressourcen-Datensätze mit IP-Adressen von einem oder mehreren Web-Servern beinhalten, die mit einem Domain-Namen wie beispielsweise „www.beispiel.de” assoziiert sind. In einigen anderen Implementierungen kann die DNS-Datenbank 808 IP-Adressen anderer DNS-Server beinhalten, die DNS-Abfragen für den DNS-Server 800 verarbeiten können. In einigen Implementierungen können die in der DNS-Datenbank gespeicherten IP-Adressen Anycast-IP-Adressen sein.
Der Speicher 804 kann mehrere Anwendungen zur Ausführung durch den Prozessor 802 speichern. Zum Beispiel kann der Speicher 804 eine DNS-Anwendung 810 zur Durchführung verschiedener Funktionen im Zusammenhang mit dem Domain-Name-System beinhalten. Insbesondere kann die DNS Anwendung ein Anycast-Modul 812 beinhalten, die durch Prozessor 802 ausgeführt werden kann, um Clients (beispielsweise in 1 gezeigten 102a–102n) eine oder Adressen mehrere Anycast-IP-Adressen bereitzustellen, die aus einer Vielzahl von Anycast-Adressen ausgewählt wurden, die in der DNS-Datenbank 808 gespeichert sind. Der DNS-Anwendung 810 kann auch ein Lastverteilungsmodul 814 beinhalten. Das Lastverteilungsmodul 814 kann durch den Prozessor 802 ausgeführt werden, um von Servern (wie beispielsweise in den 2–5 gezeigte Server 204a–204c) empfange Lastinformationen zu verarbeiten und Anweisungen in Bezug auf das Bekanntmachen von Anycast-IP-Adressen an die Server zu senden. Zum Beispiel kann das Lastverteilungsmodul 814 Anweisungen zum Kommunizieren an einen überlasteten Server beinhalten, das Bekanntmachen einer oder mehrerer Anycast-IP-Adressen einzustellen.
9 beinhaltet ein beispielhaftes Blockdiagramm eines Servers 900. In einigen Implementierungen kann der Server 900 beispielsweise als die in den 2–5 gezeigten Content-Server 204a–204c verwendet werden. In einigen Implementierungen kann der Server 900 zum Ausführen des in 7 gezeigten beispielhaften Prozesses 700 verwendet werden.
Der Server 900 kann einen Prozessor 902, einen Speicher 904 und eine Netzwerkschnittstelle 906 beinhalten. In einigen Implementierungen können der Prozessor 902, der Speicher 904 und die Netzwerkschnittstelle 906 in einer Weise ähnlich zu der oben in Bezug auf den in 8 gezeigten Prozessor 802, Speicher 804 bzw. der Netzwerkschnittstelle 806 erörterten Weise, implementiert sein.
Der Speicher 904 kann eine Server-Datenbank 908 speichern, welche beispielsweise eine Vielzahl von Anycast-IP-Adressen beinhalten kann, die mit einem oder mehreren Domain-Names assoziiert sein können. Der Speicher 904 kann auch eine Zustandstabelle 910 enthalten, die Zustandsinformationen der laufenden Transaktionen beinhaltet, die von den Servern, die an dem Domain-Name-System teilnehmen, verarbeitet werden.
Der Speicher 904 kann auch mehrere Anwendungen zur Ausführung durch den Prozessor 902 beinhalten. Zum Beispiel kann der Speicher 904 eine Server-Anwendung 912 beinhalten, die von dem Prozessor 902 zur Durchführung verschiedener Server-Operationen im Zusammenhang mit dem Domain-Name-System ausgeführt werden können. Insbesondere kann die Server-Anwendung 912 ein Bekanntmachungsmodul 914 und ein Lastüberwachungsmodul 916 beinhalten. Das Bekanntmachungsmodul 914 kann durch den Prozessor 902 durchgeführt werden, um zu bestimmen, welche der in der Server-Datenbank 908 gespeicherten Anycast-IP-Adressen bekanntgemacht werden müssen. In einigen Implementierungen kann das Bekanntmachungsmodul 914 verwendet werden, um mit dem in 8 gezeigten DNS-Server 800 zu kommunizieren, um Anweisungen zu erhalten, die angeben, welche der Anycast-IP-Adressen bekanntgemacht oder nicht mehr bekanntgemacht werden soll.
Das Lastüberwachungsmodul 916 kann durch den Prozessor 902 zur Bestimmung der Lastinformation auf dem Server und zum Kommunizieren der Lastinformationen an den DNS-Server ausgeführt werden. Zum Beispiel kann das Lastüberwachungsmodul 916 Informationen sammeln, wie beispielsweise, aber nicht beschränkt auf, Server-Antwortzeit, Anzahl von Hits, Ressourcenauslastung, Latenz, usw. Die durch das Lastüberwachungsmodul 916 gesammelten Lastinformationen können an den DNS-Server, wie beispielsweise den in 8 gezeigten DNS-Server 800 kommuniziert werden. In einigen Implementierungen kann das Lastüberwachungsmodul 916 Anweisungen beinhalten, in regelmäßigen Abständen Lastinformationen zu sammeln oder Lastinformationen zu sammeln, wenn diese von dem DNS-Server angefordert werden.
Verschiedene Modifikationen der in dieser Offenbarung beschriebenen Implementierungen sind Fachleuten ohne Weiteres offensichtlich und die allgemeinen hierin definierten Prinzipien können auf andere Implementierungen angewendet werden, ohne vom Grundgedanken und Schutzbereich dieser Offenbarung abzuweichen. Somit sollen die Ansprüche nicht auf die hier dargestellten Implementierungen beschränkt sein, sondern sind dem breitesten Umfang zugänglich, der mit dieser Offenbarung, den Prinzipien und den neuartigen Merkmalen, die hierin offenbart sind, konsistent ist.

Claims

Domain-Name-System (DNS), umfassend: einen DNS-Server, der Folgendes beinhaltet: eines Anycast-Moduls, konfiguriert, um das Annehmen einer Anforderung einer Netzwerkadresse eines Content-Servers, und da Antworten auf die Anforderung mit einer Netzwerkadresse, ausgewählt aus einer Vielzahl von Anycast-Netzwerkadressen, eines Lastverteilungsmoduls, das kommunizierbar mit dem Anycast-Modul gekoppelt ist, konfiguriert ist, um: Lastinformation von zumindest einem einer Vielzahl von Content-Servern zu empfangen, um basierend auf den Lastinformationen einen überlasteten Content-Server zu identifizieren, und den überlasteten Content-Server anzuweisen, das Bekanntmachen einer oder mehrerer der Vielzahl von Anycast-Netzwerk-Adressen einzustellen, und einer Vielzahl von Content-Servern, die in der Lage sind, mit dem DNS-Server zu kommunizieren, wobei jeder der Vielzahl von Content-Servern beinhaltet: ein Bekanntmachungsmodul, das dafür konfiguriert ist, um: Anweisungen von dem DNS-Server zu empfangen, bestimmte der Vielzahl von Anycast-Netzwerkadressen bekanntzumachen und die bestimmten der Vielzahl von Anycast-Netzwerkadressen bekanntzumachen, und ein Lastüberwachungsmodul, das konfiguriert ist, um: mit dem Server verbundene Lastinformationen zu sammeln und die Lastinformationen an den DNS-Server zu kommunizieren.
System nach Anspruch 1, wobei das Anycast-Modul ferner konfiguriert ist, die Netzwerkadresse in einer Round-Robin-Weise aus der Vielzahl von Anycast-Netzwerkadressen auszuwählen.
System nach Anspruch 1, wobei das Lastverteilungsmodul ferner konfiguriert ist, zusätzlich Lastinformationen von dem identifizierten überlasteten Content-Server zu empfangen und den überbelasteten Content-Server anzuweisen, die eine oder mehreren der Vielzahl von Anycast-Netzwerkadressen wieder bekanntzumachen.
System nach Anspruch 1, wobei jeder der Vielzahl von Content-Servern ferner konfiguriert ist, eine erste Anforderung von einem ersten Client, die an eine der spezifizierten der Vielzahl von Anycast-Netzwerkadressen adressiert ist, zu empfangen, Zustandsinformation, die der ersten Anforderung zugeordnet ist, zu unterhalten und den Zustand an einen anderen Server zu kommunizieren, der konfiguriert ist, die Vielzahl von Anycast-Netzwerkadressen bekanntzumachen.
System nach Anspruch 1, wobei jeder der Vielzahl von Content-Servern ferner konfiguriert ist, eine zweite Anforderung von einem zweiten Client zu erhalten, die an eine der spezifizierten der Vielzahl von Anycast-Adressen adressiert ist; und die zweite Anforderung einzukapseln und die eingekapselte zweite Anforderung basierend auf Zustandsinformationen, die mit der zweiten von dem anderen Server empfangenen Anforderung verbunden sind, an einen anderen Server weiterzuleiten.
Nicht-flüchtiges computerlesbares Speichermedium mit darauf codierten Anweisungen implementiert werden, welche, wenn sie von einem Prozessor ausgeführt werden, den Prozessor veranlassen, ein Verfahren durchzuführen, umfassend: das Empfangen einer Anforderung einer Netzwerkadresse eines Content-Servers; das Antworten auf die Anforderung mit einer Netzwerkadresse, die aus einer Vielzahl von Anycast-Netzwerkadressen ausgewählt wird; das Empfangen von Lastinformationen von zumindest einem einer Vielzahl von Content-Servern; und das Anweisen, basierend auf den empfangenen Lastinformationen, dass ein oder mehrere überlastete Content-Server einstellen, eine oder mehrere einer Vielzahl von Anycast-Netzwerkadressen bekanntzumachen.
Nicht-flüchtiges computerlesbares Speichermedium nach Anspruch 6, wobei das Antworten auf eine Anfrage mit einer Netzwerkadresse, ausgewählt aus der Vielzahl von Anycast-Netzwerkadressen, das Auswählen der Netzwerkadresse aus der Vielzahl von Anycast-Netzwerkadressen in einer Round-Robin-Weise beinhaltet.
Nicht-flüchtiges computerlesbares Speichermedium nach Anspruch 6, wobei das Antworten auf eine Anfrage mit einer Netzwerkadresse, ausgewählt aus der Vielzahl von Anycast-Netzwerkadressen, das zufällige Auswählen der Netzwerkadresse aus der Vielzahl von Anycast-Netzwerkadressen beinhaltet.
Nicht-flüchtiges computerlesbares Speichermedium nach Anspruch 6, des Weiteren umfassend das Anweisen anderer des einen oder der mehreren der Vielzahl von Content-Servern, laufende Anfragen, die mit dem einen oder den mehreren überlasteten Content-Servern verbunden sind, die das Bekanntmachen der einen oder mehreren der Vielzahl von Anycast-Netzwerkadressen einstellen, an den einen oder die mehreren überlasteten Content-Servern weiterzuleiten.
Nicht-flüchtiges computerlesbares Speichermedium nach Anspruch 6, des Weiteren umfassend das Empfangen zusätzlicher Lastinformationen von dem zumindest einem der Vielzahl von Content-Servern und Anweisen, auf Basis der zusätzlichen Lastinformationen, des einen oder der mehreren der Vielzahl von Content-Servern, die eine oder mehreren der Vielzahl von Anycast-Netzwerkadressen wieder bekanntzumachen.