Configurar parâmetros do kernel para o AlloyDB Omni no Kubernetes

Esta página contém informações sobre a configuração de nós do Kubernetes que hospedam clusters de banco de dados do AlloyDB Omni para o desempenho ideal do operador do AlloyDB Omni Kubernetes e do mecanismo de banco de dados do AlloyDB Omni.

A configuração de parâmetros do kernel permite que o AlloyDB Omni use a memória do sistema e os recursos de E/S de forma mais eficiente ao processar cargas de trabalho pesadas.

Pré-requisito

Antes de começar, verifique se os nós do Kubernetes executam o kernel do Linux 6.1 ou mais recente, especificamente um kernel que ofereça suporte às flags MADV_COLLAPSE e MADV_POPULATE_WRITE. Para mais informações sobre essas flags, consulte a documentação do madwise do Linux.

A tabela a seguir lista os parâmetros do kernel obrigatórios e os valores correspondentes para nós do Kubernetes que executam pods de cluster de banco de dados:

Arquivo Valor
/sys/kernel/mm/transparent_hugepage/shmem_enabled
Para informações sobre a memória compartilhada, consulte Suporte transparente para Hugepage.		 within_size ou always
/proc/sys/vm/max_map_count
Para informações sobre o número de áreas de mapa de memória que um processo pode criar, consulte a Documentação do /proc/sys/vm.		 Maior que ou igual a 1073741824

Para configurar os parâmetros do kernel nos nós do Kubernetes usando um DaemonSet, faça o seguinte:

  1. Aplique rótulos aos nós em que você planeja executar clusters de banco de dados usando as instruções em Adicionar um rótulo a um nó.

  2. Para definir os parâmetros do kernel nos nós rotulados como LABEL_KEY=LABEL_VALUE, crie um DaemonSet:

    cat << EOF | kubectl apply -f -
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: alloydb-omni-kernel-tuning
  namespace: DS_NAMESPACE
spec:
  selector:
    matchLabels:
      name: alloydb-omni-kernel-tuning
  template:
    metadata:
      labels:
        name: alloydb-omni-kernel-tuning
    spec:
      volumes:
        - name: host-sys
          hostPath:
            path: /sys
      nodeSelector:
        LABEL_KEY: "LABEL_VALUE"
      restartPolicy: Always
      terminationGracePeriodSeconds: 1
      initContainers:
        - name: enable-thp-mmc
          image: INIT_IMAGE
          volumeMounts:
            - name: host-sys
              mountPath: /sys
          securityContext:
            privileged: true
          command: ["sh", "-c", "sysctl -w vm.max_map_count=MAX_MAP_COUNT && echo within_size >/sys/kernel/mm/transparent_hugepage/shmem_enabled"]
      containers:
        - name: CONTAINER_NAME
          image: CONTAINER_IMAGE
          command: ["watch", "-n", "600", "cat", "/sys/kernel/mm/transparent_hugepage/shmem_enabled"]
EOF

    Substitua:

    • DS_NAMESPACE: o namespace em que você quer implantar o DaemonSet, por exemplo, default.
    • LABEL_KEY: o identificador do rótulo. Por exemplo, workload.
    • LABEL_VALUE: os dados associados ao identificador do rótulo, por exemplo, database.
    • INIT_IMAGE: o nome da imagem usada para o contêiner de inicialização.
    • MAX_MAP_COUNT: o número máximo de áreas de mapa de memória que um processo pode criar, por exemplo, 1073741824.
    • CONTAINER_NAME: o nome do contêiner principal, por exemplo, main.
    • CONTAINER_IMAGE: o nome da imagem usada para o contêiner principal, por exemplo, latest.

  3. Depois de implantar o DaemonSet, para verificar se todos os pods no cluster do Kubernetes estão no estado Running e se você tem um pod para cada nó com o rótulo LABEL_KEY=LABEL_VALUE, use o seguinte comando:

    kubectl get pods -l LABEL_KEY=LABEL_VALUE

    Confira um exemplo de saída:

    NAME                               READY   STATUS    RESTARTS   AGE
alloydb-omni-kernel-tuning-2dkwh   1/1     Running   0          22s
alloydb-omni-kernel-tuning-pgkbj   1/1     Running   0          19s

  4. Para verificar se a flag do kernel foi aplicada, execute o seguinte comando para cada um dos pods identificados após a implantação do DaemonSet:

    kubectl logs POD_NAME

    Substitua POD_NAME pelo nome do pod que você quer examinar.

    Confira um exemplo de saída:

    always [within_size] advise never deny force

Para implantar clusters de banco de dados em nós do Kubernetes com os parâmetros de kernel recomendados, adicione uma seção nodeAffinity a uma das seguintes seções do manifesto do cluster de banco de dados:

  • primarySpec.schedulingConfig para instâncias principais
  • spec.schedulingConfig para instâncias do pool de leitura
      nodeaffinity:
        requiredDuringSchedulingIgnoredDuringExecution:
          nodeSelectorTerms:
          - matchExpressions:
            - key: LABEL_KEY
              operator: In
              values:
              - "LABEL_VALUE"

Para mais informações sobre como executar clusters de banco de dados em nós específicos do Kubernetes, consulte Atribuir nós a um cluster de banco de dados usando a programação.

Verificar a aplicação de parâmetros do kernel

Para verificar se os parâmetros do kernel são aplicados aos pods do banco de dados, faça o seguinte:

  1. Se a alta disponibilidade estiver ativada, especificamente spec.availability.numberOfStandbys estiver definido como um valor maior que zero, verifique se o recurso personalizado do banco de dados mostra DBClusterReady na coluna DBCLUSTERPHASE e True na coluna HAREADYSTATUS.

    kubectl get dbcluster -n DBCLUSTER_NAMESPACE DBCLUSTER_NAME

    Substitua:

    • DBCLUSTER_NAME: o nome do cluster de banco de dados que você verificou.
    • DBCLUSTER_NAMESPACE: o nome do namespace específico em que o cluster do banco de dados está localizado.

    Confira um exemplo de saída:

    NAME               PRIMARYENDPOINT   PRIMARYPHASE   DBCLUSTERPHASE   HAREADYSTATUS   HAREADYREASON
dbcluster-sample   10.29.21.240      Ready          DBClusterReady   True            Ready

  2. Liste os pods do Kubernetes que pertencem ao cluster do banco de dados:

    kubectl get pods -n DBCLUSTER_NAMESPACE -l alloydbomni.internal.dbadmin.goog/dbcluster=DBCLUSTER_NAME

  3. Para verificar as informações de memória compartilhada, execute o seguinte comando:

    kubectl exec -n DBCLUSTER_NAMESPACE POD_NAME -- grep Shmem /proc/meminfo

  4. A saída precisa conter números diferentes de zero em todas as entradas.

    Confira um exemplo de saída:

    Shmem:          126255872 kB
ShmemHugePages: 18403328 kB
ShmemPmdMapped:  2961408 kB

    Se você encontrar 0 kB em qualquer uma das entradas, reinicie o pod correspondente:

    kubectl delete pod -n DBCLUSTER_NAMESPACE POD_NAME

  5. Repita as etapas de 1 a 5 depois que o pod estiver no estado Running.