📑 🙇🏽 👈🏽 etcd 3.4.3: Speicherzuverlässigkeits- und Sicherheitsforschung 😺 👊🏽 👂🏿

Hinweis perev. : Der Inhalt dieses Artikels ist nicht ganz typisch für unseren Blog. Wie viele wissen, befindet sich etcd jedoch im Herzen von Kubernetes, weshalb sich diese Studie, die von einem unabhängigen Berater auf dem Gebiet der Zuverlässigkeit durchgeführt wurde, unter Ingenieuren, die dieses System betreiben, als interessant herausstellte. Interessant ist auch, wie Open Source-Projekte, die sich bereits in der Produktion bewährt haben, auch auf einem so "niedrigen" Niveau verbessert werden.

Der Tresor für Schlüsselwerte (KV) usw. ist eine verteilte Datenbank, die auf dem Raft-Konsensalgorithmus basiert. In einer 2014 durchgeführten Analysehaben wir festgestellt, dass etcd 0.4.1 standardmäßig von den sogenannten veralteten Lesevorgängen betroffen ist(Leseoperationen, die aufgrund einer Verzögerung der Synchronisation einen alten, irrelevanten Wert zurückgeben - ca. übersetzt) . Wir haben uns entschlossen, zu etcd zurückzukehren (diesmal zu Version 3.4.3), um das Potenzial im Bereich Zuverlässigkeit und Sicherheit erneut im Detail zu bewerten.

Wir haben festgestellt, dass die Operation mit Paaren von "Schlüsselwerten" streng serialisierbar ist und dass die Prozesse des Beobachters (Uhren) bei jeder Änderung des Bestellschlüssels geliefert werden. Allerdings Schlösser in ETCD sind grundsätzlich unsicher, und die mit ihnen verbundenen Risiken werden durch einen Fehler verschlimmert, als Folge davon die Relevanz des Mietvertrags nicht geprüft wird , nach einer Wartezeit für das Schloss. Sie können den Kommentar der etcd-Entwickler in unserem Bericht im Projektblog lesen .

Die Studie wurde von der Cloud Native Computing Foundation (CNCF) gesponsert, die Teil der Linux Foundation ist. Es wurde in voller Übereinstimmung mit den ethischen Richtlinien von Jepsen durchgeführt .

1. Hintergrund

Das Etc KV-Repository ist ein verteiltes System, das als Grundlage für die Koordination dient. Wie Zookeeper und Consul speichert etcd kleine Mengen selten aktualisierter Status ( standardmäßig bis zu 8 GB ) in Form einer Schlüsselwertzuordnung und bietet streng serialisierbare Lese-, Schreib- und Mikrotransaktionen im gesamten Data Warehouse sowie Koordinationsprimitive wie Sperren und Nachverfolgung (Uhren) und Führerauswahl. Viele verteilte Systeme wie Kubernetes und OpenStack verwenden etcd, um Cluster-Metadaten zu speichern, koordinierte Ansichten von Daten zu koordinieren, einen Leiter auszuwählen usw.

Im Jahr 2014 haben wir bereits eine Bewertung von etcd 0.4.1 durchgeführt . Dann haben wir festgestellt, dass es aufgrund der Optimierung standardmäßig zu veralteten Lesevorgängen kommt. Während in der Arbeit an Raft-Prinzipien die Notwendigkeit erörtert wird, Lesevorgänge in Threads aufzuteilen und diese durch ein Konsenssystem zu leiten, um die Lebensfähigkeit sicherzustellen, liest etcd jeden Anführer lokal, ohne nach einem aktuelleren Status des neueren Leiters zu suchen. Das etcd-Entwicklungsteam implementierte das optionale Quorum-Flag , und in der etcd-Version 3.0-API wurde standardmäßig die Linearisierbarkeit für alle Vorgänge mit Ausnahme der Nachverfolgungsvorgänge angezeigt .

Die etcd 3.0-API konzentriert sich auf eine flache KV-Karte, in der die Schlüssel und Werte undurchsichtig sind( undurchsichtige ) Byte-Arrays. Mithilfe von Bereichsabfragen können Sie hierarchische Schlüssel simulieren. Benutzer können Schlüssel lesen, schreiben und löschen sowie den Aktualisierungsfluss für einen einzelnen Schlüssel oder Schlüsselbereich überwachen. Das etcd-Toolkit wird durch Leases (variable Objekte mit begrenzter Lebensdauer, die durch Heartbeat-Anforderungen des Clients im aktiven Zustand gehalten werden), Sperren (dedizierte benannte Objekte, die an Leases gebunden sind) und die Auswahl von Leitern ergänzt.

In Version 3.0 bietet etcd eine eingeschränkte Transaktions-APIfür atomare Operationen mit vielen Schlüsseln. In diesem Modell ist eine Transaktion ein bedingter Ausdruck mit einem Prädikat, einem wahren Zweig und einem falschen Zweig. Ein Prädikat kann eine Verbindung mehrerer Schlüsselvergleiche sein: Gleichheit oder verschiedene Ungleichungen, je nach Version eines Schlüssels, globaler Revision usw. oder dem aktuellen Schlüsselwert. Wahre und falsche Verzweigungen können mehrere Lese- und Schreibvorgänge umfassen. Alle von ihnen werden abhängig vom Ergebnis der Prädikatenschätzung atomar angewendet.

1.1 Garantien für die Konsistenz der Dokumentation

Ab Oktober 2019 heißt es in der Dokumentation zur etcd- Dokumentation : „Alle API-Aufrufe weisen eine konsistente Konsistenz auf - die stärkste Form der Konsistenzgarantie, die auf verteilten Systemen verfügbar ist.“ Dies ist nicht der Fall: Die konsistente Konsistenz ist streng schwächer als die Linearisierbarkeitund Linearisierbarkeit ist definitiv in verteilten Systemen erreichbar. Ferner wird in der Dokumentation angegeben, dass "während des Lesevorgangs etcd nicht die Übertragung des [letzten (gemessen durch die externe Uhr nach Abschluss der Anforderung)] Werts garantiert, der auf einem Vertreter des Clusters verfügbar ist". Dies ist auch eine zu konservative Aussage: Wenn etcd Linearisierbarkeit bietet, werden Leseoperationen immer mit dem letzten festgeschriebenen Zustand in der Linearisierungsreihenfolge verknüpft.

Die Dokumentation behauptet auch, dass etcd eine serialisierbare Isolation garantiert: Alle Vorgänge (auch solche, die mehrere Schlüssel betreffen) werden in einer allgemeinen Reihenfolge ausgeführt. Die Autoren beschreiben die serialisierbare Isolation als "die stärkste Isolationsstufe, die in verteilten Systemen verfügbar ist". Dies (abhängig davon, was Sie mit der „Isolationsstufe“ meinen) ist auch nicht wahr; Die strikte Serialisierbarkeit ist stärker als die einfache Serialisierbarkeit, während die erstere auch in verteilten Systemen erreichbar ist.

Die Dokumentation besagt, dass alle Operationen (außer Tracking) in etcd standardmäßig linearisierbar sind. In diesem Fall wird Linearisierbarkeit als Konsistenz mit schwach synchronisierten globalen Uhren definiert. Es ist zu beachten, dass eine solche Definition nicht nur mit der Definition der Linearisierbarkeit unvereinbar istHerlihy & Wing impliziert aber auch eine Verletzung der Kausalität: Knoten mit führenden Stunden werden versuchen, die Ergebnisse von Operationen zu lesen, die noch nicht einmal begonnen haben. Wir gehen davon aus, dass etcd immer noch keine Zeitmaschine ist, und da es auf dem Raft-Algorithmus basiert, sollte die allgemein akzeptierte Definition der Linearisierbarkeit angewendet werden.

Da KV-Operationen in etcd serialisierbar und linearisierbar sind, denken wir, dass etcd standardmäßig eine strikte Serialisierung bietet . Dies ist sinnvoll, da sich alle Schlüssel usw. in einer einzigen Zustandsmaschine befinden und Raft die vollständige Reihenfolge aller Vorgänge auf dieser Zustandsmaschine bereitstellt. Tatsächlich ist der gesamte etcd-Datensatz ein einzelnes linearisierbares Objekt.

Optionale Flagge serializable senkt sichDie Ebene der Lesevorgänge von strikter bis zu regulärer serialisierbarer Konsistenz, die das Lesen eines veralteten festgeschriebenen Status ermöglicht. Beachten Sie, dass das Flag serializabledie Serialisierbarkeit der Story nicht beeinflusst. KV-Operationen etcd sind in allen Fällen serialisierbar.

2. Testentwicklung

Um eine Testsuite zu erstellen , haben wir die entsprechende Jepsen-Bibliothek verwendet. Die Version etcd 3.4.3 (spätestens ab Oktober 19) wurde analysiert und arbeitete an Debian Stretch-Clustern, die aus 5 Knoten bestehen. Wir haben eine Reihe von Fehlern in diesen Clustern implementiert, darunter Netzwerkpartitionen, Isolieren einzelner Knoten, Aufteilen des Clusters in eine Mehrheit und eine Minderheit sowie nicht-transitive Partitionen mit einer überlappenden Mehrheit. Sie haben zufällige Untergruppen von Knoten „fallen gelassen“ und suspendiert sowie Führungskräfte absichtlich behindert. Zeitliche Verzerrungen von bis zu mehreren hundert Sekunden wurden sowohl in Intervallen von mehreren Sekunden als auch in Intervallen von Millisekunden eingeführt (schnelles „Flimmern“). Da etcd das dynamische Ändern der Anzahl der Komponenten unterstützt, haben wir während des Tests zufällig Knoten hinzugefügt und entfernt.

Zu den Testlasten gehörten Register, Sets und Transaktionstests zur Überprüfung des Betriebs von KV sowie Speziallasten für Schlösser und Uhren.

2.1 Register

Um die Zuverlässigkeit von etcd während KV-Operationen zu bewerten, wurde ein Registertest entwickelt, bei dem zufällige Lese-, Schreib-, Vergleichs- und Einstelloperationen an Einheitsschlüsseln durchgeführt wurden. Die Ergebnisse wurden unter Verwendung des Knossos- Linearisierbarkeitstools unter Verwendung des Vergleichs- / Installationsregistermodells und der Versionsinformationen bewertet .

2.2 Sätze

Um veraltete Lesevorgänge zu quantifizieren, wurde ein Test entwickelt , der eine Vergleichs- und Satztransaktion verwendete , um einen Satz von Ganzzahlen von einem einzelnen Schlüssel zu lesen und diesem Satz dann einen Wert hinzuzufügen. Während des Tests haben wir auch eine parallele Ablesung des gesamten Sets durchgeführt. Nach Abschluss des Tests wurden die Ergebnisse auf das Auftreten von Fällen analysiert, in denen das Element, von dem bekannt war, dass es im Satz vorhanden war, in den Leseergebnissen nicht vorhanden war. Diese Fälle wurden verwendet, um veraltete Lesevorgänge und verlorene Aktualisierungen zu quantifizieren.

2.3 Test anhängen

Um die strikte Serialisierbarkeit zu überprüfen, wurde ein Append-Test entwickelt , bei dem Transaktionen parallel gelesen und Listen mit eindeutigen Ganzzahlsätzen mit Werten versehen wurden. Jede Liste wurde in einem etcd-Schlüssel gespeichert, und innerhalb jeder Transaktion wurden Ergänzungen vorgenommen, wobei jeder Schlüssel gelesen wurde , der in einer Transaktion geändert werden musste. Anschließend wurden diese Schlüssel geschrieben und in der zweiten Transaktion, die geschützt war, gelesenum sicherzustellen, dass sich seit dem ersten Lesen kein aufgezeichneter Schlüssel geändert hat. Am Ende des Tests haben wir die Beziehung zwischen Transaktionen basierend auf der Echtzeitpriorität und der Beziehung zwischen Lese- und Additionsoperationen aufgezeichnet. Durch Überprüfen dieses Diagramms auf Schleifen konnte festgestellt werden, ob die Operationen streng serialisierbar waren.

Während etcd verhindert, dass Transaktionen denselben Schlüssel mehrmals schreiben, können Sie Transaktionen mit bis zu einem Datensatz pro Schlüssel erstellen. Wir haben auch sichergestellt, dass Lesevorgänge innerhalb derselben Transaktion frühere Schreibvorgänge aus derselben Transaktion widerspiegeln.

2.4 Schlösser

Als Koordinierungsdienst verspricht etcd integrierte Unterstützung für verteiltes Sperren . Wir haben diese Schlösser auf zwei Arten untersucht. Zunächst wurden zufällige Sperr- und Entsperranforderungen generiert , die für jede Sperre eine Lease erhielten und diese keepalive bis zur Freigabe mithilfe des integrierten etc- Clients im Java-Client geöffnet ließen . Wir haben die Ergebnisse mit Knossos getestet, um festzustellen, ob sie eine linearisierte Implementierung des Sperrdienstes bilden.

Für einen praktischeren Test (und um die Häufigkeit von Sperrfehlern zu quantifizieren) haben wir Sperren und etcd verwendet, um den gegenseitigen Ausschluss zu organisieren, wenn Aktualisierungen des Satzes im Speicher vorgenommen werdenund suchte nach verlorenen Updates in diesem Set. Mit diesem Test konnten wir direkt bestätigen, ob Systeme, die etcd als Mutex verwenden, den internen Status sicher aktualisieren können.

Die dritte Version des Sperrtests umfasste Schutzmaßnahmen für den Lease-Schlüssel , um das in etcd gespeicherte Set zu ändern.

2.5 Verfolgung

Um zu überprüfen, ob die Uhren Informationen zu jeder Schlüsselaktualisierung liefern, wurde im Rahmen des Tests ein Schlüssel erstellt und blind eindeutige Ganzzahlwerte zugewiesen . In der Zwischenzeit teilten Kunden diesen Schlüssel mehrere Sekunden lang. Jedes Mal nach dem Start der Uhr begann der Kunde mit der Überarbeitung, bei der er das letzte Mal gestoppt hatte.

Am Ende dieses Prozesses haben wir sichergestellt, dass jeder Client dieselbe Abfolge von Schlüsseländerungen beobachtet.

3. Ergebnisse

3.1 Tracking ab der 0. Revision

Beim Verfolgen eines Schlüssels können Clients eine erste Revision angeben , bei der es sich um eine optionale Revision handelt, mit der die Verfolgung (einschließlich) beginnt. Wenn der Benutzer jede Operation mit einem bestimmten Schlüssel sehen möchte, kann er die erste Revision von etcd angeben. Was ist dieses Audit? Das Datenmodell und das Glossar geben keine Antwort auf diese Frage. Revisionen werden als monoton ansteigende 64-Bit-Zähler beschrieben, es ist jedoch unklar, ob etcd bei 0 oder 1 beginnt. Es ist vernünftig anzunehmen, dass der Countdown von Grund auf neu ist (nur für den Fall).

Leider ist das falsch. Wenn Sie die 0. Revision anfordern, sendet etcd Updates, beginnend mit der aktuellen Revision auf dem Server plus eins, aber nicht mit dem allerersten. Die Anfrage für die 1. Revision enthält alle Änderungen. Dieses Verhalten ist nirgendwo dokumentiert .

Wir glauben, dass diese Subtilität in der Praxis wahrscheinlich nicht zu Produktionsproblemen führt, da die meisten Cluster bei der ersten Überarbeitung nicht verweilen. Darüber hinaus ETCD Kompressen die Geschichte ohnehin im Laufe der Zeit, so in realen Anwendungen, höchstwahrscheinlich, in jedem Fall ist es nicht erforderlich , alle Versionen zu lesen, mit der ersten Revision beginnen. Ein solches Verhalten ist gerechtfertigt, würde jedoch die entsprechende Beschreibung in der Dokumentation nicht beeinträchtigen.

3.2 Mythische Schlösser

In der API-Dokumentation für Sperren heißt es, dass ein gesperrter Schlüssel "in Verbindung mit Transaktionen verwendet werden kann, um sicherzustellen, dass Aktualisierungen in etcd nur dann erfolgen, wenn die Sperre im Besitz ist." Seltsam, aber es gibt keine Garantie für die Schlösser selbst und ihr Zweck wird nicht erklärt.

In anderen Materialien teilen die Betreuer usw. jedoch weiterhin Informationen über die Verwendung von Schlössern. In der Release-Ankündigung zu etcd 3.2 wird beispielsweise eine Anwendung etcdctlzum Blockieren von Änderungen an der Dateifreigabe auf einer Festplatte beschrieben. Darüber hinaus beantwortete einer der etcd-Entwickler in einem Problem auf GitHub mit einer Frage zum spezifischen Zweck der Sperren Folgendes:

etcd , ( ) , ( etcd), - :

etcd;
- ( , etcd);
.

Ein solches Beispiel finden Sie in etcdctl: Zum Schutz des Teams putwurde eine Sperre verwendet, die den Sperrschlüssel jedoch nicht an das Update gebunden hat.

Leider ist dies nicht sicher, da mehrere Clients gleichzeitig dieselbe Sperre halten können. Das Problem wird durch die Unterbrechung von Prozessen, Netzwerkabstürzen oder Partitionen verschärft. Es kann jedoch auch in vollständig fehlerfreien Clustern ohne externe Fehler auftreten. In diesem Testlauf setzt beispielsweise Prozess Nummer 3 die Sperre erfolgreich, und Prozess 1 erhält dieselbe Sperre parallel, noch bevor Prozess 3 die Möglichkeit hat, sie zu entfernen:

Die Mutex-Verletzung war bei Leasingverträgen mit kurzen TTLs am auffälligsten: TTLs von 1, 2 und 3 Sekunden konnten bereits nach wenigen Testminuten (selbst in gesunden Clustern) keinen gegenseitigen Ausschluss bewirken. Prozesssuspensionen und Netzwerkpartitionen führten noch schneller zu Problemen.

In einer unserer Lock-Test-Varianten wurden etcd-Mutexe verwendet, um gemeinsame Aktualisierungen einer Reihe von Ganzzahlen zu schützen (wie in der Dokumentation etcd vorgeschlagen). Bei jeder Aktualisierung wird der aktuelle speicherinterne Beispielwert gelesen und nach etwa einer Sekunde wird diese Sammlung mit einem eindeutigen Element zurückgeschrieben. Mit Leases mit einer TTL von zwei Sekunden, fünf parallelen Prozessen und einer Prozesspause alle fünf Sekunden konnten wir einen stetigen Verlust von etwa 18% der bestätigten Aktualisierungen verursachen.

Dieses Problem wurde durch den internen Verriegelungsmechanismus in etcd verschärft. Wenn ein Client darauf gewartet hat, dass ein anderer Client ihn entsperrt, seine Lease verloren hat und die Sperre danach aufgehoben wurde, hat der Server die Lease nicht erneut überprüft , um sicherzustellen, dass sie noch gültig ist, bevor er den Client darüber informiert hat, dass die Sperre jetzt dahinter steht.

Die Aufnahme einer zusätzlichen Mietvertragsprüfung sowie die Auswahl längerer TTLs und die sorgfältige Festlegung von Wahlzeitüberschreitungen verringern die Häufigkeit dieses Problems. Mutex-Verstöße können jedoch nicht vollständig beseitigt werden, da verteilte Sperren in asynchronen Systemen grundsätzlich unsicher sind. Dr. Martin Kleppmann beschreibt dies in seinem Artikel überzeugendÜber verteilte Sperren. Ihm zufolge müssen Blockierungsdienste die Korrektheit opfern, um die Lebensfähigkeit in asynchronen Systemen aufrechtzuerhalten: Wenn der Prozess während der Steuerung der Blockierung abstürzt, benötigt der Blockierungsdienst eine Möglichkeit, das Entsperren der Blockierung zu erzwingen. Wenn der Prozess jedoch tatsächlich nicht abgebrochen wurde, sondern nur langsam abläuft oder vorübergehend nicht verfügbar ist, kann das Entsperren dazu führen, dass er an mehreren Stellen gleichzeitig ausgeführt wird.

Aber selbst wenn der verteilte Blockierungsdienst beispielsweise eine Art magischen Fehlerdetektor verwendet und tatsächlich den gegenseitigen Ausschluss garantieren kann, ist seine Verwendung im Fall einer nicht lokalen Ressource immer noch unsicher. Angenommen, Prozess A sendet eine Nachricht an die Datenbank D, während er eine Sperre hält. Danach stürzt Prozess A ab und Prozess B empfängt eine Sperre und sendet auch eine Nachricht an Basis D. Das Problem besteht darin, dass eine Nachricht von Prozess A (aufgrund von Asynchronität) nach einer Nachricht von Prozess B kommen kann, wodurch die gegenseitige Ausnahme verletzt wird, die die Sperre bereitstellen sollte. .

Um dieses Problem zu vermeiden, muss man sich darauf verlassen, dass das Speichersystem selbst die Richtigkeit von Transaktionen unterstützt oder, wenn der Sperrdienst einen solchen Mechanismus bereitstellt, verwendet" Fechten" -Token , das in allen vom Schlosshalter ausgeführten Vorgängen enthalten ist. Dadurch wird sichergestellt, dass zwischen den Vorgängen des aktuellen Schlossbesitzers keine Operationen des vorherigen Schlosshalters plötzlich auftreten. Im Chubby-Blockierungsdienst von Google werden diese Token beispielsweise als Sequenzer bezeichnet . In etcd können Sie die Revision des Sperrschlüssels als global geordnetes Blockierungs-Token verwenden.

Darüber hinaus können Sperrschlüssel in etcd verwendet werden, um Transaktionsaktualisierungen in etcd selbst zu schützen. Überprüfen der Sperrschlüsselversion als Teil der TransaktionBenutzer können eine Transaktion verhindern, wenn die Sperre nicht mehr gehalten wird (d. h. die Version des Sperrschlüssels ist größer als Null). In unseren Tests konnten wir mit diesem Ansatz Lese-, Änderungs- und Schreibvorgänge erfolgreich isolieren, bei denen das Schreiben die einzige durch Sperren geschützte Transaktion war. Dieser Ansatz bietet eine ähnliche Isolation wie Barrage-Token, garantiert jedoch (wie Barrage-Token) keine Atomizität: Ein Prozess kann während eines Updates, das aus vielen Vorgängen besteht, abstürzen oder einen Mutex verlieren, wodurch etcd in einem logisch inkonsistenten Zustand verbleibt.

Die Ergebnisse der Arbeit in den Themen des Projekts:

Uhren ab Revision 0 starten später - nicht entschieden;
Sperren kehren nach dem Blockieren zurück, ohne den Besitz zu überprüfen - im Master;
Sperren werden nicht als unsicher dokumentiert - nicht gelöst.

4. Diskussion

In unseren Tests hat etcd 3.4.3 die Erwartungen hinsichtlich der KV-Operationen erfüllt: Wir haben trotz der Unterbrechung von Prozessen, Abstürzen, Manipulationen der Uhr und des Netzwerks sowie einer Änderung der Anzahl der Clustermitglieder eine streng serialisierbare Konsistenz von Lese-, Schreib- und sogar Mehrschlüsseltransaktionen beobachtet . In KV-Operationen wurde standardmäßig streng serialisierbares Verhalten implementiert. Die Durchführung von Messwerten mit serializablegesetztem Flag führte zum Auftreten veralteter Lesevorgänge (wie in der Dokumentation beschrieben).

Überwachen Sie (Uhren) , um richtig zu arbeiten - zumindest an den einzelnen Tasten. Bis die Komprimierung des Verlaufs die alten Daten zerstörte, gab die Uhr jedes Schlüsselupdate erfolgreich aus.

Es stellte sich jedoch heraus, dass Sperren in etcd (wie alle verteilten Sperren) keinen gegenseitigen Ausschluss bieten. Verschiedene Prozesse können die Sperre gleichzeitig halten - auch in gesunden Clustern mit perfekt synchronisierten Uhren. Die Dokumentation mit der Sperr-API sagte nichts darüber aus, und die vorgestellten Beispiele für Sperren waren unsicher. Einige der Probleme mit den Sperren mussten jedoch nach der Veröffentlichung dieses Patches behoben werden .

Als Ergebnis unserer Zusammenarbeit hat das etcd-Team eine Reihe von Änderungen an der Dokumentation vorgenommen (diese wurden bereits auf GitHub veröffentlicht und werden in zukünftigen Versionen der Projektwebsite veröffentlicht). Auf der GitHub Warranties API-Seite wird jetzt angegeben, dass etcd standardmäßig streng serialisierbar istund die Behauptung, dass seriell und serialisierbar die stärksten in verteilten Systemen verfügbaren Konsistenzniveaus sind, wurde entfernt. In Bezug auf Revisionen wird jetzt angegeben, dass der Start von Einheit (1) aus erfolgen sollte , obwohl in der API-Dokumentation immer noch nicht angegeben ist, dass ein Versuch, mit der 0. Revision zu beginnen, dazu führt, dass Ereignisse ausgegeben werden, die nach der aktuellen Revision plus 1 aufgetreten sind. anstelle des erwarteten "Versands aller Ereignisse". Die Dokumentation von Sicherheitsproblemen bei Sperren befindet sich in der Entwicklung .

Einige Dokumentationsänderungen, z. B. die Beschreibung des besonderen Verhaltens von etcd beim Versuch zu lesen, beginnend mit einer Null-Revision, erfordern weiterhin Aufmerksamkeit.

Wie üblich betonen wir, dass Jepsen einen experimentellen Ansatz zur Sicherheitsüberprüfung bevorzugt: Wir können das Vorhandensein von Fehlern bestätigen, nicht jedoch deren Fehlen. Es werden erhebliche Anstrengungen unternommen, um Probleme zu finden, aber wir können die allgemeine Richtigkeit von etcd nicht beweisen.

4.1 Empfehlungen

Wenn Sie Sperren in etcd verwenden, überlegen Sie, ob Sie diese aus Sicherheitsgründen oder einfach zur Leistungssteigerung benötigen, indem Sie die Parallelität wahrscheinlich einschränken. Etcd-Sperren können verwendet werden, um die Leistung zu steigern. Die Verwendung aus Sicherheitsgründen kann jedoch riskant sein.

Insbesondere wenn Sie die etcd-Sperre verwenden, um eine gemeinsam genutzte Ressource wie eine Datei, eine Datenbank oder einen Dienst zu schützen, sollte diese Ressource die Sicherheit gewährleisten, ohne sie zu blockieren. Eine Möglichkeit, dies zu erreichen, ist die Verwendung eines monotonen Sperrmarkers . Dies kann beispielsweise eine etcd-Revision sein, die dem aktuell gehaltenen Sperrschlüssel zugeordnet ist. Die gemeinsam genutzte Ressource muss sicherstellen, dass der Client das Token verwendet hatyUm eine Operation auszuführen, wird jede Operation mit einem Token x < yabgelehnt. Dieser Ansatz stellt keine Atomizität sicher, garantiert jedoch, dass Operationen im Rahmen der Verriegelung in der richtigen Reihenfolge und nicht zeitweise ausgeführt werden.

Wir vermuten, dass normale Benutzer dieses Problem wahrscheinlich nicht haben. Wenn Sie sich jedoch darauf verlassen , alle Änderungen von etcd zu lesen, beginnend mit der ersten Revision, denken Sie daran, dass Sie 1 und nicht 0 als Parameter übergeben müssen. Unsere Experimente zeigen, dass eine Null-Revision in diesem Fall „aktuelle Revision“ bedeutet und nicht "Früheste."

Schließlich führen Sperren und etcd (wie alle verteilten Sperren) Benutzer in die Irre: Sie möchten sie möglicherweise als reguläre Sperren verwenden, sind jedoch sehr überrascht, wenn sie feststellen, dass diese Sperren keinen gegenseitigen Ausschluss bieten. Die API-Dokumentation, Blog-Beiträge und Probleme auf GitHub sagen nichts über dieses Risiko aus. Wir empfehlen, dass Sie Informationen in die etcd-Dokumentation aufnehmen, dass Sperren keinen gegenseitigen Ausschluss bieten, und Beispiele für die Verwendung von Sperr-Token zum Aktualisieren des Status freigegebener Ressourcen anstelle von Beispielen angeben, die zum Verlust von Updates führen können.

4.2 Weitere Pläne

Das etcd-Projekt gilt seit mehreren Jahren als stabil: Der darauf basierende Raft-Algorithmus hat gut funktioniert, die API für KV-Operationen ist einfach und unkompliziert. Obwohl einige zusätzliche Funktionen kürzlich eine neue API erhalten haben, ist ihre Semantik relativ einfach. Wir glauben, dass wir bereits genug grundlegende Befehle wie getund put, Transaktionen, Blockieren und Verfolgen studiert haben. Es gibt jedoch andere Tests, die durchgeführt werden sollten.

Derzeit haben wir keine ausreichend detaillierte Bewertung der Löschungen durchgeführt.: Mit Versionen und Revisionen können Grenzfälle verbunden sein, wenn Objekte ständig erstellt und gelöscht werden. In zukünftigen Tests beabsichtigen wir, die Entfernungsvorgänge einer genaueren Untersuchung zu unterziehen. Wir haben auch keine Bereichsabfragen oder Verfolgungsoperationen mit mehreren Schlüsseln getestet, obwohl wir vermuten, dass ihre Semantik Operationen mit einzelnen Schlüsseln ähnelt.

In den Tests verwendeten wir die Unterbrechung von Prozessen, Abstürzen, Manipulationen mit der Uhr, das Netzwerk wurde geteilt und die Zusammensetzung des Clusters geändert; Hinter den Kulissen gab es Probleme wie Festplattenschäden und andere byzantinische Fehler auf der Ebene eines Knotens. Diese Möglichkeiten können in zukünftigen Forschungen untersucht werden.

Die Arbeit wurde von der Cloud Native Computing Foundation unterstützt., Teil der Linux Foundation , und entspricht den ethischen Richtlinien von Jepsen . Wir möchten dem etcd-Team für ihre Hilfe und insbesondere den folgenden Vertretern danken: Chris Aniszczyk, Gyuho Lee, Xiang Li, Hitoshi Mitake, Jingyi Hu und Brandon Philips.

PS vom Übersetzer

Lesen Sie auch in unserem Blog:

etcd 3.4.3: Speicherzuverlässigkeits- und Sicherheitsforschung