Configurer les paramètres du kernel pour AlloyDB Omni sur Kubernetes

Sélectionnez une version de la documentation :

Cette page fournit des informations sur la configuration des nœuds Kubernetes qui hébergent les clusters de bases de données AlloyDB Omni pour des performances optimales de l'opérateur Kubernetes AlloyDB Omni et du moteur de base de données AlloyDB Omni.

La configuration des paramètres du noyau permet à AlloyDB Omni d'utiliser plus efficacement la mémoire système et les ressources d'E/S lors du traitement de charges de travail importantes.

Conditions préalables

Avant de commencer, assurez-vous que vos nœuds Kubernetes exécutent le noyau Linux 6.1 ou une version ultérieure, en particulier un noyau compatible avec les indicateurs MADV_COLLAPSE et MADV_POPULATE_WRITE. Pour en savoir plus sur ces options, consultez la documentation madwise de Linux.

Le tableau suivant répertorie les paramètres de noyau requis et leurs valeurs correspondantes pour les nœuds Kubernetes qui exécutent des pods de cluster de base de données :

Fichier Valeur
/sys/kernel/mm/transparent_hugepage/shmem_enabled
 Pour en savoir plus sur la mémoire partagée, consultez Transparent Hugepage Support.		 within_size ou always
/proc/sys/vm/max_map_count
 Pour en savoir plus sur le nombre de zones de mappage mémoire qu'un processus peut créer, consultez la documentation pour /proc/sys/vm.		 Supérieur ou égal à 1073741824

Pour configurer les paramètres du noyau sur vos nœuds Kubernetes à l'aide d'un DaemonSet, procédez comme suit :

  1. Appliquez des libellés aux nœuds sur lesquels vous prévoyez d'exécuter des clusters de bases de données en suivant les instructions de la section Ajouter un libellé à un nœud.

  2. Pour définir les paramètres du noyau sur les nœuds portant le libellé LABEL_KEY=LABEL_VALUE, créez 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

    Remplacez les éléments suivants :

    • DS_NAMESPACE : espace de noms dans lequel vous souhaitez déployer le DaemonSet (par exemple, default).
    • LABEL_KEY : identifiant du libellé (par exemple, workload).
    • LABEL_VALUE : données associées à l'identifiant du libellé, par exemple database.
    • INIT_IMAGE : nom de l'image utilisée pour le conteneur init.
    • MAX_MAP_COUNT : nombre maximal de zones de mappage mémoire qu'un processus peut créer, par exemple 1073741824.
    • CONTAINER_NAME : nom du conteneur principal, par exemple main.
    • CONTAINER_IMAGE : nom de l'image utilisée pour le conteneur principal, par exemple latest.

  3. Après avoir déployé le DaemonSet, pour vérifier que tous les pods de votre cluster Kubernetes sont à l'état Running et que vous disposez d'un pod pour chaque nœud portant le libellé LABEL_KEY=LABEL_VALUE, utilisez la commande suivante :

    kubectl get pods -l LABEL_KEY=LABEL_VALUE

    Voici un exemple de résultat :

    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. Pour vérifier que le flag du noyau a bien été appliqué, exécutez la commande suivante pour chacun des pods identifiés après le déploiement du DaemonSet :

    kubectl logs POD_NAME

    Remplacez POD_NAME par le nom du pod dont vous souhaitez examiner les journaux.

    Voici un exemple de résultat :

    always [within_size] advise never deny force

Pour déployer des clusters de bases de données sur des nœuds Kubernetes avec les paramètres de noyau recommandés, ajoutez une section nodeAffinity à l'une des sections suivantes du fichier manifeste de votre cluster de bases de données :

  • primarySpec.schedulingConfig pour les instances principales
  • spec.schedulingConfig pour les instances de pool de lecture
      nodeaffinity:
        requiredDuringSchedulingIgnoredDuringExecution:
          nodeSelectorTerms:
          - matchExpressions:
            - key: LABEL_KEY
              operator: In
              values:
              - "LABEL_VALUE"

Pour en savoir plus sur l'exécution de clusters de bases de données sur des nœuds Kubernetes spécifiques, consultez Attribuer des nœuds à un cluster de bases de données à l'aide de la planification.

Vérifier l'application des paramètres du noyau

Pour vérifier que les paramètres du noyau sont appliqués aux pods de base de données, procédez comme suit :

  1. Si la haute disponibilité est activée (c'est-à-dire si spec.availability.numberOfStandbys est défini sur une valeur supérieure à zéro), vérifiez que la ressource personnalisée de la base de données affiche DBClusterReady dans la colonne DBCLUSTERPHASE et True dans la colonne HAREADYSTATUS.

    kubectl get dbcluster -n DBCLUSTER_NAMESPACE DBCLUSTER_NAME

    Remplacez les éléments suivants :

    • DBCLUSTER_NAME : nom du cluster de base de données que vous vérifiez.
    • DBCLUSTER_NAMESPACE : nom de l'espace de noms spécifique dans lequel réside votre cluster de bases de données.

    Voici un exemple de résultat :

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

  2. Affichez la liste des pods Kubernetes appartenant au cluster de bases de données :

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

  3. Pour vérifier les informations sur la mémoire partagée, exécutez la commande suivante :

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

  4. Le résultat doit contenir des nombres différents de zéro dans toutes les entrées.

    Voici un exemple de résultat :

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

    Si 0 kB s'affiche dans l'une des entrées, redémarrez le pod correspondant :

    kubectl delete pod -n DBCLUSTER_NAMESPACE POD_NAME

  5. Répétez les étapes 1 à 5 une fois que le pod est à l'état Running.