centros de datos de Google

El hardware original (alrededor de 1998) que utilizaba Google cuando estaba ubicado en la Universidad de Stanford incluía: ^{[ 78 ]}

• Sun Microsystems Ultra II con dos procesadores de 200 MHz y 256 MB de RAM . Esta era la máquina principal del sistema Backrub original .  
• Dos servidores Pentium II duales de 300  MHz , donados por Intel , contaban con 512 MB de RAM y 10 discos duros de 9 GB entre ambos. En estos servidores se ejecutó la búsqueda principal.  
• El ordenador IBM RS/6000 F50 , donado por IBM , incluía 4 procesadores, 512  MB de memoria y 8  discos duros de 9 GB.
• Dos cajas adicionales contenían tres discos duros de 9 GB y seis discos duros  de 4 GB respectivamente (el almacenamiento original de Backrub). Estos se conectaron al Sun Ultra II. 
•  Caja de expansión de disco SSD con otros 8 discos duros de 9 GB donados por IBM.
• Caja de discos casera que contenía 10 discos duros SCSI de 9  GB .

El estado de la infraestructura de Google en 2003 fue descrito en un informe de Luiz André Barroso , Jeff Dean y Urs Hölzle como una "infraestructura informática fiable a partir de clústeres de PC comerciales poco fiables". ^{[ 79 ]}

En ese momento, en promedio, una sola consulta de búsqueda leía ~100 MB de datos y consumía${\displaystyle \sim 10^{10}}$Ciclos de CPU. Durante las horas pico, Google procesaba aproximadamente 1000 consultas por segundo. Para gestionar esta carga máxima, construyeron un clúster de computación con aproximadamente 15 000 PC estándar en lugar de costosos superordenadores, con el fin de ahorrar dinero. Para compensar la menor fiabilidad del hardware, desarrollaron software tolerante a fallos .

La estructura del clúster consta de cinco partes. Los servidores web centrales de Google (GWS) están conectados a Internet. Al recibir una solicitud del usuario, el servidor web de Google se comunica con un corrector ortográfico, un servidor de publicidad, varios servidores de índices y varios servidores de documentos. Cada una de las cuatro partes responde a una parte de la solicitud, y el GWS recopila sus respuestas y ofrece la respuesta final al usuario.

Los documentos originales ocupaban aproximadamente 100 TB, y los archivos de índice, unos 10 TB. Los archivos de índice están fragmentados, y cada fragmento es gestionado por un conjunto de servidores de índice. De forma similar, los documentos originales también están fragmentados. Cada consulta al archivo de índice genera una lista de identificadores de documentos, que luego se envían a los servidores de documentos para recuperar el título y los fragmentos de texto con palabras clave en contexto.

Se utilizaron varias generaciones de CPU, desde servidores Intel Celeron  de 533 MHz con un solo procesador hasta servidores Intel Pentium III de 1,4 GHz con dos procesadores . Cada servidor contenía uno o más discos duros de 80 GB cada uno. Los servidores de índice tenían menos espacio en disco que los servidores de documentos. Cada rack contaba con dos conmutadores Ethernet , uno por lado. Los servidores de cada lado se interconectaban mediante una conexión de 100 Mbps. Cada conmutador tenía un enlace ascendente de aproximadamente 250 MB/s a un conmutador central que conectaba todos los racks. 

Los objetivos de diseño incluyen:

• Utilice hardware de consumo de baja fiabilidad y compénselo con software tolerante a fallos.
• Maximizar el paralelismo, por ejemplo, dividiendo la búsqueda de una única coincidencia de documento en un índice grande en un proceso MapReduce sobre muchos índices pequeños.
• Se dividen los datos del índice y los cálculos para minimizar la comunicación y equilibrar uniformemente la carga entre los servidores, ya que el clúster es una gran máquina de memoria compartida.
• Minimice los costos generales de administración del sistema desarrollando todo el software internamente.
• Elige el hardware que maximice la relación rendimiento/precio, no el rendimiento absoluto.
• Es preferible elegir hardware con alto rendimiento a uno con alta latencia . Esto se debe a que las consultas se procesan con un paralelismo masivo, con muy pocos pasos dependientes y una comunicación mínima entre servidores, por lo que la alta latencia no representa un problema.

Debido al paralelismo masivo, aumentar la escala del hardware incrementa el rendimiento de forma lineal; es decir, duplicar el clúster de computación duplica el número de consultas que se pueden atender por segundo.

El clúster está compuesto por racks de servidores con dos configuraciones: 40 unidades de 1U por lado con dos lados, o 20 unidades de 2U por lado con dos lados. El consumo de energía es de 10  kW por rack, con una densidad de 400 W/ft², lo que supone un consumo de 10 MWh al mes y un coste de 1500 dólares mensuales.

Desde 2014, Google utiliza una versión altamente personalizada de Debian Linux . Migraron gradualmente desde un sistema basado en Red Hat en 2013. ^{[ 80 ]}

El objetivo de la personalización es adquirir generaciones de CPU que ofrezcan el mejor rendimiento por dólar, no el rendimiento absoluto. No está claro cómo se mide esto, pero es probable que incorpore los costos operativos de todo el servidor, y el consumo de energía de la CPU podría ser un factor significativo. ^{[ 81 ]} Los servidores de 2009-2010 consistían en sistemas personalizados de cubierta abierta que contenían dos procesadores (cada uno con varios núcleos ^{[ 82 ]} ), una cantidad considerable de RAM distribuida en 8 ranuras DIMM que albergaban módulos DIMM de doble altura y al menos dos discos duros SATA conectados a través de una fuente de alimentación de tamaño ATX no estándar. ^{[ 83 ]} Los servidores eran de cubierta abierta para que cupieran más servidores en un rack. Según CNET y un libro de John Hennessy , cada servidor tenía una novedosa batería de 12 voltios para reducir costos y mejorar la eficiencia energética. ^{[ 82 ] [ 84 ]}

Según Google, la potencia eléctrica de operación de sus centros de datos globales oscilaba entre 500 y 681 megavatios en 2010. ^{[ 85 ] [ 86 ]} La potencia de procesamiento combinada de estos servidores podría haber alcanzado entre 20 y 100 petaflops en 2008. ^{[ 87 ]}

Los detalles de las redes privadas mundiales de Google no están disponibles públicamente, pero las publicaciones de Google ^{[ 88 ] [ 89 ]} hacen referencia al informe "Atlas Top 10" que clasifica a Google como el tercer ISP más grande después de Level 3 .

Para operar una red tan grande, con conexiones directas a la mayor cantidad posible de ISP al menor costo posible, Google tiene una política de interconexión muy abierta . ^{[ 90 ]}

Desde este sitio, podemos ver que se puede acceder a la red de Google desde 67 puntos de intercambio públicos y 69 ubicaciones diferentes en todo el mundo. A mayo de 2012, Google tenía 882  Gbit/s de conectividad pública (sin contar los acuerdos de interconexión privada que Google tiene con los ISP más grandes). Esta red pública se utiliza para distribuir contenido a los usuarios de Google, así como para rastrear internet y construir sus índices de búsqueda. El lado privado de la red es secreto, pero una divulgación reciente de Google ^{[ 91 ]} indica que utilizan conmutadores-enrutadores de alta capacidad personalizados (con una capacidad de 128 puertos Ethernet de 10 Gigabit ) para la red de área amplia . Al operar no menos de dos enrutadores por centro de datos (para redundancia), podemos concluir que la red de Google escala en el rango de terabits por segundo (con dos enrutadores completamente cargados, el ancho de banda biseccional asciende a 1280 Gbit/s).  

Estos conmutadores-enrutadores personalizados se conectan a dispositivos DWDM para interconectar centros de datos y puntos de presencia (PoP) a través de fibra oscura .

Desde la perspectiva del centro de datos, la red comienza en el nivel del rack, donde los racks de 19 pulgadas se fabrican a medida y contienen de 40 a 80 servidores (de 20 a 40 servidores de 1 U a cada lado, mientras que los servidores nuevos son sistemas de montaje en rack de 2U. ^{[ 92 ]} Cada rack tiene un conmutador Ethernet ). Los servidores se conectan mediante un enlace Ethernet de  1 Gbit/s al conmutador de la parte superior del rack (ToR). Los conmutadores ToR se conectan a un conmutador de clúster Gigabit mediante enlaces ascendentes de varios o diez gigabits. ^{[ 93 ]} Los conmutadores de clúster están interconectados y forman la estructura de interconexión del centro de datos (probablemente utilizando un diseño de libélula en lugar de una mariposa clásica o una mariposa aplanada ^{[ 94 ]} ).

Desde el punto de vista operativo, cuando un ordenador cliente intenta conectarse a Google, varios servidores DNS resuelven www.google.commúltiples direcciones IP mediante la política Round Robin . Además, esto actúa como primer nivel de equilibrio de carga y dirige al cliente a diferentes clústeres de Google. Un clúster de Google tiene miles de servidores , y una vez que el cliente se ha conectado al servidor, se realiza un equilibrio de carga adicional para enviar las consultas al servidor web con menor carga. Esto convierte a Google en una de las redes de distribución de contenido más grandes y complejas . ^{[ 95 ]}

Google cuenta con numerosos centros de datos repartidos por todo el mundo. Al menos 12 importantes instalaciones de centros de datos de Google se encuentran en Estados Unidos. Los centros más grandes conocidos están ubicados en The Dalles, Oregón ; Atlanta, Georgia ; Reston, Virginia ; Lenoir, Carolina del Norte ; y Moncks Corner, Carolina del Sur . ^{[ 96 ]} En Europa, los centros más grandes conocidos están en Eemshaven y Groningen, en los Países Bajos , y en Mons , Bélgica . ^{[ 96 ]} El centro de datos de Google en Oceanía se encuentra en Sídney , Australia . ^{[ 97 ]}

Para admitir la tolerancia a fallos , aumentar la escala de los centros de datos y acomodar conmutadores de baja radix, Google ha adoptado en el pasado varias topologías Clos modificadas. ^{[ 98 ]}

Uno de los centros de datos más grandes de Google se encuentra en la ciudad de The Dalles, Oregón , a orillas del río Columbia , aproximadamente a 129 km (80 millas  ) de Portland . El complejo, cuyo nombre en clave es "Proyecto 02", fue construido en 2006 y tiene aproximadamente el tamaño de dos campos de fútbol americano , con torres de refrigeración de cuatro pisos de altura. ^{[ 99 ] [ 100 ]} El sitio fue elegido para aprovechar la energía hidroeléctrica barata y el gran excedente de cable de fibra óptica de la región , un remanente del auge de las puntocom . Un plano del sitio apareció en 2008. ^{[ 101 ]}

En febrero de 2009, Stora Enso anunció que había vendido la fábrica de papel Summa en Hamina , Finlandia , a Google por 40 millones de euros. ^{[ 102 ] [ 103 ]} Google invirtió 200 millones de euros en el sitio para construir un centro de datos y anunció una inversión adicional de 150 millones de euros en 2012. ^{[ 104 ] [ 105 ]} Google eligió esta ubicación debido a la disponibilidad y proximidad de fuentes de energía renovables. ^{[ 106 ]}

En 2013, la prensa reveló la existencia de los centros de datos flotantes de Google a lo largo de las costas de los estados de California ( Edificio 3 de Treasure Island ) y Maine. El proyecto de desarrollo se mantuvo en estricto secreto. Los centros de datos tienen 250 pies de largo, 72 pies de ancho y 16 pies de profundidad. Google compró la patente de una tecnología de refrigeración para centros de datos submarinos en 2009 ^{[ 107 ] [ 108 ]} (junto con una patente de un centro de datos basado en barcos alimentado por energía undimotriz en 2008 ^{[ 109 ] [ 110 ]} ). Poco después, Google declaró que las dos enormes infraestructuras construidas en secreto eran simplemente "centros de aprendizaje interactivos, [...] un espacio donde la gente puede aprender sobre nuevas tecnologías". ^{[ 111 ]}

Google detuvo el trabajo en las barcazas a finales de 2013 y comenzó a venderlas en 2014. ^{[ 112 ] [ 113 ]}

La mayoría de las operaciones son de solo lectura. Cuando se requiere una actualización, las consultas se redirigen a otros servidores para simplificar los problemas de coherencia. Las consultas se dividen en subconsultas, que pueden enviarse a diferentes conductos en paralelo , reduciendo así el tiempo de latencia. ^{[ 92 ]}

Para minimizar los efectos de fallos de hardware inevitables , el software está diseñado para ser tolerante a fallos . De este modo, cuando un sistema falla, los datos siguen estando disponibles en otros servidores, lo que aumenta la fiabilidad.

Al igual que la mayoría de los motores de búsqueda, Google indexa los documentos mediante la creación de una estructura de datos conocida como índice invertido . Este índice obtiene una lista de documentos a partir de una palabra clave. El índice es muy grande debido a la cantidad de documentos almacenados en los servidores. ^{[ 95 ]}

El índice se divide por identificadores de documentos en varias partes llamadas fragmentos . Cada fragmento se replica en múltiples servidores. Inicialmente, el índice se servía desde discos duros , como se hace en los sistemas tradicionales de recuperación de información (RI). Google gestionó el creciente volumen de consultas aumentando el número de réplicas de cada fragmento y, por lo tanto, el número de servidores. Pronto descubrieron que tenían suficientes servidores para mantener una copia de todo el índice en la memoria principal (aunque con poca o ninguna replicación), y a principios de 2001 Google cambió a un sistema de índice en memoria . Este cambio «modificó radicalmente muchos parámetros de diseño» de su sistema de búsqueda y permitió un aumento significativo en el rendimiento y una gran disminución en la latencia de las consultas. ^{[ 131 ]}

En junio de 2010, Google lanzó un sistema de indexación y distribución de próxima generación llamado "Caffeine", capaz de rastrear y actualizar continuamente el índice de búsqueda. Anteriormente, Google actualizaba su índice de búsqueda por lotes mediante una serie de trabajos MapReduce . El índice se dividía en varias capas, algunas de las cuales se actualizaban más rápido que otras, y la capa principal podía tardar hasta dos semanas en actualizarse. Con Caffeine, todo el índice se actualiza de forma incremental y continua. Posteriormente, Google reveló un sistema de procesamiento de datos distribuido llamado "Percolator" ^{[ 132 ]} , que se considera la base del sistema de indexación Caffeine. ^{[ 124 ] [ 133 ]}

La infraestructura de servidores de Google se divide en varios tipos, cada uno asignado a un propósito diferente: ^{[ 92 ] [ 95 ] [ 134 ] [ 135 ] [ 136 ]}

• Los servidores web coordinan la ejecución de las consultas enviadas por los usuarios y, a continuación, formatean el resultado en una página HTML . La ejecución consiste en enviar consultas a los servidores de indexación, combinar los resultados, calcular su clasificación, obtener un resumen de cada resultado (mediante el servidor de documentos), solicitar sugerencias a los servidores de corrección ortográfica y, finalmente, obtener una lista de anuncios del servidor de publicidad.
• Los servidores de recopilación de datos están dedicados permanentemente a rastrear la web. El rastreador web de Google se conoce como GoogleBot. Actualizan las bases de datos de índices y documentos y aplican los algoritmos de Google para asignar clasificaciones a las páginas.
• Cada servidor de índices contiene un conjunto de fragmentos de índice. Estos devuelven una lista de identificadores de documentos ("docid"), de modo que los documentos correspondientes a un docid determinado contienen la palabra de consulta. Estos servidores requieren menos espacio en disco, pero soportan la mayor carga de trabajo de la CPU.
• Los servidores de documentos almacenan los documentos. Cada documento se guarda en decenas de servidores. Al realizar una búsqueda, un servidor de documentos devuelve un resumen del documento basado en las palabras clave de la consulta. También pueden recuperar el documento completo si se les solicita. Estos servidores requieren más espacio en disco.
• Los servidores de anuncios gestionan la publicidad ofrecida por servicios como AdWords y AdSense .
• Los servidores de corrección ortográfica ofrecen sugerencias sobre la ortografía de las consultas.

También existen las "solicitudes canary", mediante las cuales una solicitud se envía primero a uno o dos servidores hoja para comprobar si el tiempo de respuesta es razonable. Si no lo es, la solicitud falla. Esto proporciona seguridad. ^{[ 137 ]}