Cómo Railway construyó su propio centro de datos
(blog.railway.com)- Railway consideró que el cómputo basado en GCP limitaba el precio, soporte y desarrollo de funciones, por lo que inició Railway Metal, una infraestructura física con control más directo
- Tras comenzar en enero de 2024, tardaron 5 meses hasta conectar el primer servidor, y 3 meses más hasta poner cargas de trabajo de usuarios; 9 meses después entró en operación el primer sitio en California
- Más que el alquiler del espacio, las mayores limitaciones fueron la energía y la refrigeración; en lugar de Greenfield o arrendar racks por unidad, Railway eligió Cage Colocation
- La red se diseñó con al menos 2 ISP por región, tabla de enrutamiento completa de internet, selección de rutas por prefijo IP y varias zones para resistir la falla de un solo centro de datos
- Tuvieron que encargarse directamente de la disposición de racks, documentación de cableado, PDU, switches con airflow inverso, Redfish API, PXE, FRR y SONiC; construir su propia nube se parece más a construir una casa que a desplegar con Terraform
Por qué se movieron de GCP a Railway Metal
- El cómputo de Railway estuvo construido sobre Google Cloud Platform desde el inicio
- GCP ayudó en la etapa inicial de crecimiento, pero a medida que la operación creció, empezaron a surgir límites para ofrecer a los clientes la plataforma que querían
- Operar sobre un hiperescalador limitaba directamente el precio, el nivel de servicio y el alcance del desarrollo de funciones que Railway podía ofrecer
- Las egress fee impactaban el precio
- Incluso cuando había problemas en la infraestructura superior, rara vez podían entender la causa raíz
- Evaluaban que, aun gastando millones de dólares al año, el nivel de soporte no era muy distinto al de alguien que gasta 100 dólares
- En respuesta, Railway inició el proyecto Railway Metal en 2024
- 9 meses después puso en marcha su primer sitio en California
- Diseñaron, especificaron e instalaron por su cuenta desde los cables de fibra dentro del cage hasta los contratos con los ISP
- Además, están habilitando 3 regiones de centros de datos adicionales
La primera elección de espacio: un cage en un centro de datos
- El proyecto Railway Metal comenzó en enero de 2024 y tomó 5 meses hasta conectar el primer servidor
- Hicieron falta 3 meses adicionales antes de decidir que ya era seguro ejecutar cargas de trabajo de usuarios sobre el hardware
- La infraestructura propia requiere espacio para alojar servidores, energía estable y refrigeración suficiente
- Había tres opciones principales
- Greenfield buildout: comprar o arrendar un centro de datos
- Cage Colocation: asegurar un espacio dedicado rodeado por paredes de malla dentro de un centro de datos operado por un tercero
- Rack colocation: arrendar racks individuales o una parte de ellos en un centro de datos de colocation
- Railway eligió Cage Colocation para obtener un espacio vacío con cuatro paredes, puerta de seguridad y libertad para diseñar el resto por su cuenta
- El costo del espacio en sí no era tan grande, pero la energía y la refrigeración asociada eran lo más costoso
- Según la región, el costo por kW varía mucho
- En la costa oeste de EE. UU. puede costar menos de la mitad que en Singapur
- La energía se paga como un compromiso mensual fijo para garantizar disponibilidad on-demand, independientemente del uso real
Diseño eléctrico y PDU
- Para igualar la capacidad que usaban en GCP, Railway primero definió un objetivo de vCPU, GB de RAM y TB de NVMe
- Con esas cifras eligieron servidores y CPU
- La variable clave era la densidad de potencia: cuánta capacidad de cómputo podían meter dentro de un consumo eléctrico determinado
- Calcular energía no se reduce a sumar watts, y en especial con alimentación trifásica se vuelve más complejo
- Cloudflare tiene una introducción a la energía trifásica y las PDU sobre el tema
- En un centro de datos, la energía es el recurso más importante, y un corte puede implicar tiempos de recuperación muy largos
- Cada rack necesita 2 feeds de energía completamente independientes
- En condiciones normales, ambos feeds comparten la carga
- Debe poder resistir si uno de los feeds cae
- Para llevar energía a los servidores se necesita una Power Distribution Unit
- Una PDU básica es, en la práctica, parecida a una regleta expandida
- Las PDU que Railway despliega permiten control y medición por toma individual
- Cada PDU es accesible por red y permite medir y controlar remotamente cada toma
Red: ISP, enrutamiento y rutas por región
- Una máquina en la nube no existe aislada, así que la red cumple un papel clave
- Railway buscó instalaciones de centros de datos con conectividad sólida hacia el mundo exterior para mantener baja latencia
- Sus condiciones preferidas eran las siguientes
- Estar on-network con un ISP Tier 1
- Estar incluido en un Internet Exchange
- Tener fibra que permitiera conectarse a otros centros de datos cercanos
- Las aplicaciones desplegadas en Railway se comunican con distintos tipos de endpoints
- Un usuario de internet residencial en Sídney
- Una API alojada en un servidor de AWS en EE. UU.
- Para lograr baja latencia y bajo costo de ancho de banda, Railway firmó con varios proveedores de internet optimizados para distintos casos de uso
- Los ISP se eligieron según la madurez de su red en la región objetivo
- Trabajar con el ISP equivocado puede agregar hops de red adicionales hasta ciertos mercados objetivo y aumentar la latencia
- En el peor caso, puede generar rutas de red complejas y enredadas
- En cada región eligieron al menos 2 redes separadas según su footprint regional
- Una vez conectados, reciben de cada ISP la tabla completa de enrutamiento de internet y la consolidan en los switches de red para decidir la mejor ruta por prefijo IP
- Si un usuario en Australia accede a una app desplegada en Singapur, es probable que el tráfico se entregue a Telstra
- Si esa misma app envía tráfico a usuarios o servidores en Japón, es probable que lo entregue a PCCW
- La información de peering es pública y puede verse la interconexión de redes en bgp.tools
- Para redundancia, están construyendo varias zones dentro de cada región, y la interconexión entre sitios también es importante para escalar
- Están evaluando herramientas como dark fiber o wavelength service
- La idea es que la app no note diferencia entre tener la base de datos en la misma sala o en un edificio vecino a 4 cuadras
- Es un diseño orientado a mejorar la resiliencia ante la falla de un centro de datos individual
Racks, pasillos, refrigeración y rutas de cableado
- En un centro de datos, los racks se colocan en filas y los pasillos entre ellos se usan para el flujo de aire
- En el Cold Aisle entra aire frío desde la instalación, y los servidores lo absorben antes de expulsarlo hacia el Hot Aisle en la parte trasera
- Para mejorar la eficiencia, el aire entre el Cold Aisle y el Hot Aisle no debe mezclarse
- Aunque los equipos suelen usar ancho de 19 pulgadas, la altura, el ancho y la profundidad del rack pueden elegirse según el equipo y los requisitos de cableado
- La mayoría de los equipos de servidor pueden extraerse hacia adelante sobre rieles para mantenimiento, así que las dimensiones del cage deben permitirlo
- También hace falta espacio para cables y gestión de cables, lo que crea una compensación entre qué tan densamente llenar los racks y cuántos racks meter dentro del cage
- Según la experiencia de Railway, la energía y la refrigeración se vuelven una limitación con más frecuencia que el espacio físico real
- En sitios nuevos eligieron racks más anchos, de 800 mm, para sacar el cableado de la ruta de escape del aire y mejorar el airflow
- Además de los racks, se necesita infraestructura superior y bandejas para llevar energía y datos
- Se enruta fibra desde el borde del cage hasta cada rack
- También se enrutan cables entre racks
- Estos elementos a veces están incluidos en la cotización del cage por parte del operador del centro de datos
- Como Railway tiene alta densidad de cables de fibra entre switch y servidor en cada rack, compró switches con reverse airflow cuyos puertos apuntan hacia la parte trasera del rack
- Son switches que expulsan el aire hacia el lado donde están los puertos de red
- Ajustan las bandejas de cableado para que todo el cableado ocurra de un solo lado del rack
- Así evitan que los cables vayan zigzagueando entre el frente y la parte trasera del rack
Documentación de instalación y rack-and-stack
- Railway intentó hacer el cableado por su cuenta al inicio, pero los resultados fueron irregulares, así que recurrió a especialistas para instalarlo correctamente
- Para que los técnicos sepan qué instalar y dónde, hace falta un paquete de documentación completo
- La documentación habitual incluye dos elementos
- Cabling matrix: define la ubicación del equipo en ambos extremos de cada cable, los puertos, especificación del cable, tipo de fibra, longitud y más
- Rack elevation: muestra visualmente la posición y orientación de cada equipo dentro del rack
- Cada fase de instalación de Railway incluye más de 60 equipos, más de 300 cables individuales y decenas de detalles finos
- Las especificaciones escritas y hojas de cálculo que sirven de base para la instalación y la puesta en marcha se elaboran manualmente
- Después de que los materiales llegan al sitio, completar toda la instalación toma aproximadamente 6 a 14 días
- Más adelante, Railway creó una herramienta interna para automatizar la generación de build specification
- Construir un cage en un centro de datos se parece poco al despliegue de software típico, DevOps o un stack de Terraform, y mucho más a construir una casa
- Cada instalación, contratista y proveedor opera de manera un poco distinta, incluso dentro de la misma organización, por lo que hace falta mucha atención a detalles operativos muy finos
Excepciones y problemas físicos encontrados en sitio
- En un sitio, una PDU estaba instalada al revés, por lo que la energía entraba desde el piso y los números de toma del plan quedaban invertidos
- En el sitio de Ámsterdam, había una instalación donde el enlace de fibra externo llegaba directamente a una caja dentro del rack, en lugar de pasar por un demarcation point dedicado
- Algunas instalaciones, a diferencia de otros sitios, cableaban los enchufes eléctricos como phase-to-neutral, mientras que otras usaban phase-to-phase
- Hubo un caso donde un contratista no sabía que el equipo de red tenía reverse airflow e intentó montarlo al revés, concluyendo que los cables de datos eran demasiado cortos
- En cierto cable, la razón por la que el link no levantaba era un error de polaridad en la fibra, y fue entonces cuando Railway conoció los “rolling fibre cables”
- Consiste en sacar y cruzar entre sí los conectores de un LC connector
- Alrededor de 24 PDU de un proveedor tenían defectos en las tomas y los enchufes de energía no encajaban correctamente, y ni siquiera aplicando fuerza física considerable se resolvía
Trabajo de software después de la instalación física
- Una vez que el hardware queda en su lugar, el trabajo pasa a un terreno de software más familiar
- Las tareas necesarias incluyen lo siguiente
- Configuración de BGP
- Instalación del OS
- Configuración de monitoreo
- Configuración del equipo de red
- Escritura de la configuración de routers
- Actualización de registros del RIR, es decir, el registro regional de internet
- Para acceder a los controladores dedicados de servidores y PDU, usan las Redfish APIs
- Para arrancar servidores por red, usan PXE
- El diseño de red de Railway utiliza switches de red whitebox que ejecutan FRR y SONiC
- Con este diseño, construyeron una red guiada por software, solo L3, profundamente integrada con el control plane de Railway
- En los últimos meses, Railway creó nuevas herramientas de software llamadas Railyard y MetalCP
- Diseñar nuevos cages
- Rastrear y visualizar cableado
- Instalar el OS de servidores
- Son herramientas pensadas para llevar hasta una experiencia de clics el proceso de conectar servidores a internet
- En un próximo artículo explicarán cómo convierten un conjunto de servidores en una sala en una zone funcional de Railway
1 comentarios
Comentarios en Hacker News
Por mi experiencia y por textos como este, parece que a Google no le gusta tener clientes
Como que alguien decidió que “hay que hacer nube pública” y la construyeron, pero da la impresión de que quieren mantener a los clientes a tres metros de distancia
Estoy 100% seguro de que un ejecutivo de cuentas de AWS se metería al lodo contigo si hiciera falta. Si se lo pides en una crisis, hasta dormiría en el suelo contigo
En cambio, los de Google Cloud me dan tristeza. Porque se nota que dentro de Google los quieren y los apoyan menos que a nosotros. Da pena ver a alguien intentando convencer a su propia empresa de vender y dar servicio como es debido, y parece que estuvieran configurados para fracasar
La gente de Microsoft es durísima, vende bien, da buen servicio, y logra sacarte hasta el último centavo del bolsillo haciéndote creer con toda el alma que eso te conviene. Pero su nube es una cosa muy rara…
Que Railway se vaya a bare metal es algo a lo que, después de unos 15 años haciéndolo, jamás, jamás, jamás querría volver. No vale la pena. Pero supongo que hay que vivirlo en carne propia para entenderlo; así suele ser ese camino
Pronto van a descubrir por qué Google la pasa tan mal. Ahora, si de verdad tienes muchas ganas de vender servicios a la gente en vez de construir Borg o cerebros artificiales, podrías hacerlo 100 veces mejor que Google
Aun así, no me lo imagino metiéndose al lodo conmigo, y eso me sorprende un poco. Me pregunto cuánto habrá que gastar para entrar en la etapa de acompañamiento en el lodo
Todo el servicio de nube se siente como si lo hubiera diseñado alguien que no sabe absolutamente nada de computación en la nube y solo conoce “rentar servidores bare metal”. Sí es computación en la nube, pero de una forma que destruye el concepto mismo de computación en la nube
También
gcloud, la herramienta de línea de comandos de GCP, se siente mejor diseñadaEso nos habría ahorrado meses de trabajo previo
En mi experiencia personal, el soporte de Google Cloud nos trató bastante bien incluso siendo un equipo pequeño de tres personas con un gasto muy bajo, y en otra empresa Microsoft también nos trató muy bien. Aunque en ese caso el nivel de gasto probablemente era del tipo que hasta podría rastrearse monitoreando la red eléctrica del centro de datos
En cambio, AWS mintió sobre una funcionalidad y al final nunca respondió
Los ejecutivos de cuentas que negocian con la alta dirección contratos imprescindibles de AWS por millones de dólares parecen saber muy bien cómo hablarle a esos directivos
Pero cuando llegó el momento real de desarrollar y entregar un producto para otras personas, nos dejaron solos tragando polvo
Lo más gracioso es que esa funcionalidad sobre la que mintieron era justamente la que vendían como clave para hacer que la experiencia del usuario final fuera excelente
Respondí al ticket de soporte, pero no hubo respuesta, y también les mandé correo a dos contactos de AWS, pero tampoco contestaron
Me hace recordar a los viejos tiempos de Rackspace. De verdad pasaban muchas cosas dignas de una guerra
Una vez llegó gente de EMC a instalar equipo de almacenamiento para pruebas y, entre que se estorbaban entre ellos, terminaron bajando por completo un rack de servidores como si fuera una comedia. Obviamente no consiguieron el contrato
En otra ocasión, un conductor de camión sufrió un infarto, y por el accidente el centro de datos de DFW quedó fuera de línea. Había bolardos para evitar este tipo de situaciones, pero todavía no los habían rellenado con cemento
En algún momento hasta lanzaron ancho de banda por láser hacia otro edificio al otro lado de la calle para montar una conexión temporal
Un día los servidores literalmente empezaron a incendiarse, así que rompieron una ventana y fueron a comprar ventiladores de caja
La ingeniería de centros de datos ha avanzado bastante desde aquellos primeros tiempos. En ese entonces trabajaban con Facebook en el OpenCompute Project, y ya tenían conceptos de infraestructura muy adelantados para la época
Un enlace principal de microondas se caía constantemente, con errores intermitentes de paquetes en las capas profundas del enlace de datos. Al investigar, resultó que a un árbol del otro lado del camino le habían salido hojas y las ramas se mecían hasta entrar en la línea de vista del equipo de nuestro edificio. Con una escalera, una sierra y 10 minutos, el enlace volvió a funcionar
El router BGP principal que salía del centro de datos seguía reiniciándose. No había equipo redundante. Al revisar, el centro de datos estaba demasiado caliente y la refrigeración era tan mala que la temperatura del aire en la entrada de los ventiladores superaba los 60°C. Lo resolvieron provisionalmente apuntándole un ventilador
Unas semanas después también murió el aire acondicionado de otra sala y empezó a rociar agua sobre un Nortel DMS-100. Era un ISP de dial-up con su propio switch. No me entusiasmaba ayudar a secarlo porque pensé que el agua podía conducir electricidad, pero no había de otra
Después trabajé en una pequeña isla remota, donde el enlace principal a internet era una conexión de 1MB/s por satélite GS y el ping superaba los 500ms. Los locales se conectaban por dial-up sobre una red telefónica de microondas calificada para 9600 baud, pero por alguna razón los módems de 56k sí funcionaban
Un día me di cuenta de que a una caja Solaris le faltaba un
.soimportante, y no había respaldo local ni medio de instalación. Llamé a un amigo en el Reino Unido y le pedí que subiera una copia a un servidor FTP, y así logré volver a poner esa máquina en líneaAños después también instalé un enlace láser sobre Oxford Road en Manchester, entonces la ruta de autobuses más transitada de Europa, para conectar una oficina con el campus universitario. Eran tiempos divertidos
Todo fue muy divertido, pero la verdad agradezco muchísimo que ahora casi todo lo que hago sea solo software
Aunque los servidores no se incendiaron literalmente, eso de abrir ventanas y usar ventiladores también pasó en enero de 2024 en el centro de datos Equinix CH1 de Chicago. Azure ExpressRoute se cayó
Escuché que hizo tanto frío que el CRAC no pudo aguantar. Según dicen, dejaron abiertas todas las puertas y ventanas para mantenerlo lo suficientemente frío, pero al final no funcionó. Si el CRAC cae, los servidores también
Ese switch definitivamente estaba maldito. Más tarde esa misma semana, un error de configuración de spanning tree en ese mismo equipo dejó a LINX fuera de servicio durante varias horas, y la mitad del peering de los ISP del Reino Unido cayó en un caos temporal. Todas las demás personas involucradas en ese proyecto también murieron dentro de los siguientes dos años
Años después recorrí la instalación y el cadáver asado seguía ahí en el suelo, justo debajo
La parte del artículo que dice “aunque gastes millones de dólares al año, solo recibes el nivel de soporte de alguien que paga 100 dólares” duele. Es un problema bastante grande en Google
Este artículo me resultó especialmente divertido porque vivimos aventuras parecidas al construir la infraestructura de Blekko
En una empresa como Blekko, donde el tráfico entre racks, es decir, el tráfico este-oeste, era mayor que el tráfico que iba y venía de internet, era fundamental que los servicios colocados físicamente juntos no compitieran por ancho de banda con otros servidores, y resultaba mucho más económico que pagar ese caso especial en SoftLayer, es decir, la nube cautiva de IBM
También hay empresas bastante interesantes que construyen recintos para encerrar el pasillo frío. Básicamente hacen que todo el aire frío que sale del piso entre por la parte trasera de los servidores y no se fugue hacia otros lados
También evitan que aire menos frío se meta desde los laterales hacia los servidores
También es interesante calcular la capacidad HVAC/CRAC de un centro de datos. En nuestra primera instalación de colocación teníamos derecho de tanteo para expandirnos hacia la superficie de piso junto a nuestra jaula, pero cuando llegó el momento real de expandirnos, la instalación ya no tenía capacidad de refrigeración disponible, así que no sirvió de nada
Después de pasar por este proceso, la solución de 0xide se entiende mucho mejor
Así es como se construye una empresa dominante. Bien por ignorar la noción llorona de que hay que quedarse atrapado en los hiperescaladores
Si eres una empresa de infraestructura, debes ser dueño del bare metal que vendes. Si no, no eres más que un revendedor de nube, y siempre corres el riesgo de perder por precio frente a un competidor de bare metal con costo de egreso en cero
Gracias a la colocación y al peering, Cloudflare puede ofrecer un plan gratuito porque puede llevar el costo de egreso a 0 dólares, y ningún nuevo participante puede competir con Cloudflare simplemente revendiendo servicios en la nube
De hecho, el sobreprecio del ancho de banda de los hiperescaladores no es solo una fuente de ingresos, sino un foso defensivo. Impide construir el siguiente AWS encima de AWS, y crea un segmento de mercado completamente nuevo y estratégicamente más débil llamado “PaaS” sobre IaaS
Con esto podemos reducir ese costo a la mitad, bajar también el costo de almacenamiento y eliminar el esquema de precios “por asiento”
Estoy realmente entusiasmado
Es un texto bastante bueno. Una cosa que me viene a la mente es por qué hicieron su propia herramienta interna para gestionar racks. NetBox ya existe
NetBox es excelente, y ojalá hubiera existido cuando administraba más de 50 racks a mediados de los 2000
https://github.com/netbox-community/netbox
Pero la razón por la que nuestra herramienta, Railyard, encaja tan bien es porque está profundamente integrada con todo nuestro stack de software, hardware y orquestación
El problema de las herramientas de código abierto es que son demasiado genéricas. En vez de resolver el problema, terminas doblando el problema para que encaje en el modelo de datos de la herramienta
Al final, es muy probable que integremos esta herramienta dentro de Railway mismo. Si quisieras irte on-premise, sería algo así como ofrecer diseño de hardware, comisionamiento, despliegue y experiencia para desarrolladores con solo hacer clic en un botón. Algo parecido a lo que hace Oxide, pero abordado desde el lado opuesto
https://github.com/netbox-community/netbox/issues?q=is%3Aiss...
NetBox quiere ser la “fuente de verdad (source of truth) de la infraestructura de red”
Lo importante cambia según cada caso, pero la historia podría haber sido distinta si NetBox hubiera apuntado a ser un repositorio central sin insistir en que ciertos elementos no pueden tener su verdad en otros sistemas
Aprendimos que los intentos de centralizar la complejidad y el control no funcionan. Ya se sabía casi inmediatamente después de que se aprobara la Clinger-Cohen Act, y ahora ITIL y TOGAF también lo tratan con claridad. Sospecho que en los próximos años los consultores van a explotar mucho ese punto
Sí se necesita una forma central y consistente de encontrar el estado. Para eliminar la duda sobre dónde buscar la información autorizada
Pero si quieres escalar, crecer o adaptarte a nuevos cambios, conviene evitar sistemas prescriptivos como esta nueva caja centralizada
No es un software especialmente gratificante de usar
Es el típico caso de “necesitamos X y Y hace X”, ignorando que Y también hace Z, M, Q y hasta lava los platos, y que nada de eso hace falta
A veces la solución más fácil es construir solo lo que necesitas. Especialmente si lo que necesitas es CRUD frente a una base de datos
En la práctica, solo estás ampliando el alcance. NetBox puede ser un buen punto de partida si empiezas desde ahí y estás dispuesto a acomodar tu sistema a su alrededor
Pero si ya tienes un sistema o necesitas hacer cosas que no encajan con la lógica de NetBox, probablemente sea mejor extender el sistema existente
En este caso, Railway necesita preocuparse por muchísima más información adicional, más allá de racks, direcciones IP y servidores físicos
Trabajé en automatización de reparación de equipos en una gran empresa tecnológica. Creo que las reparaciones están subestimadas, pero son de las cosas más difíciles de manejar
Cuando corres en AWS, casi no te preocupas por el hardware averiado. Normalmente se repara solo, en la práctica
Cuando lo operas tú mismo, no tienes ese lujo. Necesitas refacciones, técnicos que reparen, procedimientos para sacar y volver a meter cargas de trabajo en los hosts, suites de pruebas, herramientas de monitoreo de hardware y mil una cosas más
A pequeña escala puedes medio improvisar algunas partes, pero al final te pasa la factura. Y eso es solo hablando de servidores
El equipo de red trae otro conjunto de problemas interesantes, y si falla puede tumbar un rack completo. ¿Qué tanto puedes confiar en que el proveedor de colocación no perderá la energía en plena carga pico? Ojalá hagan simulacros de recuperación ante desastres para prepararse para ese tipo de situaciones
Mucha suerte a este equipo. Se ve divertido
Esto me recordó varios días de mi carrera. Entre 2003 y 2010 tuve que desplegar decenas de miles de servidores y aprendí cosas bastante interesantes sobre centros de datos
La gestión del cableado y la estandarización eran extremadamente importantes. No se podía sobrevivir con prácticas desordenadas
En un lugar donde desplegábamos cientos de servidores cada semana, había un menú del que el operador podía elegir cuando un servidor difería de uno de los clústeres principales. Básicamente había 2 tipos de chasis: servidores de discos grandes en 2U o cajas tipo pizza de 1U. Se podía elegir entre discos SCSI de 9/36/146GB
Todos eran de doble procesador con el mismo procesador, y si no recuerdo mal llenábamos la parte inferior del rack con unas 10 cajas de 2U y el resto con más de 20 cajas de 1U
Si no me falla la memoria, teníamos una tarifa de energía muy buena, probablemente porque usábamos racks del proveedor dentro de la jaula. Creo que al usar esos racks te daban gratis los primeros 2 circuitos de 30A 240V
Era un contrato a 10 años y no había medición, así que llenábamos cada rack lo más posible. En un lado poníamos dos de 30A y en el otro dos de 20A
Pensando en el calor que emitíamos y el consumo eléctrico, el centro de datos debe haber estado casi en punto de equilibrio. Quizá lo compensaban con los costos de conexión o peering
Ya no recuerdo bien los detalles, así que tendría que confirmarlo con un amigo que trabajaba ahí en esa época
Hay cosas que sí conviene tener en la nube y cosas que no. El mejor ejemplo son las aplicaciones de alto ancho de banda o las que usan muchísimo disco
Si ves Netflix, casi todo está en la nube, pero la entrega real del video corre sobre su propio hardware. Incluso a la escala de Netflix, me pregunto si habría sido económicamente viable pagarle a otro por eso
Cambiando un poco una cifra que veo seguido, 20PB de salida a 0.02 dólares por GB son 400 mil dólares al mes
20PB equivalen más o menos a 67Gbps en percentil 95
No es difícil encontrar una línea fija de 100Gbps por 5 mil dólares al mes
Claro, esto simplifica demasiado el cálculo, y en la realidad entran muchos más factores. Aun así, la diferencia es grande
Para algunas empresas, 4.68 millones de dólares al año puede no ser nada, pero para otras puede ser la diferencia entre sobrevivir o no
Ojalá hubiera mucho más detalle. La sección WTF fue la mejor
Parece que el equipo necesita letreros tipo “apunte este lado hacia el enemigo” o buenas affordances para que solo se inserte en una dirección
¿Estandarizaron el layout a nivel de rack? ¿Qué procedimientos de poka-yoke metieron para evitar errores?
¿Cómo se ve el stack desde bare metal hasta el arranque?
Habiendo trabajado en dos proveedores de nube distintos y armado una nube interna con hosts de arranque PXE, este tipo de contenido me parece realmente interesante
Cuando arrancas un datacenter nuevo, conviene aprovechar al máximo para probar todos los escenarios de falla que se te ocurran, además de inyección aleatoria de fallas para cubrir escenarios que no habías pensado
La estandarización del layout a nivel de rack ya la hacemos ahora. No nos cayó el veinte hasta después del segundo sitio. Hace que validar todo sea mucho más fácil
La validación es difícil y hasta ahora la hacemos manualmente. Me gustaría intentar extraer los datos de LLDP, pero hay bugs en el stack de software del switch
Es un proceso que sigue evolucionando. Cuanto más trabajamos con distintos contratistas, más casos excepcionales encontramos e incorporamos
La mejora más grande fue crear un DCIM interno para volver plantillas los diseños de rack y entregar a los técnicos en sitio un “explorador de cableado” interactivo. También incluye diagramas detallados y anotados del equipo, con nombres de puertos y demás. La captura del alzado de rack que aparece en el artículo es parte de esa herramienta
Para ir de bare metal al arranque, tenemos un hack construido sobre https://github.com/danderson/netboot/tree/main/pixiecore que sirve Debian netboot y archivos preseed
También tenemos un worker personalizado de Temporal que se conecta a la API Redfish del BMC para controlar estos equipos. Después, un agente de host personalizado aprovisiona VMs de QEMU y usa FRR en el host para anunciar por BGP las IP asignadas
Sobre los escenarios de falla en datacenters nuevos, ya hemos probado botando breakers y gracias a eso descubrimos que el balanceo de fases estaba mal. En otro sitio entramos con una cámara térmica
La próxima semana entra en línea el sitio AMS, y el objetivo es ver hasta dónde podemos llevar un switch fabric completamente lleno
Buen artículo. Cuando necesitas 100G, Google realmente cobra una barbaridad. Casi resulta insultante
Por ejemplo, un Dedicated Interconnect redundante de 100G cuesta alrededor de 35 mil dólares al mes, y eso ni siquiera incluye VLAN attachment, cross-connects de colocation ni tránsito. Además, el VLAN attachment tiene un máximo de 50G
Si comparas ese costo, con la misma lana podrías comprar 2 switches Arista nuevos de 32 puertos a 100G
En Norteamérica puedes conseguir un enlace WAN de 100G, o sea un Wavelength administrado, por menos de 5 mil dólares al mes. Si es metro local, incluso puedes conseguir dark fiber más barata y correrla a la velocidad que quieras