Product SiteDocumentation Site

Bab 12. Administrasi Tingkat Lanjut

12.1. RAID dan LVM
12.1.1. RAID Perangkat Lunak
12.1.2. LVM
12.1.3. RAID atau LVM?
12.2. Virtualisasi
12.2.1. Xen
12.2.2. LXC
12.2.3. Virtualisasi dengan KVM
12.3. Pemasangan Otomatis
12.3.1. Fully Automatic Installer (FAI, Pemasang Otomatis Sepenuhnya)
12.3.2. Memprabibit Debian-Installer
12.3.3. Simple-CDD: Solusi Semua-Jadi-Satu
12.4. Pemantauan
12.4.1. Menyiapkan Munin
12.4.2. Menyiapkan Nagios
Bab ini meninjau kembali beberapa aspek yang telah kami uraikan, dengan perspektif yang berbeda: alih-alih memasang pada sebuah komputer, kita akan mempelajari sistem deployment masal; alih-alih membuat volume RAID atau LVM pada saat instalasi, kita akan belajar melakukannya secara manual sehingga nanti kita dapat merevisi pilihan awal kita. Akhirnya, kita akan mendiskusikan perkakas pemantauan dan teknik virtualisasi. Sebagai konsekuensinya, bab ini secara lebih khusus menarget para administrator profesional, and sedikit kurang brfokus pada para individu yang bertanggungjawab atas jaringan rumahan mereka.

12.1. RAID dan LVM

Bab 4, Instalasi mempresentasikan teknologi ini dari sudut pandang pemasang, dan bagaimana itu mengintegrasikan mereka untuk membuat deployment mereka mudah dari awal. Setelah instalasi awal, seorang administrator mesti bisa menangani keperluan ruang penyimpanan yang berkembang tanpa mesti mengandalkan instalasi ulang yang mahal. Maka mereka mesti paham peralatan yang diperlukan untuk memanipulasi volume RAID dan LVM.
RAID dan LVM adalah teknik untuk mengabstrakkan volume yang dikait dari pasangan fisik mereka (yaitu hard disk atau partisi); yang pertama memastikan keamanan dan ketersediaan data dari kegagalan perangkat keras dengan memperkenalkan redundansi, yang belakangan membuat manajemen volume lebih luwes dan tak bergantung kepada ukuran sebenarnya dari disk yang mendasarinya. Dalam kedua kasus, sistem pada akhirnya mendapat perangkat blok baru, yang dapat dipakai untuk membuat sistem berkas atau ruang swap, tanpa perlu mereka dipetakan ke satu disk fisik. RAID dan LVM datang dari latar belakang yang cukup berbeda, tapi fungsionalitas mereka sebagian dapat bertumpang tindih, sehingga mereka sering disinggung bersama-sama.
Pada kedua kasus RAID dan LVM, kernel menyediakan suatu berkas perangkat blok, mirip dengan yang berkaitan dengan suatu hard disk atau suatu partisi. Ketika suatu aplikasi, atau bagian lain dari kernel, meminta akses ke suatu blok dari perangkat seperti itu, subsistem yang sesuai mengarahkan blok ke lapisan fisik yang relevan. Bergantung kepada konfigurasi, blok ini dapat disimpan pada satu atau beberapa disk fisik, dan lokasi fisiknya mungkin tak berkorelasi langsung ke lokasi blok dalam perangkat lojik.

12.1.1. RAID Perangkat Lunak

RAID adalah Redundant Array of Independent Disks (larik redundan dari disk-disk independen). Tujuan dari sistem ini adalah untuk mencegah kehilangan data dan memastikan ketersediaan dalam kasus kegagalan hard disk. Prinsip umumnya cukup sederhana: data disimpan pada beberapa disk fisik alih-alih hanya satu, dengan tingkat redundansi yang dapat dikonfigurasi. Bergantung kepada banyaknya redundansi ini, dan bahkan dalam kejadian kegagalan disk yang tak terduga, data dapat direkonstruksi tanpa adanya kehilangan dari disk sisanya.
RAID dapat diwujudkan baik oleh perangkat keras khusus (modul RAID yang terintegrasi ke dalam kartu pengendali SCSI atau SATA) atau oleh abstraksi perangkat lunak (kernel). Apakah perangkat keras atau perangkat lunak, sistem RAID dengan redundansi yang cukup bisa secara transparan tetap operasional ketika sebuah disk gagal; lapisan atas tumpukan (aplikasi) bahkan dapat tetap mengakses data terlepas dari kegagalan. Tentu saja, "mode terdegradasi" ini dapat memiliki dampak pada kinerja, dan redundansi berkurang, sehingga kegagalan disk lebih lanjut dapat mengakibatkan kehilangan data. Dalam prakteknya, oleh karena itu, kita akan berusaha untuk hanya berada dalam mode terdegradasi ini selama diperlukannya untuk menggantikan disk yang gagal. Sekali disk baru terpasang sistem RAID dapat merekonstruksi data yang dibutuhkan untuk kembali ke mode aman. Aplikasi tidak akan melihat apa-apa, selain kecepatan akses berpotensi berkurang, sementara larik ada dalam mode terdegradasi atau selama fase rekonstruksi.
Ketika RAID diimplementasikan oleh perangkat keras, konfigurasinya umumnya terjadi dalam alat konfigurasi BIOS, dan kernel akan menganggap sebuah array RAID sebagai satu disk, yang akan bekerja sebagai disk fisik standar, meskipun nama perangkat mungkin berbeda (tergantung pada driver).
Kami hanya berfokus pada RAID perangkat lunak dalam buku ini.

12.1.1.1. Tingkat-tingkat RAID

RAID sebenarnya buka satu sistem, tapi berbagai sistem yang diidentifikasi oleh tingkat mereka; tingkat-tingkat itu dibedakan oleh tata letak dan banyaknya redundansi yang mereka sediakan. Semakin banyak redundan, semakin kebal kegagalan, karena sistem akan dapat terus bekerja dengan lebih banyak disk yang gagal. Kekurangannya adalah bahwa ruang yang dapat digunakan menyusut untuk satu set disk tertentu; dilihat dengan cara lain, akan diperlukan lebih banyak disk untuk menyimpan sejumlah data yang diberikan.
RAID Linier
Meskipun subsistem RAID kernel memungkinkan menciptakan "linear RAID", ini bukan RAID yang benar, karena konfigurasi ini tidak melibatkan redundansi apapun. Kernel hanya mengumpulkan beberapa disk end-to-end dan menyediakan volume agregat yang dihasilkan sebagai satu disk virtual (satu perangkat blok). Itu adalah satu-satunya fungsinya. Konfigurasi ini jarang digunakan sendirian (lihat nanti untuk pengecualian), terutama karena kurangnya redundansi berarti bahwa salah satu disk gagal membuat seluruh agregat, dan karena itu semua data, tidak tersedia.
RAID-0
Tingkat ini tidak menyediakan redundansi apapun, tapi disk-disk tidak hanya sekadar dilekatkan satu di akhir yang lain: mereka dibagi dalam stripe, dan blok-blok di perangkat virtual disimpan dalam stripe di disk-disk fisik yang berbeda-beda. Dalam setup RAID-0 dua-disk, misalnya, blok bernomor genap dari perangkat virtual akan disimpan pada disk fisik pertama, sementara blok bernomor ganjil akan berakhir pada disk fisik kedua.
Sistem ini tidak bertujuan meningkatkan keandalan, karena (seperti dalam kasus linier) ketersediaan semua data hancur begitu satu disk gagal, tetapi meningkatkan kinerja: selama akses berurutan ke sejumlah besar data yang berdekatan, kernel akan mampu membaca dari kedua disk (atau menulis ke mereka) secara paralel, yang akan meningkatkan laju transfer data. Disk dimanfaatkan sepenuhnya oleh peranti RAID, sehingga mereka mestinya memiliki ukuran yang sama agar tidak kehilangan kinerja.
Penggunaan RAID-0 berkurang, ceruknya sedang diisi oleh LVM (lihat lagi nanti).
RAID-1
Tingkat ini, juga dikenal sebagai "RAID mirroring", adalah yang paling sederhana dan setup yang paling banyak digunakan. Dalam bentuk standar, menggunakan dua disk fisik berukuran sama, dan memberikan volume logis berukuran yang sama lagi. Data disimpan identik pada disk kedua, maka dijuluki "mirror (cermin)". Ketika satu disk gagal, data ini masih tersedia di yang lain. Untuk data yang benar-benar penting, RAID-1 dapat tentu saja diatur pada disk yang lebih dari dua, dengan dampak langsung pada rasio biaya perangkat keras versus ruang muatan yang tersedia.
Tingkat RAID ini, walaupun mahal (karena hanya separuh dari ruang penyimpanan fisik, dalam keadaan terbaik, berguna), secara luas digunakan dalam praktek. Hal ini mudah untuk dipahami, dan memungkinkan cadangan yang sangat sederhana: karena disk kedua memiliki isi yang identik, salah satu dari mereka dapat sementara diekstraksi dengan tidak berdampak pada sistem yang bekerja. Kinerja baca sering meningkat karena kernel bisa membaca setengah dari data pada setiap disk secara paralel, sementara kinerja tulis tidak terlalu turun parah. Dalam sebuah array RAID-1 N disk, data tetap tersedia bahkan dengan N-1 disk gagal.
RAID-4
Tingkat RAID ini, tidak banyak dipakai, menggunakan N disk untuk menyimpan data yang berguna, dan disk tambahan untuk menyimpan informasi redundansi. Jika disk itu gagal, sistem dapat merekonstruksi isinya dari N yang lain. Jika salah satu dari N disk data gagal, N-1 sisa yang dikombinasikan dengan disk "paritas" berisi cukup informasi untuk merekonstruksi data yang dibutuhkan.
RAID-4 tidak terlalu mahal karena itu hanya melibatkan peningkatan biaya satu-dari-N dan tidak memiliki dampak yang terlihat pada kinerja baca, tapi penulisan melambat. Selanjutnya, karena menulis ke salah satu dari N disk juga melibatkan menulis ke disk paritas, yang terakhir melihat menulis lebih banyak daripada yang pertama, dan usia pakainya dapat memendek secara dramatis sebagai akibatnya. Data pada array RAID-4 aman hanya sampai dengan satu disk gagal (dari N+1).
RAID-5
RAID-5 menjawab masalah asimetri dari RAID-4: blok paritas disebar ke seluruh N+1 disk, tanpa ada satu disk yang memiliki peran tertentu.
Kinerja baca dan tulis identik dengan RAID-4. Di sini, sistem tetap berfungsi bila satu disk (dari N+1) gagal, tapi tak boleh lebih.
RAID-6
RAID-6 dapat dianggap perluasan dari RAID-5, dimana setiap seri N blok melibatkan dua blok redundansi, dan setiap seri N+2 blok disebar ke N+2 disk.
Tingkat RAID ini sedikit lebih mahal daripada dua sebelumnya, tapi itu membawa beberapa keamanan tambahan karena sampai dengan dua drive (dari N+2) bisa gagal tanpa mengorbankan ketersediaan data. Kekurangannya adalah bahwa sekarang operasi tulis melibatkan menulis satu blok data dan dua blok redundansi, yang membuat mereka lebih lambat lagi.
RAID-1+0
Ini secara presisi bukan tingkat RAID, tapi penumpukan dua pengelompokan RAID. Mulai dari 2×N disk, kita pertama kali menyiapkan pasangan-pasangan ke N volume RAID-1; N volume ini kemudian dikumpulkan menjadi satu, baik memakai "linear RAID" atau (semakin banyak) memakai LVM. Kasus terakhir ini di luar RAID murni, tapi tidak ada masalah dengan itu.
RAID-1+0 dapat bertahan dari beberapa disk gagal: sampai N dalam array 2×N yang dijelaskan di atas, asal bahwa setidaknya satu disk tetap bekerja di setiap pasangan RAID-1.
Jelas, tingkat RAID akan dipilih sesuai dengan kendala dan persyaratan setiap aplikasi. Perhatikan bahwa satu komputer dapat memiliki beberapa array RAID yang berbeda dengan konfigurasi yang berbeda.

12.1.1.2. Menyiapkan RAID

Menyiapkan volume RAID memerlukan paket mdadm; ini menyediakan perintah mdadm, yang memungkinkan membuat dan memanipulasi array RAID, maupun skrip dan alat-alat yang mengintegrasikan ke seluruh sistem, termasuk sistem pemantauan.
Contoh kita akan menjadi server dengan sejumlah disk, beberapa di antaranya sudah digunakan, sisanya tersedia untuk menyiapkan RAID. Kita awalnya memiliki disk dan partisi sebagai berikut:
  • disk sdb, 4 GB, sepenuhnya tersedia;
  • disk sdc, 4 GB, ini juga sepenuhnya tersedia;
  • pada disk sdd, hanya partisi sdd2 (sekitar 4 GB) tersedia;
  • akhirnya, disk sde, masih 4 GB, sepenuhnya tersedia.
Kita akan menggunakan unsur-unsur fisik ini untuk membangun dua volume, satu RAID-0 dan satu cermin (RAID-1). Mari kita mulai dengan 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 : Tue Jun 25 08:47:49 2019
        Raid Level : raid0
        Array Size : 8378368 (7.99 GiB 8.58 GB)
      Raid Devices : 2
     Total Devices : 2
       Persistence : Superblock is persistent

       Update Time : Tue Jun 25 08:47:49 2019
             State : clean 
    Active Devices : 2
   Working Devices : 2
    Failed Devices : 0
     Spare Devices : 0

        Chunk Size : 512K

Consistency Policy : none

              Name : mirwiz:0  (local to host debian)
              UUID : 146e104f:66ccc06d:71c262d7:9af1fbc7
            Events : 0

    Number   Major   Minor   RaidDevice State
       0       8       32        0      active sync   /dev/sdb
       1       8       48        1      active sync   /dev/sdc
# mkfs.ext4 /dev/md0
mke2fs 1.44.5 (15-Dec-2018)
Discarding device blocks: done                            
Creating filesystem with 2094592 4k blocks and 524288 inodes
Filesystem UUID: 413c3dff-ab5e-44e7-ad34-cf1a029cfe98
Superblock backups stored on blocks: 
	32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632

Allocating group tables: done                            
Writing inode tables: done                            
Creating journal (16384 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   36M  7.4G   1% /srv/raid-0
Perintah mdadm --create memerlukan beberapa parameter: nama volume yang akan dibuat (/dev/md*, dengan MD singkatan dari Multiple Devices), tingkat RAID, cacah disk (yang wajib meskipun sebagian besar bermakna hanya dengan RAID-1 dan di atasnya), dan drive fisik yang akan digunakan. Setelah perangkat dibuat, kita dapat menggunakannya seperti kita akan menggunakan sebuah partisi normal, membuat sebuah sistem berkas di atasnya, mengait sistem berkas itu, dan sebagainya. Perhatikan bahwa penciptaan kita atas suatu volume RAID-0 pada md0 hanya kebetulan, dan penomoran array tidak perlu berkorelasi dengan pilihan banyaknya redundansi. Hal ini juga memungkinkan untuk membuat array RAID bernama, dengan memberikan parameter mdadm seperti misalnya /dev/md/linear bukan /dev/md0.
Penciptaan RAID-1 mengikuti cara yang sama, perbedaannya hanya menjadi terlihat setelah penciptaan:
# 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 : Tue Jun 25 10:21:22 2019
        Raid Level : raid1
        Array Size : 4189184 (4.00 GiB 4.29 GB)
     Used Dev Size : 4189184 (4.00 GiB 4.29 GB)
      Raid Devices : 2
     Total Devices : 2
       Persistence : Superblock is persistent

       Update Time : Tue Jun 25 10:22:03 2019
             State : clean, resyncing 
    Active Devices : 2
   Working Devices : 2
    Failed Devices : 0
     Spare Devices : 0

Consistency Policy : resync

     Resync Status : 93% complete

              Name : mirwiz:1  (local to host debian)
              UUID : 7d123734:9677b7d6:72194f7d:9050771c
            Events : 16

    Number   Major   Minor   RaidDevice State
       0       8       64        0      active sync   /dev/sdd2
       1       8       80        1      active sync   /dev/sde
# mdadm --detail /dev/md1
/dev/md1:
[...]
          State : clean
[...]
Beberapa komentar perlu disinggung. Pertama, mdadm tahu bahwa elemen-elemen fisik memiliki ukuran yang berbeda; karena hal ini menyiratkan bahwa sebagian ruang akan hilang pada elemen yang lebih besar, konfirmasi diperlukan.
Lebih penting lagi, perhatikan keadaan cermin. Keadaan normal dari suatu cermin RAID adalah bahwa kedua disk memiliki isi yang tepat sama. Namun, tidak ada yang menjamin ini ketika volume pertama kali dibuat. Subsistem RAID karena itu akan memberikan jaminan itu sendiri, dan akan ada tahap sinkronisasi segera setelah perangkat RAID dibuat. Setelah beberapa waktu (lama persisnya akan tergantung pada ukuran sebenarnya dari disk...), array RAID berpindah ke keadaan "aktif" atau "bersih". Perhatikan bahwa selama fase rekonstruksi ini, cermin ada dalam mode terdegradasi, dan redundansi tidak dijamin. Sebuah disk yang gagal selama jendela risiko itu bisa mengakibatkan kehilangan semua data. Namun, sejumlah besar data penting, jarang disimpan pada sebuah array RAID yang baru dibuat sebelum sinkronisasi awalnya. Catat bahwa bahkan dalam mode terdegradasi, /dev/md1 dapat digunakan, dan sebuah sistem berkas dapat dibuat di atasnya, maupun data dapat disalin ke sana.
Sekarang mari kita lihat apa yang terjadi ketika salah satu elemen array RAID-1 gagal. mdadm, khususnya opsi --fail, memungkinkan simulasi suatu kegagalan disk:
# mdadm /dev/md1 --fail /dev/sde
mdadm: set /dev/sde faulty in /dev/md1
# mdadm --detail /dev/md1
/dev/md1:
[...]
       Update Time : Tue Jun 25 11:03:44 2019
             State : clean, degraded 
    Active Devices : 1
   Working Devices : 1
    Failed Devices : 1
     Spare Devices : 0

Consistency Policy : resync

              Name : mirwiz:1  (local to host debian)
              UUID : 7d123734:9677b7d6:72194f7d:9050771c
            Events : 20

    Number   Major   Minor   RaidDevice State
       -       0        0        0      removed
       1       8       80        1      active sync   /dev/sdd2

       0       8       64        -      faulty   /dev/sde
Isi dari volume masih dapat diakses (dan, jika dipasang, aplikasi tidak menyadari apapun), tapi keselamatan data tidak dijamin lagi: seandainya sdd disk gagal bergantian, data akan hilang. Kami ingin menghindari risiko, jadi kami akan mengganti disk yang gagal dengan yang baru, 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 : Tue Jun 25 11:09:42 2019
             State : clean, degraded, recovering 
    Active Devices : 1
   Working Devices : 2
    Failed Devices : 1
     Spare Devices : 1

Consistency Policy : resync

    Rebuild Status : 27% complete

              Name : mirwiz:1  (local to host debian)
              UUID : 7d123734:9677b7d6:72194f7d:9050771c
            Events : 26

    Number   Major   Minor   RaidDevice State
       2       8       96        0      spare rebuilding   /dev/sdf
       1       8       80        1      active sync   /dev/sdd2

       0       8       64        -      faulty   /dev/sde
# [...]
[...]
# mdadm --detail /dev/md1
/dev/md1:
[...]
       Update Time : Tue Jun 25 11:10:47 2019
             State : clean 
    Active Devices : 2
   Working Devices : 2
    Failed Devices : 1
     Spare Devices : 0

Consistency Policy : resync

              Name : mirwiz:1  (local to host debian)
              UUID : 7d123734:9677b7d6:72194f7d:9050771c
            Events : 39

    Number   Major   Minor   RaidDevice State
       2       8       96        0      active sync   /dev/sdd2
       1       8       80        1      active sync   /dev/sdf

       0       8       64        -      faulty   /dev/sde
Di sini lagi, kernel secara otomatis memicu tahap rekonstruksi yang ketika berlangsung, meskipun volume masih dapat diakses, berada dalam mode terdegradasi. Setelah rekonstruksi berakhir, array RAID kembali ke keadaan normal. Kita kemudian dapat memberitahu ke sistem bahwa disk sde akan dihapus dari array, sehingga berakhir dengan RAID mirror klasik pada dua disk:
# 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
       2       8       96        0      active sync   /dev/sdd2
       1       8       80        1      active sync   /dev/sdf
Selanjutnya drive dapat secara fisik dicabut saat server berikutnya dimatikan, atau bahkan dicabut saat menyala ketika konfigurasi hardware mengizinkan hot-swap. Konfigurasi tersebut termasuk beberapa pengendali SCSI, kebanyakan disk SATA, dan drive eksternal yang beroperasi pada USB atau Firewire.

12.1.1.3. Mem-back up Konfigurasi

Kebanyakan meta-data tentang volume RAID disimpan secara langsung pada disk yang menusun array ini, sehingga kernel dapat mendeteksi array dan komponen mereka dan merakit mereka secara otomatis saat sistem mulai berjalan. Namun, membuat cadangan konfigurasi ini disarankan, karena deteksi ini tidak kebal kesalahan, dan hanya diharapkan bahwa itu akan gagal tepat dalam keadaan yang sensitif. Dalam contoh kita, jika kegagalan disk sde telah nyata (bukan simulasi) dan sistem sudah direstart tanpa menghapus disk sde ini, disk ini bisa mulai bekerja lagi karena telah dijajaki selama reboot. Kernel kemudian akan memiliki tiga elemen fisik, masing-masing mengklaim mengandung setengah dari volume RAID yang sama. Sumber kebingungan lain dapat datang ketika volume RAID dari dua server dikonsolidasi hanya ke satu server. Jika array ini sedang berjalan biasanya sebelum disk dipindahkan, kernel akan mampu mendeteksi dan merakit kembali pasangan dengan benar; tetapi jika disk yang dipindah telah diagregasi ke dalam md1 pada server lama, dan server baru telah memiliki md1, salah satu cermin akan diubah nama.
Karena itu cadangan konfigurasi penting, walaupun hanya untuk referensi. Cara standar untuk melakukannya adalah dengan menyunting berkas /etc/mdadm/mdadm.conf, contohnya tercantum di sini:

Contoh 12.1. berkas konfigurasi mdadm

# mdadm.conf
#
# !NB! Run update-initramfs -u after updating this file.
# !NB! This will ensure that initramfs has an uptodate copy.
#
# 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=146e104f:66ccc06d:71c262d7:9af1fbc7
ARRAY /dev/md1 metadata=1.2 name=mirwiz:1 UUID=7d123734:9677b7d6:72194f7d:9050771c

# This configuration was auto-generated on Tue, 25 Jun 2019 07:54:35 -0400 by mkconf
Salah satu rincian paling berguna adalah opsi DEVICE, yang berisi daftar perangkat tempat sistem akan secara otomatis mencari komponen volume RAID saat start-up. Dalam contoh, kita menggantikan nilai default, partitions containers, dengan daftar eksplisit berkas perangkat, karena kita memilih untuk menggunakan seluruh disk dan tidak hanya partisi, untuk beberapa volume.
Dua baris terakhir dalam contoh kita adalah yang memungkinkan kernel untuk secara aman memilih nomor volume yang ditetapkan ke array mana. Metadata yang tersimpan pada disk itu sendiri cukup untuk membangun kembali volume, tetapi tidak untuk menentukan nomor volume (dan nama perangkat /dev/md* yang cocok).
Untungnya, baris-baris ini dapat dihasilkan secara otomatis:
# mdadm --misc --detail --brief /dev/md?
ARRAY /dev/md0 metadata=1.2 name=mirwiz:0 UUID=146e104f:66ccc06d:71c262d7:9af1fbc7
ARRAY /dev/md1 metadata=1.2 name=mirwiz:1 UUID=7d123734:9677b7d6:72194f7d:9050771c
Isi dari dua baris terakhir ini tidak tergantung pada daftar disk yang disertakan dalam volume. Maka tidak diperlukan untuk meregenerasi baris-baris ini ketika menggantikan disk gagal dengan yang baru. Di sisi lain, perawatan harus diambil untuk memperbarui berkas ketika membuat atau menghapus sebuah array RAID.

12.1.2. LVM

LVM, Logical Volume Manager, adalah pendekatan lain untuk mengabstrakkan volume logis dari dukungan fisik mereka, yang berfokus pada peningkatan fleksibilitas daripada meningkatkan kehandalan. LVM dapat mengubah volume logis secara transparan bagi aplikasi; sebagai contoh, sangat mungkin untuk menambahkan disk baru, memigrasi data ke mereka, dan menghapus disk lama, tanpa melepas kait volume.

12.1.2.1. Konsep LVM

Fleksibilitas ini dicapai dengan tingkat abstraksi yang melibatkan tiga konsep.
Pertama, PV (Physical Volume) adalah entitas terdekat dengan perangkat keras: itu bisa berupa partisi pada disk atau seluruh disk, atau bahkan perangkat blok lain (termasuk, sebagai contoh, sebuah array RAID). Perhatikan bahwa ketika sebuah elemen fisik diatur hingga menjadi PV untuk LVM, itu mesti hanya diakses melalui LVM, jika tidak sistem akan bingung.
Sejumlah PV dapat dikumpulkan dalam VG (Volume Group), yang dapat dibandingkan dengan disk virtual dan extensible. VG abstrak, dan tidak muncul dalam perangkat berkas di hirarki /dev, sehingga tidak ada risiko menggunakan mereka secara langsung.
Jenis ke tiga objek adalah LV (Logical Volume), yang berupa potongan dari suatu VG; jika kita memakai analogi VG-sebagai-disk, LV setara dengan partisi. LV muncul sebagai perangkat blok dengan entri di /dev, dan dapat digunakan seperti setiap partisi fisik lainnya dapat (paling sering, mewadahi sebuah sistem berkas atau ruang swap).
Yang penting adalah bahwa pemisahan VG ke LV sepenuhnya independen dari komponen fisiknya (PV). VG dengan hanya satu komponen fisik (disk misalnya) dapat dipisah menjadi selusin volume logis; demikian pula, sebuah VG dapat menggunakan beberapa disk fisik dan muncul sebagai satu volume logis yang besar. Satu-satunya kendala, jelas, adalah bahwa ukuran total yang dialokasikan untuk LV tidak bisa lebih dari total kapasitas dari PV dalam kelompok volume.
Namun sering masuk akal untuk memiliki semacam keseragaman antara komponen fisik VG, dan untuk membagi VG menjadi volume logis yang akan memiliki pola penggunaan serupa. Misalnya, jika perangkat keras yang tersedia termasuk disk cepat dan disk lambat, yang cepat dapat dikelompokkan ke satu VG dan yang lambat ke lain; potongan pertama dapat kemudian ditugaskan untuk aplikasi yang membutuhkan akses data yang cepat, sementara yang kedua akan disimpan untuk tugas-tugas yang kurang menuntut.
Dalam kasus apapun, perlu diingat bahwa LV tidak perlu melekat ke PV manapun. Dimungkinkan untuk mempengaruhi mana data dari LV secara fisik disimpan, tapi kemungkinan ini tidak diperlukan untuk penggunaan sehari-hari. Sebaliknya: ketika set komponen fisik VG berkembang, lokasi penyimpanan fisik yang sesuai dengan LV tertentu dapat bermigrasi di seluruh disk (dan tentu saja tetap di dalam PVs yang ditugaskan untuk VG).

12.1.2.2. Menyiapkan LVM

Mari kita sekarang ikuti, langkah demi langkah, proses pengaturan LVM untuk kasus penggunaan yang khas: kami ingin menyederhanakan situasi kompleks penyimpanan. Situasi seperti ini biasanya terjadi setelah beberapa sejarah yang panjang dan berbelit dari akumulasi langkah-langkah sementara. Untuk tujuan ilustrasi, kami akan mempertimbangkan server yang kebutuhan penyimpanannya telah berubah dari waktu ke waktu, berakhir dalam labirin dari partisi-partisi yang terpecah ke beberapa disk yang terpakai sebagian. Secara lebih konkret, partisi berikut tersedia:
  • pada disk sdb, sebuah partisi sdb2, 4 GB;
  • pada disk sdc, sebuah partisi sdc3, 3 GB;
  • disk sdd, 4 GB, sepenuhnya tersedia;
  • pada disk sdf, partisi sdf1, 4 GB; dan partisi sdf2, 5 GB.
Selain itu, mari kita asumsikan bahwa disk sdb dan sdf adalah lebih cepat daripada dua lainnya.
Tujuan kami adalah untuk mengatur tiga volume logis untuk tiga aplikasi yang berbeda: server berkas memerlukan ruang penyimpanan 5 GB, sebuah basis data (1 GB) dan ruang untuk back-up (12 GB). Dua yang pertama perlu kinerja yang baik, tapi back-up kurang kritis dalam hal kecepatan akses. Semua kendala ini mencegah penggunaan partisi sendirian; menggunakan LVM dapat mengabstraksi ukuran fisik dari perangkat, sehingga satu-satunya batas adalah jumlah ruang yang tersedia.
Alat-alat yang diperlukan ada dalam paket lvm2 dan dependensinya. Ketika mereka sedang diinstal, pengaturan LVM mengambil tiga langkah, cocok dengan konsep tiga tingkat.
Pertama, kami siapkan volume fisik menggunakan pvcreate:
# 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               z4Clgk-T5a4-C27o-1P0E-lIAF-OeUM-e7EMwq

# 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.00g  3.00g
  /dev/sdd      lvm2 ---   4.00g  4.00g
  /dev/sdf1     lvm2 ---   4.00g  4.00g
  /dev/sdf2     lvm2 ---  <5.00g <5.00g
Sejauh ini, masih baik; perhatikan bahwa PV dapat disiapkan pada seluruh disk maupun pada partisi individunya. Seperti yang ditunjukkan di atas, perintah pvdisplay menampilkan daftar PVs yang ada, dengan dua format keluaran mungkin.
Sekarang mari kita merakit elemen-elemen fisik ini menjadi VG menggunakan vgcreate. Kita akan mengumpulkan hanya PV-PV dari disk cepat ke VG vg_critical; VG lain, vg_normal, juga akan memuat elemen-elemen yang lebih lambat.
# 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               7.99 GiB
  PE Size               4.00 MiB
  Total PE              2046
  Alloc PE / Size       0 / 0   
  Free  PE / Size       2046 / 7.99 GiB
  VG UUID               wAbBjx-d82B-q7St-0KFf-z40h-w5Mh-uAXkNZ

# 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-   7.99g   7.99g
  vg_normal     3   0   0 wz--n- <11.99g <11.99g
Di sini lagi, perintahnya agak sederhana (dan vgdisplay mengusulkan dua format output). Perhatikan bahwa sangat mungkin untuk menggunakan dua partisi dari disk fisik yang sama ke dua VG yang berbeda. Perhatikan juga bahwa kita menggunakan awalan vg_ untuk nama VG kita, tapi itu tidak lebih dari sebuah konvensi.
Kita sekarang memiliki dua "disk virtual", masing-masing berukuran sekitar 8 GB dan 12 GB. Mari kita sekarang mengukir mereka ke dalam "partisi virtual" (LV). Ini melibatkan perintah lvcreate, dan sintaks yang agak lebih kompleks:
# 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                W6XT08-iBBx-Nrw2-f8F2-r2y4-Ltds-UrKogV
  LV Write Access        read/write
  LV Creation host, time debian, 2019-11-30 22:45:46 -0500
  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           254:0

# lvcreate -n lv_base -L 1G vg_critical
  Logical volume "lv_base" created.
# lvcreate -n lv_backups -L 11.98G vg_normal
  Rounding up size to full physical extent 11.98 GiB
  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--- 11.98g
Dua parameter diperlukan ketika membuat volume logis; mereka harus diberikan ke lvcreate sebagai opsi. Nama LV yang akan dibuat ditetapkan dengan opsi -n, dan ukurannya biasanya diberikan menggunakan opsi -L. Tentu saja kita juga perlu memberitahu ke perintah, VG mana yang dikenai operasi, maka diberikanlah parameter terakhir pada baris perintah.
Volume logis, sekali dibuat, akan menjadi berkas perangkat blok dalam /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
Untuk membuat semua lebih mudah, taut simbolik juga dibuat dalam direktori-direktori yang cocok dengan VG:
# 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
LV kemudian dapat digunakan persis seperti partisi standar:
# mkfs.ext4 /dev/vg_normal/lv_backups
mke2fs 1.44.5 (15-Dec-2018)
Discarding device blocks: done                            
Creating filesystem with 3140608 4k blocks and 786432 inodes
Filesystem UUID: b9e6ed2f-cb37-43e9-87d8-e77568446225
Superblock backups stored on blocks: 
	32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208

Allocating group tables: done                            
Writing inode tables: done                            
Creating journal (16384 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   41M   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
Dari sudut pandang aplikasi, berbagai partisi kecil sekarang telah diabstrakkan ke dalam satu volume 12 GB besar, dengan nama yang lebih mudah.

12.1.2.3. LVM Dari Waktu Ke Waktu

Meskipun kemampuan untuk mengagregasi partisi atau disk fisik itu nyaman, ini bukanlah keuntungan utama yang dibawa oleh LVM. Fleksibilitas yang dibawanya terutama teramati seiring berjalannya waktu, ketika kebutuhan berevolusi. Dalam contoh kita, mari kita asumsikan bahwa berkas besar baru harus disimpan, dan bahwa LV yang didedikasikan untuk server berkas terlalu kecil untuk menampung mereka. Karena kita belum menggunakan seluruh ruang yang tersedia di vg_critical, kita bisa perbesar lv_files. Untuk tujuan tersebut, kita akan menggunakan perintah lvresize, lalu resize2fs untuk mengadaptasi sistem berkas:
# df -h /srv/files/
Filesystem                        Size  Used Avail Use% Mounted on
/dev/mapper/vg_critical-lv_files  4.9G  4.2G  485M  90% /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- 7.99g 1.99g
# lvresize -L 6G vg_critical/lv_files
  Size of logical volume vg_critical/lv_files changed from 5.00 GiB (1280 extents) to 6.00 GiB (1536 extents).
  Logical volume vg_critical/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---- 6.00g
# resize2fs /dev/vg_critical/lv_files
resize2fs 1.44.5 (15-Dec-2018)
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 1572864 (4k) blocks long.

# df -h /srv/files/
Filesystem                        Size  Used Avail Use% Mounted on
/dev/mapper/vg_critical-lv_files  5.9G  4.2G  1.5G  75% /srv/files
Kita bisa melanjutkan dengan cara yang sama untuk memperbesar volume yang mewadai basis data, tapi kita telah mencapai batas ruang VG yang tersedia:
# df -h /srv/base/
Filesystem                       Size  Used Avail Use% Mounted on
/dev/mapper/vg_critical-lv_base  976M  882M   28M  97% /srv/base
# vgdisplay -C vg_critical
  VG          #PV #LV #SN Attr   VSize VFree   
  vg_critical   2   2   0 wz--n- 7.99g 1016.00m
Tidak masalah, karena LVM memungkinkan menambahkan volume fisik ke grup volume yang ada. Misalnya, mungkin kita telah memperhatikan bahwa partisi sdb1, yang sejauh ini digunakan di luar LVM, hanya berisi arsip yang dapat dipindahkan ke lv_backups. Kita sekarang dapat mendaur ulang itu dan mengintegrasikannya ke grup volume, dan dengan demikian memperoleh kembali ruang bebas. Ini adalah tujuan dari perintah vgextend. Tentu saja, partisi harus disiapkan sebagai sebuah volume fisik terlebih dahulu. Setelah VG telah diperbesar, kita dapat menggunakan perintah sejenis seperti yang sebelumnya untuk menumbuhkan volume logis kemudian sistem berkasnya:
# 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.99g <1.99g
# [...]
[...]
# df -h /srv/base/
Filesystem                       Size  Used Avail Use% Mounted on
/dev/mapper/vg_critical-lv_base  2.0G  882M  994M  48% /srv/base

12.1.3. RAID atau LVM?

RAID dan LVM keduanya membawa keuntungan tak terbantahkan bila kita abaikan kasus sederhana komputer desktop dengan satu hard disk dengan pola penggunaan tidak berubah dari waktu ke waktu. Namun, RAID dan LVM mengambil arah yang berbeda, dengan tujuan divergen, dan sah-sah saja bertanya-tanya mana yang harus diambil. Jawaban paling tepat akan tentu saja tergantung pada kebutuhan saat ini dan masa mendatang.
Ada beberapa kasus sederhana dimana pertanyaan tidak benar-benar muncul. Jika kebutuhan adalah untuk mengamankan data terhadap kegagalan perangkat keras, maka jelas RAID akan disiapkan pada array disk, karena LVM tidak benar-benar menjawab masalah ini. Si sisi lain, jika kebutuhan adalah untuk skema penyimpanan yang fleksibel dimana volume dibuat independen terhadap tata letak fisik dari disk, RAID tidak banyak membantu dan LVM akan menjadi pilihan yang tepat.
Use case ketiga yang menarik adalah ketika seseorang hanya ingin mengagregat dua disk ke dalam satu volume, baik untuk alasan kinerja atau memiliki sistem berkas tunggal yang lebih besar daripada salah satu disk yang tersedia. Hal ini dapat dijawab oleh RAID 0 (atau bahkan linear-RAID) maupun dengan volume LVM. Dalam situasi ini, dan tanpa batasan tambahan kendala (misalnya, menjaga sejalan dengan sisa komputer jika mereka hanya menggunakan RAID), konfigurasi pilihan akan seringkali adalah LVM. Penyiapan awal hampir tidak lebih kompleks, dan bahwa sedikit peningkatan kompleksitas terbayar oleh fleksibilitas tambahan yang dibawah oleh LVM jika persyaratan berubah atau jika disk baru perlu ditambahkan.
Kemudian tentu saja, ada kasus penggunaan yang benar-benar menarik, dimana sistem penyimpanan perlu dibuat tahan terhadap kegagalan perangkat keras dan fleksibel tentang alokasi volume. RAID maupun LVM masing-masing dapat menjawab kedua persyaratan; ini adalah di mana kita menggunakan keduanya pada saat yang sama -- atau lebih tepatnya, satu di atas yang lain. Skema yang memiliki semua tapi belum menjadi standar karena RAID dan LVM telah mencapai kedewasaan untuk memastikan redundansi data pertama dengan pengelompokan disk dalam sejumlah kecil larik RAID besar, dan menggunakan larik RAID ini sebagai volume fisik LVM; partisi logis kemudian dapat ditoreh dari LV-LV ini untuk sistem berkas. Nilai jual konfigurasi ini adalah bahwa ketika sebuah disk gagal, hanya sejumlah kecil larik RAID yang perlu dibangun kembali, sehingga membatasi waktu yang dihabiskan oleh administrator untuk pemulihan.
Mari kita ambil contoh konkret: departemen hubungan masyarakat di Falcot Corp memerlukan sebuah workstation untuk penyuntingan video, tapi anggaran departemen tidak mengizinkan berinvestasi di perangkat keras kelas tinggi secara lengkap. Keputusan dibuat untuk mendukung perangkat keras yang khusus untuk sifat grafis pekerjaan (monitor dan kartu video), dan tetap dengan perangkat keras generik untuk penyimpanan. Namun, seperti sudah dikenal luas, video digital memiliki beberapa persyaratan khusus untuk penyimpanan: banyaknya data yang akan disimpan besar, dan kecepatan pembacaan dan penulisan data ini penting untuk keseluruhan kinerja sistem (lebih daripada waktu akses rata-rata, misalnya). Batasan-batasn ini perlu dipenuhi dengan perangkat keras generik, dalam kasus ini dua hard disk drive SATA 300 GB; data sistem juga harus dibuat tahan terhadap kegagalan perangkat keras, termasuk sebagian data pengguna. Klip video yang diedit memang harus aman, tetapi tidak perlu bergegas menyunting video yang tertunda, karena mereka masih berada pada kaset.
RAID-1 dan LVM digabungkan untuk memenuhi batasan-batasan ini. Disk dilekatkan pada dua pengendali SATA yang berbeda untuk mengoptimalkan akses paralel dan mengurangi risiko kegagalan simultan, dan karena itu mereka muncul sebagai sda dan sdc. Mereka dipartisi secara identik mengikut skema sebagai berikut:
# 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
  • Partisi pertama dari kedua disk (sekitar 1 GB) dirakit menjadi volume RAID-1, md0. Cermin ini langsung digunakan untuk menyimpan sistem berkas root.
  • Partisi sda2 dan sdc2 digunakan sebagai partisi swap, menyediakan total 2 GB ruang swap. Dengan RAM 1 GB, workstation memiliki sejumlah memori tersedia yang nyaman.
  • sda5 dan partisi sdc5, serta sda6 dan sdc6, dirakit menjadi dua volume RAID-1 baru masing-masing sekitar 100 GB, md1 dan md2 . Kedua cermin diinisialisasi sebagai volume fisik untuk LVM, dan ditugaskan ke grup volume vg_raid. Maka VG ini berisi ruang sekitar 200 GB yang aman.
  • Sisa partisi, sda7 dan sdc7, langsung digunakan sebagai volume fisik, dan ditugaskan untuk VG lain yang disebut vg_bulk, yang karena itu menjadi ruang sekitar 200 GB.
Setelah VGs dibuat, mereka dapat dipartisi dengan cara yang sangat fleksibel. Harus tetap diingat bahwa LV yang dibuat dalam vg_raid akan dipertahankan bahkan jika salah satu disk gagal, yang tidak akan terjadi untuk LV dibuat di vg_bulk; di sisi lain, yang kedua akan dialokasikan secara paralel pada kedua disk, yang memungkinkan kecepatan baca atau tulis yang lebih tinggi untuk berkas-berkas besar.
Karena itu kita akan membuat LV lv_var, dan lv_home pada vg_raid, untuk mewadahi sistem berkas yang cocok; LV besar lain, lv_movies, akan digunakan untuk mewadahi film-film versi definitif setelah penyuntingan. VG lain akan dibagi menjadi lv_rushesyang besar, untuk data langsung dari kamera video digital, dan lv_tmp untuk berkas-berkas sementara. Lokasi area kerja adalah pilihan yang kurang mudah untuk dibuat: sementara kinerja yang baik diperlukan untuk volume itu, apakah layak risiko kehilangan pekerjaan jika disk gagal selama sesi menyunting? Tergantung pada jawaban untuk pertanyaan itu, LV yang relevan akan dibuat pada satu VG atau yang lain.
Kita sekarang memiliki sebagian redundansi untuk data penting dan banyak fleksibilitas dalam bagaimana ruang yang tersedia dibagi atas berbagai aplikasi.