Acelere o desempenho de leitura de cargas de trabalho com estado com a GKE Data Cache

Este guia descreve como pode melhorar o desempenho das aplicações com estado de leitura intensiva usando a cache de dados do GKE nos seus clusters do Google Kubernetes Engine (GKE). A GKE Data Cache é uma solução de armazenamento de blocos gerida que acelera as operações de leitura para as suas aplicações com estado, como bases de dados, que são executadas no GKE.

Só pode usar a cache de dados com clusters padrão do GKE. Este guia explica como ativar a GKE Data Cache quando cria um novo cluster padrão do GKE ou um conjunto de nós, e como aprovisionar discos anexados do GKE com a aceleração da Data Cache.

Acerca da GKE Data Cache

Com a GKE Data Cache, pode usar SSDs locais nos seus nós do GKE como uma camada de cache para o seu armazenamento persistente, como discos persistentes ou hiperdiscos. A utilização de SSDs locais reduz a latência de leitura do disco e aumenta as consultas por segundo (CPS) para as suas cargas de trabalho com estado, ao mesmo tempo que minimiza os requisitos de memória. A cache de dados do GKE suporta todos os tipos de Persistent Disk ou Hyperdisk como discos de apoio.

Para usar a GKE Data Cache para a sua aplicação, configure o seu conjunto de nós do GKE com SSDs locais anexados. Pode configurar a GKE Data Cache para usar tudo ou parte do SSD local anexado. Os SSDs locais usados pela solução GKE Data Cache são encriptados em repouso através da encriptação Google Cloud padrão.

Vantagens

A GKE Data Cache oferece as seguintes vantagens:

  • Aumento da taxa de consultas processadas por segundo para bases de dados convencionais, como o MySQL ou o Postgres, e bases de dados vetoriais.
  • Desempenho de leitura melhorado para aplicações com estado, minimizando a latência do disco.
  • Atualização e reatualização de dados mais rápidas, uma vez que os SSDs são locais para o nó. A hidratação de dados refere-se ao processo inicial de carregamento dos dados necessários do armazenamento persistente para o SSD local. A reidratação de dados refere-se ao processo de restauro dos dados nos SSDs locais após a reciclagem de um nó.

Arquitetura de implementação

O diagrama seguinte mostra um exemplo de uma configuração da GKE Data Cache com dois pods que executam cada um uma app. Os pods são executados no mesmo nó do GKE. Cada Pod usa um SSD local separado e um disco persistente de apoio.

Arquitetura de implementação para a GKE Data Cache
Figura 1. Arquitetura de implementação para a GKE Data Cache.

Modos de implementação

Pode configurar a GKE Data Cache num de dois modos:

  • Writethrough (recomendado): quando a sua aplicação escreve dados, os dados são escritos sincronamente na cache e no disco persistente subjacente. O modo writethrough evita a perda de dados e é adequado para a maioria das cargas de trabalho de produção.
  • Gravação: quando a sua aplicação escreve dados, os dados são escritos apenas na cache. Em seguida, os dados são gravados no disco persistente de forma assíncrona (em segundo plano). O modo writebackmelhora o desempenho de escrita e é adequado para cargas de trabalho que dependem da velocidade. No entanto, este modo afeta a fiabilidade. Se o nó for desligado inesperadamente, os dados da cache não descarregados são perdidos.

Objetivos

Neste guia, vai aprender a:

Requisitos e planeamento

Certifique-se de que cumpre os seguintes requisitos para usar a GKE Data Cache:

  • O cluster do GKE tem de ter a versão 1.32.3-gke.1440000 ou posterior.
  • Os seus conjuntos de nós têm de usar tipos de máquinas que suportam SSDs locais. Para mais informações, consulte o artigo Compatibilidade com a série Machine.

Planeamento

Considere estes aspetos quando planear a capacidade de armazenamento para a GKE Data Cache:

  • O número máximo de pods por nó que vão usar a GKE Data Cache em simultâneo.
  • Os requisitos de tamanho da cache esperados dos pods que vão usar a GKE Data Cache.
  • A capacidade total dos SSDs locais disponíveis nos seus nós do GKE. Para obter informações sobre os tipos de máquinas que têm SSDs locais anexados por predefinição e os tipos de máquinas que requerem que anexe SSDs locais, consulte o artigo Escolha um número válido de discos SSD locais.
  • Para tipos de máquinas de terceira geração ou posteriores (que têm um número predefinido de SSDs locais associados), tenha em atenção que os SSDs locais para a cache de dados são reservados dos SSDs locais totais disponíveis nessa máquina.
  • A sobrecarga do sistema de ficheiros que pode reduzir o espaço utilizável nos SSDs locais. Por exemplo, mesmo que tenha um nó com dois SSDs locais com 750 GiB de capacidade bruta total, o espaço disponível para todos os volumes da cache de dados pode ser inferior devido à sobrecarga do sistema de ficheiros. Parte da capacidade do SSD local está reservada para utilização do sistema.

Preços

A faturação é feita com base na capacidade aprovisionada total dos seus SSDs locais e dos discos persistentes anexados. A cobrança é feita por GiB por mês.

Para mais informações, consulte a secção Preços dos discos na documentação do Compute Engine.

Antes de começar

Antes de começar, certifique-se de que realizou as seguintes tarefas:

  • Ative a API Google Kubernetes Engine.
    • Ative a API Google Kubernetes Engine
  • Se quiser usar a CLI gcloud para esta tarefa, instale-a e, em seguida, inicialize-a. Se instalou anteriormente a CLI gcloud, execute gcloud components update para obter a versão mais recente.

Configure os nós do GKE para usar a cache de dados

Para começar a usar a GKE Data Cache para armazenamento acelerado, os seus nós têm de ter os recursos de SSD local necessários. Esta secção mostra comandos para aprovisionar SSDs locais e ativar a cache de dados do GKE quando cria um novo cluster do GKE ou adiciona um novo conjunto de nós a um cluster existente. Não pode atualizar um conjunto de nós existente para usar a cache de dados. Se quiser usar a cache de dados num cluster existente, adicione um novo conjunto de nós ao cluster.

Num novo cluster

Para criar um cluster do GKE com a cache de dados configurada, use o seguinte comando:

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

Substitua o seguinte:

  • CLUSTER_NAME: o nome do cluster. Atribua um nome exclusivo ao cluster do GKE que está a criar.
  • LOCATION: a Google Cloud região ou a zona do novo cluster.
  • MACHINE_TYPE: o tipo de máquina a usar de uma série de máquinas de segunda, terceira ou geração posterior para o seu cluster, como n2-standard-2 ou c3-standard-4-lssd. Este campo é obrigatório porque não é possível usar o SSD local com o tipo e2-medium predefinido. Para mais informações, consulte as séries de máquinas disponíveis.
  • DATA_CACHE_COUNT: o número de volumes de SSD local a dedicar exclusivamente para a cache de dados em cada nó no conjunto de nós predefinido. Cada um destes SSDs locais tem uma capacidade de 375 GiB. O número máximo de volumes varia consoante o tipo de máquina e a região. Tenha em atenção que alguma capacidade do SSD local está reservada para utilização do sistema.

  • (Opcional) LOCAL_SSD_COUNT: o número de volumes de SSD local a aprovisionar para outras necessidades de armazenamento temporário. Use a flag --ephemeral-storage-local-ssd count se quiser aprovisionar SSDs locais adicionais que não são usados para a cache de dados.

    Tenha em atenção o seguinte para os tipos de máquinas de terceira geração ou posteriores:

    • Os tipos de máquinas de terceira geração ou posteriores têm um número específico de SSDs locais anexados por predefinição. O número de SSDs locais associados a cada nó depende do tipo de máquina que especificar.
    • Se planeia usar a flag --ephemeral-storage-local-ssd count para armazenamento efémero adicional, certifique-se de que define o valor de DATA_CACHE_COUNT como um número inferior ao número de discos SSD locais totalmente disponíveis na máquina. A quantidade total de SSDs locais disponíveis inclui os discos anexados predefinidos e quaisquer novos discos que adicione através da flag --ephemeral-storage-local-ssd count.

Este comando cria um cluster do GKE que é executado num tipo de máquina de segunda, terceira ou geração posterior para o respetivo conjunto de nós predefinido, aprovisiona SSDs locais para a cache de dados e, opcionalmente, aprovisiona SSDs locais adicionais para outras necessidades de armazenamento temporário, se especificado.

Estas definições aplicam-se apenas ao conjunto de nós predefinido.

Num cluster existente

Para usar a cache de dados num cluster existente, tem de criar um novo conjunto de nós com a cache de dados configurada.

Para criar um conjunto de nós do GKE com a cache de dados configurada, use o seguinte comando:

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

Substitua o seguinte:

  • NODE_POOL_NAME: o nome do node pool. Indique um nome único para o conjunto de nós que está a criar.
  • CLUSTER_NAME: o nome de um cluster do GKE existente onde quer criar o conjunto de nós.
  • LOCATION: a mesma Google Cloud região ou zona que o seu cluster.
  • MACHINE_TYPE: o tipo de máquina a usar de uma série de máquinas de segunda, terceira ou geração posterior para o seu cluster, como n2-standard-2 ou c3-standard-4-lssd. Este campo é obrigatório, uma vez que não é possível usar o SSD local com o tipo e2-medium predefinido. Para mais informações, consulte as séries de máquinas disponíveis.
  • DATA_CACHE_COUNT: o número de volumes de SSD local a dedicar exclusivamente para a cache de dados em cada nó no conjunto de nós. Cada um destes SSDs locais tem uma capacidade de 375 GiB. O número máximo de volumes varia consoante o tipo de máquina e a região. Tenha em atenção que alguma capacidade do SSD local está reservada para utilização do sistema.

  • (Opcional) LOCAL_SSD_COUNT: o número de volumes de SSD local a aprovisionar para outras necessidades de armazenamento temporário. Use a flag --ephemeral-storage-local-ssd count se quiser aprovisionar SSDs locais adicionais que não sejam usados para a cache de dados.

    Tenha em atenção o seguinte para os tipos de máquinas de terceira geração ou posteriores:

    • Os tipos de máquinas de terceira geração ou posteriores têm um número específico de SSDs locais anexados por predefinição. O número de SSDs locais associados a cada nó depende do tipo de máquina que especificar.
    • Se planeia usar a flag --ephemeral-storage-local-ssd count para armazenamento efémero adicional, certifique-se de que define DATA_CACHE_COUNT como inferior ao número de discos SSD locais disponíveis no total na máquina. A quantidade total de SSDs locais disponíveis inclui os discos anexados predefinidos e quaisquer novos discos que adicione através da flag --ephemeral-storage-local-ssd count.

Este comando cria um conjunto de nós do GKE que é executado num tipo de máquina de segunda, terceira ou geração posterior, aprovisiona SSDs locais para a cache de dados e, opcionalmente, aprovisiona SSDs locais adicionais para outras necessidades de armazenamento temporário, se especificado.

Aprovisione a cache de dados para armazenamento persistente no GKE

Esta secção fornece um exemplo de como ativar as vantagens de desempenho da GKE Data Cache para as suas aplicações com estado.

Crie um node pool com SSDs locais para a cache de dados

Comece por criar um novo conjunto de nós com SSDs locais anexados no cluster do GKE. A GKE Data Cache usa os SSDs locais para acelerar o desempenho dos discos persistentes anexados.

O seguinte comando cria um node pool que usa uma máquina de segunda geração, 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

Substitua o seguinte:

  • CLUSTER_NAME: o nome do cluster. Especifique o cluster do GKE onde está a criar o novo node pool.
  • LOCATION: a mesma Google Cloud região ou zona que o seu cluster.

Este comando cria um conjunto de nós com as seguintes especificações:

  • --num-nodes=2: define o número inicial de nós neste conjunto como dois.
  • --data-cache-count=1: especifica um SSD local por nó dedicado à GKE Data Cache.

O número total de SSDs locais aprovisionados para este conjunto de nós é dois, porque cada nó é aprovisionado com um SSD local.

Crie uma StorageClass de cache de dados

Crie um Kubernetes StorageClass que indica ao GKE como aprovisionar dinamicamente um volume persistente que usa a cache de dados.

Use o seguinte manifesto para criar e aplicar um StorageClass denominado pd-balanced-data-cache-sc:

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

Os parâmetros StorageClass para a cache de dados incluem o seguinte:

  • type: especifica o tipo de disco subjacente para o volume persistente. Para mais opções, consulte os tipos de discos persistentes ou tipos de Hyperdisk suportados.
  • data-cache-mode: usa o modo writethrough recomendado. Para mais informações, consulte Modos de implementação.
  • data-cache-size: define a capacidade do SSD local como 100 GiB, que é usada como uma cache de leitura para cada PVC.

Peça armazenamento com uma PersistentVolumeClaim (PVC)

Crie um PVC que faça referência à pd-balanced-data-cache-scStorageClass que criou. O PVC pede um volume persistente com a cache de dados ativada.

Use o seguinte manifesto para criar um PVC denominado pvc-data-cache que pede um volume persistente de, pelo menos, 300 GiB com acesso ReadWriteOnce.

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

Crie uma implementação que use o PVC

Crie uma implementação denominada postgres-data-cache que execute um pod que use o PVC pvc-data-cache que criou anteriormente. O seletor de nós cloud.google.com/gke-data-cache-count garante que o pod é agendado num nó que tem os recursos de SSD local necessários para usar a cache de dados do GKE.

Crie e aplique o seguinte manifesto para configurar um pod que implementa um servidor Web do Postgres usando o PVC:

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

Confirme que a implementação foi criada com êxito:

kubectl get deployment

O contentor do Postgres pode demorar alguns minutos a concluir o aprovisionamento e apresentar um estado READY.

Valide o aprovisionamento da cache de dados

Depois de criar a implementação, confirme que o armazenamento persistente com a cache de dados foi aprovisionado corretamente.

  1. Para verificar se o pvc-data-cache está associado com êxito a um volume persistente, execute o seguinte comando:

    kubectl get pvc pvc-data-cache

    O resultado é semelhante ao seguinte:

    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. Para confirmar que o grupo do Logical Volume Manager (LVM) para a cache de dados foi criado no nó, siga estes passos:

    1. Obtenha o nome do pod do controlador PDCSI nesse nó:

      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

      Na saída, copie o nome do pdcsi-nodepod.

    2. Veja os registos do controlador PDCSI para a criação de grupos LVM:

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

      Substitua PDCSI-NODE_POD_NAME pelo nome do pod real que copiou no passo anterior.

      O resultado é semelhante ao seguinte:

      Volume group creation succeeded for LVM_GROUP_NAME

Esta mensagem confirma que a configuração do LVM para a cache de dados está configurada corretamente no nó.

Limpar

Para evitar incorrer em custos na sua conta do Google Cloud , elimine os recursos de armazenamento que criou neste guia.

  1. Elimine a implementação.

    kubectl delete deployment postgres-data-cache

  2. Elimine o PersistentVolumeClaim.

    kubectl delete pvc pvc-data-cache

  3. Elimine o node pool.

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

    Substitua CLUSTER_NAME pelo nome do cluster onde criou o conjunto de nós que usa a cache de dados.

O que se segue?