{"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 Unerreichbarkeit von Quay.io","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Hinweis.<\/b>: Anfang August gab Red Hat \u00f6ffentlich bekannt, dass die Probleme mit der Verf\u00fcgbarkeit, die in den vergangenen Monaten bei den Nutzern ihres Dienstes aufgetreten waren, behoben wurden. Quay.io<\/a><\/noindex> (dahinter steht ein Container-Image-Registry, das zusammen mit dem Kauf von CoreOS in den Besitz des Unternehmens \u00fcberging). Unabh\u00e4ngig von Ihrem Interesse an diesem Dienst ist der Weg, den die SRE-Ingenieure des Unternehmens bei der Diagnose und Behebung der Ursachen f\u00fcr die Ausf\u00e4lle gegangen sind, lehrreich.<\/i><\/p>\n

\"Post
\n
\nAm 19. Mai, fr\u00fch am Morgen (nach Summer Eastern Daylight Time, EDT), fiel der Dienst quay.io aus. Der Ausfall betraf sowohl die Nutzer von quay.io als auch Open-Source-Projekte, die quay.io als Plattform zum Bauen und Verbreiten von Software nutzten. Red Hat sch\u00e4tzt das Vertrauen beider Gruppen.<\/p>\n

Das SRE-Team von Ingenieuren setzte sich sofort an die Arbeit und bem\u00fchte sich, den Dienst Quay so schnell wie m\u00f6glich zu stabilisieren. W\u00e4hrend sie jedoch daran arbeiteten, hatten die Kunden die M\u00f6glichkeit verloren, neue Images zu pushen, und konnten nur sporadisch vorhandene Images pullen. Aus unbekannten Gr\u00fcnden wurde die Datenbank von quay.io nach der Skalierung des Dienstes auf volle Kapazit\u00e4t blockiert.<\/a><\/noindex><\/p>\n

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

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

Ursachenanalyse<\/h2>\n

\nDas Hauptsymptom des Ausfalls war eine Flut von Zehntausenden von Verbindungen zur Datenbank, wodurch die MySQL-Instanz faktisch nicht mehr funktionsf\u00e4hig war. Dies machte es schwierig, das Problem zu diagnostizieren. Wir haben eine Obergrenze f\u00fcr die maximale Anzahl von Verbindungen von Clients festgelegt, um dem SRE-Team zu helfen, das Problem einzusch\u00e4tzen. Es wurde kein ungew\u00f6hnlicher Datenbankverkehr festgestellt: Tats\u00e4chlich waren die meisten Anfragen Leseanfragen, w\u00e4hrend nur wenige Schreibanfragen waren.<\/p>\n

Wir haben auch versucht, ein Muster im Datenbankverkehr zu identifizieren, das diese Flut ausl\u00f6sen k\u00f6nnte. Allerdings konnten wir keine Regelm\u00e4\u00dfigkeiten in den Logs finden. W\u00e4hrend wir auf die Bereitstellung des neuen Clusters mit OSD 4.3.18 warteten, setzten wir unsere Versuche fort, 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 hatten wir den Dienst im Nur-Lese-Modus stabilisiert und die meisten nicht wesentlichen Funktionen (zum Beispiel die M\u00fcllsammlung im Namensraum) deaktiviert, um die Last auf der Datenbank zu senken. Die Ausf\u00e4lle h\u00f6rten auf, aber die Ursache wurde nicht gefunden<\/b>. Das neue OSD-Cluster war einsatzbereit, und wir haben den Dienst umgezogen, den Datenverkehr angeschlossen und die \u00dcberwachung fortgesetzt.<\/p>\n

Quay.io funktionierte stabil auf dem neuen OSD-Cluster, also kehrten wir zu den Datenbanklogs zur\u00fcck, konnten jedoch keine Korrelation entdecken, die die Blockierungen erkl\u00e4ren w\u00fcrde. Die Ingenieure von OpenShift arbeiteten eng mit uns zusammen, um herauszufinden, ob \u00c4nderungen in Red Hat OpenShift 4.3.19 Probleme mit Quay verursachen k\u00f6nnten. Allerdings wurde nichts entdeckt, und es war nicht m\u00f6glich, das Problem unter Laborbedingungen zu reproduzieren.<\/b>.<\/p>\n

Zweiter Ausfall<\/h2>\n

\nAm 28. Mai, kurz vor Mittag EDT, fiel quay.io erneut mit demselben Symptom aus: die Datenbankfunktion wurde blockiert. Wiederum setzten wir alle Kr\u00e4fte ein, um zu ermitteln, woran es lag. Zun\u00e4chst musste der Dienst wiederhergestellt werden. Allerdings Bei diesem Versuch f\u00fchrten das Neustarten der RDS und das Neustarten der Pods von quay.io zu nichts.<\/b>: eine weitere Flut von Verbindungen \u00fcberw\u00e4ltigte die Datenbank. Aber warum?<\/p>\n

Quay ist in Python geschrieben, und jeder Pod arbeitet als ein einzelner monolithischer Container. In der Ausf\u00fchrungsumgebung des Containers werden gleichzeitig viele parallele Aufgaben ausgef\u00fchrt. Wir verwenden die Bibliothek gevent<\/code> eine gunicorn<\/code> zur Verarbeitung von Webanfragen. Wenn eine Anfrage an Quay gelangt (\u00fcber unsere eigene API oder die Docker-API), wird ihm ein gevent-Worker zugewiesen. Dieser Worker sollte normalerweise mit der Datenbank kommunizieren. Nach dem ersten Ausfall stellten wir fest, dass die gevent-Worker sich mit der Datenbank unter Verwendung der Standardkonfigurationen verbanden.<\/p>\n

Angesichts der erheblichen Anzahl an Quay-Pods und der tausenden eingehenden Anfragen pro Sekunde h\u00e4tte eine hohe Anzahl an Datenbankverbindungen theoretisch eine MySQL-Instanz \u00fcberlasten k\u00f6nnen. Durch Monitoring war bekannt, dass Quay im Durchschnitt 5.000 Anfragen pro Sekunde verarbeitet. Etwa die gleiche Anzahl an Datenbankverbindungen war zu verzeichnen. 5.000 Verbindungen lagen innerhalb der M\u00f6glichkeiten unserer RDS-Instanz (was man nicht von zehntausenden sagen kann). Aus irgendeinem Grund gab es unerwartete Spitzen bei der Anzahl der Verbindungen.<\/b>, jedoch beobachteten wir keine Korrelation mit den eingehenden Anfragen.<\/p>\n

Diesmal haben wir uns entschieden, die Quelle des Problems zu finden und zu beheben, anstatt uns mit einem Neustart zufriedenzugeben. Im Quay-Code Es wurden \u00c4nderungen vorgenommen, die die Anzahl der Datenbankverbindungen f\u00fcr jeden Worker begrenzen.<\/b> gevent. Diese Zahl wurde zu einem Parameter in der Konfiguration: Es ist nun m\u00f6glich, ihn \u201eon-the-fly\u201c zu \u00e4ndern, ohne ein neues Container-Image zu erstellen. Um herauszufinden, wie viele Verbindungen tats\u00e4chlich verarbeitet werden k\u00f6nnen, wurden mehrere Tests in einer Staging-Umgebung durchgef\u00fchrt, bei denen verschiedene Werte gesetzt wurden, um zu sehen, wie sich dies auf die Lasttestszenarien auswirken w\u00fcrde. Am Ende stellte sich heraus, dass Quay anf\u00e4ngt, 502-Fehler auszugeben, wenn die Anzahl der Verbindungen 10.000 \u00fcberschreitet.<\/b><\/p>\n

Wir haben diese neue Version sofort in der Produktion ausgerollt und begannen, die Verbindungsstatistiken zur Datenbank zu \u00fcberwachen. Fr\u00fcher wurde die Datenbank nach ungef\u00e4hr 20 Minuten blockiert. Nach 30 problemlosen Minuten hatten wir Hoffnung, und nach einer Stunde \u2014 Zuversicht. Wir haben den Schreibverkehr auf der Website wiederhergestellt und mit der Postmortem-Analyse begonnen.<\/p>\n

Nachdem wir das Problem umgangen haben, haben wir seine wahren Ursachen nicht herausgefunden.<\/b>Es wurde best\u00e4tigt, dass es nicht mit \u00c4nderungen in OpenShift 4.3.19 zusammenhing, da dasselbe auch bei Version 4.3.18 auftrat, die zuvor ohne Probleme mit Quay funktionierte.<\/p>\n

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

Eine detaillierte Untersuchung<\/h2>\n

\nQuay.io hat sechs Jahre lang die Standardkonfiguration f\u00fcr die Verbindung zur Datenbank ohne irgendwelche Probleme genutzt. Was hat sich ge\u00e4ndert? Es ist offensichtlich, dass der Traffic auf quay.io w\u00e4hrend dieser ganzen Zeit stetig gewachsen ist. In unserem Fall sah es so aus, als ob ein gewisser Grenzwert erreicht wurde, der einen Anstieg der Verbindungen ausgel\u00f6st hat. Wir haben weiterhin die Datenbankprotokolle nach dem zweiten Ausfall untersucht, konnten jedoch keine Muster oder offensichtlichen Zusammenh\u00e4nge feststellen.<\/p>\n

In der Zwischenzeit arbeitete das SRE-Team an Verbesserungen im Bereich der Sichtbarkeit von Anfragen bei Quay sowie der allgemeinen Gesundheit des Dienstes. Es wurden neue Metriken und Dashboards bereitgestellt<\/b>, die zeigen, welche Teile von Quay bei den Kunden am meisten nachgefragt werden.<\/p>\n

Quay.io funktionierte bis zum 9. Juni normal. Am Morgen (nach EDT) wurden wir erneut Zeugen eines erheblichen Anstiegs der Verbindungen zur Datenbank. Dieses Mal gab es keinen Ausfall.<\/b>, da die neue Einstellung ihre Anzahl einschr\u00e4nkte und eine \u00dcberschreitung der MySQL-Bandbreite verhinderte. Nach etwa einer halben Stunde berichteten viele Benutzer von langsamen Ladezeiten auf quay.io. Wir sammelten schnell alle verf\u00fcgbaren Daten, indem wir die neu hinzugef\u00fcgten \u00dcberwachungswerkzeuge verwendeten. Pl\u00f6tzlich trat ein Muster auf.<\/p>\n

Kurz vor dem Anstieg der Verbindungsanzahl gab es eine F\u00fclle von Anfragen an die App Registry API.<\/b>. Die App Registry ist eine weniger bekannte Funktion von quay.io. Sie erm\u00f6glicht das Speichern von Elementen wie Helm-Charts und Containern mit umfangreichen Metadaten. Die meisten Benutzer von quay.io nutzen diese Funktion nicht, jedoch wird sie aktiv von Red Hat OpenShift verwendet. OperatorHub im Rahmen von OpenShift speichert alle Operatoren in der App Registry. Diese Operatoren bilden die Grundlage f\u00fcr das \u00d6kosystem der Arbeitslasten von OpenShift und das Betriebskonzept (im Rahmen der \u201eSecond-Day\u201c-Operationen), das sich an Partner orientiert.<\/p>\n

Jeder OpenShift 4-Cluster nutzt Operatoren aus dem integrierten OperatorHub zur Ver\u00f6ffentlichung eines Katalogs von verf\u00fcgbaren Operatoren zur Installation und zur Bereitstellung von Updates f\u00fcr bereits installierte. Mit der wachsenden Popularit\u00e4t von OpenShift 4 nahm auch die Anzahl der Cluster weltweit zu. Jeder dieser Cluster l\u00e4dt Inhalte von Operatoren, um den integrierten OperatorHub zu starten, wobei das App-Registry innerhalb von quay.io als Backend verwendet wird. Auf der Suche nach der Ursache des Problems haben wir \u00fcbersehen, dass mit dem allm\u00e4hlichen Anstieg der Beliebtheit von OpenShift auch die Belastung einer der selten genutzten Funktionen von quay.io zugenommen hat.<\/b>.<\/p>\n

Wir haben eine Analyse des Anforderungs-Traffics des App Registrys durchgef\u00fchrt und den Code des Registers \u00fcberpr\u00fcft. Dabei traten sofort M\u00e4ngel zutage, die dazu f\u00fchrten, dass die Datenbankanfragen suboptimal gebildet wurden. Bei geringer Belastung gab es keine Probleme, jedoch wurden sie bei steigender Last zur Quelle von Schwierigkeiten. Der App Registry hatte zwei problematische Endpunkte, die schlecht auf eine erh\u00f6hte Last reagierten: Der erste lieferte eine Liste aller Pakete im Repository, der zweite gab alle Blobs f\u00fcr ein Paket zur\u00fcck.<\/p>\n

Beseitigung der Ursachen<\/h2>\n

\nIn der gesamten n\u00e4chsten Woche haben wir an der Optimierung des App Registrys und seiner Umgebung gearbeitet. Dabei wurden offensichtlich ineffiziente SQL-Abfragen \u00fcberarbeitet, unn\u00f6tige Kommandoausspr\u00fcche beseitigt, die bei jedem Abruf von Blobs ausgef\u00fchrt wurden, und \u00fcberall dort, wo es m\u00f6glich war, Caching hinzugef\u00fcgt. ,<\/code> (dies wurde bei jedem Abruf von Blobs aktiviert), es wurde \u00fcberall, wo m\u00f6glich, Caching hinzugef\u00fcgt. Anschlie\u00dfend wurde umfangreiches Leistungstesting durchgef\u00fchrt und die Geschwindigkeit des App Registrys vor und nach den \u00c4nderungen verglichen.<\/p>\n

API-Anfragen, die zuvor bis zu einer halben Minute ben\u00f6tigten, werden jetzt in Millisekunden ausgef\u00fchrt.<\/b>. In der n\u00e4chsten Woche haben wir die \u00c4nderungen in der Produktion bereitgestellt, und seitdem funktioniert quay.io stabil. W\u00e4hrend dieser Zeit gab es mehrere pl\u00f6tzliche Verkehrsspitzen am Endpunkt des App Registrys, aber die durchgef\u00fchrten Verbesserungen haben Ausf\u00e4lle der Datenbank verhindert.<\/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 j\u00fcngsten Ausf\u00e4lle dazu beigetragen haben, quay.io zu verbessern. Wir haben einige wichtige Lektionen daraus gezogen, die wir gerne teilen m\u00f6chten:<\/p>\n

    \n
  1. Daten dar\u00fcber, wer und wie Ihr Dienst genutzt wird, sind niemals \u00fcberfl\u00fcssig.<\/b>. Da Quay \"einfach funktionierte\", hatten wir nie das Gef\u00fchl, Zeit mit der Optimierung des Verkehrs und der Lastensteuerung verbringen zu m\u00fcssen. Dies f\u00fchrte zu einem falschen Gef\u00fchl der Sicherheit, dass der Service unbegrenzt skalierbar sei.<\/li>\n
  2. Wenn der Service ausf\u00e4llt, hat die Wiederherstellung der Funktionalit\u00e4t oberste 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 Service nicht wiederherstellen. Dies f\u00fchrte zu einer Situation, in der wir Zeit mit der Analyse und Datensammlung verbringen mussten, in der Hoffnung, die Ursache zu finden \u2013 anstatt unsere gesamte Energie auf die Wiederherstellung der Funktionalit\u00e4t zu richten.<\/li>\n
  3. Bewerten Sie die Auswirkungen jeder Funktion des Services.<\/b>. Kunden haben das App Registry selten genutzt, weshalb es f\u00fcr unser Team nicht priorit\u00e4r war. Wenn bestimmte Funktionen eines Produkts kaum verwendet werden, tauchen deren Bugs selten auf und die Entwickler h\u00f6ren auf, den Code zu \u00fcberwachen. Es ist leicht, in die Irre zu glauben, dass es so sein sollte \u2013 bis pl\u00f6tzlich diese Funktion im Mittelpunkt eines gr\u00f6\u00dferen Vorfalls steht.<\/li>\n<\/ol>\n

    <\/p>\n

    Wie geht es weiter?<\/h2>\n

    \nDie Arbeiten zur Gew\u00e4hrleistung der Service-Stabilit\u00e4t ruhen nie und wir verbessern st\u00e4ndig unsere Leistungen. Die Traffic-Mengen auf quay.io wachsen weiterhin und wir sind uns bewusst, dass wir alles tun m\u00fcssen, um das Vertrauen der Kunden zu rechtfertigen. Daher arbeiten wir derzeit an folgenden Aufgaben:<\/p>\n

      \n
    1. Bereitstellung von nur lesenden Datenbank-Repliken, um dem Service zu helfen, den entsprechenden Traffic im Falle von Problemen mit der Hauptinstanz RDS zu verarbeiten.<\/li>\n
    2. Aktualisierung der RDS-Instanz. Die aktuelle Version stellt an sich kein Problem dar. Vielmehr m\u00f6chten wir einfach einen falschen Hinweis beseitigen (dem wir w\u00e4hrend des Ausfalls gefolgt sind); das Halten der Software auf dem neuesten Stand wird einen weiteren Faktor f\u00fcr zuk\u00fcnftige Ausf\u00e4lle beseitigen.<\/li>\n
    3. Zus\u00e4tzliches Caching im gesamten Cluster. Wir suchen weiterhin nach Bereichen, in denen Caching die Last auf die Datenbank reduzieren kann.<\/li>\n
    4. Hinzuf\u00fcgen einer Webanwendungs-Firewall (WAF), um zu sehen, wer sich bei quay.io anmeldet und warum.<\/li>\n
    5. Ab der n\u00e4chsten Version werden die Red Hat OpenShift-Cluster auf Kataloge von Operatoren (Operator Catalogs) umsteigen und den App Registry zugunsten von Container-basierten Images, die auf quay.io verf\u00fcgbar sind, aufgeben.<\/li>\n
    6. Langfristig k\u00f6nnte die Unterst\u00fctzung der Spezifikationen der Open Container Initiative (OCI) die App Registry ersetzen. Derzeit wird sie als native Funktion von Quay umgesetzt und wird den Nutzern zur Verf\u00fcgung stehen, wenn die Spezifikation endg\u00fcltig genehmigt ist.<\/li>\n<\/ol>\n

      \nAll diese Ma\u00dfnahmen sind Teil der anhaltenden Investitionen von Red Hat in quay.io, w\u00e4hrend wir uns von einem kleinen, 'startup-artigen' Team zu einer ausgereiften SRE-gemanagten Plattform entwickeln. Wir wissen, dass viele unserer Kunden auf quay.io f\u00fcr ihre t\u00e4glichen Aufgaben angewiesen sind (einschlie\u00dflich Red Hat!) und bem\u00fchen uns, so transparent wie m\u00f6glich \u00fcber k\u00fcrzliche Ausf\u00e4lle und unsere laufenden Bem\u00fchungen um Verbesserung zu sein.<\/p>\n

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

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