Discos rápidos por quase metade do preço!

Para usar o Balanced SSD em workloads de Kubernetes gerenciado, é preciso instalar o addon do CSI driver — basta o comando abaixo.

• 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

Observação: conforme os termos de serviço do Google, o CSI driver ainda não tem cobertura de SLA — vale o alerta.

Atenção: a atualização do cluster é uma operação bloqueante e pode deixá-lo indisponível por 10 minutos ou mais.

Se você pretende atualizar seus workloads no Kubernetes, veja mais adiante neste artigo exemplos de mudanças em StorageClass e Volume Claim Templates.

A documentação do Google traz instruções para criar discos nos links abaixo — basta usar o tipo pd-balanced:

• Zonal
• Regional

Uma estratégia é montar o novo Balanced SSD junto com o disco atual e copiar os dados. Outra é seguir os passos abaixo para criar uma nova imagem a partir do snapshot.

1. Snapshot. Se for trocar um disco de boot, primeiro pare a instância. Para um disco comum, não precisa pará-la. Dá para tirar o snapshot com a instância em execução, mas há risco de perda de dados.

• 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. Criar. Crie um novo disco a partir do 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. Desanexar e reanexar. Se for trocar um disco de boot, edite a instância e troque o disco de boot pelo novo. Para um disco comum, basta desanexar o atual e anexar o novo.

• 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. Testar. Inicie a instância e confirme se o sistema operacional sobe normalmente. Se algo der errado, é só parar a instância e voltar para o disco antigo.

Observação: lembre-se de que a opção Disk Cloning não serve aqui — não dá para mudar o tipo de disco pelo Disk Clone.

Para colocar isso à prova, usei um projeto sandbox em que vinha experimentando o MongoDB multi-VM da Bitnami. Resolvi trocar um persistent disk padrão por um Balanced SSD e conferir se meus dados continuavam intactos. Veja a seguir.

Parar a instância, desanexar o disco, criar um novo disco, anexar e iniciar

Depois de anexar o novo disco do tipo pd-balanced e reiniciar a instância, usei o terminal SSH no navegador para me conectar a ela.

Clique em SSH na instância para fazer login

Em seguida, listei os dispositivos anexados e parti para montar o novo disco Balanced SSD e checar se todos os meus arquivos do MongoDB continuavam lá.

Novo disco montado e arquivos testados

Deu certo! Espero que este exemplo seja útil e poupe seu tempo de pular de artigo em artigo para descobrir como tirar proveito desse novo produto.

Se você roda workloads no GKE e está tranquilo quanto ao status do CSI driver, depois de atualizar o cluster basta adicionar ou editar uma StorageClass e referenciá-la nos PersistentVolumeClaims dos seus workloads.

Um colega meu testou atualizar um projeto demo no GKE com Apache Ignite para usar o novo armazenamento Balanced SSD — confira abaixo as mudanças que ele fez.

Altere o provisioner e o tipo

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

São só pequenos ajustes nos workloads das aplicações caso você ainda não estivesse declarando uma StorageClass.

Se já usa uma StorageClass customizada, não muda nada; caso contrário, faça a referência nos workloads assim

Seguimos trabalhando junto com nossos parceiros de nuvem para repassar feedback do dia a dia, com base nos casos de uso e desafios que acompanhamos com os clientes. Estamos animados com soluções como o tão aguardado Balanced SSD que o Google trouxe.

Fique de olho: vêm mais novidades por aí sobre produtos que podem ajudar nossos clientes atuais e futuros.