In dieser Anleitung erfahren Sie, wie Sie einen Linux-basierten Kernel-Space Network File System (NFS)-Caching-Proxy in Compute Engine bereitstellen, konfigurieren und testen. Die in dieser Anleitung beschriebene Architektur wurde für ein Szenario entwickelt, in dem schreibgeschützte Daten auf Byte-Ebene von einem NFS-Ursprungsdateiserver synchronisiert (z. B. einem lokalen NFS-Dateiserver) oder nach Bedarf von einer primären Datenquelle (Source of Truth) mit mehreren schreibgeschützten Replikaten synchronisiert werden.
In dieser Anleitung wird vorausgesetzt, dass Sie mit den folgenden Themen vertraut sind:
- Benutzerdefinierte Versionen des Linux-Betriebssystems erstellen.
- Software mit Startskripts in Compute Engine installieren und konfigurieren.
- NFS-Dateisystem konfigurieren und verwalten.
Diese Architektur unterstützt keine Dateisperren. Die Architektur eignet sich am besten für Pipelines, die eindeutige Dateinamen zum Verfolgen von Dateiversionen verwenden.
Architektur
Die Architektur in dieser Anleitung hat einen NFS-Daemon für den Kernel-Bereich (KNFSD), der als NFS-Proxy und -Cache fungiert. Diese Konfiguration ermöglicht Ihren cloudbasierten Computing-Knoten Zugriff auf lokalen, schnellen Speicher, indem Daten migriert werden, wenn ein NFS-Client sie anfordert. NFS-Clientknoten schreiben Daten direkt über den Schreib-Caching an den NFS-Ursprungsdateiserver. Das folgende Diagramm zeigt diese Architektur:
In dieser Anleitung stellen Sie das KNFSD-Proxysystem bereit und testen es. Sie erstellen und konfigurieren einen einzelnen NFS-Server, einen einzelnen KNFSD-Proxy und einen einzelnen NFS-Client in Google Cloud.
Das KNFSD-Proxysystem stellt ein Volume vom NFS-Server bereit und exportiert dieses Volume noch einmal. Der NFS-Client stellt das neu exportierte Volume aus dem Proxy bereit. Wenn ein NFS-Client Daten anfordert, prüft der KNFSD-Proxy seine verschiedenen Cache-Tabellen, um festzustellen, ob sich die Daten lokal befinden. Befinden sich die Daten bereits im Cache, werden sie vom KNFSD-Proxy sofort bereitgestellt. Befinden sich die angeforderten Daten nicht im Cache, migriert der Proxy die Daten, aktualisiert die Cache-Tabellen und stellt dann die Daten bereit. Der KNFSD-Proxy speichert sowohl Dateidaten als auch Metadaten auf Byte-Ebene im Cache, sodass nur die verwendeten Bytes übertragen werden, wenn sie angefordert werden.
Der KNFSD-Proxy hat zwei Cache-Ebenen: L1 und L2. L1 ist der Standardblock-Cache des Betriebssystems, das sich im RAM befindet. Wenn das Datenvolumen das verfügbare RAM überschreitet, wird der L2-Cache mit FS-Cache implementiert. Dies ist ein Linux-Kernel-Modul, das Daten lokal auf dem Laufwerk zwischenspeichert. In dieser Bereitstellung verwenden Sie eine lokale SSD als L2-Cache, obwohl Sie das System auf verschiedene Arten konfigurieren können.
Zur Implementierung der Architektur in dieser Anleitung verwenden Sie Standard-NFS-Tools, die mit den NFS-Versionen 2, 3 und 4 kompatibel sind.
KNFSD-Bereitstellung in einer Hybridarchitektur
In einer Hybridarchitektur fragen NFS-Clients, die in Google Cloud ausgeführt werden, bei Bedarf Daten an. Diese Anfragen werden an den KNFSD-Proxy gesendet, der Daten aus seinem lokalen Cache bereitstellt, sofern vorhanden. Befinden sich die Daten nicht im Cache, verwaltet der Proxy die Kommunikation mit den lokalen Servern. Das System kann einzelne oder mehrere NFS-Ursprungsserver bereitstellen. Der Proxy verwaltet die gesamte Kommunikation und Datenmigration, die über ein VPN oder Dedicated Interconnect zurück zu den lokalen NFS-Ursprungsservern erforderlich ist. Das folgende Diagramm zeigt diese KNFSD-Bereitstellung in einer Hybridarchitektur:
Hybridkonnektivität wird in dieser Anleitung nicht behandelt. Informationen zu erweiterten Themen wie die Bereitstellung in einer Hybridarchitektur, die Skalierung für hohe Leistung sowie die Verwendung von Messwerten und Dashboards zur Fehlerbehebung und Feinabstimmung finden Sie unterErweiterte Workflow-Themen.
Ziele
- KNFSD-Proxysystem bereitstellen und testen.
- Erstellen und konfigurieren Sie die folgenden Komponenten in Google Cloud:
- Benutzerdefiniertes Laufwerk-Image
- Ein KNFSD-Proxy
- NFS-Server
- Ein NFS-Client
- NFS-Proxy auf einem NFS-Client bereitstellen.
- Kopieren Sie eine Datei vom NFS-Server über den NFS-Proxy in den NFS-Client.
Kosten
In diesem Dokument verwenden Sie die folgenden kostenpflichtigen Komponenten von Google Cloud:
Mit dem Preisrechner können Sie eine Kostenschätzung für Ihre voraussichtliche Nutzung vornehmen.
Berücksichtigen Sie für Ihre Nutzung die Kosten für ausgehenden Netzwerktraffic für Daten, die von Google Cloud zurück in den lokalen Speicher geschrieben werden, sowie die Kosten für Hybridkonnektivität.
Vorbereitung
Für diese Referenzanleitung benötigen Sie ein Google Cloud-Projekt. Sie können ein neues Projekt erstellen oder ein vorhandenes Projekt auswählen:
-
In the Google Cloud console, on the project selector page, select or create a Google Cloud project.
-
Die Abrechnung für das Google Cloud-Projekt muss aktiviert sein.
-
Enable the Compute Engine API.
-
In the Google Cloud console, activate Cloud Shell.
Authentifizieren Sie Ihre Anmeldung im Cloud Shell-Terminal:
gcloud auth application-default login
Die Befehlszeile führt Sie durch die Schritte zur Autorisierung.
Legen Sie Umgebungsvariablen fest:
export GOOGLE_CLOUD_PROJECT=PROJECT_NAME gcloud config set project $GOOGLE_CLOUD_PROJECT
Ersetzen Sie
PROJECT_NAME
durch den Namen des Projekts, das Sie zuvor erstellt oder ausgewählt haben.
Nach Abschluss der in diesem Dokument beschriebenen Aufgaben können Sie weitere Kosten vermeiden, indem Sie die erstellten Ressourcen löschen. Weitere Informationen finden Sie unter Bereinigen.
Konfigurationsdateien der Anleitung herunterladen
Klonen Sie in Cloud Shell das GitHub-Repository:
cd ~/ git clone https://github.com/GoogleCloudPlatform/knfsd-cache-utils.git
Legen Sie das Git-Tag auf eine als funktionierend bekannte Version fest (in diesem Fall
v0.9.0
):cd ~/knfsd-cache-utils git checkout tags/v0.9.0
Wechseln Sie in Ihrem Code-Repository zum Verzeichnis
image
:cd ~/knfsd-cache-utils/image
Netzwerk konfigurieren
Zur Vereinfachung der Bereitstellung wird in dieser Anleitung das Standard-VPC-Netzwerk verwendet. Damit Sie über SSH eine Verbindung zu verschiedenen Ressourcen zu Konfigurations- und Monitoringzwecken herstellen können, werden in dieser Anleitung auch externe IP-Adressen bereitgestellt.
Best Practices und Referenzarchitekturen für das VPC-Design werden in dieser Anleitung nicht behandelt. Wenn Sie diese Ressourcen jedoch in eine Hybridumgebung einbinden, sollten Sie folgende Best Practices befolgen:
- Compute Engine-Ressourcen ohne externe IP-Adressen erstellen
- Konfigurieren Sie die Internetverbindung für private VMs, um Software zu konfigurieren.
- Verwenden Sie Identity-Aware Proxy (IAP) für die TCP-Weiterleitung, um eine Verbindung zu Ressourcen herzustellen.
So konfigurieren Sie Ihr Netzwerk:
Legen Sie in Cloud Shell die folgenden Variablen fest:
export BUILD_MACHINE_NETWORK=default export BUILD_MACHINE_SUBNET=default
NFS-Proxy-Build-Maschine erstellen
In diesem Abschnitt erstellen Sie eine VM, die als Ihre NFS-Proxy-Build-Maschine fungiert, und melden sich dann an. Anschließend führen Sie ein bereitgestelltes Installationsskript aus, um Kernel-Versionen zu aktualisieren und die gesamte erforderliche Software für das KNFSD-Proxysystem zu installieren. Die Ausführung des Softwareinstallationsskripts kann einige Minuten dauern. Sie müssen es jedoch nur einmal ausführen.
Legen Sie in Cloud Shell die folgenden Variablen fest:
export BUILD_MACHINE_NAME=knfsd-build-machine export BUILD_MACHINE_ZONE=us-central1-a export IMAGE_FAMILY=knfsd-proxy export IMAGE_NAME=knfsd-proxy-image
Starten Sie die VM-Instanz:
gcloud compute instances create $BUILD_MACHINE_NAME \ --zone=$BUILD_MACHINE_ZONE \ --machine-type=n1-standard-16 \ --project=$GOOGLE_CLOUD_PROJECT \ --image=ubuntu-2004-focal-v20220615 \ --image-project=ubuntu-os-cloud \ --network=$BUILD_MACHINE_NETWORK \ --subnet=$BUILD_MACHINE_SUBNET \ --boot-disk-size=20GB \ --boot-disk-type=pd-ssd \ --metadata=serial-port-enable=TRUE
Möglicherweise wird eine Warnmeldung angezeigt, die auf eine Diskrepanz der Laufwerksgröße hinweist. Sie können diese Nachricht ignorieren.
Erstellen Sie eine TAR-Datei mit der zu installierenden erforderlichen Software und kopieren Sie diese auf Ihren Build-Computer:
tar -czf resources.tgz -C resources . gcloud compute scp resources.tgz build@$BUILD_MACHINE_NAME: \ --zone=$BUILD_MACHINE_ZONE \ --project=$GOOGLE_CLOUD_PROJECT
Öffnen Sie nach dem Start der VM einen SSH-Tunnel zu ihr:
gcloud compute ssh build@$BUILD_MACHINE_NAME \ --zone=$BUILD_MACHINE_ZONE \ --project=$GOOGLE_CLOUD_PROJECT
Nachdem der SSH-Tunnel eingerichtet wurde und die Befehlszeile auf die Instanz
knfsd-build-machine
ausgerichtet ist, führen Sie das Installationsskript aus:tar -zxf resources.tgz sudo bash scripts/1_build_image.sh
Das Skript klont das Ubuntu Kernel Code-Repository, aktualisiert die Kernel-Version und installiert zusätzliche Software. Da ein Repository-Klon beteiligt ist, kann die Ausführung des Skripts sehr lange dauern.
Nachdem das Installationsskript beendet ist und die Eingabeaufforderung
SUCCESS
angezeigt wird, starten Sie die Build-Maschine neu:sudo reboot
Wenn Ihr Build-Computer neu gestartet wird, werden die folgenden Meldungen angezeigt:
WARNING: Failed to send all data from [stdin] ERROR: (gcloud.compute.ssh) [/usr/bin/ssh] exited with return code [255]
Diese Fehler werden angezeigt, während Cloud Shell von Ihrem NFS-Proxy-Build-Rechner auf Ihren Host-Rechner umschaltet. Sie können diese Fehler ignorieren.
Öffnen Sie nach dem Neustart der VM noch einmal einen SSH-Tunnel zu ihr:
gcloud compute ssh $BUILD_MACHINE_NAME \ --zone=$BUILD_MACHINE_ZONE \ --project=$GOOGLE_CLOUD_PROJECT
Nachdem der SSH-Tunnel eingerichtet wurde und die Befehlszeile auf die Instanz
nfs-proxy-build
ausgerichtet ist, wechseln Sie zuRoot
und prüfen Sie die Version Ihres Betriebssystems:uname -r
Die Ausgabe sieht etwa so aus, was darauf hinweist, dass die Softwareupdates erfolgreich waren:
linux <$BUILD_MACHINE_NAME> 5.13.*-gcp ...
Wenn die Ausgabe nicht dem vorherigen Beispiel ähnelt, führen Sie diesen Vorgang aus, um die NFS-Proxy-Build-Maschine noch einmal zu erstellen.
Bereinigen Sie das lokale Laufwerk und fahren Sie die Build-Maschine herunter:
sudo bash /home/build/scripts/9_finalize.sh
Die folgenden Warnungen werden angezeigt:
userdel: user build is currently used by process 1431 userdel: build mail spool (/var/mail/build) not found
Diese Warnungen werden angezeigt, während Cloud Shell von Ihrem NFS-Proxy-Build-Rechner auf Ihren Host-Rechner umschaltet. Sie können diese Fehler ignorieren.
Benutzerdefiniertes Laufwerk-Image erstellen
In diesem Abschnitt erstellen Sie ein benutzerdefiniertes Image aus der Instanz. Das benutzerdefinierte Image wird in einem multiregionalen Cloud Storage-Bucket in den USA gespeichert.
Legen Sie in Cloud Shell die folgenden Variablen fest:
export IMAGE_NAME=knfsd-image export IMAGE_DESCRIPTION="first knfsd image from tutorial" export IMAGE_LOCATION=us
Erstellen Sie das Laufwerk-Image:
gcloud compute images create $IMAGE_NAME \ --project=$GOOGLE_CLOUD_PROJECT \ --description="$IMAGE_DESCRIPTION" \ --source-disk=$BUILD_MACHINE_NAME \ --source-disk-zone=$BUILD_MACHINE_ZONE \ --storage-location=$IMAGE_LOCATION
Nachdem das Laufwerk-Image erstellt wurde, löschen Sie die Instanz:
gcloud compute instances delete $BUILD_MACHINE_NAME \ --zone=$BUILD_MACHINE_ZONE
Wenn Sie zum Fortfahren aufgefordert werden, geben Sie
Y
ein.Wenn Sie die Instanz
$BUILD_MACHINE_NAME
löschen, werden Sie aufgefordert, die angehängten Laufwerke auf der VM zu löschen. Da Sie gerade ein benutzerdefiniertes Image gespeichert haben, benötigen Sie dieses temporäre Laufwerk nicht mehr und können es sicher löschen.
NFS-Ursprungsserver erstellen
Wie bereits erwähnt, ist diese Architektur so konzipiert, dass sie cloudbasierte Ressourcen mit einem lokalen Dateiserver verbindet. Zur Vereinfachung des Vorgangs in dieser Anleitung erstellen Sie eine eigenständige Ressource, die in Ihrem Google Cloud-Projekt ausgeführt wird, um diese Verbindung zu simulieren. Sie nennen die eigenständige Ressource nfs-server
. Die Softwareinstallation und -einrichtung ist in einem Startskript enthalten. Weitere Informationen finden Sie im Skript ~/knfsd-cache-utils/tutorial/nfs-server/1_build_nfs-server.sh
.
Wechseln Sie in Cloud Shell zum heruntergeladenen
nfs-server
-Skriptverzeichnis:cd ~/knfsd-cache-utils/tutorial
Erstellen Sie Ihren eigenständigen NFS-Server:
gcloud compute \ --project=$GOOGLE_CLOUD_PROJECT instances create nfs-server \ --zone=$BUILD_MACHINE_ZONE \ --machine-type=n1-highcpu-2 \ --maintenance-policy=MIGRATE \ --image-family=ubuntu-2004-lts \ --image-project=ubuntu-os-cloud \ --boot-disk-size=100GB \ --boot-disk-type=pd-standard \ --boot-disk-device-name=nfs-server \ --metadata-from-file startup-script=nfs-server-startup.sh
Dieses Skript kann einige Minuten in Anspruch nehmen. Möglicherweise wird eine Warnmeldung angezeigt, dass Ihre Laufwerkgröße kleiner als 200 GB ist. Sie können diese Warnung ignorieren.
NFS-Proxy erstellen
In diesem Abschnitt erstellen Sie den NFS-Proxy. Wenn der Proxy gestartet wird, konfiguriert er lokalen Speicher, bereitet Bereitstellungsoptionen für den NFS-Server vor und exportiert die im Cache gespeicherten Ergebnisse. Ein bereitgestelltes Startskript orchestriert einen Großteil dieses Workflows.
Legen Sie in Cloud Shell die folgenden Variablen fest:
export PROXY_NAME=nfs-proxy
Erstellen Sie die VM
nfs-proxy
:gcloud compute instances create $PROXY_NAME \ --machine-type=n1-highmem-16 \ --project=$GOOGLE_CLOUD_PROJECT \ --maintenance-policy=MIGRATE \ --zone=$BUILD_MACHINE_ZONE \ --min-cpu-platform="Intel Skylake" \ --image=$IMAGE_NAME \ --image-project=$GOOGLE_CLOUD_PROJECT \ --boot-disk-size=20GB \ --boot-disk-type=pd-standard \ --boot-disk-device-name=$PROXY_NAME \ --local-ssd=interface=NVME \ --local-ssd=interface=NVME \ --local-ssd=interface=NVME \ --local-ssd=interface=NVME \ --metadata-from-file startup-script=proxy-startup.sh
Möglicherweise wird eine Warnmeldung angezeigt, dass Ihre Laufwerkgröße unter 200 GB liegt. Sie können diese Warnung ignorieren.
Das Startskript konfiguriert NFS-Bereitstellungsbefehle und ermöglicht Ihnen die Feinabstimmung des Systems. Die Einstellungen für NFS-Version, Synchronisierung oder asynchron,
nocto
undactimeo
sind einige der Variablen, die Sie möglicherweise über das Startskript optimieren möchten. Weitere Informationen zu diesen Einstellungen finden Sie unter NFS-Dateisystem optimieren.Mit dem Befehl in diesem Schritt wird das Flag
--metadata-from-file
definiert, das das Startskript in Ihre Image-Vorlage einfügt. In dieser Anleitung verwenden Sie ein einfachesproxy-startup.sh
-Skript. Das Skript enthält einige vordefinierte Variablen und umfasst nicht viele Optionen, die Sie verwenden können, wenn Sie die Pipeline in Ihre Pipeline einbinden. Informationen zu komplexeren Anwendungsfällen finden Sie im GitHub-Repositoryknfsd-cache-utils
.
NFS-Client erstellen
In diesem Schritt erstellen Sie einen einzelnen NFS-Client (mit dem Namen nfs-client
), der für eine wahrscheinlich größere verwaltete Instanzgruppe (MIG) einspringt.
Erstellen Sie in Cloud Shell Ihren NFS-Client:
gcloud compute \ --project=$GOOGLE_CLOUD_PROJECT instances create nfs-client \ --zone=$BUILD_MACHINE_ZONE \ --machine-type=n1-highcpu-8 \ --network-tier=PREMIUM \ --maintenance-policy=MIGRATE \ --image-family=ubuntu-2004-lts \ --image-project=ubuntu-os-cloud \ --boot-disk-size=10GB \ --boot-disk-type=pd-standard \ --boot-disk-device-name=nfs-client
Möglicherweise wird eine Warnmeldung angezeigt, dass Ihre Laufwerkgröße unter 200 GB liegt. Sie können diese Warnung ignorieren.
NFS-Proxy auf dem NFS-Client bereitstellen
In diesem Schritt öffnen Sie eine separate SSH-Sitzung auf Ihrem NFS-Client und stellen dann den NFS-Proxy bereit. Sie verwenden dieselbe Shell zum Testen des Systems im nächsten Abschnitt.
Rufen Sie in der Google Cloud Console die Seite VM-Instanzen auf.
Klicken Sie in der Spalte Verbinden auf SSH, um eine Verbindung zu
nfs-client
herzustellen.Installieren Sie im
nfs-client
-SSH-Fenster die erforderlichen NFS-Tools innfs-client
:sudo apt-get install nfs-common -y
Erstellen Sie einen Bereitstellungspunkt und stellen Sie den NFS-Proxy bereit:
sudo mkdir /data sudo mount -t nfs -o vers=3 nfs-proxy:/data /data
Das System testen
Alle Ressourcen wurden erstellt. In diesem Abschnitt führen Sie einen Test durch, indem Sie eine Datei vom NFS-Server über den NFS-Proxy in den NFS-Client kopieren. Wenn Sie diesen Test zum ersten Mal ausführen, stammen die Daten vom Ursprungsserver. Dieser Vorgang kann über eine Minute dauern.
Wenn Sie diesen Test das zweite Mal ausführen, werden die Daten aus einem Cache bereitgestellt, der auf den lokalen SSDs des NFS-Proxys gespeichert ist. Bei dieser Übertragung dauert das Kopieren von Daten deutlich weniger Zeit. Dadurch wird bestätigt, dass das Caching die Datenübertragung beschleunigt.
Kopieren Sie in dem SSH-Fenster
nfs-client
, das Sie im vorherigen Abschnitt geöffnet haben, die Dateitest
und sehen Sie sich die entsprechende Ausgabe an:time dd if=/data/test.data of=/dev/null iflag=direct bs=1M status=progress
Die Ausgabe sieht ähnlich aus wie die folgende, die eine Zeile mit der Dateigröße, der Übertragungszeit und der Übertragungsgeschwindigkeit enthält:
10737418240 bytes (11 GB, 10 GiB) copied, 88.5224 s, 121 MB/s real 1m28.533s
Bei dieser Übertragung wird die Datei vom nichtflüchtigen Speicher des NFS-Servers bereitgestellt, sodass sie durch die Geschwindigkeit des Laufwerks des NFS-Servers begrenzt ist.
Führen Sie denselben Befehl ein zweites Mal aus:
time dd if=/data/test.data of=/dev/null iflag=direct bs=1M status=progress
Die Ausgabe sieht ähnlich aus wie die folgende, die eine Zeile mit der Dateigröße, der Übertragungszeit und der Übertragungsgeschwindigkeit enthält:
10737418240 bytes (11 GB, 10 GiB) copied, 9.41952 s, 948 MB/s real 0m9.423s
Bei dieser Übertragung wird die Datei aus dem Cache im NFS-Proxy bereitgestellt, sodass sie schneller abgeschlossen wird.
Sie haben jetzt die Bereitstellung und den Test des KNFSD-Caching-Proxys abgeschlossen.
Erweiterte Workflow-Themen
Dieser Abschnitt enthält Informationen zur Bereitstellung in einer Hybridarchitektur, zur Skalierung für hohe Leistung sowie zur Verwendung von Messwerten und Dashboards für die Fehlerbehebung und Feinabstimmung.
Leistungsmerkmale und Ressourcengröße
Wie bereits erwähnt, wird in dieser Anleitung ein einzelner KNFSD-Proxy verwendet. Bei der Skalierung des Systems müssen Sie daher Ihre einzelnen Proxyressourcen so ändern, dass sie für CPU, RAM, Netzwerk, Speicherkapazität oder Leistung optimiert werden. In dieser Anleitung haben Sie KNFSD auf einer einzelnen Compute Engine-VM mit den folgenden Optionen bereitgestellt:
- 16 vCPUs, 104 GB RAM (
n1-highmem-16
).- Mit 16 vCPUs und einer Architektur von Sandy Bridge oder höher können Sie eine maximale Netzwerkgeschwindigkeit von 32 Gbit/s aktivieren.
- 10 GB nichtflüchtiger Speicher als Bootlaufwerk.
- 4 lokale SSDs. Diese Konfiguration bietet ein Hochgeschwindigkeits-Dateisystem mit 1,5 TB.
Obwohl diese Anleitung über den Umfang dieser Anleitung hinausgeht, können Sie diese Architektur skalieren. Dazu erstellen Sie mehrere KNFSD-Proxys in einer MIG und verwenden einen TCP-Load-Balancer, um Verbindungen zwischen den NFS-Clients und NFS-Proxys zu verwalten. Weitere Informationen finden Sie im GitHub-Repository knfsd-cache-utils
, das Terraform-Skripts, Beispielcode für die Bereitstellung und verschiedene FAQ zu Skalierungsarbeitslasten enthält.
Überlegungen zu einer Hybridbereitstellung
In vielen Bereitstellungen ist die Bandbreite Ihrer lokalen Verbindung zur Cloud bei der Konfiguration des Systems ein wichtiger Faktor. Hybridkonnektivität wird in dieser Anleitung nicht behandelt. Eine Übersicht über die verfügbaren Optionen finden Sie in der Dokumentation zu Hybridkonnektivität. Anleitungen zu Best Practices und Designmustern finden Sie in der Reihe Hybrid- und Multi-Cloud-Architekturen mit Google Cloud erstellen.
Messwerte erkunden
Dashboards können nützlich sein, um Feedback zu Messwerten zu erhalten, die für die Leistungsoptimierung und die allgemeine Fehlerbehebung verwendet werden können. Das Entdecken von Messwerten würde den Rahmen dieser Anleitung sprengen. Ein Messwert-Dashboard wird jedoch verfügbar gemacht, wenn Sie das Mulit-Knoten-System, da im knfsd-cache-utils
GitHub-Repository definiert ist, bereitstellen.
Bereinigen
Damit Ihrem Google Cloud-Konto die in dieser Anleitung verwendeten Ressourcen nicht in Rechnung gestellt werden, löschen Sie entweder das Projekt, das die Ressourcen enthält, oder Sie behalten das Projekt und löschen die einzelnen Ressourcen.
Projekt löschen
Am einfachsten vermeiden Sie weitere Kosten, indem Sie das für die Anleitung erstellte Projekt löschen.
- In the Google Cloud console, go to the Manage resources page.
- In the project list, select the project that you want to delete, and then click Delete.
- In the dialog, type the project ID, and then click Shut down to delete the project.
Nächste Schritte
- Weitere Informationen zu Best Practices für die Image-Verwaltung.
- Weitere Informationen zur Arbeit mit der Linux-Entwickler-Community zum NFS-Export.
- Weitere Informationen zur allgemeinen Verwaltung und Konfiguration von NFS unter Ubuntu.
- Weitere Informationen zum Skalieren einer KNFSD-Bereitstellung mit MIGs und einem Load-Balancer finden Sie im GitHub-Repository
knfsd-cache-utils
. - Weitere Referenzarchitekturen, Diagramme und Best Practices finden Sie im Cloud-Architekturcenter.