Elasticsearch und Kibana bereitstellen

Elasticsearch ist eine Open-Source-Suchmaschine der Unternehmensklasse. Elasticsearch ist über eine umfangreiche API zugänglich und kann schnelle Suchen durchführen, die Ihre Datenerkennungsanwendungen unterstützen. Es kann Tausende von Servern skalieren und Petabyte von Daten aufnehmen. Seine große Kapazität resultiert direkt aus seiner aufwendigen, verteilten Architektur.

Die häufigsten Anwendungsfälle für Elasticsearch sind Analysen mit superschnellen Datenextraktionen aus strukturierten und unstrukturierten Datenquellen und Volltextsuche, die von einer umfangreichen Abfragesprache und automatischen Fertigstellung unterstützt wird.

Architektur

Diese Referenzarchitektur zeigt ein geclustertes Deployment von Elasticsearch und Kibana.

Beschreibung von elk-oci.png folgt
Beschreibung der Abbildung elk-oci.png

elk-oci.zip

Diese Architektur verfügt über folgende Komponenten:

  • Verfügbarkeitsdomains

    Availability-Domains sind eigenständige, unabhängige Rechenzentren innerhalb einer Region. Die physischen Ressourcen in jeder Availability-Domain werden von den Ressourcen in den anderen Availability-Domains isoliert, was eine Fehlertoleranz bietet. Verfügbarkeitsdomänen teilen keine Infrastruktur wie Strom oder Kühlung oder das interne Availability-Domänennetzwerk. Somit ist es unwahrscheinlich, dass ein Fehler bei einer Availability-Domain die anderen Availability-Domains in der Region beeinträchtigt.

  • Fault-Domains

    Eine Faultdomain ist eine Gruppierung von Hardware und Infrastruktur innerhalb einer Availability-Domain. Jede Availability-Domain verfügt über drei Fault-Domains mit unabhängiger Leistung und Hardware. Wenn Sie Ressourcen auf mehrere Faultdomains verteilen, können Ihre Anwendungen physischen Serverausfall, Systemwartung und Stromausfälle innerhalb einer Faultdomain tolerieren.

  • Bastionshost

    Der Bastionshost ist eine Compute-Instanz, die als sicherer, kontrollierter Einstiegspunkt zur Topologie von außerhalb der Cloud dient. Der Bastionshost wird normalerweise in einer entmilitarisierten Zone (DMZ) bereitgestellt. Dadurch können Sie sensible Ressourcen schützen, indem Sie sie in private Netzwerke platzieren, auf die Sie nicht direkt von außerhalb der Cloud zugreifen können. Die Topologie hat einen einzigen bekannten Einstiegspunkt, den Sie regelmäßig überwachen und auditieren können. So können Sie vermeiden, die sensibleren Komponenten der Topologie freizugeben, ohne den Zugriff auf sie zu beeinträchtigen.

  • Load Balancer

    Der Load Balancer gleicht Indexvorgänge mit den Datenknoten und Kibana-Zugriff auf die Masterknoten aus. Er verwendet zwei Listener, einen für Kibana und einen für den Indexdatenzugriff, wobei Masterknotenbackends und Datenknotenbackends verwendet werden. Der Load Balancer befindet sich in einem öffentlichen Subnetz mit einer öffentlichen IP-Adresse.

  • Masterknoten

    Masterknoten führen Clusterverwaltungsaufgaben aus, wie das Erstellen von Indizes und das Rebalancing von Shards. Sie speichern keine Daten. Drei Masterknoten (empfohlen für größere Cluster) werden über drei Faultdomains bereitgestellt, um eine hohe Verfügbarkeit zu gewährleisten.

  • Datenknoten

    Drei Datenknoten werden für hohe Verfügbarkeit über drei Faultdomains bereitgestellt. Wir empfehlen speicheroptimierte Compute-Instanzen, da Elasticsearch von der verfügbaren Speichermenge abhängt. Jeder Datenknoten ist mit einem 200 GiB-Blockspeicher konfiguriert. Neben VMs bietet Oracle Cloud Infrastructure leistungsstarke Bare-Metal-Instanzen, die in Clustern mit einer No-oversubscription 25 Gb-Netzwerkinfrastruktur verbunden sind. Diese Konfiguration garantiert eine geringe Latenz und einen hohen Durchsatz, die für hochleistungsfähige verteilte Streaming-Workloads sorgen.

  • Kibana

    Wie die Masterknoten hat Kibana relativ leichte Ressourcenanforderungen. Die meisten Berechnungen werden auf Elasticsearch verschoben. In diesem Deployment wird Kibana auf den Masterknoten ausgeführt.

Empfehlungen

Ihre Anforderungen können von der hier beschriebenen Architektur abweichen. Verwenden Sie die folgenden Empfehlungen als Ausgangspunkt.

  • VCN

    Wenn Sie ein VCN erstellen, bestimmen Sie die Anzahl der erforderlichen CIDR-Blöcke und die Größe jedes Blocks basierend auf der Anzahl der Ressourcen, die Sie an Subnetze in VCN anhängen möchten. Verwenden Sie CIDR-Blöcke, die sich innerhalb des standardmäßigen privaten IP-Adressraums befinden.

    Nachdem Sie ein VCN erstellt haben, können Sie die CIDR-Blöcke ändern, hinzufügen und entfernen.

    Wenn Sie die Subnetze entwerfen, berücksichtigen Sie Ihre Verkehrsfluss- und Sicherheitsanforderungen. Ordnen Sie alle Ressourcen innerhalb einer bestimmten Ebene oder Rolle an dasselbe Subnetz zu, das als Sicherheitsgrenze dienen kann.

    Verwenden Sie regionale Subnetze.

  • Netzwerksicherheitsgruppen (NSGs)

    Mit NSGs können Sie eine Gruppe von Ingress- und Egressregeln definieren, die für bestimmte VNICs gelten. Wir empfehlen, NSGs anstelle von Sicherheitslisten zu verwenden, da NSGs Ihnen ermöglichen, die Subnetzarchitektur von VCN von den Sicherheitsanforderungen Ihrer Anwendung zu trennen. In der Referenzarchitektur wird die gesamte Netzwerkkommunikation über NSGs gesteuert.

  • Block Storage

    Diese Architektur verwendet 200 GB Blockspeicher. Wir empfehlen Ihnen, einen logischen Volume Manager (LVM) zu konfigurieren, damit das Volume wachsen kann, wenn Sie mehr Speicherplatz benötigen. Jedes Block-Volume ist für die Verwendung einer ausgeglichenen Performance konfiguriert und bietet 35K IOPS und 480 MBps des Durchsatzes.

  • Compute Shapes

    Diese Architektur verwendet eine Virtual Machine Shape (VM.Standard2.24) für alle Datenknoten. Diese Compute-Instanzen können Traffic auf 25 Gbps pushen und 320 GB RAM bereitstellen.

Überlegungen

  • Performance

    Elasticsearch hängt von der verfügbaren Speichermenge ab. Um die beste Leistung zu erzielen, verwenden Sie Compute Shapes, die Ihnen eine gute Menge Speicher bieten. Sie können Bare-Metal-Formen verwenden, in denen Sie bis zu 768 GB RAM erhalten können.

  • Verfügbarkeit

    Fault-Domains bieten die beste Resilienz innerhalb einer Availability-Domain. Wenn Sie eine höhere Verfügbarkeit benötigen, sollten Sie mehrere Availability-Domains oder mehrere Regionen für Ihr Deployment verwenden.

  • Skalierbarkeit

    Obwohl Sie Master- und Datenknoten manuell skalieren können, empfehlen wir die Verwendung von Autoscaling, um die Chance zu minimieren, dass Services unter hohen Belastungen nach Ressourcen hungern. Eine automatische Skalierungsstrategie muss sowohl Master- als auch Datenknoten berücksichtigen.

  • Kostenfaktor

    Die Kosten Ihres Elasticsearch Deployments hängen von Ihren Anforderungen an Speicher und Verfügbarkeit ab. Die von Ihnen gewählten Compute-Formen wirken sich stärker auf die mit dieser Architektur verbundenen Kosten aus.

Bereitstellen

Der für das Deployment dieser Referenzarchitektur erforderliche Code ist in GitHub verfügbar. Sie können den Code mit einem einzigen Klick in Oracle Cloud Infrastructure Resource Manager ziehen, den Stack erstellen und bereitstellen. Alternativ können Sie den Code von GitHub auf Ihren Computer herunterladen, den Code anpassen und die Architektur mit der Terraform-CLI bereitstellen.

  • Mit Oracle Cloud Infrastructure Resource Manager bereitstellen:
    1. Klicken Sie auf In Oracle Cloud bereitstellen

      Wenn Sie noch nicht angemeldet sind, geben Sie die Mandanten- und Benutzerzugangsdaten ein.

    2. Lesen und akzeptieren Sie die Vertragsbedingungen.
    3. Wählen Sie den Bereich, in dem Sie den Stack bereitstellen möchten.
    4. Befolgen Sie die Anweisungen zum Erstellen des Stacks auf dem Bildschirm.
    5. Klicken Sie nach dem Erstellen des Stacks auf Terraform-Aktionen, und wählen Sie Plan aus.
    6. Warten Sie, bis der Job abgeschlossen ist, und prüfen Sie den Plan.

      Um Änderungen vorzunehmen, kehren Sie zur Seite "Stackdetails" zurück, klicken Sie auf Stack bearbeiten, und nehmen Sie die erforderlichen Änderungen vor. Führen Sie dann die Aktion Plan erneut aus.

    7. Wenn keine weiteren Änderungen erforderlich sind, kehren Sie zur Seite "Stackdetails" zurück, klicken Sie auf Terraform-Aktionen, und wählen Sie Anwenden.
  • Stellen Sie mit der Terraform-CLI bereit:
    1. Gehen Sie zu GitHub.
    2. Laden Sie den Code herunter oder klonen Sie ihn auf Ihren lokalen Computer.
    3. Befolgen Sie die Anweisungen in cluster/single-ad/README.md.

Änderungslog

In diesem Log werden nur die wesentlichen Änderungen aufgeführt: