Recursos especiais neste artigo:
Artigo no estilo Curso Online
Neste artigo serão apresentados os procedimentos operacionais para efetuar a migração dos dados utilizando as técnicas definidas na primeira parte deste artigo. Utilizaremos recursos do próprio gerenciador de volumes LVM e ferramentas nativas do sistema operacional Linux como RSYNC e TAR.
Em que situação o tema é útil
Oartigo tem como público
alvo a geração Datacenter, como técnicos e administradores de TI responsáveis
por executar ou planejar migrações de dados corporativos, envolvendo ambientes
de missão crítica compostos por sistemas operacionais Linux.
Conforme visto na primeira parte deste artigo na edição anterior da revista Infra Magazine, o processo de migração de dados corporativos contempla diversos procedimentos operacionais e várias tarefas administrativas relacionadas ao planejamento da atividade, tornando a etapa de “Movimentação dos Dados” em si apenas parte ou uma pequena fração do processo.
Diversos outros fatores como planejamento, definição de qual estratégia utilizar levando em consideração risco x segurança x conforto operacional, direcionamentos do negócio, janela produtiva, procedimentos de Rollback, comunicação interna, entre outros, devem ser respeitados e estar alinhados com as necessidades do negócio para se decidir com objetividade, de fato, “Qual a melhor estratégia de movimentação” a ser utilizada para migrar determinado dado ou informação.
Vimos também um dos principais pilares para decisão de qual estratégia de migração utilizar, que é a situação ou forma em que o dado se encontra hospedado. O dado encontra-se armazenado em um raw device? O File System é dinâmico? A aplicação tem alguma peculiaridade? Existe algum gerenciador de volumes? Existe Multipath? Essas, entre outras questões, interferem no processo de definição do método de movimentação e também podem viabilizar ou não determinada estratégia de migração.
Na primeira parte deste artigo, foram apresentados como exemplos três servidores, sendo estes RJOSRVUXX01, RJOSRVUXX02 e RJOSRVUXX03, respectivamente. Cada um destes servidores possui seus File Systems hospedados em situações específicas de forma que, para realizar a migração de dados de cada um desses File Systems, foi escolhida uma técnica distinta de movimentação de dados, variando entre estratégias utilizando recursos do próprio gerenciador de volumes LVM ou ferramentas nativas do sistema operacional, como RSYNC e TAR.
Agora, na segunda parte do artigo, abordaremos em detalhes como executar essas estratégias, apresentando todos os comandos e procedimentos operacionais para execução de cada uma das migrações de dados.
Procedimento Operacional
A partir de agora, serão apresentadas as três estratégias de migração abordadas no artigo. Antes de efetuar a migração dos dados em si, sempre é recomendado verificar se existem backups confiáveis e íntegros de todos os dados envolvidos na migração.
Conforme definido na primeira parte do artigo, cada um dos três servidores do nosso ambiente terá uma estratégia de migração específica em função de como os dados encontram-se hospedados. As estratégias que serão empregadas para migração dos dados são:
1. Servidor RJOSRVUXX01 – Estratégia LVM PV Move;
2. Servidor RJOSRVUXX02 – Estratégia LVM Split Mirror;
3. Servidor RJOSRVUXX03 – Estratégia RSYNC.
Migração do servidor RJOSRVUXX01 – Estratégia LVM PV Move
Conforme visto na Figura 1, responsável por consolidar o mapeamento realizado no servidor RJOSRVUXX01, esse host tem quatro LVOLs (Logical Volumes) a serem migrados atualmente hospedados em três PVs (Physical Volumes). Nesse procedimento, criaremos três novos PVs e depois efetuaremos a operação “Movimentação de PV” para realizar a migração dos dados.
Figura 1. Dados a serem migrados do servidor RJOSRVUUXX01.
A Figura 2 ilustra os estágios que ocorrem durante a fase de movimentação dos dados utilizando a estratégia “LVM PV Move”. Cada um dos estágios será comentado durante o procedimento encontrado na Listagem 1, utilizada para acompanhamento do processo de migração de dados do servidor RJOSRVUXX01.
Figura 2. Estágios do procedimento “LVM – PV Move” executado no servidor RJOSRVUXX01.
Para facilitar a compreensão da sequência de comandos exibida na Listagem 1, a dividimos em várias partes e agora explicaremos cada uma separadamente:
1. Primeiramente, adicione no servidor os novos discos que receberão os dados oriundos do processo de migração. Em nosso exemplo, os novos discos já foram reconhecidos no sistema operacional com os caminhos /dev/sde (4:0:0:0), /dev/sdf (5:0:0:0) e /dev/sdg (6:0:0:0), respectivamente.
Depois dos discos já reconhecidos no sistema operacional, preencha a coluna “New Dev” da tabela “De/Para” inserindo os novos discos/LUNs reconhecidos, conforme destacado em negrito e observado na Tabela 1;
Tabela 1. Tabela De/Para preenchida do servidor RJOSRVUXX01.
2. Entre no utilitário FDISK e crie uma partição de tamanho igual ou superior à /dev/sdb1 em cada um dos novos discos. Adicionalmente, não se esqueça de colocar o tipo da partição como “8E”, senão não será possível executar os próximos passos do tutorial e não será possível criar um PV (Physical Volume) nessa partição física. Repita essa operação para os três novos discos/LUNs /dev/sde, /dev/sdf e /dev/sdg;
3. Visualize a estrutura LVM que será migrada conforme o Estágio 1 da Figura 2. Para facilitar a compreensão do procedimento que será executado, o PV existente no device /dev/sdb1 será movimentado para o device /dev/sde1, o PV existente no device /dev/sdc1 será movimentado para o device /dev/sdf1 e o PV existente no device /dev/sdd1 será movimentado para o device /dev/sdg1.
Antes que se possa movimentar o Physical Volume, primeiro devemos criar os Physical Volumes nas partições que preparamos no passo 2 (/dev/sde1, /dev/sdf1 e /dev/sdg1);
4. Agora adicione os três novos PVs criados no passo anterior ao VG (Volume Group) já existente. Após conclusão desse passo, nossa estrutura LVM estará semelhante ao Estágio 2 da Figura 2;
5. Com a etapa preparatória da estrutura LVM concluída com sucesso, podemos dar início ao processo de movimentação dos dados utilizando o comando pvmove. Essa operação pode ser executada com a aplicação em estado ONLINE. Assim que o comando for executado, a cópia já é iniciada. Repita essa etapa para cada um dos três PVs. Durante a fase de cópia, nossa estrutura LVM estará semelhante ao estágio 3 da Figura 2.
Assim que o comando pvmove concluir sua execução, o cenário esperado é que todos os Extents (áreas de 4 MB) tenham sido migrados com sucesso entre o PV origem e o PV destino e a estrutura LVM estaria semelhante ao estágio 4 da Figura 2;
6. Após ter concluído o processo de migração, daremos início à remoção lógica da estrutura LVM existente nos discos/LUNs antigos (/dev/sdc, /dev/sdd e /dev/sde), pois não precisaremos mais desses discos antigos. Todos os dados já foram migrados com sucesso para os novos discos. Essa remoção é realizada utilizando o comando vgreduce, responsável por remover um PV de um VG. Ao final do processo, nossa estrutura LVM estará equivalente ao estágio 5 da Figura 2.
Após a remoção dos PVs antigos do Volume Group db_vg, nossa estrutura LVM estará semelhante ao Estágio 6 da Figura 2, ou seja, já sem nenhuma referência dos discos/LUNs antigos que serão removidos;
7. Para manter a consistência das informações, é importante, além de remover os PVs não mais utilizados do VG, remover os PVs das partições antigas para que o LVM nunca mais identifique ou reconheça essas áreas como PVs válidos. Utilize o comando pvremove para remover esses Metadados dos discos que serão removidos em um momento futuro adiante no artigo;
8. A partir desse ponto, os discos/LUNs antigos (/dev/sdb, /dev/sdc e /dev/sdd) já podem ser removidos do host/sistema operacional sem causar nenhum impacto para as aplicações. Por meio do comando pvs, confirme que não existe mais nenhum PV nos discos antigos além dos que devem existir de fato nos novos discos. Observe que já não existe mais nenhuma referência aos PVs que existiam nos discos SDB, SDC e SDD.
Os procedimentos de remoção de devices incluem reconfiguração da camada Multipathing no sistema operacional, remoção de Zones nos Switches SAN, Unmasking dos devices na interface de gerenciamento do Storage, Unmapping dos devices das portas do Storage na interface de gerenciamento do Storage, desfazer as LUNs no Storage, entre outros. Como esses procedimentos são muito específicos em função da tecnologia e do fabricante utilizados, não serão abordados nesse artigo.
Listagem 1. Sequência de comandos para migração do host RJOSRVUXX01.
########## Trecho 1 ##########
sysadmin@rjosrvuuxx01:~$ lsscsi --size
[0:0:0:0] disk ATA VBOX HARDDISK 1.0 /dev/sda 8.58GB
[1:0:0:0] disk ATA VBOX HARDDISK 1.0 /dev/sdb 42.9GB
[2:0:0:0] disk ATA VBOX HARDDISK 1.0 /dev/sdc 42.9GB
[3:0:0:0] disk ATA VBOX HARDDISK 1.0 /dev/sdd 42.9GB
[4:0:0:0] disk ATA VBOX HARDDISK 1.0 /dev/sde 42.9GB
[5:0:0:0] disk ATA VBOX HARDDISK 1.0 /dev/sdf 42.9GB
[6:0:0:0] disk ATA VBOX HARDDISK 1.0 /dev/sdg 42.9GB
########## Trecho 2 ##########
sysadmin@rjosrvuuxx01:~$ sudo fdisk /dev/sde
Command (m for help): n
Partition type:
p primary (0 primary, 0 extended, 4 free)
e extended
Select (default p): p
Partition number (1-4, default 1): 1
First sector (2048-167772159, default 2048): <enter>
Using default value 2048
Last sector, +sectors or +size{K,M,G} (2048-167772159, default 167772159): <enter>
Using default value 167772159
Command (m for help): t
Selected partition 1
Hex code (type L to list codes): 8e
Command (m for help): w
The partition table has been altered!
Calling ioctl() to re-read partition table.
Syncing disks.
sysadmin@rjosrvuuxx01:~$ sudo fdisk /dev/sdf
sysadmin@rjosrvuuxx01:~$ sudo fdisk /dev/sdg
########## Trecho 3 ##########
sysadmin@rjosrvuuxx01:~$ sudo pvcreate /dev/sde1
Physical volume "/dev/sde1" successfully created
sysadmin@rjosrvuuxx01:~$ sudo pvcreate /dev/sdf1
Physical volume "/dev/sdf1" successfully created
sysadmin@rjosrvuuxx01:~$ sudo pvcreate /dev/sdg1
Physical volume "/dev/sdg1" successfully created
########## Trecho 4 ##########
sysadmin@rjosrvuuxx01:~$ sudo vgextend app_vg /dev/sde1
Volume group "app_vg" successfully extended
sysadmin@rjosrvuuxx01:~$ sudo vgextend app_vg /dev/sdf1
Volume group "app_vg" successfully extended
sysadmin@rjosrvuuxx01:~$ sudo vgextend app_vg /dev/sdg1
Volume group "app_vg" successfully extended
########## Trecho 5 ##########
sysadmin@rjosrvuuxx01:~$ sudo pvmove /dev/sdb1 /dev/sde1
/dev/sdb1: Moved: 0.6%
/dev/sdb1: Moved: 50.0%
/dev/sdb1: Moved: 75.0%
/dev/sdb1: Moved: 88.8%
/dev/sdb1: Moved: 100.0%
sysadmin@rjosrvuuxx01:~$ sudo pvmove /dev/sdc1 /dev/sdf1
sysadmin@rjosrvuuxx01:~$ sudo pvmove /dev/sdd1 /dev/sdg1
########## Trecho 6 ##########
sysadmin@rjosrvuuxx01:~$ sudo vgreduce db_vg /dev/sdb1
Removed "/dev/sdb1" from volume group "db_vg"
sysadmin@rjosrvuuxx01:~$ sudo vgreduce db_vg /dev/sdc1
Removed "/dev/sdc1" from volume group "db_vg"
sysadmin@rjosrvuuxx01:~$ sudo vgreduce db_vg /dev/sdd1
Removed "/dev/sdd1" from volume group "db_vg"
########## Trecho 7 ##########
sysadmin@rjosrvuuxx01:~$ sudo pvremove /dev/sdb1
Labels on physical volume "/dev/sdb1" successfully wiped
sysadmin@rjosrvuuxx01:~$ sudo pvremove /dev/sdc1
Labels on physical volume "/dev/sdc1" successfully wiped
sysadmin@rjosrvuuxx01:~$ sudo pvremove /dev/sdd1
Labels on physical volume "/dev/sdd1" successfully wiped
########## Trecho 8 ##########
sysadmin@rjosrvuuxx01:~$ sudo pvs
PV VG Fmt Attr PSize PFree
/dev/sde1 db_vg lvm2 a- 40.00g 8.00m
/dev/sdf1 db_vg lvm2 a- 40.00g 0
/dev/sdg1 db_vg lvm2 a- 40.00g 0
Migração do servidor RJOSRVUXX02 – Estratégia LVM Split Mirror
Conforme visto na Figura 3, responsável por consolidar o mapeamento realizado no servidor RJOSRVUXX02, esse host tem apenas um LVOL (Logical Volumes) de 80 GB para ser migrado atualmente hospedado em um único PV (Physical Volume).
Figura 3. Dados a serem migrados do servidor RJOSRVUUXX02.
Nesse procedimento, utilizaremos uma técnica muito interessante para migrar nossos dados, conforme observado na Figura 4, que consiste em realizar um espelhamento de dados entre disco/LUN origem e destino. Depois do espelhamento estabelecido e todos os dados copiados entre disco/LUN origem e destino, realizaremos o SPLIT (quebra) do espelhamento entre os dois discos/LUNs. Após a execução desse procedimento, ao final do artigo teremos dois Volume Groups compostos por cada um dos dois lados do espelhamento.
Normalmente essa técnica é utilizada se desprezando o Volume Group que contém os discos originais imediatamente após o término do processo de espelhamento, porém, para propósitos de Rollback, é interessante manter ambas as estruturas LVM antiga e nova até que se tenha certeza de qual dos lados será utilizado ao término do processo de migração dos dados.
Imagine uma migração de alguns Terabytes que demore cerca de 12 horas para ocorrer. Imagine também que ocorra algum problema de desempenho com o novo Storage de forma que os novos discos/LUNs não possam ser utilizados, e que seja necessário realizar um Rollback da migração dos dados depois de a migração ter sido concluída com sucesso. Uma janela de manutenção de 12 horas pode se transformar em uma janela de 24 horas, pois para realizar o Rollback os dados precisam ser sincronizados novamente.
Para evitar a necessidade de nova sincronização do espelhamento em caso de Rollback após o término do processo, ou seja, duplicando a janela de manutenção, esse artigo vai focar em manter os dois lados do espelhamento depois do término do processo de migração dos dados. A Listagem 2 consolida todos os procedimentos operacionais que devem ser adotados para migrar com sucesso os dados do servidor RJOSRVUXX02.
Figura 4. Estágios do procedimento “LVM – Split Mirror” executado no servidor RJOSRVUXX02.
Para facilitar a compreensão da sequência de comandos exibida na Listagem 2, a dividimos em várias partes, e agora explicaremos cada uma separadamente:
1- Inicie o processo adicionando no servidor RJOSRVUXX02 o novo disco que receberá os dados oriundos do processo de migração. Em nosso exemplo, o novo disco já foi reconhecido no sistema operacional com o caminho /dev/sdc (2:0:0:0).
Depois de o novo disco já estar reconhecido no sistema operacional, preencha a coluna “New Dev” da tabela “De/Para”, inserindo o caminho do novo disco/LUN reconhecido no passo anterior conforme observado na Tabela 2 e destacado em negrito;
Tabela 2. Tabela De/Para preenchida do servidor RJOSRVUXX02.
2- Entre no utilitário FDISK e crie uma partição de tamanho igual ou superior a /dev/sdb1 no disco /dev/sdc. Adicionalmente, não se esqueça de colocar o tipo da partição como “8E”; caso contrário, não será possível executar os próximos passos do tutorial e não será possível criar um PV na partição física do novo disco;
3- Visualize a estrutura LVM que será migrada conforme o Estágio 1 da Figura 4. Para facilitar a compreensão do procedimento que será executado, o Logical Volume lvol_01 existente no device /dev/sdb1 será espelhado para o device /dev/sdbc1.
Antes que se possa movimentar o PV, primeiramente devemos criar o Physical Volume na partição que preparamos no passo 2 (/dev/sdc1);
4- Depois do Physical Volume criado no passo anterior, agora adicione o PV /dev/sdc1 ao Volume Group app_vg utilizando o comando vgextend. Nesse instante, a estrutura LVM deve estar semelhante à estrutura visualizada no Estágio 2 da Figura 4;
5- A partir desse ponto, a estrutura LVM já pode ser espelhada com sucesso. Utilize o comando lvconvert e inicie a conversão do Logical Volume lvol_01 para o formato espelhamento (RAID 1), utilizando o device /dev/sdc1 como disco que receberá o novo espelhamento.
A opção “–m1” informa um espelhamento e a opção “–corelog” informa que o log de consistência entre o submirror 1 e o submirror 2 será mantido em memória em vez de ser criado em disco. A utilização da opção “—corelog” facilitará o processo de SPLIT do espelhamento que será executado mais adiante.
A velocidade de cópia varia de acordo com diversos fatores, como velocidade da controladora do host e barramento que acessa os dados, concorrência com os demais I/Os destinados à controladora do Storage por outros hosts, taxa de acesso da aplicação, entre outros fatores.
A aplicação ou serviço que utiliza os dados que estão sendo migrados não precisa estar em estado OFFLINE nesse momento. O espelhamento pode ocorrer com a aplicação ONLINE em estado produtivo.
Durante o andamento do processo de espelhamento, a estrutura LVM será idêntica à vista no Estágio 3 da Figura 4;
6- O andamento do espelhamento pode ser observado com o comando lvs na coluna Copy %, conforme destacado em negrito no output do comando.
Em nosso caso, o espelhamento já se encontra finalizado com status de sincronismo de 100% dos dados. Esse já é o ponto seguro para realizar o SPLIT da estrutura LVM. Nessa fase, a estrutura LVM estará como ilustrada no Estágio 4 da Figura 4;
7- Baseado no output do comando lvs que mostra o estado do sincronismo (Copy %) em 100%, já podemos realizar com segurança o SPLIT dos dados.
Caso seja do interesse do leitor manter os dois lados do espelhamento (antigo e novo) conforme o artigo sugere, é necessário gerar um ponto de consistência da aplicação. Se ocorrer SPLIT do espelhamento com a aplicação ativa, apenas o lado novo do espelhamento continuará sendo atualizado com os I/Os destinados ao volume. O lado antigo do espelho não será mais atualizado com as alterações que ocorrem no volume depois do momento do SPLIT, podendo inclusive estar corrompido ao final do processo e não servir para efeitos de Rollback porque o File System estava montado com a aplicação ativa.
Para haver consistência dos dados, em nosso exemplo vamos efetuar UMOUNT do File System /srv/app para que cada um dos lados do espelho tenha uma imagem idêntica e íntegra. Caso qualquer um dos lados do espelhamento venha a ser utilizado no futuro, devido à operação de SPLIT ter sido executada com o File System desmontado, não será necessária a execução da ferramenta FSCK (verificação de integridade).
Existem algumas aplicações comerciais destinadas ao universo Datacenter que oferecem recursos adicionais de consistência de dados para realizar o processo de SPLIT de espelhamento com integridade dos dados, evitando a necessidade de parada da aplicação ou umount do File System. O banco de dados Oracle, por exemplo, tem um recurso que permite colocar todas as suas TableSpaces (estruturas internas que armazenam as informações) em modo Backup (BEGIN BACKUP). Dessa forma, pode ocorrer SPLIT do espelhamento de forma íntegra. Após o termino do processo, as TableSpaces precisam ser tiradas do modo Backup.
Por meio do comando umount, efetue a desmontagem do File System para gerar o ponto de consistência;
8- Mediante geração do ponto de consistência da aplicação, utilize o comando lvconvert para efetuar o SPLIT do espelhamento. Durante este processo, o administrador precisa informar o nome do novo Logical Volume, de forma que ao final dessa etapa tenhamos dois Logical Volumes dentro de um mesmo Volume Group, conforme o Estágio 5 da Figura 4.
A opção “-n new_lvol_01” define o nome do novo Logical Volume, em nosso caso, “new_lvol_01”.
O comando lvconvert também precisa receber como parâmetro o nome do volume que sofrerá a operação de SPLIT, em nosso caso, “app_vg/lvol_01”, e por fim qual o disco que vai permanecer associado ao Logical Volume antigo, em nosso caso, “/dev/sdb1”;
9- Depois de ocorrer o SPLIT do espelhamento, verifique com o comando lvs que a partir de agora existem dois Logical Volumes, lvol_01 e new_lvol_01, com aproximadamente 80 GB cada um, e que o Volume antigo pode voltar a ser acessado sem problema algum, com os dados íntegros refletindo o momento prévio ao SPLIT. Monte novamente o File System;
10- No momento atual temos dois Logical Volumes dentro de um único Volume Group. Agora, para melhorar a gerenciabilidade dos dados, realizaremos a operações de SPLIT do Volume Group de forma que, ao final do processo, tenhamos dois Volume Groups com um Logical Volume cada, conforme pode ser observado no Estágio 6 da Figura 4. A aplicação pode estar ONLINE nesse momento, pois apenas o novo volume (new_lvol_01) que será desmembrado do Volume Group app_vg será afetado com a operação de Split do Volume Group.
Garanta a consistência dos dados deixando o volume new_lvol_01 em estado desabilitado com o comando lvchange antes de realizar o Split do Volume Group;
11- Utilize o comando vgsplit para realizar o SPLIT do Volume Group app_vg. O comando vgsplit precisa receber como parâmetros o nome do Volume Group que sofrerá operação de SPLIT (app_vg), o nome do novo Volume Group que será criado (app_vg_old) depois da operação e quais Physical Volumes irão para esse novo Volume Group; em nosso caso, /dev/sdb1.
Cuidado com a execução do comando vgsplit. Na dúvida, consulte as MAN PAGES do comando para ter certeza da sintaxe que você está executando. Em nosso caso, a utilização da nomenclatura app_vg_old se deve ao fato de o novo Volume Group que será criado ser composto do disco antigo (/dev/sdb) que já existia antes de espelharmos o volume. Ao final dessa etapa, o Volume Group antigo (app_vg) conterá o novo disco (/dev/sdc).
Listagem 2. Sequência de comandos para migração do host RJOSRVUXX02.
########## Trecho 1 ##########
sysadmin@rjosrvuuxx02:~$ sudo lsscsi --size
[0:0:0:0] disk ATA VBOX HARDDISK 1.0 /dev/sda 8.58GB
[1:0:0:0] disk ATA VBOX HARDDISK 1.0 /dev/sdb 85.8GB
[2:0:0:0] disk ATA VBOX HARDDISK 1.0 /dev/sdc 85.8GB
########## Trecho 2 ##########
sysadmin@rjosrvuuxx02:~$ sudo fdisk /dev/sdc
Command (m for help): n
Partition type:
p primary (0 primary, 0 extended, 4 free)
e extended
Select (default p): p
Partition number (1-4, default 1): 1
First sector (2048-167772159, default 2048): <enter>
Using default value 2048
Last sector, +sectors or +size{K,M,G} (2048-167772159, default 167772159): <enter>
Using default value 167772159
Command (m for help): t
Selected partition 1
Hex code (type L to list codes): 8e
Command (m for help): w
The partition table has been altered!
########## Trecho 3 ##########
sysadmin@rjosrvuuxx02:~$ sudo pvcreate /dev/sdc1
Physical volume "/dev/sdc1" successfully created
########## Trecho 4 ##########
sysadmin@rjosrvuuxx02:~$ sudo vgextend app_vg /dev/sdc1
Volume group "app_vg" successfully extended
########## Trecho 5 ##########
sysadmin@rjosrvuuxx02:~$ sudo lvconvert -m1 --corelog app_vg/lvol_01 /dev/sdc1
app_vg/lvol_01: Converted: 0.0%
app_vg/lvol_01: Converted: 22.3%
app_vg/lvol_01: Converted: 54.7%
app_vg/lvol_01: Converted: 72.9%
app_vg/lvol_01: Converted: 99.3%
app_vg/lvol_01: Converted: 100.0%
########## Trecho 6 ##########
sysadmin@rjosrvuuxx02:~$ sudo lvs
LV VG Attr LSize Origin Snap% Move Log Copy% Convert
lvol_01 app_vg mwi-ao 79.90g 100.00
sysadmin@rjosrvuuxx02:~$ sudo lvs -a -o+devices
########## Trecho 7 ##########
sysadmin@rjosrvuuxx02:~$ sudo umount /srv/app
########## Trecho 8 ##########
sysadmin@rjosrvuuxx02:~$ sudo lvconvert --splitmirrors 1 -n new_lvol_01 app_vg/lvol_01 /dev/sdb1
Logical volume lvol_01 converted.
########## Trecho 9 ##########
sysadmin@rjosrvuuxx02:~$ sudo lvs
LV VG Attr LSize Origin Snap% Move Log Copy% Convert
lvol_01 app_vg -wi-a- 79.90g
new_lvol_01 app_vg -wi-a- 79.90g
sysadmin@rjosrvuuxx02:~$ sudo mount /srv/app
########## Trecho 10 ##########
sysadmin@rjosrvuuxx02:~$ lvchange –an app_vg/new_lvol_01
########## Trecho 11 ##########
sysadmin@rjosrvuuxx02:~$ vgsplit app_vg app_vg_old /dev/sdb1Migração do servidor RJOSRVUXX03 – Estratégia RSYNC
Diferentemente dos demais servidores que até então passaram pelos procedimentos operacionais de migração de dados propostos pelo artigo, o servidor RJOSRVUXX03, conforme visto na Figura 5, não tem seus dados gerenciados pelo LVM. O mesmo possui apenas um File System (/srv/monitor) de 80 Gb montado atualmente como Hard Partition.
Já vimos também em outros momentos desse artigo que a situação de Hard Partition (/dev/sdb1) não é interessante para migração de dados ONLINE, pois é necessário parar a aplicação para gerar um ponto de consistência dos dados que serão migrados. Não podemos, por exemplo, utilizar o espelhamento via sistema operacional quando os dados não estão sob gestão do LVM.
Nesse procedimento, utilizaremos a ferramenta RSYNC nativa do próprio sistema operacional Linux para efetuar a cópia entre o File System antigo e o novo. O utilitário RSYNC possui recursos muito interessantes para esse tipo de migração, oferecendo recursos como preservar Hard Links, Soft Links, controle de banda de rede, possibilidade de controle de integridade baseado em Checksum, entre outras voltadas às necessidades mais comuns dos ambientes Datacenter.
A ferramenta RSYNC também suporta a sincronização entre servidores remotos utilizando SSH. Nesse cenário basta informar como origem ou destino da cópia um caminho no formato “usuário@servidor:/caminho/completo” e a transferência ocorrerá de forma criptografada. Em nosso tutorial, não efetuaremos uma cópia remota, mas sim local, no próprio servidor, entre um File System origem e outro File System destino.
Outra vantagem interessante do utilitário RSYNC é a possibilidade de execução de cópias incrementais dos dados. É possível executar várias sessões de RSYNC de forma que se possa copiar os dados aos poucos, em operações incrementais. Sempre que uma nova sessão é estabelecida, todos os arquivos são verificados novamente, de forma que aqueles que já estiverem copiados e idênticos entre origem e destino não sejam copiados novamente.
Figura 5. Dados a serem migrados do servidor RJOSRVUUXX03.
Para facilitar a compreensão da sequência de comandos exibida na Listagem 3, a dividimos em várias partes e agora explicaremos cada uma separadamente:
1- Inicie o processo adicionando no servidor RJOSRVUXX03 o novo disco que receberá os dados oriundos do processo de migração. Em nosso exemplo o novo disco já foi reconhecido no sistema operacional com o caminho /dev/sdc (2:0:0:0).
Depois de o novo disco já estar reconhecido no sistema operacional, preencha a coluna “New Dev” inserindo o caminho do novo disco/LUN reconhecido no passo anterior, conforme destacado em negrito na Tabela 3;
Tabela 3. Tabela De/Para preenchida do servidor RJOSRVUXX03.
2- Entre no utilitário FDISK e crie uma partição de tamanho igual ou superior a /dev/sdb1 no disco /dev/sdc. Também é recomendado manter o tipo da partição como “83”, diferente do formato LVM que era “8E”;
3- Para que se possa utilizar a nova área em disco existente no device /dev/sdc, é necessário criar um File System. Baseado no levantamento de informações que foi realizada no início do artigo, também foi documentado que o File System atual (/srv/monitor) é do tipo ext3;
4- Efetue a operação de montagem do novo File System em algum Mount Point temporário, em nosso caso, /srv/new_monitor;
5- Execute o comando df –h e verifique se o File System origem e destino já estão relacionados e disponíveis. Nos próximos passos, copiaremos todo o conteúdo do File System /srv/monitor para dentro do File System /srv/new_monitor;
6- Estabeleça um ponto de consistência dos dados efetuando o STOP das aplicações e serviços que utilizam o File System /srv/monitor que será migrado em seguida. Caso a aplicação não seja interrompida, os dados que estão sendo migrados não estarão confiáveis, podendo haver arquivos corrompidos.
Efetue a cópia dos dados utilizando a ferramenta RSYNC. O RSYNC pode receber várias opções de execução que controlam a forma que a ferramenta trabalha. Em nosso caso, são utilizadas as opções “-axvH”. Em seguida, o RSYNC precisa receber o caminho origem da cópia (/srv/monitor/), e, por fim, o caminho destino que receberá os dados (/srv/new_monitor).
A utilização das opções “-axvH” do utilitário RSYNC é recomendada para manter a integridade da estrutura de arquivos e diretórios que será migrada. Com a opção “-v” estamos habilitando o modo Verbose, a fim de mostrar mais informações durante a cópia. A opção “-x” orienta o RSYNC a não ultrapassar Mount Points caso um File System tenha Mount Point dentro de outro. A opção “-H” preserva a existência de Hard Links, caso existam. Já a opção “-a” é uma combinação de várias outras opções que ajuda a preservar todos os atributos originais do arquivo como características de permissionamento, owner/group (propriedade) e tipo de arquivo;
7- O comando TAR ou outra ferramenta de sua preferência também poderia ser utilizada para migrações de dados, porém cada uma tem sua limitação. O utilitário TAR, por exemplo, não permite arquivamento de arquivos maiores de 4GB em alguns sistemas operacionais UNIX mais antigos. Em outros casos, é necessário usar diversas opções do comando para manter os devidos permissionamentos e a integridade da estrutura de arquivos, diretórios e links. Por meio do comando TAR, realize a migração dos dados;
8- Depois de a primeira execução do comando RSYNC ter finalizado com sucesso, é saudável verificar que todos os dados permanecem íntegros e que nada mudou em relação ao momento de início da primeira execução do RSYNC. Dessa forma, execute novamente o comando RSYNC.
Não se preocupe em executar o RSYNC uma segunda ou terceira vez, pois os arquivos não serão copiados novamente. A execução de várias sessões é uma prática comum quando o RSYNC é utilizado. A ferramenta RSYNC possui um recurso de verificação entre caminho origem e destino. Os arquivos somente são copiados novamente se algum atributo for alterado, como permissão, proprietário, grupos, tamanho e conteúdo. Se alguma dessas situações ocorrer, o próprio RSYNC copia o arquivo ou diretório novamente. Caso contrário, nenhuma nova transferência é feita, apenas a verificação de integridade entre origem e destino;
9- Conforme explicado anteriormente, quando o mesmo arquivo já existe na origem e no destino, o mecanismo de verificação de integridade do RSYNC por padrão se baseia em Metadados (permissionamento, atributos e tamanho) do arquivo para entender se alguns desses itens foram alterados e se é necessário copiar novamente o arquivo. O utilitário RSYNC possui uma opção “-c” que troca esse método de validação de consistência por uma verificação de consistência baseada no Checksum do conteúdo do arquivo. Nesse caso, não só as informações de Metadados são comparadas entre origem e destino para decidir se um dado arquivo será copiado, mas também o conteúdo do arquivo em si.
As operações de verificação de integridade baseadas em Checksum devem ser utilizadas com cautela, pois demoram mais e consomem mais CPU. Isto ocorre porque além dos Metadados, o conteúdo do arquivo também precisa ser verificado;
10- Após o término do processo, efetue a desmontagem do File System antigo e monte o novo device utilizando o Mount Point anterior. Também vale ressaltar que talvez seja necessário um ajuste no arquivo /etc/fstab que mantém a relação dos File Systems que são montados automaticamente em momento do Boot do sistema operacional, refletindo a alteração entre o device antigo (/dev/sdb1) e o novo (/dev/sdc1).
Desse ponto em diante, os dados foram migrados com sucesso e já pode dar início à fase de validação do processo de migração dos dados.
Listagem 3. Sequência de comandos para migração do host RJOSRVUXX03.
########## Trecho 1 ##########
sysadmin@rjosrvuuxx03:~$ sudo lsscsi --size
[0:0:0:0] disk ATA VBOX HARDDISK 1.0 /dev/sda 8.58GB
[1:0:0:0] disk ATA VBOX HARDDISK 1.0 /dev/sdb 85.8GB
[2:0:0:0] disk ATA VBOX HARDDISK 1.0 /dev/sdc 85.8GB
########## Trecho 2 ##########
sysadmin@rjosrvuuxx03:~$ sudo fdisk /dev/sdc
Command (m for help): n
Partition type:
p primary (0 primary, 0 extended, 4 free)
e extended
Select (default p): p
Partition number (1-4, default 1): 1
First sector (2048-167772159, default 2048): <enter>
Using default value 2048
Last sector, +sectors or +size{K,M,G} (2048-167772159, default 167772159): <enter>
Using default value 167772159
Command (m for help): t
Selected partition 1
Hex code (type L to list codes): 83
Command (m for help): w
The partition table has been altered!
Calling ioctl() to re-read partition table.
Syncing disks.
########## Trecho 3 ##########
sysadmin@rjosrvuuxx03:~$ sudo mkfs.ext3 /dev/sdc1
########## Trecho 4 ##########
$ sysadmin@rjosrvuuxx03:~$ sudo mount -t ext3 /dev/sdc1 /srv/new_monitor
########## Trecho 5 ##########
sysadmin@rjosrvuuxx03:~$ df -h | tail -2
/dev/sdb1 79G 40G 39G 50% /srv/monitor
/dev/sdc1 79G 184M 75G 1% /srv/new_monitor
########## Trecho 6 ##########
sysadmin@rjosrvuuxx03:~$ sudo rsync -axvH /srv/monitor/ /srv/new_monitor/
########## Trecho 7 ##########
sysadmin@rjosrvuuxx03:$ cd /srv/monitor
sysadmin@rjosrvuuxx03:$ sudo tar xf - . | ( cd /srv/new_monitor ; tar xf - )
########## Trecho 8 ##########
sysadmin@rjosrvuuxx03:~$ sudo rsync -axvH /srv/monitor/ /srv/new_monitor/
sending incremental file list
sent 22256 bytes received 202 bytes 44916.00 bytes/sec
total size is 47329209 speedup is 2107.45
########## Trecho 9 ##########
sysadmin@rjosrvuuxx03:~$ sudo rsync -acxvH /srv/monitor/ /srv/new_monitor/
########## Trecho 10 ##########
sysadmin@rjosrvuuxx03:~$ sudo umount /srv/monitor
sysadmin@rjosrvuuxx03:~$ sudo umount /srv/new_monitor
sysadmin@rjosrvuuxx03:~$ sudo mount /dev/sdc1 /srv/monitorValidação da Migração
Não menos importante que o processo de migração dos dados em si é o processo de validação da migração, que normalmente consiste em testes para evidenciar que o ambiente ou sistema encontra-se ok com todos os dados íntegros depois da movimentação dos dados.
Um processo adequado de validação da migração dos dados consiste em execuções de tarefas e rotinas da aplicação que utilizem de alguma forma os dados que foram migrados. Uma simples inicialização da aplicação em muitos casos não se mostra um procedimento adequado de validação, pois nem toda aplicação valida a integridade de seus dados no momento da inicialização.
Certas aplicações como bancos de dados voltados ao mercado Enterprise possuem mecanismos de consistência de dados baseados em checksum ou em consistência de blocos, de forma que um start com sucesso já pode ser suficiente em alguns casos para validar a migração dos dados. Existem outras aplicações, por sua vez, que só validam os dados mediante um acesso formal que resulte no I/O nos blocos que foram migrados. Às vezes é necessário realizar consultas, gerar relatórios ou fazer requisições específicas que validem referências de índices, estruturas de dados e algum ponto específico do sistema em questão.
Mesmo nos casos de sucesso do start da aplicação ou na validação adequada de consistência, ainda é importante validar aspectos de desempenho como tempo de resposta dos novos discos/LUNs e como esse reflete na aplicação. Não são raros casos em que um ambiente é migrado e validado na janela de manutenção, porém, quando a aplicação entra em janela produtiva e recebe a carga cotidiana de seus milhões de acessos, o ambiente se comporta mal nos novos discos ou Storage e pode não haver mais tempo hábil para uma análise mais apurada e definitiva que não resulte em impacto aos negócios.
Existem casos em que o cliente adquire um modelo de Storage novo, podendo ser de outro fabricante, outra formatação física, bem como outro algoritmo de gerência dos discos, mecanismos de cache, entre outros, de forma que a performance final pode ser muito diferente da normalmente vivenciada no hardware antigo. É normal haver configurações específicas relacionadas a SAN, FC, SCSI, iSCSI e FCOE, que podem não estar com valores adequados para trabalhar com o novo equipamento, resultando em baixo desempenho ou desempenho insatisfatório.
Por isso é importante estabelecer testes apropriados de validação que ao menos simulem a quantidade ou o volume de acessos próximo do real, de modo que reflitam em informações consistentes de desempenho que possam atestar e evidenciar realmente o sucesso da migração de dados do ponto de vista de consistência e velocidade de acesso.
Adicionalmente, sempre considere a possibilidade de Rollback. Normalmente é muito comum ninguém se preocupar com isso durante o planejamento ou a definição da duração da janela adequada de manutenção. A consequência disso pode ser desastrosa quando o tempo necessário para Rollback não é incluído na janela de manutenção. Rollback não significa “incompetência” ou “não saber fazer”, como muitos consideram. Às vezes problemas não esperados ocorrem como desempenho não satisfatório ou bugs.
A estratégia de Split Mirror do LVM mostra-se muito interessante nesse aspecto. É possível ainda manter os volumes espelhados por um período definido, configurando qual lado do mirror vai responder preferencialmente aos I/Os. Assim, é possível manter os dados sincronizados e somente realizar o split quando houver certeza absoluta de que tudo se encontra conforme esperado e quando o resultado final for satisfatório.
Clean-Up do ambiente
Mediante confirmação do sucesso da migração e validação adequada dos dados migrados, chegou o momento de Clean-up do ambiente.
Em alguns casos, os dados residiam em um Storage que será desativado e necessita ter os discos/LUNs removidos do servidor. Nesse caso, além da remoção dos discos do host, algumas etapas como remoção do ZONE na SAN (Storage Area Network) e remoção de Masking e Mapping no subsistema Storage também devem ser executados.
Em outros casos, quando os Mount Points sofrem alteração, alguns outros sistemas adjacentes no Datacenter como Monitoramento, Backup, automação, entre outros, devem ser acionados ou sinalizados da alteração que ocorreu. Também é muito comum que esse ponto seja esquecido ou não considerado no planejamento, gerando problemas para outra equipe que não aquela que realizou a manutenção no ambiente. Imagine as políticas de Backup que se baseiam em Mount Points. Caso esse Mount Point mude, o Job de Backup irá falhar. Caso a equipe que realizou a migração não seja a mesma que mantenha o ambiente de backup, a causa raiz do problema não estará clara e será desperdiçado um esforço desnecessário para resolução do problema.
Outra necessidade de alteração dos controles internos de uma equipe ocorre quando o Mount Point de um determinado File System é alterado na migração. Vale lembrar que ferramentas de monitoramento como o Nagios e OpenView podem conter scripts que se baseiam no Mount Point para monitorar o File System. Nesse caso também é necessário realizar alterações nessas ferramentas.
Outro ponto que é impactado durante os processos de migração de dados são os Frameworks de alta disponibilidade. É comum a existência de Clusters que mantêm em sua configuração o caminho absoluto dos device files (/dev/sda) que referenciam as LUNs que estão sendo migradas. Sendo assim, estes também requerem adequações em suas configurações. Caso o administrador não realize as alterações de Mount Point ou caminho dos discos nas configurações do Cluster, haverá problemas para iniciar a aplicação depois de realizar a migração dos dados.
As políticas de backup também costumam ser impactadas e devem ser reconfiguradas refletindo as alterações ocorridas no processo de migração. Existem soluções de Backup que utilizam o caminho dos RAW devices (/dev/raw3), por exemplo, e são sensíveis a migrações de dados que alterem o PATH de acesso ao dispositivo.
Também é comum encontrar aplicações web em ambientes Datacenter que tenham interfaces externas como áreas de upload destinadas a receber arquivos de outros clientes ou outras aplicações. É natural que essas aplicações tenham atributos ou parâmetros de configuração que se baseiem em algum File System ou Mount Point. Quando o Mount Point é alterado durante a migração de dados é fundamental incluir no planejamento da migração a reconfiguração desse atributo ou parâmetro refletindo as mudanças. Caso não seja realizado, clientes externos ou aplicações dependentes serão afetadas gerando um impacto negativo aos negócios.
Outro ponto pouco lembrado nas migrações de dados é a adequação das documentações de controle depois da migração ser concluída. Em centros computacionais de grande porte, existem diversas equipes e colaboradores que mantêm vasta documentação do ambiente gerenciado através de planilhas relacionando endereços IP, nomes de servidores, aplicações, caminhos de arquivos, entre outros. Equipes como a de suporte a Bancos de Dados, suporte a Servidores e Sistemas Operacionais, suporte a Infraestrutura de Network e suporte a ambientes WEB mantêm esses dados que vão se tornando obsoletos com o passar dos anos e podem dificultar a gestão ou manutenção do ambiente, contrariando seu propósito. Portanto, é muito importante para a gestão de TI que essas informações sejam alteradas e mantidas corretamente a cada migração, permitindo que todos os controles estejam sempre bem documentados.
Conclusão
Esse artigo procurou compartilhar com os leitores a abrangência de um processo que envolve movimentação de dados corporativos, abordando algumas estratégias e metodologias que podem ser empregadas para planejamento de atividades de migração em diversos ambientes de TI que disponham de sistemas operacionais Linux.
As técnicas apresentadas nesse artigo poderão ser empregadas em seu ambiente de TI, melhorando o processo atual ou servindo de parâmetro para implementação de um novo processo de mudanças que envolvem tarefas de migração de dados.
A primeira parte deste artigo, apresentada na edição anterior da Infra Magazine, procurou abordar aspectos conceituais com propósitos de planejamento do processo de migração de dados corporativos. Adicionalmente, na primeira parte, todo o ambiente utilizado em nossos testes foi mapeado por meio da execução de comandos específicos nos três servidores propostos.
Já a segunda parte do artigo, objeto desta edição, procurou compartilhar com os leitores os procedimentos técnicos utilizados para realizar a migração de dados em si. As estratégias foram traçadas baseadas em metodologias de mercado respeitando as diretrizes operacionais do negócio. Para escolher qual estratégia utilizar para movimentar os dados, cada um dos três servidores passou por um processo de análise considerando a condição em que o dado encontrava-se hospedado. Neste cenário, para melhor didática e compreensão dos leitores, procuramos abordar técnicas para movimentar os dados utilizando estratégias de LVM ou empregando ferramentas nativas do sistema operacional Linux como RSYNC ou TAR, presentes em qualquer servidor de ambiente Datacenter.
O foco desse artigo foi discutir e apresentar estratégias de migrações de dados por meio do sistema operacional Linux ou gerenciador de volumes LVM. No entanto, existem inúmeras outras técnicas e modalidades que também podem ser empregadas para migrar dados, como estratégias RAID, manobras com File Systems NFS, produtos específicos oferecidos por fabricantes de Storages, Appliances, estratégias LVM adicionais, entre outras.
