Ausführen von Lucidworks Fusion 5 auf Azure Kubernetes

Lucidworks hat vor kurzem einen wichtigen Meilenstein für sein Flaggschiffprodukt Fusion erreicht, indem es erfolgreich auf eine Cloud-native Microservices-Architektur migriert hat, die von Kubernetes orchestriert wird (K8s). Das Ergebnis ist eine KI-gestützte Suchplattform, die einfach zu installieren, anzupassen, zu aktualisieren und zu skalieren ist, um auch die anspruchsvollsten Arbeitslasten zu erfüllen. Mit Fusion 5 können unsere Kunden die Anwendungsressourcen dynamisch verwalten, wenn die Auslastung schwankt, was eine bessere Kostenoptimierung in der Cloud ermöglicht.

Zeitgleich mit unserer Reise zu K8s haben die Cloud-Anbieter stark in verwaltete Angebote investiert, die die Komplexität des Kubernetes-Betriebs verringern. Natürlich gibt es einen großen Hype um K8s, aber nachdem ich fast ein Jahr mit dieser Plattform verbracht habe, bin ich davon überzeugt, dass es nur einen richtigen Weg gibt, um groß angelegte, verteilte Unternehmensanwendungen wie Lucidworks Fusion 5 zu betreiben: Kubernetes!

Ich habe meine Reise mit Kube auf der Google Kubernetes Engine (GKE) begonnen und bin in dieser Hinsicht verwöhnt worden, denn Google ist immer noch der klare Marktführer in diesem Bereich. Mit GKE macht Kubernetes Spaß und ist einfach! Aber als Anwendungsanbieter können wir unseren Kunden nicht vorschreiben, auf welcher Kube-Plattform sie arbeiten sollen, und in letzter Zeit haben wir ein wachsendes Interesse an Azure Kubernetes Service (AKS) festgestellt. Unser Ziel ist es, dass es einfach ist, mit Lucidworks Geschäfte zu machen.

Aus der Sicht von Fusion ist es für unsere Container dasselbe, sobald Kubernetes in Betrieb ist, da wir keine Cloud-Provider-spezifischen Abhängigkeiten in unserer Anwendung haben. Lassen Sie uns diese Behauptung testen, indem wir Fusion 5 auf AKS installieren und einige Daten aus Azure Blob Storage indizieren. Wenn Sie nicht direkt mit Kubernetes arbeiten möchten, lassen Sie Lucidworks Ihre geschäftskritischen Suchanwendungen für Sie ausführen mit unserem Managed Search a und Managed Fusion Angebote, die, wie Sie vielleicht schon erraten haben, auf K8s laufen.

Erste Schritte mit Fusion auf AKS

Wie bei jedem Cloud-Anbieter benötigen Sie ein Konto und müssen die Befehlszeilen-Tools installieren. Für Azure können Sie ein neues Konto einrichten, indem Sie die hier bereitgestellten Anweisungen verwenden.

Sobald Sie über ein Konto verfügen, müssen Sie das Tool azure-cli (az) anhand dieser Anweisungen installieren . Um zu überprüfen, ob Ihr Kontozugang und die Befehlszeilentools korrekt eingerichtet sind, führen Sie das az login aus (az login –help, um die verfügbaren Optionen zu sehen).

Als Anbieter von Kubernetes-Anwendungen steht Lucidworks vor der Entscheidung, wie die verschiedenen verwalteten K8s-Angebote wie GKE und AKS unterstützt werden sollen. Nach der Zusammenarbeit mit mehreren frühen Anwendern von Fusion 5 haben wir festgestellt, dass die meisten Betriebsteams selbst entscheiden wollen, wie sie Kubernetes-Cluster bereitstellen und konfigurieren.

Wir möchten aber auch interessierten Benutzern helfen, insbesondere denen, die nur wenig Erfahrung mit Kubernetes haben. Daher stellen wir Hilfsskripte für GKE, AKS und EKS im folgenden Github Repo zur Verfügung .

Die Skripte bieten eine Option zur Erstellung von Kubernetes-Clustern, die nur für Demo- / Proof-of-Concept-Zwecke geeignet sind.

Um diesem Artikel folgen zu können, klonen Sie bitte das fusion-cloud-native Repo, da Sie die setup_f5_aks.sh Skript in den folgenden Schritten ausführen müssen.

git clone https://github.com/lucidworks/fusion-cloud-native.git

Wenn Sie kein Git-Benutzer sind, laden Sie einfach die ZIP-Datei des Projekts herunter und entpacken Sie sie:

wget https://github.com/lucidworks/fusion-cloud-native/archive/master.zip

unzip master.zip && mv fusion-cloud-native-master fusion-cloud-native

Nehmen wir an, Ihr Arbeitsverzeichnis für den Rest dieses Blogs ist:

$HOME/fusion-cloud-native

Verwenden Sie Helm zur Verwaltung von Apps auf dem K8s Cluster

Helm ist ein beliebter Paketmanager für Kubernetes, der Sie bei der Installation und Verwaltung von Anwendungen auf Ihrem K8s-Cluster unterstützt. Unabhängig davon, welche Kubernetes-Plattform Sie verwenden, z.B. AKS, GKE, EKS, OpenShift, müssen Sie Helm installieren, da es für die Installation von Fusion erforderlich ist. Für diesen Beitrag verwende ich Helm V3 rc1 anstelle der neuesten stabilen Helm V2-Version.

[Tiller, die serverseitige Komponente von Helm V2, hat bekannte SicherheitsbedenkenDaher ist es üblich, dass K8s-Administratoren die Verwendung von Tiller nicht erlauben, insbesondere bei Produktionsclustern. Helm V3 verwendet Tiller aufgrund dieser Sicherheitsbedenken nicht. Daher wollte ich einige Erfahrungen damit sammeln, obwohl Helm V3 noch im Status eines Release Candidate ist. Um das klarzustellen: Tiller eignet sich hervorragend für die schnelle Installation von Helm-Diagrammen in Entwicklungs- und Testumgebungen und die Bedenken gelten hauptsächlich für die Produktion].

Laden Sie die neueste Version von Helm V3 hier herunter .

Ich verwende rc1 auf meinem Mac von hier.

Extrahieren Sie das Helm V3-Archiv in das Verzeichnis $HOME/fusion-cloud-native Verzeichnis, auf meinem Mac habe ich das zum Beispiel getan:

cd $HOME/fusion-cloud-native

wget https://get.helm.sh/helm-v3.0.0-rc.1-darwin-amd64.tar.gz

tar zxf helm-v3.0.0-rc.1-darwin-amd64.tar.gz

export PATH=$HOME/fusion-cloud-native/darwin-amd64:$PATH

helm version --short

Sie sollten etwas sehen wie: v3.0.0-rc.1+gee77ae3

Wenn Sie bereits Helm V2 verwenden, stellen Sie sicher, dass die ausführbare Datei von Helm V3 in Ihrem Pfad für diese Übung weiter vorne liegt.

Azure-Voraussetzungen

Um einen Cluster in AKS zu starten (oder so ziemlich alles mit Azure zu tun), müssen Sie eine Ressourcengruppe einrichten. Ressourcengruppen sind eine Möglichkeit, zusammenhängende Ressourcen in Azure zu organisieren und zu verwalten. Weitere Informationen über Ressourcengruppen finden Sie hier.

Sie müssen auch einen Ort wählen, an dem Sie Ihren AKS-Cluster aufsetzen wollen, z.B. westus2. Eine Liste der Orte, die Sie auswählen können, finden Sie hier.

Verwenden Sie die Azure-Konsole in Ihrem Browser, um eine Ressourcengruppe zu erstellen oder tun Sie es einfach:

az group create -g $AZURE_RESOURCE_GROUP -l $AZURE_LOCATION

Auf meiner Seite verwende ich AZURE_RESOURCE_GROUP=LW-Blog und AZURE_LOCATION=westus2 aber Sie sollten einen geeigneten Namen und Standort für Ihre Umgebung wählen.

Zusammenfassend lässt sich sagen, dass Sie die folgenden Voraussetzungen erfüllen sollten:

• Azure Konto einrichten
• azure-cli (az) Befehlszeilen-Tools installiert
• az login funktioniert
• Klonen Sie das fusion-cloud-native Repo von github
• Helm V3 zu Ihrem Pfad für Ihre aktuelle Arbeitsshell hinzugefügt
• Erstellen Sie eine Azure-Ressourcengruppe und wählen Sie einen Standort für den Start des Clusters

Jetzt sind Sie bereit, einen AKS-Cluster zu starten und Lucidworks Fusion 5 zu installieren!

Cluster starten und Lucidworks Fusion installieren

Verwenden Sie das Skript aus dem fusion-cloud-native Repo und führen Sie den folgenden Befehl aus:

./setup_f5_aks.sh -c <CLUSTER_NAME> -p <AZURE_RESOURCE_GROUP> --preview

Um die vollständige Verwendung des Skripts zu sehen, tun Sie dies:

./setup_f5_aks.sh --help

Von meiner Seite aus bin ich gerannt:

./setup_f5_aks.sh -c lw-blog-1 -p LW-Blog --preview

Standardmäßig installiert unser Skript Fusion in den Standard-Namespace; denken Sie an einen K8s Namespace als virtueller Cluster innerhalb eines physischen Clusters. Sie können mehrere Instanzen von Fusion im selben Cluster in separaten Namespaces installieren. Bitte installieren Sie jedoch nicht mehr als eine Fusion-Version im selben Namensraum.

Sie können den Namensraum mit der Option -n außer Kraft setzen. Darüber hinaus verwendet unser Skript f5 für den Helm-Versionsnamen; Sie können diesen mit der Option -r anpassen. Helm verwendet den von Ihnen angegebenen Versionsnamen, um eine bestimmte Instanz einer Installation zu verfolgen, so dass Sie Updates und Rollback-Änderungen nur für diese bestimmte Version durchführen können.

Mit unserem Skript können Sie auch Vorschaufunktionen aktivieren, wie ich es hier getan habe, indem ich –previewdie in Kürze erscheinende Funktionen für AKS ermöglicht, wie z.B. die Bereitstellung eines Multi-Zone-Clusters über 3 Verfügbarkeitszonen für höhere Verfügbarkeitsgarantien. Weitere Informationen über die Funktion Availability Zone finden Sie hier . Sie müssen diese Funktionen nicht aktivieren, um Fusion auszuführen, aber ich wollte sehen, wie die automatische Skalierung und die Multi-AZ mit AKS funktionieren, da ich diese Funktionen bei GKE schätzen gelernt habe.

Es dauert eine Weile, bis AKS den neuen Cluster hochgefahren hat. Der Cluster wird aus drei Standard_D4_v3-Knoten bestehen, die über 4 CPUs und 16 GB Speicher verfügen. Hinter den Kulissen ruft unser Skript einfach die az aks erstellen Befehl. Azure hat mir anfangs eine lächerliche CPU-Quote von 10 CPU auferlegt und ich musste eine Support-Anfrage stellen, um sie zu erhöhen, ymmv. Ehrlich gesagt hatte ich noch nie so viel Mühe, einen Cloud-Anbieter dazu zu bringen, mich mehr Geld für seine Plattform ausgeben zu lassen! Alternativ können Sie den Parameter -y mit unserem Skript verwenden, um die Anzahl der angeforderten Knoten zu verringern, z. B. -y 2.

Sobald der Cluster online ist, verwendet das Skript Helm, um das neueste Fusion 5 Helm-Diagramm aus unserem öffentlichen Repository zu ziehen. Das Helm-Diagramm enthält Definitionen für alle Dienste, Einsätze, Zustandsdaten und so weiter. Die öffentlichen Docker-Images für die Fusion-Dienste werden in Docker Hub gehostet.

Unser Skript wartet auf den erfolgreichen Rollout des Fusion API Gateway-Dienstes, was 7-8 Minuten dauern kann, da AKS die Images von DockerHub herüberziehen muss. Sobald unser Skript fertig ist, gibt es die externe IP-Adresse für den Fusion Gateway-Dienst aus, der die Authentifizierung, Autorisierung und das API-Routing für andere Fusion-Dienste übernimmt. Am Ende unseres Skripts sollten Sie eine Ausgabe ähnlich der folgenden sehen:

Der Fusion 5 Gateway-Dienst ist verfügbar unter: Irgendeine-externe-IP:6764

WARNUNG: Diese IP-Adresse ist ohne SSL für das WWW zugänglich! Dies geschieht zu Demonstrationszwecken und zur Vereinfachung der Installation. Wir empfehlen Ihnen dringend, einen K8s Ingress mit TLS zu konfigurieren, siehe hier.

Nachdem Sie einen Ingress konfiguriert haben, ändern Sie bitte den ‚Proxy‘-Dienst in einen ClusterIP anstelle von LoadBalancer

Wir haben das Fusion API Gateway auf einer externen IP-Adresse eingerichtet, um den Zugriff auf die Fusion Admin UI zu erleichtern. Sie sollten dies jedoch hinter einem Kubernetes-Ingress mit aktiviertem TLS abschließen, insbesondere bevor Sie sichere Daten in Fusion laden. Wir belassen es vorerst bei einer Übung für den ambitionierten Leser(https://docs.microsoft.com/en-us/azure/aks/ingress-basic) und fahren mit der Anmeldung bei der Fusion Admin UI über die exponierte IP auf Port 6764 fort.

Fusion mit Helm anpassen

Fusion ist von Haus aus gut konfiguriert, aber Sie können jede der integrierten Einstellungen mit einer yaml-Datei für benutzerdefinierte Werte anpassen. Wenn Sie eines unserer Einrichtungsskripte verwenden, wie z.B. setup_f5_aks.sheingeben, dann wird diese Datei beim ersten Start unter Verwendung der Namenskonvention für Sie erstellt:

<provider>_<cluster>_<relase>_fusion_values.yaml. 

Für meinen obigen Cluster hat das Skript Folgendes erstellt: aks_lw-blog-1_f5_fusion_values.yaml. Suchen Sie danach in dem Verzeichnis, in dem Sie das Skript ausgeführt haben. Halten Sie diese Datei griffbereit, denn Sie benötigen sie, um die Fusion-Einstellungen anzupassen und auf eine neuere Version zu aktualisieren.

Nehmen Sie sich einen Moment Zeit, um die yaml-Datei mit den benutzerdefinierten Werten durchzusehen, die das Skript für Ihren Cluster erstellt hat. Bei lange laufenden Clustern, z.B. in der Produktion, sollten Sie diese Datei in der Versionskontrolle aufbewahren, damit Sie eine Aufzeichnung der an der Fusion-Installation vorgenommenen Änderungen haben.

Zu diesem Zeitpunkt sollte Fusion in AKS laufen. Führen Sie den folgenden Befehl aus, um eine Liste der Pods für Fusion anzuzeigen:

kubectl get pods -l app.kubernetes.io/part-of=fusion

Hier sehen Sie einen Blick auf einige der Fusion-Pods, die im AKS-Cluster laufen:

Einen Überblick über die verschiedenen Fusion 5-Microservices finden Sie hier.

Wenn Sie Fusion zum ersten Mal starten, müssen Sie ein Passwort für den Benutzer „admin“ eingeben. Sobald Sie eingeloggt sind, müssen Sie eine neue Fusion-App erstellen, wie im folgenden Screenshot gezeigt:

Das Erstellen einer neuen App kann mehr als eine Minute dauern, da eine Reihe von Solr-Sammlungen, Spark-Jobs und Pipelines erstellt werden.

Vorschau auf mehrere Availability Zones

Erinnern Sie sich, dass ich beim Start meines Clusters die Option –preview Option übergeben, die die Multizonenfunktion für AKS mit der –node-zones 1 2 3 an den Befehl az aks erstellen Befehl. Wenn Sie mehr als einen Knoten gestartet haben, sollten Sie mehrere Solr-Pods haben, die auf die Knoten in Ihrem Cluster verteilt sind. Überprüfen Sie dies mit:

kubectl get pods -l app.kubernetes.io/name=solr -o wide

Eine coole Sache, die das Fusion Helm Diagramm macht, ist das Setzen der solr_zone Java System-Eigenschaft auf jedem Solr-Pod. Um dies zu bestätigen, verwenden Sie kubectl, um auf einen laufenden Solr-Pod zu portieren:

kubectl port-forward f5-solr-0 8983

Suchen Sie insbesondere nach der Option -Dsolr_zone unter Args auf dem Solr Dashboard. Sie sollte auf eine der Verfügbarkeitszonen in AKS eingestellt sein. Das Fusion-Diagramm legt diese Eigenschaft fest, so dass Sie sie nutzen können, um die Platzierung von Replikaten für eine Sammlung mit automatischen Skalierungsrichtlinien zu steuern, z.B:

{"replica":"#EQUAL", "shard":"#EACH", "sysprop.solr_zone":"#EACH"}

Es nützt uns nichts, Kubernetes-Knoten über Zonen hinweg für HA bereitzustellen, wenn Solr Repliken für eine Sammlung auf Knoten in derselben Zone platziert.

Wenn Sie mehr über den Betrieb von Solr in Kubernetes erfahren möchten, lesen Sie meinen früheren Artikel.

Daten aus Azure Blob Storage laden

Eine leere Fusion-Installation ist nicht sehr interessant, lassen Sie uns den Fusion’s Parallel Bulk Loader Job (https://doc.lucidworks.com/fusion/5.8/557/parallel-bulk-loader), um einige Daten aus dem Azure Blob Storage-Dienst zu laden. Ich werde nicht darauf eingehen, wie Sie Daten in den Azure Blob Storage bekommen, sondern nur aufschieben das zu den Azure-Dokumenten. Generell macht Fusion 5 das Laden von Daten aus Cloud-Speichern wie S3, GCS und Azure zu einem Kinderspiel.

In meinem Azure-Konto habe ich eine Parquet-Datei mit simulierten Protokolldaten. Hinter den Kulissen verwendet unser Parallel Bulk Loader Spark, um Daten aus NoSQL-Datenquellen und Big Data-Dateisystemen wie Azure Blog Storage oder Data Lake zu importieren.

Wählen Sie in der App aks-test-1 die Option Jobs (unter dem Symbol, das wie eine Schublade aussieht ) und wählen Sie den Paralleler Bulk Loader wie unten zu sehen:

{
  "type": "parallel-bulk-loader",
  "id": "load_data",
  "format": "parquet",
  "path": "wasbs://datagen@lw1fusion1test1data.blob.core.windows.net/...parquet",
  "outputCollection": "aks-test-1",
  "defineFieldsUsingInputSchema": true,
  "sparkConfig": [
    {
      "key": "spark.hadoop.fs.wasbs.impl",
      "value": "org.apache.hadoop.fs.azure.NativeAzureFileSystem"
    },
    {
      "key": "spark.hadoop.fs.azure.account.key.lw1fusion1test1data.blob.core.windows.net",
      "value": "SECRET"
    }
  ],
  "shellOptions": [
    {
      "key": "--packages",
      "value": "org.apache.hadoop:hadoop-azure:2.7.3"
    },
    {
      "key": "--exclude-packages",
      "value": "com.fasterxml.jackson.core:jackson-core"
    }
  ]
}

Dies ist nur ein Beispiel, um zu zeigen, wie Sie Daten aus dem Azure Blob-Speicher mit dem wasbs-Dateisystem indizieren. Ändern Sie den Pfad zu einem Datensatz, den Sie indizieren möchten. Die wichtigsten Einstellungen in diesem Beispiel sind die –packages in shellOptions, um das wasbs-Dateisystem in Spark zu laden, sowie die Einstellungen spark.hadoop.fs.wasbs.impl und spark.hadoop.fs.azure.account.key.<storage_account_name>.blob.core.windows.net unter sparkConfig. Diese werden von Spark benötigt, um Daten von Azure zu lesen; siehe hier. Mit einer ähnlichen Konfiguration, die an Ihre Umgebung angepasst ist, sollten Sie in der Lage sein, Daten aus Azure Blob Storage oder Azure Data Lake zu laden.

Bevor ich zum Schluss komme, möchte ich noch darauf eingehen, wie Upgrades mit Fusion 5 funktionieren, da dies eine der verlockendsten Funktionen von K8s ist.

Upgrade von Fusion in Kubernetes

Eine der leistungsfähigsten Funktionen, die Kubernetes und eine Cloud-native Microservices-Architektur bieten, ist die Möglichkeit, ein rollendes Update auf einem Live-Cluster durchzuführen. Eines meiner Hauptziele bei der Entwicklung von Fusion 5 war es, Kunden die Möglichkeit zu geben, ein Upgrade von Fusion 5.x.y auf eine spätere Version 5.x.z auf einem Live-Cluster ohne Ausfallzeiten oder Unterbrechung des Dienstes durchzuführen.

Wenn Kubernetes ein Rolling Update für einen einzelnen Microservice durchführt, gibt es gleichzeitig eine Mischung aus alten und neuen Diensten im Cluster (in den meisten Fällen nur kurz) und Anfragen von anderen Diensten werden an beide Versionen weitergeleitet. Daher stellt Lucidworks sicher, dass alle Änderungen, die wir an unserem Dienst vornehmen, nicht die API-Schnittstelle beeinträchtigen, die anderen Diensten der gleichen 5.x-Reihe zur Verfügung steht. Wir stellen auch sicher, dass die gespeicherte Konfiguration in derselben 5.x-Release-Linie kompatibel bleibt.

Lucidworks veröffentlicht häufig kleinere Updates für einzelne Dienste, so dass unsere Kunden diese Upgrades nach eigenem Ermessen mit Helm einspielen können. Um Ihren Cluster jederzeit zu aktualisieren, tun Sie dies:

./setup_f5_aks.sh -c <CLUSTER_NAME> -p <AZURE_RESOURCE_GROUP> --upgrade

Das Skript bezieht automatisch die neuesten Diagramm-Updates aus unserem Helm-Repository und stellt alle erforderlichen Updates bereit, indem es einen Vergleich zwischen Ihrer aktuellen Installation und der neuesten Version von Lucidworks durchführt. Um zu sehen, was aktualisiert werden würde, können Sie die –dry-run Option zum Skript hinzufügen.

K8s übernimmt das Heben schwerer Lasten bei Installation, Upgrades und Skalierung

Wenn Sie bis zu diesem Punkt mitgekommen sind, sollten Sie die neueste Fusion 5-Version auf AKS in Betrieb haben und hoffentlich einige Ihrer Daten aus Azure Blob Storage indizieren können. Das ist ein großartiger Fortschritt und ich freue mich über meine Behauptung, dass, wenn Kubernetes erst einmal läuft, es bei Fusion nicht anders ist!

Das ist der Grund, warum ich Kubernetes für so leistungsfähig halte – große, verteilte Systeme können sich darauf verlassen, dass K8s die meisten der schweren Aufgaben rund um Installation, Upgrades und Skalierung übernimmt, zusätzlich zu den Cloud-Anbietern, die den Betrieb von Kubernetes einfacher denn je machen. Ich könnte wahrscheinlich noch weitere 10 Seiten damit verbringen, zu erklären, wie man Fusion auf Kube betreibt, aber heben wir uns das für einen anderen Artikel auf. Bis dahin: Gute Reise mit Fusion 5 und Kubernetes!