0

LVM Migration

0 Flares 0 Flares ×

Qual seria a melhor estrategia para migração de SAN em LVM? Antes de responder, precisamos entender os tipos de lvm existente, quando e como devemos usa-los.

No LVM, um grupo de volumes é divido em volumes logicos. Existem três tipos de volumes logicos LVM, são: linear, striped e mirror.

 

Linear Volumes

Um volume linear agrega espaço de um ou mais volumes físicos em um volume lógico. O armazenamento físico é concatenado. Se nada for especificado, este profile será adotado por default.

 

 

 

 

 

Striped Logcal Volumes

Você pode controlar a maneira de como os dados são escritos nos volumes físicos, utilizando o volume logico striping. Striping melhora o desempenho de gravação de dados em um número predeterminado de volumes físicos em round-robin, dessa forma o I/O pode ser feito em paralelo. Em algumas situações, isto pode resultar em ganho de desempenho quase linear para cada volume físico adicional na faixa.

 

 

 

Mirrored Logical Volumes

Um mirror mantém cópias idênticas de dados em dispositivos diferentes. Quando os dados são gravados em um dispositivo, ele é escrito para um segundo dispositivo também, espelhando os dados. Isso fornece proteção para falhas do dispositivo. Quando uma perna de um espelho falhar, o volume lógico se tornará um volume linear e ainda pode ser acessado. LVM mantém um pequeno registro que ele usa para manter o controle de quais regiões estão em sincronia com os espelhos. Este registo pode ser mantido no disco, que irá mantê-lo persistente entre as reinicializações, ou pode ser mantida na memoria.

 

 

Ok! E, sobre a migração de SAN, qual será a estratégia mais segura? O pvmove funcionará !?A minha recomendação, vá de LVM mirror. É um método mais seguro, zero de inatividade e sem perda de dados. !!

 

Há duas maneiras de migrar partições LVM (Storages), uma está usando o método Mirroring e outro usando o comando pvmove. Para fins de demonstração, aqui estou usando Rhel 6.8 e FreeNAS.

  • Volume Físico ativo: /dev/sdc1: 7gb – Volume group name vgAB.
  • Volume Físico destino: /dev/sdb1 9gb

 

Importante!

Para o sucesso da migração, o volume de destino deverá ser igual ou superior ao numero de blocagem do volume de origem.

 

Antes de começar o processo de migração de lvm, vou criar um arquivo e toma seu md5sum para compara-lo no final do processo.

[root@localhost VolA]# md5sum tt
89198ba76bef8505d3416fdb910f617a  tt

Processo LVM Mirror

Iniciando o disco físico no LVM, em outras palavras, criando um volume físico.

[root@localhost ~]# pvcreate /dev/sdb1 
  Physical volume "/dev/sdb1" successfully created

Agora vamos estender o volume group vgAB

[root@localhost ~]# vgextend vgAB /dev/sdb1
  Volume group "vgAB" successfully extended

Feito isso, podemos converter o volume logico existente vgAB em um mirror com duas pernas. Observe que eu estou usando um registro baseado em memória sync (opção corelog) em vez de um volume de registro bitmap. Uma vez que este não se destina a ser um espelho de longo prazo, que é seguro e rápido de usar um registo de memória em vez de o volume de log mais tradicional.

[root@localhost VolA]# lvconvert -m1 --corelog vgAB/lvAB /dev/sdb1
  vgAB/lvAB: Converted: 0.3%
  vgAB/lvAB: Converted: 7.8%
  vgAB/lvAB: Converted: 15.3%
  vgAB/lvAB: Converted: 22.7%
  vgAB/lvAB: Converted: 29.8%
  vgAB/lvAB: Converted: 37.3%
  vgAB/lvAB: Converted: 44.2%
  vgAB/lvAB: Converted: 51.2%
  vgAB/lvAB: Converted: 58.2%
  vgAB/lvAB: Converted: 65.4%
  vgAB/lvAB: Converted: 72.3%
  vgAB/lvAB: Converted: 79.7%
  vgAB/lvAB: Converted: 86.8%
  vgAB/lvAB: Converted: 94.3%
  vgAB/lvAB: Converted: 100.0%

Em outro prompt, acompanhei o processo atentamente. Lógico que o tempo aqui vai variar de acordo com a sua quantidade de dados.

[root@localhost ~]# lvs -o+devices vgAB
  LV   VG   Attr       LSize Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert Devices                          
  lvAB vgAB mwi-aom--- 3.50g                   61.79            lvAB_mimage_0(0),lvAB_mimage_1(0)

Este evento registrar no message algo como se segue.

Mar  2 16:08:03 localhost dmeventd[2497]: dmeventd ready for processing.
Mar  2 16:08:03 localhost lvm[2497]: Monitoring mirror device vgAB-lvAB for events.

Finalizando. No shell do lvm podemos ver com o comando “lvdisplay -m” que o vgAB está espelhado em dois discos.

lvm> lvdisplay -m
  --- Logical volume ---
  LV Path                /dev/vgAB/lvAB
  LV Name                lvAB
  VG Name                vgAB
  LV UUID                XGsWeU-9js8-4Ras-mSFj-3YaP-RSnq-cSiL64
  LV Write Access        read/write
  LV Creation host, time localhost.localdomain, 2016-03-02 16:01:56 -0300
  LV Status              available
  # open                 1
  LV Size                3.50 GiB
  Current LE             895
  Mirrored volumes       2
  Segments               1
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     256
  Block device           253:2
   
  --- Segments ---
  Logical extents 0 to 894:
    Type            mirror
    Monitoring             monitored
    Mirrors         2
    Mirror size            895
    Mirror region size     512.00 KiB
    Mirror original:
      Logical volume lvAB_mimage_0
      Logical extents      0 to 894
    Mirror destinations:
      Logical volume lvAB_mimage_1
      Logical extents      0 to 894

Este próximo passo vamos quebrar o mirror. Escolhi fazer a quente, com file system ativo. Se isso é sábio ou não, depende do tipo do seu file system e o tipo de workload. Em um mundo perfeito, desmontaria o volume, dividia o mirror e por fim, montaria o volume.

[root@localhost ~]# lvconvert -m0 vgAB/lvAB  /dev/sdc1
  Logical volume lvAB converted.

Perceba que em atributos do volume logico (Attr) não temos mais lvm mirror.

[root@localhost VolA]# lvs -o+devices vgAB
  LV   VG   Attr       LSize Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert Devices     
  lvAB vgAB -wi-ao---- 3.50g                                                     /dev/sdb1(0)

 

Nota:

Caso necessário, executa uma limpeza no lv mirror. O LVM não irar remover automaticamente os dispositivo de imagem do mirror, porquer o volume ficou ativo duranto o processo de divisão. Para garantir, novamente no shell lvm, execute o comanda lvdisplay com as flags -am, para garantir que todas as extenções estão corretamente mapeados ao VG.

lvremove -f  vgAB/lvAB lvAB_mimage_0
lvremove -f  vgAB/lvAB lvAB_mimage_1

 

Podemos dividir dois volume group. Depois recriar o volume lógico exatamente nos mesmo limites de extensão. Observe o parâmetro -l1791. O valor 1791 foi o “Current LE” size antes de iniciar o mirror.

[root@localhost ~]# vgsplit vgAB bkpAB /dev/sdc1
  New volume group "bkpAB" successfully split from "vgAB"
[root@localhost ~]# lvcreate -l1791 -n bkpLV bkpAB
  Logical volume "bkpLV" created.

Como último passo, executa o fsck no dispositivo de backup. Necessário pelo fato que, quebramos o mirror online, sem desmontar o file system.

[root@localhost ~]# fsck /dev/bkpAB/bkpLV 
fsck from util-linux-ng 2.17.2
e2fsck 1.41.12 (17-May-2010)
fsck.ext2: Superblock invalid, trying backup blocks...
Superblock needs_recovery flag is clear, but journal has data.
Recovery flag not set in backup superblock, so running journal anyway.
/dev/mapper/bkpAB-bkpLV: recovering journal
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information

Free blocks count wrong for group #1 (32543, counted=32542).
Fix<y>? yes

Free blocks count wrong (883898, counted=883897).
Fix<y>? yes

Free inodes count wrong for group #0 (8181, counted=8180).
Fix<y>? yes

Free inodes count wrong (229365, counted=229364).
Fix<y>? yes


/dev/mapper/bkpAB-bkpLV: ***** FILE SYSTEM WAS MODIFIED *****
/dev/mapper/bkpAB-bkpLV: 12/229376 files (0.0% non-contiguous), 32583/916480 blocks

Feito isso, vamos montar o volume de backup e compara o md5sum do conteúdo vs o conteúdo de produção atual.

Volumes ativos e montados:
/dev/mapper/vgAB-lvAB
                      3.4G  7.0M  3.2G   1% /root/VolA
/dev/mapper/bkpAB-bkpLV
                      3.4G  7.0M  3.2G   1% /root/VolB

Volume Group ativos:

[root@localhost ~]# vgs
  VG         #PV #LV #SN Attr   VSize VFree
  bkpAB        1   1   0 wz--n- 7.00g    0 
  vgAB         1   1   0 wz--n- 9.00g 5.50g
  vg_livedvd   1   2   0 wz--n- 7.51g    0

Comparando o md5. Não temos alteração

[root@localhost ~]# md5sum Vol*/tt
89198ba76bef8505d3416fdb910f617a  VolA/tt
89198ba76bef8505d3416fdb910f617a  VolB/tt
[root@localhost ~]# cat Vol*/tt
Ola
Tudo certo por aqui !!!

Ola
Tudo certo por aqui !!!
[root@localhost ~]# ls -lh Vol*/
VolA/:
total 20K
drwx------ 2 root root 16K Mar  2 16:02 lost+found
-rw-r--r-- 1 root root  29 Mar  2 16:06 tt

VolB/:
total 20K
drwx------ 2 root root 16K Mar  2 16:02 lost+found
-rw-r--r-- 1 root root  29 Mar  2 16:06 tt

No futuro próximo, podemos remover o volume de backup e entregar a lun antigo para o storage !!!!

Processo com o comando pvmove Mirroring

O comando pvmove com a opção -n é usando para espelhar os dados entre dois devices.

[root@localhost ~]# pvmove -n /dev/mapper/vgAB-lvAB /dev/sdc1 /dev/sdb1

Nota

Recomendo, para maior segurança a utilização do método lvm mirror.

Jonatas Lopes

Sempre aprendendo coisas novas e passando o conhecimento adiante !!!

Dúvidas? Deixe seu comentário ou entre em contato.