Google geeft inzicht in datacenterinfrastructuur

Google heeft onlangs vier 'research papers' gepubliceerd waarin het een beschrijving geeft van de manier waarop het concern de technische infrastructuur binnen zijn datacenters heeft opgezet. Interessant is dat de papers aangeven hoe de diverse generaties van deze infrastructuur ontstonden als gevolg van de almaar groeiende behoefte aan bandbreedte, inclusief enkele misstappen.

Het is een publiek geheim dat Google in zijn datacenters nauwelijks nog commercieel verkrijgbare hardware en software gebruikt. Vrijwel alles - van besturingssystemen tot netwerkmanagementsoftware en van servers tot switches - is intern ontwikkeld. In een blogpost schrijft Google Fellow Amin Vahdat dat in de beginjaren het bedrijf nog 'off-the-shelf' hardware kocht bij de bekende fabrikanten van server- en netwerkapparatuur. De enorme vraag naar zoekdiensten maakte echter al gauw duidelijk dat dit een eindig verhaal was. In figuur 1 is een schema weergegeven hoe de diverse architecturen elkaar vervolgens in de loop van de tijd opvolgden.

Figuur 1. Chronologische ontwikkeling van de netwerktechnologie die Google intern toepast.

Misstappen

Inmiddels is men bij een aanpak genaamd 'Jupiter' aangekomen. Deze architectuur maakt het mogelijk dat 100.000 servers met een totale bandbreedte (Google noemt dit: 'biscetion bandwith') van 1 Petabyte per seconde met elkaar kunnen samenwerken. In de praktijk betekent dit dat iedere server met iedere server kan 'praten' en daarvoor een bandbreedte ter beschikking heeft van 10 Gb per seconde. Dat getal van 100.000 is niet willekeurig gekozen. Dat is namelijk het aantal servers dat zich binnen de zeer sterk gestandaardiseerde datacenters van het bedrijf bevindt. Jupiter maakt het voor Google mogelijk deze 100.000 servers per datacenter te gebruiken alsof het om één gigantische computer gaat. Anders gezegd: ieder datacenter wordt binnen het bedrijf gezien als één groot uitgevallen server.

Het heeft wel even geduurd voordat Google op deze manier van werken uitkwam, schrijft Amin Vahdat in zijn blogpost. Zoals uit figuur 1 blijkt, heeft men inmiddels al heel wat generaties achter de rug en daar zaten hier en daar ook wel wat misstappen tussen. Zo heeft Google in de beginjaren geprobeerd om de switching-functionaliteit van het netwerk te integreren in zijn servers. Op zich lukte dat wel, ware het niet dat de beschikbaarheid van individuele servers hierdoor aanzienlijk omlaag ging.

Eigen hardware

In 2005 gebruikte het bedrijf nog standaard server-hardware. Dat was in de tijd dat Gmail al was gelanceerd, maar men YouTube nog niet had gekocht. Intern was men al wel aan het kijken naar mogelijkheden voor optimalisatie van het datacenter, wat de naam Firehose mee kreeg. De bisection bandwith lag in die jaren op 1 Gbps bij een datacenter dat toen al 10.000 servers omvatte. Firehose was ook de architectuur waarin Google probeerde om servers en switches met elkaar te integreren. Zonder succes dus.

Met Firehose 1.1 kwam de eerste volledig intern ontwikkelde - wat het bedrijf noemt - 'datacenter cluster fabric'. Zeg maar: de architectuur van Google's datacenters. Voor de netwerkinfrastructuur betekende dit een aanpak zoals weergegeven in figuur 2. Alles kan met alles 'praten'. Dat betekende dat er meer dan tienduizend switches nodig waren. Dat ging niet met de standaard apparatuur van vendoren, dus koos men voor een toen net ontwikkeld concept genaamd: software defined networking. Alles werd hierdoor anders: van switching-hardware tot netwerkprotocollen. Traditionele switches leren op dynamische wijze hoe het netwerk is opgebouwd. Op basis van die informatie sturen zij datapakketjes door. Dat gebeurt met standaard protocollen die weliswaar robuust zijn, maar die wel redelijk veel overhead met zich meebrengen. Met andere woorden, een flink gedeelte van de beschikbare capaciteit is voor netwerkadministratie en dergelijke nodig en kan dus niet gebruikt worden voor het transporteren van data zelf. Bovendien werden switches in dergelijke omgevingen nog grotendeels handmatig beheerd en dat kost tijd en maakt de kans op fouten onacceptabel groot - zeker bij de aantallen en de beschikbaarheidseisen waarmee Google werkt.

Figuur 2. De netwerktopologie binnen de datacenters van Google.

Broadcast-protocol

Om een voorbeeld te geven van de problemen waar Google tegenaan liep: als zich wijzigingen in het netwerk binnen het datacenter voordoen - wat bij het bedrijf natuurlijk dagelijks gebeurt - worden deze aanpassingen in een traditioneel netwerk via een broadcast-protocol aan alle switches bekend gemaakt. Dit protocol werkt goed, maar is relatief traag. Het kan dus even duren voordat de wijzigingen overal in het netwerk bekend zijn. Dat is te traag voor een bedrijf als Google. Dan kan het gebeuren dat de ene wijziging nog niet overal bekend is, terwijl de volgende wijziging alweer in gang is gezet. Daarom koos Google voor een andere aanpak. Het keek niet meer naar individuele servers en switches maar naar het totale datacenter. Iedere switch speelt hierin een eigen en duidelijk omschreven rol. Men bouwde voor het volledige datacenter een centrale configuratie van het netwerk op en 'pusht' deze vervolgens naar alle switches. Iedere switch haalt uit deze configuratie de info die het nodig heeft om de eigen rol binnen het datacenter te kunnen spelen. Dit is schematisch weergegeven in figuur 3.

Figuur 3. De routing-structuur die Google toepast.

Dit is het principe waarmee Google nog altijd binnen zijn datacenters werkt. Na Firehose 1.1 volgde een WatchTower geheten aanpak met 10 GB fiber in plaats van klassieke bekabeling. Totale bisection bandbreedte: 87 Tbps. WatchTower werd opgevolgd door Saturn en de bisection bandwith groeide naar 207 Tbps. Saturn heeft het drie jaar volgehouden voordat Google opnieuw in capaciteitsptoblemen kwam. Inmiddels is men met Jupiter naar 40 Gbps en een bisection bandwith van 1 Pbps gegroeid, waardoor het bedrijf ieder datacenter nu inderdaad als één computer kan aansturen.

Nieuwe startups

Wat erg interessant is om te lezen, is de lans die het bedrijf breekt voor het met elkaar integreren van operations- en research-teams. Engineers die dagelijks bezig zijn met het beheer van de datacenters hebben nauw samengewerkt met R&D-technici én studenten om gezamenlijk nieuwe ideeën uit te werken en te onderzoeken. Dat is een bewuste keuze van het bedrijf geweest om daarmee niet alleen alle betrokken medewerkers bij dit soort trajecten te kunnen betrekken, maar ook om radicale ideeën een kans te geven.

Met het publiceren van de vier papers geeft Google nu inzage in de huidige stand van zaken binnen zijn datacenters. In het verleden heeft het bedrijf al vaker research papers gepubliceerd. Die hadden steevast tot gevolg dat een serie startups met de ideeën die in de papers werden beschreven aan de slag ging en nieuwe producten ontwikkelde die ook interessant zijn voor andere datacenters die minder grote eisen stellen. Die startups werden niet zelden opgezet door medewerkers die daarvoor nog bij Google in dienst waren en aan deze interne projecten werkten. Analisten gaan er van uit dat we ook ditmaal eenzelfde ontwikkeling zullen gaan zien.

De blogpost van Amin Vahda over de vier research papers en de documenten zelf zijn hier te vinden: http://googleresearch.blogspot.nl/2015/08/pulling-back-curtain-on-googles-network.html

Robbert Hoeffnagel