Dischi veloci a quasi metà prezzo!

Per i workloads su Kubernetes gestito, Balanced SSD richiede l'addon del driver CSI, attivabile con un singolo comando.

• 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

Nota: in base ai termini di servizio di Google, il driver CSI al momento non è coperto da SLA, ed è giusto segnalarlo.

Attenzione: l'aggiornamento del cluster è un'operazione bloccante e può comportare un'indisponibilità di 10 minuti o più.

Se ha intenzione di aggiornare i suoi workloads Kubernetes, più avanti nell'articolo trova alcuni esempi di modifica di StorageClass e Volume Claim Templates.

La documentazione di Google riporta le istruzioni per creare i dischi ai link qui sotto: è sufficiente utilizzare il tipo pd-balanced:

• Zonale
• Regionale

Una strategia possibile è montare il nuovo disco Balanced SSD accanto a quello esistente e copiare i dati; in alternativa, qui sotto trova i passaggi per creare una nuova immagine a partire dallo snapshot.

1. Snapshot. Se sta cambiando un disco di boot, arresti prima l'istanza. Se invece si tratta di un disco normale, non è necessario fermarla: può eseguire lo snapshot a istanza attiva, ma con il rischio di perdita di dati.

• 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. Creazione. Crei un nuovo disco a partire dallo snapshot

• 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. Scollegamento e ricollegamento. Se sta cambiando un disco di boot, modifichi l'istanza e imposti il nuovo disco come disco di boot. Se invece si tratta di un disco normale, può scollegare quello esistente e collegare il nuovo.

• 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. Test. Avvii l'istanza e verifichi che l'OS si avvii come previsto. In caso di problemi, può fermarla e ripristinare il vecchio disco.

Nota: tenga presente che l'opzione Disk Cloning in questo caso non è utilizzabile: tramite Disk Clone non è possibile cambiare il tipo di disco.

Per provarlo ho usato un progetto sandbox in cui stavo sperimentando il multi-VM di Mongo DB di Bitnami. Ho deciso di sostituire un persistent disk standard con un Balanced SSD e di verificare che i miei dati fossero ancora intatti. Ecco com'è andata.

Arresto istanza, scollegamento disco, creazione del nuovo disco, collegamento e avvio

Dopo aver collegato il nuovo disco di tipo pd-balanced e riavviato l'istanza, mi sono connesso tramite il terminale SSH del browser.

Clicchi su SSH per accedere all'istanza

Ho quindi elencato i dispositivi collegati e ho montato il nuovo disco Balanced SSD per verificare che tutti i file di MongoDB fossero ancora presenti.

Nuovo disco montato e file verificati

Tutto a posto! Spero che questo esempio le sia utile e le risparmi la fatica di saltare da un articolo all'altro per capire come sfruttare al meglio questa novità.

Se esegue workloads su GKE e si trova a suo agio con lo stato attuale del driver CSI, dopo aver aggiornato il cluster è sufficiente aggiungere o modificare una StorageClass e referenziarla dai PersistentVolumeClaims all'interno dei suoi workloads.

Un mio collega ha provato ad aggiornare un progetto GKE demo per Apache Ignite con il nuovo storage Balanced SSD: qui sotto le modifiche apportate.

Modifica di provisioner e type

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

Per i workloads applicativi servono pochissime modifiche, nel caso non avesse ancora dichiarato una StorageClass.

Se utilizza già una StorageClass personalizzata non serve alcuna modifica; in caso contrario, la referenzi nei suoi workloads in questo modo

Continuiamo a collaborare con i nostri partner cloud per fornire feedback dal campo, basato sui casi d'uso e sulle sfide che ogni giorno vediamo affrontare ai clienti. Siamo entusiasti che Google abbia introdotto soluzioni come l'attesissimo Balanced SSD.

Resti sintonizzato: presto pubblicheremo nuovi aggiornamenti su prodotti che riteniamo possano fare la differenza per i nostri clienti, attuali e futuri.