1. Bereitstellung eines skalierbaren, verteilten Dateisystems mit GlusterFS
  2. Bereitstellen eines skalierbaren, verteilten Dateisystems mit GlusterFS

Bereitstellen eines skalierbaren, verteilten Dateisystems mit GlusterFS

Ein skalierbares, verteiltes Netzwerkdateisystem eignet sich für datenintensive Aufgaben wie Bildverarbeitung und Medien-Streaming. Bei Verwendung in High-Performance Computing-(HPC-)Umgebungen bietet GlusterFS leistungsstarken Zugriff auf große Datasets, insbesondere unveränderliche Dateien.

Architektur

Diese Referenzarchitektur enthält die Infrastrukturkomponenten, die für ein verteiltes Netzwerkdateisystem erforderlich sind. Er enthält drei Bare-Metal-Instanzen. Dies ist das Minimum für das Setup der High Availability für GlusterFS.

In einer Konfiguration mit drei Servern müssen mindestens zwei Server online sein, um Schreibvorgänge in das Cluster zu ermöglichen. Daten werden auf allen Knoten repliziert, wie im Diagramm dargestellt.

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

glusterfs-oci-oracle.zip

  • Region

    Eine Oracle Cloud Infrastructure-Region ist ein lokalisierter geografischer Bereich, der mindestens ein Data Center, sogenannte Availability-Domains, enthält. Regionen sind unabhängig von anderen Regionen, und große Entfernungen können sie (über Länder oder sogar Kontinente) trennen.

  • Availability-Domain

    Availability-Domains sind eigenständige, unabhängige Data Center in einer Region. Die physischen Ressourcen in jeder Availability-Domain sind von den Ressourcen in den anderen Availability-Domains isoliert, was eine Fehlertoleranz bietet. Availability-Domains haben keine gemeinsame Infrastruktur wie Stromversorgung oder Kühlung oder das interne Availability-Domainnetzwerk. Daher ist es wahrscheinlich, dass sich ein Fehler in einer Availability-Domain auf die anderen Availability-Domains in der Region auswirkt.

  • Faultdomain

    Eine Fehlerdomain ist eine Gruppierung aus Hardware und Infrastruktur innerhalb einer Availability-Domain. Jede Availability-Domain hat drei Faultdomains mit unabhängiger Stromversorgung und Hardware. Wenn Sie Ressourcen auf mehrere Faultdomains verteilen, können Ihre Anwendungen physische Serverfehler, Systemwartung und Stromausfälle innerhalb einer Faultdomain tolerieren.

  • Virtuelles Cloud-Netzwerk und Subnetze

    Ein VCN ist ein anpassbares, softwaredefiniertes Netzwerk, das Sie in einer Oracle Cloud Infrastructure-Region einrichten. Wie herkömmliche Data Center-Netzwerke erhalten VCNs vollständige Kontrolle über Ihre Netzwerkumgebung. Ein VCN kann mehrere nicht überlappende CIDR-Blöcke haben, die Sie nach dem Erstellen des VCN ändern können. Sie können ein VCN in Subnetze segmentieren, die für eine Region oder eine Availability-Domain gelten können. Jedes Subnetz besteht aus einem fortlaufenden Adressbereich, der sich nicht mit den anderen Subnetzen im VCN überschneidet. Sie können die Größe eines Subnetzes nach dem Erstellen ändern. Ein Subnetz kann öffentlich oder privat sein.

    Diese Architektur verwendet zwei Subnetze: ein öffentliches Subnetz zum Erstellen der DMZ und zum Hosten des Bastionsservers sowie ein privates Subnetz zum Hosten der GlusterFS-Knoten.

  • Network Security Group (NSG)

    NSGs fungieren als virtuelle Firewalls für Ihre Cloud-Ressourcen. Mit dem Sicherheitsmodell "Null vertrauenswürdig" von Oracle Cloud Infrastructure wird der gesamte Traffic verweigert, und Sie können den Netzwerkverkehr innerhalb eines VCN kontrollieren. Eine NSG besteht aus einer Gruppe von Ingress- und Egress-Sicherheitsregeln, die nur für eine bestimmte Gruppe von VNICs in einem einzelnen VCN gelten.

  • Sicherheitsliste

    Für jedes Subnetz können Sie Sicherheitsregeln erstellen, die Quelle, Ziel und Typ des Traffics angeben, der im Subnetz und aus dem Subnetz zugelassen werden muss.

  • GFS-Knoten

    Dies sind die GlusterFS-Headends, wobei 1 TB Blockspeicher an jede Instanz angehängt sind.

  • /gfs-data

    In der Referenzarchitektur hängt der Client das Volume GlusterFS am Einhängepunkt /gfs-data ein, über den Ihre Anwendung auf das Dateisystem zugreift. Mehrere Server können parallel auf die Headend-Knoten zugreifen.

  • Bastion Host

    Der Bastionhost ist eine Compute-Instanz, die als sicherer, kontrollierter Einstiegspunkt in die Topologie von außerhalb der Cloud dient. Der Bastionhost wird in der Regel in einer demilitarisierten Zone (DMZ) bereitgestellt. Dadurch können Sie sensible Ressourcen schützen, indem Sie sie in privaten Netzwerken platzieren, auf die nicht direkt von außerhalb der Cloud zugegriffen werden kann. Die Topologie hat einen einzigen, bekannten Einstiegspunkt, den Sie regelmäßig überwachen und auditieren können. Sie können also vermeiden, die sensibleren Komponenten der Topologie freizugeben, ohne den Zugriff darauf zu beeinträchtigen.

Empfehlungen

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

  • GlusterFS-Architektur

    Diese Architektur verwendet replizierte GlusterFS-Volumes. Die Daten werden auf allen Knoten repliziert. Diese Konfiguration bietet die höchste Verfügbarkeit von Daten, verwendet aber auch den größten Speicherplatz. Wie im Architekturdiagramm dargestellt, wird File1 beim Erstellen über die Knoten repliziert.

    GlusterFS unterstützt die folgenden Architekturen. Wählen Sie eine Architektur, die Ihren Anforderungen entspricht:
    • Verteilte Volumes

      Diese Architektur ist die Standardkonfiguration GlusterFS und wird verwendet, um maximale Volume-Größe und Skalierbarkeit zu erhalten. Es gibt keine Datenredundanz. Wenn ein Block im Volumen ausfällt, führt dies zu einem vollständigen Datenverlust.

    • Replizierte Volumes

      Diese Architektur wird am häufigsten verwendet, wenn High Availability entscheidend ist. Datenverlustprobleme aufgrund von Ziegelmängeln werden vermieden, indem Daten über zwei oder mehr Ziegelsteine repliziert werden. Diese Referenzarchitektur verwendet die Konfiguration der replizierten Volumes.

    • Verteilte replizierte Volumes

      Diese Architektur ist eine Kombination aus verteilten und replizierten Volumes und wird verwendet, um größere Volume-Größen zu erhalten als ein repliziertes Volume und eine höhere Verfügbarkeit als ein verteiltes Volume. In dieser Konfiguration werden Daten auf eine Teilmenge der Gesamtzahl der Steine repliziert. Die Anzahl der Ziegel muss ein Vielfaches der Replikatanzahl sein. Beispiel: Vier Steine mit je 1 TB geben Ihnen einen verteilten Raum von 2 TB mit zweifacher Replikation.

    • Gestreifte Volumes

      Diese Architektur wird für große Dateien verwendet, die in kleinere Chunks unterteilt werden, und jeder Chunk wird in einem Block gespeichert. Die Last wird auf die Ziegel verteilt und die Datei kann schneller abgerufen werden, es ist jedoch keine Datenredundanz verfügbar.

    • Verteilte Stripesets

      Diese Architektur wird für große Dateien mit einer Verteilung über mehr Ziegelsteine verwendet. Der Kompromiss mit dieser Konfiguration besteht darin, dass Sie, wenn Sie die Volumengröße erhöhen möchten, Steine in Vielfachen der Stripe-Anzahl hinzufügen müssen.

  • Compute-Ausprägungen

    Diese Architektur verwendet eine Bare-Metal-Ausprägung (BM.Standard2.52) für alle GlusterFS-Knoten. Diese Bare-Metal-Compute-Instanzen verfügen über zwei physische NICs, die Traffic mit jeweils 25 Gbit/s per Push übertragen können. Die zweite physische NIC ist für den GlusterFS-Traffic dediziert.

  • Block Storage

    Diese Architektur verwendet 1 TB Blockspeicher. Wir empfehlen, einen Logical Volume Manager (LVM) zu konfigurieren, damit das Volume wachsen kann, wenn mehr Speicherplatz benötigt wird. Jedes Block-Volume ist für die Verwendung einer ausgewogenen Performance konfiguriert und stellt 35K-IOPS und 480 MB/s Durchsatz bereit.

  • Virtual Cloud Network (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 im VCN anhängen möchten. Verwenden Sie CIDR-Blöcke, die sich im standardmäßigen privaten IP-Adressbereich befinden.

    Wählen Sie CIDR-Blöcke, die sich nicht mit einem anderen Netzwerk überschneiden (in Oracle Cloud Infrastructure, Ihrem On-Premise-Data Center oder einem anderen Cloud-Provider), in dem Sie private Verbindungen einrichten möchten.

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

    Berücksichtigen Sie beim Entwerfen der Subnetze den Verkehrsfluss und die Sicherheitsanforderungen. Hängen Sie alle Ressourcen innerhalb einer bestimmten Ebene oder Rolle an dasselbe Subnetz an, das als Sicherheitsgrenze dienen kann.

  • Network Security Groups (NSGs)

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

  • Sicherheitslisten

    Verwenden Sie Sicherheitslisten, um Ingress- und Egress-Regeln zu definieren, die für das gesamte Subnetz gelten.

Überlegungen

  • Performance

    Um die beste Performance zu erzielen, verwenden Sie dedizierte NICs für die Kommunikation von der Anwendung an Ihre Benutzer und die GlusterFS-Headends. Verwenden Sie die primäre NIC für die Kommunikation zwischen Ihrer Anwendung und den Benutzern. Verwenden Sie die sekundäre NIC für die Kommunikation mit den GlusterFS-Headends. Sie können auch die Volume-Performance für Blockspeicher ändern, um IOPS und Durchsatz Ihrer Festplatte zu erhöhen oder zu verringern.

  • Verfügbarkeit

    Faultdomains 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 verwenden. Bei unternehmenskritischen Workloads sollten Sie verteilte Striping-Volumes GlusterFS verwenden.

  • Kostenfaktor
    Die Kosten für das GlusterFS-Deployment hängen von Ihren Anforderungen an die Datenträgerperformance und -verfügbarkeit ab:
    • Sie können zwischen folgenden Leistungsoptionen wählen: hohe Leistung, ausgeglichene Performance und niedrige Kosten.
    • Für eine höhere Verfügbarkeit benötigen Sie eine größere Anzahl von GlusterFS-Knoten und -Volumes.

Bereitstellen

Der für das Deployment dieser Referenzarchitektur erforderliche Code ist in GitHub verfügbar. Sie können den Code mit nur einem Klick in Oracle Cloud Infrastructure Resource Manager abrufen, 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 den Mandanten und die Benutzerzugangsdaten ein.

    2. Prüfen und akzeptieren Sie die Vertragsbedingungen.
    3. Wählen Sie die Region aus, in der Sie den Stack bereitstellen möchten.
    4. Befolgen Sie die Prompts und Anweisungen zum Erstellen des Stacks auf dem Bildschirm.
    5. Nachdem Sie den Stack erstellt haben, klicken Sie auf Terraform-Aktionen, und wählen Sie Planen 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 anschließend die Aktion Planen 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.
  • Mit der Terraform-CLI bereitstellen:
    1. Gehen Sie zu GitHub.
    2. Klonen Sie das Repository, oder laden Sie es auf Ihren lokalen Computer herunter.
    3. Befolgen Sie die Anweisungen im Dokument README.

Mehr anzeigen

Änderungslog

In diesem Log werden wichtige Änderungen aufgeführt: