/dev/cciss/c0d0
; o núcleo no Wheezy alterou esse nome para algo mais natural como /dev/sda
, mas outras controladoras RAID podem ainda se comportar de modo diferente.
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.
sdb
, 4 GB, está completamente disponível;
sdc
, 4 GB, também está completamente disponível;
sdd
, somente a partição sdd2
(cerca de 4 GB) está disponível;
sde
, ainda com 4 GB, disponível.
#
mdadm --create /dev/md0 --level=0 --raid-devices=2 /dev/sda /dev/sde
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 : Thu Sep 30 15:21:15 2010 Raid Level : raid0 Array Size : 8388480 (8.00 GiB 8.59 GB) Raid Devices : 2 Total Devices : 2 Persistence : Superblock is persistent Update Time : Thu Sep 30 15:21:15 2010 State : active Active Devices : 2 Working Devices : 2 Failed Devices : 0 Spare Devices : 0 Chunk Size : 512K Name : squeeze:0 (local to host squeeze) UUID : 0012a273:cbdb8b83:0ee15f7f:aec5e3c3 Events : 0 Number Major Minor RaidDevice State 0 8 0 0 active sync /dev/sda 1 8 64 1 active sync /dev/sde #
mkfs.ext4 /dev/md0
mke2fs 1.41.12 (17-May-2010) Filesystem label= OS type: Linux Block size=4096 (log=2) Fragment size=4096 (log=2) Stride=0 blocks, Stripe width=0 blocks 524288 inodes, 2097152 blocks 104857 blocks (5.00%) reserved for the super user First data block=0 Maximum filesystem blocks=2147483648 55 block groups 32768 blocks per group, 32768 fragments per group 8160 inodes per group Superblock backups stored on blocks: 32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632 Writing inode tables: done Creating journal (32768 blocks): done Writing superblocks and filesystem accounting information: done This filesystem will be automatically checked every 26 mounts or 180 days, whichever comes first. Use tune2fs -c or -i to override. #
mkdir /srv/raid-0
#
mount /dev/md0 /srv/raid-0
#
df -h /srv/raid-0
Filesystem Size Used Avail Use% Mounted on /dev/md0 8.0G 249M 7.4G 4% /srv/raid-0
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
.
#
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 : Thu Jan 17 16:13:04 2013 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 : Thu Jan 17 16:13:04 2013 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 [...]
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.
/dev/md1
é usável, e um sistema de arquivos pode ser criado nele, assim como alguns dados podem ser copiados para ele.
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 : Thu Jan 17 16:14:09 2013 State : active, 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 1 0 0 1 removed 1 8 64 - faulty spare /dev/sde
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 : Thu Jan 17 16:15:32 2013 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 spare /dev/sde #
[...]
[...] #
mdadm --detail /dev/md1
/dev/md1: [...] Update Time : Thu Jan 17 16:16:36 2013 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 spare /dev/sde
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
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.
/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
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.
/dev/md*
).
#
mdadm --misc --detail --brief /dev/md?
ARRAY /dev/md0 metadata=1.2 name=squeeze:0 UUID=6194b63f:69a40eb5:a79b7ad3:c91f20ee ARRAY /dev/md1 metadata=1.2 name=squeeze:1 UUID=20a8419b:41612750:b9171cfe:00d9a432
/dev
, então não a risco em usá-los diretamente.
/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).
sdb
, uma partição sdb2
, 4 GB;
sdc
, uma partição sdc3
, 3 GB;
sdd
, 4 GB, está completamente disponível;
sdf
, uma partição sdf1
, 4 GB; e uma partição sdf2
, 5 GB.
sdb
e sdf
são mais rápidos do que os outros dois.
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 (KByte) 0 Total PE 0 Free PE 0 Allocated PE 0 PV UUID 9JuaGR-W7jc-pNgj-NU4l-2IX1-kUJ7-m8cRim #
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 a- 4.00g 4.00g /dev/sdc3 lvm2 a- 3.09g 3.09g /dev/sdd lvm2 a- 4.00g 4.00g /dev/sdf1 lvm2 a- 4.10g 4.10g /dev/sdf2 lvm2 a- 5.22g 5.22g
pvdisplay
lista os PVs existentes, com dois possíveis formatos de saída.
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
#
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.14 GB PE Size 4.00 MB Total PE 2084 Alloc PE / Size 0 / 0 Free PE / Size 2084 / 8.14 GB VG UUID 6eG6BW-MmJE-KB0J-dsB2-52iL-N6eD-1paeo8 #
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.14g 8.14g vg_normal 3 0 0 wz--n- 12.30g 12.30g
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.
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, 2013-01-17 17:05:13 +0100 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% Move Log Copy% 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
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.
/dev/mapper/
:
#
ls -l /dev/mapper
total 0 crw------T 1 root root 10, 236 Jan 17 16:52 control lrwxrwxrwx 1 root root 7 Jan 17 17:05 vg_critical-lv_base -> ../dm-1 lrwxrwxrwx 1 root root 7 Jan 17 17:05 vg_critical-lv_files -> ../dm-0 lrwxrwxrwx 1 root root 7 Jan 17 17:05 vg_normal-lv_backups -> ../dm-2 #
ls -l /dev/dm-*
brw-rw---T 1 root disk 253, 0 Jan 17 17:05 /dev/dm-0 brw-rw---T 1 root disk 253, 1 Jan 17 17:05 /dev/dm-1 brw-rw---T 1 root disk 253, 2 Jan 17 17:05 /dev/dm-2
#
ls -l /dev/vg_critical
total 0 lrwxrwxrwx 1 root root 7 Jan 17 17:05 lv_base -> ../dm-1 lrwxrwxrwx 1 root root 7 Jan 17 17:05 lv_files -> ../dm-0 #
ls -l /dev/vg_normal
total 0 lrwxrwxrwx 1 root root 7 Jan 17 17:05 lv_backups -> ../dm-2
#
mkfs.ext4 /dev/vg_normal/lv_backups
mke2fs 1.42.5 (29-Jul-2012) Filesystem label= OS type: Linux Block size=4096 (log=2) [...] 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 158M 12G 2% /srv/backups #
[...]
[...] #
cat /etc/fstab
[...] /dev/vg_critical/lv_base /srv/base ext4 /dev/vg_critical/lv_files /srv/files ext4 /dev/vg_normal/lv_backups /srv/backups ext4
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% Move Log Copy% 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
Extending logical volume lv_files to 7.00 GB Logical volume lv_files successfully resized #
lvdisplay -C vg_critical/lv_files
LV VG Attr LSize Pool Origin Data% Move Log Copy% Convert lv_files vg_critical -wi-ao-- 7.00g #
resize2fs /dev/vg_critical/lv_files
resize2fs 1.42.5 (29-Jul-2012) Filesystem at /dev/vg_critical/lv_files is mounted on /srv/files; on-line resizing required old_desc_blocks = 1, new_desc_blocks = 1 Performing an on-line resize of /dev/vg_critical/lv_files to 1835008 (4k) blocks. The filesystem on /dev/vg_critical/lv_files is now 1835008 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
#
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
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
Writing physical volume data to disk "/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
sda
e sdc
. Eles são particionados de forma idêntica, seguindo o seguinte esquema:
#
fdisk -l /dev/sda
Disk /dev/hda: 300.0 GB, 300090728448 bytes 255 heads, 63 sectors/track, 36483 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x00039a9f Device Boot Start End Blocks Id System /dev/sda1 * 1 124 995998+ fd Linux raid autodetect /dev/sda2 125 248 996030 82 Linux swap / Solaris /dev/sda3 249 36483 291057637+ 5 Extended /dev/sda5 249 12697 99996561 fd Linux raid autodetect /dev/sda6 12698 25146 99996561 fd Linux raid autodetect /dev/sda7 25147 36483 91064421 8e Linux LVM
md0
. Este espelho é diretamente usado para armazenar o sistema de arquivos raiz.
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.
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.
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.
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.
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.
/usr/
pode ser aumentado sem dor de cabeça.