Ausführen von Solr mit Etcd: SolrCloud ohne Zookeeper?
Keine Empfehlung. Noch in der Experimentierphase. Nicht rigoros getestet. Benötigt Hilfe. Eingeschüchtert. Als ich letzte Woche unseren Blogbeitrag Apache Solr…
Keine Empfehlung. Noch in der Experimentierphase. Nicht rigoros getestet. Benötigt Hilfe. Eingeschüchtert.
Als ich letzte Woche unseren Blogbeitrag Apache Solr mit Kubernetes erneut las, dachte ich über die Möglichkeit nach, Kubernetes für die Erkennung von Diensten für Solr einzusetzen, anstatt ZooKeeper zu verwenden. Schließlich scheinen Kubernetes (über etcd) und ZooKeeper viele der gleichen Dinge zu tun. Könnte etcd vielleicht dafür sorgen, dass Solr schlanker und schneller läuft?
Der Gedanke, ZooKeeper aufzugeben, ist allerdings ein wenig beunruhigend. Jeder, der aus der Solr-Welt kommt, wird Ihnen sagen, wenn Sie versuchen, einen Solr-Cluster ohne ZooKeeper zu betreiben: „Viel Glück!“ ZooKeeper und Solr sind eng miteinander verbunden. Ich habe diese Meinung von einigen der besten Solr-Ingenieure der Welt gehört und die Leute, die das gesagt haben, haben in der Regel Recht.
Aber ich habe angefangen, über die Verwendung von etcd nachzudenken, der Service Discovery-Komponente von Kubernetes. Was wäre, wenn es eine ZooKeeper-ähnliche API für Solr gäbe, die ohne viel Nacharbeit mit etcd kommunizieren könnte? Zum Glück für uns alle hat jemand anderes bereits daran gedacht und sie entwickelt: die freundlichen Leute von etc-io (ehemals CoreOS). Sie haben eine Bibliothek namens zetcd entwickelt, die es Anwendungen ermöglicht, die ZooKeeper-APIs zu nutzen, allerdings mit einem etcd-Cluster im Rücken. So beschreibt das Team von etc-io zetcd:
Der zetcd-Proxy sitzt vor einem etcd-Cluster und bedient einen emulierten ZooKeeper-Client-Port, so dass unveränderte ZooKeeper-Anwendungen auf etcd laufen können. Im Großen und Ganzen nimmt zetcd die Anfragen der ZooKeeper-Clients auf, passt sie an das Datenmodell und die API von etcd an, gibt die Anfragen an etcd aus und sendet dann die übersetzten Antworten zurück an den Client. Die Leistung des Proxys ist konkurrenzfähig mit ZooKeeper selbst und vereinfacht die Verwaltung von ZooKeeper-Clustern mit den Funktionen und Werkzeugen von etcd.
Es war erschreckend einfach, Solr mit zetcd auszuführen.
Wie man Solr mit Zetcd ausführt
Das ist alles, was Sie tun müssen, um zetcd (die ZooKeeper-ähnliche Schicht über etcd in Kubernetes) zu starten:
Umgebung einrichten
Sie müssen Go installiert und die Umgebungsvariablen eingerichtet haben. Falls nicht, finden Sie unten in Schritt 1 ein Beispiel oder den Link im vorherigen Satz. Wenn Sie Go bereits installiert haben, können Sie mit Schritt 2 fortfahren.
Schritt 1 (Beispiel unter Mac OS X)
$ brew install go
$ export GOPATH="$HOME/go"
$ export PATH="$PATH:$GOPATH/bin"
Schritt 2
$ go get github.com/etcd-io/zetcd/cmd/zetcd
$ zetcd --zkaddr 0.0.0.0:2181 --endpoints localhost:2379
Solr im Standalone-Modus starten
Schritt 3
Starten Sie dann Solr im Standalone-Modus. Hier ist das Cloud-Beispiel:
$ bin/solr start -e cloud -z localhost:2181 -noprompt
Solr kommuniziert jetzt mit zetcd, das eigentlich etcd ist, aber Solr denkt, dass es mit ZooKeeper kommuniziert. So einfach ist das. Probieren Sie es aus und lassen Sie mich wissen, wie es läuft. Ich fange gerade erst an zu graben und muss noch viel lernen.
Einige Funktionen funktionieren nicht wie einige der Befehle, die Sie von der ZooKeeper-Befehlszeile gewohnt sind. Ein anderes, offensichtlicheres Problem ist die Tatsache, dass zetcd die CPU- und Heap-Größe nicht ausgibt. Ich bin dabei, die Gründe dafür zu ergründen und hoffe, dass wir sie bald beheben können. Offensichtlich weiß ich noch nicht, was ich nicht weiß.
Ich habe diese Integration noch nicht vollständig getestet, aber ich versuche es und wir erwarten, dass wir in den nächsten Tagen einige Rückmeldungen geben können. Für jede Hilfe wären wir Ihnen sehr dankbar. Diese Entwicklung könnte für Solr von großem Nutzen sein, denn sie bietet Unternehmen mehr Flexibilität bei der Bereitstellung der Anwendung oder bei der Entscheidung, ob sie Solr überhaupt verwenden wollen.
Marcus Eagan ist Software-Ingenieur in Palo Alto, Kalifornien, und Leiter der Abteilung Developer Advocacy bei Lucidworks. Folgen Sie Marcus auf Twitter @marcusforpeace.