Linux Para Mortais : SUSE Leap / Enterprise; CentOS / RHEL; Ubuntu; Oracle: LVM - Logical Volume Management - Parte III

Resolvendo problemas de espaço

Nesse artigo vamos ver como o LVM (Logical Volume Management) facilita nossa vida, ao permitir resolver muito facilmente a falta de espaço de armazenamento. Veremos isso de duas maneiras nesse artigo:

The Easy Way: Iremos ver como adicionar um novo HD e "apresentá-lo" ao LVM;
The Hard Way: Alternativamente, expandir a capacidade da configuração atual, seja aumentando a partição originalmente utilizada ou adicionando mais uma partição ao LVM.

Com esse objetivo em mente, vamos criar um cenário hipotético, mas que pode ocorrer com muita facilidade: um usuário está no processo de fazer um upgrade de versão do openSUSE, quando é avisado que falta espaço em disco para prosseguir com o upgrade!

Para evitar isso, é que devemos prestar muita atenção nas informações apresentadas durante o processo de instalação e, principalmente, sabermos o espaço que temos disponível antes de começar!

Em nosso cenário hipotético, um usuário desatento está no processo de fazer um upgrade de versão do openSUSE, quando se depara com essa tela:

Ele lê algumas informações e fica um pouco preocupado, pois lembra de, antes de ter começado a empreitada, ter executado um df -h e a saída do comando foi mais ou menos essa:

linux-9558:~ # df -h

Filesystem Size Used Avail Use% Mounted on
(...)
/dev/mapper/system-root 16G 8.5G 5.0G 63% /
(...)

Hummm, dos 16 GB da partição root ( / ), ele só tem 5.0 GB disponíveis! Isso conflita com a informação na seção "Pacotes", onde consta que o tamanho total dos pacotes para a atualização é de 5.5 GB!

Além disso, algumas telas antes nesse processo de instalação, ele teve outra informação:

O sistema de arquivos da partição root é o btrfs, famoso por fazer snapshots de áreas importantes do sistema. Justamente todas as que certamente serão modificadas por um upgrade!

Como se não bastasse, o instalador irá fazer um backup de todos os arquivos que serão modificados pelo upgrade, como pode ser visto na seção "Backup" da primeira tela.

Essas informações não são ruins. Muito pelo contrário, são ótimas! A possibilidade de se recuperar de um "desastre" qualquer é o sonho de todo administrador de um SO. O que está preocupando nosso usuário é que ele simplesmente não vai ter espaço suficiente para tanto backup e os (nem tanto) inevitáveis snapshots que o btrfs irá fazer.

Nosso intrépido usuário, que já conhece um pouco o LVM, resolve abortar o upgrade nesse momento, para aumentar a capacidade do sistema. Ele sabe que vai ter que aumentar a capacidade de armazenamento da partição root.

Configuração atual

Antes de mais nada, precisamos uma boa investigação nas configurações atuais e fdisk é uma ferramenta familiar, que pode nos ajudar:

linux-9558:~ # fdisk -l
Disk /dev/sda: 40 GiB, 42949672960 bytes, 83886080 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x000efce7

Device Boot Start End Sectors Size Id Type
/dev/sda1 * 2048 83886079 83884032 40G 8e Linux LVM

Disk /dev/mapper/system-swap: 2 GiB, 2147483648 bytes, 4194304 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

Disk /dev/mapper/system-root: 15.2 GiB, 16315842560 bytes, 31866880 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

Disk /dev/mapper/system-home: 22.8 GiB, 24473763840 bytes, 47800320 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

O que podemos extrair de informação dessa listagem?

Nosso usuário tem apenas um HD (/dev/sda), com 40 GB de capacidade;
Esse HD foi particionado com uma única partição (/dev/sda1) do tipo "Linux LVM" (a-ha!), que certamente corresponde a um Physical Volume (PV) com o mesmo nome (/dev/sda1);
Existe um único Volume Group (VG), o system;
Certamente o VG system está usando todo o PV /dev/sda1;
Existem três Logical Volumes (LV): swap, root e home. E eles estão "consumindo" todos os recursos de VG system. Podemos deduzir isso somando 22.8 GB (home) + 15.2 GB (root) + 2 GB (swap).

Naturalmente, os comandos LVM pvdisplay, vgdisplay e lvdisplay devem confirmar tudo isso!

É necessário aumentar a capacidade da partição root ( / ) em, pelo menos, 16 GB! Como fazer isso?

THE EASY WAY

VGEXTEND: Que tal mais um HD?

Se nosso usuário estiver envolvido com um sistema "enlatado", ou seja, baseado em máquina física, ele pode adicionar um HD físico, com seus Terabytes extra! Se estiver em um ambiente virtual, ele simplesmente pode adicionar mais um disco virtual de bom tamanho!

Se adicionar um HD não for uma opção e se existir espaço no HD atualmente instalado que possa ser "reaproveitado", ele pode tentar a segunda opção lá na frente, a "The Hard Way"!

NOTA: Para esse tutorial, adicionamos em nossa máquina virtual um HD extra de 40 GB. Numa situação em máquina "física", esse HD não teria menos que 1 TB hoje em dia. Mas, tanto faz, os comandos são os mesmo, só os parâmetros que mudariam! Então, se quiserem, podem fazer de conta que estamos trabalhando num computador físico, que dá no mesmo...

Primeiramente, vamos checar o reconhecimento do novo HD pelo sistema:

Aí está nosso HD extra: /dev/sdb! Vamos prepará-lo para LVM.

Fazendo o que já aprendemos, com fdisk

linux-9558:~ # fdisk /dev/sdb

Welcome to fdisk (util-linux 2.28).

(...)

Command (m for help): n

Partition type

p primary (0 primary, 0 extended, 4 free)

e extended (container for logical partitions)

Select (default p): p

Partition number (1-4, default 1):

First sector (2048-83886079, default 2048):

Last sector, +sectors or +size{K,M,G,T,P} (2048-83886079, default 83886079):

Created a new partition 1 of type 'Linux' and of size 40 GiB.

Command (m for help): t

Selected partition 1

Partition type (type L to list all types): 8e

Changed type of partition 'Linux' to 'Linux LVM'.

Command (m for help): w

The partition table has been altered.

Calling ioctl() to re-read partition table.

Syncing disks.

Agora, criando o novo PV

linux-9558:~ # pvcreate /dev/sdb1

Physical volume "/dev/sdb1" successfully created

linux-9558:~ #

FINALMENTE: Estendendo o VG system

linux-9558:~ # vgextend system /dev/sdb1

Volume group "system" successfully extended

linux-9558:~ #

Depois de vgextend, nosso VG system deve estar com os 40 GB adicionados! Podemos nos assegurar disso executando vgdisplay:

linux-9558:~ # vgdisplay

--- Volume group ---

VG Name system

System ID

Format lvm2

Metadata Areas 2

Metadata Sequence No 5

VG Access read/write

VG Status resizable

MAX LV 0

Cur LV 3

Open LV 3

Max PV 0

Cur PV 2

Act PV 2

VG Size 79.99 GiB

PE Size 4.00 MiB

Total PE 20478

Alloc PE / Size 10237 / 39.99 GiB

Free PE / Size 10241 / 40.00 GiB

VG UUID X512Uf-NyrZ-1m0P-nAn0-eY3i-0ewm-LfLC8F

Estendendo o LV root

UM PARÊNTESE: Nós adicionamos 40 GB ao sistema. Mas não quer dizer que vamos usar tudo isso agora. Não precisamos, certo? Então vamos adicionar "apenas" 16 GB ao LV root, deixando o espaço restante para quando for preciso...

Se executarmos um lvdisplay agora, iremos ver a situação atual do LV root:

linux-9558:~ # lvdisplay

--- Logical volume ---

(...)

--- Logical volume ---

LV Path /dev/system/root

LV Name root

VG Name system

LV UUID mzN9k8-a6HT-nnAj-RqfG-MK5F-IoH9-djfBp4

LV Write Access read/write

LV Creation host, time install, 2017-07-30 12:46:55 -0300

LV Status available

# open 1

LV Size 15.20 GiB

Current LE 3890

Segments 1

Allocation inherit

Read ahead sectors auto

- currently set to 1024

Block device 254:1

--- Logical volume ---

(...)

Sem mais delongas, vamos executar agora um lvextend:

linux-9558:~ # lvextend -L+16G /dev/system/root

Size of logical volume system/root changed from 15.20 GiB (3890 extents) to 31.20 GiB (7986 extents).

Logical volume root successfully resized

linux-9558:~ #

Fazendo o sistema de arquivos reconhecer o novo tamanho de root

linux-9558:~ #

linux-9558:~ # btrfs filesystem resize max /

Resize '/' of 'max'

Conclusão:

linux-9558:~ # df -h

Filesystem Size Used Avail Use% Mounted on

(...)

/dev/mapper/system-root 32G 8.5G 21G 29% /

(...)

linux-9558:~ #

Pronto, 21 GB disponíveis em root ( / ), em pouquíssimas e muito práticas etapas.

Agora nosso usuário pode retomar sem medo a atualização para a nova versão do openSUSE!

Achamos que adicionar mais HD é sempre a melhor opção.

Todavia, como estamos aqui para aprender ensinando, vamos fazer um "milagre"! Até porque, existem situações extraordinárias para tudo nessa vida...

THE HARD WAY

pvresize (and more)

Se nosso usuário tiver meios de aumentar o tamanho da partição /dev/sda1, por qualquer um dos motivos abaixo, isso (usar pvresize) pode ser uma opção!

ele não usou o HD inteiro ao criar /dev/sda1, e tem espaço sobrando lá;
ele administra um sistema baseado em virtualização e prefere aumentar a capacidade física do HD virtual e em seguida o tamanho da partição /dev/sda1 (muito questionável isso!);
ele tem outra partição no HD após /dev/sda1 e que pode ser deletada (/dev/sda2, por exemplo), liberando espaço.

Independente do motivo, se ele tiver como aumentar o tamanho de /dev/sda1 ele vai poder após isso fazer um resize do Physical Volume (PV), usando o comando pvresize!

Se uma partição previamente associado à um PV ganha mais espaço por qualquer um dos "milagres" acima, executar o seguinte comando terá o efeito de fazer o LVM enxergar o "milagre"!

linux-9558:~ # pvresize /dev/sda1

Usar pvresize dessa forma, sem parâmetros nenhum, redimensiona o PV (Physical Volume) para o tamanho reportado pelo sistema operacional.

Ok, estamos entendidos! Mas o que significa aquele (and more) no título desse tópico?!

Naturalmente, comandos adicionais precisarão ser executados, para obter um "efeito cascata" ao surgimento desse tamanho extra no HD!

lvextend root..., para obter os recursos extras existentes em system, após pvresize;

btrfs filesystem resize max /, para o espaço extra chegar ao sistema de arquivos montado em root ( / )!

Mas porque o "milagre" número 2 é questionável?

Simples: dá muito trabalho e é até meio ilógico fazer isso em um ambiente virtual. É mais "inteligente" adicionar outro HD virtual e simplesmente fazer uso de um vgextend, colocando mais espaço no Volume Group system!

Todavia: Se for uma configuração "em lata", ou seja, um computador físico, talvez não seja "econômico" adicionar mais um HD por causa de 16 GB! E não seria de todo improvável a existência de espaço livre no HD atual...

Mão na massa!

Num ambiente virtual baseado em VirtualBox, por exemplo, os procedimentos descritos se traduziriam nos passos a seguir:

Aumentando o HD virtual

VBoxManage modifymedium (...)/VirtualBox/SuSEx64/Disk001.vdi --resize 61440
0%...10%...20%...30%...40%...50%...60%...70%...80%...90%...100%

O parâmetro --resize espera que o valor informado esteja em MB. Então 61440 são 61.440 MB, ou seja, 60 GB

Por questões de "segurança" e praticidade, adicionamos 20GB, ao invés de apenas adicionar os 16GB que queremos. O que chamamos de "segurança" aqui é que é sempre bom deixar uma "folga" em tudo o que fazemos, do que simplesmente trabalhar no limite de tudo. Assim, adicionamos 20 GB para usarmos 16 GB e deixarmos 4 GB de "folga".
Sim, 4 GB é uma "folga" muito grande! Uns 100 MB seriam suficientes. Mas, já que estamos tendo todo esse trabalho para adicionar 16 GB a root, por que não deixar aí uns GB sobrando, para se precisarmos em outro lugar?

Fazendo um "resizing" em /dev/sda1

Lamento informar, mas não vai ser possível fazer um "resizing" em /dev/sda1 com ela montada. O problema é que ela É o sistema e não vai dar para "consertar o avião com ele voando"!

Essa tarefa costumava dar um baita de um trabalho tempos atrás. Mas, por que complicar, se podemos simplificar? No "kit de ferramentas" do openSUSE, existe o Rescue CD!

Reiniciando o sistema pelo Rescue CD, vamos conseguir fazer o que queremos. Sigam as figuras, lendo os comentários, por favor.

Depois que iniciar o sistema pelo Rescue CD, localize e abra o GParted, como mostrado na figura acima.

Opa, tem um alerta ali! Clicando em /dev/sda1, e selecionando Informações no menu Partição, podemos ler um aviso.
Para o usuário iniciante, isso é sempre muito preocupante. Para o usuário mais avançado, isso não deve preocupar, mas precisa ser checado. Aparentemente, falta algum pacote da biblioteca lvm2...

Mas, ao tentar instalar temporariamente (estamos no Resuce CD, lembram?) o pacote lvm2, o zypper nos avisa que já está tudo instalado!

Nada a fazer!

E podemos comprovar que o pacote lvm2 está instalado simplesmente executando um comando. Por exemplo, o pvdisplay:

Malditos avisos!

Vamos ignorar isso, então, e seguir em frente!

Com /dev/sda1 selecionada, clicamos em Redimensionar / Mover e, puxando a "barra de ocupação" (?) da partição até o final, usamos todo o espaço disponível.

Depois de clicar no botão [ Redimensionar / Mover ], voltamos à tela principal. Hora de clicar no botão [ Aplicar ]!

Dam, mais avisos! E agora acusando um erro!! Calma... Vamos ver o que a ferramenta está chamando de erro:

Hummm, dá para ver que as três primeiras etapas deram certo (para a ferramenta). A que mais nos interessa é a "aumentar partição de 40.00 GB para 60.00 GB". Deu certo! Mas deu erro justamente em pvresize!...

SEM PROBLEMAS!

Por razões que não queremos nem saber, pvresize não funcionou no contexto do Rescue CD. Não tem problema, pois pretendíamos fazer isso no ambiente operacional mesmo! Vamos encerrar as atividades do Rescue CD, simplesmente clicando em [ Fechar ].

De volta à tela principal, podemos ver que a partição foi, de fato, "reparticionada", digamos assim:

Hora de reiniciar o ambiente operacional!

--X--

De volta ao nosso ambiente, podemos checar que os 60 GB estão lá!

linux-9558:~ # fdisk -l
Disk /dev/sda: 60 GiB, 64424509440 bytes, 125829120 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x000efce7

Porém, o Physical Volume continua como antes:

linux-9558:~ # pvdisplay
--- Physical volume ---
PV Name               /dev/sda1
VG Name               system
PV Size               40.00 GiB / not usable 3.00 MiB
Allocatable           yes
PE Size               4.00 MiB
Total PE              10239
Free PE               2
Allocated PE          10237
PV UUID               baPJGU-8qtX-BAmq-ZH3l-N2AH-WDMF-3bJrTJ

E, da mesma forma o Volume Group:

linux-9558:~ # vgdisplay
--- Volume group ---
VG Name               system
System ID
Format                lvm2
Metadata Areas        1
Metadata Sequence No 5
VG Access             read/write
VG Status             resizable
MAX LV                0
Cur LV                3
Open LV               3
Max PV                0
Cur PV                1
Act PV                1
VG Size               40.00 GiB
PE Size               4.00 MiB
Total PE              10239
Alloc PE / Size       10237 / 39.99 GiB
Free PE / Size       2 / 8.00 MiB
VG UUID               X512Uf-NyrZ-1m0P-nAn0-eY3i-0ewm-LfLC8F

Hora de usar pvresize

Sem mais delongas, executamos pvresize da forma como já foi explicado:

linux-9558:~ # pvresize /dev/sda1
Physical volume "/dev/sda1" changed
1 physical volume(s) resized / 0 physical volume(s) not resized

Como resultado, pvdisplay agora mostra o seguinte:

linux-9558:~ # pvdisplay
--- Physical volume ---
PV Name               /dev/sda1
VG Name               system
PV Size               60.00 GiB / not usable 2.00 MiB
Allocatable           yes
PE Size               4.00 MiB
Total PE              15359
Free PE               5122
Allocated PE          10237
PV UUID               baPJGU-8qtX-BAmq-ZH3l-N2AH-WDMF-3bJrTJ

E, como mágica, vgdisplay mostra que o Volume Group system já "enxergou" isso:

linux-9558:~ # vgdisplay
--- Volume group ---
VG Name               system
System ID
Format                lvm2
Metadata Areas        1
Metadata Sequence No 6
VG Access             read/write
VG Status             resizable
MAX LV                0
Cur LV                3
Open LV               3
Max PV                0
Cur PV                1
Act PV                1
VG Size               60.00 GiB
PE Size               4.00 MiB
Total PE              15359
Alloc PE / Size       10237 / 39.99 GiB
Free PE / Size       5122 / 20.01 GiB
VG UUID               X512Uf-NyrZ-1m0P-nAn0-eY3i-0ewm-LfLC8F

20 GiB livres!

Hora de usar lvextend

Claro que o Logical Volume root continua como antes, pois não há essa relação "bilateral" de causa e efeito, como existe entre um PV e um VG! Por isso, precisamos adicionar "manualmente" os 16 GB que queremos:

linux-9558:~ # lvextend -L+16384 /dev/system/root
Size of logical volume system/root changed from 15.20 GiB (3890 extents) to 31.20 GiB (7986 extents).
Logical volume root successfully resized

NOTA: O parâmetro -L espera que o valor informado esteja em MB. Assim 16384 significa 16.384 MB, ou seja, 16 GB. Aquele sinal de mais (+), informa que o valor informado é para ser adicionado ao tamanho existente.

Se executarmos lvdisplay agora, vamos ver o seguinte:

linux-9558:~ # lvdisplay
--- Logical volume ---
(...)

--- Logical volume ---
LV Path                /dev/system/root
LV Name                root
VG Name                system
LV UUID                mzN9k8-a6HT-nnAj-RqfG-MK5F-IoH9-djfBp4
LV Write Access        read/write
LV Creation host, time install, 2017-07-30 12:46:55 -0300
LV Status              available
# open                 1
LV Size                31.20 GiB
Current LE             7986
Segments               2
Allocation             inherit
Read ahead sectors     auto
- currently set to     1024
Block device           254:1

--- Logical volume ---
(...)

Os 16 GB já foram adicionados ao LV root. Mas...

...o sistema de arquivos precisa tomar conhecimento disso. Mas antes disso, vamos verificar em que condição o VG system se encontra agora:

linux-9558:~ # vgdisplay
--- Volume group ---
VG Name               system
System ID
Format                lvm2
Metadata Areas        1
Metadata Sequence No 7
VG Access             read/write
VG Status             resizable
MAX LV                0
Cur LV                3
Open LV               3
Max PV                0
Cur PV                1
Act PV                1
VG Size               60.00 GiB
PE Size               4.00 MiB
Total PE              15359
Alloc PE / Size       14333 / 55.99 GiB
Free PE / Size       1026 / 4.01 GiB
VG UUID               X512Uf-NyrZ-1m0P-nAn0-eY3i-0ewm-LfLC8F

Perfeito! A "sobra" que adicionamos está lá, à nossa disposição..

O tamanho de root ( / ), porém, continua como antes:

linux-9558:~ # df -h
Filesystem               Size Used Avail Use% Mounted on
(...)
/dev/mapper/system-root   16G 8.9G 4.0G 69% /
(...)

Size = 16 GB e Avail = 4.0 GB!

Hora de usar btrfs filesystem resize max /

Por fim, vamos lá:

linux-9558:~ # btrfs filesystem resize max /
Resize '/' of 'max'
ERROR: resizing of '/' failed: add/delete/balance/replace/resize operation in progress

linux-9558:~ #

Ups! Erro?!!!!! Não necessariamente...

Observem o motivo da falha: "...add/delete/balance/replace/resize operation in progress"

Estamos fazendo as coisas de forma muita rápida, talvez, e o sistema está bastante ocupado, sincronizando um monte de coisas em background, etc, etc, etc... Vamos aguardar uns 10 minutos! Hora de um cafezinho...

Se depois de uns 10 minutos o erro persistir, sugerimos que reiniciem o sistema. Sim, reboot mesmo!

linux-9558:~ # reboot
Connection to 192.168.56.101 closed by remote host.
Connection to 192.168.56.101 closed.

NOTA: Um "purista" de Linux, se por acaso tiver algum lendo esse artigo, deve estar fazendo aquela cara que o pessoal do Slackware adora fazer, quando vêem alguém reiniciando o Linux, e bradam: "Linux não é Windows, pô!". É verdade, poderíamos executar uma "meia dúzia" de comandos que fogem ao escopo desse artigo, que já está bastante esticado, e resolver esse "problema". Mas, antes de reiniciar, o Linux se encarrega de executar essa "meia dúzia" do comandos, e resolve isso pra nós...

Depois de reiniciar o sistema, podemos tentar mais uma vez:

linux-9558:~ # btrfs filesystem resize max /
Resize '/' of 'max'

Sucesso!

linux-9558:~ # df -h
Filesystem Size Used Avail Use% Mounted on
(...)
/dev/mapper/system-root 32G 8.5G 22G 29% /
(...)

Size = 32 GB e Avail = 22 GB!

NOTA: Embora seja possível fazer o que acabamos de mostrar, a nossa abordagem preferida é adicionar um HD extra (para ser redundante), mesmo que o ambiente seja virtualizado! Querem saber por quê? Então vejam como será mais simples!

BÔNUS: THE MIDLE WAY!

vgextend (and more)

Se nosso usuário for um daqueles precavidos, e ao instalar originalmente se(s) SO(s) não utilizou completamente o HD, deixando espaço para criar mais partições no futuro, existe um meio termo!

Pode ser também que ele tenha uma "partição descartável" que possa ser reaproveitada para resolver o problema que enfrentamos aqui.

Seja como for, tudo o que ele precisa fazer é o seguinte:

Preparar uma nova partição em seu HD, criando ou reutilizando uma;
Transformá-la num PV (Physical Volume), usando pvcreate;
"Apresentá-la" ao VG (Volume Group) system, usando vgextend;
Estender o LV (Logical Volume) root, usando lvextend;
Finalmente, informar ao sistema de arquivos o novo tamanho de root!

FICA A DICA!

E assim enceramos esse artigo! Esperamos que tenham gostado.

Até o próximo!...

Linux Para Mortais : SUSE Leap / Enterprise; CentOS / RHEL; Ubuntu; Oracle

Páginas

quinta-feira, 7 de junho de 2018

LVM - Logical Volume Management - Parte III - Resolvendo problemas de espaço

Resolvendo problemas de espaço

Nenhum comentário:

Postar um comentário