Wie Railway sein eigenes Rechenzentrum aufbaute
(blog.railway.com)- Railway kam zu dem Schluss, dass Compute auf Basis von GCP Preisgestaltung, Support und Feature-Entwicklung einschränkt, und startete mit Railway Metal eine physische Infrastruktur, die direkter kontrollierbar ist
- Nach dem Start im Januar 2024 dauerte es 5 Monate bis zum Anschluss des ersten Servers und weitere 3 Monate bis zur Aufnahme von Nutzer-Workloads; 9 Monate später ging der erste Standort in Kalifornien in Betrieb
- Die größere Einschränkung als gemietete Fläche waren Strom und Kühlung; Railway entschied sich statt Greenfield oder Rack-Miete für Cage Colocation
- Das Netzwerk ist mit mindestens 2 ISPs pro Region, der vollständigen Internet-Routing-Tabelle, Pfadwahl pro IP-Präfix und mehreren Zonen darauf ausgelegt, den Ausfall eines einzelnen Rechenzentrums zu verkraften
- Rack-Layout, Kabeldokumentation, PDUs, Switches mit umgekehrtem Airflow, Redfish API, PXE, FRR und SONiC müssen direkt gehandhabt werden; der Aufbau einer eigenen Cloud ähnelt eher dem Bau eines Hauses als einem Terraform-Deployment
Warum der Wechsel von GCP zu Railway Metal?
- Railways Compute war von Anfang an auf der Google Cloud Platform aufgebaut
- GCP half beim frühen Wachstum, setzte dem Betrieb mit zunehmender Größe aber Grenzen dabei, den Kunden die gewünschte Plattform zu bieten
- Der Betrieb auf Basis eines Hyperscalers beschränkt direkt, welche Preise, welches Serviceniveau und welchen Umfang an Feature-Entwicklung Railway anbieten kann
- Egress Fees wirken sich auf die Preise aus
- Wenn in der darunterliegenden Infrastruktur Probleme auftreten, versteht man die Ursache nur selten
- Railway bewertet das Supportniveau so, dass es sich trotz jährlicher Ausgaben in Millionenhöhe kaum von dem unterscheidet, was man bei 100 Dollar Ausgaben erhält
- Als Reaktion darauf startete Railway 2024 das Projekt Railway Metal
- 9 Monate später wurde der erste Standort in Kalifornien in Betrieb genommen
- Vom Glasfaserkabel im Cage bis zu ISP-Verträgen übernahm Railway Design, Spezifikation und Installation selbst
- Drei weitere Rechenzentrumsregionen werden derzeit zusätzlich eingeschaltet
Erste Flächenwahl: ein Rechenzentrums-Cage
- Das Projekt Railway Metal begann im Januar 2024; bis zum Anschluss des ersten Servers vergingen 5 Monate
- Weitere 3 Monate waren nötig, bis Railway entschied, Nutzer-Workloads auf die Hardware zu legen
- Eigene Infrastruktur braucht Platz für Server, stabile Stromversorgung und ausreichende Kühlung
- Grob gab es drei Optionen
- Greenfield buildout: ein Rechenzentrum kaufen oder mieten
- Cage Colocation: in einem Betreiber-Rechenzentrum einen eigenen, von Gitterwänden umgebenen Bereich sichern
- Rack colocation: einzelne Racks oder Teile davon in einem Colocation-Rechenzentrum mieten
- Railway entschied sich für Cage Colocation, um vier Wände, eine Sicherheitstür und ansonsten leeren Raum zu bekommen, den man selbst gestalten kann
- Die Fläche selbst ist kein großer Kostenfaktor; am teuersten sind Strom und die daraus folgende Kühlung
- Je nach Region unterscheiden sich die Kosten pro kW stark
- Im Westen der USA kann man teils weniger als die Hälfte dessen zahlen, was in Singapur anfällt
- Strom wird unabhängig vom tatsächlichen Verbrauch als monatliches Commit bezahlt, um On-Demand-Verfügbarkeit zu garantieren
Stromdesign und PDUs
- Railway legte zunächst die Zielzahlen für vCPUs, RAM in GB und NVMe in TB fest, um die in GCP genutzte Kapazität abzubilden
- Auf Basis dieser Werte wurden Server und CPUs ausgewählt
- Die zentrale Variable war die Leistungsdichte: die gewünschte Compute-Dichte innerhalb eines bestimmten Stromverbrauchs unterzubringen
- Stromberechnung endet nicht mit dem Addieren von Wattzahlen und ist besonders bei Drehstrom komplexer
- Cloudflares Einführung in Drehstrom und PDUs behandelt diese Themen
- Strom ist im Rechenzentrum die wichtigste Ressource, und Stromausfälle können sehr lange Wiederherstellungszeiten haben
- Jedes Rack benötigt zwei vollständig unabhängige Strom-Feeds
- Im Normalbetrieb teilen sich die beiden Feeds die Last
- Fällt ein Feed aus, muss das System das aushalten können
- Um Server mit Strom zu versorgen, braucht man eine Power Distribution Unit
- Eine einfache PDU ist im Grunde eine erweiterte Steckdosenleiste
- Die von Railway eingesetzten PDUs ermöglichen Steuerung und Messung einzelner Steckdosen
- Jede PDU ist über das Netzwerk erreichbar; einzelne Steckdosen lassen sich aus der Ferne messen und steuern
Netzwerk: ISPs, Routing, regionale Pfade
- Cloud-Maschinen existieren nicht isoliert, daher spielt das Netzwerk eine Schlüsselrolle
- Railway suchte Rechenzentrumsstandorte mit robuster Anbindung an die Außenwelt, um niedrige Latenzen zu erreichen
- Die bevorzugten Bedingungen waren:
- mit Tier-1-ISPs on-network sein
- Teil eines Internet Exchange sein
- Glasfaserverbindungen zu nahegelegenen anderen Rechenzentren haben
- Auf Railway deployte Anwendungen kommunizieren mit unterschiedlichsten Endpunkten
- private Internetnutzer in Sydney
- auf AWS-Servern in den USA gehostete APIs
- Für niedrige Latenzen und geringe Bandbreitenkosten schließt Railway Verträge mit mehreren Internetanbietern, die je nach Use Case optimiert sind
- ISPs werden anhand ihrer Netzwerkreife in der Zielregion ausgewählt
- Die Zusammenarbeit mit einem falschen ISP kann zusätzliche Netzwerk-Hops bis zu einem Zielmarkt verursachen und damit die Latenz erhöhen
- Im schlimmsten Fall entstehen kompliziert verschlungene Netzwerkpfade
- In jeder Region werden anhand des lokalen Footprints mindestens zwei getrennte Netzwerke ausgewählt
- Nach der Anbindung erhält Railway von jedem ISP die vollständige Internet-Routing-Tabelle und konsolidiert sie auf den Netzwerk-Switches, um den optimalen Pfad pro IP-Präfix zu bestimmen
- Greift ein australischer Nutzer auf eine in Singapur deployte App zu, werden Pakete wahrscheinlich an Telstra übergeben
- Sendet dieselbe App Pakete an Nutzer oder Server in Japan, werden sie wahrscheinlich an PCCW übergeben
- Peering-Informationen sind öffentlich; auf bgp.tools lassen sich Netzwerkverbindungen einsehen
- Für Redundanz baut Railway innerhalb jeder Region mehrere Zonen auf; auch Interconnects zwischen Standorten sind für die Skalierung wichtig
- Werkzeuge wie Dark Fiber oder Wavelength Services werden geprüft
- Ziel ist, dass Apps keinen Unterschied bemerken, ob die Datenbank im selben Raum steht oder vier Blocks entfernt im Nachbargebäude
- Das Design soll die Resilienz gegenüber Ausfällen einzelner Rechenzentren erhöhen
Racks, Gänge, Kühlung und Kabelführung
- In Rechenzentren werden Racks in Reihen angeordnet, und die Gänge zwischen den Racks dienen dem Luftstrom
- In die Cold Aisle strömt kalte Luft aus der Anlage; Server saugen sie an und geben sie hinten in die Hot Aisle ab
- Für hohe Effizienz darf sich die Luft zwischen Cold Aisle und Hot Aisle nicht vermischen
- Auch wenn 19-Zoll-Geräte verwendet werden, lassen sich Höhe, Breite und Tiefe der Racks passend zu Geräte- und Kabelanforderungen wählen
- Die meisten Servergeräte können zur Wartung auf Schienen nach vorn herausgezogen werden; die Cage-Abmessungen müssen das zulassen
- Kabel und Kabelmanagement benötigen ebenfalls Platz, wodurch ein Kompromiss entsteht zwischen der Dichte, mit der Racks gefüllt werden, und der Anzahl der Racks im Cage
- Nach Railways Erfahrung sind Strom und Kühlung häufiger limitierend als der physische Platz
- An neuen Standorten wählt Railway breitere Racks mit 800 mm, um Kabel aus dem Abluftpfad zu halten und den Airflow zu verbessern
- Neben den Racks braucht es auch Overhead-Infrastruktur und Trassen für Strom und Daten
- Glasfasern werden vom Rand des Cage zu jedem Rack geführt
- Auch Kabel zwischen Racks werden geführt
- Solche Posten nimmt der Rechenzentrumsbetreiber manchmal in das Angebot für den Cage auf
- Da Railway pro Rack eine hohe Dichte an Switch-to-Server-Glasfaserkabeln hat, kauft das Unternehmen Reverse-Airflow-Switches, deren Ports zur Rückseite des Racks zeigen
- Es sind Switches, die zur Seite mit den Netzwerkports hin ausblasen
- Die Kabeltrassen werden so angepasst, dass die gesamte Verkabelung auf einer Seite des Racks erfolgt
- So wird vermieden, dass Kabel zwischen Vorder- und Rückseite des Racks im Zickzack verlaufen
Installationsdokumente und Rack-and-Stack
- Railway versuchte zunächst, die Verkabelung selbst durchzuführen, doch die Ergebnisse waren uneinheitlich; für eine korrekte Installation wurden Fachleute hinzugezogen
- Damit Installationsspezialisten wissen, was wo installiert werden muss, braucht es ein umfassendes Dokumentenpaket
- Übliche Dokumente sind zwei Arten
- Cabling matrix: definiert Gerätepositionen, Ports, Kabelspezifikationen, Glasfasertypen, Längen usw. an beiden Enden jedes Kabels
- Rack elevation: zeigt visuell Position und Ausrichtung jedes Geräts im Rack
- Jede Installationsphase bei Railway umfasst mehr als 60 Geräte, über 300 einzelne Kabel und Dutzende Detailpunkte
- Schriftliche Spezifikationen und Tabellen, die die Grundlage für Installation und Inbetriebnahme bilden, wurden manuell erstellt
- Nachdem das Material vor Ort eingetroffen ist, dauert die vollständige Installation etwa 6 bis 14 Tage
- Danach entwickelte Railway ein internes Tool, das die Erstellung von Build Specifications automatisiert
- Der Aufbau eines Rechenzentrums-Cage ist weit entfernt von typischer Software-, DevOps- oder Terraform-Stack-Bereitstellung und ähnelt eher dem Bau eines Hauses
- Rechenzentrumsanlagen, Auftragnehmer und Vendoren arbeiten selbst innerhalb derselben Organisation leicht unterschiedlich, was im Betrieb große Aufmerksamkeit für Details erfordert
Ausnahmen und physische Probleme vor Ort
- An einem Standort waren PDUs kopfüber installiert; da der Strom vom Boden kam, waren die geplanten Steckdosennummern umgekehrt
- Am Standort Amsterdam gab es eine Anlagenpraxis, bei der externe Glasfaserlinks nicht an einem dedizierten Demarcation Point endeten, sondern direkt in eine Box im Rack geführt wurden
- Eine Anlage hatte, anders als andere Standorte, Stromsteckdosen phase-to-neutral verdrahtet; andere waren phase-to-phase verdrahtet
- Ein Auftragnehmer wusste nicht, dass die Netzwerkgeräte Reverse-Airflow hatten, und wollte sie in der falschen Richtung montieren, woraufhin er die Datenkabel für zu kurz hielt
- Der Grund dafür, dass bei einem bestimmten Kabel der Link nicht hochkam, war ein Fehler in der Glasfaser-Polarität; dabei lernte Railway das „rolling fibre cables“ kennen
- Dabei werden die Stecker eines LC connector herausgezogen und gegeneinander getauscht
- Rund 24 PDUs eines Vendors hatten defekte Steckdosen, sodass Stromstecker nicht richtig einrasteten; auch starke physische Kraft löste das Problem nicht
Softwarearbeit nach der physischen Installation
- Nachdem die Hardware an ihrem Platz ist, verlagert sich die Arbeit in den vertrauteren Softwarebereich
- Nötige Aufgaben sind unter anderem:
- BGP konfigurieren
- OS installieren
- Monitoring konfigurieren
- Netzwerkgeräte konfigurieren
- Router-Konfigurationen schreiben
- Einträge bei RIRs, also regionalen Internet-Registries, aktualisieren
- Für den Zugriff auf dedizierte Controller von Servern und PDUs werden Redfish APIs genutzt
- Um Server über das Netzwerk zu booten, verwendet Railway PXE
- Railways Netzwerkdesign nutzt Whitebox Network Switches, auf denen FRR und SONiC laufen
- Mit diesem Design baut Railway ein rein L3-basiertes, softwaregesteuertes Netzwerk auf, das tief in die Railway Control Plane integriert ist
- In den letzten Monaten entwickelte Railway die neuen Softwaretools Railyard und MetalCP
- neue Cages entwerfen
- Kabel nachverfolgen und visualisieren
- Server-OS installieren
- den Prozess, Server mit dem Internet zu verbinden, als Button-Klick-Erlebnis ermöglichen
- Ein späterer Beitrag wird behandeln, wie aus einem Bündel Server in einem Raum eine funktionsfähige Railway-Zone wird
1 Kommentare
Hacker-News-Kommentare
Nach meiner Erfahrung und solchen Beiträgen wirkt es so, als würde Google es hassen, Kunden zu haben.
Jemand hat offenbar entschieden: „Wir müssen Public Cloud machen“, und sie haben sie gebaut – aber es fühlt sich an, als wollten sie Kunden mit einer drei Meter langen Stange auf Abstand halten.
Bei einem AWS-Account-Manager bin ich zu 100 % sicher, dass er sich bei Bedarf mit dir auch im Schlamm wälzen würde. Wenn du ihn in einer Krise darum bittest, würde er mit dir auf dem Boden schlafen.
Die Leute von Google Cloud dagegen machen mich traurig. Man sieht ihnen an, dass sie intern bei Google noch weniger geliebt und unterstützt werden als wir. Es ist bitter, jemanden zu beobachten, der versucht, das eigene Unternehmen davon zu überzeugen, ordentlich zu verkaufen und Service zu leisten; es wirkt, als wären sie auf Scheitern eingestellt.
Die Microsoft-Leute sind kugelsicher: stark im Vertrieb, gut in der Service-Erbringung, und sie quetschen dir jeden Cent aus der Tasche, während sie dich bis aufs Blut davon überzeugen, dass das gut für dich ist. Nur ist ihre Cloud ein sehr merkwürdiges … Etwas.
Dass Railway auf Bare Metal geht: Nach rund 15 Jahren Erfahrung würde ich dorthin niemals, niemals, niemals zurückwollen. Es ist es nicht wert. Aber das muss man wohl selbst durchmachen; so läuft es eben.
Bald werden sie verstehen, warum Google sich damit so verdammt schwertut. Allerdings: Wenn man wirklich sehr stark den Wunsch hat, Menschen Services zu verkaufen, statt Borg oder ein künstliches Gehirn zu bauen, kann man es 100-mal besser machen als Google.
Trotzdem glaube ich nicht, dass er sich mit mir im Schlamm wälzen würde; das ist schon erstaunlich. Ich frage mich, wie viel man ausgeben muss, um die „Schlamm-Begleitung“-Stufe zu erreichen.
Der gesamte Cloud-Service fühlt sich an, als wäre er von jemandem entworfen worden, der von Cloud Computing überhaupt keine Ahnung hat und nur „Bare-Metal-Server mieten“ kennt. Es ist zwar Cloud Computing, aber auf eine Weise, die das Konzept von Cloud Computing selbst untergräbt.
Auch das GCP-Kommandozeilentool
gcloudwirkt besser durchdacht.Dann hätten wir uns Monate an Vorarbeit sparen können.
Aus persönlicher Erfahrung hat uns der Google-Cloud-Support selbst als kleines Drei-Personen-Team mit sehr geringen Ausgaben ziemlich gut behandelt; bei einem anderen Unternehmen hat uns auch Microsoft sehr gut behandelt. Allerdings war das Ausgabenvolumen damals vermutlich so hoch, dass man es sogar über die Überwachung des Stromnetzes im Rechenzentrum hätte verfolgen können.
AWS dagegen hat über ein Feature gelogen und am Ende nicht einmal eine Antwort geliefert.
Account-Manager, die mit Führungskräften über zwingend notwendige AWS-Verträge in Millionenhöhe sprechen, scheinen genau zu wissen, wie sie mit diesen Führungskräften reden müssen.
Aber in der Phase, in der man tatsächlich ein Produkt für andere entwickelt und bereitstellt, wurden nur wir im Staub zurückgelassen.
Noch absurder ist, dass dieses erlogene Feature als entscheidend dafür verkauft wurde, die Endnutzererfahrung herausragend zu machen.
Ich habe auf das Support-Ticket geantwortet, aber keine Reaktion erhalten; ich habe zwei AWS-Ansprechpartnern E-Mails geschickt, aber ebenfalls keine Antwort bekommen.
Erinnert mich an die alten Rackspace-Zeiten. Da gab es wirklich viele Dinge, die sich wie Krieg anfühlten.
Leute von EMC kamen, um Storage-Equipment zum Testen zu installieren, stolperten sich gegenseitig in die Quere und ließen wie in einer Komödie ein ganzes Server-Rack herunterkrachen. Den Auftrag haben sie natürlich nicht bekommen.
Ein Lkw-Fahrer erlitt einen Herzinfarkt, und durch den Unfall ging das DFW-Datacenter offline. Um solche Situationen zu verhindern, gab es Poller, aber sie waren noch nicht mit Zement gefüllt.
Einmal haben wir eine provisorische Verbindung aufgebaut, indem wir Bandbreite per Laser bis zu einem anderen Gebäude auf der anderen Straßenseite schickten.
An einem anderen Tag fing ein Server buchstäblich an zu brennen, also schlugen wir ein Fenster ein und kauften Box-Fans.
Datacenter-Engineering hat sich seit den Anfangstagen ziemlich weiterentwickelt. Damals haben wir zusammen mit Facebook am OpenCompute Project gearbeitet, und für die damalige Zeit gab es dort sehr fortschrittliche Infrastrukturkonzepte.
Ein zentraler Microwave-Link brach immer wieder mit sporadischen Paketfehlern tief unten im Data-Link-Layer ab. Bei der Untersuchung stellte sich heraus, dass ein Baum auf der anderen Straßenseite Blätter bekommen hatte und Äste in die Sichtlinie der Geräte an unserem Gebäude hineinwehten. Leiter, Säge, 10 Minuten – und die Verbindung war wiederhergestellt.
Der primäre BGP-Router nach draußen aus dem Datacenter rebootete ständig. Redundante Hardware gab es nicht. Wie sich zeigte, war die Temperatur im Datacenter viel zu hoch und die Kühlung so schlecht, dass die Lufttemperatur an den Intake-Fans über 60 °C lag. Provisorisch stellten wir einen Ventilator darauf ausgerichtet auf.
Ein paar Wochen später gab auch die Klimaanlage in einem anderen Raum auf und begann, Wasser über eine Nortel DMS-100 zu spucken. Das war ein Dial-up-ISP mit eigener Switch. Ich wollte nicht unbedingt beim Aufwischen helfen, weil ich dachte, dass im Wasser Strom fließen könnte, aber ich hatte keine Wahl.
Danach arbeitete ich auch auf einer kleinen, abgelegenen Insel. Der primäre Internet-Link war ein 1 MB/s-Link über einen GS-Satelliten, mit Pings über 500 ms. Die Einheimischen wählten sich über ein Microwave-Telefonnetz ein, das mit 9600 Baud eingestuft war, aber irgendwie funktionierten 56k-Modems.
Eines Tages stellte ich fest, dass auf einer Solaris-Box eine wichtige
.sofehlte, aber es gab weder ein lokales Backup noch Installationsmedien. Ich rief einen Freund in Großbritannien an und bat ihn, eine Kopie auf einen FTP-Server zu legen, und bekam die Box so wieder online.Ein paar Jahre später installierten wir zudem einen Laser-Link über der Oxford Road in Manchester, damals der meistbefahrenen Busstrecke Europas, um ein Büro mit dem Universitätscampus zu verbinden. Das waren lustige Zeiten.
Das alles hat enorm Spaß gemacht, aber ich bin wirklich froh, dass ich heute fast nur noch Software mache.
Auch wenn kein Server buchstäblich gebrannt hat: Fenster öffnen und Ventilatoren einsetzen passierte im Januar 2024 auch im Equinix CH1 Datacenter in Chicago. Azure ExpressRoute fiel aus.
Ich habe gehört, es sei wohl so kalt geworden, dass die CRAC es nicht mehr geschafft hat. Angeblich hatten sie alle Türen und Fenster offen gelassen, um es ausreichend kühl zu halten, aber am Ende scheiterte das. Wenn die CRAC geht, gehen die Server mit.
Dieser Switch war definitiv verflucht. Später in derselben Woche gab es auf demselben Gerät einen Fehler in der Spanning-Tree-Konfiguration, LINX stand mehrere Stunden still, und die Hälfte des britischen ISP-Peerings geriet vorübergehend ins Chaos. Auch alle anderen, die an diesem Projekt beteiligt waren, starben innerhalb von zwei Jahren.
Ein paar Jahre später sah ich mir die Anlage an, und auf dem Boden darunter lag immer noch der gebratene Kadaver.
Die Stelle im Artikel, dass man „selbst bei mehreren Millionen Dollar Ausgaben pro Jahr nur so viel Support bekommt wie jemand, der 100 Dollar ausgibt“, tut weh. Für Google ist das ein ziemlich großes Problem.
Besonders interessant fand ich den Artikel, weil wir beim Aufbau der Blekko-Infrastruktur ähnliche Abenteuer erlebt haben.
Für Firmen wie Blekko, bei denen der Traffic zwischen Racks – also East-West-Traffic – größer ist als der Traffic ins und aus dem Internet, war es essenziell, dass physisch gemeinsam platzierte Services nicht mit anderen Servern um Bandbreite konkurrieren. Das war deutlich wirtschaftlicher, als für solche Sonderfälle bei SoftLayer, also IBMs abhängiger Cloud, zu bezahlen.
Es gibt auch ziemlich coole Firmen, die Einhausungen für Cold Aisles bauen. Im Grunde sorgen sie dafür, dass die gesamte kalte Luft aus dem Boden zur Rückseite der Server gelangt und nicht woanders entweicht. Außerdem verhindern sie, dass weniger kalte Luft von den Seiten in die Server hineingezogen wird.
Auch die Berechnung der HVAC- und CRAC-Kapazitäten eines Datacenters ist interessant. In unserer ersten Colocation-Anlage hatten wir ein Vorkaufsrecht auf Erweiterungsfläche direkt neben unserem Cage, aber als es tatsächlich Zeit für die Erweiterung war, hatte die Anlage keine Kühlkapazität mehr übrig, sodass das völlig bedeutungslos war.
Wenn man so etwas einmal durchgemacht hat, versteht man die 0xide-Lösung sehr viel besser.
So baut man ein dominantes Unternehmen auf. Gut, dass sie die jammernde Binsenweisheit ignoriert haben, die einen in Hyperscaler einsperrt.
Wenn man ein Infrastrukturunternehmen ist, sollte man das Bare Metal, das man verkauft, selbst besitzen. Andernfalls ist man nur ein Cloud-Mittelsmann und läuft jederzeit Gefahr, von Bare-Metal-Konkurrenten mit 0 Dollar Egress-Kosten über den Preis verdrängt zu werden.
Weil man Egress-Kosten durch Colocation und Peering auf 0 Dollar bringen kann, kann Cloudflare einen kostenlosen Tarif anbieten, und ein neuer Anbieter, der Cloud-Services weiterverkauft, kann nicht mit Cloudflare konkurrieren.
Tatsächlich sind überhöhte Bandbreitenpreise für Hyperscaler nicht bloß eine Einnahmequelle, sondern ein Moat. Sie verhindern, dass man auf AWS das nächste AWS baut, und schaffen über IaaS ein völlig neues und strategisch schwächeres Marktsegment namens „PaaS“.
Damit können wir diese Kosten halbieren, auch die Storage-Kosten senken und außerdem die Preisgestaltung „pro Seat“ abschaffen.
Ich freue mich wirklich darauf.
Ein ziemlich guter Artikel. Eine Sache, die mir einfällt: Warum haben sie ein internes Tool für das Rack-Management selbst gebaut? NetBox gibt es bereits.
NetBox ist großartig; als ich Mitte der 2000er mehr als 50 Racks verwaltete, hätte ich mir gewünscht, es damals schon zu haben.
https://github.com/netbox-community/netbox
Der Grund, warum unser eigenes Tool Railyard so gut passt, ist aber, dass es tief in unseren gesamten Software-, Hardware- und Orchestrierungs-Stack integriert ist.
Das Problem bei Open-Source-Tools ist, dass sie zu generisch sind. Statt das Problem zu lösen, verbiegt man das Problem so, dass es zum Datenmodell des Tools passt.
Am Ende ist es sehr wahrscheinlich, dass wir dieses Tool in Railway selbst integrieren. Wenn man on-premises gehen möchte, gäbe es dann per Klick Hardware-Design, Commissioning, Deployment und Developer Experience. Ähnlich wie Oxide, nur von der anderen Seite her angegangen.
https://github.com/netbox-community/netbox/issues?q=is%3Aiss...
NetBox will die „Source of Truth“ für Netzwerkinfrastruktur sein.
Je nach Situation ist Unterschiedliches wichtig; wenn NetBox nicht darauf bestehen würde, dass bestimmte Einträge nicht in einem anderen System die Wahrheit haben können, sondern eher ein zentrales Repository anstreben würde, sähe die Sache vielleicht anders aus.
Ich habe gelernt, dass Versuche, Komplexität und Kontrolle zu zentralisieren, nicht funktionieren. Das war schon kurz nach der Verabschiedung des Clinger-Cohen Act ziemlich klar, und inzwischen behandeln auch ITIL und TOGAF das ausdrücklich. Ich vermute, dass Berater in den nächsten Jahren genau diesen Punkt stark bearbeiten werden.
Man braucht eine zentrale, konsistente Methode, um Status zu finden — damit es keine Frage gibt, wo autoritative Informationen zu finden sind.
Aber wenn man skalieren, wachsen oder sich an neue Veränderungen anpassen will, sollte man solche präskriptiven Systeme vom Typ zentralisierte Gottesbox vermeiden.
Es ist keine Software, deren Nutzung besonders erfüllend ist.
Das ist ein typischer Fall von „Wir brauchen X, und Y macht X“, wobei ignoriert wird, dass Y auch Z, M, Q und noch den Abwasch macht — und dass man all das gar nicht braucht.
Manchmal ist es die einfachste Lösung, nur das zu bauen, was man braucht. Besonders dann, wenn das, was man braucht, CRUD vor einer Datenbank ist.
Im Grunde erweitert man nur den Scope. NetBox ist ein guter Ausgangspunkt, wenn man dort beginnt und bereit ist, das System darum herum auszurichten.
Wenn man aber bereits ein System hat oder Dinge tun muss, die nicht zur NetBox-Logik passen, ist es wahrscheinlich besser, einfach das bestehende System zu erweitern.
In diesem Fall muss Railway sich um deutlich mehr zusätzliche Informationen kümmern als nur Racks, IP-Adressen und physische Server.
Ich habe bei einem großen Tech-Unternehmen Automatisierung für Gerätereparaturen gemacht. Reparaturen werden unterschätzt, gehören aber meiner Meinung nach zu den schwierigeren Themen.
Wenn man auf AWS läuft, kümmert man sich kaum um defekte Hardware. Meist wird sie einfach automatisch repariert.
Wenn man selbst betreibt, hat man diesen Luxus nicht. Man braucht Ersatzteile, Techniker für Reparaturen, Prozesse, um Hosts aus dem Betrieb zu nehmen und wieder einzubinden, Test-Suites, Hardware-Monitoring-Tools und 1001 weitere Dinge.
In kleinem Maßstab kann man manches improvisieren, aber irgendwann rächt sich das. Und das betrifft nur die Server.
Netzwerkequipment bringt noch einmal ein eigenes Bündel spannender Probleme mit sich und kann bei Ausfällen ein ganzes Rack herunterreißen. Wie sehr kann man sich darauf verlassen, dass der Colocation-Anbieter während Spitzenlast nicht den Strom verliert? Ich hoffe, sie machen für solche Situationen Disaster-Recovery-Übungen.
Viel Glück dem Team. Sieht nach Spaß aus.
Das erinnert mich an einige Tage in meiner Karriere. Zwischen 2003 und 2010 musste ich Zehntausende Server ausrollen und habe dabei einiges ziemlich Interessantes über Rechenzentren gelernt.
Kabelmanagement und Standardisierung waren extrem wichtig. Mit chaotischen Praktiken konnte man nicht durchkommen.
Dort, wo wir jede Woche Hunderte Server bereitstellten, gab es für Betreiber ein Menü zur Auswahl, wenn ein Server von einem der Hauptcluster abwich. Im Grunde gab es zwei Chassis: einen 2U-Server mit hoher Plattenkapazität oder eine 1U-Pizzaschachtel. Bei den Platten konnte man zwischen 9/36/146 GB SCSI wählen.
Alle waren Dual-Prozessor-Systeme mit demselben Prozessor; unten im Rack standen etwa zehn 2U-Boxen, der Rest wurde mit mehr als zwanzig 1U-Boxen gefüllt.
Wenn ich mich richtig erinnere, hatten wir sehr gute Stromkonditionen, vermutlich weil wir innerhalb des Cages die Racks der Facility nutzten. Ich glaube, bei Nutzung dieser Racks waren die ersten zwei 30A-240V-Stromkreise kostenlos.
Es war ein Zehnjahresvertrag ohne Zähler, also packten wir jedes Rack so voll wie möglich. Auf einer Seite hatten wir zweimal 30A, auf der anderen zweimal 20A.
Wenn man an die Wärme und den Stromverbrauch denkt, die wir verursachten, war das Rechenzentrum vermutlich kaum über dem Break-even. Vielleicht haben sie es über Connectivity- oder Peering-Kosten wieder hereingeholt.
An die Details erinnere ich mich nicht mehr gut; ich müsste einen Freund fragen, der damals dort gearbeitet hat.
Für manche Dinge ist die Cloud richtig, für andere nicht. Das beste Beispiel sind Anwendungen mit hoher Bandbreite oder intensiver Disk-Nutzung.
Bei Netflix liegt fast alles in der Cloud, aber die eigentliche Videoauslieferung erfolgt über eigene Hardware. Selbst in der Größenordnung von Netflix frage ich mich, ob es wirtschaftlich möglich gewesen wäre, dafür jemand anderen zu bezahlen.
Wenn man eine häufig gesehene Zahl leicht abwandelt: 20 PB ausgehender Traffic zu 0,02 US-Dollar pro GB ergeben 400.000 US-Dollar pro Monat.
20 PB entsprechen grob 67 Gbit/s beim 95. Perzentil.
Eine 100-Gbit/s-Flatrate-Leitung findet man nicht schwer auch für 5.000 US-Dollar pro Monat.
Natürlich ist das eine stark vereinfachte Rechnung, und in der Realität spielen viel mehr Faktoren hinein. Trotzdem ist der Unterschied groß.
Für manche Unternehmen sind 4,68 Millionen US-Dollar pro Jahr vielleicht keine große Sache, für andere kann dieser Betrag über das Überleben entscheiden.
Ich würde mir noch deutlich mehr Details wünschen. Der WTF-Abschnitt war der beste
Bei der Hardware bräuchte es wohl Schilder wie „Diese Seite dem Feind zuwenden“ oder passende Affordances, damit etwas nur in einer Richtung hineinpasst
Habt ihr das Layout auf Rack-Ebene standardisiert? Welche Poka-Yoke-Prozesse habt ihr eingebaut, um Fehler zu vermeiden?
Wie sieht der Stack vom Bare Metal bis zum Booten aus?
Aus der Perspektive von jemandem, der bei zwei verschiedenen Cloud-Anbietern gearbeitet und mit PXE-Boot-Hosts eine interne Cloud selbst gebaut hat, ist so etwas wirklich spannend
Beim Start eines neuen Rechenzentrums sollte man das maximal ausnutzen und jedes denkbare Fehlerszenario testen — plus Szenarien, auf die man nicht gekommen ist, durch zufällige Fehlerinjektion
Die Standardisierung des Layouts auf Rack-Ebene machen wir inzwischen. Das haben wir erst nach dem zweiten Standort erkannt. Dadurch ist die Verifizierung viel einfacher geworden
Verifizierung ist schwierig und läuft bisher manuell. Ich würde gern LLDP-Daten abgreifen, aber der Switch-Software-Stack hat Bugs
Es ist ein laufender Evolutionsprozess. Je mehr wir mit unterschiedlichen Auftragnehmern arbeiten, desto mehr Sonderfälle entdecken wir und bauen sie ein
Die größte Verbesserung war der Aufbau eines internen DCIM, mit dem wir Rack-Designs als Templates abbilden und den Technikern vor Ort einen interaktiven „Verkabelungs-Explorer“ ausgeben. Enthalten sind auch detailliert annotierte Diagramme der Geräte mit Portnamen usw. Der Screenshot der Rack-Ansicht im Artikel ist Teil dieses Tools
Für den Weg vom Bare Metal bis zum Booten haben wir etwas auf Basis von https://github.com/danderson/netboot/tree/main/pixiecore zusammengehackt. Es stellt Debian netboot und preseed-Dateien bereit
Außerdem gibt es einen Custom-Temporal-Worker, der sich mit der Redfish API des BMC verbindet und dieses Gerät steuert. Danach provisioniert ein eigener Host-Agent QEMU-VMs, und der Host nutzt FRR, um die zugewiesene IP per BGP anzukündigen
Zu Fehlerszenarien in neuen Rechenzentren: Wir haben bereits getestet, indem wir Leistungsschalter ausgelöst haben, und dadurch festgestellt, dass die Phasenbalancierung nicht stimmte. An einem anderen Standort sind wir mit einer Wärmebildkamera hineingegangen
Nächste Woche geht der AMS-Standort live; das Ziel ist zu sehen, wie weit wir eine voll bestückte Switch-Fabric treiben können
Guter Artikel. Wenn man 100G-Speed braucht, lässt Google einen wirklich heftig zahlen. Fast schon beleidigend
Ein redundanter 100G Dedicated Interconnect kostet zum Beispiel etwa 35.000 Dollar pro Monat, und darin sind VLAN-Attachments, Colocation-Cross-Connects, Transit usw. noch nicht enthalten. Außerdem ist bei VLAN-Attachments bei 50G Schluss
Wenn man diese Kosten vergleicht, kann man für dasselbe Geld zwei neue 32-Port-100G-Switches von Arista kaufen
In Nordamerika bekommt man 100G-WAN-Leitungen, also gemanagte Wavelengths, für unter 5.000 Dollar im Monat. In einer lokalen Metro bekommt man Dark Fiber günstiger und kann sie mit beliebiger Geschwindigkeit betreiben