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

Selecione uma versão da documentação:

Esta página fornece informações sobre a configuração de nós do Kubernetes que alojam clusters de bases de dados do AlloyDB Omni para o desempenho ideal do operador do AlloyDB Omni Kubernetes e do motor de base de dados do AlloyDB Omni.

A configuração dos 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, certifique-se de que os nós do Kubernetes executam o kernel do Linux 6.1 ou superior, especificamente um kernel que suporte os flags MADV_COLLAPSE e MADV_POPULATE_WRITE. Para mais informações acerca destas flags, consulte a documentação do madwise Linux.

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

Ficheiro Valor
/sys/kernel/mm/transparent_hugepage/shmem_enabled
Para informações sobre a memória partilhada, consulte o artigo Suporte de páginas enormes transparentes		 within_size ou always
/proc/sys/vm/max_map_count
Para ver informações sobre o número de áreas de mapeamento de memória que um processo pode criar, consulte a documentação para /proc/sys/vm		 Maior ou igual a 1073741824

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

  1. Aplique etiquetas aos nós onde planeia executar clusters de base de dados através das instruções em Adicione uma etiqueta a um nó.

  2. Para definir os parâmetros do kernel nos nós etiquetados com 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 o seguinte:

    • DS_NAMESPACE: o espaço de nomes onde quer implementar o DaemonSet, por exemplo, default.
    • LABEL_KEY: o identificador da etiqueta, por exemplo, workload.
    • LABEL_VALUE: os dados associados ao identificador da etiqueta, por exemplo, database.
    • INIT_IMAGE: o nome da imagem usada para o contentor init.
    • MAX_MAP_COUNT: o número máximo de áreas de mapeamento de memória que um processo pode criar, por exemplo, 1073741824.
    • CONTAINER_NAME: o nome do contentor principal, por exemplo, main.
    • CONTAINER_IMAGE: o nome da imagem usada para o contentor principal, por exemplo, latest.

  3. Após implementar o DaemonSet, para verificar se todos os pods no seu cluster do Kubernetes estão no estado Running e se tem um pod para cada nó com a etiqueta LABEL_KEY=LABEL_VALUE, use o seguinte comando:

    kubectl get pods -l LABEL_KEY=LABEL_VALUE

    Um exemplo de resultado tem o seguinte aspeto:

    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 o sinalizador do kernel foi aplicado com êxito, para cada um dos pods identificados após a implementação do DaemonSet, execute o seguinte comando:

    kubectl logs POD_NAME

    Substitua POD_NAME pelo nome do pod cujos registos quer examinar.

    Um exemplo de resultado tem o seguinte aspeto:

    always [within_size] advise never deny force

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

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

Para mais informações sobre a execução de clusters de bases de dados em nós específicos do Kubernetes, consulte o artigo Atribua nós a um cluster de base de dados através do agendamento.

Valide a aplicação dos parâmetros do kernel

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

  1. Se a elevada disponibilidade estiver ativada, especificamente spec.availability.numberOfStandbys estiver definida para um valor superior a zero, verifique se o recurso personalizado da base de dados mostra DBClusterReady na coluna DBCLUSTERPHASE e True na coluna HAREADYSTATUS.

    kubectl get dbcluster -n DBCLUSTER_NAMESPACE DBCLUSTER_NAME

    Substitua o seguinte:

    • DBCLUSTER_NAME: o nome do cluster da base de dados que valida.
    • DBCLUSTER_NAMESPACE: o nome do espaço de nomes específico onde reside o cluster da base de dados.

    Um exemplo de resultado tem o seguinte aspeto:

    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 da base de dados:

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

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

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

  4. O resultado tem de conter números diferentes de zero em todas as entradas.

    Um exemplo de resultado tem o seguinte aspeto:

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

    Se vir 0 kB em qualquer uma das entradas, reinicie o pod correspondente:

    kubectl delete pod -n DBCLUSTER_NAMESPACE POD_NAME

  5. Repita os passos 1 a 5 depois de o pod estar no estado Running.