Bahaya LVM dan peringatan


189

Saya baru-baru ini mulai menggunakan LVM pada beberapa server untuk hard drive yang lebih besar dari 1 TB. Mereka berguna, dapat dikembangkan dan cukup mudah untuk menginstal. Namun, saya tidak dapat menemukan data tentang bahaya dan peringatan LVM.

Apa kerugian menggunakan LVM?


19
Saat membaca jawaban untuk pertanyaan ini, ingatlah tanggal (tahun) mereka diposting. Banyak yang terjadi dalam 3 tahun di industri ini.
MattBianco

2
Saya telah melakukan beberapa pembaruan baru-baru ini (Apr 2015) telah memindai untuk melihat apakah ada sesuatu yang berubah. Kernel 2.6 sekarang sudah usang, SSD lebih umum, tetapi terlepas dari beberapa perbaikan LVM kecil tidak banyak yang benar-benar berubah. Saya memang menulis beberapa hal baru tentang menggunakan snapshot VM / cloud server bukannya snapshot LVM. Keadaan caching tulis, pengubahan ukuran sistem file dan snapshot LVM belum benar-benar berubah sejauh yang saya bisa lihat.
RichVel

1
tentang komentar "ingat tanggal" - cukup benar, tetapi juga pertimbangkan bahwa banyak "perusahaan" masih menggunakan RHEL 5 dan RHEL 6, yang keduanya canggih atau lebih tua dari tanggal dari jawabannya
JDS

Jawaban:


252

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=orderedopsi ext3 yang setara (atau data=journaluntuk keamanan ekstra), plus barrier=1untuk 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=writebackbeberapa waktu lalu, jadi jangan mengandalkan pengaturan default untuk FS.)
  • Untuk menonaktifkan caching penulisan hard drive : tambahkan hdparm -q -W0 /dev/sdXuntuk 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=1opsi mount, dan masih menggunakan data=orderedatau data=journalseperti di atas.

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 pvcreateuntuk 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 lvextendmendukung 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 resize2fsuntuk ext3, dan ke lvextendatau 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 parteddari 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-toolspembaruan 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 ( gpartedtermasuk perhitungan ukuran kritis, dan testdisklain - 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.


4
Mengubah ukuran online dengan xfs berfungsi dengan baik, Anda bahkan tidak perlu menentukan ukurannya. Ini akan tumbuh ke ukuran LV baca lebih lanjut di xfs_grow (5). OTOH saya menekan +1 untuk ringkasan tentang hambatan penulisan.
cstamas

2
DUDE! Di mana saja kau selama hidup saya!?
songei2f

2
@ TREE: ide dengan pengontrol RAID yang didukung baterai adalah bahwa cache-nya persisten pada kegagalan daya dan umumnya dapat dipercaya untuk bekerja seperti yang didokumentasikan, sedangkan beberapa cache hard disk berbohong tentang apakah mereka sebenarnya menulis blok ke disk, dan dari Tentu saja cache ini tidak persisten. Jika Anda membiarkan cache hard disk diaktifkan, Anda rentan terhadap kegagalan daya tiba-tiba (mis. PSU atau UPS gagal), yang dilindungi oleh cadangan baterai pengontrol RAID.
RichVel

6
Salah satu jawaban terbaik yang pernah saya lihat, topik apa saja. Hanya perubahan yang akan saya buat, pindahkan ringkasan ke TOP pertanyaan untuk mereka yang memiliki gangguan defisit perhatian atau tidak banyak waktu. :-)
Prof. Falken

3
Saya telah menyertakan koreksi / pembaruan dari komentar yang ada jika ada. Belum menggunakan LVM baru-baru ini, tapi saya tidak ingat melihat perubahan besar berdasarkan cerita LWN.net, yang melacak hal semacam ini cukup dekat. ZFS di Linux sekarang lebih matang (tapi masih lebih baik di FreeBSD atau Solaris), dan btrf masih jauh dari kematangan produksi nyata meskipun digunakan oleh beberapa distribusi Linux. Jadi saya tidak melihat perubahan apa pun yang perlu dimasukkan sekarang, tapi saya senang mendengarkan!
RichVel

15

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

Nah, hanya pemisahan ini ada karena suatu alasan - perbedaan menunjukkan dengan penanganan kehilangan PV, dan aktivasi ulang online VG dengan mis. PV yang hilang untuk membawa mereka kembali bermain - Apa yang mudah dari "LVM asli" (AIX , HP-UX) berubah menjadi omong kosong pada LVM2 karena penanganan keadaan tidak cukup baik. Dan bahkan jangan 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)

Stabilitas pvmove ... mengapa demikian

pvmove kehilangan data

artikel peringkat teratas di blog saya, hmmm? Baru saja saya melihat disk di mana data lvm phyiscal masih digantung di negara dari mid-pvmove. Ada beberapa memleaks yang saya pikir, dan ide umum itu adalah hal yang baik untuk menyalin data blok langsung dari userspace hanya sedih. Kutipan yang bagus dari daftar lvm "sepertinya vgreduce --missing tidak menangani pvmove" Berarti sebenarnya jika disk dilepaskan 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: Snapshots The CoW dilakukan dengan tidak aman, dengan memperbarui data BARU ke area snapshot lv dan kemudian menggabungkan kembali setelah Anda menghapus snap. Ini berarti Anda memiliki lonjakan IO yang berat selama penggabungan kembali data baru ke dalam LV asli dan, yang jauh lebih penting, Anda tentu saja juga memiliki risiko korupsi data yang jauh lebih tinggi, karena bukan snapshot akan rusak begitu Anda menekan tombol dinding, tetapi aslinya.

Keuntungannya adalah dalam kinerja, melakukan 1 menulis daripada 3. Memilih algoritma yang cepat tetapi tidak aman adalah sesuatu yang jelas diharapkan dari orang-orang seperti VMware dan MS, pada "Unix" Saya lebih suka menebak hal-hal yang akan "dilakukan dengan benar". Saya tidak melihat banyak masalah kinerja selama saya memiliki snapshot backing store pada disk drive yang berbeda dari data primer (dan cadangan untuk yang lainnya tentu saja)

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

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

Tentu saja mengatakan bahwa Anda tidak dapat menemukan sumber yang bagus untuk info tersebut. "Berapa banyak LE untuk VRA?" "apa offset phyiscal untuk PVRA, VGDA, ... dll"

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

Perbarui beberapa bulan kemudian: Saya telah mencapai skenario "snapshot penuh" untuk pengujian sekarang. Jika mereka penuh, snapshot itu memblokir, bukan LV asli. Saya salah di sana ketika saya pertama kali memposting ini. Saya mengambil informasi yang salah dari beberapa dokumen, atau mungkin saya memahaminya. Dalam pengaturan saya, saya selalu sangat paranoid untuk tidak membiarkannya terisi dan saya akhirnya tidak pernah dikoreksi. Mungkin juga untuk memperpanjang / mengecilkan foto, yang merupakan hadiah.

Yang masih belum bisa saya pecahkan adalah bagaimana mengidentifikasi usia foto. Mengenai kinerja mereka, ada catatan di halaman proyek fedora "thinp" yang mengatakan teknik snapshot sedang direvisi sehingga mereka tidak akan menjadi lebih lambat dengan setiap snapshot. Saya tidak tahu bagaimana mereka mengimplementasikannya.


Poin bagus, terutama pada kehilangan data pvmove (tidak menyadari ini bisa crash di bawah memori rendah) dan desain snapshot. Tentang hambatan penulisan / caching: Saya mengkonfigurasikan LVM dan mapper perangkat kernel karena dari sudut pandang pengguna mereka bekerja bersama untuk memberikan apa yang disediakan LVM. Terpilih. Juga menyukai posting blog Anda pada kehilangan data pvmove
RichVel

Pada snapshot: mereka terkenal lambat dalam LVM, jadi jelas itu bukan keputusan desain yang baik untuk mendapatkan kinerja lebih dari keandalan. Dengan "menabrak dinding", apakah maksud Anda snapshot terisi, dan dapatkah itu benar-benar menyebabkan kerusakan pada data LV asli? LVM HOWTO mengatakan bahwa snapshot dijatuhkan dalam kasus ini: tldp.org/HOWTO/LVM-HOWTO/snapshots_backup.html
RichVel

5
"CoW dilakukan dengan tidak aman, dengan memperbarui data BARU ke area snapshot lv dan kemudian menggabungkan kembali setelah Anda menghapus snap." Ini salah. Ketika data baru ditulis ke perangkat asli, versi lama ditulis ke dalam area snapshot COW. Tidak ada data yang pernah digabungkan kembali (kecuali jika Anda mau). Lihat kernel.org/doc/Documentation/device-mapper/snapshot.txt untuk semua detail teknis berdarah.
Damien Tournoud

Hai Damien, lain kali baca terus ke titik di mana saya memperbaiki posting saya?
Florian Heigl

12

jika Anda berencana untuk menggunakan snapshot untuk cadangan - bersiaplah untuk hit kinerja utama ketika snapshot hadir. baca lebih lanjut di sini . kalau tidak, itu semua baik. Saya telah menggunakan lvm dalam produksi selama beberapa tahun di lusinan server, meskipun alasan utama saya untuk menggunakannya adalah snapshot atom bukan kemampuan untuk memperluas volume dengan mudah.

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


+1 untuk peringatan kinerja untuk snapshot terbuka.
Prof. Falken

pengalaman saya adalah bahwa drive 1TB biasanya menggunakan sektor 512 byte, tetapi kebanyakan drive 2TB menggunakan 4Kb.
Dan Pritts

@DanPritts tidak ada salahnya dengan menganggap bahwa ukuran sektor adalah 4kB atau bahkan 128kB - kalau-kalau ada razia di antaranya. Anda kehilangan sangat sedikit - mungkin itu 128kB dan Anda bisa mendapatkan banyak. juga saat pencitraan dari disk lama ke yang baru.
pQd

1
Ada beberapa kerusakan kecil untuk membuat ukuran blok filesystem "terlalu besar"; setiap file terkandung dalam tidak kurang dari satu blok. Jika Anda punya banyak file kecil dan blok 128KB itu akan bertambah. Saya setuju bahwa 4K cukup masuk akal, dan jika Anda memindahkan sistem file ke perangkat keras baru, pada akhirnya Anda akan mendapatkan sektor 4k.
Dan Pritts

1
(tidak akan membiarkan saya mengedit komentar saya sebelumnya) ... Membuang-buang ruang mungkin tidak masalah, tetapi pada akhirnya akan meningkatkan waktu pencarian rata-rata Anda pada disk yang berputar. Mungkin bisa berubah menjadi amplifikasi tulis (mengisi sektor dengan nol) pada SSD.
Dan Pritts

5

Adam,

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

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

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

Satu peringatan khusus untuk menunjukkan: jika Anda boot dari volume logis LVM2 Anda membuat menemukan operasi pemulihan sulit ketika server crash. Knoppix dan teman-teman tidak selalu memiliki barang yang tepat untuk itu. Jadi, kami memutuskan bahwa direktori / boot kami berada di partisi sendiri dan selalu kecil dan asli.

Secara keseluruhan, saya penggemar LVM2.


2
menjaga /bootterpisah selalu merupakan ide yang baik
Hubert Kario

3
GRUB2 mendukung booting dari volume logis LVM (lihat wiki.archlinux.org/index.php/GRUB2#LVM ) tetapi GRUB1 tidak. Saya akan selalu menggunakan non-LVM / boot terpisah hanya untuk memastikan mudah dipulihkan. Sebagian besar disk penyelamat saat ini memang mendukung LVM - beberapa memerlukan manual vgchange -ayuntuk menemukan volume LVM.
RichVel

1
pada pvmove: lihat poin tentang kehilangan data pvmove yang dibuat dalam jawaban Florian Heigl.
RichVel
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.