Lesevorgänge zustandsorientierter Arbeitslasten mit GKE Data Cache beschleunigen

In dieser Anleitung wird beschrieben, wie Sie die Leistung von zustandsorientierten Anwendungen mit vielen Lesevorgängen mithilfe von GKE Data Cache in Ihren GKE-Clustern (Google Kubernetes Engine) verbessern können. GKE Data Cache ist eine verwaltete Blockspeicherlösung, die Lesevorgänge für zustandsorientierte Anwendungen wie Datenbanken beschleunigt, die in GKE ausgeführt werden.

Sie können Data Cache nur mit GKE Standard-Clustern verwenden. In dieser Anleitung erfahren Sie, wie Sie GKE Data Cache aktivieren, wenn Sie einen neuen GKE Standard-Cluster oder einen Knotenpool erstellen, und wie Sie angehängte GKE-Laufwerke mit Data Cache-Beschleunigung bereitstellen.

GKE Data Cache

Mit GKE Data Cache können Sie lokale SSDs auf Ihren GKE-Knoten als Cache-Ebene für Ihren nichtflüchtigen Speicher wie nichtflüchtige Speicher oder Hyperdisks verwenden. Durch die Verwendung lokaler SSDs wird die Leselatenz von Laufwerken verringert und die Anzahl der Abfragen pro Sekunde (Queries Per Second, QPS) für Ihre zustandsorientierten Arbeitslasten erhöht, während die Arbeitsspeicheranforderungen minimiert werden. GKE Data Cache unterstützt alle Arten von nichtflüchtigen Speichern oder Hyperdisk als Sicherungslaufwerke.

Wenn Sie GKE Data Cache für Ihre Anwendung verwenden möchten, konfigurieren Sie Ihren GKE-Knotenpool mit angehängten lokalen SSDs. Sie können GKE Data Cache so konfigurieren, dass die gesamte angehängte lokale SSD oder nur ein Teil davon verwendet wird. Lokale SSDs, die von der GKE Data Cache -Lösung verwendet werden, werden im Ruhezustand mit der Standard Google Cloud verschlüsselung verschlüsselt.

Vorteile

GKE Data Cache bietet folgende Vorteile:

  • Höhere Anzahl von Abfragen, die pro Sekunde für herkömmliche Datenbanken wie MySQL oder Postgres und Vektordatenbanken verarbeitet werden.
  • Verbesserte Leseleistung für zustandsorientierte Anwendungen durch Minimierung der Laufwerklatenz.
  • Schnellere Datenhydration und -rehydration, da sich die SSDs lokal auf dem Knoten befinden. Mit Datenhydration wird der erste Prozess bezeichnet, bei dem die erforderlichen Daten aus dem nichtflüchtigen Speicher auf die lokale SSD geladen werden. Mit Datenrehydration wird der Prozess bezeichnet, bei dem die Daten auf den lokalen SSDs wiederhergestellt werden, nachdem ein Knoten wiederverwendet wurde.

Bereitstellungsarchitektur

Das folgende Diagramm zeigt ein Beispiel für eine GKE Data Cache-Konfiguration mit zwei Pods, auf denen jeweils eine App ausgeführt wird. Die Pods werden auf demselben GKE-Knoten ausgeführt. Jeder Pod verwendet eine separate lokale SSD und einen nichtflüchtigen Sicherungsspeicher.

Bereitstellungsarchitektur für GKE Data Cache
Abbildung 1. Bereitstellungsarchitektur für GKE Data Cache.

Bereitstellungsmodi

Sie können GKE Data Cache in einem von zwei Modi einrichten:

  • Writethrough (empfohlen): Wenn Ihre Anwendung Daten schreibt, werden die Daten synchron sowohl in den Cache als auch auf den zugrunde liegenden nichtflüchtigen Speicher geschrieben. Der Modus writethrough verhindert Datenverlust und eignet sich für die meisten Produktionsarbeitslasten.
  • Writeback: Wenn Ihre Anwendung Daten schreibt, werden die Daten nur in den Cache geschrieben. Anschließend werden die Daten asynchron (im Hintergrund) auf den nichtflüchtigen Speicher geschrieben. Der Modus writeback verbessert die Schreibleistung und eignet sich für Arbeitslasten, bei denen Geschwindigkeit wichtig ist. Dieser Modus wirkt sich jedoch auf die Zuverlässigkeit aus. Wenn der Knoten unerwartet heruntergefahren wird, gehen nicht geleerte Cachedaten verloren.

Ziele

In dieser Anleitung erfahren Sie, wie Sie:

Anforderungen und Planung

Achten Sie darauf, dass die folgenden Anforderungen für die Verwendung von GKE Data Cache erfüllt sind:

  • Auf Ihrem GKE-Cluster muss Version 1.32.3-gke.1440000 oder höher ausgeführt werden.
  • Ihre Knotenpools müssen Maschinentypen verwenden, die lokale SSDs unterstützen. Weitere Informationen finden Sie unter Unterstützung für Maschinenserien.

Planung

Berücksichtigen Sie bei der Planung der Speicherkapazität für GKE Data Cache die folgenden Aspekte:

  • Die maximale Anzahl von Pods pro Knoten, die GKE Data Cache gleichzeitig verwenden.
  • Die erwarteten Cache-Größenanforderungen von Pods, die GKE Data Cache verwenden.
  • Die Gesamtkapazität der lokalen SSDs, die auf Ihren GKE-Knoten verfügbar sind. Informationen dazu, welche Maschinentypen standardmäßig angehängte lokale SSDs haben und bei welchen Maschinentypen Sie lokale SSDs anhängen müssen, finden Sie unter Gültige Anzahl lokaler SSD-Laufwerke auswählen.
  • Bei Maschinentypen der dritten oder einer späteren Generation (mit einer standardmäßigen Anzahl angehängter lokaler SSDs) werden die lokalen SSDs für Data Cache aus den insgesamt verfügbaren lokalen SSDs auf dieser Maschine reserviert.
  • Der Dateisystem-Overhead, der den nutzbaren Speicherplatz auf lokalen SSDs verringern kann. Auch wenn Sie beispielsweise einen Knoten mit zwei lokalen SSDs mit einer Gesamtkapazität von 750 GiB haben, ist der verfügbare Speicherplatz für alle Data Cache-Volumes aufgrund des Dateisystem-Overheads möglicherweise geringer. Ein Teil der lokalen SSD-Kapazität ist für die Systemnutzung reserviert.

Beschränkungen

Inkompatibilität mit Backup for GKE

Um die Datenintegrität in Szenarien wie der Notfallwiederherstellung oder der Anwendungsmigration aufrechtzuerhalten, müssen Sie möglicherweise Ihre Daten sichern und wiederherstellen. Wenn Sie Backup for GKE verwenden, um einen PVC wiederherzustellen, der für die Verwendung von Data Cache konfiguriert ist, schlägt der Wiederherstellungsprozess fehl. Dieser Fehler tritt auf, weil die erforderlichen Data Cache-Parameter nicht korrekt von der ursprünglichen StorageClass weitergegeben werden.

Preise

Ihnen wird die gesamte bereitgestellte Kapazität Ihrer lokalen SSDs und der angehängten nichtflüchtigen Speicher in Rechnung gestellt. Die Abrechnung erfolgt pro GiB und Monat.

Weitere Informationen finden Sie in der Compute Engine-Dokumentation unter Laufwerkspreise.

Hinweis

Führen Sie die folgenden Aufgaben aus, bevor Sie beginnen:

  • Aktivieren Sie die Google Kubernetes Engine API.
    • Google Kubernetes Engine API aktivieren
  • Wenn Sie die Google Cloud CLI für diese Aufgabe verwenden möchten, installieren und dann initialisieren Sie die gcloud CLI. Wenn Sie die gcloud CLI bereits installiert haben, rufen Sie die neueste Version mit dem gcloud components update Befehl ab. Ältere gcloud CLI-Versionen unterstützen möglicherweise nicht die Ausführung der Befehle in diesem Dokument.

GKE-Knoten für die Verwendung von Data Cache konfigurieren

Damit Sie GKE Data Cache für beschleunigten Speicher verwenden können, müssen Ihre Knoten die erforderlichen lokalen SSD-Ressourcen haben. In diesem Abschnitt werden Befehle zum Bereitstellen lokaler SSDs und zum Aktivieren von GKE Data Cache beim Erstellen eines neuen GKE-Cluster oder beim Hinzufügen eines neuen Knotenpools zu einem vorhandenen Cluster gezeigt. Sie können einen vorhandenen Knotenpool nicht aktualisieren, um Data Cache zu verwenden. Wenn Sie Data Cache in einem vorhandenen Cluster verwenden möchten, fügen Sie dem Cluster einen neuen Knotenpool hinzu.

In einem neuen Cluster

Verwenden Sie den folgenden Befehl, um einen GKE-Cluster mit konfigurierter Data Cache-Funktion zu erstellen:

gcloud container clusters create CLUSTER_NAME \
    --location=LOCATION \
    --machine-type=MACHINE_TYPE \
    --data-cache-count=DATA_CACHE_COUNT \
    # Optionally specify additional Local SSDs, or skip this flag
    --ephemeral-storage-local-ssd count=LOCAL_SSD_COUNT

Ersetzen Sie Folgendes:

  • CLUSTER_NAME ist der Name des Clusters. Geben Sie einen eindeutigen Namen für den GKE-Cluster an, den Sie erstellen.
  • LOCATION ist die Google Cloud Region oder Zone für den neuen Cluster.
  • MACHINE_TYPE: der Maschinentyp, der aus einer Maschinenserie der zweiten, dritten oder einer späteren Generation für Ihren Cluster verwendet werden soll, z. B. n2-standard-2 oder c3-standard-4-lssd. Dieses Feld ist erforderlich, da die lokale SSD nicht mit dem Standardtyp e2-medium verwendet werden kann. Weitere Informationen finden Sie unter Verfügbare Maschinenserien.
  • DATA_CACHE_COUNTist die Anzahl der lokalen SSD-Volumes, die auf jedem Knoten im Standardknotenpool ausschließlich für Data Cache verwendet werden sollen. Jede dieser lokalen SSDs hat eine Kapazität von 375 GiB. Die maximale Anzahl von Volumes variiert je nach Maschinentyp und Region. Beachten Sie, dass ein Teil der lokalen SSD-Kapazität für die Systemnutzung reserviert ist.

  • (Optional) LOCAL_SSD_COUNT ist die Anzahl der lokalen SSD-Volumes, die für andere sitzungsspezifische Speicheranforderungen bereitgestellt werden sollen. Verwenden Sie das --ephemeral-storage-local-ssd count Flag, wenn Sie zusätzliche lokale SSDs bereitstellen möchten, die nicht für Data Cache verwendet werden.

    Beachten Sie Folgendes für die Maschinentypen der dritten oder einer späteren Generation:

    • Bei Maschinentypen der dritten oder einer späteren Generation ist standardmäßig eine bestimmte Anzahl lokaler SSDs angehängt. Die Anzahl der lokalen SSDs die an jeden Knoten angehängt sind, hängt vom angegebenen Maschinentyp ab.
    • Wenn Sie das Flag --ephemeral-storage-local-ssd count für zusätzlichen sitzungsspezifischen Speicher verwenden möchten, legen Sie den Wert von DATA_CACHE_COUNT auf eine Zahl fest, die kleiner als die insgesamt verfügbaren lokalen SSD-Laufwerke auf der Maschine ist. Die insgesamt verfügbare Anzahl lokaler SSDs umfasst die standardmäßig angehängten Laufwerke und alle neuen Laufwerke, die Sie mit dem Flag --ephemeral-storage-local-ssd count hinzufügen.

Mit diesem Befehl wird ein GKE-Cluster erstellt, der für seinen Standardknotenpool auf einem Maschinentyp der zweiten, dritten oder einer späteren Generation ausgeführt wird. Außerdem werden lokale SSDs für Data Cache bereitgestellt und optional zusätzliche lokale SSDs für andere sitzungsspezifische Speicheranforderungen, falls angegeben.

Diese Einstellungen gelten nur für den Standardknotenpool.

In einem vorhandenen Cluster

Wenn Sie Data Cache in einem vorhandenen Cluster verwenden möchten, müssen Sie einen neuen Knotenpool mit konfigurierter Data Cache-Funktion erstellen.

Verwenden Sie den folgenden Befehl, um einen GKE-Knotenpool mit konfigurierter Data Cache-Funktion zu erstellen:

gcloud container node-pool create NODE_POOL_NAME \
    --cluster=CLUSTER_NAME \
    --location=LOCATION \
    --machine-type=MACHINE_TYPE \
    --data-cache-count=DATA_CACHE_COUNT \
    # Optionally specify additional Local SSDs, or skip this flag
    --ephemeral-storage-local-ssd count=LOCAL_SSD_COUNT

Ersetzen Sie Folgendes:

  • NODE_POOL_NAME ist der Name des Knotenpools. Geben Sie einen eindeutigen Namen für den Knotenpool an, den Sie erstellen.
  • CLUSTER_NAMEist der Name eines vorhandenen GKE-Clusters, in dem Sie den Knotenpool erstellen möchten.
  • LOCATION ist dieselbe Google Cloud Region oder Zone wie Ihr Cluster.
  • MACHINE_TYPE: der Maschinentyp, der aus einer Maschinenserie der zweiten, dritten oder einer späteren Generation für Ihren Cluster verwendet werden soll, z. B. n2-standard-2 oder c3-standard-4-lssd. Dieses Feld ist erforderlich, da die lokale SSD nicht mit dem Standardtyp e2-medium verwendet werden kann. Weitere Informationen finden Sie unter Verfügbare Maschinenserien.
  • DATA_CACHE_COUNTist die Anzahl der lokalen SSD-Volumes, die auf jedem Knoten im Knotenpool ausschließlich für Data Cache verwendet werden sollen. Jede dieser lokalen SSDs hat eine Kapazität von 375 GiB. Die maximale Anzahl von Volumes variiert je nach Maschinentyp und Region. Beachten Sie, dass ein Teil der lokalen SSD-Kapazität für die Systemnutzung reserviert ist.

  • (Optional) LOCAL_SSD_COUNT ist die Anzahl der lokalen SSD-Volumes, die für andere sitzungsspezifische Speicheranforderungen bereitgestellt werden sollen. Verwenden Sie das --ephemeral-storage-local-ssd count Flag, wenn Sie zusätzliche lokale SSDs bereitstellen möchten, die nicht für Data Cache verwendet werden.

    Beachten Sie Folgendes für die Maschinentypen der dritten oder einer späteren Generation:

    • Bei Maschinentypen der dritten oder einer späteren Generation ist standardmäßig eine bestimmte Anzahl lokaler SSDs angehängt. Die Anzahl der lokalen SSDs die an jeden Knoten angehängt sind, hängt vom angegebenen Maschinentyp ab.
    • Wenn Sie das Flag --ephemeral-storage-local-ssd count für zusätzlichen sitzungsspezifischen Speicher verwenden möchten, legen Sie DATA_CACHE_COUNT auf eine Zahl fest, die kleiner als die insgesamt verfügbaren lokalen SSD-Laufwerke auf der Maschine ist. Die insgesamt verfügbare Anzahl lokaler SSDs umfasst die standardmäßig angehängten Laufwerke und alle neuen Laufwerke, die Sie mit dem Flag --ephemeral-storage-local-ssd count hinzufügen.

Mit diesem Befehl wird ein GKE-Knotenpool erstellt, der auf einem Maschinentyp der zweiten, dritten oder einer späteren Generation ausgeführt wird. Außerdem werden lokale SSDs für Data Cache bereitgestellt und optional zusätzliche lokale SSDs für andere sitzungsspezifische Speicheranforderungen, falls angegeben.

Data Cache für nichtflüchtigen Speicher in GKE bereitstellen

In diesem Abschnitt finden Sie ein Beispiel dafür, wie Sie die Leistungsvorteile von GKE Data Cache für Ihre zustandsorientierten Anwendungen nutzen können.

Knotenpool mit lokalen SSDs für Data Cache erstellen

Erstellen Sie zuerst einen neuen Knotenpool mit angehängten lokalen SSDs in Ihrem GKE-Cluster. GKE Data Cache verwendet die lokalen SSDs, um die Leistung der angehängten nichtflüchtigen Speicher zu beschleunigen.

Mit dem folgenden Befehl wird ein Knotenpool erstellt, der eine Maschine der zweiten Generation verwendet (n2-standard-2):

gcloud container node-pools create datacache-node-pool \
    --cluster=CLUSTER_NAME \
    --location=LOCATION \
    --num-nodes=2 \
    --data-cache-count=1 \
    --machine-type=n2-standard-2

Ersetzen Sie Folgendes:

  • CLUSTER_NAME ist der Name des Clusters. Geben Sie den GKE-Cluster an, in dem Sie den neuen Knotenpool erstellen.
  • LOCATION ist dieselbe Google Cloud Region oder Zone wie Ihr Cluster.

Mit diesem Befehl wird ein Knotenpool mit den folgenden Spezifikationen erstellt:

  • --num-nodes=2 legt die anfängliche Anzahl der Knoten in diesem Pool auf zwei fest.
  • --data-cache-count=1 gibt eine lokale SSD pro Knoten an, die für GKE Data Cache verwendet wird.

Die Gesamtzahl der lokalen SSDs, die für diesen Knotenpool bereitgestellt werden, beträgt zwei, da für jeden Knoten eine lokale SSD bereitgestellt wird.

StorageClass für Data Cache erstellen

Erstellen Sie eine Kubernetes-StorageClass die GKE anweist, wie ein PersistentVolume dynamisch bereitgestellt werden soll das Data Cache verwendet.

Verwenden Sie das folgende Manifest, um eine StorageClass mit dem Namen pd-balanced-data-cache-sc zu erstellen und anzuwenden:

kubectl apply -f - <<EOF
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: pd-balanced-data-cache-sc
provisioner: pd.csi.storage.gke.io
parameters:
  type: pd-balanced
  data-cache-mode: writethrough
  data-cache-size: "100Gi"
volumeBindingMode: WaitForFirstConsumer
allowVolumeExpansion: true
EOF

Zu den StorageClass-Parametern für Data Cache gehören:

  • type gibt den zugrunde liegenden Laufwerkstyp für das PersistentVolume an. Weitere Optionen finden Sie unter den unterstützten Persistent Disk-Typen oder Hyperdisk-Typen.
  • data-cache-mode verwendet den empfohlenen Modus writethrough. Weitere Informationen finden Sie unter Bereitstellungsmodi.
  • data-cache-sizelegt die lokale SSD-Kapazität auf 100 GiB fest, die als Lesecache für jeden PVC verwendet wird.

Speicher mit einem PersistentVolumeClaim (PVC) anfordern

Erstellen Sie einen PVC, der auf die von Ihnen erstellte StorageClass pd-balanced-data-cache-sc verweist. Der PVC fordert ein PersistentVolume mit aktivierter Data Cache-Funktion an.

Verwenden Sie das folgende Manifest, um einen PVC mit dem Namen pvc-data-cache zu erstellen, der ein PersistentVolume von mindestens 300 GiB mit ReadWriteOnce-Zugriff anfordert.

kubectl apply -f - <<EOF
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc-data-cache
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 300Gi
  storageClassName: pd-balanced-data-cache-sc
EOF

Deployment erstellen, das den PVC verwendet

Erstellen Sie ein Deployment mit dem Namen postgres-data-cache, das einen Pod ausführt, der den zuvor erstellten PVC pvc-data-cache verwendet. Der Knotenselektor cloud.google.com/gke-data-cache-count sorgt dafür, dass der Pod auf einem Knoten geplant wird, der die für die Verwendung von GKE Data Cache erforderlichen lokalen SSD-Ressourcen hat.

Erstellen und wenden Sie das folgende Manifest an, um einen Pod zu konfigurieren, der einen Postgres-Webserver mit dem PVC bereitstellt:

kubectl apply -f - <<EOF
apiVersion: apps/v1
kind: Deployment
metadata:
 name: postgres-data-cache
 labels:
   name: database
   app: data-cache
spec:
 replicas: 1
 selector:
   matchLabels:
     service: postgres
     app: data-cache
 template:
   metadata:
     labels:
       service: postgres
       app: data-cache
   spec:
     nodeSelector:
       cloud.google.com/gke-data-cache-disk: "1"
     containers:
     - name: postgres
       image: postgres:14-alpine
       volumeMounts:
       - name: pvc-data-cache-vol
         mountPath: /var/lib/postgresql/data2
         subPath: postgres
       env:
       - name: POSTGRES_USER
         value: admin
       - name: POSTGRES_PASSWORD
         value: password
     restartPolicy: Always
     volumes:
     - name: pvc-data-cache-vol
       persistentVolumeClaim:
         claimName: pvc-data-cache
EOF

Prüfen Sie, ob das Deployment erfolgreich erstellt wurde:

kubectl get deployment

Es kann einige Minuten dauern, bis die Bereitstellung des Postgres-Containers abgeschlossen ist und der Status READY angezeigt wird.

Bereitstellung von Data Cache prüfen

Nachdem Sie das Deployment erstellt haben, prüfen Sie, ob der nichtflüchtige Speicher mit Data Cache korrekt bereitgestellt wurde.

  1. Führen Sie den folgenden Befehl aus, um zu prüfen, ob Ihr pvc-data-cache erfolgreich an ein PersistentVolume gebunden wurde:

    kubectl get pvc pvc-data-cache

    Die Ausgabe sieht etwa so aus:

    NAME             STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS                VOLUMEATTRIBUTESCLASS   AGE
pvc-data-cache   Bound    pvc-e9238a16-437e-45d7-ad41-410c400ae018   300Gi      RWO            pd-balanced-data-cache-sc   <unset>                 10m

  2. So prüfen Sie, ob die Logical Volume Manager (LVM)-Gruppe für Data Cache auf dem Knoten erstellt wurde:

    1. Rufen Sie den Pod-Namen des PDCSI-Treibers auf diesem Knoten ab:

      NODE_NAME=$(kubectl get pod --output json |  jq '.items[0].spec.nodeName' | sed 's/\"//g')
kubectl get po -n kube-system -o wide | grep ^pdcsi-node | grep $NODE_NAME

      Kopieren Sie in der Ausgabe den Namen des pdcsi-node-Pods.

    2. PDCSI-Treiberlogs für die Erstellung der LVM-Gruppe ansehen:

      PDCSI_POD_NAME="PDCSI-NODE_POD_NAME"
kubectl logs -n kube-system $PDCSI_POD_NAME gce-pd-driver | grep "Volume group creation"

      Ersetzen Sie PDCSI-NODE_POD_NAME durch den tatsächlichen Pod-Namen, den Sie im vorherigen Schritt kopiert haben.

      Die Ausgabe sieht etwa so aus:

      Volume group creation succeeded for LVM_GROUP_NAME

Diese Meldung bestätigt, dass die LVM-Konfiguration für Data Cache auf dem Knoten korrekt eingerichtet ist.

Bereinigen

Löschen Sie die in dieser Anleitung erstellten Speicherressourcen, um Gebühren für Ihr Google Cloud Konto zu vermeiden.

  1. Löschen Sie das Deployment.

    kubectl delete deployment postgres-data-cache

  2. Löschen Sie den PersistentVolumeClaim.

    kubectl delete pvc pvc-data-cache

  3. Löschen Sie den Knotenpool.

    gcloud container node-pools delete datacache-node-pool \
    --cluster CLUSTER_NAME

    Ersetzen Sie CLUSTER_NAME durch den Namen des Clusters, in dem Sie den Knotenpool erstellt haben, der Data Cache verwendet.

Nächste Schritte