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 optimale Leistung des AlloyDB Omni Kubernetes-Operators und der AlloyDB Omni-Datenbank-Engine zu gewährleisten.

Durch das Konfigurieren von Kernelparametern kann AlloyDB Omni Systemarbeitsspeicher und E/A-Ressourcen bei der Verarbeitung hoher Arbeitslasten effizienter nutzen.

Voraussetzungen

Bevor Sie beginnen, muss auf Ihren Kubernetes-Knoten Linux-Kernel 6.1 oder höher ausgeführt werden, insbesondere ein Kernel, der die Flags MADV_COLLAPSE und MADV_POPULATE_WRITE unterstützt. Weitere Informationen zu diesen Flags finden Sie in der Linux madwise Dokumentation.

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 gemeinsamen Arbeitsspeicher finden Sie unter Unterstützung für transparente Hugepages		 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 zu /proc/sys/vm		 Größer 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 auf den 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 Daten, die mit der Kennung für das Label verknüpft sind, z. B. database.
    • INIT_IMAGE: der Name des Images, das für den Init-Container verwendet wird.
    • MAX_MAP_COUNT: die maximale Anzahl der Speicherzuordnungsbereiche, 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, prüfen Sie mit dem folgenden Befehl, ob sich alle Pods in Ihrem Kubernetes-Cluster im Status Running befinden und ob für jeden Knoten mit dem Label LABEL_KEY=LABEL_VALUE ein Pod vorhanden ist:

    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 Pods, die nach der Bereitstellung des DaemonSets identifiziert wurden, 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 prüfen 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 einen nodeAffinity-Abschnitt zu einem der folgenden Abschnitte Ihres Datenbankcluster-Manifests 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 mithilfe der Planung einem Datenbankcluster zuweisen.

Anwendung von Kernelparametern prüfen

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

  1. Wenn die Hochverfügbarkeit aktiviert ist und spec.availability.numberOfStandbys auf einen Wert größer als null festgelegt 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 prü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 gemeinsamen Arbeitsspeicher 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 der Pod den Status Running hat.