etcd: Datenbank für Schlüssel-Wert-Paare

Verteilte Systeme wie Cloud-Plattformen gewinnen mehr und mehr an Bedeutung. Im Zuge dessen weichen einzelne Datenbanken flexibel skalierbaren Clustern. Dies stellt viele Verantwortliche vor eine Reihe neuer Herausforderungen: Netzwerkausfälle, Verzögerungen, endliche Datendurchsätze, kleinteilige Systembestandteile und Transportsicherheit der Daten sind Themen, mit denen sich Betreiber intensiv auseinandersetzen müssen.

Eine mögliche Lösung ist ein zentraler Ort für änderbare Informationen, der ausfallsicher, fehlertolerant und konsistent ist – wie der praktische Key-Value-Store etcd.

Was ist etcd?

etcd ist ein verteilter Key-Value-Store, der vom CoreOS-Team entwickelt und wie viele Tools im Docker-Umfeld in der Google-Sprache Go geschrieben wurde. Ziel der Entwicklung war es, einen sicheren Speicherplatz für kritische Daten von verteilten Anwendungen zu erstellen, der die Verwaltung überschaubar macht.

Namensgebend ist das Verzeichnis für Konfigurationsdateien in GNU/Linux-Betriebssystemen „/etc“, während das angehängte „d“ für „distributed“ (dt. verteilt) steht. Mittlerweile wird etcd als Open-Source-Software von der Cloud Native Computing Foundation verwaltet.

Wie funktioniert etcd?

Will man etcd verstehen, ist es wichtig, die drei Kernbegriffe im Anwendungscluster für die Verwaltung von Speichern zu kennen:

  • Anführer (leader)
  • Wahlen (elections)
  • Zeiträume (terms)

In Raft-basierten Systemen wählt das Cluster für einen bestimmten Zeitraum einen Anführer. Dieser bearbeitet alle Speicheranfragen, die dem Konsens des Clusters entsprechen. Anfragen, die keine Zustimmung des Clusters erfordern – wie Lesezugriffe – kann jedes Mitglied des Clusters eigenständig beantworten. Akzeptiert der Anführer eine Änderung, sorgt etcd dafür, dass er die Information an die Nachfolgeknoten repliziert. Sobald diese den Empfang bestätigt haben, übernimmt der Anführer die Änderung.

Die Abstimmung des Anführers mit den Knoten des Clusters durch eine etcd-Datenbank ist besonders bei verteilten Anwendungen wertvoll. Beinträchtigen Änderungen die Funktionsweise eines Knotens, kann dieser die Änderungen blockieren. Dadurch ist gewährleistet, dass die Anwendung stabil läuft und Folgeprobleme minimiert werden.

Fällt der Anführer aus oder antwortet längere Zeit nicht, wählen die verbleibenden Knoten des Clusters nach einer bestimmten Zeitspanne einen neuen Anführer. Die Zeit, die vergeht, bis ein Knoten eine Neuwahl fordert und sich selbst als Kandidat bestimmt, ist dabei von Knoten zu Knoten unterschiedlich. Bestimmt wird diese durch eine „Stoppuhr“, über die jeder Knoten verfügt. So ist gewährleistet, dass möglichst schnell Knoten als Anführer einspringen können.

Damit bei den Wahlen stets eine Mehrheit erzielt wird, muss die Anzahl der Knoten im Cluster ungerade sein. Aus Performance-Gründen empfiehlt es sich, kein Cluster zu verwenden, das mehr als sieben Knoten besitzt.

Tipp

Um etcd zu testen, können Sie es auf einem Laptop oder in einem einfachen Cloud-Setup ausführen. Da etcd Daten auf die Festplatte schreibt, ist eine SSD dringend zu empfehlen. In der Produktion sollten Sie die in der offiziellen Dokumentation aufgezeigten Richtlinien berücksichtigen.

Die Vorteile von etcd

Neben dem Effekt, dass die Anwendung stabil läuft, bringt eine etcd-Datenbank viele weitere Vorteile mit sich:

  • Vollständig replizierbar: Der gesamte Speicher ist auf jedem Knoten im Cluster verfügbar.
  • Hohe Verfügbarkeit: etcd-Datenbanken vermeiden einzelne Fehlerquellen wie Hardware- oder Netzwerkprobleme.
  • Konsistent: Über mehrere Hosts hinweg liefert jeder Lesevorgang den letzten Schreibvorgang.
  • Einfach: etcd enthält ein gut definiertes, benutzerorientiertes API (gRPC), basierend auf REST und JSON.
  • Sicher: etcd implementiert automatisch eine sichere Übertragung via SSL/TLS. Optional können Sie die Client-Zertifikat-Authentifizierung nutzen.
  • Schnell: Das Benchmarking liegt bei mehr als 10.000 Schreibvorgängen pro Sekunde.
  • Zuverlässig: Der Raft-Algorithmus sorgt stets für eine korrekte Verteilung des Speichers.

etcd-Beispiel: Der Key-Value-Store im Praxiseinsatz

Bereits 2014 implementierten Entwickler etcd in Kubernetes, was zu einem rasanten Wachstum der etcd-Gemeinschaft führte. Cloud-Anbieter wie AWS, Google Cloud Platform und Azur folgten, indem sie etcd erfolgreich in ihre Produktionsumgebungen einsetzten.

Bleiben wir aber beim erstgenannten etcd-Beispiel Kubernetes. Kubernetes selbst ist ein verteiltes System, das auf einem Cluster aus mehreren Maschinen läuft. Dementsprechend profitiert es enorm von einem verteilten Datenspeicher wie etcd, der die kritischen Daten sicher verwahrt. Innerhalb von Kubernetes dient die etcd-Datenbank als primärer Datenspeicher, in der die Konfigurationsdaten, der Status und die Metadaten gespeichert sind. Erfolgen Änderungen, gewährleistet etcd, dass alle Knoten aus dem Kubernetes-Cluster die Daten lesen und schreiben können. Gleichzeitig überwacht etcd den aktuellen oder den gewünschten Zustand des Systems. Unterscheiden sich die Zustände, nimmt Kubernetes Änderungen vor, damit sie sich wieder angleichen.

Hinweis

Mit dem Befehl „kubectl“ wird ein gelesener Wert aus der etcd-Datenbank abgerufen. Änderungen mit „kubectl apply“ erzeugen oder aktualisieren Einträge im etcd-Store – jeder Absturz des Systems verändert automatisch Werte im etcd.


Auf dem Laufenden bleiben?

Jetzt für unseren Newsletter anmelden und gratis Online-Marketing Whitepaper für lokale Anbieter sichern!