ZooKeeper ist ein bekanntes Open-Source-Projekt, das hochzuverlässige verteilte Koordination ermöglicht. Es genießt weltweit großes Vertrauen, unter anderem bei PagerDuty. Hohe Verfügbarkeit und Linearisierbarkeit werden durch das Konzept eines Leaders gewährleistet, der dynamisch neu gewählt werden kann. Konsistenz wird durch ein Mehrheitsquorum sichergestellt.

Die Mechanismen zur Leader-Wahl und Fehlererkennung sind recht ausgereift und funktionieren normalerweise einwandfrei … bis sie es eben nicht mehr tun. Wie kann das sein? Nach eingehender Untersuchung konnten wir vier verschiedene Fehler aufdecken, die gemeinsam zu zufälligen, clusterweiten Abstürzen führten. Zwei dieser Fehler lagen in ZooKeeper, die anderen beiden im Linux-Kernel. Das ist unsere Geschichte.

Hintergrund: Die Verwendung von ZooKeeper bei PagerDuty

Bei PagerDuty nutzen wir mehrere unabhängige Dienste, die unsere Alarmierungskette steuern. Eingehende Ereignisse durchlaufen diese Dienste als eine Reihe von Aufgaben, die aus verschiedenen Warteschlangen abgearbeitet werden. Jeder dieser Dienste verwendet einen dedizierten ZooKeeper-Cluster, um zu koordinieren, welcher Anwendungshost welche Aufgabe verarbeitet. Daher ist der ZooKeeper-Betrieb absolut entscheidend für die Zuverlässigkeit von PagerDuty insgesamt.

Teil I: Die ZooKeeper-Bugs

Zu viele Kundensitzungen

Letztes Jahr bemerkte ein Techniker, dass einer der ZooKeeper-Cluster in unserer Lasttestumgebung defekt war. Dies äußerte sich in Timeouts der Sperre in der abhängigen Anwendung. Wir bestätigten, dass der Cluster erreichbar war und auf Anfragen wartete, aber irgendetwas stimmte nicht: Jeder Client hatte Dutzende aktive Sitzungen zu seinen jeweiligen ZooKeeper-Cluster-Mitgliedern. Normalerweise sind es nur zwei. Dadurch stießen wir an die Grenze der zulässigen Anzahl aktiver Sitzungen pro Knoten, und eine entsprechende Ausnahme wurde protokolliert.

Wie konnte der Kunde nur so ungeschickt sein? Vielleicht gab es einen Fehler im System. ZooKeeper-Bibliothek Wir verwendeten damals die entsprechende Bibliothek. Ein Neustart des gesamten ZooKeeper-Clusters behob das Problem, doch wir hatten keine Möglichkeit mehr, es zu reproduzieren. Nach einiger Suche im Bibliothekscode konnten wir keine Bedingung finden, die einen Sitzungsstau verursachen könnte. Wir waren völlig ratlos, und das Schlimmste war, dass wir keine Ahnung hatten, ob das Problem auch in der Produktionsumgebung auftreten könnte.

Fehler #1

Weniger als eine Woche später trat das Problem erneut in unserer Lasttestumgebung auf. Diesmal war ein anderer ZooKeeper-Cluster betroffen, und zwar während einer Phase mit hoher Last. Wir stellten fest, dass wir das Problem reproduzieren konnten, indem wir synthetische Last erzeugten und ein bis zwei Stunden warteten.

Wir stellten fest, dass die Sitzungsanzahl auf allen ZooKeeper-Knoten linear anstieg. Daraus schlossen wir, dass selbst bei einem Client-Problem wahrscheinlich eine Bedingung in ZooKeeper dieses Verhalten auslöst. Wir begannen, die ZooKeeper-Protokolle genauer zu untersuchen. Nach einiger Zeit fanden wir etwas vielversprechendes im Protokoll des Leaders:

 java.lang.OutOfMemoryError: Java-Heap-Speicherplatz erschöpft in org.apache.jute.BinaryInputArchive.readString(BinaryInputArchive.java:81) in org.apache.zookeeper.data.Id.deserialize(Id.java:54) in org.apache.jute.BinaryInputArchive.readRecord(BinaryInputArchive.java:108) in org.apache.zookeeper.data.ACL.deserialize(ACL.java:56) in org.apache.jute.BinaryInputArchive.readRecord(BinaryInputArchive.java:108) in org.apache.zookeeper.proto.CreateRequest.deserialize(CreateRequest.java:91) ... 

Bei der Analyse des Stacktraces fanden wir Folgendes: scheme=a_.readString('scheme'); Hm. Nun ja, das ZooKeeper-Protokoll hat vier Bytes. Schema-Länge Das Feld… möglicherweise berechnet der Client den Wert falsch. Ungeachtet dessen legt das Protokoll eine maximale Größe für das Schema fest. Leider findet keine Bereichsprüfung für dieses Feld statt.

Nach unzähligen Paketmitschnitten konnten wir ein einzelnes problematisches Paket finden. Es enthielt ein Schema-Länge von 0x6edd0b51 … oder etwa 1,7 GB. Da keine Bereichsprüfung stattfand, versuchte ZooKeeper, Speicher für die falsche Länge zu reservieren, was eine OutOfMemory-Ausnahme auslöste und den Thread beendete. Toll. Naja, nicht ganz so toll, aber wir kommen der Sache langsam näher. Es gibt noch viele offene Fragen, aber das wichtigste Problem ist klar: Wenn der Leader nicht mehr existiert, warum wird er nicht neu gewählt?

Fehler #2

Es stellte sich heraus, dass ZooKeeper unbehandelte Ausnahmen seiner kritischen Threads nicht abfing, was bedeutete, dass der ZooKeeper-Prozess abstürzen würde, wenn einer dieser Threads ausfiele. ohne es weiterlaufen Das bedeutet leider auch, dass die Herzschlagmechanismen weiterhin funktionieren würden und die Anhänger fälschlicherweise glauben ließen, der Anführer sei gesund. Schema-Länge Wird die Anfrage vom Request-Preprozessor-Thread verarbeitet (durch den alle Anfragen laufen müssen), wird der gesamte Cluster praktisch katatonisch – scheinbar aktiv, aber weitgehend unreagierbar.

Wir haben Prozessüberwachung mit zk-spezifischen Integritätsprüfungen eingerichtet. Aufgrund der Art des Fehlers wurden diese Prüfungen jedoch weiterhin (ärgerlicherweise) erfolgreich bestanden. Der Thread stürzte also auf dem Leader ab und blockierte alle nachfolgenden Operationen, während er gleichzeitig mehrere Fehlererkennungsmechanismen umging. Letztendlich haben wir festgestellt, dass wir einen gesamten ZooKeeper-Cluster mit einem einzigen fehlerhaften Paket lahmlegen können. Was?

Teil II: Die Kernel-Bugs

TCP-Nutzdatenbeschädigung

Jetzt verstehen wir die Probleme mit ZooKeeper, aber eine viel größere Frage bleibt: Wie kommt es, dass wir solche Werte für … sehen? Schema-Länge Beim Dekodieren des Pakets konnten wir sehen, dass es nicht nur Schema-Länge Das war zwar betroffen, aber ein ganzer 16-Byte-Block schien beschädigt zu sein. Hier ist ein Ausschnitt des ersten fehlerhaften Pakets, das wir gefunden haben:

 0170 00 00 00 03 00 00 00 b6 00 03 2a 67 00 00 00 01 ..........*g.... 0180 00 00 00 7e 2f 47 65 6d 69 6e 69 2f 63 6f 6d 2e ...~/Gemini/com. 0190 70 61 67 65 72 64 75 74 79 2e 77 6f 72 6b 71 75 pagerduty.workqu 01a0 65 75 65 2e 53 69 6d 70 6c 65 51 75 65 75 65 61 eue.SimpleQueuea 01b0 62 6c 65 2f 52 45 44 41 43 54 45 44 5f 52 45 44 ble/REDACTED_RED 01c0 41 43 54 45 44 5f 52 45 44 41 43 54 45 44 5f 52 ACTED_REDACTED_R 01d0 45 44 41 43 2f 5f 63 5f 35 66 62 65 61 34 37 62 EDAC/_c_5fbea47b 01e0 2d 61 65 62 31 2d 34 36 62 35 2d 62 32 32 33 2d -aeb1-46b5-b223- 01f0 38 65 34 65 31 37 38 34 32 31 34 39 2d 6c 6f 63 8e4e17842149-loc 0200 6b 2d 00 00 00 09 31 32 37 2e 30 2e 30 2e 31 00 k-....127.0.0.1. 0210 7c 0e 5b 86 df f3 fc 6e dd 0b 51 dd eb cb a1 a6 |.[....n..Q..... 0220 00 00 00 06 61 6e 79 6f 6e 65 00 00 00 03 ....anyone.... 

Die Beschädigung stimmt nicht mit den erwarteten Feldern des ZooKeeper-Protokolls überein, sondern mit 16-Byte-Grenzen innerhalb des Pakets selbst (beginnend bei Offset 0210). Angesichts dieser Information erscheint es nun sehr unwahrscheinlich, dass ZooKeeper etwas mit dem Fehler zu tun hat. Schema-Länge überhaupt keinen Wert.

Diese Aufzeichnung entstand, als das Paket an einem der ZooKeeper-Knoten vom Netzwerk kam. Anders ausgedrückt: Es war bereits beschädigt, als es ZooKeeper erreichte. Das bedeutet, dass entweder der Client das beschädigte Paket gesendet oder ein Netzwerkgerät es beschädigt haben muss. Normalerweise werden bei einer Beschädigung durch ein zwischengeschaltetes Gerät die Prüfsummen ungültig, und das empfangende System verwirft das Paket. Die TCP-Nutzdaten erreichten in diesem Fall eindeutig ZooKeeper, daher mussten die Prüfsummen alle korrekt sein … doch zu unserer großen Überraschung waren sie es nicht!

IPSec

Bevor wir fortfahren, ist es wichtig zu wissen, dass PagerDuty verwendet IPSec. In Transportmodus Um unseren gesamten Datenverkehr zwischen den Hosts zu sichern, verwenden wir eine VPN-Verschlüsselung. Vereinfacht gesagt, funktioniert sie im Prinzip wie ein herkömmliches IPSec-basiertes VPN, nur ohne VPN-Funktion. Die IP-Nutzdaten werden verschlüsselt, die IP-Header bleiben jedoch erhalten, sodass das Paket wie gewohnt durch das Netzwerk geleitet werden kann. Das Ergebnis ist eine VPN-ähnliche Verschlüsselung ohne die Notwendigkeit, einen separaten Adressraum zu verwalten. Zudem wird der Overhead verteilt, da jeder Host seinen eigenen Datenverkehr verschlüsselt und entschlüsselt.

Unser Einsatz dieser Technologie ist wichtig, da bisher alle analysierten Aufzeichnungen entschlüsselt wurden. Da die TCP-Header und die Nutzdaten innerhalb von IPSec verschlüsselt sind, die IP-Header jedoch nicht, bedeutet dies, dass wir außerhalb und innerhalb von IPSec jeweils eine Prüfsumme haben. Die erfolgreiche Entschlüsselung des Pakets beweist somit, dass es nach der Verschlüsselung nicht beschädigt wurde.

Unsere Untersuchung der Prüfsummen ergab, dass die IP-Prüfsumme gültig war, die TCP-Prüfsumme jedoch nicht. Dies ist nur möglich, wenn die Beschädigung auftrat. nach Der TCP-Frame wurde erstellt, aber vor Die IP-Header wurden generiert. Unabhängig davon, wie, warum und wo diese Beschädigung der TCP-Nutzdaten auftritt, sollte sie vom Empfänger unbedingt verworfen werden, da die TCP-Prüfsumme ungültig ist… was ist da los?

Fehler Nr. 3 – Unklares Verhalten

Zum jetzigen Zeitpunkt ist es nur sinnvoll, sich direkt an die Quelle zu wenden. Eine kurze Recherche im Linux-Quellcode fördert die folgenden Zeilen zutage, die im folgenden Verzeichnis verbleiben: Linux-Master-Branch Zum Zeitpunkt der Veröffentlichung dieses Textes:

 /* * 2) UDP/TCP-Prüfsummen im Fall von * NAT-T im Transportmodus ignorieren oder * andere Nachbearbeitungskorrekturen * gemäß draft-ietf-ipsec-udp-encaps-06, * Abschnitt 3.1.2 durchführen */ if (x->props.mode == XFRM_MODE_TRANSPORT) skb->ip_summed = CHECKSUM_UNNECESSARY; 

WUT!!! Es fühlt sich so falsch an – wie kann das richtig sein? RFC 3948 Die Geschichte wird erzählt. Darin heißt es, dass der Client bei Verwendung von IPSec im NAT-T-Transportmodus auf die Validierung der TCP/UDP-Prüfsumme verzichten KANN, da davon ausgegangen wird, dass die Paketintegrität bereits durch … geschützt ist. ESP Wer hätte gedacht, dass es einen Fall geben könnte, in dem man TCP-Prüfsummen nicht validiert? Die Annahme der Autoren ist falsch, da vor der ESP/IP-Bildung eindeutig ausreichend Gelegenheit für Datenverfälschungen besteht. Prüfsummen eignen sich zwar hervorragend, um Datenverfälschungen während der Übertragung zu erkennen, können aber auch zur Erkennung von Fehlern während der Paketbildung verwendet werden. Letzteres wurde übersehen, und diese Optimierung hat sich nun als Fehler erwiesen. Die fehlende Validierung ermöglichte es unserer mysteriösen Verfälschung, unentdeckt zu bleiben – und lieferte ZooKeeper fehlerhafte Daten, die er fälschlicherweise für durch TCP geschützt hielt. Wir gehen davon aus, dass es sich hierbei um einen Fehler handelt – ob beabsichtigt oder nicht.

Der Test

Im Laufe unserer Untersuchung stellten wir fest, dass die Reproduktion des Problems erstaunlich schwierig war, obwohl es uns gelegentlich gelang. Wir benötigten eine einfache Methode, um diese Datenbeschädigung zu erkennen und zu analysieren, ohne die Sache durch den Einsatz von ZooKeeper, die Entschlüsselung von Netzwerkaufzeichnungen usw. zu verkomplizieren. Nach einigen Versuchen entschieden wir uns für einen äußerst simplen Ansatz: die Verwendung von… netcat um Nullen von /dev/zero über das Kabel und senden Sie sie an xxd (ein Kommandozeilen-Hex-Tool). Jeder von Null verschiedene Wert, der gelesen wird von xxd Es handelt sich offensichtlich um Datenbeschädigung. So sehen einige unserer manipulierten TCP-Nutzdaten bei Anwendung dieses Ansatzes aus:

 -- evan@hostB:~ $ nc -l 8080 | xxd -a 0000000: 0000 0000 0000 0000 0000 0000 0000 ................ * 189edea0:0000 1e30 e75c a3ef ab8b 8723 781c a4eb ...0......#x... 189edeb0:6527 1e30 e75c a3ef ab8b 8723 781c a4eb e'.0......#x... 189edec0:6527 1e30 e75c a3ef ab8b 8723 781c a4eb e'.0......#x... 189eded0:6527 1e30 e75c a3ef ab8b 8723 781c a4eb e'.0......#x... 189edee0:6527 9d05 f655 6228 1366 5365 a932 2841 e'...Ub(.fSe.2(A 189edef0:2663 0000 0000 0000 0000 0000 0000 0000 &c............. 189edf00:0000 0000 0000 0000 0000 0000 0000 0000 ................ * 4927d4e0:5762 b190 5b5d db75 cb39 accd 5b73 982b Wb..[].u.9..[s.+ 4927d4f0:5762 b190 5b5d db75 cb39 accd 5b73 982b Wb..[].u.9..[s.+ 4927d500:5762 b190 5b5d db75 cb39 accd 5b73 982b Wb..[].u.9..[s.+ 4927d510:5762 b190 5b5d db75 cb39 accd 5b73 982b Wb..[].u.9..[s.+ 4927d520:01db 332d cf4b 3804 6f9c a5ad b9c8 0932 ..3-.K8.o......2 4927d530:0000 0000 0000 0000 0000 0000 0000 0000 ................ * 4bb51110:0000 54f8 a1cb 8f0d e916 80a2 0768 3bd3 ..T..........h;. 4bb51120:3794 54f8 a1cb 8f0d e916 80a2 0768 3bd3 7.T..........h;. 4bb51130:3794 54f8 a1cb 8f0d e916 80a2 0768 3bd3 7.T..........h;. 4bb51140:3794 54f8 a1cb 8f0d e916 80a2 0768 3bd3 7.T..........h;. 4bb51150:3794 20a0 1e44 ae70 25b7 7768 7d1d 38b1 7. ..Dp%.wh}.8. 4bb51160:8191 0000 0000 0000 0000 0000 0000 0000 ................ 4bb51170:0000 0000 0000 0000 0000 0000 0000 0000 ................ * 4de3d390:0000 0000 0000 ...... -- evan@hostB:~ $ 

Das sieht echt nach Hardware aus, oder? Tritt typischerweise an 16-Byte-Grenzen mit Wiederholungen auf. Wir vermuteten, dass einige Hosts möglicherweise fehlerhafte Hardware haben, und begannen daher, diesen Test auf verschiedenen Host-Paaren in unserer Infrastruktur durchzuführen, um die Ursache zu finden. Unsere Ergebnisse waren interessant.

Die Betroffenen

Als Erstes fiel uns die Kernelversion auf. Trotz intensiver Bemühungen konnten wir den Fehler unter Linux 2.6 nicht reproduzieren. Eine erfolgreiche Reproduktion war nur mit einem Linux-Kernel ab Version 3.0 möglich. Zwar trat das Problem auch unter Linux 3.0+ auf, jedoch nicht reproduzierbar. Bestimmte Hosts mit einer bestimmten Kernelversion ab 3.0 waren betroffen, während andere Hosts mit derselben Version keine Probleme zeigten. Daher suchten wir nach weiteren Einflussfaktoren.

Nach einigen Wochen erfolgloser Forschung und Tests machten wir schließlich eine beunruhigende Entdeckung: Die Reproduktion des Problems hing von der Xen-Version ab, auf der unsere Hosts liefen. Xen 4.4-Gäste waren nicht betroffen, Xen 4.1 und Xen 3.4 hingegen schon. Dies erklärt die inkonsistenten Testergebnisse bei Verwendung fester Kernelversionen. Wir haben also festgestellt, dass alle Hosts, auf denen ein Linux-Kernel ab Version 3.0 unter Xen 4.1 oder 3.4 läuft, sporadische Fehler bei der IPSec-Verschlüsselung aufweisen. Erstmals konnten wir das Problem zuverlässig reproduzieren und vorhersagen, welche Hosts betroffen sein würden. Jetzt müssen wir nur noch die Lösung finden!

Hilfe!

Zum jetzigen Zeitpunkt verfügen wir über genügend Informationen, um unsere Suche über die Organisationsgrenzen von PagerDuty hinaus auszudehnen. Wir haben eine Post Wir wandten uns an die LKML, um zu sehen, ob jemand anderes dieses Problem bereits kannte. Innerhalb weniger Tage erhielten wir eine Antwort. Herbert Xu, einer der Maintainer des Krypto-Subsystems, antwortete, dass er etwas Ähnliches schon einmal beobachtet hatte. Er berichtete von Spekulationen, dass der HVM-Modus von Xen möglicherweise nicht betroffen sei, und wies auf eine bestimmte Intel-Anweisung hin: aes-ni Die

Fehler Nr. 4 – aesni-intel

Der Intel x86-Befehlssatz umfasst einen AES-Anweisung Wird zur Durchführung von AES-Berechnungen in Hardware verwendet. Ein Kernelmodul. aesni-intel ist dafür verantwortlich, diese Anweisung in den vom Linux-Kernel bereitgestellten AES-Verschlüsselungsfunktionen zu nutzen. Da unsere IPSec-Verschlüsselung AES verwendet, würde dieses Modul wahrscheinlich zur Datenverkehrsverschlüsselung in Anwesenheit von aes-ni auf Intel-Hardware. Ein kurzer Check, der auf den Tipp von LKML zurückgeht, zeigt, dass wir tatsächlich die haben. aesni-intel Das Kernelmodul war auf allen Hosts unserer Flotte geladen. Nachdem wir das Modul zwangsweise entladen hatten, verschwand der Fehler! Halleluja!

Weitere Tests ergaben, dass Herbert mit seiner Aussage zu HVM Recht hatte – es war nicht betroffen. Letztendlich scheint das Problem in einer Wechselwirkung zwischen … zu liegen. aesni-intel und Xen paravirtueller Modus.

Da ein so schwerwiegender Fehler im Verborgenen lauert aesni-intel Man könnte sich fragen: Warum ist das bisher niemandem aufgefallen? Schließlich wird AES ja auch gelegentlich für SSL-Datenverkehr verwendet. Die Antwort liegt in Bug #3: Nur im IPSec-NAT-T-Transportmodus validiert der Kernel keine TCP-Prüfsummen. Das bedeutet, dass die Prüfsummenvalidierung unter allen anderen Bedingungen fehlschlägt und das Paket verworfen wird, wodurch die Anwendung vor beschädigten Daten geschützt wird. Hinzu kommen die Einschränkungen der Xen-Version und des Virtualisierungstyps, die dieses Problem extrem selten machen – ein exotisches AES-Einhorn, das nur von denen entdeckt wird, die wissen, wo es liegt. Wir haben Glück!

Teil III: Die Umgehungslösung

Rückblick

Nach über einem Monat unermüdlicher Forschung und Tests haben wir das ZooKeeper-Rätsel endlich gelöst. Datenbeschädigung während der AES-Verschlüsselung in paravirtuellen Xen-Gästen der Version 4.1 oder 3.4 mit einem Linux-Kernel ab Version 3.0, kombiniert mit fehlender TCP-Prüfsummenvalidierung im IPSec-Transportmodus, führt dazu, dass beschädigte TCP-Daten auf einem ZooKeeper-Knoten zugelassen werden. Dies resultiert in einer unbehandelten Ausnahme, von der sich ZooKeeper nicht erholen kann. Mann, war das eine Suche nach der Nadel im Heuhaufen! Trotz all dem wissen wir immer noch nicht genau, wo der Fehler liegt. Trotzdem sind wir mit dem Ergebnis der Untersuchung recht zufrieden. Jetzt müssen wir nur noch eine Umgehungslösung finden.

Was wir getan haben

Das Entladen des Moduls hat die aufgetretenen Fehler zwar behoben, führt aber zu Leistungseinbußen. Wir haben diese Auswirkungen gemessen und festgestellt, dass sie nur bei sehr hohem Durchsatz auftreten, für den wir jedoch andere Lösungen zur Verfügung haben. Wir wissen außerdem, dass Xen-HVM-Gäste und Linux 2.6 nicht betroffen sind. Mit diesem Wissen können wir nun einen Lösungsplan entwickeln.

Vorhandene paravirtuelle Xen-Gäste unter Linux 3.0+ wurden auf Version 2.6 herabgestuft, jedoch nur, wenn sie eine betroffene Xen-Version verwendeten. Wir haben ein Chef-Rezept zur Xen-Erkennung und zur Blacklistung der betroffenen Versionen geschrieben. aesni-intel Das Modul wird aktiviert, wenn die Problembedingungen vorliegen. Wir haben außerdem damit begonnen, HVM-Hosts anstelle von paravirtuellen Hosts zu standardisieren, um unter anderem weiterhin die AES-Hardwarebeschleunigung nutzen zu können.

Abschließend

Eine endgültige Lösung lässt leider weiterhin auf sich warten. Da spätere Xen-Versionen nicht betroffen sind und die Verbreitung von HVM zunimmt, besteht in der Community wenig Interesse daran, die nötige Zeit in die Isolierung des problematischen Codes zu investieren. Ein ähnliches Problem besteht bei ZooKeeper: Version 3.5 enthält zwar einen Fix, der das unbemerkte Beenden eines kritischen Threads verhindert, befindet sich aber noch im Alpha-Stadium und wird dies auch noch eine Weile bleiben. Es gibt zwar Überlegungen, den Fix in spätere Versionen zu integrieren, die offizielle Position ist jedoch, dass dies nicht möglich ist. wird nicht als Blocker betrachtet für weitere 3.4.x-Versionen.

Wir möchten uns bei den Mitgliedern unserer verschiedenen Entwicklungsteams für ihre Hilfe und ihren Beitrag zur Eingrenzung dieser Probleme bedanken. Zuverlässigkeit hat bei PagerDuty Priorität, und die Ursachenforschung selbst für die ungewöhnlichsten Probleme ist etwas, worauf wir sehr stolz sind und worauf wir sehr stolz sind. Wenn Sie das genauso sehen, würden wir uns freuen, wenn Sie uns unterstützen könnten. begleiten Sie uns Die