Sanallaştırma ile, birden fazla bağlama noktası kullanmak hala anlamlı mı?

2013 yılında, yeni bir Linux görüntüsü üzerinde hala birden fazla bağlama noktasına sahip olmak mantıklı mı, yoksa daha fazla mantıklı / mantıklı alan mı ayırıyor?

Bir bağlama noktasının boyutunu artırmak için gereken yeniden başlatmadan kaçınmayı tercih ederim. Ayrıca tek bir bağlantının alanını izlemeyi tercih ederim. Tüm sunucunun, bireysel bağlama noktalarıyla uğraşmak yerine% 70 sürücü alanı kullanımının üzerinde olduğunu tercih ederim.

Tabii hala faydalı. Kaçak bir işlemin bir günlüğü doldurmasını ve / sürücüsünün tam diske neden olmasını istemezsiniz. Ayrıca, LVM gibi bir şey kullanıyorsanız, birimlerin çevrimiçi genişlemesini yapabilirsiniz.

Birçok VM ile, IO'yu yine de ayırmak isteyeceksiniz. Muhtemelen veritabanlarınızı ayrı iğlerde isteyeceksiniz ve bunu başarmanın tek yolu, veritabanınızın konumu için ayrı bir bağlama noktasına sahip olmaktır. Veritabanları bir yana, orijinal tasarımınızı aşarsanız yolda daha ayrıntılı esneklik sağlar.

Kısacası, evet bunu 2013'te yapmak için hala iyi nedenler var.

Günümüzde, çok fazla ayrı montaj kullanmam, ancak muhtemelen birkaç anahtar olan sistem yönetiminde yardımcı olacaktır.

Sadece 2 veya 3, özellikle. boyut olarak değişen bir tane. Bu ne kullandığınıza bağlıdır. Ben sadece / (nispeten kararlı) ve / var (değişen) diyebilirim. İşletim sistemine ve disk geometrisine bağlı olarak, / boot da gerekebilir. / tmp muhtemelen yükleyici tarafından kurulmuş bir tmpfs bağlamasıdır.

Değişen (/ var çoğunlukla, ama sadece / var / log ve / var / lib / mysql vb. Olabilir) hacimler genellikle endişelenmeniz ve genişlemeyi planlamanız gereken şeydir. Bu yüzden mümkünse yeniden boyutlandırmayı kolaylaştırmak için lvm vb. Kullanın.

Evet, hala izleme, güvenlik ve bakım gereksinimleri için sanal makinelerde ve bağlantı noktalarında birden çok bölüm kullanıyorum.

Tek veya sınırlı bağlama noktası sanal makinelerinin hayranı değilim (fırlatma makineleri olmadıkça). VM'lere fiziksel sunuculara aynı şekilde davranıyorum. Bölümleri bazı Linux Dosya Sistemi Hiyerarşi Standardı ile hizalamak , yürütülebilir dosyaların, veri bölümlerinin, geçici ve günlük depolamanın mantıksal olarak ayrılması açısından hala mantıklıdır. Bu aynı zamanda sistem onarımını da kolaylaştırır. Bu, özellikle bir şablondan türetilen sanal makineler ve sunucular için geçerlidir.

(BTW, sanal makinelerde LVM'yi de sevmiyorum ... Daha iyi planlayın !! )

Sistemlerimde aşağıdakileri yapmaya çalışıyorum:

• / tipik olarak küçüktür ve fazla büyümez.
• /boot boyut olarak tahmin edilebilir ve büyüme çekirdek güncellemelerinin sıklığı ile kontrol edilir.
• /tmpuygulamaya ve çevreye bağlıdır, ancak uygun şekilde boyutlandırılabilir. Ayrı ayrı izlenmesi anormal davranışın ölçülmesine yardımcı olur ve sistemin geri kalanını korur.
• /usr Yürütülebilir dosyalar, vb. İçeren öngörülebilir olmalıdır.
• /varbüyür, ancak veri karmaşası miktarı daha az olabilir. Ayrı olarak ölçmek güzel.
• Ve bir büyüme bölümü. Bu durumda, /dataama bu bir veritabanı sistemi olsaydı, olabilir /var/lib/mysqlya da /var/lib/pgsql... Farklı bir blok cihaz olduğunu unutmayın /dev/sdb. Bu, bu sanal makinedeki başka bir VMDK'dır, bu nedenle gerçek OS bölümlerini içeren VMDK'dan bağımsız olarak yeniden boyutlandırılabilir.

# df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda2              12G  2.5G  8.8G  23% /
tmpfs                 7.8G     0  7.8G   0% /dev/shm
/dev/sda1             291M  131M  145M  48% /boot
/dev/sda7             2.0G   68M  1.9G   4% /tmp
/dev/sda3             9.9G  3.5G  5.9G  38% /usr
/dev/sda6             6.0G  892M  4.8G  16% /var
/dev/sdb1             360G  271G   90G  76% /data

Bu bölümlerin bazılarının ayrılması, eğilimleri belirlemeyi ve anormal davranışları tespit etmeyi çok daha kolay hale getirir; örneğin 4GB çekirdek dökümü /var, bitkin bir süreç /tmp,

Normal

Anormal. /varBüyük bir /bölümün kullanılıp kullanılmadığını anlamak için ani yükseliş kolay olmayacaktı .

Son zamanlarda, güvenlikle sertleştirilmiş bir VM şablonu için dosya sistemi bağlama parametreleri ve nitelikleri (nodev, nosuid, noexec, noatime, nobarrier) kokteyli uygulamak zorunda kaldım . Bölümleme bunun için mutlak bir gereklilikti, çünkü bazı bölümler global olarak uygulanamayan belirli ayarlar gerektiriyordu. Başka bir veri noktası.

Tabii ki çoklu bağlama noktalarının hala avantajları var, sanallaştırılmış bir sunucu veya değil.

Ancak sanallaştırma ile muhtemelen sanal makine şablonlarını da kullanıyorsunuz, değil mi? Ve Nagios (NConf? İle) gibi izleme sisteminiz de şablonları destekler? Eğer öyleyse, o zaman bu zihinsel bağlama noktası dövüşünden sadece bir kez geçmeniz gerekir.

Konuya geri dön.

: Ben bu şekilde sistemlerimi bölmek için kullanılan /, /home, /usr, /var, /tmp(ve muhtemelen diğer bazı veriler için bağlama noktası), fakat overkill ve güçlük olduğunu. Günümüzde basit bir işletim sistemi görüntüsü sadece /, belki de ayrı /varbir sistem ile benim için gitmenin bir yoludur; bir sanal sunucunun veri için daha fazla depolama alanına ihtiyacı varsa, bunun için başka bir disk görüntüsü veriyorum ve gerektiğinde monte ediyorum.

Dosya sunucuları için, /homebirimi kendi bölümüne / diskine bağlama eğilimindeyim ve noexecbunu takarken bu seçeneği kullanıyorum . Paranoia, ancak kullanıcıların ana klasörlerinden dosya yürütmesini engeller.

Ayrıca, /bootbirimi tüm sürücülere RAID 1 aynasına koyma eğilimindeyim , ancak yine de, eski bir uygulama, henüz bir dezavantaj görmediğimi takip ediyorum