Bab 12. Administrasi Tingkat Lanjut

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 penggelaran 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.

PERSPEKTIF Btrfs menggabung LVM dan RAID

Walaupun LVM dan RAID adalah dua sub sistem kernel yang berbeda, yang hadir di antara perangkat blok disk dan sistem berkas mereka, btrfs adalah suatu sistem berkas, yang pada awalnya dikembangkan di Oracle, yang bertujuan menggabung set fitur dari LVM dan RAID serta lebih banyak lagi.

→ https://btrfs.wiki.kernel.org/

Diantara fitur yang menarik adalah kemampuan membuat snapshot dari suatu pohon sistem berkas pada sebarang waktu. Snapshot ini pada awalnya tak memakai sebarang ruang disk, data hanya diduplikasi ketika satu dari salinan-salinan dimodifikasi. Sistem berkas juga menangani kompresi transparan dari berkas, dan checksum memastikan integritas dari semua data yang disimpan.

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.
CATATAN Ukuran klaster dan disk
Jika dua disk dengan ukuran yang berbeda diatur dalam cermin, yang lebih besar tidak akan sepenuhnya digunakan, karena itu akan berisi data yang sama seperti yang terkecil dan tidak lebih. Ruang tersedia yang berguna yang disediakan oleh volume RAID-1 karena itu cocok dengan ukuran disk terkecil dalam array. Ini masih berlaku untuk volume RAID dengan tingkat yang lebih tinggi, meskipun redundansi disimpan dengan cara berbeda.
Karena itu penting, ketika menyiapkan array RAID (kecuali RAID-0 dan "linear RAID"), untuk menyusun hanya disk-disk berukuran identik atau sangat dekat, untuk menghindari membuang-buang sumber daya.
CATATAN Disk cadangan
Tingkat RAID yang mencakup redundansi memungkinkan menugaskan disk lebih banyak dari yang dibutuhkan untuk array. Tambahan disk digunakan sebagai suku cadang ketika salah satu disk utama gagal. Sebagai contoh, cermin dua disk ditambah cadangan satu, jika salah satu disk dari dua pertama gagal, kernel akan otomatis (dan segera) merekonstruksi cermin menggunakan disk cadangan, sehingga redundansi tetap terjamin setelah masa rekonstruksi. Ini dapat digunakan sebagai jenis lain dari perlindungan bagi data penting.
Kita akan dimaafkan untuk bertanya-tanya bagaimana hal ini lebih baik daripada sekadar mencerminkan pada tiga disk di awal. Keuntungan dari konfigurasi "disk cadangan" adalah bahwa disk cadangan dapat dipakai bersama pada beberapa volume RAID. Sebagai contoh, kita dapat memiliki tiga volume tercermin, dengan redundansi yang dijamin bahkan jika salah satu kegagalan disk, hanya dengan tujuh disk (tiga pasang, ditambah satu cadangan bersama), bukan sembilan disk yang akan dibutuhkan oleh tiga buah kembar tiga.
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.
HATI-HATI RAID bukanlah Backup
Sistem RAID bukanlah mekanisme cadangan. Sementara RAID meningkatkan redundansi - dan oleh karena itu ketersediaan sistem - dan melindungi terhadap kegagalan disk, pencadangan dilakukan untuk melindungi data agar tidak diubah, dihapus, rusak, dll., dan untuk dapat memulihkannya jika perlu. Untuk menunjukkan ini: Jika Anda menghapus satu atau semua berkas secara tidak sengaja, RAID akan mencerminkan perubahan ini, tetapi tidak akan menyediakan sarana untuk memulihkan berkas. Jadi meskipun jelas ada tumpang tindih, mereka tidak sama dan harus digunakan bersama satu sama lain.
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.
LEBIH JAUH RAID-10
RAID-10 umumnya dianggap sebagai sinonim dari RAID-1+0, namun kekhususan Linux membuat itu sebenarnya generalisasi. Konfigurasi ini memungkinkan sistem dimana setiap blok disimpan pada dua disk berbeda, bahkan dengan cacah disk ganjil, salinan disebar ke model yang dapat dikonfigurasi.
Kinerja akan bervariasi tergantung pada model repartisi dan tingkat redundansi yang dipilih, dan beban kerja dari volume logis.

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: 7.99GiB raid0 2 devices, 0 spares. Use mdadm --detail for more detail.
# mdadm --detail /dev/md0
/dev/md0:
           Version : 1.2
     Creation Time : Mon Feb 28 01:54:24 2022
        Raid Level : raid0
        Array Size : 8378368 (7.99 GiB 8.58 GB)
      Raid Devices : 2
     Total Devices : 2
       Persistence : Superblock is persistent

       Update Time : Mon Feb 28 01:54:24 2022
             State : clean 
    Active Devices : 2
   Working Devices : 2
    Failed Devices : 0
     Spare Devices : 0

            Layout : -unknown-
        Chunk Size : 512K

Consistency Policy : none

              Name : debian:0  (local to host debian)
              UUID : a75ac628:b384c441:157137ac:c04cd98c
            Events : 0

    Number   Major   Minor   RaidDevice State
       0       8        0        0      active sync   /dev/sdb
       1       8       16        1      active sync   /dev/sdc
# mkfs.ext4 /dev/md0
mke2fs 1.46.2 (28-Feb-2021)
Discarding device blocks: done                            
Creating filesystem with 2094592 4k blocks and 524288 inodes
Filesystem UUID: ef077204-c477-4430-bf01-52288237bea0
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.8G   24K  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/sdc2) exceeds size (4189184K) 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 : Mon Feb 28 02:07:48 2022
        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 : Mon Feb 28 02:08:09 2022
             State : clean, resync
    Active Devices : 2
   Working Devices : 2
    Failed Devices : 0
     Spare Devices : 0

Consistency Policy : resync

    Rebuild Status : 13% complete

              Name : debian:1  (local to host debian)
              UUID : 2dfb7fd5:e09e0527:0b5a905a:8334adb8
            Events : 17

    Number   Major   Minor   RaidDevice State
       0       8       34        0      active sync   /dev/sdd2
       1       8       48        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.

TIPS Memulai mirror dalam mode terdegradasi

Kadang-kadang dua disk tidak tersedia seketika saat seseorang ingin memulai suatu cermin RAID-1, misalnya karena salah satu disk yang rencananya akan disertakan sudah digunakan untuk menyimpan data yang ingin dipindah ke array. Dalam keadaan seperti itu, dimungkinkan untuk sengaja menciptakan array RAID-1 yang terdegradasi dengan memberikan missing, bukan berkas perangkat sebagai salah satu argumen untuk mdadm. Setelah data telah disalin ke "cermin", disk lama dapat ditambahkan ke array. Sinkronisasi kemudian akan terjadi, memberikan kita redundansi yang diinginkan di awal.

TIPS Menyiapkan cermin tanpa sinkronisasi

Volume RAID-1 sering dibuat untuk digunakan sebagai disk baru, sering dianggap kosong. Isi awal sebenarnya dari disk ini karena itu tidak sangat relevan, karena hanya perlu diketahui bahwa data setelah penciptaan volume, khususnya sistem berkas, dapat diakses setelahnya.

Karena itu orang mungkin bertanya-tanya tentang titik sinkronisasi kedua disk pada waktu penciptaan. Mengapa peduli apakah isi identik pada zona volume yang kita ketahui hanya dapat dibaca setelah kita telah menulis?

Untungnya, tahap sinkronisasi ini dapat dihindari dengan memberikan opsi --assume-clean untuk mdadm. Namun, pilihan ini dapat menyebabkan kejutan dalam kasus-kasus di mana data awal akan dibaca (misalnya jika sistem berkas tersebut sudah hadir pada disk fisik), itulah sebabnya itu tidak diaktifkan secara default.

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:
           Version : 1.2
     Creation Time : Mon Feb 28 02:07:48 2022
        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 : Mon Feb 28 02:15:34 2022
             State : clean, degraded 
    Active Devices : 1
   Working Devices : 1
    Failed Devices : 1
     Spare Devices : 0

Consistency Policy : resync

              Name : debian:1  (local to host debian)
              UUID : 2dfb7fd5:e09e0527:0b5a905a:8334adb8
            Events : 19

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

       1       8       48        -      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:
           Version : 1.2
     Creation Time : Mon Feb 28 02:07:48 2022
        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 : 3
       Persistence : Superblock is persistent

       Update Time : Mon Feb 28 02:25:34 2022
             State : clean, degraded, recovering 
    Active Devices : 1
   Working Devices : 2
    Failed Devices : 1
     Spare Devices : 1

Consistency Policy : resync

    Rebuild Status : 47% complete

              Name : debian:1  (local to host debian)
              UUID : 2dfb7fd5:e09e0527:0b5a905a:8334adb8
            Events : 39

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

       1       8       48        -      faulty   /dev/sde
# [...]
[...]
# mdadm --detail /dev/md1
/dev/md1:
           Version : 1.2
     Creation Time : Mon Feb 28 02:07:48 2022
        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 : 3
       Persistence : Superblock is persistent

       Update Time : Mon Feb 28 02:25:34 2022
             State : clean
    Active Devices : 2
   Working Devices : 2
    Failed Devices : 1
     Spare Devices : 0

Consistency Policy : resync

              Name : debian:1  (local to host debian)
              UUID : 2dfb7fd5:e09e0527:0b5a905a:8334adb8
            Events : 41

    Number   Major   Minor   RaidDevice State
       0       8       34        0      active sync   /dev/sdd2
       2       8       64        1      active sync   /dev/sdf

       1       8       48        -      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
       0       8       34        0      active sync   /dev/sdd2
       2       8       64        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 menyusun 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 adalah nyata (bukan simulasi) dan sistem sudah di-restart 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*

# 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/md/0  metadata=1.2 UUID=a75ac628:b384c441:157137ac:c04cd98c name=debian:0
ARRAY /dev/md/1  metadata=1.2 UUID=2dfb7fd5:e09e0527:0b5a905a:8334adb8 name=debian:1
# This configuration was auto-generated on Mon, 28 Feb 2022 01:53:48 +0100 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/md/0  metadata=1.2 UUID=a75ac628:b384c441:157137ac:c04cd98c name=debian:0
ARRAY /dev/md/1  metadata=1.2 UUID=2dfb7fd5:e09e0527:0b5a905a:8334adb8 name=debian:1

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               yK0K6K-clbc-wt6e-qk9o-aUh9-oQqC-k1T71B

# 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               JgFWU3-emKg-9QA1-stPj-FkGX-mGFb-4kzy1G

# 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                Nr62xe-Zu7d-0u3z-Yyyp-7Cj1-Ej2t-gw04Xd
  LV Write Access        read/write
  LV Creation host, time debian, 2022-03-01 00:17:46 +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 11.98G vg_normal
  Rounding up size to full physical extent 11.98 GiB
  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.

LEBIH JAUH opsi-opsi lvcreate

Perintah lvcreate memiliki beberapa opsi untuk memungkinkan menala atas bagaimana cara LV dibuat.

Mari kita pertama menjelaskan opsi -l, dengannya ukuran LV dapat diberikan sebagai cacah blok (sebagai lawan dari unit "manusia" yang kita digunakan di atas). Blok-blok ini (disebut PE, physical extents dalam istilah LVM) adalah unit-unit ruang penyimpanan yang bersebelahan di PV, dan mereka tidak dapat dipecah di LV. Ketika seseorang ingin menentukan ruang penyimpanan untuk LV secara cukup presisi, misalnya menggunakan seluruh ruang yang tersedia, opsi -l mungkin akan lebih disukai daripada -L.

Memungkinkan juga untuk menunjuk pada lokasi fisik LV, sehingga extent disimpan pada PV tertentu (tentu saja masih tetap ada di dalam yang ditugaskan untuk VG). Karena kita tahu bahwa sdb lebih cepat daripada sdf, kita mungkin ingin menyimpan lv_base di sana jika kita ingin memberikan keuntungan kepada server basis data dibandingkan dengan server berkas. Baris perintah menjadi: lvcreate -n lv_base -L 1G vg_critical /dev/sdb2. Perhatikan bahwa perintah ini bisa gagal jika PV tidak memiliki cukup extent bebas. Dalam contoh kita, kita mungkin harus membuat lv_base sebelum lv_files untuk menghindari situasi ini - atau membebaskan sebagian ruang di sdb2 dengan perintah pvmove.

Volume logis, sekali dibuat, akan menjadi berkas perangkat blok dalam /dev/mapper/:

# ls -l /dev/mapper
total 0
crw------- 1 root root 10, 236 Mar  1 00:17 control
lrwxrwxrwx 1 root root       7 Mar  1 00:19 vg_critical-lv_base -> ../dm-1
lrwxrwxrwx 1 root root       7 Mar  1 00:17 vg_critical-lv_files -> ../dm-0
lrwxrwxrwx 1 root root       7 Mar  1 00:19 vg_normal-lv_backups -> ../dm-2 
# ls -l /dev/dm-*
brw-rw---- 1 root disk 253, 0 Mar  1 00:17 /dev/dm-0
brw-rw---- 1 root disk 253, 1 Mar  1 00:19 /dev/dm-1
brw-rw---- 1 root disk 253, 2 Mar  1 00:19 /dev/dm-2

CATATAN Mendeteksi otomatis volume LVM

Ketika komputer boot, unit layanan systemd lvm2-activation mengeksekusi vgchange -aay untuk "mengaktifkan" kelompok volume: memindai perangkat yang tersedia; yang telah diinisialisasi sebagai fisik untuk LVM didaftarkan ke subsistem LVM, yang berasal dari kelompok-kelompok volume dirakit, dan volume logis yang relevan dimulai dan dibuat tersedia. Karena itu tidak perlu menyunting berkas konfigurasi ketika membuat atau memodifikasi volume-volume LVM.

Namun, perlu diketahui bahwa tata letak elemen LVM (volume fisik dan logis, dan kelompok-kelompok volume) direkam cadang dalam /etc/lvm/backup, yang dapat berguna dalam hal ada masalah (atau hanya untuk sekedar mengintip di balik layar).

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 Mar  1 00:19 lv_base -> ../dm-1
lrwxrwxrwx 1 root root 7 Mar  1 00:17 lv_files -> ../dm-0 
# ls -l /dev/vg_normal
total 0
lrwxrwxrwx 1 root root 7 Mar  1 00:19 lv_backups -> ../dm-2

LV kemudian dapat digunakan persis seperti partisi standar:

# mkfs.ext4 /dev/vg_normal/lv_backups
mke2fs 1.46.2 (28-Feb-2021)
Discarding device blocks: done                            
Creating filesystem with 3140608 4k blocks and 786432 inodes
Filesystem UUID: 7eaf0340-b740-421e-96b2-942cdbf29cb3
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   24K   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.46.2 (28-Feb-2021)
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

HATI-HATI Mengubah ukuran sistem berkas

Tidak semua sistem berkas dapat diubah ukurannya secara daring; mengubah ukuran volume oleh karena itu mungkin pertama memerlukan melepas kait sistem berkas dan mengait ulang setelah itu. Tentu saja, jika seseorang ingin mengecilkan ruang yang dialokasikan untuk LV, sistem berkas harus diperkecil dulu; urutan dibalik ketika perubahan ukuran untuk arah lain: volume logis harus diperbesar sebelum sistem berkas di atasnya. Hal ini cukup sederhana, karena kapanpun ukuran sistem tidak boleh lebih besar dari perangkat blok tempat dia berada (apakah perangkat berupa partisi fisik atau volume logis).

Sistem berkas ext3, ext4, dan xfs dapat diperbesar secara daring, tanpa melepas kain; menyusutkan memerlukan melepas kait. Sistem berkas reiserfs memungkinkan perubahan ukuran secara daring di kedua arah. ext2 tidak memungkinkan keduanya, dan selalu membutuhkan melepas kait.

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  974M  883M   25M  98% /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 sdb3, 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/sdb3
  Physical volume "/dev/sdb3" successfully created.
# vgextend vg_critical /dev/sdb3
  Volume group "vg_critical" successfully extended
# vgdisplay -C vg_critical
  VG          #PV #LV #SN Attr   VSize   VFree 
  vg_critical   3   2   0 wz--n- <12.99g <5.99g 
# lvresize -L 2G vg_critical/lv_base
[...]
# resize2fs /dev/vg_critical/lv_base
[...]
# df -h /srv/base/
Filesystem                       Size  Used Avail Use% Mounted on
/dev/mapper/vg_critical-lv_base  2.0G  886M  991M  48% /srv/base

LEBIH JAUH LVM tingkat lanjut

LVM juga melayani untuk penggunaan tingkat lanjut, dimana banyak rincian dapat dinyatakan secara manual. Misalnya, administrator dapat menala ukuran blok yang membuat volume fisik dan logis, serta letak fisik mereka. Juga mungkin untuk memindahkan blok di PV, misalnya untuk menala halus kinerja atau, dalam cara yang lebih biasa, untuk membebaskan PV ketika kita perlu mengekstrak disk fisik yang sesuai dari VG (baik untuk mempengaruhi bagi VG lain atau menghapusnya dari LVM sama sekali). Halaman manual yang menguraikan perintah umumnya jelas dan rinci. Titik awal yang baik adalah halaman manual lvm(8).

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.

CATATAN Jika kinerja penting…

Jika kecepatan masukan/keluar adalah esensinya, terutama dalam hal waktu akses, menggunakan LVM dan/atau RAID di salah satu dari banyak kombinasi mungkin memiliki dampak pada kinerja, dan ini mungkin mempengaruhi keputusan untuk memilih yang mana. Namun, perbedaan-perbedaan dalam kinerja benar-benar kecil, dan hanya terukur dalam beberapa kasus penggunaan. Jika kinerja penting, keuntungan terbaik yang diperoleh adalah menggunakan media penyimpanan bukan rotasi (solid-state drive atau SSD); biaya per mega byte mereka lebih tinggi daripada hard disk drive standar, dan kapasitas mereka biasanya lebih kecil, tapi mereka memberikan kinerja yang sangat baik untuk akses acak. Jika pola penggunaan mencakup banyak operasi keluaran/masukan yang terpencar di seluruh sistem berkas, misalnya untuk basis data tempat query-query yang kompleks rutin dijalankan, maka keuntungan dari menjalankan mereka pada SSD jauh lebih besar daripada apa pun yang bisa diperoleh dengan memilih LVM atas RAID atau sebaliknya. Dalam situasi ini, pilihan harus ditentukan oleh pertimbangan selain murni kecepatan, karena aspek kinerja paling mudah ditangani dengan menggunakan SSD.

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-batasan 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 disunting memang harus aman, tetapi tidak perlu bergegas menyunting video yang tertunda, karena mereka masih berada pada tape video.

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:

# sfdisk -l /dev/sda
Disk /dev/sda: 894.25 GiB, 960197124096 bytes, 1875385008 sectors
Disk model: SAMSUNG MZ7LM960
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: gpt
Disk identifier: BB14C130-9E9A-9A44-9462-6226349CA012

Device         Start        End   Sectors   Size Type
/dev/sda1        2048       4095      2048     1M BIOS boot
/dev/sda2        4096  100667391 100663296    48G Linux RAID
/dev/sda3   100667392  134221823  33554432    16G Linux RAID
/dev/sda4   134221824  763367423 629145600   300G Linux RAID
/dev/sda5   763367424 1392513023 629145600   300G Linux RAID
/dev/sda6  1392513024 1875384974 482871951 230.3G Linux LVM

Partisi pertama dari kedua disk adalah partisi boot BIOS.
Kedua partisi selanjutnya sda2 and sdc2 (sekitar 48 GB) dirakit menjadi volume RAID-1, md0. Cermin ini langsung digunakan untuk menyimpan sistem berkas root.
Partisi sda3 dan sdc3 dirakit ke dalam sebuah volume RAID-0, md1, dan digunakan sebagai partisi swap, menyediakan total 32 GB ruang swap. Sistem modern dapat menyediakan banyak RAM dan sistem kami tidak akan memerlukan hibernasi. Maka dengan sebanyak ini ditambahkan, sistem kami sangat mungkin tidak akan kehabisan memori.
Partisi sda4 dan sdc4, maupun sda5 dan sdc5, dirakit menjadi dua volume RAID-1 baru masing-masing sekitar 300 GB, md2 dan md3 . Kedua cermin diinisialisasi sebagai volume fisik untuk LVM, dan ditugaskan ke grup volume vg_raid. Maka VG ini berisi ruang sekitar 600 GB yang aman.
Sisa partisi, sda6 dan sdc6, langsung digunakan sebagai volume fisik, dan ditugaskan untuk VG lain yang disebut vg_bulk, yang karena itu berakhir dengan ruang sekitar 460 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.

CATATAN Mengapa tiga volume RAID-1?

Kita bisa saja menyiapkan hanya satu volume RAID-1, untuk melayani sebagai volume fisik bagi vg_raid. Lalu mengapa membuat tiga?

Alasan untuk pemecahan pertama (md0 vs yang lain) adalah tentang keamanan data: data yang ditulis ke kedua elemen dari cermin RAID 1 persis sama, dan karena itu mungkin untuk melewati lapisan RAID dan mengait salah satu disk secara langsung. Dalam kasus bug kernel, misalnya, atau jika metadata LVM menjadi rusak, itu masih mungkin untuk mem-boot sistem minimal untuk mengakses data penting seperti tata letak disk dalam RAID dan volume LVM; metadata dapat kemudian direkonstruksi dan berkas dapat diakses lagi, sehingga sistem dapat dibawa kembali ke keadaan nominal.

Alasan untuk pemecahan kedua (md2 vs md3) kurang jelas, dan lebih berkaitan dengan mengakui bahwa masa depan itu tidak pasti. Ketika workstation pertama dirakit, persyaratan penyimpanan yang eksak tidak selalu diketahui dengan ketepatan yang sempurna; mereka juga dapat berkembang dari waktu ke waktu. Dalam kasus ini, kita tidak dapat mengetahui terlebih dahulu persyaratan ruang penyimpanan sebenarnya untuk video yang buru-buru dan klip video yang lengkap. Jika satu klip tertentu membutuhkan sejumlah yang sangat besar pekerjaan buru-buru, dan VG yang didedikasikan untuk data redundan masih terisi kurang dari setengah, kita dapat memakai kembali ruang yang tidak dibutuhkan. Kita dapat menghapus salah satu volume fisik, misalnya md3, dari vg_raid dan menambahkannya ke vg_bulk secara langsung (jika durasi operasi yang diharapkan cukup singkat sehingga kita dapat hidup dengan penurunan kinerja sementara), atau membatalkan penyiapan RAID pada md3 dan mengintegrasikan komponennya sda5 dan sdc5 ke VG curah (yang bertambah 600 GB, bukan 300 GB); volume logis lv_rushes dapat kemudian ditumbuhkan sesuai kebutuhan.