Diese Woche habe ich mich mit dem COVID-19 angesteckt und war insgesamt 9 Tage zu Hause. In dieser Zeit bestand das Wichtigste bei der Arbeit darin, die Auswirkungen der Förderung und Einführung eines kleinen Programms auf das Basisdienstsystem, für das ich verantwortlich bin, zu bewerten. Diese App traf die Bedürfnisse der Menschen im Land zu dieser Zeit und man erwartete einen großen Zustrom von Besuchern, der sich auf die Kerndienste des Basisdienstesystems auswirken könnte. Ursprünglich hatten sie eine Funktion, die kurz vor dem Start stand, und es gab viel Verkehr, so dass ich die Kapazität bereits bewertet und erweitert hatte. Doch dieses Mal, nachdem sie Hunderte von Millionen von Volumenbenachrichtigungen verschoben hatten, kam es zu einer großen Anzahl von Timeouts.
Um 8 Uhr morgens lag ich im Bett und erholte mich, als ich angerufen wurde und mir mitgeteilt wurde, dass es eine massive Zeitüberschreitung auf der Login-Schnittstelle gab. Ich holte sofort meinen Laptop heraus, verband mich mit dem Intranet und stellte fest, dass der Schnittstellenverkehr direkt mehr als 20 Mal stattfand. Ich bin ins Schwitzen gekommen und habe zunächst vermutet, dass die Anzahl der Business-Container nicht ausreicht, um eine so große Menge an Datenverkehr zu bewältigen. Als ich dann die Protokolle durchsah, stellte ich fest, dass dies nicht das Problem ist. Das Problem besteht aus zwei Teilen, zum einen aus einem begrenzten Datenfluss über die interne Schnittstelle, der aktuelle Datenfluss hat das Limit überschritten, zum anderen ist die Cache-Datenbank, die mit der Datenbank verbunden ist, voll.
Der interne Schnittstellengrenzfluss ist relativ einfach zu lösen, indem Sie über den Notruf die entsprechenden Kollegen finden, um die Schwelle des Grenzflusses anzuheben. Eine andere Cache-Datenbank, aufgrund der großen Anzahl von alten Benutzern Zustrom führt zu ständig lesen alte Daten aus der Datenbank in den Cache, und die Häufigkeit mit dem Wachstum des Verkehrs weiter zu erhöhen, und schließlich auf den Cache hinter der Datenbank verbunden, um die volle E / A. Im Anschluss an mehrere Kern-Cache-Datenbank, wieder einmal eine Charge von Expansion, verbessern Sie die Cache-Kapazität und die Anzahl der Knoten, um mit den nachfolgenden größeren Verkehr und Gleichzeitigkeit zu bewältigen.
Bei der routinemäßigen Wartung geht es vor allem darum, die k8s-Planungsrichtlinie eines Gateway-Service-Pods anzupassen und ihn auf einen Rechenknoten zu planen, der direkt von der CVM-Virtualisierung unterstützt wird (einschichtige Planung). Ursprünglich war der Compute Node, auf dem dieser Dienst geplant wurde, ein CVM, der auf einem physischen Server virtualisiert war, den unser Unternehmen gekauft und als Compute Node verwendet hatte. Nach der Planung auf diesem Knoten wird ein Ausführungsbereich auf diesem CVM virtualisiert (siehe Docker-Technologie), und dann werden Pods auf diesem Knoten geplant, um die Ausführung zu starten (zweistufige Planung). Auf einem Rechenknoten kann es mehrere oder sogar ein Dutzend Pods geben, die auf demselben Betriebssystem, aber mit unterschiedlichen Ausführungsräumen laufen. Dies führt zu einer schlechten Isolierung von CPU, Arbeitsspeicher, Netzwerkkarte und anderen Ressourcen, die sich oft gegenseitig stören. Und wenn dieser CVM-Rechenknoten neu gebootet oder aktualisiert werden muss, werden alle darauf befindlichen Pods evakuiert. Und der Wind im Betriebssystem des Rechenknotens wirkt sich auf alle darauf befindlichen Pods aus. Dies ist für diese Art von Gateway, bei dem es sich um einen Dienst mit hohen Anforderungen an Zuverlässigkeit und Latenzzeit handelt, nicht geeignet.
Und eine Schicht von Scheduling Compute Nodes, in der Tat, von der Wolke zu Computing-Ressourcen und virtuelle CVM zuweisen, um dieses Verfahren allein auszuführen, CVM-Ressourcen werden aus dem gesamten Cloud-Ressourcen-Pool erhalten. Und dieser Ansatz unterstützt k8s, denn dieser neue Scheduling-Ansatz wird als eine Art „Superknoten“ auf k8s virtualisiert. k8s kann den Pod direkt auf dem Superknoten einplanen, der Pod kann direkt auf einer Schicht des Scheduling basieren, d.h. direkt auf einem separaten CVM laufen. Dieser Ansatz ist hochgradig isoliert und beeinträchtigt sich gegenseitig nicht. Da auf jedem CVM nur ein Knoten läuft, kann ein Problem, das bei einem einzelnen Pod auftritt, für diesen Pod behoben werden, ohne dass andere Pods davon betroffen sind.
Wenn Sie die Planungsstrategie ändern und alle Pods des Dienstes auf dem Supernode einplanen, läuft der gesamte Dienst stabiler. Die Situation mit der hohen Timeout-Rate und CPU-Auslastung während der Spitzenzeiten tritt nur noch selten auf.
