Stabiler und performanter: CoreOS kündigt etcd 3.3 an
CoreOS hat die Verfügbarkeit der Version 3.3 des Key-Value Store etcd angekündigt. Neben anderen Verbesserungen soll dieses einfache Datenbankmanagement-System stabiler und schneller arbeiten.
- Frank-Michael Schlede
Der Container-Spezialist CoreOS, der erst kürzlich von Red Hat übernommen wurde, hat in einem Blogeintrag die allgemeine Verfügbarkeit der Schlüssel-Werte-Datenbank etcd in der Version 3.3 angekündigt. Laut diesen Informationen beinhaltet das aktuelle Release Verbesserungen bei der im Backend zum Einsatz kommenden Datenbank, die Überprüfung von Datenkorruption und unter anderem auch einen neuen Client, der besser mit Netzwerk-Partitionen und Unterbrechungen der Netzwerkverbindungen umgehen kann. Auch eine v2 API Emulation ist Teil der Version 3.3 von etcd.
Neue Bolt-Datenbank im Backend
Die bisherigen Versionen von etcd haben zum lokalen Abspeichern der Daten auf jedem Knoten boltdb/bolt verwendet. Eine sehr einfache und schnelle Datenbankmaschine für Projekte, die keinen vollständigen Datenbank-Server wie Postgres oder MySQL benötigen. Nun kommt bei der Version 3.3 von etcd die erweiterte Version bbolt zum Einsatz, die aus einem Fork der bolt-Datenbank entstand. Sie steht unter coreos/bbolt zur Verfügung. Dieser Zweig beinhaltet Fehlerkorrekturen, Verbesserungen bei der Performance und Features, die in Bolt nicht zu finden sind. Dabei bleibt aber die Rückwärts-Kompatibilität zur Bolt-API vollständig erhalten, wie die Entwickler versichern.
Eine weitere Veränderung in der aktuellen Version von etcd, die von den Entwicklern besonders hervorgehoben wird, ist das verbesserte Client-Verhalten, hier als "Smart Client Balancer" bezeichnet. Bei den bisherigen Versionen war es so, dass der Client einfach versuchte, unterbrochene Netzwerkverbindungen wieder herzustellen. Waren die Knoten jedoch partitioniert (beispielsweise in Cluster-Installationen) oder die Knoten verwarfen die Netzwerkpakete einfach (Black Holes), dann hängten sich die Clients sehr leicht auf – was der Produktivität der Nutzer abträglich war. Deshalb haben die Entwickler laut eigenen Aussagen sehr viel Arbeit in den sogenannten Client Balancer gesteckt, der die wiederholten Versuche zum Neuaufbau einer Netzwerkverbindung deutlich effizienter abhandeln soll. Der implementierte Failover-Mechanismus im 3.3-Client sorgt somit für einen weitaus besseren Umgang mit unzuverlässigen Netzwerkverbindungen. (fms)
