Schnelle Disks zum fast halben Preis!

Für Balanced SSD bei managed Kubernetes-workloads wird ein CSI-Treiber-Addon benötigt, das sich mit folgendem Befehl ganz einfach aktivieren lässt.

• https://cloud.google.com/kubernetes-engine/docs/how-to/persistent-volumes/gce-pd-csi-driver

gcloud beta container clusters update <YOUR-CLUSTER-NAME> --update-addons=GcePersistentDiskCsiDriver=ENABLED  # add zone or region

Hinweis: Laut Googles Service Terms ist der CSI-Treiber derzeit nicht durch ein SLA abgedeckt – das wollten wir nicht unerwähnt lassen.

Achtung: Ein Cluster-Upgrade ist eine blockierende Aktion und kann zu Ausfallzeiten von 10 Minuten oder mehr führen.

Wenn Sie ein Upgrade Ihrer Kubernetes-workloads planen, finden Sie weiter unten in diesem Artikel Beispieländerungen für StorageClass und Volume Claim Templates.

Die Google-Dokumentation enthält Anleitungen zum Anlegen von Disks unter den folgenden Links – verwenden Sie dabei den Typ pd-balanced:

• Zonal
• Regional

Eine Möglichkeit ist, die neue Balanced SSD parallel zur bestehenden Disk zu mounten und die Daten zu kopieren. Alternativ können Sie wie folgt ein neues Image aus einem Snapshot erstellen.

1. Snapshot. Bei einer Boot-Disk müssen Sie zuerst die Instanz stoppen. Bei einer regulären Disk ist das nicht nötig. Sie können auch im laufenden Betrieb einen Snapshot erstellen, riskieren dabei jedoch Datenverlust.

• https://cloud.google.com/compute/docs/disks/create-snapshots
• https://cloud.google.com/compute/docs/disks/snapshot-best-practices

# stop instance (optional if boot or concerned on data loss)
gcloud compute instances stop <instance name># create snapshot
gcloud compute disks snapshot <disk-name> --region <region>

2. Erstellen. Legen Sie aus dem Snapshot eine neue Disk an.

• https://cloud.google.com/compute/docs/disks/restore-and-delete-snapshots#restoresnapshottonew

# create new disk from snapshot
gcloud compute disks create <disk-name> --type pd-balanced --source-snapshot <snapshot ID> --size <size in GB>

3. Trennen und neu anbinden. Bei einer Boot-Disk bearbeiten Sie die Instanz und stellen die Boot-Disk auf die neue Disk um. Bei einer regulären Disk trennen Sie einfach die bestehende und hängen die neue an.

• https://cloud.google.com/compute/docs/disks/detach-reattach-boot-disk
• https://cloud.google.com/sdk/gcloud/reference/compute/instances/detach-disk
• https://cloud.google.com/sdk/gcloud/reference/compute/instances/attach-disk

# unmount volume
sudo umount /dev/disk/by-id/google-DEVICE_NAME# detach old disk
gcloud compute instances detach-disk <instance name> --disk <old disk> --zone <zone># attach new disk
gcloud compute instances attach-disk <instance name> --disk <new disk> --zone <zone># start instance (if stopped)
gcloud compute instances start <instance name># SSH into instance and mount volume
sudo lsblk            # make note of new disk (sda1, sdb, etc.)
sudo mkdir -p /path/to/mount
sudo mount -o discard,defaults /dev/sdb /path/to/mount

4. Testen. Starten Sie die Instanz und prüfen Sie, ob das Betriebssystem wie erwartet hochfährt. Sollte etwas schiefgehen, können Sie die Instanz stoppen und auf die alte Disk zurückwechseln.

Hinweis: Beachten Sie, dass die Option Disk Cloning hier nicht greift – per Disk Clone lässt sich der Disk-Typ nicht ändern.

Zum Testen habe ich ein Sandbox-Projekt genutzt, in dem ich mit der Multi-VM-Variante von Bitnamis MongoDB experimentiert hatte. Ich habe eine Standard-Persistent-Disk durch eine Balanced SSD ersetzt und geprüft, ob meine Daten weiterhin vorhanden sind. Siehe unten.

Instanz stoppen, Disk trennen, neue Disk erstellen, anhängen, starten

Nachdem ich die neue, als Typ pd-balanced erstellte Disk angehängt und die Instanz neu gestartet hatte, habe ich mich über das browserbasierte SSH-Terminal mit der Instanz verbunden.

Per Klick auf SSH an der Instanz anmelden

Anschließend habe ich die angehängten Geräte aufgelistet, die neue Balanced-SSD-Disk gemountet und geprüft, ob alle meine MongoDB-Dateien noch vorhanden waren.

Neue Disk gemountet und Dateien geprüft

Geschafft! Ich hoffe, dieses Beispiel ist hilfreich und erspart Ihnen die Suche in zig verschiedenen Artikeln, um die Vorteile dieses neuen Produkts zu nutzen.

Wenn Sie workloads auf GKE betreiben und mit dem Status des CSI-Treibers leben können, genügt es nach dem Cluster-Upgrade, eine StorageClass hinzuzufügen oder zu bearbeiten und sie in Ihren PersistentVolumeClaims zu referenzieren.

Einer meiner Kollegen hat ein Demo-GKE-Projekt für Apache Ignite auf den neuen Balanced-SSD-Speicher umgestellt – seine Änderungen sehen Sie unten.

Provisioner und Typ anpassen

kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: ignite-persistence-storage-class  # <your-name-here>
  namespace: ignite
provisioner: pd.csi.storage.gke.io
allowVolumeExpansion: true
volumeBindingMode: WaitForFirstConsumer
parameters:
  type: pd-balanced #Default: pd-standard

Für Anwendungs-workloads sind nur kleine Anpassungen nötig, falls Sie bisher keine StorageClass deklariert haben.

Wenn Sie bereits eine eigene StorageClass nutzen, ist nichts zu tun – andernfalls referenzieren Sie sie in Ihren workloads wie hier gezeigt

Wir arbeiten weiterhin eng mit unseren Cloud-Partnern zusammen und liefern Praxisfeedback aus den Anwendungsfällen und Herausforderungen, die uns täglich bei unseren Kunden begegnen. Umso mehr freuen wir uns, dass Google mit der lang erwarteten Balanced SSD eine solche Lösung an den Start bringt.

Bleiben Sie dran – wir berichten weiter über spannende Produkte, die unseren bestehenden und künftigen Kunden den Alltag erleichtern.