etcd ist ein verteilter Open-Source-Schlüssel-Werte-Speicher, der zum Speichern und Verwalten der entscheidenden Informationen verwendet wird, die verteilte Systeme benötigen. Vor allem verwaltet es die Konfigurationsdaten, Zustandsdaten und Metadaten für Kubernetes, die beliebte Container-Orchestrierungsplattform.
Wie alle verteilten Workloads haben auch containerisierte Workloads komplexe Verwaltungsanforderungen, die mit zunehmender Skalierung der Workload komplexer werden. Kubernetes vereinfacht den Prozess der Verwaltung dieser Workloads, indem Aufgaben wie Konfiguration, Bereitstellung, Serviceerkennung, Lastausgleich, Auftragsplanung und Zustandsüberwachung über alle Cluster hinweg koordiniert werden, die auf mehreren Maschinen an mehreren Standorten ausgeführt werden können.
Um diese Koordination zu erreichen, benötigt Kubernetes jedoch einen Datenspeicher, der zu jedem beliebigen Zeitpunkt eine einzige, konsistente Quelle mit Informationen über den Status des Systems (aller seiner Cluster und Pod und der darin enthaltenen Anwendungsinstanzen) bietet. etcd ist der Datenspeicher, der zum Erstellen und Verwalten dieser Version der Wahrheit verwendet wird.
etcd erfüllt eine ähnliche Rolle für Cloud Foundry – die Open-Source-Multicloud-Platform-as-a-Service (PaaS) – und ist eine praktikable Option für die Koordinierung entscheidender System- und Metadaten über Cluster jeder verteilten Anwendung hinweg. Der Name „etcd“ stammt von einer Namenskonvention innerhalb der Linux-Verzeichnisstruktur: In UNIX sind alle Systemkonfigurationsdateien für ein einzelnes System in einem Ordner namens „/etc“ enthalten; „d“ steht für „distributed“.
Bleiben Sie mit dem Think-Newsletter über die wichtigsten – und faszinierendsten – Branchentrends in den Bereichen KI, Automatisierung, Daten und mehr auf dem Laufenden. Weitere Informationen finden Sie in der IBM Datenschutzerklärung.
Es ist keine leichte Aufgabe, als Daten-Rückgrat zu dienen, das eine verteilte Workload am Laufen hält. Aber etcd ist für diese Aufgabe konzipiert und von Grund auf mit den folgenden Eigenschaften ausgestattet:
Beachten Sie, dass die Leistung von etcd stark von der Geschwindigkeit der Speicherfestplatte abhängt und die Verwendung von SSDs in etcd-Umgebungen dringend empfohlen wird.
etcd basiert auf dem Konsensalgorithmus Raf, um die Konsistenz der Datenspeicher auf allen Knoten in einem Cluster sicherzustellen – Tabellen-Stakes für ein fehlertolerantes verteiltes System.
Raft erreicht diese Konsistenz über einen gewählten Leader-Knoten, der die Replikation für die anderen Knoten im Cluster, die sogenannten Followers, verwaltet. Der Leader nimmt Anfragen von den Clients an, die er dann an die Follower-Knoten weiterleitet. Sobald der Leiter festgestellt hat, dass die Mehrheit der Follower-Knoten jede neue Anfrage als Log-Einträge gespeichert hat, wendet er den Eintrag auf seinen lokalen Zustandsmaschinen an und gibt das Ergebnis dieser Ausführung – einen Schreibvorgang – an den Client zurück. Wenn die Follower abstürzen oder Netzwerkpakete verloren gehen, versucht der Leader es erneut, bis alle Follower alle Log-Einträge einheitlich gespeichert haben.
Wenn ein Follower-Knoten innerhalb eines angegebenen Zeitintervalls keine Nachricht vom Leader empfängt, wird eine Wahl abgehalten, um einen neuen Leader zu wählen. Der Follower erklärt sich selbst zum Kandidaten, und die anderen Follower stimmen für ihn oder einen anderen Knoten, je nach Verfügbarkeit. Sobald der neue Leader gewählt ist, beginnt er mit der Verwaltung der Replikation, und der Prozess wiederholt sich. Dieser Prozess ermöglicht es allen etcd-Knoten, hochverfügbare, konsistent replizierte Kopien des Datenspeichers aufrechtzuerhalten.
etcd gehört zu den Kern-Komponenten von Kubernetes und dient als primärer Schlüssel-Werte-Speicher für die Erstellung eines funktionierenden, fehlertoleranten Kubernetes-Clusters. Der Kubernetes-API-Server speichert die Zustandsdaten jedes Clusters in etcd. Kubernetes verwendet die „Watch“-Funktion von etcd, um diese Daten zu überwachen und sich bei Änderungen neu zu konfigurieren. Die Funktion „Watch“ speichert Werte, die den tatsächlichen und den idealen Zustand des Clusters repräsentieren, und kann eine Reaktion einleiten, wenn diese abweichen.
Einen Überblick über die Verwaltung von Clustern, Services und Worker-Knoten durch Kubernetes finden Sie in unserem Video „Kubernetes Explained“.
etcd wurde von demselben Team entwickelt, das für die Entwicklung von CoreOS Container Linux verantwortlich war, einem weit verbreiteten Container-Betriebssystem, das in großem Umfang effizient ausgeführt und verwaltet werden kann. Ursprünglich wurde etcd auf Raft aufgebaut, um mehrere Kopien von Container Linux gleichzeitig zu koordinieren und so einen ununterbrochenen Anwendungsbetrieb mit hoher Betriebszeit zu gewährleisten.
Im Dezember 2018 spendete das Team etcd an die Cloud Native Computing Foundation (CNCF), eine neutrale gemeinnützige Organisation, die den Quellcode, die Domänen, die gehosteten Dienste, die Cloud-Infrastruktur und anderes projektbezogenes Eigentum von etcd als Open Source Ressourcen für die Entwicklercommunity der containerbasierten Cloud betreut. CoreOS hat mit Red Hat fusioniert.
Andere Datenbanken wurden entwickelt, um koordinierte Informationen zwischen verteilten Anwendungsclustern zu verwalten. Die beiden am häufigsten mit etcd verglichenen sind ZooKeeper und Consul.
ZooKeeper wurde ursprünglich entwickelt, um Konfigurationsdaten und Metadaten in Apache Hadoop-Clustern zu koordinieren. (Apache Hadoop ist ein Open-Source-Framework bzw. eine Sammlung von Anwendungen zum Speichern und Verarbeiten großer Datenmengen auf Clustern handelsüblicher Hardware.) ZooKeeper ist älter als etcd und die Erkenntnisse aus der Arbeit mit ZooKeeper haben das Design von etcd beeinflusst.
Als Ergebnis verfügt etcd über einige wichtige Funktionen, die ZooKeeper nicht bietet. Im Gegensatz zu ZooKeeper kann etcd beispielsweise Folgendes:
Consul ist eine Service-Networking-Lösung für verteilte Systeme, deren Funktionen irgendwo zwischen denen von etcd und dem Service-Mesh von Istio für Kubernetes liegen. Wie etcd umfasst Consul einen verteilten Schlüssel-Werte-Speicher, der auf dem Algorithmus Raft basiert und HTTP/JSON-Anwendungsprogrammierschnittstellen (APIs) unterstützt. Beide bieten eine dynamische Konfiguration der Cluster-Mitgliedschaft, aber Consul kontrolliert nicht so stark mehrere gleichzeitige Versionen von Konfigurationsdaten, und die maximale Datenbankgröße, mit der es zuverlässig funktioniert, ist kleiner.
Wie etcd ist auch Redis ein Open-Source-Tool, aber die grundlegenden Funktionen sind unterschiedlich.
Redis ist ein In-Memory-Datenspeicher und kann als Datenbank, Cache oder Nachrichtenbroker fungieren. Redis unterstützt eine größere Vielfalt an Datentypen und -strukturen als etcd und hat eine viel schnellere Lese-/Schreibleistung.
Aber etcd verfügt über eine höhere Fehlertoleranz, stärkere Failover- und kontinuierliche Datenverfügbarkeits-Funktionen und, was am wichtigsten ist, etcd speichert alle gespeicherten Daten auf einen Datenträger und opfert im Wesentlichen Geschwindigkeit zugunsten einer höheren Zuverlässigkeit und garantierten Konsistenz. Aus diesen Gründen eignet sich Redis besser als verteiltes Speicher-Caching-System als zum Speichern und Verteilen von Systemkonfigurationsinformationen.
Erstellen und verwalten Sie intelligente Streaming-Datenpipelines über eine intuitive grafische Benutzeroberfläche, die eine nahtlose Datenintegration in Hybrid- und Multicloud-Umgebungen ermöglicht.
Watsonx.data ermöglicht es Ihnen, Analysen und KI mit all Ihren Daten zu skalieren, unabhängig davon, wo sie sich befinden, und zwar über einen offenen, hybriden und kontrollierten Datenspeicher.
Erschließen Sie den Wert von Unternehmensdaten mit IBM Consulting® und bauen Sie ein erkenntnisgesteuertes Unternehmen auf, das Ihnen geschäftliche Vorteile verschafft.
