VMware'de Linux - neden bölümleme kullanıyorsunuz?

Linux VM'lerini sanallaştırılmış bir ortama monte ederken (benim durumumda ESXi), her montaj noktası için ayrı diskler eklemek yerine diskleri bölümlendirmenin (ext4 kullanırken) zorlayıcı nedenleri var mı?

Görebildiğim tek şey, örneğin fdisk ile diskte veri olup olmadığını görmeyi biraz daha kolaylaştırması.

Öte yandan, ben bazı iyi nedenleri görebilirsiniz değil (tabii ki, / boot olandan başka) bölümleri kullanarak.

• Diskleri genişletmek çok daha kolay. Yalnızca VM için disk boyutunu artırmak (genellikle VCenter'da), ardından cihazı VM'de yeniden taramak ve dosya sistemini çevrimiçi olarak yeniden boyutlandırmaktır.
• Artık bölümleri alttaki LUN'larla aynı hizaya getirme konusunda sorun yok.

Bu konuda fazla bir şey bulamadım. Önemli bir şeyi mi kaçırdım?

Bu ilginç bir soru ...

Kesin bir cevap olduğunu sanmıyorum, ancak bu konuyu çevreleyen en iyi uygulamaların zaman içinde nasıl değişmiş olabileceği konusunda tarihsel bir bağlam verebilirim.

2007'den beri VMware ortamlarında çeşitli formlarda konuşlandırılmış binlerce Linux VM'sini desteklemek zorunda kaldım. Dağıtım yaklaşımım gelişti ve diğer mühendisler tarafından oluşturulan sistemleri devralma ve yeniden yapılandırma konusunda benzersiz ( bazen talihsiz ) bir deneyimim oldu.

Eski günler...

O güne (2007) erken VMware sistemlerim tıpkı çıplak metal sistemlerim gibi bölümlendi. VMware tarafında, VM'nin verilerini oluşturmak için 2GB kalınlıkta dosyalar kullanıyordum ve birden fazla VMDK kavramı hakkında bile düşünmedim, çünkü sanallaştırmanın işe yarayabileceği için mutluydum!

Sanal Altyapı ...

ESX 3.5 ve ilk ESX / ESXi 4.x sürümlerinde (2009-2011), monolitik Thick tarafından sağlanan VMDK dosyaları üzerinde normal olarak bölümlenmiş Linux kullanıyordum . Depolamayı önceden tahsis etmek zorunda kalmam, Linux tasarımı hakkında gerçek donanımda yaptığım gibi düşünmeye zorladı. İşletim sistemi için 36GB, 72GB, 146GB'lık VMDK'lar yaratıyordum, olağan /, / boot, / usr, / var, / tmp bölümlerini ayırdım, sonra "veri" veya "büyüme" bölümü için başka bir VMDK ekledim (bu / / home, / opt veya uygulamaya özel bir şey). Yine, bu dönemde fiziksel sabit disk boyutlarındaki tatlı nokta 146 GB'dı ve ön tahsisat bir gereksinim olduğundan (NFS kullanılmadığı sürece), boşlukla muhafazakar olmam gerekiyordu.

İnce tedarikin ortaya çıkışı

VMware daha sonra ESXi 4.x sürümlerinde İnce kaynak sağlama konusunda daha iyi özellikler geliştirdi ve bu da yeni sistemler kurmaya başladığımda değişti. Tüm özellik seti 5.0 / 5.1'e eklendiğinde, yeni bir esneklik türü daha yaratıcı tasarımlara izin verdi. Unutmayın, bu sanal makinelerde daha fazla vCPUS'a ve bireysel VM'lere ne kadar RAM yüklenebileceği konusunda artan yeteneklere ayak uyduruyordu. Geçmişten daha fazla türde sunucu ve uygulama sanallaştırılabilir. Bilgisayar ortamları tamamen sanallaşmaya başladığı için bu doğru.

LVM korkunç ...

Sanal makine seviyesindeki tam hot-add işlevselliği yerinde ve yaygın olduğunda (2011-2012), müşterilerinin sanal makine servislerinin çalışma süresini ne pahasına olursa olsun ( aptal ) sürdürmeye çalışan bir firma ile çalışıyordum . Bu, çevrimiçi VMware CPU / RAM artışlarını ve mevcut VMDK'lerde yeniden boyutlandırılmasının riskli LVM disklerini içeriyordu. Bu ortamdaki çoğu Linux sistemi, LVM'nin üstünde ext3 bölümleriyle tek VMDK kurulumlarıydı. Bu korkunçtu çünkü LVM katmanı karmaşıklık ve operasyonlara gereksiz risk kattı . Örneğin / usr'da alanın tükenmesi, sonunda bir sistemi yedeklerden geri yüklemek anlamına gelen kötü kararlar zincirine yol açabilir ... Bu, kısmen süreç ve kültürle ilgiliydi ama yine de ...

Bölüm züppeği ...

Bunu değiştirmeye çalışmak için bu fırsatı kullandım . Linux’ta bir bölümleme topluluğunun parçasıyım ve izleme ve operasyonel ihtiyaçlar için dosya sistemlerinin ayrılması gerektiğini hissediyorum. Ayrıca LVM'den, özellikle VMware'den ve ne sorduğunuzu yapma yeteneğinden de hoşlanmıyorum. Böylece, VMDK dosyalarının potansiyel olarak büyüyebilecek bölümlere eklenmesini genişlettim. / opt, / var, / home gerektiğinde kendi sanal makine dosyalarını alabilir. Ve bunlar çiğ diskler olurdu. Bazen bu, belirli cılız bölümleri anında genişletmek için daha kolay bir yöntemdi.

Obamacare ...

Çok yüksek profilli bir müşterinin hizmete girmesiyle, son derece görünür uygulama ortamlarını oluşturmak için kullanılacak Linux VM referans şablonunun tasarımı ile görevlendirildim . Uygulamanın güvenlik gereksinimleri, benzersiz bir montaj seti gerektiriyordu ; bu nedenle, geliştirici olmayan bölümleri tek bir VMDK üzerine sıkıştırmayı denemek için geliştiricilerle birlikte çalıştı ve daha sonra büyüme potansiyeli olan ya da belirli gereksinimleri olan her bir montaj için ayrı VMDK'lar ekledi (şifreleme, denetim, vb.) Sonuç olarak, bu VM'ler 5 veya daha fazla VMDK'den oluşuyordu, ancak gelecekteki yeniden boyutlandırma ve verilerin korunması için en iyi esnekliği sağladı.

Bugün ne yapıyorum?

Bugün Linux ve geleneksel dosya sistemleri için olan genel tasarımım, ince bir VMDK (bölümlenmiş) işletim sistemi ve başka bir şey için ayrık VMDK'lar. Gerektiği kadar sıcak eklerim. ZFS gibi gelişmiş dosya sistemleri için, işletim sistemi için bir VMDK ve bir ZFS zpool'u olarak hizmet veren ve yeniden boyutlandırılabilen, ilave ZFS dosya sistemlerine oyulmuş bir başka VMDK'dır.

Birçok yönden haklısın, tartışmayı görebiliyorum - zor olsa da kanıtlayabilecek bir konu var. Kaynak Havuzları kullanıyorsanız (ve bilmiyorum, nefret dolu şeyleri biliyorum), o zaman daha fazla diske sahiplerse VM'ler daha fazla GÇ zamanı alabilir - aşırı kaynak kısıtlı durumlarda, iki diskli bir VM ile iki kat daha fazla GÇ kaynağı alabilir. tek bir disk. Bu sizin için bir sorun olmayabilir, ama işaret edeceğimi düşündüm.

Düzenleme - oh ve o da biraz yavaş yapışmasını sağlayacaktır, ancak yine bir sorun olmayabilir.

Altyapıda belirli bir "büyük sanallaştırma yazılımı şirketinde" çalıştığımda, genellikle bir vm'nin dosya sisteminin boyutunu artırmamız gerekiyordu. O sırada ext3 / 4 kullandık.

Sanal diski arttırmak çok kolaydır, canlı bir işletim sistemindeki yeni cihaz boyutunu almak nispeten kolaydır (ext / sys'de yer alır), ext3 / 4 dosya sistemini yeniden boyutlandırmak kolaydı, ama her zaman imkansız görünen şeydi (canlı yapmak) bölüm yeniden boyutlandırılıyor.

Fdisk kullanarak gparted kullanmak ya da yeniden bölümlemek / yeniden boyutlandırmak / yeniden boyutlandırmak zorundaydınız - fakat her zaman çekirdek tarafından kilitlendi ve çekirdeği almak için çekirdeği almak için yeniden başlatılması gerekiyordu (partprobe da yapmadı).

Birçok sistemi LVM'ye taşıdım ve dosya sistemlerini yeniden boyutlandırmak kolay, neredeyse hoş bir deneyim oldu!

• Sanal disk görüntüsünü VM dışındaki alanın artırın
• VM’de
  • Disk metriklerini yeniden taramak için / sys komutunu verin (echo "1"> / sys / class / scsi_device // device / rescan)
  • pvresize / dev / sdX (LVM'deki fiziksel hacmi yeniden boyutlandırın)
  • lvresize --extents + 100% FREE / dev / VG / lvolXX (LVM'deki mantıksal hacmi yeniden boyutlandırma)
  • resize2fs (dosya sistemini yeniden boyutlandır)

Bütün bunlar canlı bir sistemde güvenle yapılabilir - ve yeniden başlatma gerekmez!

Neden çıplak disk değil? Bu beni tedirgin ediyor - Çıplak disklerin henüz yeterince yaygın bir şekilde kabul edildiğini hissetmiyorum, ama sanırım çok daha geniş bir kabulün eşiğindeyiz. Bununla ilgili btrfs posta listesinde bir konu vardı:

http://www.spinics.net/lists/linux-btrfs/msg24730.html

Ancak çıplak bir disk sadece rescan ve resize2fs'e ihtiyaç duyar.

Yani, özet olarak, evet, eğer mümkünse bölüm tablolarından kaçının.

Yazdığınız gibi sorunuz VMWare (ESXi) ile ilgili olsa da, KVM'de de aynı fikri kullandıktan sonra bölüm tablolarını kullanmaya başladığım bir durum eklemek istiyorum.

VM'ler için LVM birimleri varsa ve VM'ler içinde bölümler kullanmadan (tüm sanal diski PV olarak kullanarak), VM'de LVM birim grubu oluşturduysanız, bu VG'nin ana makinede VM dışında görüneceği ortaya çıktı. PV olarak bölümleri kullanıyorsanız bu durum böyle değil.

Verilen, bu bir köşe durumda ama böyle bir kuruluma ihtiyacınız olup olmadığını dikkate değer.

Bunu yapmanın daha iyi olup olmadığı sisteminize bağlıdır.

Her kurulumun artıları ve eksileri var.

Ancak, tek bir sürücünün temel avantajları şunlardır:

1. Basitlik: Tek bir sürücünün kolayca dağıtılabilen ve çoğaltılabilen tek bir dosyası vardır.
2. Ana Bilgisayar İşletim Sistemine İşaretler: Tek bir dosya tek bir veri bloğu olarak değerlendirilir ve bu nedenle ana bilgisayar işletim sistemi konuk makineye erişim dizilerinin hepsinin bir dosyada olacağını bilecektir. Bu, bazı ana işletim sistemi yapılandırmalarında, tüm sürücü görüntülerini aynı dosyaya yerleştirerek elde edilebilir, ancak böyle olması gerekmez.

Ancak, çoklu sürücünün avantajları vardır.

1. Çıplak metal yakınlığı / manuel konum: Tek bir sürücü ile sürücünün tek bir çıplak metal yakınlığına kilitlenirsiniz.
2. Boyut sınırlamaları: Sisteminizde sürücünün boyutu veya dosyaları üzerinde sınırlamalar varsa, bunlara çok büyük sistemlerde vurabilirsiniz.
3. Güvenlik için Salt Okunur hacimleri: Bu büyük avantajdır. İşletim sistemi için ana biriminiz yalnızca VM tarafında okunuyorsa, temel olarak VM içindeki programların konuğun temel işletim sistemini düzenlemesini engelleyen önemli güvenlik avantajları sağlar. Ayrı bir veri sürücüsü kullanmak, sadece temiz oda şablon verileri olmadan bakım ve güncellemeler için okuma-yazma önyüklemesi yapılabilen salt okunur sürücüler oluşturmanızı sağlar ve böylece hayati işletim sistemi dizinlerinin sunucu içinden tamamen değiştirilmesini önler.

Başka bir seçenek daha var: Uygulama verilerini NFS birimlerine ekleyin. İyi dosyalara ihtiyacınız var (NFS uygulamalarının tümü aynı değildir).

NFS birimleri dolduğunda, birimi genişletin, linux istemcisi ek alanı hemen görecektir.

Uygulamanız ve satıcınız, verilerinin NFS'de olmasını desteklemelidir ve dikkatli bir NAS tasarımına ihtiyacınız vardır, ancak sanallaştırılmış ortamınız için her depolama çözümüyle yaparsınız.

Bu yaklaşımın diğer bir avantajı, eğer depolama satıcınızın anlık görüntü / klonlama teknolojisine (zfs veya Netapp gibi) sahip olması durumunda, verileri yedeklemesi ve test / dev ortamları yaratması gerçekten kolaydır.

Bazı Linux dağıtımları için diski bölümlemenizin gerekmesinin nedeni, bir önyükleyici ve bununla birlikte tüm eski parçaların, yani öykünülmüş BIOS'un olması gerçeğinden kaynaklanmaktadır. Bu, bir diski yeniden boyutlandırmayı zorlaştırır ve birçoğu LVM veya benzeri olmayan bir anlamsızlığı kullanarak sona erer.

Biri basitçe tüm birime bir dosya sistemi yaratabilir ve onu /kurabilir, ki bu çok özel (ya da özelleştirilebilir / düşünülmeyen) bir Linux dağıtımı ile çalışacaktır. Bunu Ubuntu 12.04 ile en son denediğimde, yükleyici aptal bölme masalarını ve tüm caz parçalarını kurması gerektiği için nasıl kullanılacağını bilmiyordu. Sanallaştırılmış dünyadaki genel amaçlı dağıtımların sorunu budur.

Öte yandan, biri daha az geleneksel bir kullanıma ayrılabilir , örneğin ChromeOS ve CoreOS sistem yükseltmeleri için salt okunur iki kök bölüme sahiptir.

Şu ana kadar belirtilmemesinin bir nedeni, Google Compute gibi bazı altyapılarda disk GÇ performansının , disk boyutuyla doğrusal olarak artmasıdır . Başka bir deyişle, büyük bir bölümlenmiş sürücü, birden çok küçük sürücüden daha iyi bir IO performansına sahip olacaktır.

Ancak bunun genel olarak böyle olmadığını unutmayın. Chopper3 tarafından belirtildiği gibi, çoğu zaman birden fazla sürücü daha iyi IO performansına sahip olacaktır. Sonuçta, tüm sanal sürücüleriniz tek bir fiziksel sürücüye eşlenirse, hiçbir fark olmamalıdır.

Tecrübelerime göre daha iyi bir yaklaşım OS için 1 VMDK kullanmaktır ve genellikle aşağıdaki şekilde bölümlere ayırırım:

/dev/sda1 - /boot - 256M
/dev/sda2 - swap  - ~4GB
/dev/sda3 - /     - ~8GB

8GB'ı yeterli buldum. Çünkü genellikle minimal Linux dağıtım (~ 800MB) + yazılım yüklüyorum. Kayıtlar aynı zamanda bu bölüme de gider, ancak doğru şekilde kurulursa (bir hafta boyunca oturum açarsanız) ve başka bir yere gönderilirse (syslog / elasticsearch), genellikle bölümü doldurmak için bir işlem oluşturmazlar.

Veriler başka bir VMDK olarak eklenir ve ben genellikle dosya sistemini doğrudan çıplak disk üzerinden biçimlendiririm (örn. / Dev / sdb). Bu, VmWare'deki birimi yeniden boyutlandırmama ve / umount / reboot'a yeniden bölümlemeye gerek kalmadan doğrudan VM'de yeniden boyutlandırmamı sağlıyor.

İki nedenden dolayı bölümlendiriyorum:

1. Belgeler - Bir keresinde "eğitimli" bir EMC yöneticisi, altımdan LUN'ları çalmalarını sağladı; çünkü belgelenmemişlerdi ve ayrılmamış gibi görünüyorlardı ve gecenin ortasında, aniden çevrimdışı hale gelen bir Oracle veritabanı için çağrılıyorlardı. LUN'larımı, ilgisiz bir uygulama için başka bir cilt için yeniden sağladı. O zamandan beri dokümantasyon konusunda paranoyaklığım var.
2. Diskimin aşırı sağlanması. Plakalarla verileri daha yavaş silindirlerden uzak tutar ve SSD ile kullanım ömrünü / MTBF'yi uzatır.