Tamanhos de armazenamento e PVC do plano

Selecione uma versão da documentação:

Para evitar tempo de inatividade do banco de dados e perda de dados causados por falta de armazenamento, planeje adequadamente as capacidades de armazenamento e de reivindicação de volume permanente (PVC) para seus clusters de banco de dados do AlloyDB Omni (DBCluster). Use estas recomendações de dimensionamento para configurar seus volumes ao implantar no Kubernetes usando o operador do AlloyDB Omni no Kubernetes.

Ao criar um DBCluster recurso personalizado, o operador do AlloyDB Omni provisiona PVCs do Kubernetes com base nos discos definidos nos seguintes campos:

  • Instâncias principais e em espera de alta disponibilidade (HA): configuradas no campo spec.primarySpec.resources.disks do recurso personalizado DBCluster. Se você ativar a alta disponibilidade configurando o campo spec.availability.numberOfStandbys, cada réplica em espera usará a mesma configuração de disco da instância principal.
  • Instâncias do pool de leitura: configuradas em spec.resources.disks em cada DBInstance recurso personalizado em que instanceType está definido como ReadPool. Se você omitir a seção spec.resources em um recurso DBInstance, a instância do pool de leitura vai herdar a configuração de disco do campo spec.primarySpec.resources do recurso DBCluster principal.

Volumes de PVC compatíveis

O operador do AlloyDB Omni não provisiona todos os volumes de PVC ao mesmo tempo:

  • Sempre provisionado: o operador sempre provisiona DataDisk, ObsDisk, BackupDisk e LogDisk para todos os pods de instância de banco de dados primários, de espera de HA e de pool de leitura. É preciso especificar explicitamente DataDisk e o tamanho dele no manifesto. Especificar ObsDisk, BackupDisk e LogDisk no manifesto é opcional. Se você omitir esses campos, como mostrado no manifesto de instalação básico, o operador ainda vai provisionar esses PVCs usando os tamanhos padrão.
  • Não provisionado por padrão: o operador não provisiona o volume BackupRepoDisk quando você cria um recurso DBCluster independente ou quando armazena backups no Cloud Storage ou no Amazon S3. Ele provisiona o pod do repositório de backup e o PVC BackupRepoDisk somente quando você cria um recurso BackupPlan para armazenar backups localmente no cluster do Kubernetes (ou seja, um recurso BackupPlan sem um campo backupLocation remoto).

A tabela a seguir descreve os volumes permanentes que o operador do AlloyDB Omni gerencia:

Nome do disco Caminho de montagem Pod de destino Configuração do manifesto Comportamento de provisionamento Finalidade
DataDisk /mnt/disks/pgsql Pod do banco de dados Obrigatório Sempre provisionado para cada pod de banco de dados. Armazena o diretório do cluster de banco de dados PostgreSQL (PGDATA), tabelas, índices, arquivos temporários e segmentos ativos do registro prévio de escrita (WAL).
ObsDisk /obs Pod do banco de dados Opcional (padrão: 2Gi) Sempre provisionado para cada pod de banco de dados. Armazena dados de observabilidade, incluindo registros do servidor PostgreSQL (postgresql.log), registros do pgAudit (postgresql.audit), registros internos (postgresql.internal) e arquivos de registros .gz rotacionados.
BackupDisk /backup Pod do banco de dados Opcional (padrão: 10Gi) Sempre provisionado para cada pod de banco de dados. Fornece um diretório de preparo local para operações de backup no pod do banco de dados.
LogDisk /archive Pod do banco de dados Opcional (padrão: 2Gi) Sempre provisionado para cada pod de banco de dados. Fornece um destino de arquivo WAL dedicado para sidecars de backup personalizados ou de terceiros. Se você não usar um sidecar personalizado de arquivamento de WAL, omita esse disco do manifesto e deixe-o no tamanho padrão 2Gi.
BackupRepoDisk /backup Pod do repositório de backup Opcional (padrão: 10Gi) Não provisionado por padrão. Provisionado somente quando um recurso BackupPlan armazena backups localmente. Não é provisionado quando nenhum BackupPlan está configurado ou quando os backups usam o Cloud Storage ou o Amazon S3. Fornece um volume dedicado que armazena backups físicos de banco de dados, backups incrementais e backups diferenciais e arquivos WAL arquivados quando você usa backups de armazenamento local.

Recomendações de dimensionamento de PVC

Use as diretrizes a seguir para dimensionar cada volume de PVC com base na sua carga de trabalho, configuração de geração de registros e estratégia de backup.

DataDisk volume para armazenamento do banco de dados principal

O operador do AlloyDB Omni sempre provisiona o volume DataDisk para cada pod de banco de dados, e você precisa especificar explicitamente o tamanho dele no manifesto. Para estimar a capacidade mínima de DataDisk, use a seguinte fórmula:

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

Ao dimensionar o volume do DataDisk, considere os seguintes fatores:

  • Sobrecarga de índice: os índices do PostgreSQL e as tabelas de catálogo do sistema geralmente exigem de 20% a 50% de armazenamento extra além dos dados brutos da tabela.
  • Margem de WAL ativa: transações de gravação de alta taxa de transferência acumulam arquivos WAL no diretório pg_wal até que os pontos de verificação sejam concluídos. Alocar armazenamento suficiente para acomodar o parâmetro de banco de dados max_wal_size configurado (normalmente, de vários gigabytes a dezenas de gigabytes, dependendo da sua carga de trabalho). Para conferir ou modificar parâmetros do banco de dados, como max_wal_size, consulte Configurar parâmetros do banco de dados.
  • Arquivos temporários e operações de vacuum: a classificação de consultas, a criação de índices, a reindexação e as operações de autovacuum exigem mais espaço em disco temporário.
  • Regra geral de dimensionamento: aloque de 1,5 a 2 vezes o tamanho do banco de dados bruto, incluindo pelo menos um buffer de segurança de 30%.

Volume de ObsDisk para registros de diagnóstico e auditoria

O operador do AlloyDB Omni sempre provisiona o volume ObsDisk para cada pod de banco de dados (com o tamanho padrão 2Gi se você o omitir do manifesto). Se o volume ObsDisk ficar cheio, o PostgreSQL não poderá gravar novas entradas de registro, e a rotação de registros poderá ser interrompida. Para informações sobre como configurar as opções de rotação e retenção de registros para o volume ObsDisk, consulte Configurar a rotação de registros.

Ao dimensionar o volume do ObsDisk, considere as seguintes diretrizes:

  • Registro padrão: um volume de 4 GiB a 10 GiB é suficiente para o registro operacional padrão nas configurações de rotação de registros padrão (limite de rotação de 200 MB e retenção de sete dias).
  • Registro de auditoria (pgAudit): quando você ativa o registro de auditoria com pgAudit, ele gera um volume de registros muito maior. Alocar de 20 GiB a 50 GiB ou mais, dependendo da taxa de consultas e do nível de detalhe das regras de auditoria.

Volume BackupRepoDisk para repositório de backup local

Ao contrário dos discos do pod de banco de dados, o BackupRepoDisk não é provisionado por padrão. O operador do AlloyDB Omni provisiona o pod do repositório de backup e o PVC BackupRepoDisk somente quando você cria um recurso BackupPlan para armazenar backups localmente no cluster do Kubernetes sem um campo backupLocation remoto. Se você omitir esse disco do manifesto DBCluster, ele usará o tamanho padrão de 10Gi. Se você não configurar um recurso BackupPlan ou se o recurso BackupPlan usar o Cloud Storage com o tipo GCS ou o Amazon S3 com o tipo S3, o operador não vai provisionar BackupRepoDisk. Para mais informações sobre como configurar planos de backup e redimensionar o armazenamento de backup, consulte Fazer backup e restauração no Kubernetes e Redimensionar um disco de backup.

Quando você armazena backups localmente, o volume BackupRepoDisk armazena backups completos, diferenciais e incrementais compactados, além de arquivos WAL arquivados. O armazenamento total necessário depende do tamanho do banco de dados, da taxa diária de mudança de dados, da programação de backup definida no backupSchedules e do período de armazenamento definido pelo backupRetainDays:

  • Compactação de backup: os backups compactados geralmente usam de 37% a 38% do tamanho do banco de dados não compactado, o que representa uma redução de 62% a 63%. Por exemplo, um banco de dados de 50 GiB é compactado para aproximadamente 18,5 GiB.
  • Programação e retenção de backup: combinar backups completos semanais com backups incrementais ou diferenciais diários exige muito menos armazenamento do que fazer backups completos diários.

A tabela a seguir mostra o uso máximo de armazenamento comparado e o tamanho recomendado de BackupRepoDisk (incluindo um buffer de 20%) em diferentes programações de backup para um banco de dados de 100 GiB com uma taxa de mudança de dados diária de 10% e o período de armazenamento padrão de 14 dias (backupRetainDays: 14):

Programação de backup (backupSchedules) Pico de backups completos Backups diferenciais Backups incrementais Arquivos WAL arquivados Pico de armazenamento usado Tamanho recomendado de BackupRepoDisk (+ buffer de 20%)
Completo semanal + incremental diário 148,0 GiB 0 GiB 66,6 GiB 155,4 GiB 370,0 GiB 444 GiB (~4,4 vezes o tamanho do banco de dados)
Semanal completo + diferencial de meados da semana + incremental diário 148,0 GiB 22,2 GiB 44,4 GiB 155,4 GiB 370,0 GiB 444 GiB (~4,4 vezes o tamanho do banco de dados)
Total semanal + diferencial diário 148,0 GiB 155,4 GiB 0 GiB 155,4 GiB 458,8 GiB 551 GiB (~5,5 vezes o tamanho do banco de dados)
Diária completa (programação padrão) 592,0 GiB 0 GiB 0 GiB 111,0 GiB 703,0 GiB 844 GiB (~8,4 vezes o tamanho do banco de dados)

Volume BackupDisk para o preparo do backup do pod de banco de dados

O operador do AlloyDB Omni sempre provisiona o volume BackupDisk para cada pod de banco de dados com um tamanho padrão de 10 GiB (10Gi). O AlloyDB Omni usa o volume BackupDisk como um diretório de preparação local durante as operações de backup. Como o tamanho padrão de 10 GiB é suficiente para operações padrão, você pode omitir BackupDisk do manifesto DBCluster para usar o tamanho padrão.

Volume LogDisk para arquivamento personalizado de WAL

O operador do AlloyDB Omni sempre provisiona o volume LogDisk para cada pod de banco de dados com um tamanho padrão de 2 GiB (2Gi). Só é necessário especificar um tamanho personalizado para o volume LogDisk se você implantar um contêiner secundário personalizado ou de terceiros que arquiva arquivos WAL no diretório /archive. Para implantações padrão do operador do AlloyDB Omni que usam backups integrados, é possível omitir LogDisk do manifesto DBCluster e deixar o tamanho padrão 2Gi.

Referência de dimensionamento por tamanho do conjunto de dados

A tabela a seguir mostra os tamanhos recomendados de PVC para tamanhos comuns de conjuntos de dados brutos:

Tamanho dos dados brutos Tamanho recomendado do DataDisk Tamanho recomendado do ObsDisk Tamanho recomendado de BackupRepoDisk (provisionado apenas para backups locais) Tamanho recomendado do BackupDisk Tamanho recomendado do LogDisk
50 GiB 100 GiB 4 GiB (10 a 20 GiB com pgAudit) 150 GiB 10 GiB (padrão) 2 GiB (padrão)
200 GiB 400 GiB 10 GiB (20 a 50 GiB com pgAudit) 600 GiB 10 GiB (padrão) 2 GiB (padrão)
500 GiB 1.000 GiB (1 TiB) 15 GiB (30 a 60 GiB com pgAudit) 1.500 GiB (1,5 TiB) 10 GiB (padrão) 2 GiB (padrão)
1 TiB 2.000 GiB (2 TiB) 20 GiB (50 a 100 GiB com pgAudit) 3.000 GiB (3 TiB) 10 GiB (padrão) 2 GiB (padrão)

Monitorar o uso do disco e as métricas de E/S

É possível monitorar o uso do disco em tempo real diretamente nos pods do banco de dados e do repositório de backup usando kubectl ou coletando métricas do Prometheus exportadas pelo AlloyDB Omni.

Verifique o uso do disco usando kubectl

Para verificar o uso atual do espaço em disco dos volumes de PVC montados no pod do banco de dados e no pod do repositório de backup, execute os seguintes comandos:

  1. Consiga o nome do pod do banco de dados para seu recurso 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}')

    Substitua:

    • NAMESPACE: o namespace do Kubernetes em que o cluster de banco de dados está implantado.
    • DB_CLUSTER_NAME: o nome do cluster de banco de dados.

  2. Execute df -h no contêiner do banco de dados para conferir a capacidade e o uso dos volumes 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 você configurou um recurso BackupPlan para armazenar backups localmente, receba o nome do pod do repositório de backup e execute df -h para conferir a capacidade e o uso do 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

Monitorar métricas de armazenamento usando o Prometheus

O AlloyDB Omni exporta métricas de armazenamento e E/S de disco no serviço al-INSTANCE_ID-DB_CLUSTER_NAME-monitoring-system (porta 9187). Para saber como extrair e consultar essas métricas, consulte Monitorar o AlloyDB Omni. Para uma lista completa de métricas disponíveis, consulte Métricas do AlloyDB Omni.

Monitore as seguintes métricas de disco:

  • Uso e capacidade de armazenamento: monitore as métricas alloydb_omni_node_storage_usage_per_disk_byte e alloydb_omni_node_storage_limit_per_disk_byte, que informam o uso do armazenamento e a capacidade total em bytes de cada volume usando o rótulo disk (por exemplo, DataDisk, ObsDisk ou BackupDisk). Configure alertas quando o uso do disco atingir 80% e 90% da capacidade para que você possa expandir os volumes antes que eles fiquem sem espaço.
  • Taxa de transferência de disco e operações de E/S: monitore as métricas alloydb_omni_node_storage_read_bytes_count_total e alloydb_omni_node_storage_write_bytes_count_total para taxa de transferência de leitura e gravação de disco e as métricas alloydb_omni_node_storage_read_ops_count_total e alloydb_omni_node_storage_write_ops_count_total para operações de E/S de leitura e gravação.

Redimensionar PVCs para um DBCluster atual

Se você já criou um recurso DBCluster seguindo Criar um cluster de banco de dados, seu manifesto inicial provavelmente especificou apenas o volume DataDisk (por exemplo, 10Gi), enquanto o operador do AlloyDB Omni provisionou os volumes ObsDisk (2Gi), BackupDisk (10Gi) e LogDisk (2Gi) com os tamanhos padrão. É possível expandir qualquer uma dessas PVCs atualizando o manifesto DBCluster.

Antes de redimensionar uma PVC, confira os requisitos e as limitações a seguir:

  • Expansão de volume da StorageClass: só é possível aumentar o tamanho de um disco se o recurso StorageClass do Kubernetes definir allowVolumeExpansion: true. Para mais informações, consulte Como expandir solicitações de volumes permanentes.
  • Sem redução ou mudanças de StorageClass: não é possível diminuir o tamanho de um disco nem mudar o campo storageClass de uma PVC depois que ela é provisionada.
  • Redimensionamento de discos de tamanho padrão: para expandir um disco que você omitiu anteriormente do manifesto (como o volume ObsDisk ou BackupRepoDisk), adicione uma entrada para esse disco ao campo spec.primarySpec.resources.disks com um campo size maior que a capacidade padrão atual. Sempre mantenha DataDisk e todas as outras entradas de disco na lista disks ao atualizar o manifesto.
  • Comportamento de reinicialização do pod: quando você modifica o campo resources.disks, o operador do AlloyDB Omni atualiza o PVC subjacente e reinicia o pod da instância de banco de dados para aplicar a nova especificação de recurso. Faça a expansão do armazenamento durante uma janela de manutenção planejada ou configure a alta disponibilidade para minimizar o tempo de inatividade.

Para inspecionar e redimensionar os PVCs do seu DBCluster, siga estas etapas:

  1. Liste os PVCs no namespace do cluster de banco de dados para verificar as capacidades atuais e o recurso StorageClass:

    kubectl get pvc -n NAMESPACE

    Substitua NAMESPACE pelo namespace em que você implantou o DBCluster (por exemplo, default).

    A saída será semelhante a esta para um cluster chamado 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. Verifique se o recurso StorageClass usado pelas PVCs é compatível com a expansão de volume:

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

    Substitua STORAGE_CLASS_NAME pelo nome da classe de armazenamento da coluna STORAGECLASS da saída anterior (por exemplo, standard-rwo). Confirme se o comando retorna true.

  3. Atualize o campo spec.primarySpec.resources.disks no manifesto DBCluster para aumentar o valor size do volume DataDisk e adicione os discos de tamanho padrão que você precisa expandir, como o volume ObsDisk ou BackupRepoDisk.

    O exemplo de manifesto a seguir expande o volume DataDisk para 400Gi, o volume ObsDisk do padrão 2Gi para 10Gi e configura o volume BackupRepoDisk em 600Gi para uma carga de trabalho de 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

    Substitua:

    • DB_CLUSTER_NAME: o nome do cluster de banco de dados, por exemplo, my-db-cluster.
    • NAMESPACE: o namespace do cluster de banco de dados.
    • STORAGE_CLASS_NAME: o nome do recurso StorageClass do Kubernetes usado pelos seus volumes permanentes. Por exemplo, standard-rwo. Se você omitiu o campo storageClass ao criar o cluster, continue omitindo para que o operador use o StorageClass padrão do cluster.

  4. Aplique o manifesto DBCluster atualizado:

    kubectl apply -f DB_CLUSTER_MANIFEST.yaml

    Substitua DB_CLUSTER_MANIFEST pelo caminho do arquivo de manifesto DBCluster.

  5. Verifique se os PVCs e o status DBCluster refletem os tamanhos expandidos:

    kubectl get pvc -n NAMESPACE

    Também é possível inspecionar o campo de status allocatedResources.disks no recurso DBCluster:

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

    Substitua:

    • NAMESPACE: o namespace do cluster de banco de dados.
    • DB_CLUSTER_NAME: o nome do cluster de banco de dados.

Para mais informações sobre como redimensionar recursos de computação e armazenamento, consulte Redimensionar o cluster de banco de dados baseado no Kubernetes.

A seguir