Planifier le stockage et la taille des PVC

Sélectionnez une version de la documentation :

Pour éviter les temps d'arrêt de la base de données et la perte de données causés par l'épuisement de l'espace de stockage, vous devez planifier de manière appropriée les capacités de stockage et de PersistentVolumeClaim (PVC) pour vos clusters de bases de données AlloyDB Omni (DBCluster). Utilisez ces recommandations de dimensionnement pour configurer vos volumes lors du déploiement sur Kubernetes à l'aide de l'opérateur Kubernetes AlloyDB Omni.

Lorsque vous créez une ressource personnalisée DBCluster, l'opérateur AlloyDB Omni provisionne des PVC Kubernetes en fonction des disques que vous définissez dans les champs suivants :

  • Instances principales et de secours à haute disponibilité : configurées dans le champ spec.primarySpec.resources.disks de votre ressource personnalisée DBCluster. Si vous activez la haute disponibilité en configurant le champ spec.availability.numberOfStandbys, chaque instance répliquée de secours utilise la même configuration de disque que l'instance principale.
  • Instances du pool de lecture : configurées dans spec.resources.disks sur chaque ressource personnalisée DBInstance où instanceType est défini sur ReadPool. Si vous omettez la section spec.resources sur une ressource DBInstance, l'instance de pool de lecture hérite de la configuration de disque du champ spec.primarySpec.resources de la ressource DBCluster parente.

Volumes PVC acceptés

L'opérateur AlloyDB Omni ne provisionne pas tous les volumes PVC en même temps :

  • Toujours provisionné : l'opérateur provisionne toujours DataDisk, ObsDisk, BackupDisk et LogDisk pour tous les pods d'instance de base de données principale, de secours à disponibilité élevée et de pool de lecture. Vous devez spécifier explicitement DataDisk et sa taille dans votre fichier manifeste. Vous n'êtes pas obligé de spécifier ObsDisk, BackupDisk et LogDisk dans votre fichier manifeste. Si vous les omettez, comme indiqué dans le fichier manifeste d'installation de base, l'opérateur provisionne toujours ces PVC en utilisant leurs tailles par défaut.
  • Non provisionné par défaut : l'opérateur ne provisionne pas le volume BackupRepoDisk lorsque vous créez une ressource DBCluster autonome ou lorsque vous stockez des sauvegardes dans Cloud Storage ou Amazon S3. Il provisionne le pod du dépôt de sauvegarde et son PVC BackupRepoDisk uniquement lorsque vous créez une ressource BackupPlan pour stocker les sauvegardes localement sur votre cluster Kubernetes (c'est-à-dire une ressource BackupPlan sans champ backupLocation distant).

Le tableau suivant décrit les volumes persistants gérés par l'opérateur AlloyDB Omni :

Nom du disque Chemin d'installation Pod cible Configuration du fichier manifeste Comportement de provisionnement Objectif
DataDisk /mnt/disks/pgsql Pod de base de données Obligatoire Toujours provisionné pour chaque pod de base de données. Stocke le répertoire du cluster de base de données PostgreSQL (PGDATA), les tables, les index, les fichiers temporaires et les segments de journal WAL (Write-Ahead Log) actifs.
ObsDisk /obs Pod de base de données Facultatif (par défaut : 2Gi) Toujours provisionné pour chaque pod de base de données. Stocke les données d'observabilité, y compris les journaux du serveur PostgreSQL (postgresql.log), les journaux pgAudit (postgresql.audit), les journaux internes (postgresql.internal) et les archives des journaux .gz rotatifs.
BackupDisk /backup Pod de base de données Facultatif (par défaut : 10Gi) Toujours provisionné pour chaque pod de base de données. Fournit un répertoire de préproduction local pour les opérations de sauvegarde sur le pod de base de données.
LogDisk /archive Pod de base de données Facultatif (par défaut : 2Gi) Toujours provisionné pour chaque pod de base de données. Fournit une destination d'archive WAL dédiée pour les sidecars de sauvegarde personnalisés ou tiers. Si vous n'utilisez pas de side-car d'archivage WAL personnalisé, vous pouvez omettre ce disque de votre fichier manifeste et le laisser à sa taille par défaut de 2Gi.
BackupRepoDisk /backup Pod du dépôt de sauvegarde Facultatif (par défaut : 10Gi) Non provisionné par défaut. Provisionné uniquement lorsqu'une ressource BackupPlan stocke les sauvegardes en local (non provisionné lorsqu'aucune ressource BackupPlan n'est configurée ou lorsque les sauvegardes utilisent Cloud Storage ou Amazon S3). Fournit un volume dédié qui stocke les sauvegardes physiques de la base de données, les sauvegardes incrémentielles et différentielles, ainsi que les fichiers WAL archivés lorsque vous utilisez des sauvegardes de stockage local.

Recommandations de dimensionnement des PVC

Suivez les consignes ci-dessous pour dimensionner chaque volume de PVC en fonction de votre charge de travail, de votre configuration de journalisation et de votre stratégie de sauvegarde.

Volume DataDisk pour le stockage de la base de données principale

L'opérateur AlloyDB Omni provisionne toujours le volume DataDisk pour chaque pod de base de données. Vous devez spécifier explicitement sa taille dans votre fichier manifeste. Pour estimer la capacité minimale de DataDisk, utilisez la formule suivante :

DataDisk capacity = (initial_dataset_size + projected_growth + max_wal_size) * 1.30

Lorsque vous dimensionnez le volume DataDisk, tenez compte des facteurs suivants :

  • Frais généraux liés aux index : les index PostgreSQL et les tables du catalogue système nécessitent généralement 20% à 50% de stockage supplémentaire en plus des données brutes des tables.
  • Marge de manœuvre WAL active : les transactions d'écriture à haut débit accumulent des fichiers WAL dans le répertoire pg_wal jusqu'à ce que les points de contrôle soient terminés. Allouez suffisamment d'espace de stockage pour prendre en charge le paramètre de base de données max_wal_size que vous avez configuré (généralement plusieurs gigaoctets à plusieurs dizaines de gigaoctets, selon votre charge de travail). Pour afficher ou modifier les paramètres de base de données tels que max_wal_size, consultez Configurer les paramètres de base de données.
  • Fichiers temporaires et opérations vacuum : le tri des requêtes, la création et la réindexation d'index, ainsi que les opérations autovacuum nécessitent un espace disque temporaire supplémentaire.
  • Règle générale de dimensionnement : allouez 1,5 à 2 fois la taille brute de votre base de données, y compris une marge de sécurité d'au moins 30 %.

Volume ObsDisk pour les journaux de diagnostic et d'audit

L'opérateur AlloyDB Omni provisionne toujours le volume ObsDisk pour chaque pod de base de données (avec la taille par défaut 2Gi si vous l'omettez de votre fichier manifeste). Si le volume ObsDisk est plein, PostgreSQL ne peut pas écrire de nouvelles entrées de journal et la rotation des journaux peut être bloquée. Pour savoir comment configurer les paramètres de rotation et de conservation des journaux pour le volume ObsDisk, consultez Configurer la rotation des journaux.

Lorsque vous dimensionnez le volume ObsDisk, tenez compte des consignes suivantes :

  • Journalisation standard : un volume de 4 à 10 Gio est suffisant pour la journalisation opérationnelle standard avec les paramètres de rotation des journaux par défaut (seuil de rotation de 200 Mo et durée de conservation de sept jours).
  • Journalisation d'audit (pgAudit) : lorsque vous activez la journalisation d'audit avec pgAudit, le volume de journaux généré est beaucoup plus important. Allouez entre 20 Gio et 50 Gio ou plus, en fonction de votre taux de requêtes et de la verbosité des règles d'audit.

Volume BackupRepoDisk pour le dépôt de sauvegarde local

Contrairement aux disques de pods de base de données, BackupRepoDisk n'est pas provisionné par défaut. L'opérateur AlloyDB Omni provisionne le pod du dépôt de sauvegarde et son PVC BackupRepoDisk uniquement lorsque vous créez une ressource BackupPlan pour stocker les sauvegardes localement sur votre cluster Kubernetes sans champ backupLocation distant. Si vous omettez ce disque de votre fichier manifeste DBCluster, il utilise la taille par défaut de 10Gi. Si vous ne configurez pas de ressource BackupPlan, ou si votre ressource BackupPlan utilise Cloud Storage avec le type GCS ou Amazon S3 avec le type S3, l'opérateur ne provisionne pas BackupRepoDisk. Pour en savoir plus sur la configuration des plans de sauvegarde et le redimensionnement de l'espace de stockage des sauvegardes, consultez Sauvegarder et restaurer dans Kubernetes et Redimensionner un disque de sauvegarde.

Lorsque vous stockez des sauvegardes localement, le volume BackupRepoDisk stocke les sauvegardes complètes, différentielles et incrémentielles compressées, ainsi que les fichiers WAL archivés. L'espace de stockage total requis dépend de la taille de votre base de données, du taux de variation quotidien des données, du calendrier de sauvegarde défini dans backupSchedules et de la période de conservation définie par backupRetainDays :

  • Compression des sauvegardes : les sauvegardes compressées utilisent généralement 37% à 38% de la taille de la base de données non compressée, ce qui représente une réduction de taille de 62% à 63 %. Par exemple, une base de données de 50 Gio est compressée à environ 18,5 Gio.
  • Programmation et conservation des sauvegardes : la combinaison de sauvegardes complètes hebdomadaires avec des sauvegardes incrémentielles ou différentielles quotidiennes nécessite beaucoup moins d'espace de stockage que des sauvegardes complètes quotidiennes.

Le tableau suivant présente l'utilisation maximale du stockage et la taille BackupRepoDisk recommandée (y compris une marge de 20 %) pour différents plannings de sauvegarde pour une base de données de 100 Gio avec un taux de modification des données quotidien de 10% et la période de conservation par défaut de 14 jours (backupRetainDays: 14) :

Planning des sauvegardes (backupSchedules) Nombre maximal de sauvegardes complètes Sauvegardes différentielles Sauvegardes incrémentielles Fichiers WAL archivés Pic d'espace de stockage utilisé Taille recommandée de BackupRepoDisk (+ 20% de marge)
Couverture complète hebdomadaire + couverture incrémentale quotidienne 148.0 GiB 0 Gio 66,6 Gio 155.4 GiB 370.0 Gio 444 Gio (environ 4,4 fois la taille de la base de données)
Différentiel hebdomadaire complet + en milieu de semaine + incrémentiel quotidien 148.0 GiB 22,2 Gio 44.4 GiB 155.4 GiB 370.0 Gio 444 Gio (environ 4,4 fois la taille de la base de données)
Différentiel quotidien + hebdomadaire complet 148.0 GiB 155.4 GiB 0 Gio 155.4 GiB 458.8 GiB 551 Gio (environ 5,5 fois la taille de la base de données)
Sauvegarde complète quotidienne uniquement (planning par défaut) 592,0 Gio 0 Gio 0 Gio 111,0 Gio 703,0 Gio 844 Gio (environ 8,4 fois la taille de la base de données)

Volume BackupDisk pour la préproduction de la sauvegarde du pod de base de données

L'opérateur AlloyDB Omni provisionne toujours le volume BackupDisk pour chaque pod de base de données avec une taille par défaut de 10 Gio (10Gi). AlloyDB Omni utilise le volume BackupDisk comme répertoire de préparation local lors des opérations de sauvegarde. Étant donné que la taille par défaut de 10 Gio est suffisante pour les opérations standards, vous pouvez omettre BackupDisk de votre fichier manifeste DBCluster pour utiliser la taille par défaut.

Volume LogDisk pour l'archivage WAL personnalisé

L'opérateur AlloyDB Omni provisionne toujours le volume LogDisk pour chaque pod de base de données avec une taille par défaut de 2 Gio (2Gi). Vous n'avez besoin de spécifier une taille personnalisée pour le volume LogDisk que si vous déployez un conteneur side-car personnalisé ou tiers qui archive les fichiers WAL dans le répertoire /archive. Pour les déploiements standards de l'opérateur AlloyDB Omni qui utilisent des sauvegardes intégrées, vous pouvez omettre LogDisk de votre fichier manifeste DBCluster et le laisser à sa taille par défaut 2Gi.

Référence de dimensionnement par taille de l'ensemble de données

Le tableau suivant indique les tailles de PVC recommandées pour les tailles d'ensembles de données bruts courantes :

Taille des données brutes Taille recommandée : DataDisk Taille recommandée : ObsDisk Taille recommandée de BackupRepoDisk (provisionnée pour les sauvegardes locales uniquement) Taille recommandée : BackupDisk Taille recommandée : LogDisk
50 Gio 100 Gio 4 Gio (10 à 20 Gio avec pgAudit) 150 Gio 10 Gio (par défaut) 2 Gio (par défaut)
200 Gio 400 Gio 10 Gio (20 à 50 Gio avec pgAudit) 600 Gio 10 Gio (par défaut) 2 Gio (par défaut)
500 Gio 1 000 Gio (1 Tio) 15 Gio (30 à 60 Gio avec pgAudit) 1 500 Gio (1,5 Tio) 10 Gio (par défaut) 2 Gio (par défaut)
1 Tio 2 000 Gio (2 Tio) 20 Gio (50 à 100 Gio avec pgAudit) 3 000 Gio (3 Tio) 10 Gio (par défaut) 2 Gio (par défaut)

Surveiller l'utilisation du disque et les métriques d'E/S

Vous pouvez surveiller l'utilisation du disque en direct directement dans vos pods de base de données et de dépôt de sauvegarde à l'aide de kubectl ou en collectant les métriques Prometheus exportées par AlloyDB Omni.

Vérifiez l'utilisation du disque à l'aide de kubectl.

Pour vérifier l'utilisation actuelle de l'espace disque des volumes PVC montés dans votre pod de base de données et votre pod de dépôt de sauvegarde, exécutez les commandes suivantes :

  1. Récupérez le nom du pod de base de données pour votre ressource DBCluster :

    export DB_POD=$(kubectl get pod -n NAMESPACE -l alloydbomni.internal.dbadmin.goog/dbcluster=DB_CLUSTER_NAME,alloydbomni.internal.dbadmin.goog/task-type=database -o jsonpath='{.items[0].metadata.name}')

    Remplacez les éléments suivants :

    • NAMESPACE : espace de noms Kubernetes dans lequel votre cluster de bases de données est déployé.
    • DB_CLUSTER_NAME : nom de votre cluster de bases de données.

  2. Exécutez df -h dans le conteneur de base de données pour afficher la capacité et l'utilisation des volumes DataDisk (/mnt/disks/pgsql), ObsDisk (/obs), BackupDisk (/backup) et LogDisk (/archive) :

    kubectl exec -n NAMESPACE "${DB_POD}" -c database -- df -h /mnt/disks/pgsql /obs /backup /archive

  3. Si vous avez configuré une ressource BackupPlan pour stocker les sauvegardes en local, obtenez le nom du pod du dépôt de sauvegarde et exécutez df -h pour afficher la capacité et l'utilisation du volume BackupRepoDisk (/backup) :

    export BACKUP_REPO_POD=$(kubectl get pod -n NAMESPACE -l alloydbomni.internal.dbadmin.goog/dbcluster=DB_CLUSTER_NAME,alloydbomni.internal.dbadmin.goog/backup-repository -o jsonpath='{.items[0].metadata.name}')
kubectl exec -n NAMESPACE "${BACKUP_REPO_POD}" -c backuprepo -- df -h /backup

Surveiller les métriques de stockage à l'aide de Prometheus

AlloyDB Omni exporte les métriques de stockage et d'E/S de disque sur le service al-INSTANCE_ID-DB_CLUSTER_NAME-monitoring-system (port 9187). Pour savoir comment extraire et interroger ces métriques, consultez Surveiller AlloyDB Omni. Pour obtenir la liste complète des métriques disponibles, consultez Métriques AlloyDB Omni.

Surveillez les métriques de disque suivantes :

  • Utilisation et capacité de stockage : surveillez les métriques alloydb_omni_node_storage_usage_per_disk_byte et alloydb_omni_node_storage_limit_per_disk_byte, qui indiquent l'utilisation de l'espace de stockage et la capacité totale en octets pour chaque volume à l'aide du libellé disk (par exemple, DataDisk, ObsDisk ou BackupDisk). Configurez des alertes lorsque l'utilisation du disque atteint 80% et 90% de la capacité afin de pouvoir étendre les volumes avant qu'ils ne manquent d'espace.
  • Débit et opérations d'E/S du disque : surveillez les métriques alloydb_omni_node_storage_read_bytes_count_total et alloydb_omni_node_storage_write_bytes_count_total pour le débit de lecture et d'écriture du disque, ainsi que les métriques alloydb_omni_node_storage_read_ops_count_total et alloydb_omni_node_storage_write_ops_count_total pour les opérations d'E/S de lecture et d'écriture.

Redimensionner les PVC pour un DBCluster existant

Si vous avez déjà créé une ressource DBCluster en suivant Créer un cluster de bases de données, votre fichier manifeste initial n'a probablement spécifié que le volume DataDisk (par exemple, 10Gi), tandis que l'opérateur AlloyDB Omni a provisionné les volumes ObsDisk (2Gi), BackupDisk (10Gi) et LogDisk (2Gi) avec leurs tailles par défaut. Vous pouvez étendre n'importe quel PVC en mettant à jour votre fichier manifeste DBCluster.

Avant de redimensionner un PVC, vérifiez les exigences et les limites suivantes :

  • Expansion du volume StorageClass : vous ne pouvez augmenter la taille d'un disque que si sa ressource StorageClass Kubernetes définit allowVolumeExpansion: true. Pour en savoir plus, consultez Développer les revendications de volumes persistants.
  • Pas de réduction ni de modification de StorageClass : vous ne pouvez pas réduire la taille d'un disque ni modifier le champ storageClass d'un PVC existant après son provisionnement.
  • Redimensionner des disques de taille par défaut : pour étendre un disque que vous avez précédemment omis de votre fichier manifeste (comme le volume ObsDisk ou le volume BackupRepoDisk), ajoutez une entrée pour ce disque au champ spec.primarySpec.resources.disks avec un champ size d'une capacité supérieure à sa capacité par défaut actuelle. Conservez toujours DataDisk et toutes les autres entrées de disque existantes dans la liste disks lorsque vous mettez à jour le fichier manifeste.
  • Comportement de redémarrage des pods : lorsque vous modifiez le champ resources.disks, l'opérateur AlloyDB Omni met à jour le PVC sous-jacent et redémarre le pod de l'instance de base de données pour appliquer la nouvelle spécification de ressource. Effectuez l'extension du stockage pendant un intervalle de maintenance planifié ou configurez la haute disponibilité pour minimiser les temps d'arrêt.

Pour inspecter et redimensionner les PVC de votre DBCluster, procédez comme suit :

  1. Listez les PVC dans l'espace de noms de votre cluster de base de données pour vérifier leurs capacités actuelles et la ressource StorageClass :

    kubectl get pvc -n NAMESPACE

    Remplacez NAMESPACE par l'espace de noms dans lequel vous avez déployé votre DBCluster (par exemple, default).

    Le résultat ressemble à ce qui suit pour un cluster nommé my-db-cluster :

    NAME                                STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   AGE
backupdisk-al-1060-my-db-cluster-0  Bound    pvc-45a28be2-a111-40ed-9641-61b9d25f313b   10Gi       RWO            standard-rwo   10m
datadisk-al-1060-my-db-cluster-0    Bound    pvc-c23a1ab8-f97c-4449-9072-502b6d9ba869   10Gi       RWO            standard-rwo   10m
logdisk-al-1060-my-db-cluster-0     Bound    pvc-f0c41d15-bb13-4d28-b94b-01a28dc67ef6   2Gi        RWO            standard-rwo   10m
obsdisk-al-1060-my-db-cluster-0     Bound    pvc-69ea1ca7-a868-4dc9-a9f8-503d5e5f2387   2Gi        RWO            standard-rwo   10m

  2. Vérifiez que la ressource StorageClass utilisée par vos PVC est compatible avec l'expansion de volume :

    kubectl get storageclass STORAGE_CLASS_NAME -o jsonpath='{.allowVolumeExpansion}{"\n"}'

    Remplacez STORAGE_CLASS_NAME par le nom de la classe de stockage de la colonne STORAGECLASS de la sortie précédente (par exemple, standard-rwo). Vérifiez que la commande renvoie true.

  3. Mettez à jour le champ spec.primarySpec.resources.disks dans le fichier manifeste DBCluster pour augmenter la valeur size du volume DataDisk et ajouter les disques de taille par défaut dont vous avez besoin pour l'étendre (comme le volume ObsDisk ou le volume BackupRepoDisk).

    L'exemple de fichier manifeste suivant étend le volume DataDisk à 400Gi, étend le volume ObsDisk de sa valeur par défaut 2Gi à 10Gi et configure le volume BackupRepoDisk à 600Gi pour une charge de travail de 200 Gio :

    apiVersion: alloydbomni.dbadmin.goog/v1
kind: DBCluster
metadata:
  name: DB_CLUSTER_NAME
  namespace: NAMESPACE
spec:
  databaseVersion: "18.3.0"
  primarySpec:
    adminUser:
      passwordRef:
        name: db-pw-DB_CLUSTER_NAME
    resources:
      cpu: 4
      memory: 32Gi
      disks:
      - name: DataDisk
        size: 400Gi
        storageClass: STORAGE_CLASS_NAME
      - name: ObsDisk
        size: 10Gi
        storageClass: STORAGE_CLASS_NAME
      - name: BackupRepoDisk
        size: 600Gi
        storageClass: STORAGE_CLASS_NAME

    Remplacez les éléments suivants :

    • DB_CLUSTER_NAME : nom de votre cluster de bases de données, par exemple my-db-cluster.
    • NAMESPACE : espace de noms de votre cluster de bases de données.
    • STORAGE_CLASS_NAME : nom de la ressource StorageClass Kubernetes utilisée par vos volumes persistants (par exemple, standard-rwo). Si vous avez omis le champ storageClass lors de la création du cluster, vous pouvez continuer à l'omettre afin que l'opérateur utilise le StorageClass par défaut de votre cluster.

  4. Appliquez le fichier manifeste DBCluster mis à jour :

    kubectl apply -f DB_CLUSTER_MANIFEST.yaml

    Remplacez DB_CLUSTER_MANIFEST par le chemin d'accès à votre fichier manifeste DBCluster.

  5. Vérifiez que les PVC et l'état DBCluster reflètent les tailles étendues :

    kubectl get pvc -n NAMESPACE

    Vous pouvez également inspecter le champ d'état allocatedResources.disks sur la ressource DBCluster :

    kubectl get dbcluster DB_CLUSTER_NAME -n NAMESPACE -o jsonpath='{.status.primary.allocatedResources.disks}{"\n"}'

    Remplacez les éléments suivants :

    • NAMESPACE : espace de noms de votre cluster de bases de données.
    • DB_CLUSTER_NAME : nom de votre cluster de bases de données.

Pour en savoir plus sur le redimensionnement des ressources de calcul et de stockage, consultez Redimensionner votre cluster de bases de données basé sur Kubernetes.

Étapes suivantes