Mostrando postagens com marcador lvm2. Mostrar todas as postagens
Mostrando postagens com marcador lvm2. Mostrar todas as postagens

quinta-feira, 5 de abril de 2012

LVM2 em servidores: obrigatório!



Particionar um disco, formatar uma partição e acessar seu sistema de arquivos é a forma mais rápida de utilizar o armazenamento em qualquer computador, seja ele um laptop, desktop ou servidor. No entanto, para qualquer tarefa que envolva o deslocamento desse sistema de arquivos ou dessa partição, será obrigatório parar o disco rígido e interromper todos os serviços que dependam dele. Para evitar isso existe o LVM2, e eu proponho fortemente que você o use sempre.

Já faz vários anos desde que o LVM2 começou a ser usado no Linux. Desenvolvido pela empresa britânica Sistina Software — a mesma que desenvolveu o sistema de arquivos para clusters GFS e depois foi adquirida pelaRed Hat— o LVM foi integrado ao kernel Linux desde o princípio. No kernel 2.4, ele foi implementado em sua encarnação LVM1. O LVM1 residia inteiramente no kernel e dependia de alguns programas de espaço de usuário para o gerenciamento.

O kernel 2.6 recebeu a excelente adição do device mapper, um subsistema capaz de abstrair trechos de qualquer dispositivo de armazenamento e representá-los em dispositivos virtuais (geralmente localizados sob /dev/mapper/). O LVM2, nova implementação que surgiu no espaço de usuário, emprega unicamente o device mapper para criar, gerenciar e apagar volumes LVM.

O mesmo device mapper é usado para implementar o recurso de multipath de dispositivos de armazenamento em sistemas Linux, o que confirma sua versatilidade.

As ferramentas do LVM2, portanto, funcionam unicamente como interface para interagirmos com o subsistema device mapper. Outra forma de interagir com o device mapper é por meio do comando   [dmsetup http://docs.redhat.com/docs/pt-BR/Red_Hat_Enterprise_Linux/6/html/Logical_Volume_Manager_Administration/dmsetup.html] , mas isto requer uma maior intimidade com essa ferramenta e vai muito além do uso do LVM2.

Resistência
Mesmo com suas diversas vantagens e facilidades de gerenciamento, no entanto, o LVM2 ainda encontra resistência entre alguns administradores. "Aumenta a complexidade", já ouvi alguns dizerem, ou "diminui o desempenho do disco". Eu mesmo já tive "medo do LVM2" durante algum tempo, até me familiarizar melhor com ele.

Segundo medições abrangentes, a perda de desempenho causada pelo emprego do LVM2, em comparação com a escrita direta no disco rígido, é de 10%. No entanto, medições mais recentes apontam para um ganho de desempenho ao usar LVM2 em sistemas Fedora. Segundo os autores dos benchmarks, esta diferença a favor do LVM2 deve ter sua causa na inativação das write barriers pelo LVM2nessa distribuição — algo que compromete potencialmente a confiabilidade dos dados armazenados nesses volumes.

Independentemente da velocidade de leitura ou gravação, algumas tarefas com LVM2 se tornam tão mais rápidas e fáceis, com frequentes vantagens operacionais, que o saldo é visivelmente positivo.
Vejamos alguns exemplos de casos em que o uso do LVM2 cai como uma luva.

Cenário 1: Migração de dispositivo
Digamos que você precise migrar os dados armazenados no seu servidor de um disco para outro. Para dar nomes, você deseja transferir tudo de sda5 para sdb2, por exemplo. E a aplicação afetada por isso é o Apache, que usa esse sistema de arquivos (um ext4) para abrigar seu document root.
Sem LVM2, você precisará parar a aplicação (o Apache) que utiliza esses dados, formatar o novo sistema de arquivos ( sdb2 ) transferir os dados do sistema de arquivos original ( sda5 ) para o  sdb2 (via  rsync ,  dd ou qualquer outro utilitário que você desejar), desmontar o sistema de arquivos  /dev/sda5  onde eles estão armazenados, acrescentar ao /etc/fstab  o registro do novo sistema de arquivos e retirar dele o registro do antigo.

Com LVM2, basta você formatar sdb2  como volume físico ( pvcreate /dev/sdb2 ), adicioná-lo ao grupo de volumes já existente ( vgextend nome_do_vg /dev/sdb2 ) e migrar os extents de  sda5  para  sdb2  ( pvmove /dev/sda5 /dev/sdb2 ). Seu Apache não precisa sair do ar — ele nem sequer vai perceber que os dados estão "em trânsito" de um disco para outro. Ao final do processo, basta retirar o disco antigo do grupo de volumes ( vgreduce nome_do_vg /dev/sda5 ). Nada de alterar o fstab, parar aplicação, desmontar sistema de arquivos etc. Muito mais simples.

Cenário 2: Crescimento de sistema de arquivos em disco com espaço disponível
Digamos que seu servidor de e-mail precise de mais espaço para armazenar as caixas de mensagem. Como o número de mensagens armazenadas sempre tende a crescer indefinidamente, servidores de e-mail são uma vítima comum deste tipo de problema.

Sem LVM2, você precisará desmontar o sistema de arquivos que abriga os e-mails, editar a tabela de partições do disco rígido onde ele reside (um risco sempre muito grande), remontar o sistema de arquivos e estendê-lo ( resize2fs , no caso do ext2/3/4).

Com LVM2, você talvez ainda tenha espaço no seu VG (grupo de volumes) para aumentar o LV (volume lógico) que abriga os e-mails. Se esse for o caso, basta estender o LV ( lvextend ) e depois estender o sistema de arquivos residente nele ( resize2fs ). Nada de parar o servidor de e-mails, nada de manipular a tabela de partições, nada de desmontar sistemas de arquivos. Tudo é feito sem parar o serviço.

Ainda com LVM2, se o VG que abriga seu LV estiver esgotado, você pode simplesmente usar outro PV (do mesmo disco ou de outro) para estender esse VG ( vgextend ) e em seguida estender o LV ( lvextend ) e seu sistema de arquivos ( resize2fs ). Novamente, nada de parar o serviço, desmontar o sistema de arquivos ou redimensionar partições. Talvez você ainda precise editar a tabela de partições do disco caso precise criar uma nova partição para agir como PV (volume físico) ou alterar o tipo de uma partição já existente (para 8e, o tipo Linux LVM2).

Cenário 3: Backup de um serviço com dados muito dinâmicos
Imagine que o seu servidor de e-mail tenha tráfego intenso: centenas de mensagens por minuto. Você precisa fazer backup das mensagens armazenadas no servidor, mas é muito problemático efetuar isso com o serviço em execução, já que as mensagens em constante alteração se tornam um "alvo móvel".

Sem LVM2, você teria que interromper o recebimento de mensagens — ou, se preferir, parar o servidor de e-mail completamente — e realizar o backup. Em seguida, você restauraria o funcionamento do servidor e as mensagens voltariam a circular normalmente.

Com LVM2, adivinhe: nada de parar o servidor de e-mail nem de interromper o recebimento das mensagens. Bastaria você criar um snapshot do LV que abriga as mensagens, realizar o backup apontando a origem como o snapshot (que é estático) e, ao final, destruir o snapshot sem cerimônia. Mais uma vez, o serviço permaneceu no ar sem sequer perceber que algo estava sendo feito com suas mensagens.
Adoção

Sem surpresa nenhuma, volumes LVM2 já são usados por padrão em várias distribuições GNU/Linux. No Fedora, por exemplo, o esquema automático de particionamento durante a instalação já põe até mesmo o sistema de arquivos raiz sobre um volume lógico LVM2.

Conclusão
O LVM2 oferece vantagens significativas no gerenciamento de storage. Desde o planejamento inicial dos volumes — é possível criar e redimensionar volumes a qualquer momento — até todos os tipos de manipulação que se desejar, o LVM2 é um ótimo recurso para servidores e até para alguns desktops e laptops.

 Artigo de Pablo Hess - phess@redhat.com, gentilmente cedido para nosso blog.