Bahaya dan peringatan LVM

Solusi 1:

Ringkasan

Risiko menggunakan LVM:

• Rentan untuk menulis masalah caching dengan SSD atau VM hypervisor
• Lebih sulit untuk memulihkan data karena struktur pada disk yang lebih kompleks
• Lebih sulit mengubah ukuran sistem file dengan benar
• Snapshot sulit digunakan, lambat, dan bermasalah
• Memerlukan keahlian untuk mengonfigurasi dengan benar mengingat masalah ini

Dua masalah LVM pertama digabungkan: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 waktu henti yang signifikan. Alasan utama menggunakan LVM adalah waktu aktif yang lebih tinggi (saat menambahkan disk, mengubah ukuran sistem file, dll), tetapi penting untuk menyiapkan penyiapan cache tulis dengan benar untuk menghindari LVM benar-benar mengurangi waktu aktif.

-- Diperbarui Des 2019:pembaruan kecil pada btrfs dan ZFS sebagai alternatif untuk snapshot LVM

Mengurangi risiko

LVM masih dapat bekerja dengan baik jika Anda:

• Dapatkan penyiapan cache tulis Anda langsung di hypervisor, kernel, dan SSD
• Hindari snapshot LVM
• Gunakan versi LVM terbaru untuk mengubah ukuran sistem file
• Memiliki cadangan yang baik

Detail

Saya telah meneliti ini sedikit di masa lalu setelah mengalami beberapa kehilangan data yang terkait dengan LVM. Risiko dan masalah utama LVM yang saya ketahui adalah:

Rentan terhadap caching penulisan hard disk karena hypervisor VM, caching disk, atau kernel Linux lama , dan mempersulit pemulihan data karena struktur pada disk yang lebih kompleks - lihat di bawah untuk detailnya. Saya telah melihat penyiapan LVM lengkap pada beberapa disk rusak tanpa ada peluang pemulihan, dan LVM plus caching penulisan hard disk adalah kombinasi yang berbahaya.

• Tulis caching dan tulis pemesanan ulang dengan hard drive penting untuk kinerja yang baik, tetapi dapat gagal membersihkan blok ke disk dengan benar karena hypervisor VM, caching penulisan hard drive, kernel Linux lama, dll.
• Hambatan penulisan berarti kernel menjamin bahwa itu akan menyelesaikan penulisan disk tertentu sebelum "penghalang" penulisan disk, untuk memastikan bahwa sistem file dan RAID dapat pulih jika terjadi kehilangan daya atau crash secara tiba-tiba. Hambatan semacam itu dapat menggunakan operasi FUA (Force Unit Access) untuk segera menulis blok tertentu ke disk, yang lebih efisien daripada pembersihan cache secara penuh. Penghalang dapat digabungkan dengan antrian perintah asli/tagged yang efisien (mengeluarkan beberapa permintaan I/O disk sekaligus) untuk memungkinkan hard drive melakukan pengurutan ulang penulisan cerdas tanpa meningkatkan risiko kehilangan data.
• Vypervisor VM dapat memiliki masalah 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 pemesanan . Periksa dokumentasi hypervisor Anda dengan hati-hati untuk opsi cache "flush to disk" atau write-through (ada di KVM, VMware, Xen, VirtualBox, dan lainnya) - dan uji dengan pengaturan Anda. Beberapa hypervisor seperti VirtualBox memiliki pengaturan default yang mengabaikan setiap penggelontoran disk dari tamu.
• Server perusahaan dengan LVM harus selalu menggunakan pengontrol RAID yang didukung baterai dan nonaktifkan caching tulis 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 penghalang 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 yang setara dengan data=ordered ext3 opsi (atau data=journal untuk keamanan ekstra), plus barrier=1 untuk memastikan bahwa caching kernel tidak memengaruhi integritas. (Atau gunakan ext4 yang mengaktifkan penghalang secara default.) Ini adalah opsi paling sederhana dan memberikan integritas data yang baik dengan biaya kinerja. (Linux mengubah opsi ext3 default menjadi data=writeback yang lebih berbahaya beberapa waktu lalu, jadi jangan mengandalkan setelan default untuk FS.)
• Untuk menonaktifkan cache tulis hard drive :tambahkan hdparm -q -W0 /dev/sdX untuk semua drive di /etc/rc.local (untuk SATA) atau gunakan sdparm untuk SCSI/SAS. Namun, menurut entri ini di FAQ XFS (yang sangat bagus untuk topik ini), drive SATA mungkin melupakan pengaturan ini setelah pemulihan kesalahan drive - jadi Anda harus menggunakan SCSI/SAS, atau jika Anda harus menggunakan SATA, masukkan perintah hdparm dalam tugas cron berjalan setiap menit atau lebih.
• Agar SSD/hard drive write caching tetap aktif untuk performa yang lebih baik:ini adalah area yang kompleks - lihat bagian di bawah.
• Jika Anda menggunakan Drive Format Lanjutan yaitu sektor fisik 4 KB, lihat di bawah - 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 hard crash atau hilangnya daya (misalnya kegagalan UPS, kegagalan PSU, atau baterai laptop habis) dapat kehilangan data dalam cache hard drive.
• Kernel Linux yang sangat lama (2.6.x dari 2009) :Ada dukungan penghalang penulisan yang tidak lengkap di versi kernel yang sangat lama, 2.6.32 dan sebelumnya (2.6.31 memiliki beberapa dukungan, sedangkan 2.6.33 berfungsi 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) dapat hilang karena kerusakan keras yang meninggalkan data di buffer tulis hard drive (katakanlah 32 MB per drive untuk drive SATA umum). Kehilangan 32 MB metadata FS dan data jurnal yang paling baru ditulis, yang menurut kernel sudah ada di disk, biasanya berarti banyak kerusakan FS dan karenanya kehilangan data.
• Ringkasan: 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 menggunakan LVM, dan pastikan untuk secara khusus mencadangkan metadata LVM, penyiapan partisi fisik, MBR, dan sektor boot volume. Anda juga disarankan untuk menggunakan drive SCSI/SAS karena ini cenderung berbohong tentang cara mereka menulis caching - lebih hati-hati diperlukan untuk menggunakan drive SATA.

Tetap aktifkan cache tulis untuk kinerja (dan mengatasi drive yang berbohong)

Opsi yang lebih kompleks tetapi berkinerja baik adalah tetap mengaktifkan cache tulis SSD/hard drive dan mengandalkan penghalang tulis kernel yang bekerja dengan LVM pada kernel 2.6.33+ (periksa ulang dengan mencari pesan "penghalang" di log).

Anda juga harus memastikan bahwa penyiapan RAID, penyiapan hypervisor VM, dan sistem file menggunakan penghalang penulisan (yaitu, mengharuskan drive menghapus penulisan yang tertunda sebelum dan sesudah penulisan metadata/jurnal utama). XFS memang menggunakan penghalang secara default, tetapi ext3 tidak, jadi dengan ext3 Anda harus menggunakan barrier=1 di opsi pasang, dan masih menggunakan data=ordered atau data=journal seperti di atas.

• Sayangnya, beberapa hard drive dan SSD berbohong tentang apakah mereka benar-benar mengosongkan cache ke disk (terutama drive lama, tetapi termasuk beberapa drive SATA dan beberapa SSD perusahaan) - lebih detail di sini. Ada ringkasan bagus dari pengembang XFS.
• Ada alat uji sederhana untuk meletakkan drive (skrip Perl), atau lihat latar belakang ini dengan pengujian alat lain untuk menulis ulang pengurutan sebagai hasil dari cache drive. Jawaban ini mencakup pengujian serupa pada drive SATA yang mengungkap masalah penghalang tulis dalam RAID perangkat lunak - pengujian ini benar-benar menjalankan seluruh tumpukan penyimpanan.
• Drive SATA terbaru yang mendukung Native Command Queuing (NCQ) mungkin lebih kecil kemungkinannya untuk berbohong - atau mungkin drive tersebut bekerja dengan baik tanpa cache tulis karena NCQ, dan sangat sedikit drive yang tidak dapat menonaktifkan cache tulis.
• Drive SCSI/SAS umumnya baik-baik saja karena tidak memerlukan caching tulis untuk bekerja dengan baik (melalui SCSI Tagged Command Queuing, serupa dengan NCQ SATA).
• Jika hard drive atau SSD Anda berbohong tentang mengosongkan cache ke disk, Anda benar-benar tidak dapat mengandalkan penghalang tulis dan harus menonaktifkan cache tulis. Ini adalah masalah untuk semua sistem file, basis data, pengelola volume, dan RAID perangkat lunak, bukan hanya LVM.

SSD bermasalah karena penggunaan cache tulis sangat penting untuk masa pakai SSD. Sebaiknya gunakan SSD yang memiliki superkapasitor (untuk mengaktifkan pengosongan cache saat listrik mati, sehingga memungkinkan cache untuk ditulis kembali, bukan ditulis).

• Sebagian besar SSD perusahaan tidak bermasalah dengan kontrol cache tulis, dan beberapa menyertakan superkapasitor.
• Beberapa SSD yang lebih murah memiliki masalah yang tidak dapat diperbaiki dengan konfigurasi cache-tulis - milis proyek PostgreSQL dan halaman wiki Penulisan yang Andal adalah sumber informasi yang baik. SSD konsumen dapat memiliki masalah caching penulisan besar yang akan menyebabkan hilangnya data, dan tidak menyertakan superkapasitor sehingga rentan terhadap kegagalan daya yang menyebabkan korupsi.

Format Lanjutan penyiapan drive - tulis caching, penyelarasan, RAID, GPT

• Dengan drive Format Lanjutan yang lebih baru yang menggunakan sektor fisik 4 KiB, mungkin penting untuk tetap mengaktifkan cache tulis drive, karena sebagian besar drive tersebut saat ini meniru sektor logis 512 byte ("emulasi 512"), dan beberapa bahkan mengklaim memiliki 512 -byte sektor fisik saat benar-benar menggunakan 4 KiB.
• Mematikan cache tulis drive Format Lanjutan dapat menyebabkan dampak kinerja yang sangat besar jika aplikasi/kernel melakukan penulisan 512 byte, karena drive tersebut bergantung pada cache untuk mengumpulkan 8 x 512 byte penulisan sebelum melakukan satu Tulis fisik 4 KiB. Pengujian disarankan untuk mengonfirmasi 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 untuk PV diselaraskan, karena Luas Fisik (PE) LVM adalah 4 MiB secara default. RAID harus dipertimbangkan di sini - halaman penyiapan LVM dan RAID perangkat lunak ini menyarankan untuk meletakkan superblok RAID di akhir volume dan (jika perlu) menggunakan opsi pada pvcreate untuk menyelaraskan PV. Utas daftar email LVM ini menunjukkan pekerjaan yang dilakukan di kernel selama tahun 2011 dan masalah penulisan blok parsial saat menggabungkan disk dengan sektor 512 byte dan 4 KiB dalam satu LV.
• Pemartisian GPT dengan Format Lanjutan memerlukan kehati-hatian, terutama untuk disk boot+root, untuk memastikan partisi (PV) LVM pertama dimulai pada batas 4 KiB.

Lebih sulit untuk memulihkan data karena struktur pada disk yang lebih kompleks :

• Pemulihan data LVM apa pun yang diperlukan setelah hard crash atau kehilangan daya (karena caching penulisan yang salah) paling baik adalah proses manual, karena tampaknya tidak ada alat yang sesuai. LVM pandai mencadangkan metadatanya di bawah /etc/lvm , yang dapat membantu memulihkan struktur dasar LV, VG, dan PV, tetapi tidak akan membantu hilangnya metadata sistem file.
• Oleh karena itu, pemulihan penuh dari cadangan mungkin diperlukan. Ini melibatkan lebih banyak waktu henti daripada fsck berbasis jurnal cepat saat tidak menggunakan LVM, dan data yang ditulis sejak pencadangan terakhir akan hilang.
• TestDisk, ext3grep, ext3undel, dan alat lainnya dapat memulihkan partisi dan file dari disk non-LVM tetapi tidak secara langsung mendukung pemulihan data LVM. TestDisk dapat menemukan bahwa partisi fisik yang hilang berisi PV LVM, tetapi tidak satu pun dari alat ini yang memahami volume logis LVM. Alat pengukir file seperti PhotoRec dan banyak lainnya akan berfungsi saat melewati sistem file untuk merakit ulang file dari blok data, tetapi ini adalah pilihan terakhir, pendekatan tingkat rendah untuk data 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 mengubah ukuran sistem file dengan benar - pengubahan ukuran sistem file yang mudah sering diberikan sebagai manfaat dari LVM, tetapi Anda perlu menjalankan setengah lusin perintah shell untuk mengubah ukuran FS berbasis LVM - ini dapat dilakukan dengan seluruh server masih aktif, dan dalam beberapa kasus dengan FS terpasang, tetapi saya tidak akan pernah mengambil risiko yang terakhir tanpa cadangan terbaru dan menggunakan perintah yang telah diuji sebelumnya pada server yang setara (misalnya klon pemulihan bencana dari server produksi).

• Perbarui: Versi lvextend yang lebih baru mendukung -r (--resizefs ) - jika ini tersedia, ini adalah cara yang lebih aman dan lebih cepat untuk mengubah ukuran LV dan sistem file, terutama jika Anda mengecilkan 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 mendetail di sini. Saat mengecilkan sistem file, Anda perlu menentukan ukuran baru ke alat pengubah ukuran FS, mis. resize2fs untuk ext3, dan untuk lvextend atau lvreduce . Tanpa 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 benar (atau menggunakan beberapa langkah ekstra di luar yang paling jelas), Anda mungkin akan mendapatkan FS yang terlalu besar untuk LV. Semuanya akan tampak baik-baik saja selama berbulan-bulan atau bertahun-tahun, sampai Anda benar-benar mengisi FS, di mana Anda akan mengalami kerusakan serius - dan kecuali Anda mengetahui masalah ini, sulit untuk mengetahui alasannya, karena Anda mungkin juga mengalami kesalahan disk yang sebenarnya saat itu. yang mengaburkan situasi. (Kemungkinan masalah ini hanya memengaruhi pengurangan ukuran sistem file - namun, jelas bahwa mengubah ukuran sistem file ke arah mana pun meningkatkan risiko kehilangan data, mungkin karena kesalahan pengguna.)

• Tampaknya ukuran LV harus lebih besar dari ukuran FS sebesar 2 x ukuran jangkauan fisik (PE) LVM - tetapi periksa tautan di atas untuk perincian karena sumbernya tidak resmi. Seringkali mengizinkan 8 MiB sudah cukup, tetapi mungkin lebih baik mengizinkan lebih banyak, mis. 100 MiB atau 1 GiB, agar aman. Untuk memeriksa ukuran PE, dan ukuran volume+FS logis Anda, gunakan blok 4 KiB =4096 byte:

  Menampilkan ukuran PE dalam KiB:
  vgdisplay --units k myVGname | grep "PE Size"
  
  Ukuran semua LV:
  lvs --units 4096b
  
  Ukuran (ext3) FS, asumsikan ukuran blok 4 KiB FS:
  tune2fs -l /dev/myVGname/myLVname | grep 'Block count'

• Sebaliknya, pengaturan non-LVM membuat pengubahan ukuran FS menjadi sangat andal dan mudah - jalankan Gparted dan ubah ukuran FS yang diperlukan, maka itu akan melakukan segalanya untuk Anda. Di server, Anda dapat menggunakan parted dari cangkang.

• Seringkali yang terbaik adalah menggunakan Gparted Live CD atau Parted Magic, karena ini memiliki Gparted &kernel baru-baru ini dan seringkali lebih bebas bug daripada versi distro - Saya pernah kehilangan seluruh FS karena Gparted distro tidak memperbarui partisi dengan benar dalam menjalankan inti. Jika menggunakan distro Gparted, pastikan untuk mem-boot ulang tepat setelah mengubah partisi agar tampilan kernel benar.

Snapshot sulit digunakan, lambat, dan bermasalah - jika snapshot kehabisan ruang yang dialokasikan sebelumnya, snapshot akan dihapus secara otomatis. Setiap snapshot dari LV yang diberikan adalah delta terhadap LV itu (bukan terhadap snapshot sebelumnya) yang dapat membutuhkan banyak ruang saat memotret sistem file dengan aktivitas penulisan yang signifikan (setiap snapshot lebih besar dari yang sebelumnya). Anda dapat membuat LV snapshot dengan ukuran yang sama dengan LV asli, karena snapshot tidak akan pernah kehabisan ruang kosong.

Jepretan juga bisa sangat lambat (artinya 3 hingga 6 kali lebih lambat daripada tanpa LVM untuk pengujian MySQL ini) - lihat jawaban ini yang mencakup berbagai masalah snapshot. Kelambatan ini sebagian karena snapshot memerlukan banyak penulisan sinkron.

Snapshot memiliki beberapa bug yang signifikan, mis. dalam beberapa kasus mereka dapat membuat boot menjadi sangat lambat, atau menyebabkan boot gagal sepenuhnya (karena kernel dapat kehabisan waktu menunggu root FS ketika itu adalah snapshot LVM [diperbaiki di Debian initramfs-tools perbarui, Mar 2015]).

• Namun, banyak bug kondisi balapan cuplikan tampaknya telah diperbaiki pada tahun 2015.
• LVM tanpa snapshot umumnya terlihat cukup ter-debug dengan baik, mungkin karena snapshot tidak digunakan sebanyak fitur inti.

Alternatif snapshot - sistem file dan hypervisor VM

Cuplikan VM/awan:

• 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 tujuan pencadangan (namun pertimbangkan untuk membekukan FS sebelum Anda melakukannya).

Cuplikan sistem file:

• snapshot tingkat sistem file dengan ZFS atau btrfs mudah digunakan dan umumnya lebih baik daripada LVM, jika Anda menggunakan bare metal (tetapi ZFS tampaknya jauh lebih matang, hanya lebih merepotkan untuk dipasang):

• ZFS:sekarang ada implementasi kernel ZFS, yang telah digunakan selama beberapa tahun, dan ZFS tampaknya mulai diadopsi. Ubuntu sekarang memiliki ZFS sebagai opsi 'out of the box', termasuk ZFS eksperimental di root pada 19.10.

• btrfs:masih belum siap untuk penggunaan produksi (bahkan pada openSUSE yang mengirimkannya secara default dan memiliki tim khusus untuk btrfs), sedangkan RHEL telah berhenti mendukungnya). btrfs sekarang memiliki alat fsck (FAQ), tetapi FAQ merekomendasikan Anda untuk berkonsultasi dengan pengembang jika Anda perlu fsck sistem file yang rusak.

Snapshot untuk backup online dan fsck

Snapshot dapat digunakan untuk menyediakan sumber yang konsisten untuk pencadangan, selama Anda berhati-hati dengan alokasi ruang (idealnya snapshot memiliki ukuran yang sama dengan LV yang dicadangkan). Rsnapshot yang sangat baik (sejak 1.3.1) bahkan mengelola pembuatan/penghapusan snapshot LVM untuk Anda - lihat HOWTO ini di rsnapshot menggunakan LVM. Namun, perhatikan masalah umum 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 tetap menggunakan FS non-snapshot utama - dijelaskan di sini - namun, ini tidak sepenuhnya mudah jadi sebaiknya gunakan e2croncheck seperti yang dijelaskan oleh Ted Ts 'o, pengelola ext3.

Anda harus "membekukan" sistem file untuk sementara saat mengambil snapshot - beberapa sistem file seperti ext3 dan XFS akan melakukannya secara otomatis saat 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 untuk memindahkan dan mengubah ukuran FS ketika Anda harus memiliki waktu aktif yang tinggi di server - jika Anda tidak membutuhkannya, gparted lebih mudah dan risiko kehilangan data lebih kecil.

LVM membutuhkan kehati-hatian dalam penyiapan 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 dll) membuatnya lebih sulit untuk digunakan daripada yang seharusnya.

Jika menggunakan LVM, berhati-hatilah dengan snapshot:gunakan snapshot VM/cloud jika memungkinkan, atau selidiki ZFS/btrfs untuk menghindari LVM sepenuhnya - Anda mungkin menemukan ZFS atau btrf cukup matang dibandingkan dengan LVM dengan snapshot.

Intinya:Jika Anda tidak mengetahui masalah yang tercantum di atas dan cara mengatasinya, sebaiknya jangan gunakan LVM.

Solusi 2:

Saya [+1] posting itu, dan setidaknya bagi saya, saya pikir sebagian besar masalah memang ada. Melihatnya saat menjalankan beberapa 100 server dan beberapa 100TB data. Bagi saya LVM2 di Linux terasa seperti "ide cerdas" yang dimiliki seseorang. Seperti beberapa di antaranya, terkadang mereka ternyata "tidak pintar". Yaitu. tidak memiliki status kernel dan userspace (lvmtab) yang dipisahkan secara ketat mungkin terasa sangat cerdas untuk dihilangkan, karena mungkin ada masalah korupsi (jika Anda tidak mendapatkan kode dengan benar)

Yah, hanya saja pemisahan ini ada karena suatu alasan - perbedaan terlihat dengan penanganan kehilangan PV, dan aktivasi ulang VG secara online dengan mis. PV yang hilang untuk mengembalikannya ke permainan - Apa angin sepoi-sepoi pada "LVM asli" (AIX, HP-UX) berubah menjadi omong kosong di LVM2 sejak itu penanganan negara tidak cukup baik. Dan bahkan tidak membuat saya berbicara tentang deteksi kehilangan kuorum (haha) atau penanganan negara (jika saya menghapus disk, itu tidak akan ditandai sebagai tidak tersedia. Bahkan tidak memiliki kolom status sialan)

Re:stabilitas pvmove ... mengapa

pvmove kehilangan data

artikel peringkat teratas di blog saya, hmmm? Baru saja saya melihat disk di mana data lvm fisik masih digantung di status dari mid-pvmove. Ada beberapa memleaks menurut saya, dan ide umum itu adalah hal yang baik untuk menyalin sekitar data blok langsung dari userspace hanya menyedihkan.Kutipan bagus dari daftar lvm "sepertinya vgreduce --missing tidak menangani pvmove"Berarti sebenarnya jika disk terlepas selama pvmove maka alat manajemen lvm berubah dari lvm ke vi. Oh dan ada juga bug di mana pvmove berlanjut setelah kesalahan baca/tulis blok dan sebenarnya tidak lagi menulis data ke perangkat target. WTF?

Re:Snapshot Kontrak Karya dilakukan dengan tidak aman, dengan memperbarui data BARU ke area lv snapshot dan kemudian menggabungkan kembali setelah Anda menghapus snap. Ini berarti Anda memiliki lonjakan IO yang berat selama penggabungan terakhir data baru ke LV asli dan, yang jauh lebih penting, Anda tentu saja juga memiliki risiko kerusakan data yang jauh lebih tinggi, karena snapshot tidak akan rusak setelah Anda menekan dinding, tapi aslinya.

Keuntungannya adalah kinerja, melakukan 1 penulisan daripada 3. Memilih algoritme yang cepat tetapi tidak aman adalah sesuatu yang jelas diharapkan dari orang-orang seperti VMware dan MS, di "Unix" saya lebih suka menebak semuanya akan "dilakukan dengan benar".Saya tidak melihat banyak masalah kinerja selama saya memiliki penyimpanan pendukung snapshot di berbeda disk drive daripada data utama (dan cadangan ke yang lain tentunya)

Re:Hambatan Saya tidak yakin apakah LVM bisa disalahkan. Itu adalah masalah devmapper, sejauh yang saya tahu. Tapi ada beberapa kesalahan karena tidak terlalu peduli tentang masalah ini dari setidaknya kernel 2.6 hingga 2.6.33AFAIK Xen adalah satu-satunya hypervisor yang menggunakan O_DIRECT untuk mesin virtual, masalahnya digunakan menjadi ketika "loop" digunakan karena kernel masih akan melakukan cache menggunakan itu. Virtualbox setidaknya memiliki beberapa pengaturan untuk menonaktifkan hal-hal seperti ini dan Qemu/KVM secara umum tampaknya mengizinkan caching. Semua FUSE FS juga mengalami masalah di sana (tidak ada O_DIRECT)

Re:Ukuran Saya pikir LVM melakukan "pembulatan" dari ukuran yang ditampilkan. Atau menggunakan GiB. Bagaimanapun, Anda perlu menggunakan ukuran VG Pe dan mengalikannya dengan nomor LE dari LV. Itu seharusnya memberikan ukuran bersih yang benar, dan masalah itu selalu merupakan masalah penggunaan. Ini diperparah oleh sistem file yang tidak memperhatikan hal seperti itu selama fsck/mount (halo, ext3) atau tidak memiliki "fsck online yang berfungsi" -n" (halo, ext3)

Tentu saja mengatakan bahwa Anda tidak dapat menemukan sumber yang bagus untuk info semacam itu. "berapa LE untuk VRA?" "berapa offset fisik untuk PVRA, VGDA, ... dll"

Dibandingkan dengan yang asli, LVM2 adalah contoh utama dari "Mereka yang tidak mengerti UNIX dikutuk untuk menemukannya kembali, dengan buruk."

Perbarui beberapa bulan kemudian:Saya telah mencapai skenario "snapshot penuh" untuk pengujian sekarang. Jika sudah penuh, snapshot akan memblokir, bukan LV asli. Saya salah di sana ketika saya pertama kali memposting ini. Saya mengambil info yang salah dari beberapa dokumen, atau mungkin saya telah memahaminya. Dalam pengaturan saya, saya selalu sangat paranoid untuk tidak membiarkannya terisi dan akhirnya saya tidak pernah dikoreksi. Ini juga memungkinkan untuk memperluas/mengecilkan snapshot, yang merupakan suguhan.

Apa yang masih belum dapat saya selesaikan adalah bagaimana mengidentifikasi usia snapshot. Mengenai kinerjanya, ada catatan di halaman proyek fedora "thinp" yang mengatakan teknik snapshot sedang direvisi sehingga tidak menjadi lebih lambat dengan setiap cuplikan. Saya tidak tahu bagaimana mereka menerapkannya.

Solusi 3:

Jika Anda berencana untuk menggunakan snapshot untuk pencadangan - bersiaplah untuk performa yang hebat saat snapshot tersedia. jika tidak, semuanya baik-baik saja. Saya telah menggunakan lvm dalam produksi selama beberapa tahun di lusinan server, meskipun alasan utama saya untuk menggunakannya adalah snapshot atom tidak dapat memperluas volume dengan mudah.

BTW jika Anda akan menggunakan drive 1TB, ingat tentang penyelarasan partisi - drive ini kemungkinan besar memiliki sektor fisik 4kB.

Solusi 4:

Sambil memberikan jendela yang menarik tentang keadaan LVM 10+ tahun yang lalu, jawaban yang diterima sekarang sudah benar-benar usang. Modern (yaitu:LVM pasca-2012):

• mematuhi permintaan sinkronisasi/penghalang
• memiliki kemampuan snapshot yang cepat dan andal dalam bentuk lvmthin
• memiliki cache SSD yang stabil melalui lvmcache dan kebijakan writeback cepat untuk NVMe/NVDIMM/Optane melalui dm-writecache
• pengoptimal data virtual (vdo ) dukungan berkat lvmvdo
• RAID per-volume dan terintegrasi berkat lvmraid
• penyelarasan otomatis ke 1MB atau 4MB (bergantung pada versi), sepenuhnya menghindari masalah penyelarasan 4K (kecuali menggunakan LVM pada partisi yang tidak selaras)
• dukungan luar biasa untuk memperbesar volume, terutama saat melakukannya menambahkan perangkat blok lain (yang tidak mungkin dilakukan saat menggunakan sistem file klasik sebagai ext4/xfs di atas partisi biasa)
• milis yang luar biasa, ramah, dan sangat berguna di [email protected]

Jelas, ini tidak berarti Anda selalu memiliki menggunakan LVM - aturan emas untuk penyimpanan adalah menghindari lapisan yang tidak dibutuhkan. Misalnya, untuk mesin virtual sederhana Anda pasti dapat melanjutkan dengan partisi klasik saja. Namun jika Anda menghargai salah satu fitur di atas, LVM adalah alat yang sangat berguna yang seharusnya ada di kotak alat sysadmin Linux yang serius.

Solusi 5:

Adam,

Keuntungan lain:Anda dapat menambahkan volume fisik (PV) baru, memindahkan semua data ke PV tersebut, lalu menghapus PV lama tanpa gangguan layanan apa pun. Saya telah menggunakan kemampuan itu setidaknya empat kali dalam lima tahun terakhir.

Kerugian yang belum saya lihat ditunjukkan dengan jelas:Ada kurva pembelajaran yang agak curam untuk LVM2. Sebagian besar dalam abstraksi yang dibuatnya antara file Anda dan media yang mendasarinya. Jika Anda bekerja hanya dengan beberapa orang yang berbagi tugas di satu set server, Anda mungkin menemukan kerumitan ekstra yang membebani tim Anda secara keseluruhan. Tim yang lebih besar yang didedikasikan untuk pekerjaan TI umumnya tidak akan mengalami masalah seperti itu.

Misalnya, kami menggunakannya secara luas di tempat kerja saya dan telah meluangkan waktu untuk mengajari seluruh tim dasar-dasar, bahasa, dan hal-hal mendasar tentang memulihkan sistem yang tidak bisa boot dengan benar.

Satu peringatan khusus untuk ditunjukkan:jika Anda mem-boot dari volume logis LVM2, Anda membuat operasi pemulihan menjadi sulit saat server mogok. Knoppix dan kawan-kawan tidak selalu memiliki barang yang tepat untuk itu. Jadi, kami memutuskan bahwa direktori /boot kami akan berada di partisinya sendiri dan akan selalu berukuran kecil dan asli.

Secara keseluruhan, saya penggemar LVM2.