Kernelparameter für AlloyDB Omni in Kubernetes konfigurieren

Auf dieser Seite finden Sie Informationen zum Einrichten von Kubernetes-Knoten, auf denen AlloyDB Omni-Datenbankcluster gehostet werden, um die Leistung des AlloyDB Omni Kubernetes-Operators und der AlloyDB Omni-Datenbank-Engine zu optimieren.

Durch die Konfiguration von Kernelparametern kann AlloyDB Omni den Systemspeicher und die E/A-Ressourcen bei hohen Arbeitslasten effizienter nutzen.

Voraussetzungen

Prüfen Sie vor Beginn, ob auf Ihren Kubernetes-Knoten Linux-Kernel 6.1 oder höher ausgeführt wird, insbesondere ein Kernel, der die Flags MADV_COLLAPSE und MADV_POPULATE_WRITE unterstützt. Weitere Informationen zu diesen Flags finden Sie in der madwise-Dokumentation für Linux.

In der folgenden Tabelle sind die erforderlichen Kernelparameter und ihre entsprechenden Werte für Kubernetes-Knoten aufgeführt, auf denen Datenbankcluster-Pods ausgeführt werden:

Datei Wert
/sys/kernel/mm/transparent_hugepage/shmem_enabled
 Weitere Informationen zum gemeinsamen Speicher finden Sie unter Transparent Hugepage Support.		 within_size oder always
/proc/sys/vm/max_map_count
Informationen zur Anzahl der Speicherzuordnungsbereiche, die ein Prozess erstellen kann, finden Sie in der Dokumentation für /proc/sys/vm.		 Größer als oder gleich 1073741824

So konfigurieren Sie die Kernelparameter auf Ihren Kubernetes-Knoten mit einem DaemonSet:

  1. Wenden Sie anhand der Anleitung unter Knoten ein Label hinzufügen Labels auf die Knoten an, auf denen Sie Datenbankcluster ausführen möchten.

  2. Wenn Sie die Kernelparameter auf den Knoten mit dem Label LABEL_KEY=LABEL_VALUE festlegen möchten, erstellen Sie ein 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

    Ersetzen Sie Folgendes:

    • DS_NAMESPACE: der Namespace, in dem Sie das DaemonSet bereitstellen möchten, z. B. default.
    • LABEL_KEY: die Kennung für das Label, z. B. workload.
    • LABEL_VALUE: die mit der Kennung für das Label verknüpften Daten, z. B. database.
    • INIT_IMAGE: Der Name des Images, das für den Init-Container verwendet wird.
    • MAX_MAP_COUNT: die maximale Anzahl von Speicherzuordnungsbereichen, die ein Prozess erstellen kann, z. B. 1073741824.
    • CONTAINER_NAME: der Name des Hauptcontainers, z. B. main.
    • CONTAINER_IMAGE: der Name des für den Hauptcontainer verwendeten Images, z. B. latest.

  3. Führen Sie nach der Bereitstellung des DaemonSet den folgenden Befehl aus, um zu prüfen, ob sich alle Pods in Ihrem Kubernetes-Cluster im Status Running befinden und Sie für jeden Knoten einen Pod mit dem Label LABEL_KEY=LABEL_VALUE haben:

    kubectl get pods -l LABEL_KEY=LABEL_VALUE

    Eine Beispielausgabe sieht so aus:

    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. Um zu prüfen, ob das Kernel-Flag angewendet wurde, führen Sie für jeden der nach der Bereitstellung des DaemonSets ermittelten Pods den folgenden Befehl aus:

    kubectl logs POD_NAME

    Ersetzen Sie POD_NAME durch den Namen des Pods, dessen Protokolle Sie prüfen möchten.

    Eine Beispielausgabe sieht so aus:

    always [within_size] advise never deny force

Wenn Sie Datenbankcluster mit empfohlenen Kernelparametern auf Kubernetes-Knoten bereitstellen möchten, fügen Sie einem der folgenden Abschnitte Ihres Datenbankcluster-Manifests den Abschnitt nodeAffinity hinzu:

  • primarySpec.schedulingConfig für primäre Instanzen
  • spec.schedulingConfig für Lesepoolinstanzen
      nodeaffinity:
        requiredDuringSchedulingIgnoredDuringExecution:
          nodeSelectorTerms:
          - matchExpressions:
            - key: LABEL_KEY
              operator: In
              values:
              - "LABEL_VALUE"

Weitere Informationen zum Ausführen von Datenbankclustern auf bestimmten Kubernetes-Knoten finden Sie unter Knoten einem Datenbankcluster mithilfe der Planung zuweisen.

Anwendung der Kernelparameter prüfen

So prüfen Sie, ob Kernelparameter auf Datenbank-Pods angewendet werden:

  1. Wenn die Hochverfügbarkeit aktiviert ist, insbesondere wenn spec.availability.numberOfStandbys auf einen Wert größer als null gesetzt ist, prüfen Sie, ob in der benutzerdefinierten Datenbankressource in der Spalte DBCLUSTERPHASE der Wert DBClusterReady und in der Spalte HAREADYSTATUS der Wert True angezeigt wird.

    kubectl get dbcluster -n DBCLUSTER_NAMESPACE DBCLUSTER_NAME

    Ersetzen Sie Folgendes:

    • DBCLUSTER_NAME: der Name des zu prüfenden Datenbankclusters.
    • DBCLUSTER_NAMESPACE: der Name des spezifischen Namespace, in dem sich Ihr Datenbankcluster befindet.

    Eine Beispielausgabe sieht so aus:

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

  2. Kubernetes-Pods auflisten, die zum Datenbankcluster gehören:

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

  3. Führen Sie den folgenden Befehl aus, um Informationen zum gemeinsamen Speicher zu prüfen:

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

  4. Die Ausgabe muss in allen Einträgen Zahlen enthalten, die nicht null sind.

    Eine Beispielausgabe sieht so aus:

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

    Wenn in einem der Einträge 0 kB angezeigt wird, starte den entsprechenden Pod neu:

    kubectl delete pod -n DBCLUSTER_NAMESPACE POD_NAME

  5. Wiederholen Sie die Schritte 1 bis 5, nachdem der Pod den Status Running hat.