LVM: movimentação de volumes físicos

Question

Em um servidor virtual (Debian GNU / Linux 8 amd64) eu tenho os seguintes discos e sistemas de arquivos:

# pvscan 
  PV /dev/vda1   VG vg0   lvm2 [100.00 GiB / 0    free]
  PV /dev/vdb1   VG vg0   lvm2 [46.56 GiB / 0    free]
  PV /dev/vda2   VG vg0   lvm2 [100.00 GiB / 0    free]
  PV /dev/vdc1   VG vg0   lvm2 [60.00 GiB / 60.00 GiB free]
  Total: 4 [306.55 GiB] / in use: 4 [306.55 GiB] / in no VG: 0 [0   ]

# lvdisplay 
  --- Logical volume ---
  LV Path                /dev/vg0/root
  LV Name                root
  VG Name                vg0
  LV UUID                qpeei3-v1nW-pYVR-lK7Y-4wwy-Y4Y4-c9yQEl
  LV Write Access        read/write
  LV Creation host, time nomos, 2015-03-17 16:34:05 +0100
  LV Status              available
  # open                 1
  LV Size                246.56 GiB
  Current LE             63119
  Segments               3
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     256
  Block device           253:0

# df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/dm-0       243G  135G   98G  59% /
[... no other on-disk filesystems]

O sistema de arquivos raiz é ext4.

Como /dev/vda tem espaço suficiente para todos os meus dados, desejo remover /dev/vdb e /dev/vdc . Este último existe como espaço temporário apenas para dar espaço às manobras necessárias. Os dados em /dev/vdb1 devem ser movidos para /dev/vda* antes de remover /dev/vdb1 . No entanto, o sistema de arquivos raiz atualmente abrange todas as três partições /dev/vda1 , /dev/vda2 e /dev/vdb1 .

O problema é que posso desligar a máquina virtual apenas por períodos de tempo muito curtos (alguns segundos, apenas reinicializações), por isso não posso reduzir o tamanho do sistema de arquivos raiz, porque isso requer desmontá-lo e mantê-lo o servidor para baixo por um longo tempo. Eu posso adicionar outros discos, até 500 GB, se necessário.

Eu executei pvmove para mover dados da unidade:

# pvmove /dev/vdb1 
  Detected pvmove in progress for /dev/vdb1
  /dev/vdb1: Moved: 4.0%

e esperou até atingir 100%. No entanto, o pvmove moveu os dados para /dev/vdc1 .

# pvs
  PV         VG   Fmt  Attr PSize   PFree 
  /dev/vda1  vg0  lvm2 a--  100.00g     0 
  /dev/vda2  vg0  lvm2 a--  100.00g     0 
  /dev/vdb1  vg0  lvm2 a--   46.56g 46.56g
  /dev/vdc1  vg0  lvm2 a--   60.00g 13.43g

E agora? Eu provavelmente poderia remover /dev/vdb1 , mas estou preso com meus dados em /dev/vdc1 . O que eu realmente preciso é mover os inodes alocados do sistema de arquivos raiz para fora do /dev/vdb1 para o espaço livre do sistema de arquivos em /dev/vda* . Então eu sonho que posso mover /dev/vdb1 para fora do caminho porque o sistema de arquivos mudou para /dev/vda* . Percebo que não funciona dessa maneira automaticamente, mas não consigo imaginar uma estratégia de migração que me permita fazer isso manualmente, sem encolher o sistema de arquivos raiz.

Você pode ajudar, por favor?

    

Answer 1

O procedimento a seguir é apenas uma ideia, nunca tentada, mas acho que pode funcionar:

1. Considere os prós e contras do Btrf e o fato de que ainda não está pronto para produção ainda > (bem, a partir de 2015, mas não consegui encontrar nada mais recente sobre o assunto). Vamos supor que você queira mesmo assim.
2. Backup de backup de backup
3. Converta o sistema de arquivos ext4 em Btrfs, porque o Btrfs suporta a migração on-line do ext4
4. Reduzir o novo sistema de arquivos raiz, agora Btrfs, porque o Btrfs oferece suporte à redução on-line
5. Encolher o volume do contant do LVM (vg0 / root)
6. pvmove dados desativados /dev/vdb1 (agora vdc1 se considerarmos que já os movi para /dev/vdc1 )
7. remover /dev/vdb1 (ou /dev/vdc1 )
8. diga adeus ao ext4 para sempre

Supondo que nenhuma outra resposta melhor seja postada, tentarei isso e relato aqui com os detalhes.

    

Answer 2

Ok, você evacua seus dados de vdb1 . Agora:

• remover /dev/vdb1 usando vgreduce vg0 /dev/vdb1
• use pvmove para remover dados de /dev/vdc1
• emite vgreduce vg0 /dev/vdc1 para removê-lo do grupo de volumes

Neste ponto, seus dados devem estar apenas em vda*

Seja muito cuidado antes de remover volumes físicos, pois você deve certificar-se de que seus dados foram visualizados no dispositivo a ser removido. E faça backups antes de fazer qualquer coisa

    

Answer 3

Seu problema é resize2fs de um sistema de arquivos raiz ativo e encolher para 200 GB. Uma abordagem possível é bem delineada no Unix.SE Como reduzir a questão do sistema de arquivos raiz . Ele usa pivot_root duas vezes e requer uma reinicialização manual da maioria dos processos e serviços do SO; isso leva a uma perda de dados recentes, então você não pode usá-lo se tiver um banco de dados vivo; e é assustador, para dizer o mínimo. Mas ainda assim, é uma alternativa que as pessoas tentaram com algum sucesso.