Definition „/etc distributed“ Was ist etcd?

Unter etcd ist ein Key-Value-Store zu verstehen, der für verteilte Anwendungen gedacht ist. Er hat die Aufgabe, kritische Daten sicher zu speichern. Er kommt beispielsweise in Kubernetes zum Einsatz und bietet viele Vorteile.

Bei etcd handelt es sich um einen hierarchischen und verteilten Key-Value-Store (Schlüssel-Werte-Datenbank). Geschrieben wurde er vom Core OS-Team in Go. Inzwischen wird er von der Cloud Native Computing Foundation verwaltet und ist Open Source.

Entwickelt wurde etcd, das seit 2014 in Kubernetes implementiert ist, um kritischen Daten in verteilten Anwendungen einen sicheren Speicherplatz zu bieten. Der Name setzt sich zusammen aus „/etc“, dem Verzeichnis für Konfigurationsdateien in GNU/Linux-Betriebssystemen, und „d“ für Distributed.

Verteilte Anwendungen und etcd

Verteilte Anwendungen sind längst Standard geworden. Hierfür haben die Siegeszüge der Clouds, Smartphones und des Internets der Dinge beigetragen. Dass Front- und Backend auf der identischen physischen Maschine laufen, wird immer seltener. Gerade im Cloud-Bereich entstehen jedoch einige Probleme: Teile von Netzwerken können ausfallen. Die Datenübertragung ist kostspielig und endlich.

Die Entwicklung und Zuweisung immer kleinteiligerer Bestandteile von Anwendungen ist zudem mühsam. Schließlich muss der Anwender wissen, wo sich die einzelnen Elemente befinden. Änderbare Informationen müssen deshalb an einem sicheren Ort gespeichert werden, der von diesen Problemen nicht betroffen ist. An dieser Stelle kommt etcd ins Spiel.

Die Funktionsweise von etcd

In Anwendungsclustern gibt es für die Verwaltung von Speichern drei relevante Konzepte: Anführer (Leader), Wahlen (elections) und Zeiträume (terms). Der Cluster hält eine Wahl ab und bestimmt für einen spezifischen Zeitraum einen Anführer. Dieser behandelt alle Speicheranfragen, welche die Zustimmung des Clusters bedürfen.

Der Leader ist der Repräsentant der Gesamtheit. Bei den Anfragen geht es um Änderungen von gesicherten Daten. Anfragen, die keiner Zustimmung bedürfen (z.B. Leseanfragen) können von allen Mitgliedern des Clusters eigenständig beantwortet werden. Wenn der Anführer „stirbt“ (ausfällt) oder nicht länger antwortet, führen die verbleibenden Knoten des Clusters Neuwahlen durch.

Die einzelnen Knoten verfügen dabei jeweils über eine eigene „Stoppuhr“, die bestimmt, wie lange sie warten, bis sie eine Neuwahl fordern und sich selbst als Kandidaten bestimmen. Diese Zeiträume sind von Knoten zu Knoten unterschiedlich. Hintergrund ist, damit möglichst schnell Knoten als Anführer einspringen können, wenn der bisherige ausfällt oder gleich eine ganze Reihe von Knoten nicht mehr zur Verfügung stehen.

Das System ist in der Hinsicht unsicher, dass der Anführer in Eigenregie Veränderungen von gespeicherten Informationen vornehmen kann. An dieser Stelle greift etcd ein. Der Key-Value-Store zwingt den Anführer dazu, alle Knoten bei jeder Änderung zu befragen. Hierfür kommt der Raft Algorithmus zum Einsatz. Nur, wenn die Mehrheit für die Abwandlung stimmt, darf diese durchgeführt werden.

Gerade für verteilte Anwendungen ist dies wichtig: Die einzelnen Knoten des Clusters können Änderungen blockieren, die ihre Funktionsfähigkeit beeinträchtigen. Auf diese Weise wird die Stabilität der Anwendung gewährleistet. Zudem wird die Zahl von Folgeproblemen minimiert.

Vorteile von etcd

• einfach in der Anwendung durch eine auf REST sowie JSON basierende Schnittstelle

• sicher durch SSL-Zertifikat-Authentifizierung

• zuverlässig

• schnell (bis zu 10.000 Schreibvorgänge pro Sekunde)

Empfehlungen für die Implementierung

Da etcd Daten auf Laufwerke schreibt, ist es sinnvoll, mit SSDs zu arbeiten. Die Zahl der Knoten in einem Cluster sollte ungerade sein, um stets eine Mehrheit herstellen zu können. Zudem ist aus Performance-Gründen ratsam, mit keinen Clustern zu arbeiten, die mehr als sieben Knoten besitzen.

(ID:46493033)