NFS-Caching-Proxy im Kernelbereich in Compute Engine bereitstellen

Last reviewed 2023-10-03 UTC

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:

Architektur mit einem KNFSD-Proxy in Google Cloud.

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:

Hybridarchitektur mit KNFSD-Bereitstellung.

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. Neuen Google Cloud-Nutzern steht möglicherweise eine kostenlose Testversion zur Verfügung.

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:

  1. In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

    Go to project selector

  2. Die Abrechnung für das Google Cloud-Projekt muss aktiviert sein.

  3. Compute Engine API aktivieren.

    Aktivieren Sie die API

  4. Aktivieren Sie Cloud Shell in der Google Cloud Console.

    Cloud Shell aktivieren

  5. Authentifizieren Sie Ihre Anmeldung im Cloud Shell-Terminal:

    gcloud auth application-default login

    Die Befehlszeile führt Sie durch die Schritte zur Autorisierung.

  6. 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

  1. Klonen Sie in Cloud Shell das GitHub-Repository:

    cd ~/
git clone https://github.com/GoogleCloudPlatform/knfsd-cache-utils.git

  2. 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

  3. 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:

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.

  1. 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

  2. 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.

  3. 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

  4. Ö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

  5. 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.

  6. 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.

  7. Ö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

  8. Nachdem der SSH-Tunnel eingerichtet wurde und die Befehlszeile auf die Instanz nfs-proxy-build ausgerichtet ist, wechseln Sie zu Root 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.

  9. 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.

  1. 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

  2. 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

  3. Nachdem das Laufwerk-Image erstellt wurde, löschen Sie die Instanz:

    gcloud compute instances delete $BUILD_MACHINE_NAME \
  --zone=$BUILD_MACHINE_ZONE

  4. 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.

  1. Wechseln Sie in Cloud Shell zum heruntergeladenen nfs-server-Skriptverzeichnis:

    cd ~/knfsd-cache-utils/tutorial

  2. 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.

  1. Legen Sie in Cloud Shell die folgenden Variablen fest:

    export PROXY_NAME=nfs-proxy

  2. 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 und actimeo 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 einfaches proxy-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-Repository knfsd-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.

  1. Rufen Sie in der Google Cloud Console die Seite VM-Instanzen auf.

    Zu „VM-Instanzen“

  2. Klicken Sie in der Spalte Verbinden auf SSH, um eine Verbindung zu nfs-client herzustellen.

  3. Installieren Sie im nfs-client-SSH-Fenster die erforderlichen NFS-Tools in nfs-client:

    sudo apt-get install nfs-common -y

  4. 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.

  1. Kopieren Sie in dem SSH-Fenster nfs-client, das Sie im vorherigen Abschnitt geöffnet haben, die Datei test 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.

  2. 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.

  1. Wechseln Sie in der Google Cloud Console zur Seite Ressourcen verwalten.

    Zur Seite „Ressourcen verwalten“

  2. Wählen Sie in der Projektliste das Projekt aus, das Sie löschen möchten, und klicken Sie dann auf Löschen.
  3. Geben Sie im Dialogfeld die Projekt-ID ein und klicken Sie auf Shut down (Beenden), um das Projekt zu löschen.

Nächste Schritte