Configurar parámetros del kernel para AlloyDB Omni en Kubernetes

Selecciona una versión de la documentación:

En esta página se proporciona información sobre cómo configurar nodos de Kubernetes que alojan clústeres de bases de datos de AlloyDB Omni para que el operador AlloyDB Omni Kubernetes y el motor de base de datos de AlloyDB Omni tengan un rendimiento óptimo.

Configurar los parámetros del kernel permite que AlloyDB Omni use la memoria del sistema y los recursos de E/S de forma más eficiente al gestionar cargas de trabajo pesadas.

Requisitos previos

Antes de empezar, asegúrate de que tus nodos de Kubernetes ejecuten el kernel de Linux 6.1 o una versión posterior, concretamente 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 Linux madwise.

En la siguiente tabla se indican 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 páginas enormes transparentes.		 within_size o always
/proc/sys/vm/max_map_count
Para obtener información sobre el número 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 los nodos de Kubernetes mediante un DaemonSet, haz lo siguiente:

  1. Aplica etiquetas a los nodos en los que tengas previsto ejecutar clústeres de bases de datos siguiendo las instrucciones de Añadir una etiqueta a un nodo.

  2. Para definir 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

    Haz los cambios siguientes:

    • DS_NAMESPACE: el espacio de nombres en el que quieres implementar el DaemonSet. Por ejemplo, default.
    • LABEL_KEY: el identificador de la etiqueta (por ejemplo, workload).
    • LABEL_VALUE: los datos asociados al identificador de la etiqueta, por ejemplo, database.
    • INIT_IMAGE: el nombre de la imagen usada para el contenedor init.
    • MAX_MAP_COUNT: el número máximo de áreas de asignación de memoria que puede crear un proceso. Por ejemplo, 1073741824.
    • CONTAINER_NAME: el nombre del contenedor principal (por ejemplo, main).
    • CONTAINER_IMAGE: el nombre de la imagen usada 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 tienes un pod por cada nodo con la etiqueta LABEL_KEY=LABEL_VALUE, usa el siguiente comando:

    kubectl get pods -l LABEL_KEY=LABEL_VALUE

    Un ejemplo de salida sería el siguiente:

    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 ha aplicado correctamente, ejecuta el siguiente comando en cada uno de los pods identificados después de implementar el DaemonSet:

    kubectl logs POD_NAME

    Sustituye POD_NAME por el nombre del pod cuyos registros quieras examinar.

    Un ejemplo de salida sería el siguiente:

    always [within_size] advise never deny force

Para desplegar clústeres de bases de datos en nodos de Kubernetes con los parámetros de kernel recomendados, añade 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 grupos 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 Asignar nodos a un clúster de bases de datos mediante la programación.

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

Para verificar que los parámetros del kernel se aplican a los pods de la base de datos, haz lo siguiente:

  1. Si la alta disponibilidad está habilitada, es decir, si spec.availability.numberOfStandbys tiene un valor superior a cero, comprueba 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

    Haz los cambios siguientes:

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

    Un ejemplo de salida sería el siguiente:

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

  2. Lista los pods de Kubernetes que pertenecen al clúster de la base de datos:

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

  3. Para consultar 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 ejemplo de salida sería el siguiente:

    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 cuando el pod esté en el estado Running.