Kernelparameter für AlloyDB Omni in Kubernetes konfigurieren

Wählen Sie eine Dokumentationsversion aus:

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 Systemarbeitsspeicher und E/A-Ressourcen bei der Verarbeitung von anspruchsvollen Arbeitslasten effizienter nutzen.

Voraussetzungen

Bevor Sie beginnen, müssen Sie dafür sorgen, dass auf Ihren Kubernetes-Knoten der 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 die entsprechenden Werte für Kubernetes-Knoten aufgeführt, auf denen Datenbankcluster-Pods ausgeführt werden:

Datei Wert
/sys/kernel/mm/transparent_hugepage/shmem_enabled
Informationen zum gemeinsam genutzten Speicher finden Sie unter Transparent Hugepage Support.		 within_size oder always
/proc/sys/vm/max_map_count
Informationen zur Anzahl der Memory Map-Bereiche, 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 Labels auf die Knoten an, auf denen Sie Datenbankcluster ausführen möchten. Folgen Sie dazu der Anleitung unter Label zu einem Knoten hinzufügen.

  2. Erstellen Sie ein DaemonSet, um die Kernelparameter für die Knoten mit dem Label LABEL_KEY=LABEL_VALUE festzulegen:

    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 Memory-Map-Bereichen, die ein Prozess erstellen kann, z. B. 1073741824.
    • CONTAINER_NAME: der Name des Hauptcontainers, z. B. main.
    • CONTAINER_IMAGE: der Name des Images, das für den Hauptcontainer verwendet wird, z. B. latest.

  3. Nachdem Sie das DaemonSet bereitgestellt haben, können Sie mit dem folgenden Befehl prüfen, ob sich alle Pods in Ihrem Kubernetes-Cluster im Status Running befinden und ob Sie einen Pod für jeden Knoten 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. Führen Sie für jeden der nach der Bereitstellung des DaemonSet identifizierten Pods den folgenden Befehl aus, um zu prüfen, ob das Kernel-Flag erfolgreich angewendet wurde:

    kubectl logs POD_NAME

    Ersetzen Sie POD_NAME durch den Namen des Pods, dessen Logs Sie untersuchen möchten.

    Eine Beispielausgabe sieht so aus:

    always [within_size] advise never deny force

Wenn Sie Datenbankcluster auf Kubernetes-Knoten mit empfohlenen Kernelparametern bereitstellen möchten, fügen Sie dem Manifest Ihres Datenbankclusters einen nodeAffinity-Abschnitt 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 von Kernelparametern prüfen

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

  1. Wenn 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 DBClusterReady und in der Spalte HAREADYSTATUS True angezeigt wird.

    kubectl get dbcluster -n DBCLUSTER_NAMESPACE DBCLUSTER_NAME

    Ersetzen Sie Folgendes:

    • DBCLUSTER_NAME: der Name des Datenbankclusters, den Sie überprüfen.
    • 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. Listen Sie die Kubernetes-Pods auf, 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 gemeinsam genutzten 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, starten Sie den entsprechenden Pod neu:

    kubectl delete pod -n DBCLUSTER_NAMESPACE POD_NAME

  5. Wiederholen Sie die Schritte 1 bis 5, nachdem sich der Pod im Status Running befindet.