Das moderne Web ist ohne Medieninhalte kaum noch denkbar: Fast jede Großmutter hat ein Smartphone, alle sind in sozialen Netzwerken unterwegs und Ausfallzeiten bei der Wartung sind für Unternehmen kostspielig. Hier finden Sie eine Abschrift der Unternehmensgeschichte darüber, wie sie die Zustellung der Fotos mithilfe einer Hardwarelösung organisiert hat, auf welche Performance-Probleme sie dabei gestoßen ist, was diese verursacht hat und wie diese Probleme mithilfe einer Softwarelösung auf Nginx-Basis gelöst wurden und gleichzeitig Fehlertoleranz auf allen Ebenen sichergestellt wurde (). Wir danken den Autoren von Olegs Geschichte Efimova und Alexandra Dymova, die ihre Erfahrungen auf der Konferenz teilten .
— Beginnen wir mit einer kleinen Einführung darüber, wie wir Fotos speichern und zwischenspeichern. Wir haben eine Ebene, auf der wir sie speichern, und eine Ebene, auf der wir die Fotos zwischenspeichern. Gleichzeitig ist es für uns wichtig, dass sich jedes Foto eines einzelnen Benutzers auf einem Caching-Server befindet, wenn wir eine hohe Trickrate erreichen und den Speicher entlasten möchten. Andernfalls müssten wir um ein Vielfaches mehr Festplatten installieren, je mehr Server wir haben. Unsere Trickrate liegt bei etwa 99 %, das heißt, wir reduzieren die Belastung unseres Speichers um das Hundertfache, und um dies zu erreichen, hatten wir vor 100 Jahren, als das alles gebaut wurde, 10 Server. Um diese Fotos bereitzustellen, benötigten wir dementsprechend im Wesentlichen 50 externe Domänen, die diese Server bedienen.
Natürlich stellte sich sofort die Frage: Welchen Teil des Datenverkehrs verlieren wir, wenn einer unserer Server ausfällt und nicht mehr verfügbar ist? Wir schauten uns an, was es auf dem Markt gab, und entschieden uns für den Kauf einer Hardware, die alle unsere Probleme lösen würde. Die Wahl fiel auf die Lösung des F5-Netzwerkunternehmens (das übrigens kürzlich NGINX, Inc. gekauft hat): BIG-IP Local Traffic Manager.
Was diese Hardware (LTM) macht: Es handelt sich um einen Iron-Router, der für eine Iron-Redundanz seiner externen Ports sorgt und es Ihnen ermöglicht, den Datenverkehr basierend auf der Netzwerktopologie und einigen Einstellungen weiterzuleiten und Gesundheitsprüfungen durchzuführen. Es war uns wichtig, dass diese Hardware programmiert werden kann. Dementsprechend könnten wir die Logik beschreiben, wie Fotos eines bestimmten Benutzers aus einem bestimmten Cache bereitgestellt wurden. Wie sieht es aus? Es gibt eine Hardware, die das Internet auf einer Domäne, einer IP untersucht, SSL-Offload durchführt, http-Anfragen analysiert, eine Cache-Nummer aus IRule auswählt, wohin sie gehen soll, und den Datenverkehr dorthin leitet. Gleichzeitig führt es Gesundheitsprüfungen durch und für den Fall, dass ein Computer nicht verfügbar ist, haben wir damals dafür gesorgt, dass der Datenverkehr an einen Backup-Server weitergeleitet wird. Aus Konfigurationssicht gibt es natürlich einige Nuancen, aber im Allgemeinen ist alles ganz einfach: Wir registrieren eine Karte, entsprechen einer bestimmten Nummer unserer IP im Netzwerk und sagen, dass wir die Ports 80 abhören werden und 443 sagen wir, dass Sie, wenn der Server nicht verfügbar ist, Datenverkehr an den Backup-Server, in diesem Fall den 35., senden müssen, und wir beschreiben eine Reihe von Logiken, wie diese Architektur zerlegt werden sollte. Das einzige Problem bestand darin, dass die Sprache, in der die Hardware programmiert wurde, Tcl war. Falls sich irgendjemand daran erinnert ... diese Sprache ist eher schreibgeschützt als eine zum Programmieren geeignete Sprache:
Was haben wir bekommen? Wir haben eine Hardware erhalten, die eine hohe Verfügbarkeit unserer Infrastruktur gewährleistet, unseren gesamten Datenverkehr weiterleitet, gesundheitliche Vorteile bietet und einfach funktioniert. Außerdem funktioniert es ziemlich lange: In den letzten 10 Jahren gab es keine Beschwerden darüber. Anfang 2018 haben wir bereits etwa 80 Fotos pro Sekunde verschickt. Das sind ungefähr 80 Gigabit Datenverkehr von unseren beiden Rechenzentren.
Wie auch immer ...
Zu Beginn des Jahres 2018 sahen wir in den Charts ein unschönes Bild: Die Zeit, die für den Versand von Fotos benötigt wurde, hatte sich deutlich erhöht. Und es passte nicht mehr zu uns. Das Problem ist, dass dieses Verhalten nur während der Hauptverkehrszeit sichtbar war – für unser Unternehmen ist das die Nacht von Sonntag auf Montag. Aber die restliche Zeit verhielt sich das System wie gewohnt, es gab keine Anzeichen eines Ausfalls.
Dennoch musste das Problem gelöst werden. Wir haben mögliche Engpässe identifiziert und begonnen, diese zu beseitigen. Zunächst haben wir natürlich die externen Uplinks ausgebaut, ein komplettes Audit der internen Uplinks durchgeführt und alle möglichen Engpässe gefunden. All dies führte jedoch zu keinem offensichtlichen Ergebnis, das Problem verschwand nicht.
Ein weiterer möglicher Engpass war die Leistung der Foto-Caches selbst. Und wir kamen zu dem Schluss, dass das Problem vielleicht bei ihnen liegt. Nun, wir haben die Leistung erweitert – hauptsächlich Netzwerk-Ports für Foto-Caches. Aber auch hier war keine offensichtliche Verbesserung zu erkennen. Am Ende haben wir genau auf die Leistung des LTM selbst geachtet und hier sahen wir in den Grafiken ein trauriges Bild: Die Belastung aller CPUs beginnt gleichmäßig zu verlaufen, erreicht dann aber plötzlich ein Plateau. Gleichzeitig reagiert LTM nicht mehr angemessen auf Zustandsprüfungen und Uplinks und schaltet diese nach dem Zufallsprinzip ab, was zu erheblichen Leistungseinbußen führt.
Das heißt, wir haben die Ursache des Problems und den Engpass identifiziert. Es bleibt zu entscheiden, was wir tun werden.
Das erste und offensichtlichste, was wir tun könnten, wäre, den LTM selbst irgendwie zu modernisieren. Aber es gibt hier einige Nuancen, denn diese Hardware ist ziemlich einzigartig, Sie werden nicht zum nächsten Supermarkt gehen und sie kaufen. Dies ist ein separater Vertrag, ein separater Lizenzvertrag, und es wird viel Zeit in Anspruch nehmen. Die zweite Möglichkeit besteht darin, selbst nachzudenken und mit eigenen Komponenten eine eigene Lösung zu finden, am besten mit einem Open-Access-Programm. Es bleibt nur noch zu entscheiden, was wir dafür genau auswählen und wie viel Zeit wir für die Lösung dieses Problems aufwenden werden, da die Benutzer nicht genügend Fotos erhalten haben. Deshalb müssen wir das alles sehr, sehr schnell erledigen, man könnte sagen: gestern.
Da sich die Aufgabe so anhörte, als würde man „etwas so schnell wie möglich erledigen und die Hardware nutzen, die wir haben“, dachten wir zunächst, einfach einige nicht sehr leistungsstarke Maschinen von vorne zu entfernen und Nginx dort zu platzieren, womit wir vertraut sind arbeiten und versuchen, die gleiche Logik zu implementieren, die die Hardware früher ausführte. Das heißt, wir haben tatsächlich unsere Hardware zurückgelassen, vier weitere Server installiert, die wir konfigurieren mussten, und externe Domänen für sie erstellt, ähnlich wie vor 4 Jahren ... Wir haben ein wenig an Verfügbarkeit verloren, wenn diese Maschinen ausfielen, aber Noch weniger, sie haben das Problem unserer Benutzer vor Ort gelöst.
Dementsprechend bleibt die Logik dieselbe: Wir installieren Nginx, es kann SSL-Offload durchführen, wir können die Routing-Logik irgendwie programmieren, Gesundheitsprüfungen in den Konfigurationen durchführen und einfach die Logik duplizieren, die wir zuvor hatten.
Setzen wir uns hin, um Konfigurationen zu schreiben. Auf den ersten Blick schien alles sehr einfach zu sein, aber leider ist es sehr schwierig, Handbücher für jede Aufgabe zu finden. Daher empfehlen wir nicht, einfach zu googeln, „wie man Nginx für Fotos konfiguriert“. Sehen Sie sich lieber die offizielle Dokumentation an, die zeigt, welche Einstellungen geändert werden sollten. Es ist jedoch besser, den spezifischen Parameter selbst auszuwählen. Dann ist alles ganz einfach: Wir beschreiben die Server, die wir haben, wir beschreiben die Zertifikate ... Aber das Interessanteste ist tatsächlich die Routing-Logik selbst.
Zuerst kam es uns so vor, als würden wir lediglich unseren Standort beschreiben, die Nummer unseres Foto-Caches darin abgleichen, mit unseren Händen oder einem Generator beschreiben, wie viele Upstreams wir benötigen, und in jedem Upstream den Server angeben, zu dem der Datenverkehr geleitet werden soll gehen, und einen Backup-Server – wenn der Hauptserver nicht verfügbar ist:
Aber wenn alles so einfach wäre, würden wir wahrscheinlich einfach nach Hause gehen und nichts sagen. Leider sieht die Konfiguration mit den Standard-Nginx-Einstellungen, die im Allgemeinen über viele Jahre der Entwicklung hinweg vorgenommen wurden und für diesen Fall nicht ganz geeignet sind, so aus: Wenn bei einem Upstream-Server ein Anforderungsfehler oder eine Zeitüberschreitung auftritt, funktioniert Nginx immer leitet den Verkehr auf den nächsten um. Darüber hinaus wird nach dem ersten Ausfall innerhalb von 10 Sekunden auch der Server aus Versehen oder aufgrund einer Zeitüberschreitung ausgeschaltet – dies kann in keiner Weise konfiguriert werden. Das heißt, wenn wir die Timeout-Option in der Upstream-Direktive entfernen oder zurücksetzen, wird der Server heruntergefahren, obwohl Nginx diese Anfrage nicht verarbeitet und mit einem nicht sehr guten Fehler antwortet.
Um dies zu vermeiden, haben wir zwei Dinge getan:
a) Sie haben Nginx verboten, dies manuell zu tun – und leider besteht die einzige Möglichkeit, dies zu tun, darin, einfach die Einstellungen für die maximale Anzahl von Fehlern festzulegen.
b) Wir haben uns daran erinnert, dass wir in anderen Projekten ein Modul verwenden, das es uns ermöglicht, Gesundheitschecks im Hintergrund durchzuführen – dementsprechend haben wir ziemlich häufig Gesundheitschecks durchgeführt, sodass die Ausfallzeiten im Falle eines Unfalls minimal waren.
Leider ist das aber noch nicht alles, denn buchstäblich haben die ersten zwei Betriebswochen dieses Schemas gezeigt, dass die TCP-Gesundheitsprüfung auch eine unzuverlässige Sache ist: Auf dem Upstream-Server ist es möglicherweise nicht Nginx oder Nginx im D-Status und in In diesem Fall akzeptiert der Kernel die Verbindung, die Gesundheitsprüfung wird bestanden, funktioniert aber nicht. Deshalb haben wir dies sofort durch Health-Check http ersetzt und ein spezifisches erstellt, das, wenn es 200 zurückgibt, in diesem Skript alles funktioniert. Sie können zusätzliche Logik ausführen – überprüfen Sie beispielsweise bei Caching-Servern, ob das Dateisystem korrekt gemountet ist:
Und das würde uns passen, außer dass die Schaltung in diesem Moment vollständig wiederholte, was die Hardware tat. Aber wir wollten es besser machen. Früher hatten wir einen Backup-Server, und das ist wahrscheinlich nicht sehr gut, denn wenn Sie hundert Server haben und mehrere gleichzeitig ausfallen, ist es unwahrscheinlich, dass ein Backup-Server die Last bewältigen kann. Aus diesem Grund haben wir uns entschieden, die Reservierung auf alle Server zu verteilen: Wir haben einfach einen weiteren separaten Upstream erstellt, alle Server dort mit bestimmten Parametern entsprechend der Last, die sie bedienen können, geschrieben und die gleichen Gesundheitsprüfungen hinzugefügt, die wir zuvor hatten:
Da es unmöglich ist, innerhalb eines Upstreams zu einem anderen Upstream zu wechseln, musste sichergestellt werden, dass wir, wenn der Haupt-Upstream, in dem wir einfach den richtigen, notwendigen Foto-Cache aufgezeichnet haben, nicht verfügbar war, einfach die error_page durchgingen, auf die zurückgegriffen werden sollte wo wir zum Backup-Upstream gegangen sind:
Und durch das buchstäbliche Hinzufügen von vier Servern haben wir Folgendes erreicht: Wir haben einen Teil der Last ersetzt – wir haben sie von LTM auf diese Server verlagert, dort die gleiche Logik unter Verwendung von Standardhardware und -software implementiert und sofort den Bonus erhalten, den diese Server bieten können skalierbar, da sie einfach so viel liefern können, wie benötigt wird. Das einzig Negative ist, dass wir die hohe Verfügbarkeit für externe Benutzer verloren haben. Aber in diesem Moment mussten wir darauf verzichten, weil es notwendig war, das Problem sofort zu lösen. Also haben wir einen Teil der Last entfernt, es waren zu diesem Zeitpunkt etwa 40 %, LTM fühlte sich gut an, und buchstäblich zwei Wochen nach Beginn des Problems begannen wir, nicht 45 Anfragen pro Sekunde zu senden, sondern 55. Tatsächlich sind wir um 20 % gewachsen – das ist eindeutig der Traffic, den wir dem Benutzer nicht gegeben haben. Und danach begannen sie darüber nachzudenken, wie das verbleibende Problem gelöst werden könnte – eine hohe externe Zugänglichkeit sicherzustellen.
Wir machten eine Pause und besprachen, welche Lösung wir hierfür verwenden würden. Es gab Vorschläge, die Zuverlässigkeit mithilfe von DNS, einigen selbst geschriebenen Skripten und dynamischen Routing-Protokollen sicherzustellen. Es gab viele Optionen, aber es wurde bereits klar, dass Sie für eine wirklich zuverlässige Bereitstellung von Fotos eine weitere Ebene einführen müssen, die dies überwacht . Wir haben diese Maschinen Fotoregisseure genannt. Die Software, auf die wir uns verlassen haben, war Keepalived:
Woraus besteht Keepalived zunächst einmal? Das erste ist das unter Netzwerkern weithin bekannte VRRP-Protokoll, das sich auf Netzwerkgeräten befindet und Fehlertoleranz gegenüber der externen IP-Adresse bietet, mit der Clients eine Verbindung herstellen. Der zweite Teil ist IPVS, ein virtueller IP-Server, der für den Ausgleich zwischen Fotoroutern und die Gewährleistung der Fehlertoleranz auf dieser Ebene sorgt. Und drittens – Gesundheitschecks.
Beginnen wir mit dem ersten Teil: VRRP – wie sieht es aus? Es gibt eine bestimmte virtuelle IP, die einen Eintrag im DNS badoocdn.com hat, über den sich Clients verbinden. Irgendwann haben wir eine IP-Adresse auf einem Server. Keepalived-Pakete werden mithilfe des VRRP-Protokolls zwischen den Servern übertragen. Wenn der Master vom Radar verschwindet – der Server wurde neu gestartet oder etwas anderes –, übernimmt der Backup-Server automatisch diese IP-Adresse – es sind keine manuellen Maßnahmen erforderlich. Der Unterschied zwischen Master und Backup liegt vor allem in der Priorität: Je höher sie ist, desto größer ist die Chance, dass die Maschine zum Master wird. Ein sehr großer Vorteil besteht darin, dass Sie IP-Adressen nicht auf dem Server selbst konfigurieren müssen. Es reicht aus, sie in der Konfiguration zu beschreiben. Wenn die IP-Adressen einige benutzerdefinierte Routing-Regeln benötigen, wird dies direkt in der Konfiguration mithilfe von beschrieben Dieselbe Syntax wie im VRRP-Paket beschrieben. Sie werden auf keine unbekannten Dinge stoßen.
Wie sieht das in der Praxis aus? Was passiert, wenn einer der Server ausfällt? Sobald der Master verschwindet, empfängt unser Backup keine Werbung mehr und wird automatisch zum Master. Nach einiger Zeit haben wir den Master repariert, neu gestartet, Keepalived aktiviert – Ankündigungen kommen mit einer höheren Priorität als das Backup an, und das Backup kehrt automatisch zurück, entfernt IP-Adressen, es sind keine manuellen Maßnahmen erforderlich.
Somit haben wir die Fehlertoleranz der externen IP-Adresse sichergestellt. Der nächste Teil besteht darin, den Datenverkehr von der externen IP-Adresse irgendwie auf die Foto-Router auszugleichen, die ihn bereits terminieren. Mit den Auswuchtprotokollen ist alles ganz klar. Dies ist entweder ein einfaches Round-Robin oder etwas komplexere Dinge, Wrr, Listenverbindung und so weiter. Dies ist grundsätzlich in der Dokumentation beschrieben, es gibt nichts Besonderes. Aber die Versandart... Hier schauen wir uns genauer an, warum wir uns für eine davon entschieden haben. Dies sind NAT, Direct Routing und TUN. Tatsache ist, dass wir sofort geplant hatten, 100 Gigabit Datenverkehr von den Standorten zu liefern. Wenn Sie schätzen, benötigen Sie 10 Gigabit-Karten, oder? 10 Gigabit-Karten in einem Server sprengen bereits den Rahmen, zumindest unserer Vorstellung von „Standardausstattung“. Und dann fiel uns ein, dass wir nicht nur etwas Verkehr verschenken, sondern auch Fotos.
Was ist das Besondere? — Enormer Unterschied zwischen eingehendem und ausgehendem Verkehr. Der eingehende Verkehr ist sehr gering, der ausgehende Verkehr ist sehr groß:
Wenn Sie sich diese Diagramme ansehen, können Sie sehen, dass der Regisseur derzeit etwa 200 MB pro Sekunde empfängt, dies ist ein ganz gewöhnlicher Tag. Wir geben 4,500 MB pro Sekunde zurück, unser Verhältnis beträgt etwa 1/22. Es ist bereits klar, dass wir nur einen benötigen, der diese Verbindung akzeptiert, um den ausgehenden Datenverkehr vollständig an 22 Worker-Server bereitzustellen. Hier kommt uns der Direct-Routing-Algorithmus zu Hilfe.
Wie sieht es aus? Unser Fotodirektor übermittelt laut seiner Tabelle Verbindungen zu Fotoroutern. Aber Fotorouter senden den Rückverkehr direkt ins Internet, an den Client, er geht nicht über den Fotodirektor zurück, sodass wir mit einer minimalen Anzahl von Maschinen vollständige Fehlertoleranz und das Pumpen des gesamten Datenverkehrs gewährleisten. In den Konfigurationen sieht es so aus: Wir geben den Algorithmus an, in unserem Fall ist es ein einfacher RR, stellen die direkte Routing-Methode bereit und beginnen dann damit, alle echten Server aufzulisten, wie viele davon wir haben. Was diesen Verkehr bestimmt. Wenn wir dort einen oder zwei oder mehrere Server haben, entsteht ein solcher Bedarf – wir fügen diesen Abschnitt einfach zur Konfiguration hinzu und machen uns keine allzu großen Sorgen. Von der Seite echter Server, von der Seite des Foto-Routers erfordert diese Methode die minimalste Konfiguration, sie ist in der Dokumentation perfekt beschrieben und es gibt dort keine Fallstricke.
Besonders schön ist, dass eine solche Lösung keine radikale Neugestaltung des lokalen Netzwerks bedeutet; das war für uns wichtig; wir mussten dies mit minimalen Kosten lösen. Wenn man hinschaut , dann werden wir sehen, wie es aussieht. Hier haben wir einen bestimmten virtuellen Server, auf Port 443, der lauscht, die Verbindung akzeptiert, alle funktionierenden Server werden aufgelistet und Sie können sehen, dass die Verbindung, egal ob Geben oder Nehmen, dieselbe ist. Wenn wir uns die Statistiken auf demselben virtuellen Server ansehen, haben wir eingehende Pakete und eingehende Verbindungen, aber absolut keine ausgehenden. Ausgehende Verbindungen gehen direkt zum Client. Okay, wir konnten es aus dem Gleichgewicht bringen. Was passiert nun, wenn einer unserer Fotorouter ausfällt? Schließlich ist Eisen Eisen. Es kann zu einer Kernel-Panik kommen, es kann kaputt gehen, das Netzteil kann durchbrennen. Irgendetwas. Deshalb sind Gesundheitschecks erforderlich. Sie können so einfach sein wie die Überprüfung, ob der Port geöffnet ist, oder etwas komplexeres, bis hin zu einigen selbst geschriebenen Skripten, die sogar die Geschäftslogik überprüfen.
Wir haben irgendwo in der Mitte aufgehört: Wir haben eine https-Anfrage an einen bestimmten Ort, das Skript wird aufgerufen, wenn es mit einer 200. Antwort antwortet, glauben wir, dass mit diesem Server alles in Ordnung ist, dass er am Leben ist und ganz eingeschaltet werden kann leicht.
Wie sieht das wiederum in der Praxis aus? Lassen Sie uns den Server zu Wartungszwecken ausschalten – zum Beispiel zum Flashen des BIOS. In den Protokollen kommt es sofort zu einem Timeout, wir sehen die erste Zeile, nach drei Versuchen wird sie als „fehlgeschlagen“ markiert und einfach aus der Liste entfernt.
Eine zweite Verhaltensoption ist ebenfalls möglich, wenn VS einfach auf Null gesetzt wird, aber wenn das Foto zurückgegeben wird, funktioniert dies nicht gut. Der Server wird hochgefahren, Nginx startet dort, die Gesundheitsprüfung erkennt sofort, dass die Verbindung funktioniert, dass alles in Ordnung ist, und der Server erscheint in unserer Liste und die Last wird sofort auf ihn übertragen. Es sind keine manuellen Maßnahmen seitens des diensthabenden Administrators erforderlich. Der Server wurde nachts neu gestartet – die Überwachungsabteilung ruft uns diesbezüglich nachts nicht an. Sie teilen Ihnen mit, dass dies passiert ist, alles ist in Ordnung.
Mit Hilfe einer kleinen Anzahl von Servern haben wir also auf relativ einfache Weise das Problem der externen Fehlertoleranz gelöst.
Bleibt nur noch zu sagen, dass das alles natürlich überwacht werden muss. Unabhängig davon sollte beachtet werden, dass Keepalivede als Software, die vor langer Zeit geschrieben wurde, über eine Reihe von Möglichkeiten zur Überwachung verfügt, sowohl mithilfe von Überprüfungen über DBus, SMTP, SNMP als auch über Standard-Zabbix. Außerdem weiß er selbst, wie man bei fast jedem Niesen Briefe schreibt, und um ehrlich zu sein, haben wir irgendwann sogar daran gedacht, es auszuschalten, denn er schreibt viele Briefe für jedes Verkehrsschalten, Einschalten, für jede IP-Verbindung, und so weiter. Wenn es viele Server gibt, kann man sich natürlich mit diesen Briefen überfordern. Wir überwachen Nginx auf Foto-Routern mit Standardmethoden, und die Hardware-Überwachung ist nicht verschwunden. Wir würden natürlich noch zu zwei Dingen raten: erstens zu externen Gesundheitschecks und zur Verfügbarkeit, denn selbst wenn alles funktioniert, kann es sein, dass Nutzer aufgrund von Problemen mit externen Anbietern oder etwas Komplexerem möglicherweise keine Fotos erhalten. Es lohnt sich immer, irgendwo in einem anderen Netzwerk, bei Amazon oder anderswo, eine separate Maschine zu haben, die Ihre Server von außen anpingen kann, und es lohnt sich auch, entweder die Anomalieerkennung (für diejenigen, die wissen, wie man kniffliges maschinelles Lernen durchführt) oder einfache Überwachung zu verwenden , zumindest um zu verfolgen, ob die Anfragen stark zurückgegangen sind oder im Gegenteil zugenommen haben. Es kann auch nützlich sein.
Fassen wir zusammen: Tatsächlich haben wir die eiserne Lösung, die irgendwann nicht mehr zu uns passte, durch ein ziemlich einfaches System ersetzt, das alles gleich macht, das heißt, es sorgt für die Beendigung des HTTPS-Verkehrs und weiteres intelligentes Routing mit dem notwendige Gesundheitschecks. Wir haben die Stabilität dieses Systems erhöht, das heißt, wir haben immer noch eine hohe Verfügbarkeit für jede Schicht, außerdem haben wir den Vorteil, dass es ganz einfach ist, alles auf jeder Schicht zu skalieren, weil es sich also um Standardhardware mit Standardsoftware handelt haben wir die Diagnose möglicher Probleme vereinfacht.
Was haben wir am Ende herausgefunden? Wir hatten während der Januarferien 2018 ein Problem. In den ersten sechs Monaten, in denen wir dieses Schema in Betrieb genommen haben, haben wir es auf den gesamten Datenverkehr ausgeweitet, um den gesamten Datenverkehr aus LTM zu entfernen. Wir haben nur den Datenverkehr in einem Rechenzentrum von 40 Gigabit auf 60 Gigabit erhöht und gleichzeitig für Im gesamten Jahr 2018 konnten wir fast dreimal mehr Fotos pro Sekunde versenden.
Source: habr.com