Wie Uma.Tech die Infrastruktur entwickelte

Wir haben neue Dienste eingeführt, den Datenverkehr erhöht, Server ersetzt, neue Standorte verbunden und Rechenzentren neu gestaltet - und jetzt werden wir diese Geschichte erzählen, deren Beginn wir Ihnen vor fünf Jahren vorgestellt haben .



Fünf Jahre sind eine charakteristische Zeit, um die Zwischenergebnisse zusammenzufassen. Aus diesem Grund haben wir uns entschlossen, über die Entwicklung unserer Infrastruktur zu sprechen, die in den fünf Jahren, auf die wir stolz sind, einen erstaunlich interessanten Entwicklungspfad durchlaufen hat. Die quantitativen Änderungen, die wir vorgenommen haben, haben sich in qualitative geändert. Jetzt kann die Infrastruktur in Modi betrieben werden, die Mitte des letzten Jahrzehnts fantastisch erschienen.



Wir bieten Arbeit für die komplexesten Projekte mit den strengsten Anforderungen an Zuverlässigkeit und Belastung, einschließlich PREMIER und Match TV. Bei Sportübertragungen und bei der Premiere beliebter Fernsehserien ist die Rückgabe des Verkehrs in Terabit / s erforderlich. Dies können wir problemlos umsetzen, und so oft ist es für uns längst üblich, mit solchen Geschwindigkeiten zu arbeiten. Und vor fünf Jahren war Rutube das schwierigste Projekt, das an unseren Systemen gearbeitet hat. Seitdem wurden Volumen und Verkehr erhöht, was bei der Planung von Lasten berücksichtigt werden musste.



Wir sprachen darüber, wie wir die Hardware unserer Infrastruktur entwickelt haben ( „Rutube 2009-2015: Die Geschichte unserer Hardware“ ) und ein System für das Hochladen von Videos entwickelt haben ( „Von null auf 700 Gigabit pro Sekunde - wie eine der größten Video-Hosting-Sites in Russland ""), aber seit dem Schreiben dieser Texte ist viel Zeit vergangen. Viele andere Lösungen wurden erstellt und implementiert. Die Ergebnisse ermöglichen es uns, moderne Anforderungen zu erfüllen und flexibel genug zu sein, um für neue Aufgaben neu zu erstellen.







Wir entwickeln den Netzwerkkern ständig weiter. Wir haben 2015 auf Cisco-Geräte umgestellt, wie im letzten Artikel erwähnt. Damals war es alles das gleiche 10 / 40G, aber aus offensichtlichen Gründen haben sie nach einigen Jahren das vorhandene Chassis aufgerüstet, und jetzt verwenden wir auch aktiv 25 / 100G.







100G-Verbindungen waren lange Zeit weder ein Luxus (eher eine dringende Anforderung der Zeit in unserem Segment) noch eine Seltenheit (immer mehr Betreiber bieten Verbindungen mit solchen Geschwindigkeiten an). 10 / 40G bleibt jedoch relevant: Über diese Verbindungen verbinden wir weiterhin Betreiber mit einem geringen Verkehrsaufkommen, über das es derzeit unpraktisch ist, einen größeren Port zu verwenden.



Der von uns erstellte Netzwerkkern verdient eine gesonderte Betrachtung und wird wenig später zum Thema eines gesonderten Artikels. Dort werden wir uns mit den technischen Details befassen und die Logik unserer Aktionen bei der Erstellung berücksichtigen. Aber jetzt werden wir die Infrastruktur weiterhin schematischer gestalten, da Ihre Aufmerksamkeit, liebe Leser, nicht unbegrenzt ist.



Video-Serving-Serverschnell entwickeln, wofür wir uns viel Mühe geben. Wenn wir früher hauptsächlich 2U-Server mit 4-5 Netzwerkkarten mit jeweils zwei 10G-Ports verwendet haben, wird jetzt der größte Teil des Datenverkehrs von 1U-Servern gesendet, auf denen 2-3 Karten mit jeweils zwei 25G-Ports vorhanden sind. Karten mit 10G und 25G sind fast gleich teuer, und mit schnelleren Lösungen können Sie sowohl 10G als auch 25G geben. Das Ergebnis sind deutliche Einsparungen: Weniger Serverkomponenten und Kabel zum Anschließen - weniger Kosten (und mehr Zuverlässigkeit), Komponenten benötigen weniger Rack-Platz - mehr Server können pro Flächeneinheit untergebracht werden und senken somit die Mietkosten.



Wichtiger ist aber der Geschwindigkeitsgewinn! Jetzt mit 1U können wir über 100G geben! Und dies vor dem Hintergrund einer Situation, in der einige große russische Projekte "Leistung" die Rückkehr von 40G mit 2U nennen. Wir hätten ihre Probleme!







Beachten Sie, dass die Generierung von Netzwerkkarten, die nur mit 10G funktionieren, wir weiterhin verwenden. Dieses Gerät funktioniert stabil und ist uns bestens vertraut. Wir haben es also nicht weggeworfen, sondern eine neue Anwendung dafür gefunden. Wir haben diese Komponenten in Videospeicherservern installiert, für die eine oder zwei 1G-Schnittstellen für einen effektiven Betrieb eindeutig nicht ausreichen. Hier erwiesen sich 10G-Karten als relevant.



Speichersystemewachsen auch. In den letzten fünf Jahren wurden sie von Laufwerken mit zwölf Festplatten (12x HDD 2U) auf Laufwerke mit sechsunddreißig Festplatten (36x HDD 4U) umgestellt. Einige Menschen haben Angst, solch geräumige "Kadaver" zu verwenden, da bei einem Ausfall eines solchen Chassis die Leistung - und sogar die Arbeitskapazität - gefährdet sein kann! - für das gesamte System. Dies wird bei uns jedoch nicht passieren: Wir haben Backups auf der Ebene von geoverteilten Kopien von Daten bereitgestellt. Wir verteilen das Gehäuse auf verschiedene Rechenzentren - wir verwenden insgesamt drei - und dies verhindert das Auftreten von Problemen sowohl bei Gehäuseausfällen als auch bei einem Ausfall der Plattform.







Natürlich hat dieser Ansatz Hardware-RAID überflüssig gemacht, was wir aufgegeben haben. Durch die Beseitigung der Redundanz haben wir gleichzeitig die Zuverlässigkeit des Systems erhöht, die Lösung vereinfacht und einen der potenziellen Fehlerpunkte beseitigt. Denken Sie daran, dass unsere Speichersysteme "selbst hergestellt" sind. Wir haben uns ganz bewusst dafür entschieden und das Ergebnis war für uns völlig zufriedenstellend. In den letzten fünf Jahren haben wir



Rechenzentren mehrmals gewechselt. Seit dem Schreiben des vorherigen Artikels haben wir nicht nur ein Rechenzentrum geändert - DataLine - der Rest musste im Zuge der Entwicklung unserer Infrastruktur ersetzt werden. Alle Transfers zwischen Standorten waren geplant.



Vor zwei Jahren sind wir in MMTS-9 eingewandert und an einen Standort mit einer hochwertigen Reparatur, einem guten Kühlsystem, einer stabilen Stromversorgung und ohne Staub umgezogen, der früher auf allen Oberflächen in dicken Schichten lag und auch die Innenseiten unserer Geräte stark verstopfte. Entscheiden Sie sich für hochwertigen Service - und staubfrei! - wurde der Grund für unseren Umzug.







Fast immer bedeutet „ein Zug zwei Brände“, aber die Migrationsprobleme sind jedes Mal anders. Dieses Mal wurde die Hauptschwierigkeit beim Bewegen innerhalb eines Rechenzentrums durch optische Querverbindungen "bereitgestellt" - ihre Häufigkeit zwischen den Stockwerken, ohne von Telekommunikationsbetreibern zu einer einzigen Querverbindung gemischt zu werden. Das Aktualisieren und Umleiten von Kreuzungen (mit denen uns die MMTS-9-Ingenieure geholfen haben) war möglicherweise die schwierigste Phase der Migration.



Die zweite Migration fand vor einem Jahr statt. 2019 zogen wir von einem nicht so guten Rechenzentrum auf O2xygen um. Die Gründe für den Umzug waren ähnlich wie oben beschrieben, wurden jedoch durch das Problem der Unattraktivität des ursprünglichen Rechenzentrums für Telekommunikationsbetreiber ergänzt - viele Anbieter mussten diesen Punkt selbst "aufholen".







Die Migration von 13 Racks zu einem qualitativ hochwertigen Standort in MMTS-9 ermöglichte es, diesen Standort nicht nur als Operator (einige Racks und Weiterleitungsoperatoren) zu entwickeln, sondern ihn auch als einen der wichtigsten zu verwenden. Dies vereinfachte die Migration von einem nicht sehr guten Rechenzentrum etwas - wir haben den größten Teil der Geräte von diesem an einen anderen Standort verlegt, und O2xygen übernahm die Entwicklung und schickte dort 5 Racks mit Geräten.



O2xygen ist bereits heute eine vollwertige Plattform, auf der die von uns benötigten Betreiber „gekommen“ sind und sich weiterhin neue verbinden. Für die Betreiber war O2xygen auch im Hinblick auf die strategische Entwicklung attraktiv.



Wir verbringen die Hauptphase des Umzugs definitiv über Nacht, und bei der Migration innerhalb von MMTS-9 und zu O2xygen haben wir uns an diese Regel gehalten. Wir möchten betonen, dass wir uns strikt an die Regel „in einer Nacht bewegen“ halten, unabhängig von der Anzahl der Racks! Es gab sogar einen Präzedenzfall, als wir 20 Racks bewegten und dies auch in einer Nacht taten. Die Migration ist ein ziemlich einfacher Prozess, der Genauigkeit und Konsistenz erfordert. Hier gibt es jedoch einige Tricks, sowohl im Vorbereitungsprozess als auch beim Verschieben und beim Bereitstellen an einem neuen Standort. Bei Interesse informieren wir Sie gerne ausführlich über die Migration.



ErgebnisseWir mögen Fünfjahresentwicklungspläne. Wir haben den Aufbau einer neuen ausfallsicheren Infrastruktur in drei Rechenzentren abgeschlossen. Wir haben die Dichte der Verkehrszustellung dramatisch erhöht. Wenn wir uns kürzlich über 40-80 G mit 2U gefreut haben, ist es jetzt normal, dass wir 100 G mit 1U geben. Jetzt wird ein Terabit des Verkehrs von uns als alltäglich empfunden. Wir sind bereit, unsere Infrastruktur weiterzuentwickeln, die sich als flexibel und skalierbar erwiesen hat.



Frage:Was soll ich Ihnen in den folgenden Texten sagen, liebe Leser? Warum haben wir angefangen, hausgemachte Speichersysteme zu bauen? Über den Netzwerkkern und seine Funktionen? Über die Tricks und Feinheiten der Migration zwischen Rechenzentren? Informationen zur Optimierung von Emissionsentscheidungen durch Auswahl von Komponenten und Feinabstimmung von Parametern? Über die Schaffung nachhaltiger Lösungen dank mehrfacher Redundanz und horizontaler Skalierbarkeit innerhalb des Rechenzentrums, die in einer Struktur aus drei Rechenzentren implementiert sind?



Autor: Petr Vinogradov - Technischer Direktor von Uma.TechHamster



All Articles