Bahaya LVM dan peringatan

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?

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.

• 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).

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

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):

  • ZFS: sekarang ada implementasi kernel ZFS , yang telah digunakan selama beberapa tahun
  • btrfs : masih belum siap untuk penggunaan produksi ( bahkan pada openSUSE yang mengirimkannya secara default dan memiliki tim yang didedikasikan untuk btrfs), sedangkan RHEL telah berhenti mendukungnya), dan fsck serta alat perbaikannya masih dalam pengembangan.

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.

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.

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.

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.