Pools de armazenamento
O problema e por que ele importa
Um cluster hiperconvergente não tem sistema de armazenamento externo. Os discos ficam instalados nos mesmos servidores que executam as máquinas virtuais, e a camada de armazenamento definido por software (SDS) combina esses discos em pools. Um pool oferece redundância, compressão e deduplicação e armazena todos os dados do cluster.
Isso traz uma questão prática para os administradores: um pool não é apenas um "disco com uma porcentagem de uso", mas um objeto com duas capacidades diferentes, quatro flags de estado e discos em todos os nós do cluster. Sem entender esse modelo, você pode interpretar mal os números na interface: a capacidade bruta é confundida com a capacidade disponível, e o tamanho total dos discos das máquinas virtuais é confundido com o espaço usado.
Esta página explica o modelo. Para visualizar pools, consulte Como visualizar os pools do cluster; para trabalhar com propriedades de datasets, consulte Como visualizar e alterar propriedades de datasets.
Modelo e entidades
A camada de armazenamento do cluster tem três níveis.
Discos e pool. Um pool é um grupo de discos combinados pelo ZFS. Ele é formado por discos de todos os nós do cluster, não de um único nó, e sua redundância corresponde à redundância do cluster. Por isso, a perda de um disco é um evento no nível do pool, e não um evento que afeta uma única máquina virtual. A distribuição dos discos entre os pools, o nível de RAID-Z resultante e os discos compatíveis estão descritos na documentação do vStack OS: Discos de armazenamento e pools.
Um pool tem um nome (name), um identificador persistente (guid) e o número do nó que o
atende no momento (node_id) — o nó pelo qual o cluster acessa o
pool no momento. Na interface, essa é a coluna Current node. Os discos do pool não
pertencem a esse nó: eles estão distribuídos por todos os nós, e cada disco do pool tem seu próprio número de nó.
Dataset. Uma unidade dentro de um pool que contém o disco de uma máquina virtual.
Ele é endereçado por um nome completo, como pool-a/vm-100-disk-0, e por seu próprio GUID. As propriedades
do dataset — compressão, deduplicação, tamanho do volume, checksums — são armazenadas
separadamente das propriedades do pool e alteradas por métodos próprios.
| Entidade | Endereçada por | Pertence a |
|---|---|---|
| Pool | guid ou o par nodeId (nó que atende) + name | cluster |
| Dataset | guid do disco | pool |
Como funciona
A camada de armazenamento do vStack Center tem dois caminhos independentes até os dados, e a diferença entre eles explica a maioria das respostas inesperadas.
O primeiro caminho é o mapa de pools do banco de dados do vStack Center. O dispatcher do cluster mantém um retrato dos estados de todos os pools e responde às solicitações imediatamente, de forma síncrona. O mapa fica disponível mesmo quando um nó não responde, mas mostra o último estado capturado, e não o estado atual.
O segundo caminho é uma consulta ao vivo ao nó. A solicitação é repassada ao agente Storage no nó
correspondente. Primeiro chega a resposta intermediária {"message": "relayed"}, depois a resposta final
por meio de um callback do agente. Os métodos ao vivo fornecem o conjunto completo de propriedades ZFS, mas
um nó que não responde significa um erro em vez de dados.
| O que você precisa | Método | Modo | Fonte dos dados |
|---|---|---|---|
| Todos os pools agrupados por nó | pool-map | síncrono | banco de dados do vStack Center |
| Todos os pools com capacidade e estado | pool-map-by-guid | síncrono | banco de dados do vStack Center |
| Pools atendidos por um nó | pools-list | assíncrono | agente Storage do nó |
| Propriedades completas de um pool | pools-get | assíncrono | agente Storage do nó |
| Propriedades de um dataset | filesystems-get | assíncrono | agente Storage do nó |
| Alteração de propriedades de um dataset | filesystems-set | assíncrono | agente Storage do nó |
Duas capacidades do pool
Sete campos descrevem a capacidade do pool, e confundi-los pode sair caro: a diferença entre a capacidade bruta e a utilizável é a parte reservada à redundância.
| Campo | O que mostra |
|---|---|
size_raw | Capacidade bruta — a soma das capacidades dos discos do pool |
size | Capacidade utilizável — size_raw menos a parte reservada à redundância |
used | Espaço usado pelos dados |
free | Capacidade utilizável restante: size menos used |
capacity_pct | Uso do pool em porcentagem |
provisioned | A soma dos tamanhos solicitados de todos os datasets do pool |
provisioned_pct | A razão entre provisioned e a capacidade utilizável, em porcentagem |
Os datasets usam thin provisioning: o tamanho de volume solicitado não é reservado imediatamente.
Assim, provisioned é calculado a partir dos tamanhos solicitados, enquanto used reflete o uso real, e o primeiro número
pode facilmente superar o segundo. Um valor de provisioned_pct acima de 100 indica
overcommit: os datasets do pool solicitaram mais espaço do que a capacidade utilizável do pool. Isso não é
uma emergência por si só, mas a partir desse ponto monitore o uso do pool por
capacity_pct, e não pelas cotas restantes.
Quatro flags de estado
| Campo | Significado |
|---|---|
health | Estado do pool; ONLINE para um pool íntegro |
consuming | O cluster aceitou o pool para armazenamento ativo de dados (1 / 0) |
scrubbing | Uma verificação de integridade dos dados está em andamento (1 / 0) |
resilvering | A redundância está sendo restaurada após a substituição de um disco (1 / 0) |
Junto com esses campos, o mapa retorna lif — o endereço de rede pelo qual o pool está acessível.
A flag consuming controla as gravações no pool. O cluster não grava dados em um pool com valor
0, e as operações que exigem gravação são rejeitadas: criar e
excluir snapshots de máquinas virtuais, reverter para um snapshot, enviar um backup,
criar uma máquina em um pool selecionado explicitamente, clonar uma máquina usando o pool de origem,
excluir o disco de uma máquina e operações em datasets de backup. Se uma dessas operações
falhar com a máquina virtual em execução, verifique o valor de consuming do pool dela antes de
procurar a causa na própria máquina. Adicionar e expandir um disco não verificam essa
flag.
Quem pode ver o quê
Os dois níveis têm escopos de visibilidade diferentes. Isso é uma propriedade dos métodos, não uma configuração.
Um pool é um objeto no nível do cluster. Os métodos ao vivo de pool (pools-list, pools-get) estão disponíveis
apenas para o papel global Cluster master. Dois papéis globais podem ler o mapa de pools (pool-map):
Cluster master e Resource Viewer. Um administrador de VDC
(data center virtual) não vê pools: um pool não tem VDC proprietário, e
um único pool contém datasets de VDCs diferentes. A exceção é pool-map-by-guid: a documentação canônica da API
não especifica o acesso a esse método.
Um dataset é um objeto no nível do VDC. A leitura de propriedades (filesystems-get) e a alteração delas
(filesystems-set) estão disponíveis para o papel de administrador de VDC e superiores, e apenas dentro do próprio
VDC. A propriedade do dataset é verificada antes do contato com o nó, e um dataset que pertence a outro VDC
é rejeitado com o mesmo código de erro de um dataset inexistente: a existência de um dataset
em outro VDC não é revelada. Um papel global pode trabalhar com datasets de qualquer VDC.
Limitações
No nível do pool, a API do cluster é somente leitura. O grupo storage não tem métodos para criar, excluir ou
expandir um pool — ele fornece um mapa, uma lista e propriedades. Não há como contornar isso com uma solicitação:
a única operação de gravação na camada de armazenamento nesse nível é a alteração de propriedades de datasets
por meio de filesystems-set.
Os métodos ao vivo de pool passam por um único nó. A cada momento, um pool tem um nó que o atende, e a solicitação é repassada a ele. Por isso, um nó indisponível produz um erro de repasse em vez das propriedades do pool. Solução alternativa: consulte a tabela de pools na interface — ela responde a partir do banco de dados do vStack Center e continua disponível quando o nó está indisponível, mas mostra o último estado capturado.
As propriedades de datasets são controladas por uma feature flag. Enquanto a feature
filesystem_options não for habilitada no cluster, o formulário de propriedades de dataset na interface não abre, e
filesystems-set retorna um erro.
Não há camadas (tiers) de armazenamento. A plataforma não oferece suporte a um layout "cache em SSD mais capacidade em disco rígido", e também não é possível criar um pool "lento" separado — consulte os requisitos de discos na documentação do vStack OS.
O que ler a seguir
- Como visualizar os pools do cluster — a tabela de pools, a página do pool e a divisão do pool por disco.
- Como visualizar e alterar propriedades de datasets — leitura de propriedades ZFS e alteração da compressão.
- Campos e códigos de erro dos métodos de armazenamento — campos de resposta e explicação dos códigos de erro.
- Recuperação de um pool após falha de disco — na seção "Procedimentos".