Planifica el almacenamiento y los tamaños de PVC

Selecciona una versión de la documentación:

Para evitar el tiempo de inactividad de la base de datos y la pérdida de datos causados por el agotamiento del almacenamiento, debes planificar de forma adecuada las capacidades de almacenamiento y de Persistent Volume Claim (PVC) para tus clústeres de bases de datos de AlloyDB Omni (DBCluster). Usa estas recomendaciones de tamaño para configurar tus volúmenes cuando realices la implementación en Kubernetes con el operador de Kubernetes de AlloyDB Omni.

Cuando creas un recurso personalizado DBCluster, el operador de AlloyDB Omni aprovisiona PVC de Kubernetes según los discos que definas en los siguientes campos:

  • Instancias principales y en espera de alta disponibilidad (HA): Se configuran en el campo spec.primarySpec.resources.disks de tu recurso personalizado DBCluster. Si habilitas la alta disponibilidad configurando el campo spec.availability.numberOfStandbys, cada réplica en espera usará la misma configuración de disco que la instancia principal.
  • Instancias de grupo de lectura: Se configuran en spec.resources.disks en cada DBInstance recurso personalizado en el que instanceType se establece en ReadPool. Si omites la sección spec.resources en un recurso DBInstance, la instancia del grupo de lectura hereda la configuración del disco del campo spec.primarySpec.resources del recurso DBCluster principal.

Volúmenes de PVC admitidos

El operador de AlloyDB Omni no aprovisiona todos los volúmenes de PVC al mismo tiempo:

  • Siempre aprovisionado: El operador siempre aprovisiona DataDisk, ObsDisk, BackupDisk y LogDisk para todos los Pods de instancias de bases de datos principales, en espera de alta disponibilidad y de grupos de lectura. Debes especificar de forma explícita DataDisk y su tamaño en el manifiesto. Especificar ObsDisk, BackupDisk y LogDisk en tu manifiesto es opcional. Si los omites, como se muestra en el manifiesto de instalación básico, el operador aún aprovisiona estos PVC con sus tamaños predeterminados.
  • No se aprovisiona de forma predeterminada: El operador no aprovisiona el volumen BackupRepoDisk cuando creas un recurso DBCluster independiente o cuando almacenas copias de seguridad en Cloud Storage o Amazon S3. Aprovisiona el Pod del repositorio de copias de seguridad y su PVC BackupRepoDisk solo cuando crea un recurso BackupPlan para almacenar copias de seguridad de forma local en su clúster de Kubernetes (es decir, un recurso BackupPlan sin un campo backupLocation remoto).

En la siguiente tabla, se describen los volúmenes persistentes que administra el operador de AlloyDB Omni:

Nombre del disco Ruta de activación Pod objetivo Configuración del manifiesto Comportamiento del aprovisionamiento Objetivo
DataDisk /mnt/disks/pgsql Pod de base de datos Obligatorio Siempre se aprovisiona para cada Pod de base de datos. Almacena el directorio del clúster de la base de datos de PostgreSQL (PGDATA), las tablas, los índices, los archivos temporales y los segmentos activos del registro de escritura anticipada (WAL).
ObsDisk /obs Pod de base de datos Opcional (valor predeterminado: 2Gi) Siempre se aprovisiona para cada Pod de base de datos. Almacena datos de observabilidad, incluidos los registros del servidor de PostgreSQL (postgresql.log), los registros de pgAudit (postgresql.audit), los registros internos (postgresql.internal) y los archivos de registros .gz rotados.
BackupDisk /backup Pod de base de datos Opcional (valor predeterminado: 10Gi) Siempre se aprovisiona para cada Pod de base de datos. Proporciona un directorio de preparación local para las operaciones de copia de seguridad en el Pod de la base de datos.
LogDisk /archive Pod de base de datos Opcional (valor predeterminado: 2Gi) Siempre se aprovisiona para cada Pod de base de datos. Proporciona un destino de archivo WAL dedicado para los sidecars de copias de seguridad personalizados o de terceros. Si no usas un sidecar de archivado de WAL personalizado, puedes omitir este disco de tu manifiesto y dejarlo en su tamaño predeterminado de 2Gi.
BackupRepoDisk /backup Pod del repositorio de copias de seguridad Opcional (valor predeterminado: 10Gi) No se aprovisiona de forma predeterminada. Se aprovisiona solo cuando un recurso de BackupPlan almacena copias de seguridad de forma local (no se aprovisiona cuando no se configura ningún BackupPlan o cuando las copias de seguridad usan Cloud Storage o Amazon S3). Proporciona un volumen dedicado que almacena copias de seguridad físicas de la base de datos, copias de seguridad incrementales y copias de seguridad diferenciales, y archivos WAL archivados cuando usas copias de seguridad de almacenamiento local.

Recomendaciones de tamaño de PVC

Usa los siguientes lineamientos para determinar el tamaño de cada volumen de PVC según tu carga de trabajo, la configuración de registro y la estrategia de copias de seguridad.

Volumen de DataDisk para el almacenamiento de la base de datos principal

El operador de AlloyDB Omni siempre aprovisiona el volumen DataDisk para cada Pod de base de datos, y debes especificar su tamaño de forma explícita en tu manifiesto. Para estimar la capacidad mínima de DataDisk, usa la siguiente fórmula:

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

Cuando determines el tamaño del volumen de DataDisk, ten en cuenta los siguientes factores:

  • Sobrecarga de índices: Los índices de PostgreSQL y las tablas del catálogo del sistema suelen requerir entre un 20% y un 50% adicional de almacenamiento más allá de los datos sin procesar de la tabla.
  • Espacio libre de WAL activo: Las transacciones de escritura de alto rendimiento acumulan archivos WAL en el directorio pg_wal hasta que se completan los puntos de control. Asigna suficiente almacenamiento para admitir el parámetro de base de datos max_wal_size configurado (por lo general, de varios gigabytes a decenas de gigabytes, según tu carga de trabajo). Para ver o modificar parámetros de la base de datos, como max_wal_size, consulta Configura parámetros de la base de datos.
  • Archivos temporales y operaciones de limpieza: Las operaciones de clasificación de consultas, creación de índices, reindexación y limpieza automática requieren espacio adicional en el disco temporal.
  • Regla general de dimensionamiento: Asigna de 1.5 a 2 veces el tamaño de tu base de datos sin procesar, incluido un búfer de seguridad de al menos el 30%.

Volumen de ObsDisk para los registros de diagnóstico y auditoría

El operador de AlloyDB Omni siempre aprovisiona el volumen ObsDisk para cada Pod de base de datos (con el tamaño predeterminado 2Gi si lo omites de tu manifiesto). Si el volumen de ObsDisk se llena, PostgreSQL no puede escribir entradas de registro nuevas y la rotación del registro puede detenerse. Para obtener información sobre cómo configurar la rotación y la retención de registros para el volumen ObsDisk, consulta Configura la rotación de registros.

Cuando determines el tamaño del volumen de ObsDisk, ten en cuenta los siguientes lineamientos:

  • Registro estándar: Un volumen de 4 a 10 GiB es suficiente para el registro operativo estándar con la configuración predeterminada de rotación del registro (umbral de rotación de 200 MB y retención de 7 días).
  • Registros de auditoría (pgAudit): Cuando habilitas los registros de auditoría con pgAudit, se genera un volumen de registros significativamente mayor. Asigna entre 20 y 50 GiB, o más, según la tasa de consultas y el nivel de detalle de las reglas de auditoría.

Volumen BackupRepoDisk para el repositorio de copias de seguridad locales

A diferencia de los discos de Pod de la base de datos, BackupRepoDisk no se aprovisiona de forma predeterminada. El operador de AlloyDB Omni aprovisiona el Pod del repositorio de copias de seguridad y su PVC BackupRepoDisk solo cuando creas un recurso BackupPlan para almacenar copias de seguridad de forma local en tu clúster de Kubernetes sin un campo backupLocation remoto. Si omites este disco de tu manifiesto DBCluster, se usará el tamaño predeterminado de 10Gi. Si no configuras un recurso BackupPlan o si tu recurso BackupPlan usa Cloud Storage con el tipo GCS o Amazon S3 con el tipo S3, el operador no aprovisiona BackupRepoDisk. Para obtener más información sobre cómo configurar planes de copias de seguridad y cambiar el tamaño del almacenamiento de copias de seguridad, consulta Copia de seguridad y restablecimiento en Kubernetes y Cómo cambiar el tamaño de un disco de copia de seguridad.

Cuando almacenas copias de seguridad de forma local, el volumen BackupRepoDisk almacena copias de seguridad completas, diferenciales e incrementales comprimidas junto con archivos WAL archivados. El almacenamiento total requerido depende del tamaño de la base de datos, la tasa de cambio de datos diaria, el programa de copias de seguridad definido en backupSchedules y el período de retención establecido por backupRetainDays:

  • Compresión de copias de seguridad: Las copias de seguridad comprimidas suelen usar entre el 37% y el 38% del tamaño de la base de datos sin comprimir, lo que representa una reducción del tamaño de entre el 62% y el 63%. Por ejemplo, una base de datos de 50 GiB se comprime a aproximadamente 18.5 GiB.
  • Programa y retención de copias de seguridad: Combinar copias de seguridad completas semanales con copias de seguridad incrementales o diferenciales diarias requiere mucho menos almacenamiento que realizar copias de seguridad completas diarias.

En la siguiente tabla, se muestra el uso máximo de almacenamiento comparativo y el tamaño BackupRepoDisk recomendado (incluido un búfer del 20%) en diferentes programas de copias de seguridad para una base de datos de 100 GiB con una tasa de cambio de datos diaria del 10% y el período de retención predeterminado de 14 días (backupRetainDays: 14):

Programación de la copia de seguridad (backupSchedules) Copias de seguridad completas máximas Copias de seguridad diferenciales Copias de seguridad incrementales Archivos WAL archivados Almacenamiento máximo utilizado Tamaño recomendado de BackupRepoDisk (búfer del 20%)
Copia de seguridad completa semanal y copias de seguridad incrementales diarias 148.0 GiB 0 GiB 66.6 GiB 155.4 GiB 370.0 GiB 444 GiB (aproximadamente 4.4 veces el tamaño de la base de datos)
Diferencial semanal completo y de mitad de semana, y datos incrementales diarios 148.0 GiB 22.2 GiB 44.4 GiB 155.4 GiB 370.0 GiB 444 GiB (aproximadamente 4.4 veces el tamaño de la base de datos)
Copia de seguridad completa semanal y diferencial diaria 148.0 GiB 155.4 GiB 0 GiB 155.4 GiB 458.8 GiB 551 GiB (aproximadamente 5.5 veces el tamaño de la base de datos)
Solo copia de seguridad completa diaria (programación predeterminada) 592.0 GiB 0 GiB 0 GiB 111.0 GiB 703.0 GiB 844 GiB (aproximadamente 8.4 veces el tamaño de la base de datos)

Volumen BackupDisk para la etapa intermedia de la copia de seguridad del Pod de la base de datos

El operador de AlloyDB Omni siempre aprovisiona el volumen BackupDisk para cada Pod de base de datos con un tamaño predeterminado de 10 GiB (10Gi). AlloyDB Omni usa el volumen BackupDisk como un directorio de etapa de pruebas local durante las operaciones de copia de seguridad. Dado que el tamaño predeterminado de 10 GiB es suficiente para las operaciones estándar, puedes omitir BackupDisk de tu manifiesto de DBCluster para usar el tamaño predeterminado.

Volumen de LogDisk para el archivado de WAL personalizado

El operador de AlloyDB Omni siempre aprovisiona el volumen LogDisk para cada Pod de base de datos con un tamaño predeterminado de 2 GiB (2Gi). Solo debes especificar un tamaño personalizado para el volumen LogDisk si implementas un contenedor secundario personalizado o de terceros que archiva archivos WAL en el directorio /archive. En el caso de las implementaciones estándar del operador de AlloyDB Omni que usan copias de seguridad integradas, puedes omitir LogDisk de tu manifiesto de DBCluster y dejarlo en su tamaño predeterminado de 2Gi.

Referencia de tamaño por tamaño del conjunto de datos

En la siguiente tabla, se proporcionan los tamaños de PVC recomendados para los tamaños de conjuntos de datos sin procesar comunes:

Tamaño de los datos sin procesar Tamaño recomendado de DataDisk Tamaño recomendado de ObsDisk Tamaño recomendado de BackupRepoDisk (solo se aprovisiona para copias de seguridad locales) Tamaño recomendado de BackupDisk Tamaño recomendado de LogDisk
50 GiB 100 GiB 4 GiB (de 10 a 20 GiB con pgAudit) 150 GiB 10 GiB (predeterminado) 2 GiB (predeterminado)
200 GiB 400 GiB 10 GiB (de 20 a 50 GiB con pgAudit) 600 GiB 10 GiB (predeterminado) 2 GiB (predeterminado)
500 GiB 1,000 GiB (1 TiB) 15 GiB (de 30 a 60 GiB con pgAudit) 1,500 GiB (1.5 TiB) 10 GiB (predeterminado) 2 GiB (predeterminado)
1 TiB 2,000 GiB (2 TiB) 20 GiB (de 50 a 100 GiB con pgAudit) 3,000 GiB (3 TiB) 10 GiB (predeterminado) 2 GiB (predeterminado)

Supervisa el uso del disco y las métricas de E/S

Puedes supervisar el uso del disco en tiempo real directamente dentro de los Pods de tu base de datos y repositorio de copias de seguridad con kubectl o recopilando las métricas de Prometheus que exporta AlloyDB Omni.

Verifica el uso del disco con kubectl

Para verificar el uso actual del espacio en el disco de los volúmenes de PVC montados dentro del Pod de la base de datos y el Pod del repositorio de copias de seguridad, ejecuta los siguientes comandos:

  1. Obtén el nombre del Pod de la base de datos para tu 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}')

    Reemplaza lo siguiente:

    • NAMESPACE: Es el espacio de nombres de Kubernetes en el que se implementa tu clúster de base de datos.
    • DB_CLUSTER_NAME: Es el nombre de tu clúster de base de datos.

  2. Ejecuta df -h dentro del contenedor de la base de datos para ver la capacidad y el uso de los volúmenes DataDisk (/mnt/disks/pgsql), ObsDisk (/obs), BackupDisk (/backup) y LogDisk (/archive):

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

  3. Si configuraste un recurso BackupPlan para almacenar copias de seguridad de forma local, obtén el nombre del Pod del repositorio de copias de seguridad y ejecuta df -h para ver la capacidad y el uso del volumen 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

Supervisa las métricas de almacenamiento con Prometheus

AlloyDB Omni exporta métricas de almacenamiento y de E/S de disco en el servicio al-INSTANCE_ID-DB_CLUSTER_NAME-monitoring-system (puerto 9187). Para obtener información sobre cómo recuperar y consultar estas métricas, consulta Supervisa AlloyDB Omni. Para obtener una lista completa de las métricas disponibles, consulta Métricas de AlloyDB Omni.

Supervisa las siguientes métricas de disco:

  • Uso y capacidad de almacenamiento: Supervisa las métricas alloydb_omni_node_storage_usage_per_disk_byte y alloydb_omni_node_storage_limit_per_disk_byte, que registran el uso del almacenamiento y la capacidad total en bytes para cada volumen con la etiqueta disk (por ejemplo, DataDisk, ObsDisk o BackupDisk). Configura alertas cuando el uso del disco alcance el 80% y el 90% de la capacidad para que puedas expandir los volúmenes antes de que se queden sin espacio.
  • Operaciones de E/S y capacidad de procesamiento del disco: Supervisa las métricas alloydb_omni_node_storage_read_bytes_count_total y alloydb_omni_node_storage_write_bytes_count_total para la capacidad de procesamiento de lectura y escritura del disco, y las métricas alloydb_omni_node_storage_read_ops_count_total y alloydb_omni_node_storage_write_ops_count_total para las operaciones de E/S de lectura y escritura.

Cómo cambiar el tamaño de los PVC para un DBCluster existente

Si ya creaste un recurso DBCluster siguiendo los pasos de Crea un clúster de base de datos, es probable que tu manifiesto inicial solo haya especificado el volumen DataDisk (por ejemplo, 10Gi), mientras que el operador de AlloyDB Omni aprovisionó los volúmenes ObsDisk (2Gi), BackupDisk (10Gi) y LogDisk (2Gi) con sus tamaños predeterminados. Puedes expandir cualquiera de estos PVC actualizando tu manifiesto de DBCluster.

Antes de cambiar el tamaño de un PVC, revisa los siguientes requisitos y limitaciones:

  • Expansión de volúmenes de StorageClass: Solo puedes aumentar el tamaño de un disco si su recurso StorageClass de Kubernetes establece allowVolumeExpansion: true. Para obtener más información, consulta Expande las reclamaciones de volúmenes persistentes.
  • Sin reducción ni cambios en StorageClass: No puedes disminuir el tamaño de un disco ni cambiar el campo storageClass de un PVC existente después de que se aprovisiona.
  • Cambio de tamaño de discos predeterminados: Para expandir un disco que omitiste anteriormente en tu manifiesto (como el volumen ObsDisk o el volumen BackupRepoDisk), agrega una entrada para ese disco al campo spec.primarySpec.resources.disks con un campo size más grande que su capacidad predeterminada actual. Siempre conserva DataDisk y cualquier otra entrada de disco existente en la lista disks cuando actualices el manifiesto.
  • Comportamiento de reinicio del Pod: Cuando modificas el campo resources.disks, el operador de AlloyDB Omni actualiza el PVC subyacente y reinicia el Pod de la instancia de la base de datos para aplicar la nueva especificación de recursos. Realiza la expansión del almacenamiento durante un período de mantenimiento planificado o configura la alta disponibilidad para minimizar el tiempo de inactividad.

Para inspeccionar y cambiar el tamaño de los PVC de tu DBCluster, sigue estos pasos:

  1. Enumera los PVC en el espacio de nombres del clúster de la base de datos para verificar sus capacidades actuales y el recurso StorageClass:

    kubectl get pvc -n NAMESPACE

    Reemplaza NAMESPACE por el espacio de nombres en el que implementaste tu DBCluster (por ejemplo, default).

    El resultado es similar al siguiente para un clúster llamado 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 que el recurso StorageClass que usan tus PVC admita la expansión de volumen:

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

    Reemplaza STORAGE_CLASS_NAME por el nombre de la clase de almacenamiento de la columna STORAGECLASS del resultado anterior (por ejemplo, standard-rwo). Confirma que el comando devuelva true.

  3. Actualiza el campo spec.primarySpec.resources.disks en tu manifiesto DBCluster para aumentar el valor de size del volumen DataDisk y agrega los discos de tamaño predeterminado que necesites expandir (como el volumen ObsDisk o el volumen BackupRepoDisk).

    En el siguiente manifiesto de ejemplo, se expande el volumen DataDisk a 400Gi, se expande el volumen ObsDisk de su valor predeterminado 2Gi a 10Gi y se configura el volumen BackupRepoDisk en 600Gi para una carga de trabajo 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

    Reemplaza lo siguiente:

    • DB_CLUSTER_NAME: Es el nombre de tu clúster de base de datos, por ejemplo, my-db-cluster.
    • NAMESPACE: Es el espacio de nombres de tu clúster de base de datos.
    • STORAGE_CLASS_NAME: Es el nombre del recurso StorageClass de Kubernetes que usan tus volúmenes persistentes, por ejemplo, standard-rwo. Si omitiste el campo storageClass cuando creaste el clúster, puedes seguir omitiéndolo para que el operador use el StorageClass predeterminado del clúster.

  4. Aplica el manifiesto DBCluster actualizado:

    kubectl apply -f DB_CLUSTER_MANIFEST.yaml

    Reemplaza DB_CLUSTER_MANIFEST por la ruta de acceso a tu archivo de manifiesto DBCluster.

  5. Verifica que los PVC y el estado de DBCluster reflejen los tamaños expandidos:

    kubectl get pvc -n NAMESPACE

    También puedes inspeccionar el campo de estado allocatedResources.disks en el recurso DBCluster:

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

    Reemplaza lo siguiente:

    • NAMESPACE: Es el espacio de nombres de tu clúster de base de datos.
    • DB_CLUSTER_NAME: Es el nombre de tu clúster de base de datos.

Para obtener más información sobre cómo cambiar el tamaño de los recursos de procesamiento y almacenamiento, consulta Cambia el tamaño de tu clúster de bases de datos basado en Kubernetes.

¿Qué sigue?