Wie Uma.Tech die Infrastruktur entwickelte

Wir haben neue Dienste gestartet, der Traffic stieg, wir haben Server ersetzt, neue Plattformen angeschlossen und Rechenzentren umgebaut – und jetzt erzählen wir diese Geschichte, mit der wir Sie vor fünf Jahren vertraut gemacht haben.

Fünf Jahre sind eine charakteristische Zeitspanne, um Zwischenbilanz zu ziehen. Daher haben wir uns entschieden, über die Entwicklung unserer Infrastruktur zu berichten, die in diesen fünf Jahren einen bemerkenswert interessanten Entwicklungspfad durchlaufen hat, auf den wir stolz sind. Die von uns umgesetzten quantitativen Veränderungen haben sich in qualitative gewandelt, jetzt kann die Infrastruktur in Modi arbeiten, die in der Mitte des vergangenen Jahrzehnts wie Science-Fiction erschienen.

Wir gewährleisten den Betrieb komplexester Projekte mit höchsten Anforderungen an Zuverlässigkeit und Lasten, darunter PREMIER und Match TV. Bei Sportübertragungen und der Premiere beliebter Serien ist eine Datenrate in Terabits pro Sekunde erforderlich, die wir problemlos bereitstellen, und das so oft, dass die Arbeit mit solchen Geschwindigkeiten für uns bereits zur Routine geworden ist. Vor fünf Jahren war das schwerste Projekt, das auf unseren Systemen lief, Rutube, das sich seitdem weiterentwickelt hat, an Volumen und Traffic zugelegt hat, was bei der Planung der Lasten berücksichtigt werden musste.

Wir haben darüber berichtet, wie wir die "Hardware" unserer Infrastruktur entwickelt haben ("Rutube 2009-2015: die Geschichte unserer Hardware") und das System, das für die Videoauslieferung verantwortlich ist, weiterentwickelt haben ("Von null bis 700 Gigabit pro Sekunde – wie einer der größten Video-Hosting-Dienste Russlands Videos ausliefert"), aber seit dem Zeitpunkt, an dem diese Texte geschrieben wurden, ist viel Zeit vergangen, und viele andere Lösungen wurden erstellt und implementiert, deren Ergebnisse es uns ermöglichen, den modernen Anforderungen gerecht zu werden und flexibel genug zu sein, um uns auf neue Aufgaben umzustellen.

Das Netzwerk-Kern entwickeln wir ständig weiter. Wir sind 2015 auf Cisco-Ausrüstung umgestiegen, was wir bereits in dem vorherigen Artikel erwähnt haben. Damals waren es immer noch 10/40G, aber aus verständlichen Gründen haben wir die vorhandenen Chassis bereits nach ein paar Jahren modernisiert, und jetzt nutzen wir aktiv auch 25/100G.

100G-Link sind schon lange weder ein Luxus (vielmehr handelt es sich um eine dringende Anforderung der Zeit in unserem Segment) noch eine Seltenheit (immer mehr Betreiber bieten Anschlüsse mit solchen Geschwindigkeiten an). Dennoch hat 10/40G weiterhin Relevanz: Über diese Links schließen wir weiterhin Betreiber mit niedrigem Verkehrsaufkommen an, bei denen es derzeit nicht sinnvoll ist, einen größeren Port zu verwenden.

Das von uns geschaffene Netzwerk-Kernsystem verdient eine gesonderte Betrachtung und wird später Thema eines eigenen Artikels sein. Dort werden wir tiefer in die technischen Details eintauchen und die Logik unserer Handlungen bei seiner Erstellung diskutieren. Aber jetzt setzen wir die Infrastruktur in groben Zügen fort, da Ihre Aufmerksamkeit, geehrte Leser, nicht unbegrenzt ist.

Videostreaming-Server entwickeln sich schnell weiter, wofür wir erhebliche Anstrengungen unternehmen. Während wir früher hauptsächlich 2U-Server mit 4-5 Netzwerkkarten ausgestattet mit je zwei 10G-Ports verwendet haben, wird jetzt der größte Teil des Verkehrs von 1U-Servern bereitgestellt, die 2-3 Karten mit je zwei 25G-Ports enthalten. Die Preise für 10G- und 25G-Karten sind nahezu gleich, und die schnelleren Lösungen ermöglichen es, sowohl mit 10G als auch mit 25G zu arbeiten. Das Ergebnis ist eine offensichtliche Kostensenkung: weniger Serverkomponenten und Kabel für den Anschluss – geringere Kosten (und höhere Zuverlässigkeit), die Komponenten nehmen weniger Platz im Rack ein – es ist nun möglich, eine größere Anzahl von Servern pro Flächeneinheit unterzubringen, wodurch die Mietkosten gesenkt werden.

Aber der größere Vorteil liegt in der Geschwindigkeit! Jetzt können wir mit 1U mehr als 100G bereitstellen! Und das unter den Umständen, dass einige große russische Projekte die Bereitstellung von 40G mit 2U als "Errungenschaft" bezeichnen. Wir hätten gerne ihre Probleme!

Es sei angemerkt, dass wir weiterhin Generationen von Netzwerkkarten verwenden, die nur mit 10G arbeiten können. Diese Geräte funktionieren stabil und sind uns bestens bekannt, weshalb wir sie nicht ausgemustert, sondern einer neuen Verwendung zugeführt haben. Diese Komponenten haben wir in Videolagerserver integriert, denen für eine effektive Arbeitsweise eindeutig nicht nur ein oder zwei 1G-Ports ausreichen; hier sind 10G-Karten relevant geworden.

Speichersysteme Sie wachsen ebenfalls. In dem vergangenen fünfjahres Zeitraum sind sie von zwölf Festplattenschächten (12x HDD 2U) auf sechsunddreißig Festplattenschächte (36x HDD 4U) umgestiegen. Einige befürchten, solche umfangreiche „Gehäuse“ zu nutzen, da der Ausfall eines solchen Chassis die Leistung – und möglicherweise sogar die Funktionsfähigkeit! – des gesamten Systems gefährden könnte. Aber bei uns wird so etwas nicht passieren: Wir haben eine Redundanz auf Ebene der geo-replizierten Datensicherungen sichergestellt. Wir haben die Chassis auf verschiedene Rechenzentren verteilt – insgesamt nutzen wir drei – und das schließt die Entstehung von Problemen sowohl bei Ausfällen von Chassis als auch bei einem Abbruch der Plattform aus.

Natürlich hat dieser Ansatz die Hardware-RAID überflüssig gemacht, von dem wir Abstand genommen haben. Indem wir auf Redundanz verzichtet haben, haben wir gleichzeitig die Zuverlässigkeit des Systems erhöht, indem wir die Lösung vereinfacht und einen potenziellen Ausfallpunkt eliminiert haben. Lassen Sie uns daran erinnern, dass unser Speicher-Array „selbstgebaut“ ist. Dies haben wir ganz bewusst getan und das Ergebnis hat uns voll und ganz überzeugt.

Rechenzentren haben wir in den vergangenen fünf Jahren mehrere Male gewechselt. Seit dem Schreiben des vorherigen Artikels haben wir nur ein Rechenzentrum nicht gewechselt – DataLine –, alle anderen mussten im Zuge der Weiterentwicklung unserer Infrastruktur ersetzt werden. Alle Umzüge zwischen den Standorten waren planmäßig.

Vor zwei Jahren haben wir innerhalb von MMTS-9 migriert und sind zu einem Standort mit hochwertiger Renovierung, gutem Kühlsystem, stabiler Stromversorgung und ohne Staub, der früher in dicken Schichten auf allen Oberflächen lag und die Innereien unserer Geräte massiv verstopfte, gewechselt. Die Entscheidung für hochwertige Dienstleistungen – und die Abwesenheit von Staub! – war der Grund für unseren Umzug.

Fast immer heißt es: „Ein Umzug ist gleich zwei Brände“, aber die Probleme bei der Migration sind jedes Mal anders. Diesmal war die Hauptschwierigkeit des Umzugs innerhalb eines Rechenzentrums durch die optischen Cross-Connects „verursacht“ – deren Vielzahl zwischen den Etagen ohne Zusammenfassung in eine einheitliche Cross-Connect-Seite seitens der Telekommunikationsanbieter. Der Prozess der Aktualisierung und Neuverkabelung der Cross-Connects (in dem uns die Ingenieure von MMTS-9 geholfen haben) war wohl der schwierigste Schritt der Migration.

Die zweite Migration fand vor einem Jahr statt, als wir 2019 von einem nicht besonders guten Rechenzentrum zu O2xygen umgezogen sind. Die Gründe für den Umzug waren ähnlich wie die oben genannten, jedoch kam das Problem der Unattraktivität des ursprünglichen Rechenzentrums für die Betreiber hinzu – viele Anbieter mussten wir „einholen“, um zu diesem Punkt zu gelangen.

Die Migration von 13 Racks zu einem qualitativ hochwertigen Standort in MMTS-9 ermöglichte es, diesen Standort nicht nur als Betreiberstandort (ein paar Racks und „Durchleitungen“ von Anbietern) zu entwickeln, sondern auch einen der Hauptstandorte einzusetzen. Das erleichterte die Migration aus dem nicht besonders guten Rechenzentrum – das meiste Equipment haben wir zu einem anderen Standort transportiert, während O2xygen die Rolle eines sich entwickelnden Standorts übernahm, indem wir dorthin 5 Racks mit Equipment geschickt haben.

Heute ist O2xygen bereits eine vollwertige Anlage, zu der die benötigten Anbieter „gekommen“ sind und weiterhin neue sich anschließen. Für die Anbieter war O2xygen auch aus strategischer Entwicklungsperspektive attraktiv.

Die Hauptphase des Umzugs führen wir unbedingt über Nacht durch, und sowohl bei der Migration innerhalb von MMTS-9 als auch zu O2xygen haben wir uns an diese Regel gehalten. Wir möchten betonen, dass wir die Regel „Umzug über Nacht“ strikt einhalten, unabhängig von der Anzahl der Racks! Es gab sogar einen Präzedenzfall, als wir 20 Racks bewegt haben und dies ebenfalls über Nacht erledigten. Die Migration ist ein vergleichsweise unkomplizierter Prozess, der Sorgfalt und Nachfolge erfordert, aber auch hier gibt es einige Tricks, sowohl im Vorbereitungsprozess als auch beim Umzug und beim Einsatz am neuen Standort. Wir sind bereit, detaillierte Informationen zur Migration bereitzustellen, falls Sie Interesse haben.

Ergebnisse Die Ergebnisse der fünfjährigen Entwicklung gefallen uns. Wir haben den Aufbau einer neuen ausfallsicheren Infrastruktur abgeschlossen, die auf drei Rechenzentren verteilt ist. Die Dichte der Verkehrsausgabe hat sich erheblich erhöht – während wir vor kurzem über 40-80G mit 2U erfreut waren, ist es jetzt normal, 100G mit 1U auszugeben. Jetzt wird bereits Terabit Verkehr für uns zur Gewohnheit. Wir sind bereit, unsere Infrastruktur weiterzuentwickeln, die sich als flexibel skalierbar erwiesen hat.

Frage: Was sollen wir Ihnen in den nächsten Texten erzählen, geschätzte Leser? Warum wir begonnen haben, selbstgemachte Datenspeichersysteme zu entwickeln? Über das Netzwerk-Kern und seine Besonderheiten? Über Tricks und Feinheiten der Migration zwischen Rechenzentren? Über die Optimierung von Ausgabe-Lösungen durch Auswahl der Komponenten und Feinabstimmung von Parametern? Über die Schaffung robuster Lösungen durch mehrfache Redundanz und horizontale Skalierungsmöglichkeiten innerhalb des Rechenzentrums, die in der Struktur von drei Rechenzentren implementiert sind?

Autor: Peter Winogradov — Technischer Direktor von Uma.Tech Hamster

Quelle: habr.com