Configura los parámetros del kernel para AlloyDB Omni en Kubernetes

En esta página, se proporciona información para configurar nodos de Kubernetes que almacenen clústeres de bases de datos de AlloyDB Omni para obtener un rendimiento óptimo del operador de Kubernetes de AlloyDB Omni y del motor de base de datos de AlloyDB Omni.

La configuración de los parámetros del kernel permite que AlloyDB Omni use la memoria del sistema y los recursos de E/S de manera más eficiente cuando se manejan cargas de trabajo pesadas.

Requisitos

Antes de comenzar, asegúrate de que tus nodos de Kubernetes ejecuten el kernel de Linux 6.1 o una versión posterior, específicamente un kernel que admita las marcas MADV_COLLAPSE y MADV_POPULATE_WRITE. Para obtener más información sobre estas marcas, consulta la documentación de madwise de Linux.

En la siguiente tabla, se enumeran los parámetros del kernel obligatorios y sus valores correspondientes para los nodos de Kubernetes que ejecutan pods de clúster de bases de datos:

Archivo Valor
/sys/kernel/mm/transparent_hugepage/shmem_enabled
Para obtener información sobre la memoria compartida, consulta Compatibilidad con Hugepage transparente.		 within_size o always
/proc/sys/vm/max_map_count
Para obtener información sobre la cantidad de áreas de mapa de memoria que puede crear un proceso, consulta la documentación de /proc/sys/vm.		 Mayor o igual que 1073741824

Para configurar los parámetros del kernel en tus nodos de Kubernetes con un DaemonSet, haz lo siguiente:

  1. Aplica etiquetas a los nodos en los que planeas ejecutar clústeres de bases de datos con las instrucciones que se indican en Cómo agregar una etiqueta a un nodo.

  2. Para establecer los parámetros del kernel en los nodos etiquetados como LABEL_KEY=LABEL_VALUE, crea un 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

    Reemplaza lo siguiente:

    • DS_NAMESPACE: Es el espacio de nombres en el que deseas implementar el DaemonSet, por ejemplo, default.
    • LABEL_KEY: Es el identificador de la etiqueta, por ejemplo, workload.
    • LABEL_VALUE: Los datos asociados con el identificador de la etiqueta, por ejemplo, database.
    • INIT_IMAGE: Es el nombre de la imagen que se usa para el contenedor de init.
    • MAX_MAP_COUNT: Es la cantidad máxima de áreas de mapa de memoria que puede crear un proceso, por ejemplo, 1073741824.
    • CONTAINER_NAME: Es el nombre del contenedor principal, por ejemplo, main.
    • CONTAINER_IMAGE: Es el nombre de la imagen que se usa para el contenedor principal, por ejemplo, latest.

  3. Después de implementar el DaemonSet, para verificar que todos los pods de tu clúster de Kubernetes estén en el estado Running y que tengas un pod para cada nodo con la etiqueta LABEL_KEY=LABEL_VALUE, usa el siguiente comando:

    kubectl get pods -l LABEL_KEY=LABEL_VALUE

    Un resultado de ejemplo se ve de la siguiente manera:

    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 que la marca del kernel se aplique correctamente, ejecuta el siguiente comando para cada uno de los pods identificados después de implementar el DaemonSet:

    kubectl logs POD_NAME

    Reemplaza POD_NAME por el nombre del pod cuyos registros deseas examinar.

    Un resultado de ejemplo se ve de la siguiente manera:

    always [within_size] advise never deny force

Para implementar clústeres de bases de datos en nodos de Kubernetes con los parámetros de kernel recomendados, agrega una sección nodeAffinity a una de las siguientes secciones del manifiesto de tu clúster de bases de datos:

  • primarySpec.schedulingConfig para instancias principales
  • spec.schedulingConfig para instancias de grupo de lectura
      nodeaffinity:
        requiredDuringSchedulingIgnoredDuringExecution:
          nodeSelectorTerms:
          - matchExpressions:
            - key: LABEL_KEY
              operator: In
              values:
              - "LABEL_VALUE"

Para obtener más información sobre cómo ejecutar clústeres de bases de datos en nodos de Kubernetes específicos, consulta Asigna nodos a un clúster de bases de datos con programación.

Verifica la aplicación de los parámetros del kernel

Para verificar que los parámetros del kernel se apliquen a los pods de bases de datos, haz lo siguiente:

  1. Si la alta disponibilidad está habilitada, específicamente, spec.availability.numberOfStandbys se establece en un valor superior a cero, verifica que el recurso personalizado de la base de datos muestre DBClusterReady en la columna DBCLUSTERPHASE y True en la columna HAREADYSTATUS.

    kubectl get dbcluster -n DBCLUSTER_NAMESPACE DBCLUSTER_NAME

    Reemplaza lo siguiente:

    • DBCLUSTER_NAME: Es el nombre del clúster de bases de datos que verificas.
    • DBCLUSTER_NAMESPACE: Es el nombre del espacio de nombres específico en el que reside tu clúster de bases de datos.

    Un resultado de ejemplo se ve de la siguiente manera:

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

  2. Muestra una lista de los pods de Kubernetes que pertenecen al clúster de bases de datos:

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

  3. Para verificar la información de la memoria compartida, ejecuta el siguiente comando:

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

  4. El resultado debe contener números distintos de cero en todas las entradas.

    Un resultado de ejemplo se ve de la siguiente manera:

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

    Si ves 0 kB en alguna de las entradas, reinicia el pod correspondiente:

    kubectl delete pod -n DBCLUSTER_NAMESPACE POD_NAME

  5. Repite los pasos del 1 al 5 después de que el pod esté en el estado Running.