RAID e LVM são duas técnicas para abstrair os volumes montados a partir de seus equivalentes físicos (reais unidades de disco rígido ou partições do mesmo), o primeiro protege os dados de falhas no hardware através da introdução de redundância, o último torna o gerenciamento de volumes mais flexível e independente do tamanho real nos discos. Em ambos os casos, o sistema acaba com novos volumes (partições, blocos), que podem ser usados para criar sistemas de arquivos ou espaço de troca, sem necessariamente ter eles mapeados em um disco físico. LVM e RAID vêm de origens bem diferentes, mas sua funcionalidade pode sobrepor-se um pouco, é por isso que eles são muitas vezes mencionados juntos.
Em ambos os casos RAID e LVM, o kernel fornece um arquivo de dispositivo de bloco semelhantes aos que correspondem a uma unidade de disco rígido ou partição. Quando um pedido ou uma outra parte do núcleo, requer o acesso a um bloco de um tal dispositivo, as rotas de subsistemas apropriadas do bloco são usadas para a camada física relevante. Dependendo da configuração, este bloco pode ser armazenado em um ou vários discos físicos e sua localização física pode não ser directamente relacionada com a localização do bloco no dispositivo lógico.
12.1.1. RAID Por Software
RAID significa Redundant Array of Independent Disks - conjunto redundante de discos independentes. O objetivo deste sistema é evitar perda de dados em caso de falha do disco rígido. O princípio geral é bastante simples: os dados são armazenados em vários discos físicos em vez de apenas um, com um nível configurável de redundância. Dependendo desta quantidade de redundância, e mesmo no caso de uma falha de disco inesperado, dados podem ser reconstruídos sem perdas dos restantes discos.
O RAID pode ser implementado tanto por hardware dedicado (módulos RAID integrados em placas controladoras SCSI ou SATA) ou por abstração de software (o núcleo). Seja por hardware ou software, um sistema RAID com redundância suficiente pode, de forma transparente, continuar operacional quando um disco falha; as camadas superiores da pilha (aplicações) podem até manter o acesso aos dados apesar da falha. Claro que, esse “modo degradado” pode ter impacto na performance, e a redundância é reduzida, então uma falha profunda do disco pode levar a perda de dados. Na prática, entretanto, um irá se esforçar para apenas ficar nesse modo degradado o tempo que for necessário para que se possa substituir o disco falho. Uma vez que o novo disco seja colocado, o sistema RAID pode reconstruir os dados necessários e então retornar ao modo seguro. As aplicações não notarão nada, fora a potencial redução da velocidade de acesso, enquanto a array estiver no modo degradado ou durante a fase de reconstrução.
Quando o RAID é implementado por hardware, sua configuração geralmente acontece dentro da ferramenta de configuração da BIOS, e o núcleo irá considerar uma array RAID como um único disco, que irá funcionar como um disco físico padrão, embora o nome do dispositivo possa ser diferente (dependendo do driver).
Nós apenas focamos em RAID de software neste livro.
12.1.1.1. Diferentes Níveis de RAID
RAID não é na verdade um único sistema, mas vários sistemas identificados por seus níveis; os níveis diferem por sua disposição e quantidade de redundância que eles fornecem. Quanto mais redundante, mais à prova de falhas, uma vez que o sistema será capaz de continuar a trabalhar quando mais discos falharem. A contrapartida é que reduz o espaço utilizável para um dado conjunto de discos; visto de outra forma, mais discos serão necessários para armazenar a mesma quantidade de dados.
- RAID Linear
Mesmo o que o subsistema de RAID do núcleo permita a criação de um “RAID linear”, isso não é um RAID propriamente, já que essa configuração não envolve qualquer redundância. O núcleo apenas agrega vários discos fim-a-fim e provê o volume agregado resultante como um disco virtual (um dispositivo de bloco). Essa é sua única função. Essa configuração raramente é usada por ela própria (veja mais adiante sobre as exceções), especialmente porque a falta de redundância significa que a falha de um disco faz com que todo o agregado, e portanto todos os dados, fiquem indisponíveis.
- RAID-0
Esse nível também não provê nenhuma redundância, mas os discos não são simplesmente ligados pelo final um após o outro: eles são divididos em listras (stripes), e os blocos no dispositivo virtual são armazenados em listras (stripes) em discos físicos alternados. Em uma configuração de RAID-0 de dois discos, por exemplo, em blocos de número par do dispositivo virtual serão armazenados no primeiro disco físico, enquanto os blocos ímpares ficarão no segundo disco físico.
Esse sistema não tem por objetivo um aumento de credibilidade, já que (como em um caso linear) a disponibilidade de todos os dados é comprometida assim que um disco falhar, mas um aumento de desempenho: durante um acesso sequencial a grandes quantidades de dados contíguos, o núcleo será capaz de ler a partir dos dois discos (ou escrever neles) em paralelo, o que incrementa a taxa de transferência de dados. Contudo, o uso do RAID-0 está murchando, seu nicho está sendo preenchido pelo LVM (veja mais adiante).
- RAID-1
Esse nível, também conhecido como “espelhamento RAID”, é tanto o mais simples quanto a mais amplamente usada configuração. Em sua forma padrão, ele usa dois discos físicos de mesmo tamanho e fornece um volume lógico de mesmo tamanho mais uma vez. Os dados são armazenados identicamente nos dois discos, por isso o apelido “espelho”. Quando um disco falha, os dados ainda estão disponíveis no outro. Para dados realmente críticos, RAID-1 pode, é claro, ser configurado para mais de dois discos, com impacto direto na relação de custo de hardware versus espaço de carga disponível.
Esse nível de RAID, embora caro (já que apenas metade do espaço físico de armazenagem, na melhor das hipóteses, é útil), é amplamente usado na prática. Ele é simples de entender, e ele permite cópias de segurança (backups) bem simples: como os dois discos tem conteúdos idênticos, um deles pode ser temporariamente extraído, sem impacto no sistema em funcionamento. O desempenho de leitura geralmente é incrementado , já que o núcleo pode ler metade dos dados em cada disco, em paralelo, enquanto o desempenho de escrita não é muito severamente degradado. No caso de uma array RAID-1 de N discos, os dados continuam disponíveis mesmo com a falha do disco N-1.
- RAID-4
Esse nível de RAID, não amplamente usado, usa N discos para armazenar dados úteis, e um disco extra para armazenar informação redundante. Se esse disco falhar, o sistema pode reconstruir seu conteúdo a partir do outro N. Se um dos N discos de dados falhar, O N-1 remanescente combinado com o disco “paridade” contém informação suficiente para reconstruir os dados requeridos.
RAID-4 não é muito caro já que ele apenas envolve um incremento de um-em-N nos custos e não se tem impacto perceptível no desempenho de leitura, mas a escrita é mais devagar. Além disso, como uma escrita em qualquer um dos N discos também envolve a escrita no disco de paridade, esse último tem muito mais escritas que o anterior, e sua vida útil pode ser dramaticamente diminuída como consequência. Os dados na array RAID-4 só está segura até um disco falhar (dos N+1).
- RAID-5
RAID-5 resolve o problema de assimetria do RAID-4: a paridade de blocos é distribuída por todos os N+1 discos, sendo que nenhum tem um papel particular.
A performance de leitura e escrita são idênticas ao RAID-4. Aqui novamente, o sistema continua funcional mesmo com a falha de um disco (do N+1), mas não mais.
- RAID-6
RAID-6 pode ser considerado uma extensão do RAID-5, onde cada série de N blocos envolvem dois blocos redundantes, e cada série de N+2 blocos e distribuída sobre N+2 discos.
Esse nível de RAID é levemente mais caro que os dois anteriores, mas ele traz alguma segurança extra já que até dois drives (dos N+2) podem falhar sem comprometer a disponibilidade dos dados. A contraparte é que as operações de escrita agora envolvem escrever um bloco de dados e dois blocos de redundância, o que os torna ainda mais lento.
- RAID-1+0
Isso não é, estritamente falando, um nível RAID, mas um empilhamento de dois agrupamentos RAID. A partir de 2×N discos, primeiro se configura eles por pares em volumes N RAID-1; esses volumes N são então agregados em um só, seja por “linear RAID” ou (cada vez mais) por LVM. Esse último caso vai além do puro RAID, mas não existe problema quanto a isso.
RAID-1+0 pode sobreviver com múltiplas falhas nos discos: até N na 2xN série descrita acima, provendo ao menos um disco funcional em cada par de RAID-1.
Obviamente, o nível de RAID será escolhido de acordo com as restrições e requerimentos de cada aplicação. Note que um computador sozinho pode ter diversos tipos de RAIDs distintos com diversas configurações.
12.1.1.2. Configurando um RAID
Configurar volumes RAID requer o pacote mdadm; ele provê o comando mdadm, que permite a criação e maipulação de arrays RAID, assim como scripts e ferramentas para integração com o resto do sistema, incluindo o sistema de monitoração.
Nossos exemplo será um servidor com um número de discos, sendo que alguns já estão em uso, e o resto está disponível para a configuração do RAID. Nós inicialmente temos os seguintes discos e partições:
o disco sdb, 4 GB, está completamente disponível;
o disco sdc, 4 GB, também está completamente disponível;
no disco sdd, somente a partição sdd2 (cerca de 4 GB) está disponível;
finalmente, um disco sde, ainda com 4 GB, disponível.
Iremos usar estes elementos físicos para criar dois volumes, um RAID-0 e um espelho (RAID-1). Comecemos com o volume RAID-0:
# mdadm --create /dev/md0 --level=0 --raid-devices=2 /dev/sdb /dev/sdc
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md0 started.
# mdadm --query /dev/md0
/dev/md0: 8.00GiB raid0 2 devices, 0 spares. Use mdadm --detail for more detail.
# mdadm --detail /dev/md0
/dev/md0:
Version : 1.2
Creation Time : Wed May 6 09:24:34 2015
Raid Level : raid0
Array Size : 8387584 (8.00 GiB 8.59 GB)
Raid Devices : 2
Total Devices : 2
Persistence : Superblock is persistent
Update Time : Wed May 6 09:24:34 2015
State : clean
Active Devices : 2
Working Devices : 2
Failed Devices : 0
Spare Devices : 0
Chunk Size : 512K
Name : mirwiz:0 (local to host mirwiz)
UUID : bb085b35:28e821bd:20d697c9:650152bb
Events : 0
Number Major Minor RaidDevice State
0 8 16 0 active sync /dev/sdb
1 8 32 1 active sync /dev/sdc
# mkfs.ext4 /dev/md0
mke2fs 1.42.12 (29-Aug-2014)
Creating filesystem with 2095104 4k blocks and 524288 inodes
Filesystem UUID: fff08295-bede-41a9-9c6a-8c7580e520a6
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632
Allocating group tables: done
Writing inode tables: done
Creating journal (32768 blocks): done
Writing superblocks and filesystem accounting information: done
# mkdir /srv/raid-0
# mount /dev/md0 /srv/raid-0
# df -h /srv/raid-0
Filesystem Size Used Avail Use% Mounted on
/dev/md0 7.9G 18M 7.4G 1% /srv/raid-0
O comando mdadm --create requer vários parâmetros: o nome do volume a ser criado (/dev/md*, com MD significando Multiple Device), o nível RAID, o número de discos (que é obrigatório, apesar de ser significante apenas com RAID-1 e acima), e os drives físicos a usar. Uma vez que o dispositivo seja criado, nós podemos usá-lo como usamos uma partição normal, criando um sistema de arquivos nela, montando esse sistema de arquivos, e assim por diante. Note que nossa criação de um volume RAID-0 em md0 não passa de coincidência, e a numeração da array não precisa ser correlacionada com a quantidade escolhida de redundância. Também é possível criar arrays RAID nomeadas, dando ao mdadm parâmetros como /dev/md/linear ao invés de /dev/md0.
A criação do RAID-1 segue estilo similar, as diferenças somente serão notadas após a criação:
# mdadm --create /dev/md1 --level=1 --raid-devices=2 /dev/sdd2 /dev/sde
mdadm: Note: this array has metadata at the start and
may not be suitable as a boot device. If you plan to
store '/boot' on this device please ensure that
your boot-loader understands md/v1.x metadata, or use
--metadata=0.90
mdadm: largest drive (/dev/sdd2) exceeds size (4192192K) by more than 1%
Continue creating array? y
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md1 started.
# mdadm --query /dev/md1
/dev/md1: 4.00GiB raid1 2 devices, 0 spares. Use mdadm --detail for more detail.
# mdadm --detail /dev/md1
/dev/md1:
Version : 1.2
Creation Time : Wed May 6 09:30:19 2015
Raid Level : raid1
Array Size : 4192192 (4.00 GiB 4.29 GB)
Used Dev Size : 4192192 (4.00 GiB 4.29 GB)
Raid Devices : 2
Total Devices : 2
Persistence : Superblock is persistent
Update Time : Wed May 6 09:30:40 2015
State : clean, resyncing (PENDING)
Active Devices : 2
Working Devices : 2
Failed Devices : 0
Spare Devices : 0
Name : mirwiz:1 (local to host mirwiz)
UUID : 6ec558ca:0c2c04a0:19bca283:95f67464
Events : 0
Number Major Minor RaidDevice State
0 8 50 0 active sync /dev/sdd2
1 8 64 1 active sync /dev/sde
# mdadm --detail /dev/md1
/dev/md1:
[...]
State : clean
[...]
Algumas observações em ordem. Primeiro, mdadm nota que os elementos físicos possuem tamanhos diferentes; já que isso implica que algum espaço será perdido no maior elemento, uma confirmação é necessária.
Ainda mais importante, note o estado do espelhamento.O estado normal de um espelho RAID é que os dois discos tenham exatamente o mesmo conteúdo. Contudo, nada garante que esse é o caso quando o volume é criado pela primeira vez. O subsistema RAID irá, por conseguinte, prover essa garantia por si mesmo, e acontecerá uma fase de sincronização assim que o dispositivo RAID for criado. Após algum tempo (a quantidade exata irá depender do real tamanho dos discos…), a array RAID alternará para o estado “ativo” ou "limpo". Note que durante essa fase de reconstrução, o espelho está em modo degradado, e a redundância não é garantida. Um disco falhando durante essa janela de risco poderia levar a perda de todos os dados. Grandes quantidades de dados críticos, contudo, raramente são armazenados em uma array RAID recentemente criada, antes de sua sincronização inicial. Note que mesmo em modo degradado, o /dev/md1 é usável, e um sistema de arquivos pode ser criado nele, assim como alguns dados podem ser copiados para ele.
Agora vamos ver o que acontece quando um dos elementos da array RAID-1 falha. O mdadm, em particular sua opção --fail, permite simular uma falha de disco desse tipo:
# mdadm /dev/md1 --fail /dev/sde
mdadm: set /dev/sde faulty in /dev/md1
# mdadm --detail /dev/md1
/dev/md1:
[...]
Update Time : Wed May 6 09:39:39 2015
State : clean, degraded
Active Devices : 1
Working Devices : 1
Failed Devices : 1
Spare Devices : 0
Name : mirwiz:1 (local to host mirwiz)
UUID : 6ec558ca:0c2c04a0:19bca283:95f67464
Events : 19
Number Major Minor RaidDevice State
0 8 50 0 active sync /dev/sdd2
2 0 0 2 removed
1 8 64 - faulty /dev/sde
O conteúdo do volume ainda está acessível (e, se montado, as aplicações não notarão nada), mas a segurança dos dados não é mais garantida: se, por sua vez, o disco sdd falhar, os dados serão perdidos. Nós queremos evitar esse risco, então nós vamos substituir o disco falho por um novo, sdf:
# mdadm /dev/md1 --add /dev/sdf
mdadm: added /dev/sdf
# mdadm --detail /dev/md1
/dev/md1:
[...]
Raid Devices : 2
Total Devices : 3
Persistence : Superblock is persistent
Update Time : Wed May 6 09:48:49 2015
State : clean, degraded, recovering
Active Devices : 1
Working Devices : 2
Failed Devices : 1
Spare Devices : 1
Rebuild Status : 28% complete
Name : mirwiz:1 (local to host mirwiz)
UUID : 6ec558ca:0c2c04a0:19bca283:95f67464
Events : 26
Number Major Minor RaidDevice State
0 8 50 0 active sync /dev/sdd2
2 8 80 1 spare rebuilding /dev/sdf
1 8 64 - faulty /dev/sde
# [...]
[...]
# mdadm --detail /dev/md1
/dev/md1:
[...]
Update Time : Wed May 6 09:49:08 2015
State : clean
Active Devices : 2
Working Devices : 2
Failed Devices : 1
Spare Devices : 0
Name : mirwiz:1 (local to host mirwiz)
UUID : 6ec558ca:0c2c04a0:19bca283:95f67464
Events : 41
Number Major Minor RaidDevice State
0 8 50 0 active sync /dev/sdd2
2 8 80 1 active sync /dev/sdf
1 8 64 - faulty /dev/sde
Aqui, mais uma vez, o núcleo automaticamente dispara uma fase de reconstrução, durante a qual o volume, embora ainda acessível, está em um modo degradado. Uma vez que a reconstrução esteja terminada, a array RAID está de volta ao estado normal. Pode-se então dizer ao sistema que o disco sde está para ser removido da array, para que se possa terminar com um espelhamento RAID clássico nos dois discos:
# mdadm /dev/md1 --remove /dev/sde
mdadm: hot removed /dev/sde from /dev/md1
# mdadm --detail /dev/md1
/dev/md1:
[...]
Number Major Minor RaidDevice State
0 8 50 0 active sync /dev/sdd2
2 8 80 1 active sync /dev/sdf
A partir de então, a unidade pode ser fisicamente removida quando o servidor está para ser desligado, ou até mesmo removida com o sistema ligado (hot-removed) quando a configuração de hardware permite tal operação (hot-swap). Tais configurações incluem alguns controladores SCSI, a maioria dos discos SATA e unidades externas que operam com USB ou Firewire.
12.1.1.3. Fazendo Backup da Configuração
A maioria dos meta-dados referentes a volumes RAID são salvos diretamente nos discos que compoem essas arrays, para que o núcleo possa detectar as arrays e seus componentes e montá-los automaticamente quando o sistema for iniciado. Contudo, é encorajado o uso de cópia de segurança dessa configuração, porque essa detecção não é à prova de falhas, e só se tem a expectativa de falha dela precisamente em circunstâncias sensíveis. Em nosso exemplo, se a falha do disco sde tivesse sido real (ao invés de simulada) e o sistema tivesse sido reiniciado sem a remoção desse disco sde, esse disco poderia começar a trabalhar novamente por ter sido verificado durante a reinicialização. O núcleo iria ter então três elementos físicos, cada um clamando por conter metade do mesmo volume RAID. Outra fonte de confusão pode vir quando volumes RAID de dois servidores são consolidados em apenas um servidor apenas. Se essas arrays estavam rodando normalmente antes dos discos serem removidos, o núcleo seria capaz de detectar e remontar os pares de maneira apropriada; mas se os discos movidos tiverem sido agregados em um md1 no servidor antigo, e o novo servidor já tiver um md1, um dos espelhos seria renomeado.
Fazer uma cópia de segurança da configuração é portanto importante, mesmo que apenas para referência. A maneira padrão de fazer isso é editando o arquivo /etc/mdadm/mdadm.conf, um exemplo do que é listado aqui:
Exemplo 12.1. mdadm arquivo de configuração
# mdadm.conf
#
# Please refer to mdadm.conf(5) for information about this file.
#
# by default (built-in), scan all partitions (/proc/partitions) and all
# containers for MD superblocks. alternatively, specify devices to scan, using
# wildcards if desired.
DEVICE /dev/sd*
# auto-create devices with Debian standard permissions
CREATE owner=root group=disk mode=0660 auto=yes
# automatically tag new arrays as belonging to the local system
HOMEHOST <system>
# instruct the monitoring daemon where to send mail alerts
MAILADDR root
# definitions of existing MD arrays
ARRAY /dev/md0 metadata=1.2 name=mirwiz:0 UUID=bb085b35:28e821bd:20d697c9:650152bb
ARRAY /dev/md1 metadata=1.2 name=mirwiz:1 UUID=6ec558ca:0c2c04a0:19bca283:95f67464
# This configuration was auto-generated on Thu, 17 Jan 2013 16:21:01 +0100
# by mkconf 3.2.5-3
Um dos detalhes mais úteis é a opção DEVICE, que lista os dispositivos aonde o sistema irá automaticamente procurar por componentes dos volumes RAID no momento da inicialização. No nosso exemplo, nós substituímos o valor padrão, partitions containers, por uma explícita lista de arquivos de dispositivos, já que nós escolhemos usar discos inteiros e não apenas partições, para alguns volumes.
As duas últimas linhas em nosso exemplo são aquelas que permitem ao núcleo escolher, com segurança, qual número de volume atribuir a qual array. O metadado armazenado nos próprios discos são suficientes para remontar (re-assemble) os volumes, mas não para determinar o número do volume (e o nome de dispositivo que coincide com /dev/md*).
Felizmente, estas linhas podem ser geradas automaticamente:
# mdadm --misc --detail --brief /dev/md?
ARRAY /dev/md0 metadata=1.2 name=mirwiz:0 UUID=bb085b35:28e821bd:20d697c9:650152bb
ARRAY /dev/md1 metadata=1.2 name=mirwiz:1 UUID=6ec558ca:0c2c04a0:19bca283:95f67464
O conteúdo dessas duas últimas linhas não depende da lista de discos incluídos no volume. Logo, não é necessário regenerar essas linhas quando se for substituir um disco falho por um novo. Por outro lado, tem que se tomar o cuidado de atualizar o arquivo ao se criar ou remover uma array RAID.
LVM, o Logical Volume Manager, é uma outra abordagem para abstrair volumes lógicos a partir de seus suportes físicos, que se concentra em aumentar a flexibilidade em vez de aumentar a confiabilidade. O LVM permite mudar um volume lógico de forma transparente, até aonde os aplicativos tem interesse ; por exemplo, é possível adicionar novos discos, migrar os dados para eles, e remover os discos velhos, sem desmontar o volume.
12.1.2.1. Conceitos sobre LVM
Esta flexibilidade é atingida graças ao nível de abstração envolvendo três conceitos.
Primeiro, o PV (Physical Volume) é a entidade mais próxima ao hardware: ele pode ser partições em um disco, ou um disco inteiro, ou até mesmo qualquer outro dispositivo de bloco (incluindo, por exemplo, uma array RAID). Note que quando um elemento é configurado para ser um PV para o LVM, ele deveria ser acessado via LVM apenas, de outra forma o sistema irá ficar confuso.
Vários PVs podem ser agrupados em um VG (Volume Group), que pode ser comparado com discos tanto virtual quanto extensível. VGs são abstratos, e não aparecem em um arquivo de dispositivo na hierarquia /dev, então não a risco em usá-los diretamente.
O terceiro tipo de objeto é o LV (Logical Volume), que é um pedaço de um VG; se nós mantermos a analogia VG-como-disco, o LV se compara a uma partição. O LV aparece como um dispositivo de bloco com uma entrada em /dev, e ele pode ser usado como qualquer outra partição física pode ser (mais comumente, para hospedar um sistema de arquivos ou espaço swap).
A coisa importante é que a divisão de um VG em LVs é inteiramente independente de seus componentes físicos (os PVs). Um VG com apenas um componente físico (um disco por exemplo) pode ser dividido em uma dúzia de volumes lógicos; similarmente, um VG pode usar vários discos físicos e parecer como um único e grande volume lógico. A única restrição, obviamente, é que o tamanho total alocado aos LVs não podem ser maiores que a capacidade total dos PVs no grupo de volume.
Geralmente faz sentido, contudo, ter algum tipo de homogeneidade entre os componentes físicos de um VG, e dividir o VG em volumes lógicos que irão ter padrões de uso similares. Por exemplo, se o hardware disponível inclui discos rápidos e discos lentos, os rápidos poderiam ser agrupados em um VG e os lentos em outro; pedaços do primeiro podem então se designados para aplicações que requerem rápido acesso a dados, enquanto o segundo seria mantido para tarefas de menor demanda.
Em todo caso, tenha em mente que um LV não está particularmente anexado a nenhum PV. É possível influenciar aonde os dados de um LV são fisicamente armazenados, mas essa possibilidade não é necessária para o uso do dia a dia. Pelo contrário: quando o conjunto de componentes físicos de um VG evolui, as localizações de armazenagem física correspondentes a um LV em particular podem ser migradas entre discos (enquanto se mantém dentro de PVs atribuídos ao VG, é claro).
12.1.2.2. Configurando um LVM
Vamos agora seguir, passo a passo, o processo de configurar um LVM para um caso de uso típico: nós queremos simplificar uma situação complexa de armazenagem. Uma situação dessas geralmente acontece após alguma longa e complicada história de medidas temporárias acumuladas. Para propósitos de ilustração, nós vamos considerar um servidor aonde a armazenagem precisa ter alterações com o passar do tempo, terminando em um labirinto de partições disponíveis, divididas em vários discos parcialmente usados. Em termos mais concretos, as seguintes partições estão disponíveis:
no disco sdb, uma partição sdb2, 4 GB;
no disco sdc, uma partição sdc3, 3 GB;
o disco sdd, 4 GB, está completamente disponível;
no disco sdf, uma partição sdf1, 4 GB; e uma partição sdf2, 5 GB.
Complementando, vamos assumir que os discos sdb e sdf são mais rápidos do que os outros dois.
Nosso objetivo é configurar três volumes lógicos para três diferentes aplicações: um servidor de arquivos necessitando 5 GB de espaço de armazenagem, um banco de dados (1 GB) e algum espaço para cópias de segurança (12 GB). Os dois primeiros precisam de bom desempenho, mas cópias de segurança são menos críticas em termos de velocidade de acesso. Todos essas limitações impedem o uso de partições propriamente; usando LVM pode-se abstrair o tamanho físico dos dispositivos, então o único limite é o total de espaço disponível.
As ferramentas necessárias estão no pacote lvm2 e suas dependência. Quando os mesmos estiverem instalados, configurarar o LVM terá três etapas, cobrindo três níveis de conceitos.
Primeiro, nós preparamos o volumes físicos utilizando pvcreate:
# pvdisplay
# pvcreate /dev/sdb2
Physical volume "/dev/sdb2" successfully created
# pvdisplay
"/dev/sdb2" is a new physical volume of "4.00 GiB"
--- NEW Physical volume ---
PV Name /dev/sdb2
VG Name
PV Size 4.00 GiB
Allocatable NO
PE Size 0
Total PE 0
Free PE 0
Allocated PE 0
PV UUID 0zuiQQ-j1Oe-P593-4tsN-9FGy-TY0d-Quz31I
# for i in sdc3 sdd sdf1 sdf2 ; do pvcreate /dev/$i ; done
Physical volume "/dev/sdc3" successfully created
Physical volume "/dev/sdd" successfully created
Physical volume "/dev/sdf1" successfully created
Physical volume "/dev/sdf2" successfully created
# pvdisplay -C
PV VG Fmt Attr PSize PFree
/dev/sdb2 lvm2 --- 4.00g 4.00g
/dev/sdc3 lvm2 --- 3.09g 3.09g
/dev/sdd lvm2 --- 4.00g 4.00g
/dev/sdf1 lvm2 --- 4.10g 4.10g
/dev/sdf2 lvm2 --- 5.22g 5.22g
Até agora tudo bem; note que o PV (volume físico) pode ser configurado em um disco inteiro assim como em partições individuais do mesmo. Como demonstrado acima, o comando pvdisplay lista os PVs existentes, com dois possíveis formatos de saída.
Agora vamos montar esses elementos físicos em VGs usando vgcreate. Nós vamos reunir apenas PVs dos discos rápidos em um VG vg_critical; o outro VG, vg_normal, irá incluir também elementos mais lentos.
# vgdisplay
No volume groups found
# vgcreate vg_critical /dev/sdb2 /dev/sdf1
Volume group "vg_critical" successfully created
# vgdisplay
--- Volume group ---
VG Name vg_critical
System ID
Format lvm2
Metadata Areas 2
Metadata Sequence No 1
VG Access read/write
VG Status resizable
MAX LV 0
Cur LV 0
Open LV 0
Max PV 0
Cur PV 2
Act PV 2
VG Size 8.09 GiB
PE Size 4.00 MiB
Total PE 2071
Alloc PE / Size 0 / 0
Free PE / Size 2071 / 8.09 GiB
VG UUID bpq7zO-PzPD-R7HW-V8eN-c10c-S32h-f6rKqp
# vgcreate vg_normal /dev/sdc3 /dev/sdd /dev/sdf2
Volume group "vg_normal" successfully created
# vgdisplay -C
VG #PV #LV #SN Attr VSize VFree
vg_critical 2 0 0 wz--n- 8.09g 8.09g
vg_normal 3 0 0 wz--n- 12.30g 12.30g
Aqui novamente, os comandos são bem simples (e vgdisplay propõem dois formatos de saída). Note que é perfeitamente possível usar duas partições de um mesmo disco físico em dois VGs diferentes. Note também que nós usamos um prefixo vg_ para nomear nossos VGs, mas isso não é nada mais que uma convenção.
Nós agora temos dois "discos virtuais", com o tamanho de 8 GB e 12 GB, respectivamente.Vamos transformá-los em "partições virtuais" (LVs). Isto envolve o comando lvcreate, e uma sintaxe um pouco mais complexa:
# lvdisplay
# lvcreate -n lv_files -L 5G vg_critical
Logical volume "lv_files" created
# lvdisplay
--- Logical volume ---
LV Path /dev/vg_critical/lv_files
LV Name lv_files
VG Name vg_critical
LV UUID J3V0oE-cBYO-KyDe-5e0m-3f70-nv0S-kCWbpT
LV Write Access read/write
LV Creation host, time mirwiz, 2015-06-10 06:10:50 -0400
LV Status available
# open 0
LV Size 5.00 GiB
Current LE 1280
Segments 2
Allocation inherit
Read ahead sectors auto
- currently set to 256
Block device 253:0
# lvcreate -n lv_base -L 1G vg_critical
Logical volume "lv_base" created
# lvcreate -n lv_backups -L 12G vg_normal
Logical volume "lv_backups" created
# lvdisplay -C
LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert
lv_base vg_critical -wi-a--- 1.00g
lv_files vg_critical -wi-a--- 5.00g
lv_backups vg_normal -wi-a--- 12.00g
São necessários dois parâmetros para a criação de volumes lógicos; eles tem que ser passados ao lvcreate como opções. O nome do LV a ser criado é especificado com a opção -n, e seu tamanho geralmente é dado usando a opção -L. Nós também precisamos dizer ao comando qual o VG a ser operado, é claro, sendo portanto o último parâmetro da linha de comando.
Volumes lógicos, quando criados, são representados como dispositivos de blocos no /dev/mapper/:
# ls -l /dev/mapper
total 0
crw------- 1 root root 10, 236 Jun 10 16:52 control
lrwxrwxrwx 1 root root 7 Jun 10 17:05 vg_critical-lv_base -> ../dm-1
lrwxrwxrwx 1 root root 7 Jun 10 17:05 vg_critical-lv_files -> ../dm-0
lrwxrwxrwx 1 root root 7 Jun 10 17:05 vg_normal-lv_backups -> ../dm-2
# ls -l /dev/dm-*
brw-rw---T 1 root disk 253, 0 Jun 10 17:05 /dev/dm-0
brw-rw---- 1 root disk 253, 1 Jun 10 17:05 /dev/dm-1
brw-rw---- 1 root disk 253, 2 Jun 10 17:05 /dev/dm-2
Para simplificar, links simbólicos são convenientemente criados em diretórios que coincidem com os VGs:
# ls -l /dev/vg_critical
total 0
lrwxrwxrwx 1 root root 7 Jun 10 17:05 lv_base -> ../dm-1
lrwxrwxrwx 1 root root 7 Jun 10 17:05 lv_files -> ../dm-0
# ls -l /dev/vg_normal
total 0
lrwxrwxrwx 1 root root 7 Jun 10 17:05 lv_backups -> ../dm-2
Os LVs então podem ser utilizados exatamente como partições padrão:
# mkfs.ext4 /dev/vg_normal/lv_backups
mke2fs 1.42.12 (29-Aug-2014)
Creating filesystem with 3145728 4k blocks and 786432 inodes
Filesystem UUID: b5236976-e0e2-462e-81f5-0ae835ddab1d
[...]
Creating journal (32768 blocks): done
Writing superblocks and filesystem accounting information: done
# mkdir /srv/backups
# mount /dev/vg_normal/lv_backups /srv/backups
# df -h /srv/backups
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/vg_normal-lv_backups 12G 30M 12G 1% /srv/backups
# [...]
[...]
# cat /etc/fstab
[...]
/dev/vg_critical/lv_base /srv/base ext4 defaults 0 2
/dev/vg_critical/lv_files /srv/files ext4 defaults 0 2
/dev/vg_normal/lv_backups /srv/backups ext4 defaults 0 2
Do ponto de vista das aplicações, a miríade de pequenas partições foi abstraída em um grande volume de 12 GB, com um nome amigável.
12.1.2.3. LVM ao longo do tempo
Mesmo que a habilidade de agregar partições ou discos físicos seja conveniente, essa não é a principal vantagem trazida pelo LVM. A flexibilidade que ele trás é especialmente notada com o passar do tempo, quando as necessidades se desenvolvem. Em nosso exemplo, vamos assumir que novos e grandes arquivos tem que ser armazenados, e que o LV dedicado ao servidor de arquivos é muito pequeno para acomodá-los. Como nós não usamos todo o espaço disponível em vg_critical, nós podemos crescer o lv_files. Para esse propósito, nós iremos usar o comando lvresize, e então o resize2fs para adaptar o sistema de arquivos em conformidadde:
# df -h /srv/files/
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/vg_critical-lv_files 5.0G 4.6G 146M 97% /srv/files
# lvdisplay -C vg_critical/lv_files
LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert
lv_files vg_critical -wi-ao-- 5.00g
# vgdisplay -C vg_critical
VG #PV #LV #SN Attr VSize VFree
vg_critical 2 2 0 wz--n- 8.09g 2.09g
# lvresize -L 7G vg_critical/lv_files
Size of logical volume vg_critical/lv_files changed from 5.00 GiB (1280 extents) to 7.00 GiB (1792 extents).
Logical volume lv_files successfully resized
# lvdisplay -C vg_critical/lv_files
LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert
lv_files vg_critical -wi-ao-- 7.00g
# resize2fs /dev/vg_critical/lv_files
resize2fs 1.42.12 (29-Aug-2014)
Filesystem at /dev/vg_critical/lv_files is mounted on /srv/files; on-line resizing required
old_desc_blocks = 1, new_desc_blocks = 1
The filesystem on /dev/vg_critical/lv_files is now 1835008 (4k) blocks long.
# df -h /srv/files/
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/vg_critical-lv_files 6.9G 4.6G 2.1G 70% /srv/files
Nós poderíamos proceder de maneira similar para estender o volume que hospeda o banco de dados, apenas se nós tivermos alcançado o limite de espaço disponível do VG:
# df -h /srv/base/
Sist. Arq. Tam. Usado Disp. Uso% Montado em
/dev/mapper/vg_critical-lv_base 1008M 854M 104M 90% /srv/base
# vgdisplay -C vg_critical
VG #PV #LV #SN Attr VSize VFree
vg_critical 2 2 0 wz--n- 8.09g 92.00m
Não importa, já que o LVM permite a adição de volumes físico em grupos de volumes existentes. Por exemplo, talvez nós percebamos que a partição sdb1, que era até agora usada fora do LVM, apenas contém arquivos que poderiam ser movidos para lv_backups. Nós podemos agora reciclá-la e integrá-la ao grupo de volume, e assim recuperar algum espaço disponível. Esse é o propósito do comando vgextend. Claro que, a partição tem que ser preparada antes como um volume físico. Uma vez que o VG tenha sido estendido, nós podemos usar comandos similares aos anteriores para cultivar o volume lógico e então o sistema de arquivos:
# pvcreate /dev/sdb1
Physical volume "/dev/sdb1" successfully created
# vgextend vg_critical /dev/sdb1
Volume group "vg_critical" successfully extended
# vgdisplay -C vg_critical
VG #PV #LV #SN Attr VSize VFree
vg_critical 3 2 0 wz--n- 9.09g 1.09g
# [...]
[...]
# df -h /srv/base/
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/vg_critical-lv_base 2.0G 854M 1.1G 45% /srv/base
Tanto o RAID quanto o LVM irão trazer vantagens indiscutíveis assim que se deixar o simples caso de um computador de mesa com um único disco rígido, aonde o padrão de uso não muda com o tempo. Contudo, RAID e LVM vão em direções diferentes, com objetivos divergentes, e é legítimo questionar qual deles deve ser adotado. A resposta mais apropriada irá, é claro, depender das necessidades atuais e previstas.
Existem alguns casos simples aonde a questão realmente não surge. Se a necessidade é salvaguardar dados contra falhas de hardware, então, obviamente, o RAID será configurado em uma array redundante de discos, já que o LVM realmente não é designado para esse problema. Se, por outro lado, a necessidade é por um esquema de armazenamento flexível aonde os volumes são feitos independente do layout físico dos disco, o RAID não ajuda muito e o LVM será a escolha natural.
O terceiro caso de uso notável é quando alguém apenas quer agregar dois discos em um volume, seja por questões de desempenho, ou para ter um único sistema de arquivos que seja maior que qualquer dos discos disponíveis. Esse caso pode ser resolvido pelo RAID-0 (ou mesmo um linear-RAID) e por um volume LVM. Quando nesta situação, e salvo restrições extras (por exemplo, manter em sintonia com o resto dos computadores se eles usam apenas RAID), a configuração de escolha irá geralmente ser LVM. A configuração inicial é um pouco mais complexa, mas esse incremento na complexidade mais do que compensado pela flexibilidade extra que o LVM trás caso as necessidades mudem ou se novos discos precisem ser adicionados.
Então, é claro, temos uma caso de uso realmente interessante, aonde o sistema de armazenamento precisa ser feito tanto para resistência de falha de hardware quanto flexível quando se trata de alocação de volume. Nem RAID nem LVM podem atender esses dois requisitos por conta própria; não tem problema, é aqui que nós usamos os dois ao mesmo tempo — ou melhor, um em cima do outro. O esquema que tem tudo, mas só se tornou um padrão quando o RAID e o LVM alcançaram a maturidade, é para garantir a redundância de dados, primeiro pelo agrupamento de discos em um pequeno número de grandes arrays RAID, e para usar essas arrays RAID como volumes físicos LVM; partições lógicas serão então esculpidas a partir desses LVs para sistemas de arquivos. O ponto forte dessa configuração é que, quando um disco falha, apenas um pequeno número das arrays RAID precisará ser reconstru[ida, limitando assim o tempo gasto pelo administrador para recuperação.
Vamos ver um exemplo concreto: o departamento de relações públicas da Falcot Corp precisa de uma estação de trabalho para edição de vídeo, mas o orçamento do departamento não permite investir em hardware de ponta para a finalidade. Uma decisão é tomada para favorecer o hardware que é específico para a natureza gráfica do trabalho (monitor e placa de vídeo), e ficar com o hardware genérico para armazenamento. No entanto, como é amplamente conhecido, o vídeo digital tem sim alguns requisitos especiais para seu armazenamento: a quantidade de dados a ser armazenado é grande, e a taxa de transferência para leitura e escrita desses dados é importante para o desempenho geral do sistema (mais que o tempo de acesso típico, por exemplo). Essas restrições precisam ser preenchidas com hardware genérico, neste caso com dois discos rígidos SATA de 300 GB; os dados do sistema também tem que ser resistentes a falha de hardware, assim como alguns dos dados do usuário. Videoclipes editados tem que realmente estar seguros, mas vídeo com edição pendente é menos critico, já que eles ainda estão nas fitas de vídeo.
O RAID-1 e o LVM são combinados para satisfazer essas restrições. Os discos são anexados a duas controladoras SATA diferentes, para otimizar acesso paralelo e reduzir o risco de falhas simultâneas, e eles portanto aparecem como sda e sdc. Eles são particionados de forma idêntica, seguindo o seguinte esquema:
# fdisk -l /dev/sda
Disk /dev/sda: 300 GB, 300090728448 bytes, 586114704 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x00039a9f
Device Boot Start End Sectors Size Id Type
/dev/sda1 * 2048 1992060 1990012 1.0G fd Linux raid autodetect
/dev/sda2 1992061 3984120 1992059 1.0G 82 Linux swap / Solaris
/dev/sda3 4000185 586099395 582099210 298G 5 Extended
/dev/sda5 4000185 203977305 199977120 102G fd Linux raid autodetect
/dev/sda6 203977306 403970490 199993184 102G fd Linux raid autodetect
/dev/sda7 403970491 586099395 182128904 93G 8e Linux LVM
As primeiras partições em ambos os discos (por volta de 1 GB) são montadas em um volume RAID-1, md0. Este espelho é diretamente usado para armazenar o sistema de arquivos raiz.
As partições sda2 e sdc2 são usadas como partição swap, provendo um total de 2 GB de espaço swap. Com 1 GB de RAM, a estação de trabalho encontra uma quantidade confortável de memoria disponível.
As partições sda5 e sdc5, assim como a sda6 e sdc6, são montadas em dois novos volumes RAID-1 de 100 GB cada, md1 e md2. Os dois espelhos são iniciados como volumes físicos para o LVM, e atribuídos para o grupo de volume vg_raid. Esse VG , portanto, contém 200 GB de espaço seguro.
As partições que sobraram, sda7 e sdc7,são diretamente usadas como volumes físicos, e associadas a outro VG chamado vg_bulk, o qual portanto terminará com aproximadamente 200 GB de espaço.
Uma vez que os VGs sejam criados, eles podem ser particionados de maneira bem flexível. É preciso ter em mente que os LVs criados em vg_raid serão preservados mesmo que um dos discos falhe, o que não será o caso para LVs criados em vg_bulk; por outro lado, o último será alocado em paralelo nos dois discos, o que permite altas velocidades de leitura ou escrita para arquivos grandes.
Portanto nós iremos criar os LVs lv_usr, lv_var e lv_home no vg_raid, para hospedar os sistemas de arquivos correspondentes; outro grande LV, lv_movies, será usado para hospedar as versões definitivas dos filmes após a edição. O outro VG será dividido em um grande lv_rushes, para dados tirados de câmeras digitais de vídeo, e um lv_tmp para arquivos temporários. A localização da área de trabalho é uma escolha menos simples de fazer: enquanto bom desempenho é necessário para esse volume, vale o risco de perda de trabalho se uma falha de disco ocorrer durante uma sessão de edição? Dependendo da resposta essa pergunta, o LV relevante será criado em um VG ou em outro.
Nós agora temos tanto alguma redundância para dados importantes quanto muita flexibilidade no modo como o espaço disponível é dividido entre as aplicações. Para novo software que for instalado mais tarde (para edição de clips de áudio, por exemplo), o LV que hospeda /usr/ pode ser aumentado sem dor de cabeça.
