{"id":92073,"date":"2020-08-22T19:41:56","date_gmt":"2020-08-22T17:41:56","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/post-mortem-po-nedostupnosti-quay-io"},"modified":"2020-08-22T19:41:56","modified_gmt":"2020-08-22T17:41:56","slug":"post-mortem-po-nedostupnosti-quay-io","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/post-mortem-po-nedostupnosti-quay-io","title":{"rendered":"Post Mortem zur Erreichbarkeit von Quay.io","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Anmerkung des \u00dcbersetzers.<\/b>: Anfang August hat Red Hat \u00f6ffentlich \u00fcber die L\u00f6sungen f\u00fcr die Verf\u00fcgbarkeitsprobleme berichtet, die in den Monaten zuvor bei den Nutzern ihres Dienstes aufgetreten sind. Quay.io<\/a><\/noindex> (basierend auf einem Container-Image-Registry, das das Unternehmen mit dem Kauf von CoreOS \u00fcbernommen hat). Unabh\u00e4ngig von Ihrem Interesse an diesem Dienst ist der Weg, den die SRE-Ingenieure des Unternehmens zur Diagnose und Behebung der Ursachen des Ausfalls gegangen sind, lehrreich.<\/i><\/p>\n

\"Post
\n
\nAm 19. Mai, fr\u00fch am Morgen (nach nordamerikanischer Sommerzeit, EDT), ist der Dienst quay.io ausgefallen. Der Ausfall betraf sowohl die Nutzer von quay.io als auch Open-Source-Projekte, die quay.io als Plattform f\u00fcr den Bau und die Verbreitung von Software verwenden. Red Hat legt gro\u00dfen Wert auf das Vertrauen beider Gruppen.<\/p>\n

Das Team der SRE-Ingenieure setzte sofort alles daran, den Service Quay so schnell wie m\u00f6glich wieder stabil zu machen. W\u00e4hrend sie daran arbeiteten, konnten die Kunden jedoch keine neuen Images pushen und nur sporadisch bestehende pullen. Aus unbekannten Gr\u00fcnden wurde die Datenbank von quay.io nach der Skalierung des Dienstes auf volle Leistung blockiert.<\/a><\/noindex><\/p>\n

\u00abWas hat sich ge\u00e4ndert?<\/b>\u00bb \u2014 das ist die erste Frage, die in solchen F\u00e4llen gestellt wird. Wir haben festgestellt, dass kurz vor dem Problem der OpenShift Dedicated-Cluster (auf dem quay.io l\u00e4uft) mit dem Update auf Version 4.3.19 begann. Da quay.io auf Red Hat OpenShift Dedicated (OSD) l\u00e4uft, waren regelm\u00e4\u00dfige Updates eine allt\u00e4gliche Operation und f\u00fchrten nie zu Problemen. Dar\u00fcber hinaus haben wir in den vergangenen sechs Monaten mehrere Cluster-Updates bei Quay durchgef\u00fchrt, ohne dass es zu Wartungsunterbrechungen kam.<\/p>\n

W\u00e4hrend wir versuchten, den Dienst wiederherzustellen, begannen andere Ingenieure mit der Vorbereitung eines neuen OSD-Clusters mit der vorherigen Softwareversion, um im Ernstfall alles darauf zu implementieren.<\/p>\n

Ursachenanalyse<\/h2>\n

\nDas Hauptsymptom des Ausfalls war eine Welle von zehntausenden Verbindungen zur Datenbank, wodurch die MySQL-Instanz faktisch nicht mehr funktionsf\u00e4hig war. Dies erschwerte die Diagnose des Problems. Wir haben die maximale Anzahl von Verbindungen von Clients begrenzt, um dem SRE-Team zu helfen, das Problem zu bewerten. Es wurde kein ungew\u00f6hnlicher Datenverkehr zur Datenbank festgestellt: Tats\u00e4chlich waren die meisten Anfragen Leseanfragen, und nur wenige waren Schreibanfragen.<\/p>\n

Wir haben auch versucht, ein Muster im DB-Verkehr zu ermitteln, das diese Flut verursachen k\u00f6nnte. Allerdings konnten wir in den Protokollen keine Muster finden. In Erwartung der Fertigstellung des neuen Clusters mit OSD 4.3.18 haben wir weiterhin versucht, die Pods von quay.io zu starten. Jedes Mal, wenn das Cluster seine volle Kapazit\u00e4t erreichte, hing die Datenbank. Das bedeutete, dass es notwendig war, die RDS-Instanz zus\u00e4tzlich zu allen Pods von quay.io neu zu starten.<\/p>\n

Bis zum Abend stabilisierten wir den Dienst im Nur-Lesen-Modus und schalteten m\u00f6glichst viele unwesentlichen Funktionen (wie das Aufr\u00e4umen im Namensraum) ab, um die Belastung der Datenbank zu verringern. Die H\u00e4nger h\u00f6rten auf, aber der Grund wurde nicht gefunden<\/b>. Der neue OSD-Cluster war bereit, und wir migrierten den Dienst, schlossen den Verkehr an und setzten die \u00dcberwachung fort.<\/p>\n

Quay.io lief stabil auf dem neuen OSD-Cluster, also haben wir die Datenbank-Logs wieder \u00fcberpr\u00fcft, konnten aber keine Korrelation finden, die die Sperrungen erkl\u00e4rte. Die Ingenieure von OpenShift arbeiteten mit uns zusammen, um zu verstehen, ob \u00c4nderungen in Red Hat OpenShift 4.3.19 Probleme mit Quay verursacht haben k\u00f6nnten. Doch es wurde nichts festgestellt und es war nicht m\u00f6glich, das Problem im Labor zu reproduzieren<\/b>.<\/p>\n

Der zweite Ausfall<\/h2>\n

\nAm 28. Mai, kurz vor Mittag EDT, fiel quay.io erneut mit demselben Symptom aus: die Funktion der Datenbank wurde blockiert. Und wieder versammelten wir alle Kr\u00e4fte f\u00fcr die Untersuchung. Zuerst musste der Dienst wiederhergestellt werden. Allerdings In diesem Fall f\u00fchrten der Neustart von RDS und das Neustarten der Pods von quay.io zu nichts.<\/b>: eine weitere Welle von Verbindungen \u00fcberkam die Datenbank. Aber warum?<\/p>\n

Quay ist in Python geschrieben, und jeder Pod funktioniert als ein einziger monolithischer Container. Im Container-Execution-Umfeld werden gleichzeitig viele parallele Aufgaben ausgef\u00fchrt. Wir verwenden die Bibliothek gevent<\/code> unter gunicorn<\/code> zur Verarbeitung von Webanfragen. Wenn eine Anfrage an Quay gesendet wird (\u00fcber unsere eigene API oder \u00fcber die Docker-API), wird ihr ein gevent-Worker zugewiesen. Normalerweise sollte dieser Worker mit der Datenbank verbunden werden. Nach dem ersten Ausfall stellten wir fest, dass sich die gevent-Worker mit der Datenbank unter Verwendung der Standardeinstellungen verbanden.<\/p>\n

Angesichts der erheblichen Anzahl an Quay-Pods und Tausenden von Anfragen pro Sekunde k\u00f6nnte eine gro\u00dfe Anzahl von Verbindungen zur Datenbank theoretisch die MySQL-Instanz \u00fcberlasten. Durch das Monitoring war bekannt, dass Quay im Durchschnitt 5000 Anfragen pro Sekunde bearbeitet. Etwa ebenso hoch war die Anzahl der Verbindungen zur Datenbank. 5000 Verbindungen lagen noch innerhalb der Kapazit\u00e4ten unserer RDS-Instanz (was man nicht \u00fcber Zehntausende sagen kann). Aus irgendeinem Grund gab es unerwartete Spitzen bei der Anzahl der Verbindungen.<\/b>, aber wir bemerkten keine Korrelation mit den eingehenden Anfragen.<\/p>\n

Diesmal haben wir uns entschieden, die Quelle des Problems zu finden und zu beheben, anstatt nur einen Neustart durchzuf\u00fchren. In den Quellcode von Quay Es wurden \u00c4nderungen vorgenommen, die die Anzahl der Datenbankverbindungen f\u00fcr jeden Worker begrenzen.<\/b> gevent beschr\u00e4nken. Diese Anzahl wurde zu einem Parameter in der Konfiguration: Es war m\u00f6glich, sie \u201eon-the-fly\u201c zu \u00e4ndern, ohne ein neues Container-Image erstellen zu m\u00fcssen. Um herauszufinden, wie viele Verbindungen tats\u00e4chlich verarbeitet werden k\u00f6nnen, wurden mehrere Tests mit einer Staging-Umgebung durchgef\u00fchrt, bei denen verschiedene Werte festgelegt wurden, um zu sehen, wie sich das auf die Lasttestszenarien auswirkt. Letztendlich stellte sich heraus, dass Quay beginnt, 502-Fehler auszugeben, wenn die Anzahl der Verbindungen 10.000 \u00fcberschreitet.<\/b><\/p>\n

Wir haben sofort diese neue Version in der Produktion bereitgestellt und die Verbindungsgrafik zur Datenbank \u00fcberwacht. In der Vergangenheit war die Datenbank etwa 20 Minuten nach dem Start blockiert. Nach 30 problemlosen Minuten hatten wir Hoffnung, und nach einer Stunde hatten wir Gewissheit. Wir haben den Schreibtraffic auf der Website wiederhergestellt und mit der Post-Mortem-Analyse begonnen.<\/p>\n

Indem wir das Problem, das zur Blockierung f\u00fchrte, umgingen, konnten wir die wahren Ursachen nicht kl\u00e4ren.<\/b>Es stellte sich heraus, dass es nicht mit \u00c4nderungen in OpenShift 4.3.19 zusammenh\u00e4ngt, da dasselbe auch in der Version 4.3.18 aufgetreten ist, die zuvor ohne Probleme mit Quay funktionierte.<\/p>\n

Im Cluster verbarg sich offensichtlich etwas anderes.<\/p>\n

Eine detaillierte Untersuchung<\/h2>\n

\nQuay.io hat sechs Jahre lang die Standardkonfiguration zur Verbindung mit der Datenbank ohne Probleme genutzt. Was hat sich ge\u00e4ndert? Es ist klar, dass der Verkehr auf quay.io in dieser Zeit st\u00e4ndig zugenommen hat. In unserem Fall schien es, als ob ein gewisser Schwellenwert erreicht wurde, der einen Ansto\u00df zu einer Flut von Verbindungen gab. Wir haben die Datenbankprotokolle nach dem zweiten Ausfall weiterhin untersucht, konnten jedoch keine Muster oder offensichtlichen Zusammenh\u00e4nge feststellen.<\/p>\n

W\u00e4hrenddessen hat das SRE-Team an Verbesserungen der Sichtbarkeit von Anfragen in Quay und der allgemeinen Gesundheit des Dienstes gearbeitet. Es wurden neue Metriken und Dashboards bereitgestellt<\/b>, die zeigen, welche Teile von Quay bei den Kunden am meisten gefragt sind.<\/p>\n

Quay.io funktionierte bis zum 9. Juni normal. Am Morgen (EDT) waren wir erneut Zeugen eines signifikanten Anstiegs der Verbindungen zur Datenbank. Diesmal gab es keine Ausfallzeiten<\/b>, da ein neuer Parameter ihre Anzahl begrenzte und es nicht erlaubte, die Kapazit\u00e4t von MySQL zu \u00fcberschreiten. Allerdings berichteten viele Nutzer etwa eine halbe Stunde lang von einer langsamen Leistung von quay.io. Wir haben schnell alle verf\u00fcgbaren Daten gesammelt und die hinzugef\u00fcgten \u00dcberwachungswerkzeuge genutzt. Pl\u00f6tzlich trat ein Muster zutage.<\/p>\n

Vor dem Anstieg der Verbindungen gab es eine gro\u00dfe Anzahl von Anfragen an die App Registry API<\/b>. Die App Registry ist eine wenig bekannte Funktion von quay.io. Sie erm\u00f6glicht das Speichern von Dingen wie Helm-Charts und Containern mit reichhaltigen Metadaten. Die meisten Nutzer von quay.io arbeiten nicht mit dieser Funktion, sie wird jedoch aktiv von Red Hat OpenShift genutzt. OperatorHub innerhalb von OpenShift speichert alle Operatoren in der App Registry. Diese Operatoren sind die Grundlage f\u00fcr das \u00d6kosystem von Arbeitslasten in OpenShift und das auf Partner ausgerichtete Betriebsmodell (im Rahmen der zweitagen Aktivit\u00e4ten, Day 2).<\/p>\n

Jeder OpenShift 4-Cluster verwendet Operatoren aus dem integrierten OperatorHub, um einen Katalog von Operatoren bereitzustellen, die installiert werden k\u00f6nnen, sowie Updates f\u00fcr bereits installierte Operatoren bereitzustellen. Mit der zunehmenden Beliebtheit von OpenShift 4 stieg auch die Anzahl der Cluster weltweit. Jeder dieser Cluster l\u00e4dt den Inhalt der Operatoren herunter, um den integrierten OperatorHub zu starten, wobei das App-Registry innerhalb von quay.io als Backend dient. Auf der Suche nach der Ursache des Problems haben wir \u00fcbersehen, dass mit dem allm\u00e4hlichen Anstieg der Beliebtheit von OpenShift auch die Last auf eine der selten verwendeten Funktionen von quay.io zunahm.<\/b>.<\/p>\n

Wir haben eine Analyse des Anfragetraffics der App-Registry durchgef\u00fchrt und in den Code des Registrys geschaut. Sofort wurden Schw\u00e4chen offensichtlich, die dazu f\u00fchrten, dass Datenbankanfragen suboptimal gebildet wurden. Bei geringer Last stellten sie kein Problem dar, aber bei steigender Last wurden sie zu einer Quelle von Problemen. Die App-Registry hatte zwei problematische Endpunkte, die schlecht auf die Lastanstiege reagierten: Der erste gab eine Liste aller Pakete im Repository aus, der zweite gab alle Blobs f\u00fcr ein Paket zur\u00fcck.<\/p>\n

Ursachenbeseitigung<\/h2>\n

\nDie gesamte n\u00e4chste Woche verbrachten wir mit der Optimierung des Codes des App Registrys und seiner Umgebung. Offensichtlich ineffiziente SQL-Abfragen wurden \u00fcberarbeitet, unn\u00f6tige Befehlsaufrufe beseitigt, tar<\/code> (Sie wurde bei jedem Auszug von Blobs ausgef\u00fchrt), Caching wurde \u00fcberall hinzugef\u00fcgt, wo es m\u00f6glich war. Anschlie\u00dfend wurde umfangreiches Leistungstest durchgef\u00fchrt und die Geschwindigkeit des App Registry vor und nach den \u00c4nderungen verglichen.<\/p>\n

API-Anfragen, die zuvor bis zu eine halbe Minute in Anspruch nahmen, wurden nun in Millisekunden ausgef\u00fchrt.<\/b>. In der n\u00e4chsten Woche haben wir die \u00c4nderungen in der Produktion ausgerollt, und seitdem funktioniert quay.io stabil. In dieser Zeit gab es mehrere pl\u00f6tzliche Spitzen im Traffic am Endpoint des App Registry, aber die vorgenommenen Verbesserungen verhinderten Unterbrechungen in der Datenbank.<\/p>\n

Was haben wir gelernt?<\/h2>\n

\nEs ist klar, dass jeder Dienst bestrebt ist, Ausfallzeiten zu vermeiden. In unserem Fall glauben wir, dass die k\u00fcrzlichen Ausf\u00e4lle dazu beigetragen haben, quay.io zu verbessern. Wir haben einige grundlegende Lektionen gelernt, die wir teilen m\u00f6chten:<\/p>\n

    \n
  1. Daten dar\u00fcber, wer und wie Ihr Dienst genutzt wird, sind niemals \u00fcberfl\u00fcssig.<\/b>Da Quay \u201eeinfach funktionierte\u201c, hatten wir nie das Bed\u00fcrfnis, Zeit mit der Optimierung des Verkehrs und dem Lastmanagement zu verbringen. Das erzeugte ein falsches Gef\u00fchl der Sicherheit, dass der Dienst unbegrenzt skalierbar sei.<\/li>\n
  2. Wenn ein Dienst ausf\u00e4llt, ist die Wiederherstellung seiner Funktionst\u00fcchtigkeit die h\u00f6chste Priorit\u00e4t.<\/b>. Da Quay w\u00e4hrend des ersten Ausfalls weiterhin unter einer blockierten Datenbank litt, hatten unsere Standardverfahren nicht den gew\u00fcnschten Effekt und wir konnten den Dienst mit deren Hilfe nicht wiederherstellen. Dies f\u00fchrte zu einer Situation, in der Zeit f\u00fcr die Analyse und Datensammlung aufgewendet werden musste, in der Hoffnung, die Ursache zu finden \u2014 anstatt all unsere Anstrengungen auf die Wiederherstellung der Funktionsf\u00e4higkeit zu konzentrieren.<\/li>\n
  3. Bewerten Sie die Auswirkungen jeder Funktion des Dienstes<\/b>. Kunden haben das App-Registry selten genutzt, sodass es f\u00fcr unser Team keine Priorit\u00e4t hatte. Wenn bestimmte Funktionen eines Produkts kaum benutzt werden, treten ihre Bugs selten auf und die Entwickler h\u00f6ren auf, den Code zu \u00fcberwachen. Es ist leicht, dem Missverst\u00e4ndnis zu erliegen, dass es so sein sollte \u2014 bis pl\u00f6tzlich diese Funktion im Mittelpunkt eines gro\u00dfangelegten Vorfalls steht.<\/li>\n<\/ol>\n

    <\/p>\n

    Was folgt jetzt?<\/h2>\n

    \nDie Arbeit an der Stabilit\u00e4t des Dienstes h\u00f6rt niemals auf, und wir verbessern ihn st\u00e4ndig. Die Verkehrsmengen auf quay.io wachsen weiter, und wir sind uns bewusst, dass wir alles tun m\u00fcssen, um das Vertrauen unserer Kunden zu rechtfertigen. Daher arbeiten wir derzeit an den folgenden Aufgaben:<\/p>\n

      \n
    1. Bereitstellung von nur-lesenden Datenbank-Replikaten, um dem Dienst zu helfen, den entsprechenden Verkehr im Falle von Problemen mit der Hauptinstanz RDS zu bew\u00e4ltigen.<\/li>\n
    2. Aktualisierung der RDS-Instanz. Die aktuelle Version ist an sich kein Problem. Vielmehr m\u00f6chten wir einfach die falsche Spur beseitigen (die wir w\u00e4hrend des Ausfalls verfolgt haben); die Software aktuell zu halten, wird einen weiteren Faktor im Falle zuk\u00fcnftiger Ausf\u00e4lle ausschlie\u00dfen.<\/li>\n
    3. Zus\u00e4tzliches Caching im gesamten Cluster. Wir suchen weiterhin nach Bereichen, in denen Caching dazu beitragen kann, die Last auf die Datenbank zu reduzieren.<\/li>\n
    4. Hinzuf\u00fcgung einer Webanwendungs-Firewall (WAF), um zu sehen, wer und warum sich mit quay.io verbindet.<\/li>\n
    5. Ab dem n\u00e4chsten Release werden die Red Hat OpenShift-Cluster auf App Registry verzichten zugunsten von Operator-Katalogen, die auf Container-Images basieren, die auf quay.io verf\u00fcgbar sind.<\/li>\n
    6. Eine langfristige Alternative zur App Registry k\u00f6nnte die Unterst\u00fctzung der Spezifikationen der Open Container Initiative (OCI) sein. Diese wird derzeit als native Funktion von Quay implementiert und wird Benutzern zur Verf\u00fcgung stehen, sobald die Spezifikation endg\u00fcltig vereinbart ist.<\/li>\n<\/ol>\n

      \nAlle oben genannten Punkte sind Teil der fortlaufenden Investitionen von Red Hat in quay.io, w\u00e4hrend wir von einem kleinen, \u201estart-up-\u00e4hnlichen\u201c Team zu einer ausgereiften Plattform \u00fcbergehen, die von SRE verwaltet wird. Wir wissen, dass viele unserer Kunden, einschlie\u00dflich Red Hat, auf quay.io in ihrem t\u00e4glichen Betrieb angewiesen sind und bem\u00fchen uns, so transparent wie m\u00f6glich in Bezug auf k\u00fcrzliche Ausf\u00e4lle und unsere anhaltenden Bem\u00fchungen, uns zu verbessern, zu sein.<\/p>\n

      P.S. vom \u00dcbersetzer<\/h2>\n

      \nLesen Sie auch in unserem Blog:<\/p>\n