Architektur: Lustre-Dateisystem in Google Cloud mit DDN EXAScaler

Last reviewed 2023-11-15 UTC

Dieses Dokument enthält eine Architekturanleitung, die Sie beim Entwerfen und Dimensionieren eines Lustre-Dateisystems für Hochleistungs-Computing-Arbeitslasten (HPC) unterstützt. Es bietet auch eine Übersicht über die Bereitstellung eines Lustre-Dateisystems in Google Cloud mithilfe von DDN EXAScaler.

Lustre ist ein paralleles Open-Source-Dateisystem, das Speicher mit hohem Durchsatz und niedriger Latenz für eng gekoppelte HPC-Arbeitslasten bietet. Sie können ein Lustre-Dateisystem zur Unterstützung von Zehntausenden von HPC-Clients und Petabyte an Speicher skalieren. EXAScaler Cloud ist eine Unternehmensversion von Lustre, die von DDN, einem Google-Partner, angeboten wird. Sie können EXAScaler Cloud in einer Hybrid-Cloud-Architektur bereitstellen, um Ihre lokale HPC-Kapazität zu erweitern. EXAScaler Cloud kann auch als Repository zum Speichern längerfristiger Assets aus einer lokalen EXAScaler-Bereitstellung dienen.

Die Anleitung in diesem Dokument richtet sich an Unternehmensarchitekten und technische Fachkräfte, die Speicher für HPC-Arbeitslasten in der Cloud entwerfen, bereitstellen und verwalten. In diesem Dokument wird davon ausgegangen, dass Sie ein konzeptionelles Verständnis von parallelen Dateisystemen haben. Außerdem sollten Sie die HPC-Anwendungsfälle kennen, für die parallele Dateisysteme wie Lustre ideal sind. Weitere Informationen finden Sie unter Parallele Dateisysteme für HPC-Arbeitslasten.

Übersicht über das Lustre-Dateisystem

Das folgende Diagramm zeigt die Architektur eines Lustre-Dateisystems:

Architektur eines Lustre-Dateisystems

Wie im Diagramm dargestellt, enthält die Architektur die folgenden Komponenten:

  • Verwaltungsserver (MGS) und Verwaltungsziele (MGT): Der MGS speichert und verwaltet Konfigurationsinformationen zu einem oder mehreren Lustre-Dateisystemen. Das Diagramm zeigt den MGS, der ein einzelnes Lustre-Dateisystem verwaltet. Der MGS stellt für die anderen Lustre-Komponenten in allen von ihm verwalteten Dateisystemen Konfigurationsinformationen bereit. Der MGS zeichnet Dateisystemkonfigurationslogs in Speichergeräten auf, die als MGTs bezeichnet werden.

  • Metadatenserver (MDS) und Metadatenziele (MDT): Die MDS-Knoten verwalten den Clientzugriff auf den Namespace eines Lustre-Dateisystems. Dieser Namespace enthält alle Metadaten des Dateisystems, z. B. die Verzeichnishierarchie, den Zeitpunkt der Dateierstellung und die Zugriffsberechtigungen. Die Metadaten werden auf Speichergeräten gespeichert, die als MDTs bezeichnet werden. Ein Lustre-Dateisystem hat mindestens einen MDS und ein MDT. Wenn Sie die Leistung von metadatenintensiven Arbeitslasten verbessern möchten, z. B. wenn Tausende von Clients Millionen kleiner Dateien erstellen und darauf zugreifen, können Sie dem Dateisystem weitere MDS-Knoten hinzufügen.

  • Objektspeicherserver (OSS) und Objektspeicherziele (OST): Die OSS-Knoten verwalten den Clientzugriff auf die Dateidaten, die in einem Lustre-Dateisystem gespeichert sind. Jede Datei wird als ein oder mehrere Lustre-Objekte gespeichert. Die Objekte werden entweder in einem einzelnen Speichergerät (OST genannt) oder per Striping auf mehreren OSS-Knoten und OSTs gespeichert. Ein Lustre-Dateisystem hat mindestens einen OSS und ein zugeordnetes OST. Sie können die Speicherkapazität und die Leistung des Dateisystems skalieren, indem Sie weitere OSS-Knoten und OSTs hinzufügen. Die Gesamtspeicherkapazität des Dateisystems ist die Summe der Speicherkapazitäten der OSTs, die an alle OSS-Knoten im Dateisystem angehängt sind.

  • Clients: Ein Lustre-Client ist ein Computerknoten, z. B. eine virtuelle Maschine (VM), der über einen Bereitstellungspunkt auf ein Lustre-Dateisystem zugreift. Der Bereitstellungspunkt bietet einen einheitlichen Namespace für das gesamte Dateisystem. Sie können ein Lustre-Dateisystem skalieren, um gleichzeitigen Zugriff von über 10.000 Clients zu unterstützen. Lustre-Clients greifen parallel auf alle MDS- und OSS-Knoten in einem Lustre-Dateisystem zu. Dieser parallele Zugriff trägt dazu bei, die Leistung des Dateisystems zu maximieren. Mit dem parallelen Zugriff können auch Hotspots im Speicher reduziert werden. Das sind Speicherorte, auf die viel häufiger zugegriffen wird als auf andere Orte. Hotspots sind in nicht parallelen Dateisystemen üblich und können zu einem Leistungsungleichgewicht zwischen Clients führen.

    Für den Zugriff auf ein Lustre-Dateisystem ruft ein Client das erforderliche Verzeichnis und die Dateimetadaten von einem MDS ab und liest oder schreibt dann Daten durch Kommunikation mit einem oder mehreren OSS-Knoten. Lustre bietet eine hohe Compliance mit POSIX-Semantik und ermöglicht allen Clients uneingeschränkten, parallelen Zugriff auf das Dateisystem.

Weitere Informationen zum Lustre-Dateisystem und zu seiner Funktionsweise finden Sie in der Lustre-Dokumentation.

Architektur von Lustre in Google Cloud

Das folgende Diagramm zeigt eine Architektur für die Bereitstellung eines Lustre-Dateisystems in Google Cloud:

Architektur des Lustre-Dateisystems in Google Cloud

Die in diesem Diagramm dargestellte Architektur enthält die folgenden Ressourcen. Alle Ressourcen werden in einem einzigen Google Cloud-Projekt bereitgestellt. Die Computing- und Speicherressourcen werden in einer einzigen Zone bereitgestellt.

  • Auf Compute Engine-VMs werden die MGS-, MDS- und OSS-Knoten sowie die Lustre-Clients gehostet. Sie können die Lustre-Clients auch in einem Google Kubernetes Engine-Cluster bereitstellen und das Dateisystem auf Compute Engine-VMs bereitstellen.

  • Die Architektur umfasst die folgenden Netzwerkressourcen:

    • Ein einzelnes VPC-Subnetz (Virtual Private Cloud), das für alle VMs verwendet wird.
    • Ein optionales Cloud NAT-Gateway und einen optionalen Cloud Router für ausgehenden Traffic von den privaten VMs zum Internet.
    • Optionale Firewallregeln, um eingehende SSH-Verbindungen zu allen VMs in der Topologie zuzulassen.
    • Eine optionale Firewallregel, die HTTP-Zugriff aus dem Internet auf die DDN EXAScaler-Webkonsole auf dem MGS zulässt.
    • Eine Firewall, die TCP-Verbindungen zwischen allen VMs zulässt.

  • Nichtflüchtige Speicher bieten Speicherkapazität für die MGS-, MDS- und OSS-Knoten. Wenn Sie keinen nichtflüchtigen Speicher benötigen, können Sie ein Scratch-Dateisystem mithilfe von lokalen SSD-Laufwerken (Solid State Drive) erstellen, die mit den VMs verbunden sind.

    Google hat IO500-Einträge bereitgestellt, die die Leistungsfähigkeit von nichtflüchtigen und Scratch-Dateisystemen von Lustre zeigen. Erfahren Sie mehr über das Lustre-basierte Scratch-Dateisystem von Google Cloud mit über 10 Tbit/s im IO500-Ranking von HPC-Speichersystemen.

Gestaltungsrichtlinien

Anhand der folgenden Richtlinien können Sie ein Lustre-Dateisystem entwerfen, das die Anforderungen Ihrer HPC-Arbeitslasten erfüllt. Die Richtlinien in diesem Abschnitt sind nicht vollständig. Sie bieten ein Framework, mit dem Sie die Speicheranforderungen Ihrer HPC-Arbeitslasten bewerten, die verfügbaren Speicheroptionen evaluieren und die Größe Ihres Lustre-Dateisystems festlegen können.

Arbeitslastanforderungen

Ermitteln Sie die Speicheranforderungen Ihrer HPC-Arbeitslasten. Definieren Sie die Anforderungen so detailliert wie möglich und berücksichtigen Sie auch Ihre zukünftigen Anforderungen. Verwenden Sie die folgenden Fragen als Ausgangspunkt, um die Anforderungen Ihrer Arbeitslast zu ermitteln:

  • Welche Anforderungen gelten für Durchsatz und E/A-Vorgänge pro Sekunde (IOPS)?
  • Wie viel Speicherkapazität benötigen Sie?
  • Was ist Ihr wichtigstes Designziel: Durchsatz, IOPS oder Speicherkapazität?
  • Benötigen Sie nichtflüchtigen Speicher, Scratch-Speicher oder beides?

Speicheroptionen

Für die kostengünstigsten Speicheroptionen stehen folgende Arten von Persistent Disks zur Verfügung:

  • Standardmäßige Persistent Disks (pd-standard) sind die kostengünstigste Option, wenn die Speicherkapazität das wichtigste Designziel ist. Sie bieten effizienten und zuverlässigen Blockspeicher mithilfe von Festplatten (HDD).
  • Nichtflüchtige SSD-Speicher (pd-ssd) sind die kostengünstigste Option, wenn Sie den IOPS-Wert maximieren möchten. Sie bieten schnellen und zuverlässigen Blockspeicher mithilfe von SSDs.
  • Abgestimmte nichtflüchtige Speicher (pd-balanced) sind die kostengünstigste Option, um den Durchsatz zu maximieren. Sie bieten kostengünstigen und zuverlässigen Blockspeicher mithilfe von SSDs.

Extrem nichtflüchtige Speicher (pd-extreme) können eine höhere Leistung bieten als die anderen Laufwerkstypen und Sie können den erforderlichen IOPS-Wert auswählen. pd-extreme kostet jedoch mehr als die anderen Laufwerkstypen.

Weitere Informationen zu der Leistungsfähigkeit von nichtflüchtigem Speicher finden Sie unter Blockspeicherleistung.

Als Scratch-Speicher können Sie sitzungsspezifische lokale SSDs verwenden. Lokale SSDs sind physisch mit dem Server verbunden, auf dem die VMs gehostet werden. Lokale SSDs bieten einen höheren Durchsatz und eine geringere Latenz als Persistent Disks. Die auf einer lokalen SSD gespeicherten Daten bleiben jedoch nur erhalten, bis die VM angehalten oder gelöscht wird.

Objektspeicherserver

Wenn Sie die Infrastruktur für die OSS-Knoten entwerfen, empfehlen wir Folgendes:

  • Wählen Sie für den Speicher einen geeigneten Persistent Disk-Typ entsprechend Ihren Anforderungen für Speicherkapazität, Durchsatz und IOPS aus.

    • Verwenden Sie pd-standard für Arbeitslasten, die folgende Anforderungen haben.
      • Die Arbeitslast benötigt eine hohe Speicherkapazität (z. B. mehr als 10 TB) oder sowohl einen hohen Lesedurchsatz als auch eine hohe Speicherkapazität.
      • E/A-Latenz ist nicht wichtig.
      • Ein niedriger Schreibdurchsatz ist akzeptabel.
    • Verwenden Sie pd-balanced für Arbeitslasten, die eine der folgenden Anforderungen haben:
      • Hoher Durchsatz bei geringer Kapazität.
      • Die geringe Latenz von SSD-basierten Laufwerken.
    • Verwenden Sie pd-ssd für Arbeitslasten, die einen hohen IOPS-Wert erfordern (entweder kleine E/A-Anfragen oder kleine Dateien).

  • Stellen Sie genügend Speicherkapazität bereit, um den erforderlichen IOPS-Wert zu erreichen. Prüfen Sie den Lese- und Schreib-IOPS-Wert, der von den einzelnen Laufwerkstypen bereitgestellt wird.

  • Verwenden Sie für die VMs einen Maschinentyp aus der N2- oder N2D-Maschinenfamilie. Diese Maschinentypen bieten eine vorhersehbare und kostengünstige Leistung.

  • Weisen Sie genügend vCPUs zu, um den erforderlichen Persistent Disk-Durchsatz zu erreichen. Der maximale Persistent Disk-Durchsatz pro VM beträgt 1,2 GB/s. Dieser Durchsatz kann mit 16 vCPUs erreicht werden. Beginnen Sie also mit einem Maschinentyp mit 16 vCPUs. Beobachten Sie die Leistung und weisen Sie mehr vCPUs zu, wenn Sie den IOPS-Wert skalieren müssen.

Metadatenserver

Die MDS-Knoten benötigen keine hohe Speicherkapazität zum Bereitstellen von Metadaten, sondern Speicher, der einen hohen IOPS-Wert unterstützt. Beim Entwerfen der Infrastruktur für die MMD-Knoten empfehlen wir Folgendes:

  • Verwenden Sie für Speicher pd-ssd, da dieser Persistent Disk-Typ auch bei niedriger Speicherkapazität einen hohen IOPS-Wert (30 IOPS pro GB) bietet.
  • Stellen Sie genügend Speicherkapazität bereit, um den erforderlichen IOPS-Wert zu erreichen.
  • Verwenden Sie für die VMs einen Maschinentyp aus der N2- oder N2D-Maschinenfamilie. Diese Maschinentypen bieten eine vorhersehbare und kostengünstige Leistung.
  • Weisen Sie genügend vCPUs zu, um den erforderlichen IOPS-Wert zu erreichen:
    • Verwenden Sie für Arbeitslasten mit niedriger Metadatenmenge 16 vCPUs.
    • Verwenden Sie für Arbeitslasten mit mittlerer Metadatenmenge 32 vCPUs.
    • Verwenden Sie für metadatenintensive Arbeitslasten 64 vCPUs. Beobachten Sie die Leistung und weisen Sie bei Bedarf weitere vCPUs zu.

Verwaltungsserver

Der MGS benötigt minimale Rechenressourcen. Es ist kein speicherintensiver Dienst. Beginnen Sie mit einem kleinen Maschinentyp für die VM (z. B. n2-standard-2) und einem pd-ssd-Laufwerk mit 128 GB zum Speichern und beobachten Sie die Leistung. Wenn die Antwort langsam ist, weisen Sie mehr vCPUs zu und erhöhen Sie die Laufwerkgröße.

Verfügbarkeit und Langlebigkeit

Wenn Sie nichtflüchtigen Speicher benötigen, bieten die Persistent Disk-Typen pd-standard und pd-balanced hochverfügbaren, langlebigen Speicher innerhalb einer Zone. Für die zonen- oder regionenübergreifende Persistenz können Sie die Daten mithilfe der Google Cloud CLI oder mit Storage Transfer Service in das kostengünstige Cloud Storage kopieren. Zur Reduzierung der Kosten für die Datenspeicherung in Cloud Storage können Sie selten aufgerufene Daten in einem Bucket der Nearline Storage- oderColdline Storage-Klasse speichern.

Wenn Sie für eine Scratch-Bereitstellung nur sitzungsspezifischen Speicher benötigen, verwenden Sie lokale SSDs als Datenlaufwerke für die OSS- und MDS-Knoten. Dieses Design bietet eine hohe Leistung mit der kleinsten Anzahl von OSS-VMs. Mit diesem Design können Sie im Vergleich zu den anderen Optionen auch ein optimales Kosten-Leistungs-Verhältnis erzielen.

Größenbeispiel für OSS-VMs

Die empfohlene Strategie für die Größenanpassung und Bereitstellung Ihres Lustre-Dateisystems besteht darin, genügend OSS-VMs bereitzustellen, um die Gesamtdurchsatzanforderung zu erfüllen. Erhöhen Sie dann die Speicherkapazität der OST-Laufwerke, bis Sie die erforderliche Speicherkapazität erreichen. Die in diesem Abschnitt verwendete Beispielarbeitslast zeigt, wie Sie diese Strategie mithilfe der folgenden Schritte implementieren:

  1. Bestimmen Sie die Arbeitslastanforderungen.
  2. Wählen Sie einen Persistent Disk-Typ aus.
  3. Berechnen Sie die Anzahl der OSS-VMs.
  4. Berechnen der Laufwerkgröße pro VM.
  5. Legen Sie die Anzahl der vCPUs pro VM fest.

Arbeitslastanforderungen ermitteln

In diesem Beispiel erfordert die Arbeitslast 80 TB an nichtflüchtigem Speicher mit einem Lesedurchsatz von 30 GB/s.

Persistent Disk-Typ auswählen

Wie im Abschnitt Speicheroptionen erläutert, ist pd-standard die kostengünstigste Option, wenn die Speicherkapazität das wichtigste Designziel ist, und pd-balanced die kostengünstigste Option zur Maximierung des Durchsatzes. Der maximale Durchsatz ist je nach Laufwerkstyp unterschiedlich und der Durchsatz wird mit der Laufwerkgröße skaliert.

Berechnen Sie für jeden Persistent Disk-Typ, der für diese Arbeitslast verwendet werden kann, die Speicherkapazität, die für die Skalierung des Lesedurchsatzes auf das Ziel von 30 GB/s erforderlich ist.

Laufwerkstyp Lesedurchsatz pro TB Zum Erreichen des Zieldurchsatzes erforderliche Speicherkapazität
pd-standard 0,12 GB/s 30 geteilt durch 0,12 = 250 TB
pd-balanced 0,28 GB/s 30 geteilt durch 0,28 = 107 TB

Um den Ziellesedurchsatz von 30 GB/s mithilfe von pd-standard zu erreichen, müssen Sie 250 TB an Speicherkapazität bereitstellen. Dieser Wert liegt über dem Dreifachen der erforderlichen Kapazität von 80 TB. Für die Arbeitslast in diesem Beispiel bietet pd-balanced einen kostengünstigen Speicher, der die Leistungsanforderungen erfüllt.

Anzahl der OSS-VMs berechnen

Der maximale Lesedurchsatz pro Compute Engine-VM beträgt 1,2 GB/s. Teilen Sie den Ziellesedurchsatz durch den maximalen Durchsatz pro VM, um einen Zieldurchsatz von 30 GB/s zu erreichen:

   30 GBps / 1.2 GBps = 25

Sie benötigen 25 OSS-VMs, um den Ziellesedurchsatz zu erreichen.

Laufwerkgröße pro VM berechnen

Für die Berechnung der Laufwerkgröße pro VM teilen Sie die erforderliche Kapazität (107 TB) durch die Anzahl der VMs, die zum Erreichen des Zieldurchsatzes (30 GB/s) erforderlich ist:

   107 TB / 25 VMs = 4.3

Sie benötigen 4,3 TB an pd-balanced-Kapazität pro VM.

Anzahl der vCPUs pro VM bestimmen

Der Lesedurchsatz einer VM wird mit der Anzahl der vCPUs skaliert, die der VM zugewiesen sind. Der Lesedurchsatz beträgt maximal 1,2 Gbit/s für 16 oder mehr vCPUs. Sie benötigen einen Maschinentyp mit mindestens 16 vCPUs. Wählen Sie daher einen Maschinentyp aus der Maschinenfamilie N2 oder N2D aus, z. B. n2-standard-32.

Zusammenfassung der Konfiguration

In der Beispielarbeitslast gelten die folgenden Anforderungen:

  • 80 TB an nichtflüchtiger Speicherkapazität
  • 30 Gbit/s an Lesedurchsatz

Um die Anforderungen dieser Arbeitslast zu erfüllen, benötigen Sie die folgenden Rechen- und Speicherressourcen:

  • Anzahl der OSS-VMs: 25
  • VM-Maschinenfamilie: N2 oder N2D
  • Anzahl der vCPUs pro VM: 16 oder mehr
  • Persistent Disk-Typ: pd-balanced
  • Laufwerkgröße pro VM: 4,3 TB

Konfigurationsbeispiel für ein Scratch-Dateisystem

Die folgende Konfiguration basiert auf einem Google Cloud-Eintrag für IO500, der die Leistung eines extrem großen Scratch-Dateisystems zeigt, das Lustre verwendet und in Google Cloud bereitgestellt wird:

Konfigurationsparameter MDS OSS Clients
Anzahl der VMs 50 200 1.000
Maschinentyp n2-standard-80 n2-standard-64 c2-standard-16
Anzahl der vCPUs pro VM 80 vCPUs 64 vCPUs 16 vCPUs
RAM pro VM 320 GB 256 GB 64 GB
Betriebssystem CentOS 8 CentOS 8 CentOS 8
Netzwerkbandbreite 100 Gbit/s 75 Gbit/s 32 Gbit/s
Lokaler SSD-Speicher 9-TB-NVMe
(24 Laufwerke)		 9-TB-NVMe
(24 Laufwerke)		 –

Die vorhergehende Konfiguration bietet folgende Leistung:

Leistungsmesswert Folge
Durchsatz für Schreibvorgänge 700 GB/s (5,6 Tbit/s)
Durchsatz für Lesevorgänge 1.270 GB/s (10,16 Tbit/s)
Datei-stat()-Vorgänge 1,9 Millionen pro Sekunde
Lesevorgänge für kleine Dateien (3.901 Byte) 1,5 Millionen pro Sekunde

Optionen der Bereitstellung

In diesem Abschnitt erhalten Sie eine Übersicht über die Methoden, die Sie zum Bereitstellen eines EXAScaler Cloud-Dateisystems in Google Cloud verwenden können. In diesem Abschnitt werden auch die Schritte beschrieben, die beim Bereitstellen der Client-VMs auszuführen sind.

EXAScaler Cloud-Dateisystem-Bereitstellung

Sie können aus den folgenden Methoden auswählen, um ein EXAScaler Cloud-Dateisystem in Google Cloud bereitzustellen:

Bei beiden Methoden können Sie das Dateisystem bei der Bereitstellung anpassen. Sie können beispielsweise die Anzahl der OSS-VMs, den Maschinentyp für die VMs, die Persistent Disk-Typen und die Speicherkapazität angeben.

Beachten Sie bei der Auswahl einer Methode die folgenden Unterschiede:

  • Änderung nach der Bereitstellung: Wenn Sie das Cloud HPC Toolkit verwenden, können Sie das Dateisystem nach der Bereitstellung effizient ändern. Wenn Sie beispielsweise Speicherkapazität hinzufügen möchten, können Sie die Anzahl der OSS-Knoten erhöhen. Aktualisieren Sie dazu den Cloud-HPC-Toolkit-Blueprint und wenden Sie die generierte Terraform-Konfiguration noch einmal an. Eine Liste der Parameter, die Sie im Blueprint angeben können, finden Sie im Abschnitt Eingaben in der README-Datei für das Terraform-Modul. Um ein Dateisystem zu ändern, das mithilfe der Cloud Marketplace-Lösung bereitgestellt wird, müssen Sie die Änderungen für jede Computing- und Speicherressource einzeln über die Google Cloud Console, die gcloud CLI oder die API vornehmen.

  • Support: Die Cloud Marketplace-Lösung verwendet Deployment Manager, das von VPC Service Controls nicht unterstützt wird. Weitere Informationen zu dieser Einschränkung finden Sie unter Von VPC Service Controls unterstützte Produkte und Einschränkungen.

Clientbereitstellung

Sie können eine der im Abschnitt Bereitstellung des EXAScaler Cloud-Dateisystems beschriebenen Methoden verwenden, um die Client-VMs bereitzustellen. Google empfiehlt jedoch, Ihre Client-VMs getrennt vom Dateisystem bereitzustellen und zu verwalten. Die empfohlene Methode zum Bereitstellen Ihrer Clients ist die Verwendung des von Google bereitgestellten HPC-VM-Images, das für HPC-Arbeitslasten optimiert ist.

Im Folgenden finden Sie eine Übersicht über die Verwendung des HPC-VM-Images zum Bereitstellen von Lustre-Clients:

  1. Erstellen Sie eine VM mit dem HPC-VM-Image.
  2. Installieren Sie die Lustre-Clientpakete auf der VM.
  3. Passen Sie die VM nach Bedarf an.
  4. Erstellen Sie ein benutzerdefiniertes Image von der VM.
  5. Stellen Sie die Lustre-Client-VMs mit dem von Ihnen erstellten benutzerdefinierten Image bereit. Um die Bereitstellung und Verwaltung der Client-VMs zu automatisieren, können Sie eine verwaltete Instanzgruppe von Compute Engine oder ein Drittanbietertool wie Slurm Workload Manager verwenden.
  6. Stellen Sie das Lustre-Dateisystem auf den Client-VMs bereit.

Datenübertragungsoptionen

Nachdem Sie ein Lustre-Dateisystem in Google Cloud bereitgestellt haben, müssen Sie Ihre Daten in das Dateisystem verschieben. In der folgenden Tabelle sind die Methoden aufgeführt, mit denen Sie Daten in Ihr Lustre-Dateisystem verschieben können. Wählen Sie die Methode aus, die dem zu verschiebenden Datenvolumen und dem Speicherort Ihrer Quelldaten (lokal oder in Cloud Storage) entspricht.

Datenquelle Datengröße Empfohlene Datenübertragungsmethode
Lokal Klein (z. B. kleiner als 1 TB) Stellen Sie die Daten in Cloud Storage mit dem gsutil-Tool bereit. Laden Sie dann die Daten mithilfe von Storage Transfer Service oder mit der gcloud CLI in das Lustre-Dateisystem herunter.
Lokal Groß Verschieben Sie die Daten mithilfe von Storage Transfer Service in das Lustre-Dateisystem. Folgen Sie der Anleitung unter Daten zwischen POSIX-Dateisystemen übertragen.

Bei dieser Methode wird ein Cloud Storage-Zwischen-Bucket verwendet. Nach Abschluss des Übertragungsjobs löscht Storage Transfer Service die Daten im Zwischen-Bucket.
Cloud Storage Groß oder klein Laden Sie die Daten aus Cloud Storage mithilfe von Storage Transfer Service oder mit der gcloud CLI in das Lustre-Dateisystem herunter.

Nächste Schritte

Beitragende

Autor: Kumar Dhanagopal | Cross-product Solution Developer

Weitere Beitragende: