LVM tehlikeleri ve uyarıları

Yakın zamanda, 1 TB'den büyük sabit sürücüler için LVM'yi bazı sunucularda kullanmaya başladım. Yararlı, genişletilebilir ve kurulumu oldukça kolaydır. Ancak LVM'nin tehlikeleri ve uyarıları hakkında herhangi bir veri bulamadım.

LVM kullanmanın olumsuzlukları nelerdir?

özet

LVM kullanmanın riskleri:

• SSD veya VM hipervizörü ile önbelleğe alma sorunları yazmak konusunda hassas
• Daha karmaşık disk üstü yapılar nedeniyle verilerin kurtarılması daha zor
• Dosya sistemlerini doğru şekilde yeniden boyutlandırmak zor
• Anlık görüntüleri kullanmak zor, yavaş ve adamcağız
• Bu sorunları verilen doğru yapılandırmak için biraz beceri gerektirir

İlk iki LVM sorunu bir araya gelirse: yazma önbelleği doğru çalışmıyorsa ve bir güç kaybınız varsa (örn. PSU veya UPS arızalı), yedeklemeden kurtarmanız gerekebilir, bu da önemli bir arıza süresi anlamına gelir. LVM kullanmanın ana nedeni daha yüksek çalışma süresidir (disk eklerken, dosya sistemlerini yeniden boyutlandırarak, vb.), Ancak LVM'nin çalışma süresini azaltmasını önlemek için yazma önbelleğe alma kurulumunu doğru yapmak önemlidir.

- Aralık 2018'de güncellendi: LVM anlık görüntülerine alternatif olarak ZFS ve btrfs kararlılığı dahil, anlık görüntü materyali güncellendi

Riskleri azaltmak

LVM yine de iyi çalışabilir:

• Yazma önbelleğe alma kurulumunuzu hipervizör, çekirdek ve SSD'lerden alın
• LVM anlık görüntülerinden kaçının
• Dosya sistemlerini yeniden boyutlandırmak için en son LVM sürümlerini kullanın
• İyi yedeklemeler var

ayrıntılar

Geçmişte, LVM ile ilgili bazı veri kayıpları yaşadığımda bunu biraz araştırdım. LVM'nin başlıca riskleri ve farkında olduğum konular:

VM hipervizörleri, disk önbelleklemesi veya eski Linux çekirdeği nedeniyle sabit disk yazma önbelleğine karşı hassas ve daha karmaşık disk yapıları nedeniyle verilerin kurtarılmasını zorlaştırır - ayrıntılar için aşağıya bakın. Bazı disklerde LVM kurulumlarının kurtarma şansı olmadan bozulduğunu gördüm ve LVM artı sabit disk yazma önbelleğe alma işlemi tehlikeli bir kombinasyondur.

• Önbelleğe alma ve yazma işleminin sabit sürücü tarafından yeniden sıralanması iyi performans için önemlidir, ancak VM hiper denetleyicileri, sabit disk yazma önbelleği, eski Linux çekirdeği vb.
  • Yazma engelleri , çekirdeğin, ani bir güç kaybı veya çökmesi durumunda dosya sistemlerinin ve RAID'in kurtarılmasını sağlamak için "bariyer" disk yazmadan önce belirli disk yazmalarını tamamlayacağını garanti eder. Bu tür engeller , diske hemen hemen önbellek boşalmasından daha verimli olan bazı blokları hemen diske yazmak için bir FUA (Birim Erişime Zorlama) işlemini kullanabilir. Engeller , sabit sürücünün veri kaybı riskini artırmadan akıllı yazma yeniden siparişi vermesini sağlamak için verimli etiketli / yerel komut kuyruğu (bir kerede birden fazla disk G / Ç isteği yayınlama) ile birleştirilebilir.
• VM hipervizörlerinin benzer sorunları olabilir: LVM'yi bir Linux misafirinde VMware, Xen , KVM, Hyper-V veya VirtualBox gibi bir VM hipervizörünün tepesinde çalıştırmak , yazma önbelleğe alma ve yazma işleminden dolayı yazma engelleri olmadan benzer sorunlar yaratabilir -ordering. "Diske yerleştirme" veya önbelleğe yazma önbellek seçeneği ( KVM , VMware , Xen , VirtualBox ve diğerlerinde bulunur) - hiper yönetici dokümantasyonunuzu dikkatlice kontrol edin ve kurulumunuzla test edin. VirtualBox gibi bazı hipervizörler , konuklardan herhangi bir disk basmasını yok sayan varsayılan bir ayara sahiptir.
• LVM'li kurumsal sunucular her zaman bir batarya destekli RAID denetleyicisini kullanmalı ve sabit disk yazma önbelleğini devre dışı bırakmalıdır (denetleyicide, hızlı ve güvenli olan batarya destekli yazma önbelleği vardır) - bu yorumu bu XFS SSS girişinin yazarı tarafından inceleyin . Çekirdekteki yazma engellerini kapatmak da güvenli olabilir , ancak test edilmesi önerilir.
• Pili destekli bir RAID denetleyiciniz yoksa, sabit sürücü yazma önbelleğini devre dışı bırakmak yazmaları önemli ölçüde yavaşlatır ancak LVM'yi güvenli hale getirir. Ayrıca çekirdek önbelleğe almanın bütünlüğü etkilememesini sağlamak için ext3 data=orderedseçeneğinin (veya data=journalek güvenlik için) eşdeğerini de kullanmalısınız barrier=1. (Veya varsayılan olarak engelleri etkinleştiren ext4'ü kullanın .) Bu en basit seçenektir ve performans maliyetinde iyi veri bütünlüğü sağlar. (Linux varsayılan ext3 seçeneğinidata=writeback bir süre önce daha tehlikeli olarak değiştirmiştir , bu nedenle FS'nin varsayılan ayarlarına güvenmeyin.)
• Sabit sürücü yazma önbelleğini devre dışı bırakmakhdparm -q -W0 /dev/sdX için : /etc/rc.local(SATA için) içindeki tüm sürücüleri ekleyin veya SCSI / SAS için sdparm kullanın. Ancak, XFS SSS’sindeki bu girdiye göre (bu konuda çok iyi), bir SATA sürücüsü bir sürücü hatası kurtarma işleminden sonra bu ayarı unutabilir - bu yüzden SCSI / SAS kullanmanız veya SATA kullanmanız gerekiyorsa Her dakika çalışan bir cron işinde hdparm komutu.
• SSD / sabit sürücü yazma önbelleğini daha iyi performans için etkin tutmak için: bu karmaşık bir alandır - aşağıdaki bölüme bakın.
• Kullandığınız değilseniz Gelişmiş Biçim diskleri yazma önbelleğini devre dışı bırakmak diğer sorunları olabilir - 4 KB fiziksel sektörleri aşağıya bakın yani.
• UPS , hem işletme hem de SOHO için kritiktir ancak LVM'yi güvenli hale getirmek için yeterli değildir: sert bir çökmeye veya güç kaybına neden olan herhangi bir şey (örneğin, UPS arızası, PSU arızası veya dizüstü pilinin tükenmesi) sabit sürücü önbelleklerinde veri kaybedebilir.
• Çok eski Linux çekirdekleri (2009'dan itibaren 2.6.x) : Orada eksik yazma bariyer desteği 2.6.32 ve öncesi, çok eski çekirdek sürümlerinde olduğu ( 2.6.31 bazı desteği vardır iken 2.6.33 eser cihaz hedefinin her türlü) - RHEL 6, çok sayıda yamayla 2.6.32'yi kullanır . Bu eski 2.6 çekirdekler bu sorunlar için yamalanmamışsa, büyük miktarda FS meta verisi (dergiler dahil), sabit sürücülerin yazma arabelleklerinde veri bırakan (genel SATA sürücüler için sürücü başına 32 MB olduğunu söyleyen) sert bir çöküşte kaybolabilir. Çekirdeğin zaten diskte olduğunu düşündüğü en son yazılan FS meta verileri ve dergi verilerinin 32 MB'ını kaybetmek, genellikle çok fazla FS bozulması ve dolayısıyla veri kaybı anlamına gelir.
• Özet: LVM ile birlikte kullanılan dosya sistemi, RAID, VM hipervizörü ve sabit sürücü / SSD kurulumuna dikkat etmeniz gerekir. LVM kullanıyorsanız çok iyi yedeklemelere sahip olmalısınız ve LVM meta verilerini, fiziksel bölüm kurulumunu, MBR'yi ve birim önyükleme kesimlerini özellikle yedeklediğinizden emin olmalısınız. SCSI / SAS sürücülerini kullanmanız da tavsiye edilir, çünkü bunlar yazma önbellekleme konusunda yalan söyleme olasılıkları daha düşüktür - SATA sürücülerini kullanmak için daha fazla özen gerekir.

Yazma önbelleğini performans için etkin tutma (ve yalancı sürücülerle başa çıkma)

Daha karmaşık ancak performans gösteren bir seçenek, SSD / sabit disk yazma önbelleğe almayı etkin kılmak ve Çekirdek 2.6.33+ üzerinde LVM ile çalışan çekirdek yazma engellerine dayanmaktır (günlüklerde “engel” mesajları arayarak iki kez kontrol edin).

Ayrıca RAID kurulumu, VM hiper yönetici kurulumu ve dosya sisteminin yazma engelleri kullandığından emin olmalısınız (yani, sürücünün anahtar meta veri / günlük yazma işleminden önce ve sonra bekleyen yazıların yıkanmasını gerektirir). XFS varsayılan olarak kullanılması engelleri yok, ama ext3 değil kullanmanız gereken ext3'te ile böylece barrier=1bağlama seçeneklerinde ve hala kullanmaya data=orderedveya data=journalyukarıdaki gibi.

• Maalesef, bazı sabit sürücüler ve SSD'ler , önbelleklerini diske gerçekten attıp atmadıkları (özellikle eski sürücüler, ancak bazı SATA sürücüleri ve bazı kurumsal SSD'ler dahil ) hakkında daha fazla ayrıntı - buradaki daha fazla ayrıntı . Bir yoktur bir XFS geliştiriciden harika özeti .
• Orada bir var sürücüleri yalan için basit bir test aracı (Perl script) veya bkz başka aracı ile bu arka plan tahrik önbellek sonucu yazma yeniden sipariş için test. Bu cevap , RAID yazılımındaki yazma engelini çözen SATA sürücülerinin benzer testlerini içeriyordu - bu testler aslında tüm depolama yığınını kullanıyor.
• Native Command Queuing'i (NCQ) destekleyen daha yeni SATA sürücülerinin yatma olasılıkları daha düşük olabilir - veya NCQ nedeniyle yazma önbelleği olmadan iyi çalışırlar ve çok az sürücü yazma önbelleğini devre dışı bırakamaz.
• SCSI / SAS sürücüleri, iyi bir performans sergilemek için yazma önbelleğe alma gereksinimine sahip olmadıklarından (genellikle SATA'nın NCQ'suna benzer şekilde SCSI Tagged Command Queuing aracılığıyla) iyi olduklarından genel olarak iyidir.
• Sabit sürücüleriniz veya SSD'niz önbelleklerini diske temizleme konusunda yalan söylüyorsa, gerçekten yazma engellerine güvenemezsiniz ve yazma önbelleğe almayı devre dışı bırakmanız gerekir. Bu, sadece LVM için değil tüm dosya sistemleri, veritabanları, birim yöneticileri ve RAID yazılımı için bir sorundur .

SSD'ler sorunludur çünkü yazma önbellek kullanımı SSD'nin ömrü boyunca kritik öneme sahiptir. Süper kapasitörlü bir SSD kullanmak en iyisidir (elektrik kesintisinde önbellek temizlemeyi etkinleştirmek ve bu nedenle önbelleğin yazmaya değil tekrar yazılmasını sağlamak için).

• Kurumsal SSD'lerin çoğu yazma önbellek kontrolünde Tamam olmalı ve bazıları süper kapasitörler içerir.
• Bazı ucuz SSD'lerin yazma önbellek yapılandırmasıyla çözülemeyen sorunları var - PostgreSQL projesinin posta listesi ve Güvenilir Yazma wiki sayfası iyi bilgi kaynaklarıdır. Tüketici SSD'leri, veri kaybına neden olacak önemli yazma önbelleği sorunları yaşayabilir ve süper kapasitörler içermez;

Gelişmiş Format sürücü kurulumu - yazma önbelleği, hizalama, RAID, GPT

• 4 KiB fiziksel kesimi kullanan daha yeni Gelişmiş Formatlı sürücülerde , bu tür sürücülerin şu anda 512 baytlık mantıksal kesimleri ( "512 öykünme" ) taklit ettiği ve hatta bazılarının 512 baytlık fiziksel olduğunu iddia ettiği için sürücü yazma önbelleğe alma özelliğini etkin tutmak önemli olabilir. sektörleri gerçekten 4 KiB kullanırken.
• Bir Advanced Format sürücünün yazma önbelleğini kapatmak, uygulama / çekirdek 512 bayt yazıyorsa çok büyük bir performans etkisine neden olabilir; çünkü bu tür sürücüler, tek bir 4 KiB fiziksel işlem yapmadan önce 8 x 512 bayt yazma biriktirmek için önbelleğe güvenir yazmak. Önbelleği devre dışı bırakırsanız herhangi bir etkiyi onaylamak için test yapılması önerilir.
• LV'leri 4 KiB sınırında hizalamak performans için önemlidir, ancak LVM Fiziksel İçerikler (PE'ler) varsayılan olarak 4 MiB olduğundan, PV'ler için temel bölümler hizalı olduğu sürece otomatik olarak gerçekleşmelidir. RAID burada göz önünde bulundurulmalıdır - bu LVM ve yazılım RAID kurulum sayfası , RAID süper kilidini birimin sonuna koymanızı ve (gerekirse) pvcreatePV'leri hizalamak için bir seçenek kullanmayı önerir . Bu LVM e-posta listesi iş parçacığı , 2011 yılında çekirdeklerde yapılan çalışmaları işaret eder ve tek bir LV'de 512 bayt ve 4 KiB sektörüyle diskleri karıştırırken kısmi blok yazarlığı konusuna işaret eder.
• Gelişmiş Format ile GPT bölümleme , özellikle ilk LVM bölümünün (PV) 4 KiB sınırında başlamasını sağlamak için özellikle önyükleme + kök diskleri için özen gerektirir.

Daha karmaşık disk üstü yapılar nedeniyle verilerin kurtarılması daha zor :

• Sert bir çökmeden veya elektrik kesintisinden sonra (yanlış yazma önbelleklemesi nedeniyle) gerekli LVM verilerinin kurtarılması en iyi ihtimalle manuel bir işlemdir, çünkü görünüşte uygun hiçbir araç yoktur. LVM /etc/lvm, LV'lerin, VG'lerin ve PV'lerin temel yapısını geri kazanmaya yardımcı olabilecek, ancak kayıp dosya sistemi meta verilerinde yardımcı olmayacak olan meta verilerini yedeklemede iyidir .
• Bu nedenle, yedekten tam bir geri yükleme gerekli olabilir. Bu, LVM kullanılmadığında hızlı bir dergi tabanlı fsck'ten çok daha fazla kesinti içermekte ve son yedeklemeden bu yana yazılan veriler kaybedilmektedir.
• TestDisk , ext3grep , ext3undel ve diğer araçlar LVM olmayan disklerden bölümleri ve dosyaları kurtarabilirler, ancak doğrudan LVM veri kurtarmayı desteklemezler. TestDisk, kaybolan bir fiziksel bölümün bir LVM PV içerdiğini keşfedebilir, ancak bu araçların hiçbiri LVM mantıksal hacimlerini anlamıyor. PhotoRec ve diğerleri gibi dosya oymacılığı araçları , dosyaları veri bloklarından yeniden birleştirmek için dosya sistemini atlattıkları için çalışırlar, ancak bu, değerli veriler için son çare, düşük düzeyli bir yaklaşımdır ve parçalanmış dosyalarla daha az işe yarar.
• Manuel LVM kurtarma bazı durumlarda mümkündür, ancak karmaşık ve zaman alıcıdır - nasıl kurtarılacağı için bu örneğe ve buna , buna ve buna bakın.

Dosya sistemlerinin doğru şekilde yeniden boyutlandırılması zor - kolay dosya sisteminin yeniden boyutlandırılması genellikle LVM'nin bir yararı olarak verilir, ancak LVM tabanlı bir FS'yi yeniden boyutlandırmak için yarım düzine kabuk komutunu çalıştırmanız gerekir - bu, tüm sunucu hala çalışıyor ve bazı durumlarda da yapılabilir. FS takılıyken, ikincisini hiçbir zaman güncel yedeklemeden ve eşdeğer bir sunucuda önceden test edilmiş komutları kullanmadan (örneğin, üretim sunucusunun felaket kurtarma klonu gibi) riske atmam.

• Güncelleme: daha yeni sürümleri lvextenddestekleyen -r( --resizefs) seçeneği - Bu mevcut ise, bu FS küçülüyor, özellikle LV ve dosya sistemi yeniden boyutlandırmak için daha güvenli ve daha hızlı yoludur ve çoğunlukla bu bölümü atlayabilirsiniz.
• LVM tabanlı FS'leri yeniden boyutlandırmaya yönelik çoğu kılavuz, FS'nin LV boyutundan biraz daha küçük olması gerektiğini dikkate almaz: buradaki ayrıntılı açıklama . Bir dosya sistemini daraltırken, yeni boyutu FS yeniden boyutlandırma aracına (örneğin resize2fsext3 ve / lvextendveya için) belirtmeniz gerekir lvreduce. Büyük özen göstermeden, 1 GB (10 ^ 9) ve 1 GiB (2 ^ 30) arasındaki fark veya çeşitli ataşmanların yuvarlakları yukarı veya aşağı yuvarlama şekli nedeniyle boyutlar biraz farklı olabilir .
• Hesaplamaları tam olarak yapmazsanız (veya en belirgin adımların ötesinde bazı ekstra adımlar kullanırsanız), LV için çok büyük bir FS ile sonuçlanabilir. FS'yi tamamen dolana kadar, aylar ya da yıllar boyunca her şey yoluna girecek, bu noktada ciddi yolsuzlukla karşılaşacaksınız - ve bu sorunun farkında olmadığınız sürece, o zamana kadar gerçek disk hataları yaşayabileceğiniz için nedenini bulmak zor Bu durum bulut. (Bu sorunun yalnızca dosya sistemlerinin boyutunu azaltmasını etkilemesi mümkündür - ancak dosya sistemlerinin her iki yönde yeniden boyutlandırılmasının, muhtemelen kullanıcı hatası nedeniyle veri kaybı riskini artırdığı açıktır.)

• LV boyutunun, FS boyutundan 2 x LVM fiziksel boyut (PE) boyutuna göre daha büyük olması gerektiği görünüyor - ancak bunun kaynağı yetkili olmadığı için yukarıdaki bağlantıyı kontrol edin. Genellikle 8 MiB'ye izin vermek yeterlidir, ancak daha fazla, örneğin 100 MiB veya 1 GiB'ye izin vermek daha güvenli olabilir. 4 KiB = 4096 baytlık blokları kullanarak PE boyutunu ve mantıksal hacim + FS boyutlarınızı kontrol etmek için:

  KiB'de PE boyutunu gösterir:
  vgdisplay --units k myVGname | grep "PE Size"
  
  Tüm LV'lerin boyutu: (ext3) FS'nin boyutu, 4 KiB FS blok boyutunda
  lvs --units 4096b
  
  olduğunu varsayar:
  tune2fs -l /dev/myVGname/myLVname | grep 'Block count'

• Buna karşılık, LVM olmayan bir kurulum FS'nin yeniden boyutlandırılmasını çok güvenilir ve kolay bir hale getiriyor - Gparted'i çalıştırın ve gereken FS'leri yeniden boyutlandırın; Sunucularda, partedkabuktan kullanabilirsiniz .

  • Gparted Live CD veya Parted Magic'i kullanmak çoğu zaman en iyisidir , çünkü bunlar dağıtım sürümünden daha yeni ve sık sık hatasız bir Gparted & çekirdeğe sahiptir. çekirdek. Distro Gparted kullanıyorsanız, bölümleri değiştirdikten hemen sonra yeniden başlattığınızdan emin olun, böylece çekirdek görünümü doğru olur.

Anlık görüntüleri kullanmak zor, yavaş ve parazit - anlık görüntü önceden ayrılmış alanın dışında kalırsa, otomatik olarak durdurulur . Belirli bir LV'nin her anlık görüntüsü, önemli yazma etkinliğine sahip anlık görüntü dosya sistemleri (her anlık görüntü öncekinden daha büyük) olduğunda çok fazla alan gerektiren bu LV'ye (önceki anlık görüntülere karşı değil) karşı bir deltadır. Orijinal LV ile aynı boyutta bir anlık görüntü LV oluşturmak güvenlidir, çünkü anlık görüntü daha sonra hiç boş alan kalmaz.

Anlık görüntüler de çok yavaş olabilir ( bu, MySQL testlerinde LVM'sizden 3 ila 6 kat daha yavaş anlamına gelir ) - çeşitli anlık görüntü sorunlarını kapsayan bu cevaba bakın . Yavaşlık kısmen anlık görüntülerin birçok senkronize yazma gerektirdiğindendir .

Anlık görüntülerde bazı önemli hatalar oldu, örneğin bazı durumlarda önyüklemeyi çok yavaşlatabilir veya önyüklemenin tamamen başarısız olmasına neden olabilir (çünkü bir LVM anlık görüntüsü olduğunda çekirdek FS kökünü beklerken zaman aşımına uğrayabilir [Debian initramfs-toolsgüncellemesinde, Mar 2015] ).

• Bununla birlikte, birçok anlık yarış koşulu hatası, görünüşte 2015 yılına kadar düzeltildi .
• Anlık görüntülere sahip olmayan LVM genellikle oldukça iyi bir hata ayıklama gibi görünmektedir, çünkü anlık görüntülerin çekirdek özellikleri kadar kullanılmaması nedeniyle.

Anlık görüntü alternatifleri - dosya sistemleri ve VM hipervizörleri

VM / bulut anlık görüntüleri:

• Bir VM hipervizörü veya bir IaaS bulut sağlayıcısı kullanıyorsanız (örn. VMware, VirtualBox veya Amazon EC2 / EBS), anlık görüntüleri LVM anlık görüntülerine çok daha iyi bir alternatiftir. Yedekleme amacıyla kolayca bir anlık görüntü alabilirsiniz (ancak bunu yapmadan önce FS'yi dondurmayı düşünebilirsiniz).

Dosya sistemi anlık görüntüleri:

• ZFS veya btrfs içeren dosya sistemi anlık görüntülerinin kullanımı kolaydır ve genellikle metal kullanıyorsanız LVM'den daha iyidir (ancak ZFS'nin kurulumu daha olgun, daha zahmetli görünüyor):

  • ZFS: Şimdi bir süredir kullanımda olan bir çekirdek ZFS uygulaması var.
  • btrfs : hala üretime hazır değil ( varsayılan olarak sevk eden ve btrfs'e atanan ekibine sahip olan openSUSE'de bile ), RHEL bunu desteklemeyi bıraktı) ve fsck ve onarım araçları hala geliştirilme aşamasında.

Çevrimiçi yedekleme ve fsck için anlık görüntüler

Anlık görüntüler, ayrılan alana dikkat ettiğiniz sürece yedeklemeler için tutarlı bir kaynak sağlamak için kullanılabilir (ideal olarak anlık görüntü, yedeklenen LV ile aynı boyuttadır). Mükemmel rsnapshot ( 1.3.1'den beri) sizin için LVM anlık görüntüsünü oluşturma / silme işlemini bile yönetir - LVM kullanarak bu NASIL belgesine bakın . Ancak, anlık görüntülerle ilgili genel sorunlara ve bir anlık görüntünün kendi başına bir yedekleme olarak değerlendirilmemesi gerektiğini unutmayın.

LV anlık ve hala ana olmayan anlık FS kullanırken, anlık fsck -: Ayrıca bir online fsck yapmak LVM anlık kullanabilirsiniz Burada anlatılan ancak, bu - tamamen kolay değildir o kullanmak en iyisidir böylece e2croncheck olarak Ted Ts tarafından açıklanan o' ext3'ün, idame.

Sen olmalıdır dosya sistemi "dondurmak" ext3 gibi bazı dosya sistemleri ve XFS olacak - ekran görüntüsünü alma geçici otomatik olarak yapmak LVM anlık oluşturduğunda.

Sonuçlar

Bütün bunlara rağmen, hala bazı sistemlerde LVM kullanıyorum, ancak masaüstü kurulumu için ham bölümleri tercih ediyorum. LVM'den görebildiğim en büyük avantaj, bir sunucuda yüksek çalışma süresine sahip olmanız gerektiğinde FS'leri taşıma ve yeniden boyutlandırma esnekliğidir - buna ihtiyacınız yoksa, gparted daha kolay ve daha az veri kaybı riski taşır.

LVM, VM hipervizörleri, sabit sürücü / SSD yazma önbelleği vb. Nedeniyle yazma önbelleğe alma kurulumuna büyük özen gerektirir - ancak aynı şey Linux'u DB sunucusu olarak kullanmak için de geçerlidir. Çoğu araçtan destek alınmaması ( gpartedkritik boyut hesaplamaları testdiskvb. Dahil ) kullanımı gerekenden daha zorlaştırır.

LVM kullanıyorsanız anlık görüntülere çok dikkat edin: mümkünse VM / cloud anlık görüntülerini kullanın veya LVM'yi tamamen önlemek için ZFS / btrfs'yi inceleyin - ZFS veya btr'lerin anlık görüntülerle LVM'ye kıyasla yeterince olgun olduğunu görebilirsiniz.

Alt satır: Yukarıda listelenen sorunları ve bunları nasıl çözeceğinizi bilmiyorsanız, LVM kullanmamak en iyisidir.

Ben [+1] bu postayı ve en azından benim için sorunların çoğunun var olduğunu düşünüyorum. Birkaç 100 sunucu ve birkaç 100 TB veri çalıştırırken bunları gördüm. Bana göre Linux'taki LVM2 birisinin sahip olduğu "akıllı bir fikir" gibi hissediyor. Bunlardan bazıları gibi, zaman zaman "zeki değil" oldukları ortaya çıkıyor. Yani, kesinlikle çekirdek ve kullanıcı alanı (lvmtab) durumlarını birbirinden ayırmamış olmak, kendisiyle başa çıkmak için gerçekten akıllıca hissedebilir, çünkü yolsuzluk sorunları olabilir (kodu doğru almazsanız).

Eh, tam da bu ayrılmanın bir nedeni vardı - PV kayıp kullanımında farklılıklar var ve bir VG'nin, yani tekrar PV'lerin tekrar devreye girmesiyle çevrimiçi olarak yeniden aktif hale getirilmesi - "Orijinal LVM'lerde" bir esinti nedir (AIX Durum yönetimi yeterince iyi olmadığından, HP-UX) LVM2'de hataya neden olur. Ve beni Quorum kayıp tespiti (haha) ya da durum yönetimi hakkında da konuşma (bir diski çıkarırsam, kullanılamaz olarak işaretlenmez. Lanet durum sütununa bile sahip değildir )

Re: istikrar pvmove ... neden

pvmove veri kaybı

Blogumda böyle bir üst düzey makale, hmmm? Şu anda, phyiscal lvm verilerinin hâlâ pvmove'nin ortasındaki duruma asıldığı bir diske bakıyorum. Sanırım bazı uyuşukluklar oldu ve genel düşüncenin kullanıcı alanından canlı blok verilerini kopyalamak için iyi bir şey olduğu çok üzücü. Lvm listesinden güzel bir alıntı "gibi görünüyor vgreduce - missing pvmove ile başa çıkmıyor" Aslında, bir disk pvmove sırasında ayrılırsa, o zaman lvm yönetim aracı lvm'den vi'ye değişir. Ayrıca pvmove'nin blok okuma / yazma hatasının ardından devam ettiği ve aslında hedef cihaza veri yazmadığı bir hata olmuştur. O NE LAN?

Ynt: Anlık Görüntüler SÇ, YENİ verileri anlık görüntü lv alanına güncelleyerek ve ardından çırpmayı sildikten sonra birleştirerek güvenli olmayan bir şekilde yapılır. Bu, orijinal LV ile yeni verilerin son bir araya getirilmesi sırasında ağır IO yükselmelerine sahip olduğunuz ve daha da önemlisi, elbette çok daha fazla veri bozulması riskine sahip olmanız anlamına gelir; duvar, ancak orijinal.

Avantaj performansta olup, 3 yerine 1 yazar. Hızlı ama güvenli olmayan algoritmayı seçmek, açıkçası VMware ve MS gibi insanlardan beklediğim bir şeydir, "Unix" te, işlerin "doğru yapılmasını" tercih ederim. Anlık görüntü yedekleme deposunu birincil veriden farklı bir disk sürücüde tuttuğum sürece (ve elbette bir başkasına yedekleme yaptığım sürece) pek fazla performans sorunu görmedim.

Ynt: Engeller Biri LVM'de suçlayabileceğinden emin değilim. Bildiğim kadarıyla, bir güçlendirici sorunuydu. Ancak, bu konuyu gerçekten en az çekirdek 2.6'dan 2.6'ya kadar çekmemiş olmalarından dolayı bazı suçlamalar olabilir. AFAIK Xen, sanal makineler için O_DIRECT'i kullanan tek hipervizör, çekirdeğin "loop" kullanıldığında olduğu gibi hala onu kullanarak önbellek olur. Virtualbox en azından böyle şeyleri devre dışı bırakmak için bazı ayarlara sahip ve Qemu / KVM genellikle önbelleklemeye izin veriyor gibi görünüyor. Tüm FUSE FS de orada sorun yaşıyor (O_DIRECT yok)

Ynt: Boyutlar LVM'nin görüntülenen boyutta "yuvarlama" yaptığını düşünüyorum. Veya GiB kullanır. Neyse, VG Pe boyutunu kullanmanız ve onu LV'nin LE numarası ile çarpmanız gerekir. Bu doğru net büyüklüğü vermelidir ve bu sorun her zaman bir kullanım sorunudur. Fsck / mount (merhaba, ext3) sırasında böyle bir şey fark etmeyen veya çevrimiçi çalışan bir "fsck -n" (merhaba, ext3) olmayan dosya sistemleri tarafından daha da kötüleştirilir.

Tabii ki böyle bir bilgi için iyi kaynaklar bulamayacağınızı söylüyor. "VRA için kaç tane LE var?" "PVRA, VGDA, ... vb. için fiziksel uzaklık nedir?"

Orijinaline kıyasla LVM2, "UNIX'i anlamayanlar, kötü bir şekilde yeniden icat etmeye mahkumdur" un ana örneğidir.

Birkaç ay sonra güncelleme: Şimdiye kadar bir test için "tam anlık görüntü" senaryosunu izliyorum. Doldurulursa, anlık görüntü engellenir, orijinal LV'yi değil. Bunu ilk gönderdiğimde yanılmışım. Bazı doktorlardan yanlış bilgi aldım ya da belki anladım. Kurulumlarımda her zaman onların dolmasına izin vermemek için çok paranoyak oldum ve bu yüzden hiçbir zaman düzelmedim. Ayrıca, bir tedavi olan anlık görüntüleri genişletmek / daraltmak da mümkündür.

Hala çözemediğim şey, enstantanenin yaşını nasıl tespit edeceğim. Performanslarına ilişkin olarak, enstantane tekniğinin gözden geçirildiğini belirten "thinp" fedora proje sayfasında, her enstantane ile daha yavaş olmayacaklarını belirten bir not var. Nasıl uyguladıklarını bilmiyorum.

yedekleri için anlık görüntüleri kullanmayı planlıyorsanız - anlık görüntü varken ana performans vuruşu için hazır olun. buradan daha fazla oku . Aksi takdirde hepsi iyi. Ben bunu kullanmak için asıl neden atomik anlık görüntü hacimleri kolayca genişletmek için yetenek olmamasına rağmen, birkaç yıldır üretimde lvm kullanıyorum.

1TB sürücü kullanacaksanız btw, bölüm hizalamasını unutmayın - bu sürücü büyük olasılıkla 4kB fiziksel sektörlere sahiptir.

Adam,

Başka bir avantaj: yeni bir fiziksel hacim (PV) ekleyebilir, tüm verileri bu PV'ye taşıyabilir ve ardından eski PV'yi herhangi bir servis kesintisi olmadan kaldırabilirsiniz. Bu yeteneği son beş yılda en az dört kez kullandım.

Henüz açıkça belirtmediğim bir dezavantaj: LVM2 için biraz dik bir öğrenme eğrisi var. Çoğunlukla, soyutlamada, dosyalarınız ve alttaki medya arasında yaratır. Bir dizi sunucuda işleri paylaşan sadece birkaç kişiyle çalışıyorsanız, ekibiniz için bir bütün olarak bunaltıcı olan ekstra karmaşıklığı bulabilirsiniz. BT çalışmasına adanmış daha büyük ekiplerin genellikle böyle bir sorunu olmaz.

Örneğin, burada işimde yaygın olarak kullanıyoruz ve tüm ekibe doğru bir şekilde önyükleme yapılmayan sistemlerin kurtarılmasıyla ilgili temelleri, dili ve temel şartları öğretmek için zaman harcadık.

Özellikle dikkat etmeniz gereken bir nokta: LVM2 mantıksal biriminden önyükleme yaparsanız, sunucu çöktüğünde kurtarma işlemlerini zorlaştırırsınız. Knoppix ve arkadaşlar her zaman bunun için doğru şeyler yoktur. Böylece, / boot dizinimizin kendi bölümünde olacağına ve her zaman küçük ve yerli olacağına karar verdik.

Genel olarak, LVM2 hayranıyım.