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
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.
Nenhum comentário:
Postar um comentário