Pertanyaan Bahaya dan peringatan LVM


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

Apa kerugian menggunakan LVM?


177
2018-06-12 07:34




Ketika membaca jawaban atas pertanyaan ini, ingatlah tanggal (tahun) mereka diposting. Banyak yang terjadi dalam 3 tahun di industri ini. - MattBianco
Saya telah melakukan beberapa pembaruan baru-baru ini (Apr 2015) setelah dipindai untuk melihat apakah ada 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 penggunaan snapshot VM / server cloud daripada snapshot LVM. Keadaan penulisan cache, mengubah ukuran filesystem dan snapshot LVM belum benar-benar berubah banyak sejauh yang saya bisa lihat. - RichVel
mengenai komentar "ingatlah tanggal" - cukup benar, tetapi pertimbangkan juga bahwa banyak "perusahaan" masih menggunakan RHEL 5 dan RHEL 6, yang keduanya merupakan state-of-the-art atau lebih tua dari tanggal jawabannya - JDS


Jawaban:


Ringkasan

Risiko menggunakan LVM:

  • Rentan untuk menulis masalah cache dengan hypervisor SSD atau VM
  • Lebih sulit untuk memulihkan data karena struktur on-disk yang lebih kompleks
  • Lebih sulit untuk mengubah ukuran filesystem dengan benar
  • Snapshot sulit digunakan, lambat dan buggy
  • Membutuhkan beberapa keterampilan untuk mengkonfigurasi dengan benar mengingat masalah ini

Dua masalah pertama LVM menggabungkan: jika cache tulis tidak berfungsi dengan benar dan Anda kehilangan daya (mis. PSU atau UPS gagal), Anda mungkin harus memulihkan dari cadangan, yang berarti waktu henti yang signifikan. Alasan utama untuk menggunakan LVM adalah waktu kerja yang lebih tinggi (saat menambahkan disk, mengubah ukuran filesystem, dll), tetapi penting untuk mendapatkan pengaturan penulisan cache yang benar untuk menghindari LVM benar-benar mengurangi waktu kerja.

- Diperbarui pada Sep 2017: membuat kernel lama menjadi kurang menonjol

Memitigasi risiko

LVM masih dapat berfungsi dengan baik jika Anda:

  • Dapatkan pengaturan penulisan cache Anda tepat di hypervisor, kernel, dan SSD
  • Hindari snapshot LVM
  • Gunakan versi LVM terbaru untuk mengubah ukuran filesystem
  • Memiliki cadangan yang bagus

Detail

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

Rentan menulis caching hard disk karena hypervisor VM, disk cache atau kernel Linux lama, dan membuatnya lebih sulit untuk memulihkan data karena struktur on-disk yang lebih kompleks - lihat di bawah untuk detailnya. Saya telah melihat pengaturan LVM lengkap pada beberapa disk rusak tanpa kemungkinan pemulihan, dan LVM ditambah hard disk menulis cache adalah kombinasi yang berbahaya.

  • Tulis caching dan tulis pemesanan ulang oleh hard drive Penting untuk kinerja yang baik, tetapi dapat gagal untuk menyiram blok ke disk dengan benar karena hypervisor VM, hard drive menulis caching, kernel Linux lama, dll.
    • Tulis hambatan berarti kernel menjamin bahwa ia akan menyelesaikan penulisan disk tertentu sebelum "penghalang" menulis disk, untuk memastikan bahwa filesystem dan RAID dapat pulih jika terjadi kehilangan daya secara tiba-tiba atau crash. Hambatan semacam itu dapat menggunakan Operasi FUA (Akses Unit Force) untuk segera menulis blok tertentu ke disk, yang lebih efisien daripada penyiraman cache penuh. Hambatan dapat dikombinasikan dengan efisien diberi tag/asli perintah antrian (mengeluarkan banyak permintaan I / O sekaligus) untuk mengaktifkan hard drive untuk melakukan penulisan ulang yang cerdas tanpa meningkatkan risiko kehilangan data.
  • Hypervisors 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 serupake kernel tanpa hambatan tulis, karena menulis caching dan menulis pemesanan ulang. Periksa dokumentasi hypervisor Anda dengan hati-hati untuk opsi "flush to disk" atau write-through cache (hadir di KVM, VMware, Xen, VirtualBox dan lainnya) - dan uji dengan pengaturan Anda. Beberapa hypervisor seperti VirtualBox pengaturan standar yang mengabaikan flushes disk dari tamu.
  • Server perusahaan dengan LVM harus selalu menggunakan kontroler RAID yang didukung baterai dan nonaktifkan cache hard disk write (pengontrol memiliki cache tulis yang didukung baterai yang cepat dan aman) - lihat komentar ini oleh penulis entri FAQ XFS ini. Mungkin juga aman untuk matikan penghalang tulis di kernel, tetapi pengujian dianjurkan.
  • Jika Anda tidak memiliki kontroler RAID yang didukung baterai, menonaktifkan penulisan hard disk akan memperlambat penulisan tetapi membuat LVM aman. Anda juga harus menggunakan ekuivalen dengan ext3 data=ordered opsi (atau data=journal untuk keamanan ekstra), plus barrier=1 untuk memastikan bahwa caching kernel tidak mempengaruhi integritas. (Atau gunakan ext4 yang mana memungkinkan hambatan secara default.) Ini adalah opsi yang 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 bergantung pada pengaturan default untuk FS.)
  • Untuk menonaktifkan caching 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 XFS FAQ (yang sangat bagus dalam topik ini), drive SATA mungkin lupa pengaturan ini setelah pemulihan galat drive - jadi Anda harus menggunakan SCSI / SAS, atau jika Anda harus menggunakan SATA, maka letakkan perintah hdparm dalam cron job berlari setiap menit atau lebih.
  • Untuk menjaga penyimpanan SSD / caching hard drive diaktifkan untuk kinerja yang lebih baik: ini adalah area yang kompleks - lihat bagian di bawah ini.
  • Jika Anda menggunakan Drive Format Lanjut yaitu 4 sektor fisik KB, lihat di bawah - menonaktifkan penulisan cache mungkin memiliki masalah lain.
  • UPS Sangat penting untuk kedua perusahaan dan SOHO tetapi tidak cukup untuk membuat LVM aman: apa pun yang menyebabkan crash keras atau kehilangan daya (mis. Kegagalan UPS, kegagalan PSU, atau keletihan baterai laptop) dapat kehilangan data dalam cache hard drive.
  • Kernel Linux yang sangat tua (2.6.x dari 2009): Ada dukungan penghalang tulis yang tidak lengkap dalam versi kernel lama, 2.6.32 dan sebelumnya (2.6.31 memiliki dukungan, sementara 2.6.33 berfungsi untuk semua jenis target perangkat) - RHEL 6 menggunakan 2.6.32 dengan banyak tambalan. Jika kernel 2.6 yang lama ini tidak di-unpatched untuk masalah ini, sejumlah besar metadata FS (termasuk jurnal) dapat hilang oleh hard crash yang meninggalkan data di hard drive write hard disk (katakanlah 32 MB per drive untuk drive SATA umum). Kehilangan 32 MB data metadata dan jurnal FS yang baru-baru ini ditulis, yang menurut kernel sudah ada dalam disk, biasanya berarti banyak korupsi FS dan karenanya kehilangan data.
  • Ringkasan: Anda harus berhati-hati dalam filesystem, RAID, VM hypervisor, 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. Ini juga disarankan untuk menggunakan drive SCSI / SAS karena ini cenderung berbohong tentang bagaimana mereka menulis caching - lebih hati-hati diperlukan untuk menggunakan drive SATA.

Menjaga cache penulisan tetap aktif untuk kinerja (dan mengatasi dengan drive yang berbohong)

Pilihan yang lebih kompleks tetapi lebih baik adalah menjaga penyimpanan caching tulis SSD / hard drive dan mengandalkan kernel write barriers yang bekerja dengan LVM pada kernel 2.6.33+ (periksa ulang dengan mencari pesan "penghalang" di log).

Anda juga harus memastikan bahwa pengaturan RAID, pengaturan hypervisor VM dan sistem file menggunakan hambatan tulis (yaitu membutuhkan drive untuk mem-flush pending write sebelum dan sesudah metadata / journal menulis). XFS memang menggunakan hambatan secara default, tetapi ext3 tidak, jadi dengan ext3 yang harus Anda gunakan barrier=1 di opsi mount, dan masih digunakan data=ordered atau data=journal seperti di atas.

SSD bermasalah karena penggunaan cache tulis sangat penting untuk masa pakai SSD. Sebaiknya gunakan SSD yang memiliki superkapasitor (untuk mengaktifkan pembilasan cache pada gangguan daya, dan karenanya memungkinkan cache untuk menjadi write-back bukan write-through).

Format Lanjutan pengaturan drive - menulis caching, penyelarasan, RAID, GPT

  • Dengan yang lebih baru Drive Format Lanjut yang menggunakan sektor fisik 4 KiB, mungkin penting untuk mempertahankan penulisan drive caching aktif, karena sebagian besar drive tersebut saat ini meniru sektor logis 512 byte ("512 emulasi"), dan beberapa bahkan mengklaim memiliki sektor fisik 512-byte sementara benar-benar menggunakan 4 KiB.
  • Mematikan cache tulis dari 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 menulis sebelum melakukan fisik 4 KiB tunggal 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 untuk PV sejajar, karena LVM Physical Extents (PEs) adalah 4 MiB secara default. RAID harus dipertimbangkan di sini - ini Halaman konfigurasi LVM dan perangkat lunak RAID menyarankan meletakkan RAID superblok di akhir volume dan (jika perlu) menggunakan opsi pvcreate untuk menyelaraskan PV. Thread daftar email LVM ini menunjukkan pekerjaan yang dilakukan dalam 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 boot + root disk, untuk memastikan partisi LVM pertama (PV) dimulai pada batas 4 KiB.

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

  • Setiap pemulihan data LVM diperlukan setelah crash keras atau kehilangan daya (karena salah menulis caching) adalah proses manual yang terbaik, karena tampaknya tidak ada alat yang sesuai. LVM bagus dalam membuat cadangan metadatanya /etc/lvm, yang dapat membantu memulihkan struktur dasar LV, VG, dan PV, tetapi tidak akan membantu metadata sistem file yang hilang.
  • Oleh karena itu, pemulihan penuh dari cadangan mungkin diperlukan. Ini melibatkan lebih banyak waktu henti daripada fsck berbasis jurnal cepat ketika tidak menggunakan LVM, dan data yang ditulis sejak cadangan terakhir akan hilang.
  • TestDisk, ext3grep, ext3undel dan alat lainnya  dapat memulihkan partisi dan file dari non-LVM disk tetapi mereka tidak secara langsung mendukung pemulihan data LVM. TestDisk dapat menemukan bahwa partisi fisik yang hilang berisi LVM PV, tetapi tidak satu pun dari alat ini memahami volume logis LVM. Ukiran file alat seperti PhotoRec dan banyak lainnya akan bekerja ketika mereka melewati filesystem untuk merakit ulang file dari blok data, tetapi ini adalah pendekatan tingkat rendah terakhir untuk data berharga, dan berfungsi kurang baik dengan file yang terfragmentasi.
  • Pemulihan LVM manual dimungkinkan dalam beberapa kasus, tetapi sangat kompleks dan memakan waktu - lihat contoh ini dan ini, ini, dan ini bagaimana cara memulihkannya.

Lebih sulit untuk mengubah ukuran filesystem dengan benar - mudah mengubah ukuran filesystem 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 naik, dan dalam beberapa kasus dengan FS yang terpasang, tetapi saya tidak akan pernah mempertaruhkan yang terakhir tanpa cadangan terkini dan menggunakan perintah yang telah diuji sebelumnya pada server yang setara (mis. pemulihan bencana klon server produksi).

  • Memperbarui: Versi terbaru dari lvextend dukung -r (--resizefs) pilihan - jika ini tersedia, itu cara yang lebih aman dan lebih cepat untuk mengubah ukuran LV dan filesystem, terutama jika Anda mengecilkan FS, dan Anda dapat melewatkan sebagian besar bagian ini.
  • Kebanyakan panduan untuk mengubah ukuran FS berbasis LVM tidak memperhitungkan fakta bahwa FS harus lebih kecil daripada ukuran LV: penjelasan rinci di sini. Ketika mengecilkan sistem file, Anda harus menentukan ukuran baru ke alat pengubah ukuran FS, mis. resize2fs untuk ext3, dan to lvextend atau lvreduce. Tanpa perhatian besar, ukurannya mungkin sedikit berbeda karena perbedaan antara 1 GB (10 ^ 9) dan 1 GiB (2 ^ 30), atau cara berbagai alat berputar ke atas atau ke bawah.
  • Jika Anda tidak melakukan perhitungan dengan tepat (atau menggunakan beberapa langkah tambahan di luar yang paling jelas), Anda mungkin berakhir dengan FS yang terlalu besar untuk LV. Semuanya akan baik-baik saja selama berbulan-bulan atau bertahun-tahun, sampai Anda benar-benar mengisi FS, pada titik mana Anda akan mendapatkan korupsi serius - dan kecuali Anda menyadari masalah ini sulit untuk mencari tahu mengapa, karena Anda mungkin juga memiliki kesalahan disk yang nyata saat itu. itu mengaburkan situasinya. (Mungkin masalah ini hanya mempengaruhi mengurangi ukuran filesystem - namun, jelas bahwa mengubah ukuran filesystem di kedua arah memang meningkatkan risiko kehilangan data, mungkin karena kesalahan pengguna.)
  • Tampaknya ukuran LV harus lebih besar dari ukuran FS sebesar 2 x ukuran fisik LVM (PE) - tetapi periksa tautan di atas untuk rincian sebagai sumber untuk ini tidak berwibawa. Sering mengizinkan 8 MiB cukup, tetapi mungkin lebih baik untuk memungkinkan lebih banyak, mis. 100 MiB atau 1 GiB, hanya untuk aman. Untuk memeriksa ukuran PE, dan ukuran volume + FS logis Anda, menggunakan 4 KiB = 4096 blok byte:

    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, setup non-LVM membuat pengubahan ukuran FS sangat andal dan mudah dijalankan Gparted dan mengubah ukuran FS yang dibutuhkan, maka itu akan melakukan segalanya untuk Anda. Di server, Anda dapat menggunakan parted dari cangkangnya.

    • Sering kali yang terbaik adalah menggunakan Live CD Gparted atau Sihir Parted, karena ini memiliki Gparted & kernel yang lebih baru dan sering lebih bebas bug daripada versi distro - Saya pernah kehilangan seluruh FS karena distro Gparted tidak memperbarui partisi dengan benar di kernel berjalan. Jika menggunakan distro's Gparted, pastikan untuk reboot segera setelah mengubah partisi sehingga tampilan kernel benar.

Snapshot sulit digunakan, lambat dan buggy- jika snapshot kehabisan ruang yang telah dialokasikan sebelumnya otomatis terputus. Setiap snapshot dari LV yang diberikan adalah delta terhadap LV itu (bukan terhadap snapshot sebelumnya) yang dapat membutuhkan banyak ruang ketika snapshotting filesystem dengan aktivitas menulis yang signifikan. Aman untuk membuat snapshot LV yang ukurannya sama dengan LV asli, karena snapshot tidak akan pernah kehabisan ruang kosong.

Snapshot 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 sebagian karena snapshot membutuhkan banyak penulisan yang sinkron.

Cuplikan memiliki beberapa bug yang signifikan, mis. dalam beberapa kasus mereka dapat membuat boot sangat lambat, atau menyebabkan boot gagal sepenuhnya (karena kernel dapat habis waktu  menunggu root FS ketika snapshot LVM [tetap di Debian initramfs-tools pembaruan, Mar 2015]).

  • Satu metrik adalah ada banyak bug Debian sesuai "lvm snapshot 2015", beberapa di antaranya cukup serius - namun, banyak bug kondisi balapan snapshot rupanya telah diperbaiki. LVM tanpa snapshot umumnya tampak cukup baik, mungkin karena snapshot tidak digunakan sebanyak fitur inti.

Alternatif snapshot - filesystem dan hypervisor VM

Snapshot VM / cloud:

  • Jika Anda menggunakan hypervisor VM atau penyedia cloud IaaS, snapshot mereka (misalnya snapshot EBS VMware, VirtualBox atau Amazon EC2) sering menjadi alternatif yang jauh lebih baik daripada snapshot LVM. Anda dapat dengan mudah mengambil snapshot untuk tujuan cadangan (tetapi pertimbangkan untuk membekukan FS sebelum Anda melakukannya).

Cuplikan sistem file:

  • snapshot filesystem level dengan ZFS atau btrfs mudah digunakan dan umumnya lebih baik daripada LVM, dan meskipun tidak ada filesystem yang sangat matang di Linux, mereka mungkin menjadi pilihan yang lebih baik untuk orang-orang yang benar-benar membutuhkan snapshot tanpa menggunakan VM / rute cloud:

    • ZFS: sekarang ada a implementasi ZFS kernel, yang telah digunakan selama beberapa tahun dan seharusnya jauh lebih cepat daripada ZFS pada FUSE.
    • btrfs tidak cukup siap untuk digunakan produksi, dan itu fsck dan alat perbaikan masih dalam pengembangan.

Snapshot untuk backup online dan fsck

Snapshot dapat digunakan untuk memberikan yang konsisten sumber untuk backup, selama Anda berhati-hati dengan alokasi ruang (idealnya snapshot memiliki ukuran yang sama dengan LV yang didukung). Sangat bagus rsnapshot (sejak 1.3.1) bahkan mengelola pembuatan / penghapusan snapshot LVM untuk Anda - lihat ini HOWTO pada rsnapshot menggunakan LVM. Namun, perhatikan masalah umum dengan snapshot dan bahwa snapshot seharusnya tidak dianggap sebagai cadangan itu sendiri.

Anda juga dapat menggunakan snapshot LVM untuk melakukan fsck online: snapshot LV dan fsck snapshot, sementara masih menggunakan FS non-snapshot utama - dijelaskan di sini - Namun, itu tidak sepenuhnya lugas jadi yang terbaik untuk digunakan e2croncheck sebagai dijelaskan oleh Ted Ts'o, pengelola ext3.

Kamu harus "membekukan" filesystem sementara saat mengambil snapshot - beberapa filesystem seperti ext3 dan XFS akan lakukan 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 memilih partisi mentah. Manfaat utama yang dapat saya lihat dari LVM adalah fleksibilitas memindahkan dan mengubah ukuran FS ketika Anda harus memiliki waktu aktif yang tinggi di server - jika Anda tidak membutuhkannya, gparted lebih mudah dan memiliki risiko kehilangan data yang lebih sedikit.

LVM membutuhkan perhatian besar pada pengaturan penulisan cache 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 btrs cukup matang dibandingkan dengan LVM dengan snapshot.

Intinya: Jika Anda tidak tahu tentang masalah yang tercantum di atas dan bagaimana mengatasinya, sebaiknya tidak menggunakan LVM.


238
2018-06-12 08:19



Mengubah ukuran online dengan xfs bekerja dengan sempurna, Anda bahkan tidak perlu menentukan ukurannya. Ini akan tumbuh ke ukuran LV baca lebih lanjut di xfs_grow (5). OTOH Saya memukul +1 untuk ringkasan tentang hambatan tulis. - cstamas
DUDE! Di mana saja kau selama hidup saya!? - songei2f
@TREE: ide dengan kontroler RAID yang didukung oleh baterai adalah bahwa temboloknya persisten di seluruh gangguan daya dan umumnya dapat dipercaya untuk bekerja sebagaimana didokumentasikan, sedangkan beberapa cache hard disk berbohong tentang apakah mereka benar-benar telah menulis blok ke disk, dan dari Tentu saja cache ini tidak persisten. Jika Anda meninggalkan cache hard disk diaktifkan, Anda rentan terhadap kegagalan daya tiba-tiba (misalnya PSU atau UPS gagal), yang dilindungi oleh cadangan baterai RAID controller. - RichVel
Salah satu jawaban terbaik yang pernah saya lihat, topik apa pun. Hanya perubahan yang akan saya buat, pindahkan ringkasan ke TOP dari pertanyaan untuk mereka yang mengalami gangguan attention deficit atau tidak banyak waktu. :-) - Prof. Falken
Melihat semua komentar dan pembaruan terakhir untuk jawabannya adalah setahun yang lalu, saya bertanya-tanya apakah jawabannya dapat diperbarui untuk mencerminkan perubahan baru dalam hal keandalan, kinerja, dan kemudahan penggunaan. - Luis Alvarado


Saya [+1] posting itu, dan setidaknya untuk saya, saya pikir sebagian besar masalah memang ada. Lihat mereka saat menjalankan beberapa 100 server dan beberapa 100TB data. Bagi saya, LVM2 di Linux terasa seperti "ide pintar" yang dimiliki seseorang. Seperti beberapa dari ini, mereka ternyata menjadi "tidak pintar" di kali. Yaitu. tidak memiliki negara-negara kernel dan userspace (lvmtab) yang sangat terpisah mungkin merasa sangat pintar untuk menghapusnya, karena mungkin ada masalah korupsi (jika Anda tidak mendapatkan kode yang benar)

Hanya saja pemisahan ini ada di sana untuk sebuah alasan - perbedaannya ditunjukkan dengan penanganan kerugian PV, dan aktivasi ulang secara online dari VG dengan yaitu hilangnya PV untuk membawa mereka kembali bermain - Apa yang mudah pada "LVM asli" (AIX, HP-UX) berubah menjadi omong kosong pada LVM2 sejak penanganan negara tidak cukup baik. Dan bahkan tidak membuat saya berbicara tentang deteksi hilangnya kuorum (haha) atau penanganan negara (jika saya menghapus disk, yang tidak akan ditandai sebagai tidak tersedia. Itu bahkan tidak memiliki kolom status sialan)

Re: stabilitas pvmove... kenapa

pvmove kehilangan data

seperti artikel peringkat teratas di blog saya, hmmm? Baru saja saya melihat disk di mana data lvm phyiscal masih digantung pada negara dari pertengahan pvmove. Ada beberapa pemikir yang saya pikir, dan ide umum adalah hal yang baik untuk menyalin data blok live dari userspace yang menyedihkan. Kutipan bagus dari daftar lvm "sepertinya vgreduce --missing tidak menangani pvmove" Berarti sebenarnya jika sebuah disk melepaskan 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 ternyata tidak lagi menulis data ke perangkat target. WTF?

Re: Snapshots Kontrak Karya dilakukan dengan tidak aman, dengan memperbarui data BARU ke area snapshot dan kemudian menggabungkan kembali setelah Anda menghapus snap. Ini berarti Anda memiliki lonjakan IO 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 tidak snapshot akan rusak setelah Anda menekan dinding, tapi yang asli.

Keuntungannya adalah dalam kinerja, melakukan 1 menulis, bukan 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 akan "dilakukan dengan benar". Saya tidak melihat banyak masalah kinerja selama saya memiliki snapshot backing store di berbeda disk drive daripada data primer (dan cadangan untuk satu lagi tentu saja)

Re: Hambatan Saya tidak yakin apakah orang bisa menyalahkan itu pada LVM. Itu adalah masalah devmapper, sejauh yang saya tahu. Tetapi ada beberapa kesalahan karena tidak terlalu peduli tentang masalah ini dari setidaknya kernel 2.6 hingga 2.6.33 AFAIK Xen adalah satu-satunya hypervisor yang menggunakan O_DIREK untuk mesin virtual, masalah yang digunakan ketika "loop" digunakan karena kernel akan tetap menggunakan cache itu. VirtualBox setidaknya memiliki beberapa pengaturan untuk menonaktifkan hal-hal seperti ini dan Qemu / KVM umumnya 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 harus menggunakan ukuran VG Pe dan mengalikannya dengan jumlah LE dari LV. Itu harus memberikan ukuran bersih yang benar, dan masalah itu selalu merupakan masalah penggunaan. Hal ini diperburuk oleh filesystem yang tidak memperhatikan hal seperti itu selama fsck / mount (hello, ext3) atau tidak memiliki kerja online "fsck -n" (halo, ext3)

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

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

Perbarui beberapa bulan kemudian: Saya telah mencapai skenario "cuplikan penuh" untuk tes sekarang. Jika mereka penuh, blok snapshot, 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 membiarkan mereka penuh dan jadi saya tidak pernah berakhir terkoreksi. Juga dimungkinkan untuk memperpanjang / mengecilkan snapshot, yang merupakan suguhan.

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


15
2017-12-11 14:03



Poin bagus, terutama pada kehilangan data pvmove (tidak menyadari ini bisa crash di bawah memori rendah) dan desain snapshot. Pada write barriers / caching: Saya mengonfigurasi LVM dan mapper perangkat kernel karena dari sudut pandang pengguna mereka bekerja sama untuk memberikan apa yang LVM sediakan. Upvoted. Juga menyukai posting blog Anda di kehilangan data pvmove: deranfangvomende.wordpress.com/2009/12/28/… - RichVel
Pada snapshot: mereka sangat lambat di LVM, jadi jelas itu bukan keputusan desain yang baik untuk mencari performa melebihi keandalan. Dengan "membentur dinding", apakah yang Anda maksudkan adalah pengisian snapshot, dan dapatkah itu benar-benar menyebabkan korupsi dari data LV asli? The LVM HOWTO mengatakan bahwa snapshot dijatuhkan dalam kasus ini: tldp.org/HOWTO/LVM-HOWTO/snapshots_backup.html - RichVel
"Kontrak Karya dilakukan dengan tidak aman, dengan memperbarui data BARU ke area snapshot dan kemudian menggabungkan kembali setelah Anda menghapus snap." Ini salah. Ketika data baru ditulis ke perangkat asli, itu tua Versi ditulis ke daerah snapshot COW. Tidak ada data yang digabungkan kembali (kecuali jika Anda mau). Lihat kernel.org/doc/Documentation/device-mapper/snapshot.txt untuk semua detail teknis yang mengerikan. - Damien Tournoud
Hai Damien, lain kali baca terus ke titik di mana saya memperbaiki pos saya? - Florian Heigl


jika Anda berencana untuk menggunakan snapshot untuk backup - bersiaplah untuk performa utama ketika snapshot hadir. Baca lebih lajut sini. kalau tidak semuanya baik-baik saja. Saya telah menggunakan lvm dalam produksi selama beberapa tahun pada puluhan server, meskipun alasan utama saya untuk menggunakannya adalah snapshot atom bukan kemampuan untuk memperluas volume dengan mudah.

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


12
2018-06-12 09:44



Memberi +1 untuk peringatan kinerja untuk foto yang terbuka. - Prof. Falken
Pengalaman saya adalah drive 1TB biasanya menggunakan sektor 512 byte, tetapi kebanyakan drive 2TB menggunakan 4KB. - Dan Pritts
@DanPritts tidak ada salahnya mengasumsikan bahwa ukuran sektor adalah 4kB atau bahkan 128kB - untuk berjaga-jaga jika ada penyerbuan di antaranya. Anda kehilangan begitu sedikit - mungkin 128kB itu dan Anda dapat memperoleh banyak. juga saat pencitraan dari disk lama ke disk baru. - pQd
Ada beberapa bahaya kecil untuk membuat ukuran blok filesystem "terlalu besar"; setiap file terkandung dalam tidak kurang dari satu blok. Jika Anda punya banyak file kecil dan 128 KB blok itu akan bertambah. Saya setuju bahwa 4K cukup masuk akal, dan jika Anda memindahkan filesystem ke perangkat keras baru, Anda akan berakhir dengan sektor 4k akhirnya. - Dan Pritts
(Tidak akan membiarkan saya mengedit komentar saya sebelumnya) ... Buang-buang ruang mungkin tidak masalah, tetapi itu akan berakhir meningkatkan rata-rata Anda mencari waktu pada disk berputar. Ini mungkin bisa berubah menjadi amplifikasi tulis (mengisi sektor dengan nol) pada SSD. - Dan Pritts


Adam,

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

Kerugian yang saya tidak tunjukkan dengan jelas: Ada kurva belajar yang agak curam untuk LVM2. Sebagian besar dalam abstraksi itu menciptakan antara file Anda dan media yang mendasarinya. Jika Anda bekerja hanya dengan beberapa orang yang berbagi tugas di sejumlah server, Anda mungkin menemukan kerumitan 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 mengajari seluruh tim dasar-dasar, bahasa dan hal-hal mendasar tentang memulihkan sistem yang tidak bisa di-boot dengan benar.

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

Secara keseluruhan, saya penggemar LVM2.


5
2018-06-22 21:03



penyimpanan /boot berpisah selalu merupakan ide yang bagus - Hubert Kario
GRUB2 tidak mendukung boot 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 memastikannya mudah dipulihkan. Kebanyakan disk penyelamat saat ini mendukung LVM - beberapa memerlukan manual vgchange -ayuntuk menemukan volume LVM. - RichVel
di pvmove: lihat point tentang kehilangan data pvmove yang dibuat dalam jawaban Florian Heigl. - RichVel