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.
Appliquer les paramètres de noyau recommandés aux nœuds Kubernetes
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_enabledPour en savoir plus sur la mémoire partagée, consultez Transparent Hugepage Support. |
within_size ou always |
/proc/sys/vm/max_map_countPour 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 :
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.
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"] EOFRemplacez 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 exempledatabase.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 exemple1073741824.CONTAINER_NAME: nom du conteneur principal, par exemplemain.CONTAINER_IMAGE: nom de l'image utilisée pour le conteneur principal, par exemplelatest.
Après avoir déployé le DaemonSet, pour vérifier que tous les pods de votre cluster Kubernetes sont à l'état
Runninget 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_VALUEVoici 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 19sPour 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_NAMERemplacez
POD_NAMEpar le nom du pod dont vous souhaitez examiner les journaux.Voici un exemple de résultat :
always [within_size] advise never deny force
Exécuter des clusters de bases de données sur des nœuds Kubernetes avec les paramètres de noyau recommandés
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.schedulingConfigpour les instances principalesspec.schedulingConfigpour 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 :
Si la haute disponibilité est activée (c'est-à-dire si
spec.availability.numberOfStandbysest défini sur une valeur supérieure à zéro), vérifiez que la ressource personnalisée de la base de données afficheDBClusterReadydans la colonne DBCLUSTERPHASE etTruedans la colonne HAREADYSTATUS.kubectl get dbcluster -n DBCLUSTER_NAMESPACE DBCLUSTER_NAMERemplacez 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 ReadyAffichez 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_NAMEPour 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/meminfoLe 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 kBSi
0 kBs'affiche dans l'une des entrées, redémarrez le pod correspondant :kubectl delete pod -n DBCLUSTER_NAMESPACE POD_NAMERépétez les étapes 1 à 5 une fois que le pod est à l'état
Running.