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 des 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 kernel 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 kernel Linux 6.1 ou une version ultérieure, en particulier un kernel qui prend en charge les indicateurs MADV_COLLAPSE et MADV_POPULATE_WRITE. Pour en savoir plus sur ces indicateurs, consultez la documentation Linux madwise.

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

Fichier Valeur
/sys/kernel/mm/transparent_hugepage/shmem_enabled
Pour en savoir plus sur la mémoire partagée, consultez la section Prise en charge des pages énormes transparentes		 within_size ou always
/proc/sys/vm/max_map_count
Pour en savoir plus sur le nombre de zones de mappage de mémoire qu'un processus peut créer, consultez la documentation de /proc/sys/vm		 Supérieur ou égal à 1073741824

Pour configurer les paramètres du kernel 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 kernel sur les nœuds libellés 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 d'initialisation.
    • MAX_MAP_COUNT : nombre maximal de zones de mappage de 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 avec le libellé LABEL_KEY=LABEL_VALUE, utilisez la commande suivante :

    kubectl get pods -l LABEL_KEY=LABEL_VALUE

    Voici un exemple de sortie :

    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 l'indicateur de kernel est correctement 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 sortie :

    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 kernel 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 la section Attribuer des nœuds à un cluster de bases de données à l'aide de la planification.

Vérifier l'application des paramètres de kernel

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

  1. Si la haute disponibilité est activée, en particulier 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 bases 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 sortie :

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

  2. Répertoriez les pods Kubernetes qui appartiennent 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. La sortie doit contenir des nombres différents de zéro dans toutes les entrées.

    Voici un exemple de sortie :

    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.