Skalierbares, verteiltes Dateisystem mit Lustre bereitstellen

Lustre ist ein offenes, paralleles, verteiltes Dateisystem, das für HPC-Cluster und -Umgebungen verwendet wird. Der Name Lustre ist ein Portmanteau von Linux und Cluster.

Mit Lustre können Sie einen HPC-Dateiserver auf Oracle Cloud Infrastructure Bare Metal Compute und netzwerkgebundenem Blockspeicher oder NVMe SSDs erstellen, die lokal mit Compute-Knoten verknüpft sind. Eine Terraform-Vorlage bietet eine einfache Möglichkeit, Lustre auf Oracle Cloud Infrastructure bereitzustellen.

Lustre-Clusterskala für höheren Durchsatz, höhere Speicherkapazität oder beides für das Dateisystem. Es kostet nur wenige Cent pro Gigabyte pro Monat für Compute und Speicher kombiniert.

Die Terraform-Deploymentvorlage stellt Oracle Cloud Infrastructure-Ressourcen zur Verfügung, einschließlich Compute, Storage, virtuelle Cloud-Netzwerke und Subnetze. Außerdem werden Lustre-Software bereitgestellt, darunter ein Management Server (MGS), ein Metadata Server (MDS), ein Object Storage Server (OSS) und Lustre-Clientknoten.

Architektur

Diese Referenzarchitektur verwendet eine Region mit einer einzelnen Availability-Domain und regionalen Subnetzen. Sie können dieselbe Referenzarchitektur in einer Region mit mehreren Availability-Domains verwenden. Wir empfehlen Ihnen, regionale Subnetze für Ihr Deployment zu verwenden, unabhängig von der Anzahl der Verfügbarkeitsdomains.

Das folgende Diagramm veranschaulicht diese Referenzarchitektur.

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

Die skalierbare Lustre-Architektur verfügt über folgende Komponenten:

  • Management Server (MGS)

    Ein MGS speichert Konfigurationsinformationen für ein oder mehrere Lustre-Dateisysteme und stellt diese Informationen anderen Lustre-Hosts zur Verfügung. Diese globale Ressource kann mehrere Dateisysteme unterstützen.

  • Metadatenserver (MDS)

    Ein MDS stellt den Index oder Namespace für ein Lustre-Dateisystem bereit. Der Metadateninhalt wird auf Volumes gespeichert, die Metadatenziele (MDTs) genannt werden. Die Verzeichnisstruktur und Dateinamen, Berechtigungen, erweiterte Attribute und Dateilayouts eines Lustre-Dateisystems werden auf MDTs aufgezeichnet. Jedes Lustre-Dateisystem muss mindestens ein MDT haben.

  • Object Storage Server (OSS)

    Ein OSS stellt den Massendatenspeicher für alle Dateiinhalte in einem Lustre-Dateisystem bereit. Jedes OSS bietet Zugriff auf eine Gruppe von Speicher-Volumes, sogenannte Object Storage Targets (OSTs). Jedes OST enthält mehrere binäre Objekte, die Daten für Dateien in Lustre darstellen. Dateien in Lustre bestehen aus einem oder mehreren OST-Objekten, zusätzlich zu den auf dem MDS gespeicherten Metadaten-Inodes.

  • Lustre Kunden

    Clients sind Compute-Instanzen, die auf das Lustre-Dateisystem zugreifen.

  • Virtuelles Cloud-Netzwerk (VCN) und Subnetze

    Ein VCN ist ein softwaredefiniertes Netzwerk, das Sie in einer Oracle Cloud Infrastructure-Region einrichten. VCNs können in Subnetze segmentiert werden, die für eine Region oder eine Availability-Domain spezifisch sein können. Sowohl regionsspezifische als auch Verfügbarkeitsdomainspezifische Subnetze können in demselben VCN nebeneinander bestehen. Ein Subnetz kann öffentlich oder privat sein.

  • Sicherheitslisten

    Für jedes Subnetz können Sie Sicherheitsregeln erstellen, die die Quelle, das Ziel und den Traffictyp angeben, die in und aus dem Subnetz zulässig sein müssen.

  • Verfügbarkeitsdomains

    Availability-Domains sind eigenständige, unabhängige Rechenzentren in einer Region. Die physischen Ressourcen in jeder Availability-Domain werden von den Ressourcen in den anderen Availability-Domains isoliert, was eine Fehlertoleranz bietet. Availability-Domains teilen keine Infrastruktur wie Strom oder Kühlung oder das interne Availability-Domainnetzwerk. Es ist daher unwahrscheinlich, dass der Ausfall einer Availability-Domain Auswirkungen auf andere Availability-Domains in der Region hat.

Empfehlungen

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

  • Compute Form, Bastion Host

    Mit einem Bastionshost können Sie auf beliebige Knoten im privaten Subnetz zugreifen. Verwenden Sie die VM.Standard.E2.1 - oder VM.Standard.E2.2-Form.

  • Compute Form, MGS und MDS

    Da der MGS nicht ressourcenintensiv ist, können Sie MGS und MDS auf derselben Instanz hosten. Um sicherzustellen, dass sich ein Ausfall auf Knotenebene nicht auf das Dateisystem auswirkt, verwenden Sie eine Bare-Metal-Instanz mit hoher Verfügbarkeit.

  • Bare Metal Compute mit Blockvolumen und hoher Verfügbarkeit

    Verwenden Sie BM.Standard2.52. Zwei Knoten sind in einem Paar konfiguriert. Die beiden physischen Netzwerkschnittstellen-Controller (NICs) mit jeweils 25-Gbps Netzwerkgeschwindigkeit. Verwenden Sie eine NIC für den gesamten Traffic, um den Speicher zu blockieren, und verwenden Sie die andere NIC für eingehende Daten auf den OSS- und MDS-Knoten von Clientknoten.

    Verwenden Sie Block-Volume-Speicher (Größe und Anzahl pro Deployment-Anforderung) mit mehreren Instanzen, um ein Volume an beide Compute-Knoten anzuhängen.

  • Compute Form, OSS

    Unsere Empfehlung für OSS ist die gleiche wie für MGS und MDS.

  • Compute Form, Lustre Client

    Wählen Sie eine virtuelle Maschinen-(VM-)Form basierend auf Ihren Bereitstellungsplänen, insbesondere Anforderungen an die Netzwerkbandbreite.

    Der Durchsatz der einzelnen Kunden hängt von der Kapazität ab. Wenn Sie 10 Clients mit 2.5-Gbps-Netzwerkbandbreite bereitstellen, beträgt die aggregierte Bandbreite 25 Gbps.

  • RAID-Konfiguration

    Optional können DenseIO-Formen mit RAID 0 konfiguriert werden.

    Verwenden Sie RAID beim Erstellen eines OST pro OSS.

    Wenn Sie ein OST pro OSS verwenden, empfehlen wir, acht Block-Volumes pro OSS zu verwenden, um den Durchsatz zu maximieren (RAID 0 ist optional).

    Hinweis:

    Die Terraform-Vorlage erstellt eine Bare-Metal-Form mit DenseIO oder mit Block-Volumes.
  • VCN

    Legen Sie beim Erstellen des VCN fest, wie viele IP-Adressen Ihre Cloud-Ressourcen in jedem Subnetz benötigen. Geben Sie mit der Notation Classless Inter-Domain Routing (CIDR) eine Subnetzmaske und einen Netzwerkadressbereich an, der für die erforderlichen IP-Adressen groß genug ist. Verwenden Sie einen Adressraum, der sich innerhalb der standardmäßigen privaten IP-Adressblöcke befindet.

    Wählen Sie einen Adressbereich, der sich nicht mit Ihrem On-Premise-Netzwerk überschneidet, damit Sie gegebenenfalls eine Verbindung zwischen VCN und Ihrem On-Premise-Netzwerk herstellen können.

    Nachdem Sie ein VCN erstellt haben, können Sie den Adressbereich nicht ändern.

    Wenn Sie die Subnetze entwerfen, berücksichtigen Sie Ihre Funktionalität und Sicherheitsanforderungen. Ordnen Sie alle Compute-Instanzen innerhalb derselben Ebene oder Rolle an dasselbe Subnetz zu, das als Sicherheitsgrenze dienen kann.

    Verwenden Sie regionale Subnetze.

  • Sicherheitslisten

    Verwenden Sie Sicherheitslisten, um Ingress- und Egressregeln zu definieren, die für das gesamte Subnetz gelten. Beispielsweise ermöglicht diese Architektur ICMP intern für das gesamte private Subnetz.

Überlegungen

  • Performance

    Um die beste Leistung zu erzielen, wählen Sie die richtige Compute Form mit entsprechender Bandbreite.

  • Verfügbarkeit

    Verwenden Sie eine High Availability-Option basierend auf Ihrer Deployment-Anforderung.

  • Kostenfaktor

    Bare Metal Service bietet eine höhere Leistung bei Netzwerkbandbreite für höhere Kosten. Bewerten Sie Ihre Anforderungen, um die entsprechende Compute Form auszuwählen.

  • Überwachung und Warnungen

    Richten Sie Überwachung und Alerts für die CPU- und Speichernutzung für Ihre MGS-, MDS- und OSS-Knoten ein, um die VM-Form bei Bedarf nach oben oder unten zu skalieren.

Bereitstellen

Der Terraform-Code für diese Referenzarchitektur ist als Beispielstapel in Oracle Cloud Infrastructure Resource Manager verfügbar. Sie können den Code auch von GitHub herunterladen und an Ihre spezifischen Anforderungen anpassen.

  • Deployment mit dem Beispielstack in Oracle Cloud Infrastructure Resource Manager:
    1. Klicken Sie aufIn Oracle Cloud bereitstellen.

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

    2. Prüfen und akzeptieren Sie die Allgemeinen Geschäftsbedingungen.
    3. Wählen Sie den Bereich, in dem Sie den Stack bereitstellen möchten.
    4. Befolgen Sie die Prompts und Anweisungen auf dem Bildschirm, um den Stack zu erstellen.
    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 aus.
  • Deployment mit dem Terraform-Code in GitHub:
    1. Gehen Sie zu GitHub.
    2. Klonen oder laden Sie das Repository auf Ihren lokalen Computer herunter.
    3. Befolgen Sie die Anweisungen im Dokument README.