Corrigir problemas de falta de espaço no Thin Provisioning LVM do SUSE Linux Enterprise de forma segura

O que você deve determinar antes de mudar qualquer coisa?

Primeiro, determine se o pool fino esgotou o espaço de dados , o espaço de metadados ou ambos. Essa distinção altera o plano de recuperação. Um pool fino contém um LV de dados que armazena os blocos alocados e um LV de metadados que rastreia essas alocações. O tamanho virtual dos volumes lógicos finos pode exceder a capacidade física do pool, que é o objetivo do provisionamento fino, mas também o motivo pelo qual o sobreprovisionamento deve ser monitorado.

A documentação do SUSE Linux Enterprise Server 15 SP7 confirma que os volumes thin alocam espaço de um pool thin sob demanda e que o tamanho virtual combinado pode exceder o armazenamento físico disponível. A documentação upstream do LVM thin-pool adiciona uma regra operacional importante: estenda o pool antes que o tamanho virtual Data%ou o tamanho físico Meta%atinja 100%. Consulte o Guia de Administração de Armazenamento do SUSE Linux Enterprise Server 15 SP7 e o manual de provisionamento thin do LVM .

1. O espaço de dados está cheio ou os metadados estão cheios?

Execute a verificação lvscom colunas explícitas em vez de depender de uma verificação genérica de espaço em disco. Um sistema de arquivos ainda pode reportar espaço virtual livre enquanto o pool físico subjacente estiver quase esgotado.

lvs -a -o lv_name,vg_name,lv_attr,lv_size,data_percent,metadata_percent

Legenda: O thin pool deve ser identificado pelos seus valores de Data% e Meta%; o espaço livre do sistema de arquivos por si só não indica o esgotamento físico do thin pool.

Se Data%o valor for igual ou próximo de 100, o pool ficou sem blocos para novas gravações. A documentação oficial do LVM alerta que as gravações podem retornar erros quando o pool de dados está esgotado, o que pode danificar os sistemas de arquivos. Se Meta%o valor atingir 100, a resposta será mais conservadora, pois o esgotamento dos metadados pode deixar tanto os metadados do thin pool quanto os sistemas de arquivos inconsistentes.

2. O grupo de volume ainda possui extensões físicas livres?

Este é o próximo ponto de decisão. Um pool fino só pode crescer se o seu grupo de volumes tiver extensões livres, a menos que você adicione mais armazenamento físico a esse grupo de volumes primeiro.

vgs -o vg_name,vg_size,vg_free
vgdisplay VG_NAME

Legenda: Verificar o espaço livre no VG diferencia uma simples extensão de thin pool de um caso que exige adicionar armazenamento primeiro.

Se o VG tiver espaço livre suficiente, geralmente você pode expandir o thin pool diretamente. Se o VFreeespaço for zero ou muito pequeno, não continue tentando lvextend; decida se você pode remover volumes thin ou snapshots desnecessários, recuperar blocos com o comando discard ou adicionar um novo volume físico.

3. Você deve interromper os aplicativos antes da recuperação?

Se o pool já estiver com 100% de sua capacidade ocupada, interrompa ou suspenda os aplicativos que realizam muitas gravações antes de fazer alterações no armazenamento. Isso reduz a probabilidade de que bancos de dados, máquinas virtuais, contêineres ou outros serviços continuem emitindo gravações enquanto a camada de armazenamento estiver com falhas ou sendo reparada.

systemctl stop YOUR_APPLICATION.service
systemctl status YOUR_APPLICATION.service

Legenda: Suspender os aplicativos limita gravações adicionais enquanto um pool fino cheio ou danificado está sendo recuperado.

Não existe uma lista universal de serviços a serem interrompidos. Utilize a arquitetura de sua carga de trabalho e os procedimentos de manutenção. Para bancos de dados e máquinas virtuais, prefira o método de desligamento ou quiescência suportado pelo produto em vez de encerrar processos abruptamente.

4. Se o Data% estiver cheio e o VG tiver espaço livre, como você expande o pool?

Estenda o próprio thin pool, não o thin LV virtual, porque o problema é a falta de capacidade física do pool. Por exemplo:

lvextend -L +20G VG_NAME/THIN_POOL
lvs -o lv_name,vg_name,lv_size,data_percent,metadata_percent VG_NAME/THIN_POOL

Legenda: Expandir o pool de dados limitados aumenta a capacidade física; a porcentagem de dados resultante deve diminuir assim que o novo espaço estiver disponível.

O manual do lvextend documenta a extensão direta do thin pool e a --poolmetadatasizeopção separada para metadados. Escolha um incremento com base na taxa de crescimento real e na capacidade de armazenamento que você pode reservar. Um exemplo fixo como esse +20Gnão é uma recomendação de dimensionamento para todos os sistemas.

5. E se o grupo de volumes não tiver espaço livre?

Adicione armazenamento somente após confirmar que o dispositivo de bloco de destino não está em uso e não contém dados necessários. A criação de um volume físico LVM grava metadados LVM no dispositivo selecionado; portanto, um erro no nome do dispositivo pode ser destrutivo.

lsblk
blkid

pvcreate /dev/NEW_DEVICE
vgextend VG_NAME /dev/NEW_DEVICE
vgs -o vg_name,vg_size,vg_free

Legenda: Quando o VG estiver cheio, um novo armazenamento físico poderá ser adicionado primeiro, após o administrador verificar o dispositivo não utilizado correto.

A documentação da SUSE indica que os grupos de volumes podem ser expandidos adicionando partições ou discos inteiros. Em sistemas com múltiplos caminhos (multipath), SAN, RAID, criptografados, em cluster ou com suporte em nuvem, revise a topologia de armazenamento antes de realizar essa expansão, pois a camada de dispositivo correta pode não ser o disco bruto mostrado em um exemplo simples.

6. E se a Meta% atingisse 100%?

Trate o esgotamento de metadados como um caso de reparo offline, em vez de simplesmente adicionar capacidade de dados. O manual do thin pool do LVM afirma explicitamente que o esgotamento de metadados pode causar inconsistências nos metadados e no sistema de arquivos do thin pool. A sequência de recuperação documentada consiste em desativar o pool, repará-lo com o comando `lvm repair` lvconvert --repair, estender os metadados e, em seguida, verificar o sistema de arquivos.

Após encerrar os aplicativos, desmonte os sistemas de arquivos ou desative os volumes lógicos (LVs) finos que utilizam o pool. Em seguida, siga um procedimento de manutenção controlado semelhante a:

lvchange -an VG_NAME/THIN_LV
lvconvert --repair VG_NAME/THIN_POOL
lvextend --poolmetadatasize +1G VG_NAME/THIN_POOL

Legenda: Uma condição de metadados completos requer reparo offline do thin pool e espaço adicional para metadados, não apenas mais extensões de dados.

A +1Gfigura é apenas um exemplo. O dimensionamento dos metadados depende do tamanho do pool, do tamanho do bloco, do uso de snapshots e do comportamento de alocação. Após o reparo, inspecione os logs do sistema e use o procedimento de verificação ou reparo específico do sistema de arquivos, caso tenham ocorrido erros de E/S. Não execute uma ferramenta de reparo do sistema de arquivos sem antes verificar se o sistema está montado.

Excluir arquivos pode liberar imediatamente um pool de memória limitado?

Nem sempre. Apagar um arquivo libera espaço no sistema de arquivos, mas o pool fino só recupera os blocos físicos quando as informações de descarte chegam ao pool. A documentação do LVM observa que o TRIM fstrimpode recuperar esses blocos, enquanto os snapshots podem continuar referenciando os blocos e impedindo que sejam liberados. Se o pool estiver configurado para ignorar descartes, o TRIM não recuperará os blocos.

Quando o sistema de arquivos e a carga de trabalho permitirem, verifique o comportamento de descarte e execute o trim somente depois que o pool estiver estável o suficiente para operar:

lvs -o lv_name,discards VG_NAME/THIN_POOL
fstrim -v /mount/point

A exclusão de snapshots antigos e finos também pode liberar espaço de armazenamento quando esses snapshots forem as únicas referências restantes aos blocos. Verifique os requisitos de backup e retenção antes de excluir snapshots.

7. Como evitar que isso aconteça novamente?

Habilite e verifique o monitoramento de thin pool do LVM e configure a extensão automática com capacidade livre suficiente no VG. O LVM upstream usa dmeventd, normalmente por meio do lvm2-monitorserviço, para reagir quando o uso de dados ou metadados ultrapassa o limite configurado.

systemctl status lvm2-monitor.service
lvs -o+seg_monitor VG_NAME/THIN_POOL
lvchange --monitor y VG_NAME/THIN_POOL

lvmconfig --type full activation/thin_pool_autoextend_threshold
lvmconfig --type full activation/thin_pool_autoextend_percent

Legenda: A extensão automática depende do monitoramento ativo, de um limite apropriado e de extensões livres restantes no grupo de volume.

O manual do LVM afirma que um limite de 100 desativa a extensão automática e que o limite mínimo válido é 50. Um limite inferior dá ao LVM mais tempo para reagir a pools com taxas de gravação muito rápidas. A porcentagem de extensão determina o quanto o pool cresce quando a política é acionada.

Uma configuração representativa /etc/lvm/lvm.confpoderia ser:

activation {
    thin_pool_autoextend_threshold = 70
    thin_pool_autoextend_percent = 20
}

Esses valores são exemplos, não padrões universais. Dimensione a margem de segurança de acordo com a taxa de gravação em rajada, o intervalo de monitoramento, o tempo de provisionamento de armazenamento e o espaço livre disponível no VG. A extensão automática não ajudará se o próprio VG já estiver cheio.

8. Como você sabe que a recuperação realmente funcionou?

Verifique mais de um sinal. O pool deve ter margem de segurança, o VG deve ter espaço livre suficiente para o crescimento esperado, os aplicativos devem conseguir gravar normalmente e os logs não devem mostrar erros contínuos de E/S ou de metadados do thin pool.

lvs -a -o lv_name,vg_name,lv_attr,lv_size,data_percent,metadata_percent
vgs -o vg_name,vg_size,vg_free
journalctl -u lvm2-monitor.service --since "30 minutes ago"

Legenda: A recuperação é confirmada quando a utilização do pool apresenta margem de segurança, o VG mantém espaço livre utilizável e o monitoramento não registra erros contínuos de E/S.

Reinicie os aplicativos gradualmente e observe o pool de recursos enquanto a carga de trabalho real retorna. Se Data%o número de usuários aumentar muito rapidamente novamente, expandir o pool pode ter resolvido a interrupção imediata, mas não o problema de planejamento de capacidade.

Quando você deve parar e usar um caminho de recuperação diferente?

O que você deve evitar?

• Não assuma que df -hisso comprove que uma piscina fina possui armazenamento físico gratuito.
• Não inicialize um novo dispositivo pvcreateaté que você tenha confirmado que ele não está em uso.
• Não trate o esgotamento de metadados como o mesmo problema que o esgotamento de dados comuns.
• Não confie na extensão automática sem reservar extensões livres no VG.
• Não execute comandos de reparo do sistema de arquivos em sistemas de arquivos montados, a menos que o fornecedor do sistema de arquivos ofereça suporte explícito a essa operação.
• Não desative o monitoramento apenas para suprimir avisos; o aviso geralmente é a última oportunidade de expandir o pool antes que as gravações falhem.

Referências oficiais e primárias

• Guia de Administração de Armazenamento do SUSE Linux Enterprise Server 15 SP7
• Documentação do Particionador Especialista do SUSE SLES 15 SP7
• Manual de provisionamento fino LVM
• Manual de extensão LVM