Pianificare le dimensioni dello spazio di archiviazione e dei PVC

Seleziona una versione della documentazione:

Per evitare tempi di inattività del database e perdita di dati causati dall'esaurimento dello spazio di archiviazione, devi pianificare in modo appropriato le capacità di archiviazione e Persistent Volume Claim (PVC) per i cluster di database AlloyDB Omni (DBCluster). Utilizza questi consigli sul dimensionamento per configurare i volumi durante il deployment su Kubernetes utilizzando l'operatore Kubernetes di AlloyDB Omni.

Quando crei una risorsa personalizzata DBCluster, l'operatore AlloyDB Omni esegue il provisioning dei PVC Kubernetes in base ai dischi che definisci nei seguenti campi:

  • Istanze principali e in standby ad alta disponibilità (HA): configurate nel campo spec.primarySpec.resources.disks della risorsa personalizzata DBCluster. Se attivi l'alta affidabilità configurando il campo spec.availability.numberOfStandbys, ogni replica di standby utilizza la stessa configurazione del disco dell'istanza principale.
  • Istanze del pool di lettura: configurate in spec.resources.disks su ogni DBInstancerisorsa personalizzata in cui instanceType è impostato su ReadPool. Se ometti la sezione spec.resources in una risorsa DBInstance, l'istanza del pool di lettura eredita la configurazione del disco dal campo spec.primarySpec.resources della risorsa DBCluster padre.

Volumi PVC supportati

L'operatore AlloyDB Omni non esegue il provisioning di tutti i volumi PVC contemporaneamente:

  • Sempre sottoposto a provisioning: l'operatore esegue sempre il provisioning di DataDisk, ObsDisk, BackupDisk e LogDisk per tutti i pod delle istanze di database principali, in standby HA e del pool di lettura. Devi specificare esplicitamente DataDisk e le relative dimensioni nel file manifest. La specifica di ObsDisk, BackupDisk e LogDisk nel manifest è facoltativa. Se li ometti, come mostrato nel file manifest di installazione di base, l'operatore provisiona comunque questi PVC utilizzando le dimensioni predefinite.
  • Non viene eseguito il provisioning per impostazione predefinita: l'operatore non esegue il provisioning del volume BackupRepoDisk quando crei una risorsa DBCluster autonoma o quando memorizzi i backup in Cloud Storage o Amazon S3. Esegue il provisioning del pod del repository di backup e del relativo PVC BackupRepoDisk solo quando crei una risorsa BackupPlan per archiviare i backup localmente sul tuo cluster Kubernetes (ovvero una risorsa BackupPlan senza un campo backupLocation remoto).

La tabella seguente descrive i volumi permanenti gestiti dall'operatore AlloyDB Omni:

Nome disco Percorso montaggio Pod di destinazione Configurazione del manifest Comportamento di provisioning Finalità
DataDisk /mnt/disks/pgsql Pod del database Obbligatorio Sempre sottoposto a provisioning per ogni pod di database. Archivia la directory del cluster di database PostgreSQL (PGDATA), tabelle, indici, file temporanei e segmenti di log write-ahead (WAL) attivi.
ObsDisk /obs Pod del database (Facoltativo, valore predefinito: 2Gi) Sempre sottoposto a provisioning per ogni pod di database. Archivia i dati di osservabilità, inclusi i log del server PostgreSQL (postgresql.log), i log pgAudit (postgresql.audit), i log interni (postgresql.internal) e gli archivi dei log .gz ruotati.
BackupDisk /backup Pod del database (Facoltativo, valore predefinito: 10Gi) Sempre sottoposto a provisioning per ogni pod di database. Fornisce una directory di staging locale per le operazioni di backup sul pod del database.
LogDisk /archive Pod del database (Facoltativo, valore predefinito: 2Gi) Sempre sottoposto a provisioning per ogni pod di database. Fornisce una destinazione di archivio WAL dedicata per i sidecar di backup personalizzati o di terze parti. Se non utilizzi un sidecar di archiviazione WAL personalizzato, puoi omettere questo disco dal manifest e lasciarlo con le dimensioni predefinite di 2Gi.
BackupRepoDisk /backup Pod del repository di backup (Facoltativo, valore predefinito: 10Gi) Non viene eseguito il provisioning per impostazione predefinita. Eseguito il provisioning solo quando una risorsa BackupPlan archivia i backup localmente (non viene eseguito il provisioning quando non è configurato alcun BackupPlan o quando i backup utilizzano Cloud Storage o Amazon S3). Fornisce un volume dedicato che archivia i backup fisici del database, i backup incrementali e i backup differenziali e i file WAL archiviati quando utilizzi i backup dell'archiviazione locale.

Suggerimenti per il dimensionamento dei volumi persistenti

Utilizza le seguenti linee guida per dimensionare ogni volume PVC in base al tuo workload, alla configurazione di logging e alla strategia di backup.

DataDisk volume per lo spazio di archiviazione del database principale

L'operatore AlloyDB Omni esegue sempre il provisioning del volume DataDisk per ogni pod di database e devi specificarne esplicitamente le dimensioni nel manifest. Per stimare la capacità minima per DataDisk, utilizza la seguente formula:

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

Quando dimensiona il volume DataDisk, tieni conto dei seguenti fattori:

  • Overhead dell'indice: gli indici PostgreSQL e le tabelle del catalogo di sistema in genere richiedono un ulteriore 20-50% di spazio di archiviazione oltre ai dati della tabella non elaborati.
  • Spazio libero WAL attivo: le transazioni di scrittura a velocità effettiva elevata accumulano file WAL nella directory pg_wal fino al completamento dei checkpoint. Alloca spazio di archiviazione sufficiente per ospitare il parametro del database max_wal_size configurato (in genere da diversi gigabyte a decine di gigabyte, a seconda del workload). Per visualizzare o modificare i parametri del database, ad esempio max_wal_size, consulta Configurare i parametri del database.
  • File temporanei e operazioni di vacuum: l'ordinamento delle query, la creazione di indici, la reindicizzazione e le operazioni di autovacuum richiedono spazio su disco temporaneo aggiuntivo.
  • Regola generale per il dimensionamento: alloca da 1,5 a 2 volte le dimensioni del database non elaborato, incluso un buffer di sicurezza di almeno il 30%.

Volume ObsDisk per i log di controllo e diagnostica

L'operatore AlloyDB Omni esegue sempre il provisioning del volume ObsDisk per ogni pod di database (con le dimensioni predefinite 2Gi se lo ometti dal manifest). Se il volume ObsDisk si riempie, PostgreSQL non può scrivere nuove voci di log e la rotazione dei log può bloccarsi. Per informazioni su come configurare le impostazioni di rotazione e conservazione dei log per il volume ObsDisk, consulta Configurare la rotazione dei log.

Quando dimensiona il volume ObsDisk, considera le seguenti linee guida:

  • Logging standard: un volume da 4 GB a 10 GB è sufficiente per il logging operativo standard con le impostazioni di rotazione dei log predefinite (soglia di rotazione di 200 MB e conservazione di 7 giorni).
  • Audit logging (pgAudit): quando attivi l'audit logging con pgAudit, l'audit logging genera un volume di log notevolmente superiore. Alloca da 20 GiB a 50 GiB o più, a seconda della frequenza delle query e del livello di dettaglio delle regole di controllo.

Volume BackupRepoDisk per il repository di backup locale

A differenza dei dischi del pod di database, BackupRepoDisk non viene sottoposto a provisioning per impostazione predefinita. L'operatore AlloyDB Omni esegue il provisioning del pod del repository di backup e del relativo PVC BackupRepoDisk solo quando crei una risorsa BackupPlan per archiviare i backup localmente sul tuo cluster Kubernetes senza un campo backupLocation remoto. Se ometti questo disco dal manifest DBCluster, viene utilizzata la dimensione predefinita di 10Gi. Se non configuri una risorsa BackupPlan o se la risorsa BackupPlan utilizza Cloud Storage con il tipo GCS o Amazon S3 con il tipo S3, l'operatore non esegue il provisioning di BackupRepoDisk. Per ulteriori informazioni sulla configurazione dei piani di backup e sul ridimensionamento dello spazio di archiviazione dei backup, vedi Backup e ripristino in Kubernetes e Ridimensionare un disco di backup.

Quando memorizzi i backup localmente, il volume BackupRepoDisk memorizza i backup completi, differenziali e incrementali compressi insieme ai file WAL archiviati. Lo spazio di archiviazione totale richiesto dipende dalle dimensioni del database, dalla velocità di modifica giornaliera dei dati, dalla pianificazione dei backup definita in backupSchedules e dal periodo di conservazione impostato da backupRetainDays:

  • Compressione dei backup: i backup compressi in genere utilizzano il 37-38% delle dimensioni del database non compresso, il che rappresenta una riduzione delle dimensioni del 62-63%. Ad esempio, un database da 50 GiB viene compresso a circa 18,5 GiB.
  • Pianificazione e conservazione dei backup: la combinazione di backup completi settimanali con backup incrementali o backup differenziali giornalieri richiede molto meno spazio di archiviazione rispetto all'esecuzione di backup completi giornalieri.

La seguente tabella mostra l'utilizzo dello spazio di archiviazione di picco di riferimento e le dimensioni BackupRepoDisk consigliate (incluso un buffer del 20%) in diversi programmi di backup per un database da 100 GiB con un tasso di modifica giornaliero dei dati del 10% e il periodo di conservazione predefinito di 14 giorni (backupRetainDays: 14):

Pianificazione del backup (backupSchedules) Picco di backup completi Backup differenziali Backup incrementali File WAL archiviati Picco di spazio di archiviazione utilizzato Dimensioni consigliate di BackupRepoDisk (+ buffer del 20%)
Settimanale completo + incrementale giornaliero 148,0 GiB 0 GiB 66,6 GiB 155,4 GiB 370,0 GiB 444 GiB (~4,4 volte le dimensioni del database)
Settimanale completo + differenziale di metà settimana + incrementale giornaliero 148,0 GiB 22,2 GiB 44,4 GiB 155,4 GiB 370,0 GiB 444 GiB (~4,4 volte le dimensioni del database)
Settimanale completo + differenziale giornaliero 148,0 GiB 155,4 GiB 0 GiB 155,4 GiB 458,8 GiB 551 GiB (~5,5 volte le dimensioni del database)
Solo giornaliero completo (programma predefinito) 592,0 GiB 0 GiB 0 GiB 111,0 GiB 703,0 GiB 844 GiB (~8,4 volte le dimensioni del database)

Volume BackupDisk per la gestione temporanea del backup dei pod di database

L'operatore AlloyDB Omni esegue sempre il provisioning del volume BackupDisk per ogni pod del database con una dimensione predefinita di 10 GiB (10Gi). AlloyDB Omni utilizza il volume BackupDisk come directory di gestione temporanea locale durante le operazioni di backup. Poiché la dimensione predefinita di 10 GB è sufficiente per le operazioni standard, puoi omettere BackupDisk dal manifest DBCluster per utilizzare la dimensione predefinita.

LogDisk volume per l'archiviazione WAL personalizzata

L'operatore AlloyDB Omni esegue sempre il provisioning del volume LogDisk per ogni pod del database con una dimensione predefinita di 2 GiB (2Gi). Devi specificare una dimensione personalizzata per il volume LogDisk solo se implementi un container sidecar personalizzato o di terze parti che archivia i file WAL nella directory /archive. Per le implementazioni standard dell'operatore AlloyDB Omni che utilizzano i backup integrati, puoi omettere LogDisk dal manifest DBCluster e lasciare la dimensione 2Gi predefinita.

Riferimento per il dimensionamento in base alle dimensioni del set di dati

La tabella seguente fornisce le dimensioni dei PVC consigliate per le dimensioni dei set di dati non elaborati comuni:

Dimensione dei dati non elaborati Dimensioni consigliate per DataDisk Dimensioni consigliate per ObsDisk Dimensioni consigliate di BackupRepoDisk (provisioning solo per i backup locali) Dimensioni consigliate per BackupDisk Dimensioni consigliate per LogDisk
50 GiB 100 GiB 4 GiB (da 10 a 20 GiB con pgAudit) 150 GB 10 GiB (valore predefinito) 2 GiB (valore predefinito)
200 GB 400 GiB 10 GiB (da 20 a 50 GiB con pgAudit) 600 GiB 10 GiB (valore predefinito) 2 GiB (valore predefinito)
500 GiB 1000 GiB (1 TiB) 15 GiB (da 30 a 60 GiB con pgAudit) 1500 GiB (1,5 TiB) 10 GiB (valore predefinito) 2 GiB (valore predefinito)
1 TiB 2000 GiB (2 TiB) 20 GiB (da 50 a 100 GiB con pgAudit) 3000 GiB (3 TiB) 10 GiB (valore predefinito) 2 GiB (valore predefinito)

Monitora l'utilizzo del disco e le metriche di I/O

Puoi monitorare l'utilizzo del disco in tempo reale direttamente all'interno dei pod del repository di database e backup utilizzando kubectl o raccogliendo le metriche Prometheus esportate da AlloyDB Omni.

Controlla l'utilizzo del disco utilizzando kubectl

Per controllare l'utilizzo attuale dello spazio su disco dei volumi PVC montati all'interno del pod del database e del pod del repository di backup, esegui i seguenti comandi:

  1. Recupera il nome del pod del database per la risorsa 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}')

    Sostituisci quanto segue:

    • NAMESPACE: lo spazio dei nomi Kubernetes in cui è distribuito il cluster di database.
    • DB_CLUSTER_NAME: il nome del cluster di database.

  2. Esegui df -h all'interno del container del database per visualizzare la capacità e l'utilizzo dei volumi DataDisk (/mnt/disks/pgsql), ObsDisk (/obs), BackupDisk (/backup) e LogDisk (/archive):

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

  3. Se hai configurato una risorsa BackupPlan per archiviare i backup localmente, recupera il nome del pod del repository di backup ed esegui df -h per visualizzare la capacità e l'utilizzo del 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

Monitora le metriche di archiviazione utilizzando Prometheus

AlloyDB Omni esporta le metriche di archiviazione e I/O del disco sul servizio al-INSTANCE_ID-DB_CLUSTER_NAME-monitoring-system (porta 9187). Per scoprire come estrarre ed eseguire query su queste metriche, consulta Monitora AlloyDB Omni. Per un elenco completo delle metriche disponibili, consulta Metriche di AlloyDB Omni.

Monitora le seguenti metriche del disco:

  • Utilizzo dello spazio di archiviazione e capacità: monitora le metriche alloydb_omni_node_storage_usage_per_disk_byte e alloydb_omni_node_storage_limit_per_disk_byte, che indicano l'utilizzo dello spazio di archiviazione utilizzato e la capacità totale in byte per ogni volume utilizzando l'etichetta disk (ad esempio, DataDisk, ObsDisk o BackupDisk). Configura avvisi quando l'utilizzo del disco raggiunge l'80% e il 90% della capacità, in modo da poter espandere i volumi prima che lo spazio si esaurisca.
  • Throughput e operazioni di I/O del disco: monitora le metriche alloydb_omni_node_storage_read_bytes_count_total e alloydb_omni_node_storage_write_bytes_count_total per il throughput di lettura e scrittura del disco e le metriche alloydb_omni_node_storage_read_ops_count_total e alloydb_omni_node_storage_write_ops_count_total per le operazioni di I/O di lettura e scrittura.

Ridimensionare i PVC per un DBCluster esistente

Se hai già creato una risorsa DBCluster seguendo la procedura descritta in Creare un cluster di database, il tuo manifest iniziale probabilmente specificava solo il volume DataDisk (ad esempio 10Gi), mentre l'operatore AlloyDB Omni ha eseguito il provisioning dei volumi ObsDisk (2Gi), BackupDisk (10Gi) e LogDisk (2Gi) con le dimensioni predefinite. Puoi espandere uno qualsiasi di questi PVC aggiornando il manifest DBCluster.

Prima di ridimensionare un PVC, esamina i seguenti requisiti e limitazioni:

  • Espansione del volume StorageClass: puoi aumentare le dimensioni di un disco solo se la risorsa Kubernetes StorageClass imposta allowVolumeExpansion: true. Per saperne di più, consulta Espansione delle rivendicazioni di volumi permanenti.
  • Nessuna riduzione o modifica di StorageClass: non puoi ridurre le dimensioni di un disco e non puoi modificare il campo storageClass di una PVC esistente dopo il provisioning.
  • Ridimensionamento dei dischi di dimensioni predefinite: per espandere un disco che hai omesso in precedenza dal manifest (ad esempio il volume ObsDisk o il volume BackupRepoDisk), aggiungi una voce per quel disco al campo spec.primarySpec.resources.disks con un campo size più grande della sua capacità predefinita attuale. Mantieni sempre DataDisk e qualsiasi altra voce del disco esistente nell'elenco disks quando aggiorni il manifest.
  • Comportamento di riavvio del pod: quando modifichi il campo resources.disks, l'operatore AlloyDB Omni aggiorna la PVC sottostante e riavvia il pod dell'istanza del database per applicare la nuova specifica delle risorse. Esegui l'espansione dello spazio di archiviazione durante un periodo di manutenzione pianificato o configura l'alta affidabilità per ridurre al minimo i tempi di inattività.

Per esaminare e ridimensionare i PVC per il tuo DBCluster:

  1. Elenca i PVC nello spazio dei nomi del cluster di database per verificarne le capacità attuali e la risorsa StorageClass:

    kubectl get pvc -n NAMESPACE

    Sostituisci NAMESPACE con lo spazio dei nomi in cui hai eseguito il deployment di DBCluster (ad esempio, default).

    L'output è simile al seguente per un cluster denominato 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. Verifica che la risorsa StorageClass utilizzata dai tuoi PVC supporti l'espansione del volume:

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

    Sostituisci STORAGE_CLASS_NAME con il nome della classe di archiviazione della colonna STORAGECLASS dell'output precedente (ad esempio, standard-rwo). Verifica che il comando restituisca true.

  3. Aggiorna il campo spec.primarySpec.resources.disks nel manifest DBCluster per aumentare il valore size del volume DataDisk e aggiungi i dischi di dimensioni predefinite che devi espandere (ad esempio il volume ObsDisk o il volume BackupRepoDisk).

    Il seguente manifest di esempio espande il volume DataDisk a 400Gi, espande il volume ObsDisk dal valore predefinito 2Gi a 10Gi e configura il volume BackupRepoDisk a 600Gi per un workload di 200 GiB:

    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

    Sostituisci quanto segue:

    • DB_CLUSTER_NAME: il nome del cluster di database, ad esempio my-db-cluster.
    • NAMESPACE: lo spazio dei nomi del cluster di database.
    • STORAGE_CLASS_NAME: il nome della risorsa Kubernetes StorageClass utilizzata dai volumi permanenti, ad esempio standard-rwo. Se hai omesso il campo storageClass quando hai creato il cluster, puoi continuare a ometterlo in modo che l'operatore utilizzi il StorageClass predefinito del cluster.

  4. Applica il manifest DBCluster aggiornato:

    kubectl apply -f DB_CLUSTER_MANIFEST.yaml

    Sostituisci DB_CLUSTER_MANIFEST con il percorso del file manifest DBCluster.

  5. Verifica che i PVC e lo stato di DBCluster riflettano le dimensioni espanse:

    kubectl get pvc -n NAMESPACE

    Puoi anche esaminare il campo di stato allocatedResources.disks nella risorsa DBCluster:

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

    Sostituisci quanto segue:

    • NAMESPACE: lo spazio dei nomi del cluster di database.
    • DB_CLUSTER_NAME: il nome del cluster di database.

Per saperne di più sul ridimensionamento delle risorse di calcolo e archiviazione, consulta Ridimensionare il cluster di database basato su Kubernetes.

Passaggi successivi