Soru LVM tehlikeleri ve uyarılar


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

LVM kullanmanın olumsuz yönleri nelerdir?


178
2018-06-12 07:34


Menşei


Bu soruya verilen cevapları okurken, gönderildikleri tarihi (yıl) unutmayın. Bu sektörde 3 yılda çok şey oluyor. - MattBianco
Son zamanlarda bir şey değişip değişmediğini görmek için taranan bazı güncellemeler yaptım (Nis 2015). 2.6 çekirdeği artık geçersizdir, SSD'ler daha yaygındır, ancak bazı küçük LVM düzeltmelerinin dışında pek bir şey değişmemiştir. LVM anlık görüntüleri yerine VM / bulut sunucusu anlık görüntülerini kullanarak yeni şeyler yazdım. Önbelleğe alma, dosya sistemi yeniden boyutlandırma ve LVM anlık görüntülerinin durumu, görebildiğim kadar çok değişmedi. - RichVel
"tarih aklında olanı" yorumuna ilişkin - yeterince doğru, ama aynı zamanda bir çok "girişimin" hala her ikisi de son teknoloji ürünü olan veya daha eski olan RHEL 5 ve RHEL 6'yı kullandığını düşünün. cevabın - JDS


Cevaplar:


özet

LVM kullanmanın riskleri:

  • SSD veya VM hiper yönetici ile önbelleğe alma sorunları yazmak için hassas
  • Daha karmaşık disk yapıları nedeniyle verileri kurtarmak daha zor
  • Dosya sistemlerini doğru şekilde yeniden boyutlandırmak
  • Anlık görüntüler kullanmak zor, yavaş ve buggy
  • Bu sorunları doğru bir şekilde yapılandırmak için biraz beceri gerektirir.

İlk iki LVM sorunu birleştirilir: eğer yazma önbelleği doğru çalışmıyorsa ve bir güç kaybınız varsa (örneğin, PSU veya UPS başarısız olursa), yedeklemeden kurtulmanız gerekebilir, bu da önemli bir kesinti anlamına gelir. LVM'yi kullanmanın temel nedeni daha yüksek çalışma süresidir (disk eklerken, dosya sistemlerini yeniden boyutlandırırken, vb.), Ancak LVM'nin çalışma süresini gerçekten düşürmesini önlemek için yazma önbellekleme ayarlarının doğru olması önemlidir.

- Eylül 2017'yi güncelledi: eski çekirdek malzemesini daha az öne çıkardı

Risklerin azaltılması

LVM hala işe yarayabilir:

  • Yazma önbellekleme kurulumunuzu hiper yönetici, çekirdek ve SSD'lerde doğru şekilde alın
  • LVM anlık görüntülerinden kaçının
  • Dosya sistemlerini yeniden boyutlandırmak için son LVM sürümlerini kullanın
  • İyi yedekler var

ayrıntılar

Geçmişte, LVM ile ilişkili bazı veri kayıplarının yaşandığı bir araştırma yaptım. Ana LVM riskleri ve farkında olduğum konular şunlardır:

VM hipervizörleri, disk önbellekleme veya eski Linux çekirdekleri nedeniyle sabit diske karşı yazma önbelleğe almave daha karmaşık disk yapıları nedeniyle verileri kurtarmayı zorlaştırır - ayrıntılar için aşağıya bakın. Birkaç diskte tam LVM kurulumlarının kurtarma şansı olmadan bozulduğunu gördüm ve LVM artı sabit disk yazma önbelleklemesi tehlikeli bir kombinasyon.

  • Sabit sürücüyle önbelleğe yazma ve yeniden sıralama yazma iyi performans için önemlidir, ancak sanal makine denetleyicileri, sabit sürücü yazma önbelleklemesi, eski Linux çekirdeği vb. nedeniyle blokları doğru bir şekilde diske atlayamaz.
    • Engelleri yaz kernel, "bariyer" disk yazmadan önce belirli disk yazımlarını tamamlayacağını, dosya sistemlerinin ve RAID'in ani bir güç kaybı veya çarpışma durumunda kurtarabileceğini garanti eder. Bu engeller FUA (Kuvvet Birimi Erişimi) işlemi Tam blok önbellekten daha verimli olan diske hemen belirli blokları yazmak için. Bariyerler verimli bir şekilde kombine edilebilir etiketlendi/yerli Sabit disk sürücüsünün, veri kaybı riskini arttırmadan akıllı yazma yeniden siparişi gerçekleştirmesini sağlamak için komut kuyruğu (birden çok disk G / Ç isteğini bir defada vererek).
  • VM hipervizörleri benzer sorunlara sahip olabilir: Bir Linux kullanıcısının VMware gibi bir VM hipervizörünün üstünde LVM çalıştırması, Xen, KVM, Hyper-V veya VirtualBox oluşturabilirsiniz benzer problemleryazma önbelleği içermeyen bir çekirdeğe, önbelleğe yazma ve yeniden yazma önbelleği nedeniyle. "Diske sığdır" veya yazma önbelleği seçeneği için hipervizör belgelerinizi dikkatli bir şekilde kontrol edin. KVM, VMware, Xen, VirtualBox ve diğerleri) - ve kurulumunuzla test edin. VirtualBox gibi bazı hiper yöneticiler var varsayılan ayar Bu, konuklardan herhangi bir disk temizliğini yok sayar.
  • LVM'ye sahip kurumsal sunucular her zaman bir pil destekli RAID denetleyici ve sabit diskin önbelleğe alınmasını engelleyin (denetleyicinin hızlı ve güvenli bir şekilde yedeklenmiş önbelleğe sahip olması gerekir) - bkz. bu yorum yazarı bu XFS SSS girişi. Ayrıca güvenli olabilir yazma engellerini kapat çekirdekte, ancak test önerilir.
  • Pil destekli bir RAID denetleyiciniz yoksa, sabit sürücüyü önbelleğe almayı devre dışı bırakmak yazmayı yavaşlatır ancak LVM'yi güvenli hale getirir. Ayrıca ext3'lerin eşdeğerini kullanmalısınız. data=ordered seçenek (veya data=journal ekstra güvenlik için) barrier=1 Çekirdek önbelleklemenin bütünlüğü etkilemediğinden emin olmak için. (Veya ext4 kullanın engelleri varsayılan olarak etkinleştirir.) Bu en basit seçenektir ve performans maliyetinde iyi veri bütünlüğü sağlar. (Linux varsayılan ext3 seçeneğini değiştirdi daha tehlikeli data=writeback Bir süre önce, FS için varsayılan ayarlara güvenmeyin.)
  • Sabit sürücüyü devre dışı bırakmak için yazma önbellekleme: eklemek hdparm -q -W0 /dev/sdX içindeki tüm sürücüler için /etc/rc.local (SATA için) veya SCSI / SAS için sdparm kullanın. Ancak, göre bu giriş XFS SSS'de (ki bu konu üzerinde çok başarılıdır), bir SATA sürücüsü bir sürücü hatası kurtarıldıktan sonra bu ayarı unutabilir - bu yüzden SCSI / SAS'ı kullanmalı veya SATA kullanmanız gerekiyorsa, hdparm komutunu bir cron işine koymalısınız. her dakika çalışıyor.
  • SSD / sabit sürücüyü tutmak için önbelleğe kaydetme etkin Daha iyi performans için: Bu karmaşık bir alan - aşağıdaki bölüme bakın.
  • Eğer kullanıyorsanız Gelişmiş Format sürücüleri 4 KB fiziksel sektörler, aşağıya bakınız - yazma önbelleğini devre dışı bırakmanın başka sorunları olabilir.
  • GÜÇ KAYNAĞI hem kurumsal hem de SOHO için kritiktir, ancak LVM'yi güvenli hale getirmek için yeterli değildir: sabit bir kilitlenme veya güç kaybına neden olan herhangi bir şey (örn. UPS arızası, PSU arızası veya dizüstü bilgisayarın pil tükenmesi) sabit sürücü önbelleklerinde veri kaybına neden olabilir.
  • Çok eski Linux çekirdekleri (2009'dan 2.6.x): Çok eski çekirdek sürümlerinde, 2.6.32 ve önceki sürümlerde eksik yazma bariyeri desteği var.2.6.31'in bazı desteği var, süre 2.6.33 çalışır her türlü cihaz hedefi için) - RHEL 6, 2.6.32 kullanıyor birçok yamalar ile. Bu sorunlar için bu eski 2.6 çekirdekler gönderilmezse, sabit disklerin yazma arabelleklerinde (ortak SATA sürücüler için sürücü başına 32 MB) veri biriktiren bir sabit çökme nedeniyle büyük miktarda FS meta verileri (dergiler dahil) kaybolabilir. Çekirdeğin diskte olduğunu düşündüğü en son yazılı FS metaveri ve günlük verilerinin 32MB'sini kaybetmek, genellikle çok fazla FS bozulması ve dolayısıyla veri kaybı demektir.
  • Özet: LVM ile kullanılan dosya sisteminde, RAID, VM hipervizöründe ve sabit sürücü / SSD kurulumunda dikkatli olmalısınız. LVM kullanıyorsanız çok iyi yedeklemelere sahip olmanız ve özellikle LVM meta verilerini, fiziksel bölüm kurulumunu, MBR ve birim önyükleme sektörlerini yedeklediğinizden emin olmalısınız. Ayrıca SCSI / SAS sürücülerini kullanmanın da önbellekleme yazma konusunda daha az yatkın olduğu için kullanılması önerilir - SATA sürücülerini kullanmak için daha fazla bakım gerekir.

Yazma önbellekleme etkin tutmak performans için (ve yalan disklerle başa çıkmak)

SSD / hard disk yazma önbelleğe almayı etkinleştirmek ve çekirdek 2.6.33+ üzerinde LVM ile çalışan kernel yazma bariyerlerine güvenmek daha karmaşık fakat performanslı bir seçenektir (günlüklerde "bariyer" mesajlarını arayarak iki kez kontrol edin).

Ayrıca RAID kurulumunun, VM hiper yönetici kurulumunun ve dosya sisteminin de yazma engellerini kullanır (yani, anahtar metadata / dergi yazmadan önce ve sonra bekleyen yazma işlemlerini temizlemesini gerektirir). XFS varsayılan olarak engelleri kullanır, ancak ext3 değilYani ext3 ile kullanmalısınız barrier=1 mount seçeneklerinde ve hala kullanmak data=ordered veya data=journal yukarıdaki gibi.

SSD'ler sorunludur çünkü yazma önbelleğinin kullanımı SSD'nin ömrü boyunca kritiktir. Bir süperkapasitöre sahip bir SSD kullanmak en iyisidir (güç kesintisinde önbelleği temizlemeyi etkinleştirmek ve böylece önbelleğin yazma-yazma işleminin geri yazılmasını sağlamak).

Gelişmiş Biçim sürücü kurulumu - önbelleğe yazma, hizalama, RAID, GPT yaz

  • Daha yeni Gelişmiş Format sürücüleri 4 KiB fiziksel sektörünü kullanan bu sürücülerin çoğu, 512 bayt mantıksal sektörleri taklit ettiğinden, sürücünün yazma önbelleğe alma özelliğini etkin tutması önemli olabilir ("512 emülasyonu"), hatta bazıları 4 KiB kullanırken 512 baytlık fiziksel sektörlere sahip olduğunu iddia ediyor.
  • Bir Advanced Format sürücüsünün yazma önbelleğinin kapatılması, 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 yapmadan önce 8 x 512 baytlık yazımlar biriktirmek için önbelleğe güvenir yazmak. Önbelleği devre dışı bırakırsanız, herhangi bir etkiyi onaylamak için sınamanız önerilir.
  • LV'leri 4 KiB sınırında hizalama Performans için önemlidir, ancak PV'lerin altta kalan bölümleri hizalandığı sürece otomatik olarak gerçekleşmelidir, çünkü LVM Fiziksel Genişler (PE) varsayılan olarak 4 MiB'dir. RAID burada düşünülmelidir - bu LVM ve yazılım RAID kurulum sayfası RAID süper bloğunu ses seviyesinin sonuna koymanızı ve (gerekirse) bir seçeneği kullanarak pvcreate PV'leri hizalamak için. Bu LVM e-posta listesi dizisi 2011 yılında çekirdeklerde yapılan çalışmalara işaret etmekte ve 512 bayt ve 4 KiB sektörleri ile tek bir AG'de disk karıştırırken kısmi blok yazmaktadır.
  • Gelişmiş Biçimle GPT bölümleme İlk LVM bölümünün (PV) 4 KiB sınırında başladığından emin olmak için özellikle önyükleme + kök diskleri için bakım gerekir.

Daha karmaşık disk yapıları nedeniyle verileri kurtarmak daha zor:

  • Sabit bir çarpışma veya güç kaybından sonra (yanlış yazma önbelleği nedeniyle) gerekli olan LVM verilerinin geri kazanımı, en iyi ihtimalle manuel bir işlemdir, çünkü uygun hiçbir araç yoktur. LVM, meta verilerini yedeklemede iyidir /etc/lvmLV'lerin, VG'lerin ve PV'lerin temel yapısını geri kazanmaya yardımcı olabilir, ancak kayıp dosya sistemi meta verilerine yardımcı olmayacaktır.
  • Bu nedenle, yedeklemeden tam olarak geri yükleme yapılması gerekebilir. Bu, LVM kullanılmadığında hızlı bir dergi tabanlı fsck'den çok daha fazla kesinti süresine neden olur ve son yedeklemeden bu yana yazılan veriler kaybolacaktır.
  • TestDisk, ext3grep, ext3undel ve diğer Aletler  LVM olmayan disklerden bölümleri ve dosyaları kurtarabilir, ancak LVM veri kurtarma işlemini doğrudan desteklemez. TestDisk, kayıp bir fiziksel bölümün bir LVM PV içerdiğini keşfedebilir, ancak bu araçların hiçbiri LVM mantıksal birimlerini anlamaz. Dosya oyma gibi araçlar PhotoRec ve diğerleri, dosya sistemini veri bloklarından yeniden birleştirmek için dosya sistemini baypas ettikleri için çalışacaklardı, ancak bu, değerli veriler için son çare, düşük seviyeli bir yaklaşım ve parçalanmış dosyalarla daha az iyi çalışıyor.
  • Bazı durumlarda manuel LVM kurtarma mümkündür, ancak karmaşık ve zaman alıcıdır - bkz. bu örnek ve bu, bu, ve bu nasıl kurtarılacağı.

Dosya sistemlerini doğru şekilde yeniden boyutlandırmak - Kolay dosya sistemi yeniden boyutlandırma genellikle LVM'nin bir avantajı olarak verilir, ancak bir LVM tabanlı FS'yi yeniden boyutlandırmak için yarım düzine kabuk komutunu çalıştırmanız gerekir - bu, tüm sunucuyla hala çalışır durumda olabilir ve bazı durumlarda FS'ye takılıyken, Ancak, ikincisini hiçbir zaman güncel yedeklemeler olmadan ve eşdeğer bir sunucu üzerinde önceden test edilmiş komutları (örn. üretim sunucusunun felaket kurtarma klonu) kullanmadan riske atmam.

  • Güncelleştirme: Daha yeni sürümleri lvextend destek -r (--resizefs) seçenek - eğer mevcutsa, özellikle FS'yi küçültürseniz, LV'yi ve dosya sistemini yeniden boyutlandırmak için daha güvenli ve daha hızlı bir yoldur ve çoğunlukla bu bölümü atlayabilirsiniz.
  • LVM tabanlı FS'leri yeniden boyutlandırma kılavuzlarının çoğu, FS'nin AG'nin boyutundan biraz daha küçük olması gerektiğini dikkate almaz: detaylı açıklama burada. Bir dosya sistemini daraltırken, yeni boyutu FS yeniden boyutlandırma aracına, örn. resize2fs ext3 için ve lvextend veya lvreduce. Büyük bir özen göstermeden, boyutlar 1 GB (10 ^ 9) ve 1 arasındaki fark nedeniyle biraz farklı olabilir. GiB (2 ^ 30) veya çeşitli araçların yukarı veya aşağı doğru yuvarlanma şekli.
  • Hesaplamaları tam olarak doğru yapmazsanız (veya en belirgin olanların ötesinde bazı ekstra adımlar kullanın), LV için çok büyük bir FS ile sonuçlanabilir. FS'yi tamamen dolduruncaya kadar, her şey ciddi bir yolsuzluğa kapılıncaya kadar aylar ya da yıllar boyunca her şey iyi görünecektir - ve bu sorunun farkında olmadıkça, bunun nedenini bulmak zor çünkü o zamana kadar gerçek disk hataları olabilir. Bu durumu bulut. (Bu sorunun sadece dosya sistemlerinin boyutunu küçültmesi olasıdır. Ancak, dosya sistemlerini her iki yönde yeniden boyutlandırmanın, muhtemelen kullanıcı hatası nedeniyle veri kaybı riskini artırdığı açıktır.)
  • Görünen o ki, LV boyutu FS boyutundan daha büyük olmalıdır, LVM fiziksel kapsamı (PE) büyüklüğü - ancak bunun kaynağı için kaynak olduğundan emin olmak için yukarıdaki bağlantıyı kontrol edin. Çoğunlukla 8 MiB'ye izin vermek yeterlidir, ancak daha fazla izin vermek daha iyi olabilir, örn. Sadece güvende olmak için 100 MiB veya 1 GiB. PE boyutunu ve mantıksal hacminizi + FS boyutlarını kontrol etmek için 4 KiB = 4096 bayt bloğu kullanın:

    KiB'de PE boyutunu gösterir:
    vgdisplay --units k myVGname | grep "PE Size"

    Tüm LV'lerin büyüklüğü:
    lvs --units 4096b

    FS (ext3) boyutu, 4 KiB FS blok boyutunu varsayar:
    tune2fs -l /dev/myVGname/myLVname | grep 'Block count'

  • Buna karşılık, LVM olmayan bir kurulum FS'yi yeniden boyutlandırmayı çok güvenilir ve kolay çalıştırır Gparted ve gerekli FS'leri yeniden boyutlandırın, sonra sizin için her şeyi yapar. Sunucularda, kullanabilirsiniz parted kabuktan.

    • Kullanmak genellikle en iyisidir Gparted Canlı CD veya Ayrılmış SihirBunlar, yeni ve genellikle daha fazla hatasız Gparted & kernel distro sürümüne sahip olduğu için - bir zamanlar FS'nin dağıtım bölümündeki düzgün çalışmayan bölümleri güncellememesi nedeniyle bir bütün FS'yi kaybettim. Dağıtımcı Gparted kullanılıyorsa, bölümleri değiştirdikten sonra kernel'in görünümü doğru olduğundan yeniden başlattığınızdan emin olun.

Anlık görüntüler kullanmak zor, yavaş ve buggy- anlık görüntü önceden ayrılmış alandan çıktıysa otomatik olarak düştü. Belli bir LV'nin her bir anlık görüntüsü, önemli bir yazma aktivitesine sahip dosya sistemlerini çekerken çok alan gerektirebilecek LV'ye (önceki anlık görüntülere karşı değil) karşı bir deltadır. Anlık görüntü hiçbir zaman boş alandan çıkmayacağından, orijinal LV ile aynı boyutta bir anlık görüntü (LV) oluşturmak güvenlidir.

Anlık görüntüler de çok yavaş olabilir (bu da LVM'den 3 ila 6 kat daha yavaş anlamına gelir) bu MySQL testleri) - görmek bu cevap çeşitli anlık görüntü sorunlarını kapsar. Yavaşlık kısmen çünkü anlık görüntüler birçok senkronize yazmayı gerektirir.

Anlık görüntülerin bazı önemli hataları vardır, ör. bazı durumlarda çok yavaş önyükleme yapabilirler veya önyüklemenin tamamen başarısız olmasına neden olabilirler. çekirdek zaman aşımına uğratabilir  LVM anlık görüntüsünde kök FS'yi beklemek [Debian'da sabit initramfs-tools güncelleme, Mar 2015]).

  • Bir metrik, birçok Debian hatası var "lvm snapshot 2015" ile eşleşenBazıları oldukça ciddi - ancak, birçok enstantane yarış durumu hataları görünüşe göre tamir edildi. Anlık görüntülere sahip olmayan LVM, genellikle çekimlerin ana özellikler kadar kullanılmadığı için genelde çok iyi ayıklanmış gibi görünüyor.

Anlık görüntü alternatifleri - dosya sistemleri ve sanal makine denetleyicileri

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

  • Bir VM hiper yönetici veya bir IaaS bulut sağlayıcısı kullanıyorsanız, bunların anlık görüntüleri (ör. VMware, VirtualBox veya Amazon EC2'nin EBS anlık görüntüleri) genellikle LVM anlık görüntülerine çok daha iyi bir alternatiftir. Yedekleme amacıyla anlık olarak kolayca fotoğraf çekebilirsiniz (ancak bunu yapmadan önce FS'yi dondurmayı düşünebilirsiniz).

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

  • ZFS veya btrfs ile dosya sistemi düzeyindeki anlık görüntülerin kullanımı kolaydır ve genellikle LVM'den daha iyidir ve her iki dosya sistemi Linux'ta çok olgun olmasa da, VM / bulut rotasına gitmeden anlık görüntülere ihtiyaç duyan kişiler için daha iyi bir seçenek olabilir:

    • ZFS: şimdi bir var çekirdek ZFS uygulamasıBazı yıllarda kullanımda olan ve FUSE'den ZFS'den çok daha hızlı olması gerekiyor.
    • btrfs, üretim kullanımı için oldukça hazır değil ve fsck ve tamir araçları hala geliştirme aşamasındadır.

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

Anlık görüntüler tutarlı bir şekilde sağlamak için kullanılabilir kaynak Yedekleme için, ayrılmış alana dikkat ettiğiniz sürece (ideal olarak, yedek kopya, yedeklenecek olanla aynı boyuttadır). Mükemmel rsnapshot (1.3.1'den beri) sizin için LVM anlık görüntü oluşturma / silme işlemini bile yönetir - bunu gör LVM kullanarak rsnapshot üzerinde NASIL. Ancak, anlık görüntülerle ilgili genel sorunlara ve bir anlık görüntünün kendi başına bir yedek olarak görülmemesine dikkat edin.

LVM anlık görüntülerini çevrimiçi fsck yapmak için de kullanabilirsiniz: Anlık görüntü çekimi FS'yi kullanırken, anlık görüntüyü yakalama ve anlık görüntüyü kapatma burada tarif - Ancak, bu tamamen basit değil bu yüzden kullanmak en iyisi e2croncheck gibi Ted Ts'o tarafından tarif edilen, ext3'ün bakıcısı.

Malısın dosya sistemini "dondur" anlık görüntü çekerken geçici olarak - ext3 ve XFS gibi bazı dosya sistemleri bunu otomatik olarak yap LVM anlık görüntüyü oluşturduğunda.

Sonuçlar

Tüm bunlara rağmen, bazı sistemlerde LVM kullanıyorum, ancak bir masaüstü kurulumu için ham bölümleri tercih ediyorum. LVM'den görebildiğim temel fayda, FS'lerin taşınması ve yeniden boyutlandırılması esnekliğidir. Bir sunucuda yüksek çalışma zamanınız olması gerektiğinde - Buna ihtiyacınız yoksa, gparted daha kolay ve daha az veri kaybı riski vardır.

LVM, sanal makine denetleyicileri, sabit sürücü / SSD yazma önbelleği vb. Nedeniyle yazma önbelleğe alma kurulumuna büyük özen gösterilmesini gerektirir, ancak aynısı Linux'u bir DB sunucusu olarak kullanmak için de geçerlidir. Çoğu araçtan destek eksikliği (gparted kritik boyut hesaplamaları dahil, ve testdisk vb) kullanılması gerekenden daha zor hale getirir.

LVM kullanıyorsanız, anlık görüntülerle çok dikkatli olun: Mümkün olduğunda VM / bulut anlık görüntülerini kullanın veya LVM'yi tamamen önlemek için ZFS / btrfleri araştırın. ZFS veya btr'lerin anlık görüntülerle birlikte LVM'ye göre yeterince olgun olduğunu görebilirsiniz.

Alt satır: Yukarıda listelenen sorunları ve bunları nasıl ele alacağınızı bilmiyorsanız LVM'yi kullanmamanız en iyisidir.


239
2018-06-12 08:19



Xfs ile çevrimiçi yeniden boyutlandırma mükemmel çalışır, hatta boyutunu belirtmeniz gerekmez. Xfs_grow (5) 'deki LV boyutuna büyüyecektir. OTOH Yazma engelleri hakkındaki özet için +1'e basarım. - cstamas
KANKA! Tüm hayatım boyunca neredeydin!? - songei2f
@TREE: pil destekli bir RAID denetleyicisi ile olan önbellek, önbelleğinin güç kesintilerinde kalıcı olduğunu ve genellikle belgelendirilmiş olarak çalışacak şekilde güvenilebilmesini sağlarken, bazı sabit disk önbelleklerinin gerçekten diske bir blok yazıp yazmadıklarını ve Tabii bu önbellekler kalıcı değil. Sabit disk önbelleğini etkin bırakırsanız, RAID denetleyicisinin pil yedeği ile korunan ani bir elektrik kesintisine (örneğin PSU veya UPS arızası) karşı korunursunuz. - RichVel
Gördüğüm en iyi cevaplardan biri, herhangi bir konu. Sadece bir değişiklik yapardım, özeti dikkat eksikliği bozukluğu olan ya da çok fazla olmayanlar için sorunun TOPLAMINA hareket ettirir. :-) - Prof. Falken
Tüm yorumları ve cevabın son güncellemesini görmek bir yıl önceydi, cevabın güvenilirlik, performans ve kullanım kolaylığındaki yeni değişiklikleri yansıtacak şekilde güncellenip güncellenemeyeceğini merak ediyordum. - Luis Alvarado


Bu gönderiyi [+1] ve en azından benim için çoğu problemin var olduğunu düşünüyorum. Birkaç 100 sunucu ve birkaç 100 TB veri çalışırken bunları gördüm. Bana göre Linux'taki LVM2, birinin sahip olduğu "akıllı fikir" gibi geliyor. Bunlardan bazıları gibi, bazen "zeki" olmadıkları ortaya çıkıyor. Yani tamamen ayrılmış çekirdek ve userspace (lvmtab) durumlarının olmaması akıllıca davranmak için gerçekten akıllı olmuş olabilir, çünkü yolsuzluk sorunları olabilir (eğer kodu doğru bilmiyorsanız)

Eh, sadece bu ayrılık oradaydı bir neden için - farklılıklar, PV kayıp işleme ve bir VG'nin, yani tekrar oynatmalarını sağlamak için bir PV'nin çevrimiçi yeniden aktivasyonu ile gösterilir. - "Orijinal LVM'ler" (AIX, HP-UX) üzerindeki bir esinti, LVM2'ye ne zaman dayanır? devlet yönetimi yeterince iyi değil. Ve hatta, Çekirdek kaybı algılama (haha) veya durum yönetimi (disk çıkarırsam, kullanılamaz olarak işaretlenmez) hakkında konuşmama bile gerek yok. var lanet durum sütunu)

Re: istikrar pvmove... neden ki

pvmove veri kaybı

Blogumda böyle bir üst düzey makale, hmmm? Sadece şimdi phyiscal lvm verilerinin hala pvmove'den devlete asıldığı bir diske bakıyorum. Ben düşünüyorum bazı memleaks vardı ve genel bir fikir kullanıcı bloğundan canlı blok veri etrafında kopyalamak için iyi bir şey sadece üzücü. Lvm listesinden güzel alıntılar "vvreduce gibi görünüyor - tatlım pvmove işlemez" Aslında bir disk pvmove sırasında ayrılırsa, lvm yönetim aracı lvm'den vi'ya değişir. Ah ve ayrıca pvmove'un bir blok okuma / yazma hatasından sonra devam ettiği ve aslında artık hedef cihaza veri yazamadığı bir hata oldu. O NE LAN?

Re: Anlık Görüntüler CoW, yeni verileri anlık görüntü lv alanına güncelleyerek ve ardından eki sildikten sonra tekrar birleştirerek, yanlış bir şekilde yapılır. Bu, yeni verilerin orijinal LV'ye son birleştirme sırasında ağır IO sivrileriniz olduğu ve daha da önemlisi, elbette veri bozulma riskinin de daha yüksek olduğu anlamına gelir, çünkü vurduğunuz andan itibaren anlık görüntü kırılmaz. duvar, ama orijinal.

Avantajı, performans yerine 3 yerine 1 yazıyor. Hızlı ama anlaşılmamış algoritmanın seçilmesi, VMware ve MS gibi insanların beklenmedik bir şekilde "Unix" üzerinde beklediği şeylerin "doğru yapıldığını" tahmin etmekteyim. Anlık görüntü desteğine sahip olduğum sürece fazla performans sorunu görmedim. farklı Birincil veriden daha fazla disk sürücüsü (ve tabii ki başka bir tanesine yedekleme)

Re: Bariyerler Birinin bunu LVM'de suçlayabileceğinden emin değilim. Bildiğim kadarıyla bir devmapper sorunu oldu. Ancak, bu konu hakkında en azından çekirdek 2.6'dan 2.6.33'e kadar gerçekten ilgilenmediğim için bazı suçlamalar olabilir. AFAIK Xen, sanal makineler için O_DIRECT kullanan tek hipervizördür; çekirdek, "çekirdek" kullanıldığında kullanılan problemdir, çünkü çekirdek bunu kullanarak hala önbelleğe sahip olacaktır. Virtualbox en azından böyle bir şeyi devre dışı bırakmak için bazı ayarlara sahiptir ve Qemu / KVM genellikle önbelleğe almayı sağlar. Tüm FUSE FS de orada sorun yaşıyor (O_DIRECT yok)

Re: Bedenler LVM'nin görüntülenen büyüklükte "yuvarlama" yaptığını düşünüyorum. Ya da GiB kullanır. Her neyse, VG Pe boyutunu kullanmanız ve LV'nin LE numarasıyla çarpmanız gerekir. Doğru net boyutu vermeli ve bu sorun her zaman bir kullanım sorunudur. Bu, 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 bulamadığını söylüyor. "VRA için kaç LE?" "PVRA, VGDA, ... vs için phyiscal ofset nedir"

Orijinal bir LVM2'ye kıyasla "UNIX'i anlamayanlar onu yeniden icat etmeye mahkumdurlar" ın en önemli örneği.

Birkaç ay sonra güncelleştirin: Şu ana kadar bir test için "tam anlık görüntü" senaryosuna isabet ediyorum. Tamamlanırsa, anlık görüntü blokları, orijinal LV değil. Bunu ilk gönderdiğimde yanılmışım. Bazı doktorlardan yanlış bilgi aldım ya da belki anladım. Benim düzenlerimde her zaman doldurulamayacak kadar paranoyak olurdum ve bu yüzden asla düzeltilmedim. Aynı zamanda bir enstantane olan enstantaneleri genişletmek / daraltmak da mümkündür.

Hala çözemediğim şey, anlık görüntülerin yaşını nasıl belirleyeceğimiz. Performanslarına göre, anlık görüntü tekniğinin revize edildiğini söyleyen "thinp" fedora proje sayfasında, her bir anlık görüntüde daha yavaş olmayacakları bir not bulunmaktadır. Bunu nasıl uyguladıklarını bilmiyorum.


15
2017-12-11 14:03



İyi puanlar, özellikle pvmove veri kaybında (bunun düşük hafızanın altına düştüğünün farkında olmadı) ve enstantane tasarımında. Yazma bariyerleri / önbellekleme üzerine: LVM ve çekirdek cihaz eşleştiricisini, kullanıcı bakış açısıyla LVM'nin ne sunduğunu sunmak için birlikte çalıştıklarından bir araya getiriyordum. Upvoted. Ayrıca pvmove veri kaybına ilişkin blog yayınınızı beğendi: deranfangvomende.wordpress.com/2009/12/28/... - RichVel
Anlık görüntülerde: LVM'de çok yavaşlar, bu nedenle güvenilirlik için performansa gitmek için iyi bir tasarım kararı değildi. "Duvara çarptı" ile, fotoğrafın dolduruyor mu demek istediniz, ve bu gerçekten orijinal LV verilerinin bozulmasına neden olabilir mi? LVM NASIL belgesi, bu durumda enstantanın düştüğünü söylüyor: tldp.org/HOWTO/LVM-HOWTO/snapshots_backup.html - RichVel
"CoW, yeni verileri anlık görüntü lv alanına güncelleyerek ve ardından eki sildikten sonra tekrar birleştirerek yapılır." Bu sadece yanlıştır. Orijinal cihaza yeni veriler yazıldığında, eski sürüm, anlık görüntülerin COW alanına yazılır. Hiçbir veri geri birleştirilmez (isterseniz hariç). Görmek kernel.org/doc/Documentation/device-mapper/snapshot.txt tüm gory teknik detaylar için. - Damien Tournoud
Selam Damien, bir dahaki sefere mesajımı düzelttiğim noktaya kadar okudum mu? - Florian Heigl


Yedeklemeler için anlık görüntüleri kullanmayı planlıyorsanız - anlık görüntü mevcut olduğunda büyük performans isabeti için hazırlanın. daha fazla oku İşte. aksi halde hepsi iyi. Kullanmak için temel nedeni, atomik anlık görüntü kolayca hacimleri genişletmek için yeteneğidir, ancak onlarca sunucu üzerinde birkaç yıl boyunca lvm kullanıyorum.

Eğer 1TB sürücü kullanacaksanız btw, bölüm hizalamayı hatırlayın - bu sürücü büyük olasılıkla 4kB fiziksel sektörlere sahiptir.


12
2018-06-12 09:44



Açık anlık görüntüler için performans uyarısı +1. - Prof. Falken
Benim deneyimim, 1TB sürücülerinin genellikle 512 baytlık sektörler kullanmasıdır, ancak çoğu 2TB sürücüler 4Kb kullanır. - Dan Pritts
@DanPritts, sektör büyüklüğünün 4kB veya hatta 128kB olduğunu farz etmenin zararı yoktur - sadece aralarında bir baskının olması durumunda. çok az kaybedersiniz - belki 128kB ve çok kazanabilirsiniz. ayrıca eski diskten yeni bir görüntüye görüntüleme yaparken. - pQd
Dosya sistemi blok boyutu "çok büyük" yapmak için küçük bir zarar vardır; her dosya, tek bir bloktan daha azında yer alır. Çok sayıda küçük dosya ve 128 KB bloğunuz varsa ekleyeceksiniz. 4K'nın oldukça makul olduğunu ve bir dosya sistemini yeni bir donanıma taşıdığınızda, sonunda 4k sektörleri ile sonuçlanacaksınız. - Dan Pritts
(bir önceki yorumumu düzenlememe izin vermeyeceğim) ... Bir alan kaybı önemli olmayabilir, ancak sonuç olarak eğirme disklerindeki ortalama arama süreniz artacaktır. SSD'ler üzerinde muhtemelen yazma amplifikasyonuna (null ile sektörün doldurulması) dönüşebilir. - Dan Pritts


Adam,

Bir başka avantaj: Yeni bir fiziksel birim (PV) ekleyebilir, tüm verileri o PV'ye taşıyabilir ve daha sonra servis kesintileri olmadan eski PV'yi çıkarabilirsiniz. Bu yeteneği son beş yılda en az dört kez kullandım.

Henüz anlamadığım bir dezavantaj: LVM2 için biraz dik bir öğrenme eğrisi var. Çoğunlukla soyutlamada, dosyalarınız ve altta yatan ortamlar arasında oluşturur. Bir dizi sunucuda işleri paylaşan sadece birkaç kişiyle çalışıyorsanız, ekibiniz için bir bütün olarak aşırı karmaşıklık yaratabilirsiniz. BT çalışmasına adanmış daha büyük ekipler genellikle böyle bir problem yaşamazlar.

Örneğin, işte burada yaygın olarak kullanıyoruz ve tüm takımı temelden, dilden ve doğru önyükleme yapmayan sistemlerin kurtarılmasına ilişkin temel unsurları öğretmek için zaman ayırdık.

Özellikle dikkat çekmek için bir uyarı: Eğer bir LVM2 mantıksal biriminden önyükleme yapıyorsanız, sunucu çöktüğünde kurtarma işlemlerini zor hale getirdiniz. Knoppix ve arkadaşların bunun için her zaman doğru şeyleri yoktur. Bu yüzden, / boot dizinimizin kendi bölümünün üzerinde olacağına karar verdik ve her zaman küçük ve yerli olacaktık.

Genel olarak, ben LVM2 hayranıyım.


5
2018-06-22 21:03



koruma /boot Ayrı her zaman iyi bir fikirdir - Hubert Kario
GRUB2, LVM mantıksal biriminden önyüklemeyi destekliyor (bkz. wiki.archlinux.org/index.php/GRUB2#LVM) ama GRUB1 yok. Her zaman kurtarmanın kolay olmasını sağlamak için ayrı bir LVM / boot kullanmam. Çoğu kurtarma diski bu günlerde LVM'yi destekliyor - bazılarının manuel olması gerekiyor vgchange -ayLVM birimleri bulmak için. - RichVel
pvmove'de: Florian Heigl'in cevabında yapılan pvmove veri kaybı hakkındaki noktaya bakınız. - RichVel