Railway schildert GCP-Ausfall und entscheidet sich für den Abschied von Google Cloud

 (blog.railway.app)
1 Punkte von GN⁺ 2023-12-04 | 1 Kommentare | Auf WhatsApp teilen
  • Railway erlebte beim Betrieb seiner auf Google Cloud basierenden Plattform einen Vorfall, bei dem einige Maschinen in us-west nacheinander ausfielen und das automatische Failover scheiterte, sodass zur Wiederherstellung der Benutzer-Workloads manuelle Maßnahmen nötig waren
  • Einzelne Instanzen waren im Rolling-Verfahren jeweils etwa 10 Minuten offline, der Vorfall begann um 16:40 UTC, und um 20:53 UTC waren alle Workload-Failovers und die Service-Wiederherstellung abgeschlossen
  • Railway hatte in den vorangegangenen 18 Monaten mit instabilem Networking, einer Reduzierung der Artifact-Registry-Quota und Problemen beim Support zu kämpfen und baute deshalb einen eigenen Netzwerk-Stack sowie eine eigene Registry auf
  • Im Verlauf der Untersuchung wurden CPU soft lockup sowie Stack-Traces mit kvm_wait und __pv_queued_spin_lock_slowpath festgestellt; Railway hält eine Interaktion zwischen GCP-Gast und Hypervisor für die wahrscheinlichste Ursache
  • Railway hat entschieden, die Google-Cloud-Dienste zu beenden und auf eigene Bare-Metal-Instanzen zu migrieren; die erste Instanz ist bereits in Betrieb, die vollständige Migration ist für 2024 geplant

Rolling-Ausfall in us-west

  • Railway betreibt seine Plattform für die Anwendungsentwicklung auf Produkten der Google Cloud Platform wie Google Compute Engine
  • Ab dem 1. Dezember 2023 um 16:40 UTC wurden einige Maschinen der us-west-Flotte nacheinander nicht mehr erreichbar
    • Einzelne Instanzen waren jeweils etwa 10 Minuten offline
    • Der Ausfall setzte sich in rollender Form fort
    • Das automatische Failover griff nicht, daher war ein manuelles Failover nötig
  • Um 20:53 UTC waren alle Workloads erfolgreich per Failover umgestellt und der Dienst wiederhergestellt
  • Nach der Untersuchung kam Railway zu dem Schluss, dass eine Interaktion im Zusammenhang mit der Speicherübertragung von Userspace zum Kernel im GCP-Gast unter Ressourcenstress in seltenen Fällen einen Softlock auslösen kann

Über 18 Monate angesammelte Google-Cloud-Probleme

  • Railway hatte in den vergangenen 18 Monaten mehrere betriebliche Probleme im Zusammenhang mit Google Cloud

  • Instabiles Networking

    • 2022 kam es in Google-Cloud-Produkten zu anhaltenden Netzwerkunterbrechungen
    • Nach mehreren Eskalationen an Google baute Railway einen eigenen Netzwerk-Stack auf
    • Dieser eigene Stack ist ein resilienter eBPF/IPv6-WireGuard-Netzwerkstack und trägt heute alle Deployments
    • Danach verschwanden die Netzwerkprobleme

  • Artifact-Registry-Quota

    • Railway zufolge reduzierte Google 2023 die Quota der Artifact Registry willkürlich faktisch auf nahezu 0
    • Dadurch sank der Durchsatz bei der Image-Bereitstellung stark, und Builds verzögerten sich
    • Daraufhin entwickelte Railway ein eigenes Registry-Produkt, womit auch die Durchsatzprobleme der Registry verschwanden

Support-Reaktion und Entscheidung für den Wechsel zu Bare Metal

  • Railway zahlte Google Cloud mehrere Millionen Dollar pro Jahr, hatte nach eigener Einschätzung aber keine angemessene Reaktion erhalten, obwohl Maßnahmen von Google Auswirkungen auf die Workloads von Railway und anderen Kunden hatten
  • Nachdem der Gründer das Problem auf X gepostet hatte, nahm Google Kontakt auf, und Railway besprach die Ursache mit Google-Vizepräsidenten
  • Laut Railway konnte ein Google-Ingenieur GCP-Quotas willkürlich ändern
    • Die Google-Vizepräsidenten hätten zugestimmt, dass dies nicht akzeptabel sei
    • Auch nach Juni forderte Railway weiterhin einen Rückblick, eine offizielle Antwort und Richtlinien gegen willkürliche Quota-Änderungen
  • Im Zuge dessen änderte Google laut Railway ohne vorherige Warnung die ToS, wodurch die Kosten von Railway um 20% stiegen
    • Google habe zugesagt, auch auf dieses Problem zu antworten, doch Railway habe bis heute keine Antwort erhalten
  • Railway traf im vergangenen Quartal intern die Entscheidung, alle Google-Cloud-Dienste einzustellen und auf eigene Bare-Metal-Instanzen umzuziehen
    • Die erste Bare-Metal-Instanz ging vor einigen Wochen in Betrieb
    • Die vollständige Migration aller Instanzen soll 2024 erfolgen

Verlauf des Ausfalls am 30. November und 1. Dezember

  • Am 30. November 2023 um 21:41 UTC startete Google eine Maschine neu, wodurch eine Box offline ging
    • Railway verfügt über ein automatisches System, das solche Situationen erkennt und behebt
    • Für diese Box erfolgte das Failover ordnungsgemäß, und es wurde keine Alarmseite ausgelöst
  • Am 1. Dezember 2023 um 16:52 UTC ging eine Box unerreichbar offline
    • Auch nach dem automatischen Failover kam es zu keiner normalen Wiederherstellung
    • Der primäre On-Call-Ingenieur wurde alarmiert, und während der Untersuchung gingen weitere Boxen offline und erholten sich nicht
  • Railway begann, die Boxen manuell per Failover umzuschalten
    • Pro Host kam es zu etwa 10 Minuten Ausfallzeit
    • Bald waren rund 12 Boxen betroffen, und etwa die Hälfte der Belegschaft arbeitete anhand des Runbooks an der Reaktion
  • Wegen serieller Log-Muster, die der automatischen Live-Migration von Google Cloud ähnelten, nahm man zunächst an, ein routinemäßiger Neustart von Google sei schiefgelaufen
    • Eine E-Mail an den zuständigen Ansprechpartner bei Google führte jedoch nur zu einer sofortigen Abwesenheitsnotiz

Hinweise aus den Serial-Console-Logs

  • Railway prüfte zuerst die Serial-Console-Logs
    • Diese Logs kommen direkt aus dem Kernel über ein virtualisiertes serielles Gerät
  • In den Logs erschienen ein soft-gelockter CPU-Kern sowie Stack-Traces der blockierten CPU
    • Beispielhafte Einträge waren kvm_wait und __pv_queued_spin_lock_slowpath
  • Solche Logs und ein solches Verhalten hatte Railway zuletzt im Dezember des Vorjahres gesehen, als Google Neustarts einleitete
    • Damals traten bei drei Boxen dieselben Muster auf
  • Bei weiteren Untersuchungen fand man Kernel-Fehler, die zu Threads über Nested Kernel Virtualization auf GCP und Soft Lockups passten
  • Da Railway auf den betroffenen Hosts keine eigene Virtualisierung einsetzte, wertete das Unternehmen die Meldungen zu kvm und Paravirtualisierung als Signal für Gast-Kernel-Code, der mit dem GCP-Hypervisor interagiert
  • GCP scheint ähnliche Probleme als nicht reproduzierbar behandelt zu haben, doch Railway ist stark überzeugt, dass der aktuelle Vorfall derselben Kategorie angehört

Vermutete Ursache und Gegenmaßnahmen

  • Railway geht davon aus, dass es bei der Speicherübertragung von Userspace zum Kernel im GCP-Gast eine potenziell fatale Interaktion gibt, die unter seltenem Ressourcenstress einen Softlock auslöst
  • Genauer vermutet Railway einen Zusammenhang mit paravirtualisiertem Speichermanagement und der Art, wie Seiten im Hypervisor gemappt und neu gemappt werden, unter bestimmten Ressourcenstress-Situationen
  • Als weiteres gemeinsames Merkmal sieht Railway, dass nahezu alle ähnlichen Berichte von GCP-Nutzern kamen
  • Auch der Umstand, dass Google den Großteil der MMIO-Befehle im Userspace verarbeitet, passt zu dieser Vermutung von Railway
  • Falls diese Einschätzung zutrifft, könnten Boxen aufgrund nicht offengelegter Rate-Limits, Schwellenwerte oder Bedingungen in einen Softlock geraten, selbst wenn CPU-, Speicher- und IOPS-Metriken unter den beobachtbaren Grenzwerten liegen
    • Die betroffenen Maschinen lagen damals bei etwa 50% der veröffentlichten Ressourcenlimits
  • Nach einem manuellen Neustart deaktivierte Railway einige interne Dienste, um den Ressourcenstress auf den betroffenen Instanzen zu senken; danach stabilisierten sich die Instanzen

Auswirkungen auf die Nutzer

  • Während des manuellen Failovers kam es pro Maschine zu 10 Minuten Ausfallzeit
  • Da mehrere Nutzer Workloads mit mehreren Diensten ausführten, konnte sich die Ausfallzeit mehrfach aufsummieren, wenn die Boxen nacheinander offline gingen
  • Railway entschuldigte sich bei den Nutzern und erklärte, zur Erhöhung der Zuverlässigkeit auf eigenes Bare Metal umzuziehen

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2023-12-04
Meinungen auf Hacker News

  • Wir sind eine kleine Softwarefirma mit zwei Leuten, und auch wir hatten über Jahre hinweg viele Probleme mit Google wegen Google Adwords. Zum Beispiel:
    https://successfulsoftware.net/2015/03/04/google-bans-hyperl...
    https://successfulsoftware.net/2016/12/05/google-cpa-bidding...
    https://successfulsoftware.net/2020/08/21/google-ads-can-cha...
    https://successfulsoftware.net/2021/05/04/wtf-google-ads/
    Wenn sie nicht einmal bereit sind, dem Autor des Originalbeitrags, der Google enorme Summen zahlt, ordentlichen Support zu bieten, frage ich mich, welche Hoffnung es dann für kleine Unternehmen wie uns gibt.

  • Insgesamt habe ich den Eindruck, dass GCP in den letzten Jahren die Richtung verloren hat. Noch vor ein paar Jahren war es bei Preis/Leistung für Compute, Storage und Bandbreite eine deutlich bessere Option als AWS; das hatten wir für unsere Workloads sogar mit detaillierten Performance-Tests und Kostenmodellierung bestätigt.
    Auch der Support war damals hervorragend. Ein Ticket zu einem anfangs unklaren Netzwerkproblem wurde schnell eskaliert, von Engineers in mehreren Regionen übernommen und gelöst; am Ende wurde eine Änderung auf GCP-Seite zurückgerollt. Auch der Sales-Ansprechpartner hat schnell interne Ressourcen vermittelt, was die Gesamterfahrung positiv gemacht hat.
    Inzwischen hat AWS bei der Preis/Leistung klar aufgeholt und ist bei mehreren Managed Services weiterhin Jahre voraus. Der GCP-Support hingegen ist deutlich schlechter geworden und scheint meist bei externen Support-Anbietern zu landen; deren Einblick in die tatsächliche GCP-Infrastruktur wirkt kaum besser als unserer.
    Auch die Sales-Erfahrung ist viel schlechter geworden, und unser aktueller Ansprechpartner ist eindeutig ein Minuspunkt. Wir haben stark in GCP investiert, sehen aber keine Anzeichen für Besserung, arbeiten daher aktiv daran, unsere GCP-Ausgaben zu reduzieren, und obwohl ich früher ein GCP-Befürworter war, kann ich heute kaum noch empfehlen, neue Projekte auf GCP zu starten.

  • Es stimmt schon, dass alle Cloud-Anbieter Probleme haben. In den letzten zwei Jahren habe ich beruflich mehrere Probleme mit Keyspaces, Amazon Aurora und App Runner gefunden und gemeldet, die alle zu Performance-Einbußen führten, und der AWS-Support hat uns Zeit damit verschwenden lassen, an den falschen Stellen zu graben.
    Erst nach wochenlanger Eskalation haben die Projektverantwortlichen die Probleme eingeräumt; einige davon waren bereits bekannt, trotzdem hat das Support-Team uns Zeit vergeuden lassen. Im Moment sind wir zwar an Keyspaces gebunden, aber künftig will ich nichts mehr nutzen, was nicht zu den Kernservices wie EC2, EBS oder S3 gehört. Darüber hinaus wird es riskant.

    • Genau so ist es. Etwa die Hälfte der AWS-Services scheint schlecht designt, schlecht betrieben oder beides zu sein. CloudWatch ist besonders fehleranfällig und langsam und wirkt im Grunde wie eine Anfängerfalle.
      Wenn ich sehe, dass ein Unternehmen CloudWatch für alle Logs nutzt, vermute ich, dass das aus mangelnder Erfahrung und Unkenntnis der vielen Alternativen passiert. Die Compute-Services sind allerdings verlässlich.

  • Es ist absurd, GCP dafür zu kritisieren, dass eine Compute-Instanz ausgefallen ist. Der Autor des Originalbeitrags räumt selbst ein, dass das ein seltenes Ereignis war; bei AWS habe ich dagegen oft erlebt, dass Instanzen zwangsweise gestoppt wurden oder ganz verschwanden. 99,95 % Haltbarkeit und 99,999 % sind ein großer Unterschied.
    Hätte man dieselbe Architektur auf AWS betrieben, hätte es meiner Erfahrung nach ständig Ausfälle gegeben. Laut AWS-Dokumentation und meiner Erfahrung sind die grundlegenden Bausteine von AWS deutlich weniger stabil als die von GCP.

    • Der Artikel scheint AWS nicht wirklich zu behandeln. Das Kernproblem war wohl auch nicht, dass eine einzelne Instanz ausgefallen ist, sondern der Mangel an Kommunikation und Support selbst gegenüber einem großen Unternehmenskunden.
      Sie scheinen auf Bare Metal umziehen zu wollen, was den klaren Vorteil hat, dass man dem On-Call-Engineer direkt sagen kann, er solle es irgendwie reparieren.
    • Die SLAs von EC2 und GCP Compute liegen beide exakt bei 99,99 %; darunter gibt es 10 % Rückerstattung, unter 95 % gibt es 100 % Rückerstattung.
      [0] https://aws.amazon.com/compute/sla/
      [1] https://cloud.google.com/compute/sla
    • Das unterscheidet sich stark von meiner Erfahrung. In mehreren Jahren mit AWS wurde eine Instanz bei mir nur ein einziges Mal wegen irgendeines merkwürdigen AWS-Hintergrundjobs gestoppt, der nichts mit der Anwendung zu tun hatte; dass eine Instanz einfach verschwunden wäre, habe ich weder erlebt noch, soweit ich mich erinnere, je gehört.
    • In der Cloud sollte man seine Architektur im Allgemeinen, wie jemand sagte, unter der Annahme bauen, dass alles jederzeit ausfällt.

  • Ich hatte viele Interaktionen mit Google Cloud Support, insbesondere zu Managed Services, und ehrlich gesagt war das im Vergleich zu ähnlich großen AWS-Umgebungen, in denen die Support-Erfahrung immer hervorragend war, nicht besonders beeindruckend.
    Wenn einem bei Google Cloud aber wirklich jemand gut geholfen hat, sollte man das deutlich loben. Gerade weil das selten ist, ist es kein großer Aufwand, dafür mit stark positivem Feedback zu sorgen, dass die Person belohnt wird. Ich hatte selbst vier wirklich hervorragende Erfahrungen und habe jedes Mal sofort unserem TAM geschrieben. Ich hoffe, dass solche Leute belohnt und befördert werden.

    • Stimmt. Solche Diskussionen können leicht wie vi/emacs-Debatten ablaufen, und auf die HN-Startseite schaffen es meist nur Beschwerden.
      Ich habe GCP etwa zehn Jahre lang immer wieder für Projekte genutzt und darauf auch mehrere erfolgreiche Unternehmen aufgebaut. Perfekt war es nicht, aber insgesamt bin ich zufrieden.
      Umgekehrt habe ich in dem Team, das eine frühe gehostete Version von Cloud Foundry gebaut hat, intensiv AWS genutzt, und dorthin möchte ich nicht zurück. Es war ein endloses Durcheinander.

  • In GCP war einmal eine sehr enterprise-mäßige Funktion kaputt, und es wurde klar, dass diese Funktion bis zu diesem Zeitpunkt nie korrekt funktioniert hatte. Beim Versuch, das stillschweigend zu beheben, verursachten sie auch Downtime, und die GCP-Ansprechpartner erinnerten in einem Call, in dem sie die Ursache erklären sollten, immer wieder nur daran, dass alle unter NDA standen.
    Hätten sie diese Tatsache eingeräumt, wäre das für regulierte Branchen ein Albtraum gewesen.

    • Ich frage mich immer, ob eine NDA einen wirklich daran hindern kann, mit Aufsichtsbehörden, Polizei, Staatsanwaltschaft oder echten staatlichen Stellen zu sprechen oder Whistleblowing zu betreiben. Ich würde gern davon ausgehen, dass man Straftaten jederzeit melden können muss.

  • „Am 1. Dezember um 8:52 Uhr PST ging eine Box offline und war nicht mehr erreichbar. Nach einem Failover hätte sie automatisch zurückkommen sollen, tat es aber nicht. Während der primäre On-Call-Engineer alarmiert wurde und untersuchte, ging eine weitere Box offline und kam ebenfalls nicht zurück.“
    Das ergibt keinen Sinn. Eine Maschine wurde neu gestartet und es kam zu einem katastrophalen Ausfall? VMs rebooten gelegentlich. Wenn die gesamte Konfiguration in diesem Szenario so entworfen ist, dass sie von selbst zusammenbricht, wäre ich damit auch nicht zufrieden, egal ob man zu AWS umzieht oder sogar eigenes Colocation nutzt.

    • Du solltest den Beitrag genauer lesen. Auch in der von dir zitierten Passage steht nicht, dass die Maschine „neu gestartet“ wurde, sondern dass sie nach einem Crash nicht wieder online kam.
      Und nirgends im Beitrag steht, dass es sich um einen „katastrophalen Ausfall“ gehandelt habe. Railway war nicht komplett down, aber Railway ist ein Deployment-Unternehmen und verkauft Compute-Ressourcen weiter, auf denen Kundenanwendungen deployt werden. Wenn also eine VM ausfällt und das automatische Failover nicht funktioniert, bedeutet das für die jeweiligen Kunden, deren Dienste auf dieser Maschine liefen, Downtime.
      Im Beitrag steht auch: „Während wir diese Maschinen manuell failoverten, gab es 10 Minuten Downtime pro Host. Da viele Nutzer Multi-Service-Workloads betreiben, kann sich diese Downtime vervielfachen, wenn die Boxen nacheinander offline gehen. Wir entschuldigen uns aufrichtig bei allen Nutzern.“

  • Interessanterweise bekomme ich langsam den Eindruck, dass es bei GCP ziemlich häufig undokumentierte Schwellenwerte gibt.
    Bei Cloud Run habe ich etwas Ähnliches erlebt. Es gab Scaling-Events, die sich nicht durch die in der Dokumentation genannten Kriterien CPU-Auslastung und Anzahl gleichzeitiger Requests erklären ließen, mit denen das Scaling gesteuert wird.
    Nach langem Hin und Her mit dem kostenpflichtigen Support erfuhr ich, dass es ein zusätzliches Kriterium im Zusammenhang mit der Request-Dauer gibt, aber natürlich konnte niemand es im Detail erklären.

  • Das klingt nach einer wirklich frustrierenden Erfahrung. Allerdings ist mir etwas unklar, was Nested Virtualization mit diesem Problem zu tun hat, wenn man innerhalb der VM keine Virtualisierung nutzt. Ein Soft Lockup ist im Allgemeinen ein recht allgemeines Signal dafür, dass kein Fortschritt mehr passiert.
    Der Kommentar zu MMIO-Instruktionen ist ähnlich verwirrend. Wenn es um Instruction Emulation geht, sehe ich nicht, warum relevant ist, wo sie stattfindet. Sie ist ohnehin langsam und wird in den Userspace ausgelagert sein; wenn etwas schnell laufen muss, sollte es praktisch keine Exits aus dem Guest geben, und Emulation erst recht nicht.
    Es wirkt so, als sei der Autor frustriert und versuche, bei den jüngsten Vorfällen an allem festzuhalten, was halbwegs verständlich ist, um eine Ursache zu finden.

  • „2022 hatten wir bei einem Google-Cloud-Produkt anhaltende kurze Netzwerkaussetzer. Nachdem wir mehrfach bei Google eskaliert hatten, waren wir es leid und bauten unseren eigenen Networking-Stack: ein elastisches eBPF/IPv6-WireGuard-Netzwerk, das alle Deployments antreibt. Daraufhin verschwanden die Netzwerkprobleme plötzlich.“
    Soweit ich es verstehe, ist das Netzwerk für VMs ein VLAN, das in Switches programmiert wird, und wenn man eine VPC erstellt, erzeugt man vermutlich ein VLAN. Wenn das zugrunde liegende Netzwerk instabil ist, frage ich mich, wie ein Overlay wie UDP/WireGuard stabiler sein kann.
    Nebenbei: Wäre bei so einem Kunden auf AWS auch nur ein Zehntel dieses Problems aufgetreten, hätte eine Armee von Solution Architects alle zwei Wochen in einem Meetingraum gesessen, die Architektur geprüft und Support Engineers in die Calls geholt.

    • Es wird nicht ein Switch programmiert, um ein VLAN zu erstellen; das läuft alles über ein Overlay-Netzwerk.
      Das Material ist zwar älter, hilft aber, ein Gefühl dafür zu bekommen: https://www.usenix.org/conference/nsdi18/presentation/dalton
    • Meine Vermutung wäre, dass Googles clevere Netzwerkoptimierungen mit deren Traffic kollidierten.
      Durch den eigenen Networking-Stack haben sie solche Optimierungen umgangen, und WireGuard ist im Kern auf unzuverlässigem UDP aufgebaut, sodass es mit sporadischen Ausfällen möglicherweise besser umgehen konnte.