Die Bezeichnung “Google Dance” (Google Tanz) ist eine vielerorts anzutreffende Umschreibung des Verhaltens der Suchmaschine Google im Laufe eines Index-Updates. In der Vergangenheit erfolgte dieses Index-Update im Schnitt einmal pro Monat. Es zeichnete sich vor allem dadurch aus, dass Google’s kompletter Cache indexierter Seiten diese zum Stand des letzten Spiderns widerspiegelte und dass Google neue eingehende Links für Seiten anzeigte. Mitte 2003 begann Google jedoch mit der Einführung fortlaufender Update-Prozesse. Es scheint zwar, dass der Index auch weiterhin von Zeit zu Zeit ein komplettes Update erfahren muss, allerdings wirkt dieses sich auf Grund der kontinuierlichen Updates nicht mehr gravierend auf die Suchergebnisse aus.
Da diese Site Informationen bereithält, die über den eigentlichen Google Dance hinaus gehen, werden wir sie auch weiterhin pflegen. Wir werden jedoch während eines möglichen “Google Dance” auf Grund seiner nunmehr eher geringen Bedeutung nicht mehr über den Stand eines Updates auf den verschiedenen Rechenzentren berichten.
Die technischen Hintergründe des Google Dance
Die Suchmaschine Google liefert Suchergebnisse von mehr als 10.000 Servern, bei denen es sich um schlichte Linux-PCs handelt, die Google in erster Linie aus Kostengründen einsetzt. Ein Index-Update kann dabei natürlich nicht auf allen Servern gleichzeitig erfolgen. Der neue Index muss sukzessive auf den einzelnen Servern aufgespielt werden.
Es herrscht weithin die Vorstellung, dass Google während des Google Dance in irgendeiner Form intern steuert, ob auf eine Suchanfrage hin ein Server mit neuem oder ein Server mit altem Index antwortet. Da jedoch Google einen inversen Index nutzt, wäre die sehr kompliziert. Wie später gezeigt wird, findet auch tatsächlich keine derartige Steuerung innerhalb des Systems statt. Vielmehr liegt die Ursache für den Google Dance in Google’s Nutzung des Domain Name Systems (DNS).
Google Dance und DNS
Es ist nicht nur Google’s Index auf viele tausend Server verteilt, diese Server befinden sich zudem in derzeit 13 Rechenzentren. Sie liegen hauptsächtlich in den USA (z.B in Santa Clara, Kalifornien und Herndon, Virginia) sowie in Dublin, Irland.
Nun wäre es theoretisch denkbar, dass sämtliche Suchanfragen zentral erfasst und dann an die einzelnen Rechenzentren verteilt werden. Dies ist allerdings offensichtlich ineffizient. Jedes Rechenzentrum hat vielmehr eigene IP-Adressen – also eigene numerische Adressen innerhalb des Internets – und die Art und Weise, wie auf diese IP-Adressen zugegriffen wird, regelt das Domain Name System.
Das DNS funktioniert grundsätzlich folgendermaßen: Datentransfers erfolgen im Internet immer nur zwischen IP-Adressen. Informationen darüber, welche Domain zu welcher IP-Adresse auflöst, halten die Name Server des DNS bereit. Gibt ein Nutzer eine Domain in seinen Browser ein, ermittelt der lokal konfigurierte Name Server die dazugehörige IP-Adresse, indem er den für die jeweilige Domain zuständigen Name Server kontaktiert. (Dabei ist das DNS hierarchisch strukturiert. Eine Wiedergabe des exakten Vorgangs würde an dieser Stelle jedoch zu weit führen.) Diese IP-Adresse wird dann im lokal konfigurierten Name Server gecached, damit nicht bei jeder Verbindung wiederum eine Anfrage über das DNS erfolgen muss.
Für jede Domain wird dabei festgelegt, wie lange sie im Cache eines Name Servers verbleiben darf. Dieser Wert ist die Time To Live (TTL) einer Domain. Sobald die TTL abgelaufen ist, muss ein Name Server die IP-Adresse wiederum über das DNS beim zuständigen Name Server anfordern. Oft wird die TTL auf einen oder mehrere Tage festgelegt. Im Falle der Domain www.google.com ist die Time To Live jedoch mit 5 Minuten wesentlich kürzer. Damit dürfen Name Server die IP-Adresse der Domain www.google.com nur fünf Minuten cachen und müssen sie dann wieder beim zuständigen Name Server Google’s anfordern.
Google’s Name Server gibt bei Anfragen die IP-Adresse von nur einem Rechenzentrum zurück. Suchanfragen an Google werden also an ständig wechselde Rechenzentren gerichtet. Die Verteilung der Name-Server-Einträge dürfte dabei einerseits auf der Auslastung der einzelnen Rechenzentren basieren. Damit würde Google eine grobe Form des Load Balancing über das DNS durchführen. Andererseits lassen Tests für unterschiedliche Name Server darauf schließen, dass die geographische Lage eines Name Servers Einfluss darauf hat, welche IP-Adressen er relativ häufiger erhält. Auf diese Weise können die Datenübertragungsstrecken reduziert werden.
Der Zusammenhang zwischen Rechenzentren, DNS und Google Dance ist einfach: Im Zuge des Google Dance erhalten nicht alle Rechenzentren gleichzeitig den neuen Index. Es wird vielmehr in einem Rechenzentrum nach dem anderen der neue Index auf den Servern aufgespielt. Stellt ein Benutzer während des Google Dance eine Suchanfrage an Google, so kann er zu einem Zeitpunkt noch das Ergebnis von einem Rechenzentrum erhalten, das noch den alten Index nutzt, und bereits nach wenigen Minuten erhält er das Ergebnis auf die selbe Suchanfrage hin von einem Rechenzentrum, das den neuen Index nutzt. Für ihn hat sich das Update scheinbar binnen weniger Minuten und auf einen Schlag vollzogen. Dieser Vorgang kann sich natürlich auch umkehren, so dass Google scheinbar laufend zwischen dem alten und dem neuen Index wechselt.
Es sei schließlich noch angemerkt, dass Google bis September 2003 das DNS Load Balancing auf eigenen Name Servern durchgeführt hat. Seitdem jedoch werden hierfür die Dienste von Akamai Technologies, Inc. und natürlich deren Name Server genutzt.
IP-Adressen und Domains der einzelnen Rechenzentren
Der Verlauf des Google Dance könnte grundsätzlich durch Suchanfragen bei den IP-Adressen der jeweiligen Rechenzentren erfolgen. In der Regel werden jedoch bei Suchanfragen die IP-Adressen auf www.google.com umgelenkt. Google hält allerdings für die einzelnen Rechenzentren eigene Domains bereit, die stets zu den jeweiligen IP-Adressen auflösen. Diese Domains und ihre entsprechenden IP-Adresses können der folgenden Auflistung entnommen werden.
Domain IP-Adresse
www-ex.google.com 216.239.33.100
www-sj.google.com 216.239.35.100
www-va.google.com 216.239.37.100
www-dc.google.com 216.239.39.100
www-ab.google.com 216.239.51.100
www-in.google.com 216.239.53.100
www-zu.google.com 216.239.55.100
www-cw.google.com 216.239.57.100
www-fi.google.com 216.239.41.100
www-gv.google.com 216.239.59.100
www-kr.google.com 66.102.11.100
www-mc.google.com 66.102.7.100
www-lm.google.com 66.102.9.100
Beobachter des Google Dance vermuten oft, dass das Index-Update abgeschlossen ist, sobald sie den neuen Index auf www.google.com entdecken bzw. wenn sie den alten Index für eine gewisse Zeit nicht mehr auf www.google.com sehen können. Letztlich ist das Update jedoch erst abgeschlossen, wenn keine der oben aufgelisteten Domains mehr Resultate aus dem alten Index aufweist.
Das Update eines jeweiligen Rechenzentrums erfolgt scheinbar von einem Moment auf den anderen. Sobald ein Rechenzentrum einmal den neuen Index präsentiert, werden von dort keine Ergebnisse aus dem alten Index mehr geliefert. Dies ist lediglich so zu erklären, dass Google’s Index mehrfach redundant in einem Rechenzentrum vorgehalten wird. Zunächst wird nur ein Teil (eventuell die Hälfte) aller Server eines Rechenzentrums mit dem neuen Index versehen. Für diesen Zeitraum wird bei Suchanfragen nur der andere Teil der Server angesprochen. Ist das Update des einen Teils der Server abgeschlossen, wird bei Suchanfragen nur dieser Teil der Server angesprochen, während der andere Teil der Server den neuen Index erhält. Für den Benutzer vollzieht sich dass Update eines Rechenzentrums dann zu genau einem Zeitpunkt.
Anzumerken bleibt letztlich, dass der Zugriff auf die einzelnen Rechenzentren generell über das DNS gesteuert wird, zum Teil jedoch auch Suchanfragen gezielt weitergeleitet werden. Dies ist allerdings leicht zu erkennen: Wenn bei einer Suche auf einer der oben aufgelisteten Domains der Link zu Google’s Cache des Suchergebnisses nicht auf die der Domain entsprechenden IP-Adresse verweist, ist die Suchanfrage weitergeleitet. Sobald das passiert, verhindert Google – aus welchen Gründen auch immer – den Zugriff auf ein bestimmtes Rechenzentrum.
Die Google Dance Testdomains www2 und www3
Der Beginn eines Google Dance kann stets anhand der beiden Testdomains www2.google.com und www3.google.com beobachtet werden. Den beiden Domains ist im Zeitablauf relativ fix jeweils eine (oft die gleiche) IP-Adresse zugeordnet. Vor Beginn des Google Dance wird zumindest einer der beiden Domains über das DNS die IP-Adresse desjenigen Rechenzentrums zugewiesen, dessen Server den neuen Index zuerst erhalten.
Der monatliche Aufbau eines komplett neuen Index ist mit vielen Risiken verbunden. Schließlich muss Google in kürzester Zeit einige Milliarden Dokumente spidern und anschließend viele TeraByte Daten verarbeiten. Damit sind Tests eines neuen Index unumgänglich. Natürlich benötigen nicht die Google-Mitarbeiter selbst die Domains www2.google.com und www3.google.com zu Testzwecken. Sie haben sicherlich die verschiedensten Möglichkeiten ihren Index zu überprüfen, wobei sie allerdings starken zeitlichen Restriktionen unterworfen sind.
Ein neuer Index wird also vielmehr über Testdomains einer interessierten Öffentlichkeit zugänglich gemacht, die sich in den verschiedensten Foren intensiv über die jeweiligen Index-Updates austauscht. Dieser Austausch kann dann von Google-Mitarbeitern verfolgt werden. Dabei bleibt das Update der allgemeinen Öffenlichkeit zunächst weitestgehend verborgen, da Google’s Name Server vor Beginn des Updates in der Regel so eingestellt wird, dass www.google.com nicht mehr zu der IP-Adresse desjenigen Rechenzentrums auflöst, das den neuen Index zuerst erhält.
Sobald auch der gar nicht so kleinen Gruppe von Testnutzern keine groben Fehlfunktionen durch das Index-Update auffallen, wird Google’s Name Server wieder so eingestellt, dass www.google.com auch wieder auf die IP-Adresse desjenigen Rechenzentrums aufgelöst wird, dass den neuen Index zuerst erhalten hat, und der Google Dance beginnt. Sollten sich beim Test des neuen Index durch die Nutzer allerdings gravierende Fehlfunktionen zeigen, besteht grundsätzlich die Möglichkeit, das Update der anderen Rechenzentren erst gar nicht einzuleiten. Die Domain www.google.com würde nicht auf die IP-Adresse des Rechenzentrums mit dem fehlerhaften Index auflösen und die Fehlfunktionen blieben der breiten Öffentlichkeit verborgen. In diesem Falle könnte der Index neu aufgebaut oder aber gegebenenfalls das Web neu gespidert werden.
Die Suchergebnisse die sich vor Beginn des eigentlichen Google Dance auf www2.google.com bzw. www3.google.com zeigen, werden bei einem reibungslosen Update zu einem späteren Zeitpunkt also stets auch auf www.google.com erscheinen. Dabei können sich allerdings immer noch geringfügige Fluktuationen ergeben. Zum einen gleicht der Index des einen Rechenzentrums nie exakt dem eines anderen. Dies lässt sich oft sehr leicht an der Anzahl der Suchergebnisse für beliebige Suchanfragen bei den weiter oben aufgelisteten Domains der einzelnen Rechenzentren ablesen. Zum anderen wird oft vermutet, dass die iterative PageRank-Berechnung beim ersten Aufspielen eines neuen Index nicht komplett abgeschlossen ist, so dass zunächst lediglich vorläufige Werte in die Rankings eingehen.
Die neuen PageRank-Werte im Laufe des Google Dance
Natürlich sind Positionsveränderungen der eigenen Seiten nach Beginn des Google Dance das wichtigste für jeden Webmaster. Daneben interessieren sich die meisten jedoch auch für die Entwicklung der PageRank-Werte ihrer Seiten. Bei der Abfrage der PageRank-Werte über die Google Toolbar kontaktiert diese jedoch in der Regel das Rechenzentrum, welches gerade im DNS-Eintrag für www.google.com festgelegt ist. Somit werden gerade zu Beginn des Google Dance meist die alten PageRank-Werte angezeigt.
Für dieses Problem existiert allerdings eine Lösung. Google übermittelt den PageRank in einfachen Textdateien an die Toolbar. Früher geschah dies per XML. Der Wechsel zu Textdateien fand im August 2002 statt. Die PageRank-Dateien können direkt von der Domain www.google.com abgerufen werden. In ihrer Grundform sehen die URLs der Dateien folgendermaßen aus (ohne Zeilenumbrüche):
http://www.google.com/search?client=navclient-auto&
ch=0123456789&features=Rank&q=info:http://www.domain.com/
Die PageRank-Dateien bestehen aus einer Zeile. Der PageRank-Wert ist die letzte Ziffer in dieser Zeile.
Die oben in der URL dargestellten Parameter sind unerlässlich für die Anzeige der PageRank-Dateien im Browser. So identifiziert sich mit dem Wert “navclient-auto” für den Parameter “client” die Toolbar. Mit dem Parameter “q” wird die abgefragte URL übermittelt. Der Wert “Rank” für den Parameter “features” legt fest, dass die PageRank-Dateien abgerufen werden. Wird dieser Parameter weggelassen, werden auch weiterhin XML-Dateien übermittelt. Der Parameter “ch” wiederum übergibt eine Prüfsumme für die URL, wobei sich diese Prüfsumme im Zeitablauf für einzelne URLs lediglich bei Updates der Toolbar ändern kann.
Die von der Toolbar abgerufenen PageRank-Dateien werden vom Internet Explorer gecached. Ihre jeweilige URL sowie die entsprechende Prüfsumme kann also im Ordner Temporary Internet Files eingesehen werden. Damit können die PageRank-Dateien direkt im Browser betrachtet werden. Da die PageRank-Dateien im Browser-Cache gespeichert werden und somit offen einsehbar sind und die Abfrage nicht automatisiert erfolgt, sollte ein direkter Einblick keine Verletzung von Googles Dienstleistungsbedingungen darstellen. Es ist allerdings Vorsicht geboten. Die Toolbar übermittelt einen eigenen User-Agent an Google. Es ist:
Mozilla/4.0 (compatible; GoogleToolbar 1.1.60-deleon; OS SE 4.10)
Hierbei ist 1.1.60-deleon eine Toolbar-Version, die sich natürlich ändern kann, und OS das Betriebssystem des jeweils eingesetzten Rechners. Google kann also nachprüfen, ob eine direkte Anfrage über den Browser erfolgt, sofern kein Proxy zwischengeschaltet und der User-Agent entsprechend modifiziert wird.
Nun aber dazu, wie die neuen PageRank-Werte in Erfahrung zu bringen sind: Beim Blick in den Cache des IE wird man in der Regel feststellen, dass die PageRank-Dateien nicht von der Domain www.google.com, sondern von IP-Adressen wie z.B. 216.239.33.102 abgerufen werden. Ebenso enthalten die URLs häufig einen weiteren Parameter “failedip” mit Werten wie z.B. “216.239.35.102;1111″, dessen Bedeutung nicht ganz klar ist. Es ist allerdings recht einfach, an die neuen PageRank-Werte zu gelangen: In der URL sind lediglich die IP-Adressen so zu modifizieren, dass Anfragen an ein Rechenzentrum gerichtet werden, dass bereits das Index-Update erhalten hat. Die erforderlichen Informationen hierzu finden sich weiter oben.
Google und PageRank sind geschützte Marken der Google Inc., Mountain View CA, USA. Quelle: http://dance.efactory.de/d-index.php
Artikel bei Wikipedia zum Thema Google Index-Update / Google Dancs
Ablauf und Konditionen
