Ringkasan
Risiko menggunakan LVM:
- Rentan untuk menulis masalah caching dengan SSD atau VM hypervisor
- Sulit untuk memulihkan data karena struktur pada disk yang lebih kompleks
- Sulit mengubah ukuran sistem file dengan benar
- Snapshots sulit digunakan, lambat dan bermasalah
- Membutuhkan beberapa keterampilan untuk mengkonfigurasi dengan benar mengingat masalah ini
Dua masalah LVM pertama bergabung: jika cache tulis tidak berfungsi dengan benar dan Anda mengalami kehilangan daya (mis. PSU atau UPS gagal), Anda mungkin harus memulihkan dari cadangan, yang berarti downtime yang signifikan. Alasan utama untuk menggunakan LVM adalah waktu kerja yang lebih tinggi (saat menambahkan disk, mengubah ukuran sistem file, dll), tetapi penting untuk mendapatkan pengaturan caching penulisan yang benar untuk menghindari LVM yang sebenarnya mengurangi waktu kerja.
- Diperbarui Desember 2018: materi snapshot yang diperbarui, termasuk stabilitas ZFS dan btrf sebagai alternatif untuk snapshot LVM
Mengurangi risiko
LVM masih dapat bekerja dengan baik jika Anda:
- Dapatkan pengaturan caching tulis Anda tepat di hypervisor, kernel, dan SSD
- Hindari snapshot LVM
- Gunakan versi LVM terbaru untuk mengubah ukuran sistem file
- Punya cadangan yang bagus
Detail
Saya sudah meneliti ini sedikit di masa lalu setelah mengalami beberapa kehilangan data yang terkait dengan LVM. Risiko dan masalah LVM utama yang saya ketahui adalah:
Rentan terhadap caching penulisan hard disk karena hypervisor VM, caching disk atau kernel Linux lama , dan membuatnya lebih sulit untuk memulihkan data karena struktur on-disk yang lebih kompleks - lihat detail di bawah ini. Saya telah melihat setup LVM lengkap pada beberapa disk rusak tanpa ada kesempatan untuk pulih, dan LVM plus caching menulis hard disk adalah kombinasi yang berbahaya.
- Menulis caching dan menulis ulang pemesanan dengan hard drive penting untuk kinerja yang baik, tetapi dapat gagal untuk menyiram blok ke disk dengan benar karena VM hypervisors, caching penulisan hard drive, kernel Linux lama, dll.
- Hambatan tulis berarti kernel menjamin bahwa kernel tersebut akan menyelesaikan penulisan disk tertentu sebelum penulisan disk "penghalang", untuk memastikan bahwa sistem file dan RAID dapat pulih jika terjadi kehilangan daya atau kerusakan tiba-tiba. Hambatan tersebut dapat menggunakan operasi FUA (Force Unit Access) untuk segera menulis blok tertentu ke disk, yang lebih efisien daripada flush cache penuh. Hambatan dapat dikombinasikan dengan antrian perintah tag / asli efisien (mengeluarkan beberapa permintaan I / O disk sekaligus) untuk memungkinkan hard drive untuk melakukan pemesanan ulang penulisan cerdas tanpa meningkatkan risiko kehilangan data.
- VM hypervisor dapat memiliki masalah yang serupa: menjalankan LVM di tamu Linux di atas hypervisor VM seperti VMware, Xen , KVM, Hyper-V atau VirtualBox dapat membuat masalah yang mirip dengan kernel tanpa hambatan penulisan, karena menulis caching dan menulis ulang -Memerintah. Periksa dokumentasi hypervisor Anda dengan saksama untuk opsi "flush to disk" atau cache write-through (ada dalam KVM , VMware , Xen , VirtualBox , dan lainnya) - dan mengujinya dengan pengaturan Anda. Beberapa hypervisor seperti VirtualBox memiliki pengaturan default yang mengabaikan sembarang disk dari tamu.
- Server perusahaan dengan LVM harus selalu menggunakan pengontrol RAID yang didukung baterai dan menonaktifkan caching penulisan hard disk (pengontrol memiliki cache tulis yang didukung baterai yang cepat dan aman) - lihat komentar ini oleh penulis entri FAQ XFS ini . Mungkin juga aman untuk mematikan hambatan penulisan di kernel, tetapi pengujian disarankan.
- Jika Anda tidak memiliki pengontrol RAID yang didukung baterai, menonaktifkan caching penulisan hard drive akan memperlambat penulisan secara signifikan tetapi membuat LVM aman. Anda juga harus menggunakan
data=ordered
opsi ext3 yang setara (atau data=journal
untuk keamanan ekstra), plus barrier=1
untuk memastikan bahwa caching kernel tidak memengaruhi integritas. (Atau gunakan ext4 yang memungkinkan hambatan secara default .) Ini adalah opsi paling sederhana dan memberikan integritas data yang baik dengan biaya kinerja. (Linux mengubah opsi ext3 default ke yang lebih berbahaya data=writeback
beberapa waktu lalu, jadi jangan mengandalkan pengaturan default untuk FS.)
- Untuk menonaktifkan caching penulisan hard drive : tambahkan
hdparm -q -W0 /dev/sdX
untuk semua drive dalam /etc/rc.local
(untuk SATA) atau gunakan sdparm untuk SCSI / SAS. Namun, sesuai dengan entri ini di XFS FAQ (yang sangat bagus tentang topik ini), drive SATA mungkin melupakan pengaturan ini setelah pemulihan kesalahan drive - jadi Anda harus menggunakan SCSI / SAS, atau jika Anda harus menggunakan SATA lalu letakkan perintah hdparm dalam pekerjaan cron berjalan setiap menit atau lebih.
- Untuk tetap mengaktifkan cache penyimpanan SSD / hard drive untuk kinerja yang lebih baik: ini adalah area yang kompleks - lihat bagian di bawah ini.
- Jika Anda menggunakan drive Format Lanjutan yaitu sektor fisik 4 KB, lihat di bawah ini - menonaktifkan cache tulis mungkin memiliki masalah lain.
- UPS sangat penting untuk perusahaan dan SOHO tetapi tidak cukup untuk membuat LVM aman: apa pun yang menyebabkan kerusakan parah atau kehilangan daya (mis. Kegagalan UPS, kegagalan PSU, atau kelelahan baterai laptop) dapat kehilangan data dalam cache hard drive.
- Kernel Linux yang sangat lama (2.6.x dari 2009) : Ada dukungan penghalang tulis yang tidak lengkap dalam versi kernel yang sangat tua, 2.6.32 dan yang lebih lama ( 2.6.31 memiliki beberapa dukungan , sementara 2.6.33 bekerja untuk semua jenis target perangkat) - RHEL 6 menggunakan 2.6.32 dengan banyak tambalan. Jika kernel 2.6 lama ini tidak ditambal untuk masalah ini, sejumlah besar metadata FS (termasuk jurnal) bisa hilang oleh crash keras yang meninggalkan data dalam buffer tulis hard drive (katakanlah 32 MB per drive untuk drive SATA umum). Kehilangan 32MB dari data metadata dan jurnal FS yang paling baru ditulis, yang menurut kernel sudah ada di disk, biasanya berarti banyak korupsi FS dan karenanya kehilangan data.
- Rangkuman: Anda harus berhati-hati dalam sistem file, RAID, hypervisor VM, dan pengaturan hard drive / SSD yang digunakan dengan LVM. Anda harus memiliki cadangan yang sangat baik jika Anda menggunakan LVM, dan pastikan untuk secara khusus mencadangkan metadata LVM, pengaturan partisi fisik, MBR dan sektor boot volume. Dianjurkan juga untuk menggunakan drive SCSI / SAS karena drive ini cenderung tidak berbohong tentang bagaimana mereka menulis caching - kehati-hatian lebih besar diperlukan untuk menggunakan drive SATA.
Tetap mengaktifkan cache tulis untuk kinerja (dan mengatasi drive yang berbohong)
Opsi yang lebih kompleks tetapi performan adalah untuk tetap mengaktifkan cache penulisan SSD / hard drive dan mengandalkan penghalang penulisan kernel yang bekerja dengan LVM pada kernel 2.6.33+ (periksa dua kali dengan mencari pesan "penghalang" di log).
Anda juga harus memastikan bahwa pengaturan RAID, pengaturan hypervisor VM, dan sistem file menggunakan penghalang penulisan (yaitu mengharuskan drive untuk mem-flush menulis yang tertunda sebelum dan sesudah metadata / jurnal utama menulis). XFS memang menggunakan penghalang secara default, tetapi ext3 tidak , jadi dengan ext3 Anda harus menggunakan barrier=1
opsi mount, dan masih menggunakan data=ordered
atau data=journal
seperti di atas.
- Sayangnya, beberapa hard drive dan SSD berbohong tentang apakah mereka benar-benar membuang cache ke disk (terutama drive yang lebih tua, tetapi termasuk beberapa drive SATA dan beberapa SSD perusahaan ) - lebih detail di sini . Ada ringkasan yang bagus dari pengembang XFS .
- Ada alat uji sederhana untuk berbohong drive (skrip Perl), atau lihat latar belakang ini dengan pengujian alat lain untuk menulis ulang pemesanan sebagai akibat dari cache drive. Jawaban ini mencakup pengujian yang serupa pada drive SATA yang menemukan masalah penghalang penulisan pada perangkat lunak RAID - tes ini benar-benar menggunakan seluruh tumpukan penyimpanan.
- Drive SATA yang lebih baru yang mendukung Native Command Queuing (NCQ) mungkin lebih kecil kemungkinannya untuk berbohong - atau mungkin mereka berkinerja baik tanpa caching tulis karena NCQ, dan sangat sedikit drive yang tidak dapat menonaktifkan caching tulis.
- Drive SCSI / SAS umumnya OK karena tidak perlu caching tulis untuk berkinerja baik (melalui SCSI Tagged Command Queuing , mirip dengan NCQ SATA).
- Jika hard drive atau SSD Anda berbohong tentang membuang cache ke disk, Anda benar-benar tidak bisa mengandalkan hambatan tulis dan harus menonaktifkan cache tulis. Ini adalah masalah untuk semua sistem file, basis data, manajer volume, dan RAID perangkat lunak , bukan hanya LVM.
SSD bermasalah karena penggunaan cache tulis sangat penting untuk masa pakai SSD. Cara terbaik adalah menggunakan SSD yang memiliki super kapasitor (untuk mengaktifkan pembilasan cache pada kegagalan daya, dan karenanya memungkinkan cache untuk ditulisi kembali, bukan write-through).
Pengaturan drive Format Lanjutan - tulis cache, perataan, RAID, GPT
- Dengan drive Format Lanjutan yang lebih baru yang menggunakan 4 sektor fisik KiB, mungkin penting untuk tetap mengaktifkan cache tulis drive, karena sebagian besar drive tersebut saat ini meniru sektor logis 512 byte ( "512 emulation" ), dan beberapa bahkan mengklaim memiliki fisik 512-byte. sektor sementara benar-benar menggunakan 4 KiB.
- Menonaktifkan cache tulis pada drive Format Lanjutan dapat menyebabkan dampak kinerja yang sangat besar jika aplikasi / kernel melakukan penulisan 512 byte, karena drive tersebut mengandalkan cache untuk mengakumulasi penulisan 8 x 512-byte sebelum melakukan fisik tunggal 4 KiB menulis. Pengujian disarankan untuk mengkonfirmasi dampak apa pun jika Anda menonaktifkan cache.
- Menyelaraskan LV pada batas 4 KiB penting untuk kinerja tetapi harus terjadi secara otomatis selama partisi yang mendasari PV diselaraskan, karena LVM Physical Extents (PEs) adalah 4 MiB secara default. RAID harus dipertimbangkan di sini - halaman setup LVM dan perangkat lunak RAID ini menyarankan untuk meletakkan superblock RAID di akhir volume dan (jika perlu) menggunakan opsi
pvcreate
untuk menyelaraskan PV. Daftar email LVM ini menunjuk ke pekerjaan yang dilakukan di kernel selama 2011 dan masalah blok parsial menulis ketika mencampur disk dengan 512 byte dan 4 sektor KiB dalam satu LV.
- Partisi GPT dengan Format Lanjutan perlu perawatan, terutama untuk disk boot + root, untuk memastikan partisi LVM (PV) pertama dimulai pada batas 4 KiB.
Sulit untuk memulihkan data karena struktur pada disk yang lebih kompleks :
- Pemulihan data LVM yang diperlukan setelah kerusakan parah atau kehilangan daya (karena caching penulisan yang salah) adalah proses manual yang terbaik, karena tampaknya tidak ada alat yang cocok. LVM baik dalam membuat cadangan metadata di bawah
/etc/lvm
, yang dapat membantu memulihkan struktur dasar LV, VG dan PV, tetapi tidak akan membantu dengan metadata sistem file yang hilang.
- Karenanya pemulihan penuh dari cadangan kemungkinan diperlukan. Ini melibatkan lebih banyak downtime daripada fsck berbasis jurnal cepat ketika tidak menggunakan LVM, dan data yang ditulis sejak cadangan terakhir akan hilang.
- TestDisk , ext3grep , ext3undel dan alat-alat lain dapat memulihkan partisi dan file dari disk non-LVM tetapi mereka tidak secara langsung mendukung pemulihan data LVM. TestDisk dapat menemukan bahwa partisi fisik yang hilang berisi LVM PV, tetapi tidak ada alat yang memahami volume logis LVM. Alat pahat file seperti PhotoRec dan banyak lainnya akan berfungsi saat mereka mem-bypass sistem file untuk merakit kembali file dari blok data, tetapi ini adalah upaya terakhir, pendekatan tingkat rendah untuk data yang berharga, dan bekerja kurang baik dengan file yang terfragmentasi.
- Pemulihan LVM manual dimungkinkan dalam beberapa kasus, tetapi rumit dan memakan waktu - lihat contoh ini dan ini , ini , dan ini untuk cara memulihkan.
Lebih sulit untuk mengubah ukuran filesystem dengan benar - mengubah ukuran filesystem mudah sering diberikan sebagai keuntungan LVM, tetapi Anda perlu menjalankan setengah lusin perintah shell untuk mengubah ukuran FS berbasis LVM - ini dapat dilakukan dengan seluruh server masih naik, dan dalam beberapa kasus dengan FS yang dipasang, tetapi saya tidak akan pernah mengambil risiko yang terakhir tanpa cadangan yang terkini dan menggunakan perintah yang telah diuji sebelumnya pada server yang setara (mis. klon pemulihan bencana dari server produksi).
- Pembaruan: Versi lebih baru
lvextend
mendukung opsi -r
( --resizefs
) - jika ini tersedia, ini adalah cara yang lebih aman dan lebih cepat untuk mengubah ukuran LV dan sistem file, terutama jika Anda menyusutkan FS, dan sebagian besar Anda dapat melewati bagian ini.
- Sebagian besar panduan untuk mengubah ukuran FS berbasis LVM tidak memperhitungkan fakta bahwa FS harus lebih kecil dari ukuran LV: penjelasan terperinci di sini . Saat menyusutkan sistem file, Anda perlu menentukan ukuran baru ke alat pengubah ukuran FS, misalnya
resize2fs
untuk ext3, dan ke lvextend
atau lvreduce
. Tanpa sangat hati-hati, ukurannya mungkin sedikit berbeda karena perbedaan antara 1 GB (10 ^ 9) dan 1 GiB (2 ^ 30), atau cara berbagai alat membulatkan ukuran ke atas atau ke bawah.
- Jika Anda tidak melakukan perhitungan dengan tepat (atau menggunakan beberapa langkah ekstra di luar yang paling jelas), Anda mungkin berakhir dengan FS yang terlalu besar untuk LV. Semuanya akan tampak baik selama berbulan-bulan atau bertahun-tahun, sampai Anda benar-benar mengisi FS, pada titik mana Anda akan mendapatkan korupsi serius - dan kecuali Anda mengetahui masalah ini, sulit untuk mencari tahu mengapa, karena Anda mungkin juga memiliki kesalahan disk nyata saat itu awan itu situasinya. (Mungkin masalah ini hanya memengaruhi pengurangan ukuran sistem file - namun, jelas bahwa mengubah ukuran sistem file di kedua arah meningkatkan risiko kehilangan data, mungkin karena kesalahan pengguna.)
Tampaknya ukuran LV harus lebih besar dari ukuran FS sebanyak 2 x ukuran fisik LVM (PE) - tetapi periksa tautan di atas untuk perincian karena sumbernya tidak otoritatif. Sering membiarkan 8 MiB sudah cukup, tetapi mungkin lebih baik untuk membiarkan lebih banyak, misalnya 100 MiB atau 1 GiB, hanya untuk aman. Untuk memeriksa ukuran PE, dan volume logis Anda + ukuran FS, menggunakan 4 KiB = 4096 byte blok:
Menunjukkan ukuran PE dalam KiB:
vgdisplay --units k myVGname | grep "PE Size"
Ukuran semua LV:
lvs --units 4096b
Ukuran (ext3) FS, mengasumsikan 4 KiB FS blocksize:
tune2fs -l /dev/myVGname/myLVname | grep 'Block count'
Sebaliknya, pengaturan non-LVM membuat mengubah ukuran FS menjadi sangat andal dan mudah dijalankan Gparted dan mengubah ukuran FS yang diperlukan, maka itu akan melakukan segalanya untuk Anda. Di server, Anda dapat menggunakan parted
dari shell.
- Sering kali lebih baik menggunakan CD Live Gparted atau Parted Magic , karena ini memiliki Gparted & kernel bebas bug yang lebih baru dan sering lebih bug daripada versi distro - Saya pernah kehilangan seluruh FS karena distro Gparted tidak memperbarui partisi dengan benar dalam menjalankan inti. Jika menggunakan distro's Gparted, pastikan untuk reboot tepat setelah mengubah partisi sehingga tampilan kernel benar.
Snapshots sulit digunakan, lambat dan bermasalah - jika snapshot kehabisan ruang yang dialokasikan sebelumnya, secara otomatis akan jatuh . Setiap snapshot dari LV yang diberikan adalah delta terhadap LV itu (bukan terhadap snapshots sebelumnya) yang dapat membutuhkan banyak ruang ketika snapshotting filesystem dengan aktivitas penulisan yang signifikan (setiap snapshot lebih besar dari yang sebelumnya). Aman untuk membuat snapshot LV yang ukurannya sama dengan LV asli, karena snapshot kemudian tidak akan pernah kehabisan ruang kosong.
Snapshots juga bisa sangat lambat (artinya 3 hingga 6 kali lebih lambat daripada tanpa LVM untuk tes MySQL ini ) - lihat jawaban ini mencakup berbagai masalah snapshot . Kelambatan ini sebagian karena snapshot membutuhkan banyak penulisan yang sinkron .
Snapshots memiliki beberapa bug yang signifikan, misalnya dalam beberapa kasus mereka dapat membuat boot sangat lambat, atau menyebabkan boot gagal sepenuhnya (karena kernel dapat waktu tunggu menunggu root FS ketika itu adalah snapshot LVM [diperbaiki dalam initramfs-tools
pembaruan Debian , Mar 2015] ).
- Namun, banyak bug kondisi ras snapshot tampaknya telah diperbaiki pada tahun 2015.
- LVM tanpa snapshot umumnya tampaknya cukup baik debugging, mungkin karena snapshot tidak digunakan sebanyak fitur inti.
Alternatif potret - sistem file dan hypervisor VM
Snapshots VM / cloud:
- Jika Anda menggunakan hypervisor VM atau penyedia cloud IaaS (mis. VMware, VirtualBox atau Amazon EC2 / EBS), snapshot mereka seringkali merupakan alternatif yang jauh lebih baik daripada snapshot LVM. Anda dapat dengan mudah mengambil snapshot untuk keperluan cadangan (tetapi pertimbangkan untuk membekukan FS sebelum melakukannya).
Cuplikan sistem file:
snapshot tingkat filesystem dengan ZFS atau btrfs mudah digunakan dan umumnya lebih baik daripada LVM, jika Anda menggunakan bare metal (tetapi ZFS tampaknya jauh lebih matang, hanya saja lebih sulit untuk menginstal):
Jepretan untuk cadangan online dan fsck
Snapshots dapat digunakan untuk menyediakan sumber yang konsisten untuk backup, selama Anda berhati-hati dengan ruang yang dialokasikan (idealnya snapshot ini berukuran sama dengan LV yang dicadangkan). Rsnapshot luar biasa (sejak 1.3.1) bahkan mengelola pembuatan / penghapusan snapshot LVM untuk Anda - lihat HOWTO ini pada rsnapshot menggunakan LVM . Namun, perhatikan masalah umum dengan snapshot dan bahwa snapshot tidak boleh dianggap sebagai cadangan itu sendiri.
Anda juga dapat menggunakan snapshot LVM untuk melakukan fsck online: snapshot LV dan fsck snapshot, sambil masih menggunakan FS non-snapshot utama - yang dijelaskan di sini - namun, itu tidak sepenuhnya mudah sehingga sebaiknya menggunakan e2croncheck seperti yang dijelaskan oleh Ted Ts 'o , pengelola ext3.
Anda harus "membekukan" sistem file sementara untuk mengambil snapshot - beberapa filesystem seperti ext3 dan XFS akan melakukan ini secara otomatis ketika LVM membuat snapshot.
Kesimpulan
Terlepas dari semua ini, saya masih menggunakan LVM pada beberapa sistem, tetapi untuk pengaturan desktop saya lebih suka partisi mentah. Manfaat utama yang dapat saya lihat dari LVM adalah fleksibilitas memindahkan dan mengubah ukuran FS ketika Anda harus memiliki waktu kerja yang tinggi di server - jika Anda tidak membutuhkannya, gparted lebih mudah dan memiliki risiko lebih kecil dari kehilangan data.
LVM membutuhkan perhatian besar pada pengaturan caching tulis karena hypervisor VM, caching tulis hard drive / SSD, dan sebagainya - tetapi hal yang sama berlaku untuk menggunakan Linux sebagai server DB. Kurangnya dukungan dari sebagian besar alat ( gparted
termasuk perhitungan ukuran kritis, dan testdisk
lain - lain) membuatnya lebih sulit untuk digunakan daripada yang seharusnya.
Jika menggunakan LVM, berhati-hatilah dengan snapshot: gunakan snapshot VM / cloud jika mungkin, atau selidiki ZFS / btrfs untuk menghindari LVM sepenuhnya - Anda mungkin menemukan ZFS atau btrs sudah cukup matang dibandingkan dengan LVM dengan snapshot.
Intinya: Jika Anda tidak tahu tentang masalah yang tercantum di atas dan bagaimana mengatasinya, sebaiknya jangan menggunakan LVM.