Mit Dgit (nicht zu verwechseln mit dem gleichnamigen Debian-Projekt) setzt Github seine neue Serverarchitektur um. Die basiert auf einem verteilten System, das Git selbst verwendet. Github verspricht sich davon einige Vorteile, die es in einem Blogeintrag erläutert.
In einem Blogeintrag beschreibt Github die neue Dgit-Technologie ausgiebig. Der Name verwirrt allerdings: Dgit steht für Distributed Git. Dgit heißt aber auch eine Technologie, die das Debian-Projekt für verteilte Repositories verwendet. Beide haben nichts miteinander zu tun.
Bislang betrieb Github seine Server in Paaren und gab es von jeder Festplatte vier Kopien. Zwei wurden auf dem Hauptdateiserver als RAID betrieben, zwei warteten als Hot Spare aus dem Reserve-Server und waren über DRDB und ein Crossover-Kabel verbunden. Den Nachteil dieses Setups beschreibt Github auch gleich: Bei einem Ausfall des Hauptdateiservers musste ein Admin das überprüfen und den Hot Spare aktivieren. Das erforderte nicht nur einen schnellen Einsatz, sondern hatte unter Umständen auch Downtimes für viele Repositories zur Folge. Kein Wunder, hostet Github doch 35 Millionen Repositories und 30 Millionen Gists.
Distributed Git (kurz Dgit) legt Repositories hingegen auf drei Fileservern ab, hält sie synchron und versorgt sie mit Updates. Kommt eine Anfrage, wählt es den am besten erreichbaren Server aus, um zu antworten. Da potenziell drei Kandidaten antworten können, sollen die Lesezugriffe drei Mal so schnell klappen. Schreibanforderungen landen hingegen bei allen drei Servern. Melden zwei von ihnen Vollzug, gilt der Commit als abgeschlossen. Die Repositorys landen auf einem Cluster, das “github-dfs” (Dgit File Server) verwendet. Ihm vorgeschaltet sind das Github Frontend, auf das die Webclients zugreifen, sowie Git Proxys, die als Anlaufstelle für alleinstehende Git Clients dienen.
Für Github ergeben sich dank des Szenario einige Vorteile. Fällt jetzt ein Server aus, macht Dgit automatisch neue Kopien auf anderen Servern. Im Fehlerfall lässt sich so einfach um Server herum routen, ohne den Betrieb aufzuhalten, es gibt keinen Ausfall von Repositories mehr, kein Mitarbeiter muss umgehend zur Unfallstelle eilen. Außerdem lassen sich auch Produktivserver ohne Ausfälle neu booten. Auf die Hot-Spare-Fileserver kann Github so ebenfalls verzichten, diese sitzen nicht länger tatenlos auf der Ersatzbank.
Dgit benutzt Git für diese Infrastruktur, kein SAN oder verteiltes Dateisystem. Der Grund sei die Robustheit und die Geschwindigkeit, die ein “git log” oder “git blame” erfordern. Dgit legt die Repos auf Fileservern mit lokalen SSDs ab, die möglichst schnell antworten sollen. Zugleich arbeiten Git-Entwickler in der Firma, die bei Problemen am dahinter liegenden Code arbeiten können. Bei externen Lösungen wäre der Support schwieriger.
Nicht zuletzt zeigt der Blogeintrag, dass die CPU-Load auf den Servern nach der Umstellung deutlich abgenommen habe. Wer sich in die weiteren Details zur Umstellung einlesen möchte, findet diese im Post. Die Entwickler kündigen weitere an, um die Technologie hinter Dgit zu beleuchten.
