Pools de almacenamiento
El problema y por qué es importante
Un clúster hiperconvergente no tiene un sistema de almacenamiento externo. Los discos están instalados en los mismos servidores que ejecutan las máquinas virtuales, y la capa de almacenamiento definido por software (SDS) combina estos discos en pools. Un pool proporciona redundancia, compresión y deduplicación, y almacena todos los datos del clúster.
Esto plantea una cuestión práctica para los administradores: un pool no es simplemente un "disco con un porcentaje de uso", sino un objeto con dos capacidades distintas, cuatro indicadores de estado y discos en todos los nodos del clúster. Sin comprender este modelo, es posible interpretar mal las cifras de la interfaz: se confunde la capacidad bruta con la capacidad disponible, y el tamaño total de los discos de las máquinas virtuales con el espacio utilizado.
Esta página explica el modelo. Para consultar los pools, consulte Cómo ver los pools del clúster; para trabajar con las propiedades de los datasets, consulte Cómo ver y cambiar las propiedades de un dataset.
Modelo y entidades
La capa de almacenamiento del clúster consta de tres niveles.
Discos y pool. Un pool es un grupo de discos combinados por ZFS. Está formado por discos de todos los nodos del clúster, no de un solo nodo, y su redundancia coincide con la redundancia del clúster. Por tanto, la pérdida de un disco es un evento a nivel de pool y no un evento que afecte a una sola máquina virtual. La distribución de los discos entre los pools, el nivel RAID-Z resultante y los discos compatibles se describen en la documentación de vStack OS: Discos de almacenamiento y pools.
Un pool tiene un nombre (name), un identificador persistente (guid) y el número del nodo que
lo sirve actualmente (node_id), es decir, el nodo a través del cual el clúster accede en ese momento al
pool. En la interfaz, es la columna Current node. Los discos del pool no
pertenecen a este nodo: están distribuidos entre todos los nodos, y cada disco del pool tiene su propio número de nodo.
Dataset. Una unidad dentro de un pool que contiene un disco de máquina virtual.
Se identifica por un nombre completo como pool-a/vm-100-disk-0 y por su propio GUID. Las propiedades
del dataset (compresión, deduplicación, tamaño del volumen, sumas de comprobación) se almacenan
por separado de las propiedades del pool y se cambian mediante métodos independientes.
| Entidad | Se identifica por | Pertenece a |
|---|---|---|
| Pool | guid, o el par nodeId (nodo que lo sirve) + name | clúster |
| Dataset | guid del disco | pool |
Cómo funciona
La capa de almacenamiento de vStack Center tiene dos vías independientes de acceso a los datos, y la diferencia entre ellas explica la mayoría de las respuestas inesperadas.
La primera vía es el mapa de pools de la base de datos de vStack Center. El despachador del clúster mantiene una instantánea del estado de todos los pools y responde a las solicitudes de inmediato, de forma síncrona. El mapa está disponible incluso cuando un nodo no responde, pero muestra el último estado registrado y no el estado actual.
La segunda vía es una consulta en vivo al nodo. La solicitud se retransmite al agente Storage del nodo
correspondiente. Primero llega la respuesta intermedia {"message": "relayed"} y después la respuesta final
mediante una devolución de llamada (callback) del agente. Los métodos en vivo proporcionan el conjunto completo de propiedades de ZFS, pero
un nodo que no responde implica un error en lugar de datos.
| Lo que necesita | Método | Modo | Origen de los datos |
|---|---|---|---|
| Todos los pools agrupados por nodo | pool-map | síncrono | base de datos de vStack Center |
| Todos los pools con capacidad y estado | pool-map-by-guid | síncrono | base de datos de vStack Center |
| Pools servidos por un nodo | pools-list | asíncrono | agente Storage del nodo |
| Propiedades completas de un pool | pools-get | asíncrono | agente Storage del nodo |
| Propiedades de un dataset | filesystems-get | asíncrono | agente Storage del nodo |
| Cambio de las propiedades de un dataset | filesystems-set | asíncrono | agente Storage del nodo |
Dos capacidades del pool
Siete campos describen la capacidad del pool, y confundirlos puede salir caro: la diferencia entre la capacidad bruta y la útil es la parte destinada a la redundancia.
| Campo | Qué muestra |
|---|---|
size_raw | Capacidad bruta: la suma de las capacidades de los discos del pool |
size | Capacidad útil: size_raw menos la parte destinada a la redundancia |
used | Espacio ocupado por los datos |
free | Capacidad útil restante: size menos used |
capacity_pct | Uso del pool en porcentaje |
provisioned | La suma de los tamaños solicitados de todos los datasets del pool |
provisioned_pct | La relación entre provisioned y la capacidad útil, en porcentaje |
Los datasets usan aprovisionamiento ligero (thin provisioning): el tamaño de volumen solicitado no se reserva de inmediato.
Por ello, provisioned se calcula a partir de los tamaños solicitados, mientras que used refleja el uso real, y la primera cifra
puede superar fácilmente a la segunda. Un valor de provisioned_pct superior a 100 indica
sobreasignación: los datasets del pool han solicitado más espacio que la capacidad útil del pool. Esto no es
una emergencia en sí, pero a partir de ese momento supervise el uso del pool mediante
capacity_pct y no mediante las cuotas restantes.
Cuatro indicadores de estado
| Campo | Significado |
|---|---|
health | Estado del pool; ONLINE para un pool en buen estado |
consuming | El clúster ha aceptado el pool para el almacenamiento activo de datos (1 / 0) |
scrubbing | Hay en curso una comprobación de integridad de los datos (1 / 0) |
resilvering | Se está restaurando la redundancia tras la sustitución de un disco (1 / 0) |
Junto con estos campos, el mapa devuelve lif: la dirección de red a través de la cual el pool es accesible.
El indicador consuming controla la escritura en el pool. El clúster no escribe datos en un pool con valor
0, y se rechazan las operaciones que requieren escritura: crear y
eliminar instantáneas de máquinas virtuales, revertir a una instantánea, enviar una copia de seguridad,
crear una máquina en un pool seleccionado explícitamente, clonar una máquina usando el pool de origen,
eliminar un disco de una máquina y las operaciones con datasets de copias de seguridad. Si una de estas operaciones
falla mientras la máquina virtual está en ejecución, compruebe el valor de consuming de su pool antes de
buscar la causa en la propia máquina. Añadir y ampliar un disco no comprueban este
indicador.
Quién puede ver qué
Los dos niveles tienen ámbitos de visibilidad distintos. Es una propiedad de los métodos, no una configuración.
Un pool es un objeto a nivel de clúster. Los métodos en vivo de pools (pools-list, pools-get) están disponibles
solo para el rol global Cluster master. Dos roles globales pueden leer el mapa de pools (pool-map):
Cluster master y Resource Viewer. Un administrador de VDC
(centro de datos virtual) no puede ver un pool: un pool no tiene un VDC propietario, y
un mismo pool contiene datasets de distintos VDC. La excepción es pool-map-by-guid: la documentación canónica de la API
no especifica el acceso a este método.
Un dataset es un objeto a nivel de VDC. La lectura de propiedades (filesystems-get) y su modificación
(filesystems-set) están disponibles para el rol de administrador de VDC y superiores, y solo dentro de su propio
VDC. La pertenencia del dataset se comprueba antes de contactar con el nodo, y un dataset que pertenece a otro VDC
se rechaza con el mismo código de error que uno inexistente: no se revela la existencia de un dataset
en otro VDC. Un rol global puede trabajar con datasets de cualquier VDC.
Limitaciones
A nivel de pool, la API del clúster es de solo lectura. El grupo de almacenamiento no tiene métodos para crear, eliminar ni
ampliar un pool: proporciona un mapa, una lista y propiedades. Una solicitud no puede eludir esto:
la única operación de escritura en la capa de almacenamiento a este nivel es el cambio de propiedades
de un dataset mediante filesystems-set.
Los métodos en vivo de pools pasan por un único nodo. En cada momento, un pool tiene un único nodo que lo sirve, y la solicitud se retransmite a él. Por tanto, un nodo no disponible produce un error de retransmisión en lugar de las propiedades del pool. Solución alternativa: consulte la tabla de pools en la interfaz; responde desde la base de datos de vStack Center y sigue disponible cuando el nodo no lo está, pero muestra el último estado registrado.
Las propiedades de los datasets están controladas por un indicador de funcionalidad (feature flag). Mientras la
funcionalidad filesystem_options no esté habilitada en el clúster, el formulario de propiedades del dataset en la interfaz no se abre, y
filesystems-set devuelve un error.
No hay niveles de almacenamiento. La plataforma no admite un esquema de "caché en SSD más capacidad en discos duros", y tampoco se puede crear un pool "lento" independiente; consulte los requisitos de discos en la documentación de vStack OS.
Qué leer a continuación
- Cómo ver los pools del clúster: la tabla de pools, la página del pool y el desglose del pool por disco.
- Cómo ver y cambiar las propiedades de un dataset: lectura de las propiedades de ZFS y cambio de la compresión.
- Campos y códigos de error de los métodos de almacenamiento: campos de respuesta y explicación de los códigos de error.
- Recuperación de un pool tras el fallo de un disco: en la sección "Procedimientos".