C: \ OS içindir, D: \ Data içindir?


9

"Günün geri döndüğü" her zaman işletim sistemi sürücülerimizi (Windows'ta) Veri sürücülerimizden ayırdık. Linux dünyasında, ona daha az aşina olmama rağmen, bilgeliğin en iyi uygulama yapılandırmasında tanımlanmış ve kullanılmış daha fazla cilt belirlediğinin farkındayım.

Artık sunucu depolamasının bir SAN'da olması muhtemel (disk kaynaklarının birçok işletim sistemi ve uygulama tarafından paylaşıldığı yerlerde), işletim sistemi ve Veri bölümlerinin ses düzeyinde ayrı tutulması artık gerçekten önemli mi?

Düşüncelerin nelerdir?

Yanıtlar:


7

İşletim Sistemi ve Veriyi depoda saklamak için üç ana sürücü vardır.

  1. Uzay . ErikA'nın belirttiği gibi, gerçekten GERÇEKTEN, işletim sistemi hacminizin boşta kalmasını istemiyorsunuz. Her türlü kötü şey olabilir. Bu iki büyüme yönteminin ayrılması
  2. G / Ç Erişim Gereksinimleri . İşletim sistemi biriminizde kullanılan G / Ç türü genellikle Veri hacimlerinizde kullanılandan çok farklıdır. G / Ç türlerinizi ayrı tutmak, birçok düzeyde çok iyi bir fikirdir.
  3. Depolama Taşınabilirliği . Sunucu işletim sisteminizi yükseltme zamanı geldiğinde, işletim sistemi ses seviyesini azaltabilir ve tüm verileri tutabilirsiniz. Veya SAN veya VM ortamlarında Veri birimini yeni, yeni kurulmuş bir sunucuya taşıyabilir ve yükseltmelerde zaman kazanabilirsiniz.

Ayrıca, bazı işletim sistemleri (Windows bunların arasındadır), işletim sisteminin hacmini yeniden boyutlandırma konusunda çok kibar davranmaz; bu, genellikle sunucuyu biçimlendirirken kullanım ömrü boyunca ihtiyaç duyduğunuz kadarını vermeniz gerektiği anlamına gelir. Bunu, sunucunun kullanım ömrü boyunca birçok kez yeniden boyutlandırılabilen ve sık sık yeniden boyutlandırılan Veri birimleriyle karşılaştırın. İşletim Sistemi ve Datavvumes'in kendilerinin aynı gerçek depoya yerleştirildiği tamamen sanallaştırılmış ortamlarda bile, işletim sistemi hacminizi yeniden boyutlandıramamak büyük bir engel olabilir. Windows 2008+ şimdilerde C: \ sürücüsü için şu an 30 GB’ı önermektedir, bugünlerde Server 2003’te kullandığımız 10 GB’dan çok uzakta; bu, birçok Windows yöneticisini 2003'ten 2008'e dönüştürdükleri için çivileyecek bir şey.


Bunlar iyi noktalar ve paylaşılan depolama yönetimi ile ilgili daha derin konulara değiniyorlar. Örnek: Eğer C: ve D: aynı RAID konfigürasyonunda, vb. Aynı iş takımındaysa, GÇ türü için optimize edemezsiniz. Depolama taşınabilirliği için, C ve D sürücülerin sanal depolamayı hangi nesneyle desteklese olursa olsun aslında farklı LUN'lar olduğundan emin olmak için aynı derecede önemlidir. Aksi takdirde, aynı LUN'da yalnızca bölümlerse, tam bir kopya yapmadan birini yeni bir sunucuya taşıyamazsınız.
Jeremy

12

Evet, kesinlikle işletim sisteminizi verilerden ayırın. Bölünmüş bir bölmeyle, bölmenin doldurulmasının ve işletim sisteminin yamalanmasının imkansız hale gelmesinin, bölmenin genişletilmesinin imkansız hale gelmesinin (çeşitli nedenlerden dolayı) vb.

IMO, iki bölüm yönetmenin ek yükü, sağlanan izolasyon için ödeme yapmak için küçük bir fiyattır.

Bahsettiğiniz SAN destekli sistemler söz konusu olduğunda, bu sizi işletim sistemi bölümünüzü dolduracak verilerden koruyamayacak. Tamamen sanallaştırılmış depolama sayesinde, işletim sistemi ve verilerin ayrı iş millerinde yaşamasını sağlamak için endişelenmenize gerek yok.


Komik, işletim sistemi ve verileri ayırmak için verdiğiniz sebepler aslında yapmamamın nedenleri.
John Gardeniers

Evet, elinizde büyük bir kova o disk bulundurmanın avantajlı olabileceği durumlar (özellikle doğrudan bağlı diski olan sanallaştırılmamış sunucular için) vardır.
EEAA

İlginç bir not olarak, işletim sistemi yeniden yükleme sırasında garip bir şey olduğu için, Windows işletim sistemim F: sürücüsünden önyüklendi ve fazladan veri sürücüm C:
Brian Knoblauch

2

Sistemle ne yaptığınıza bağlı olduğunu söyleyebilirim. İşletim sisteminizi yeniden kurmanız gerekebilirse, tüm verilerinizi ayrı bir bölüme yerleştirerek kendinize biraz güçlük atabilirsiniz. Aksi halde, artık gerekliliği göremiyorum. Benim iki Sentim.


2

Genel ilke olarak, varsayılan işletim sistemi alanını (örneğin, C :) gibi Verilerden ayırmanın iyi bir fikir olduğunu düşünüyorum, ancak günlük dosyaları için küçük bir bölüm oluşturmayı da tavsiye ederim. daha güvenli ve bazı Hizmet Reddi saldırıları önleme.

Linux, kullandığınız fiziksel disk veya sanal bölüm ne olursa olsun, dosya sisteminin tek bir kök dizinin altında hiyerarşik olarak kalması bakımından çok iyidir. Kesinlikle diski bölümlerim, ancak veri ve işletim sistemi ayrımı için mutlaka gerekli olmaz (çünkü çoğu zaman ikisi birbirine karışır).

Şuna bakardım:

  1. Hangi alt dizinlerin disklerini doldurması ve diğer dizinler için alan sorunlarına neden olması muhtemeldir (örneğin, bölüm / home ve / var / log bölümleri).
  2. Dizin yapınızın farklı bölümlerinin performans nedenleriyle farklı dosya sistemlerine ihtiyaç duyup duymadığı (ör. Kararlılık için XFS, tüm kullanım için Ext3 vb.)
  3. Gelecekte hangi dizinlerin genişletilmesi gerekebilir - bunlar bölümleme için iyi adaylardır çünkü dizini yeniden adlandırabilir, bölümleyebilir ve yeni bir disk alanı kümesini dizine yerleştirebilir ve verileri eskiden yeniye kopyalayabilirsiniz. yer.

2

Tarihsel Linux (aslında, Unix gerçekten) bölümlendirme önerileri, kısmen, donanımın (o zaman) göreceli olarak güvenilmezliğinden etkilendiğinden şüphelenilen (ağa bağlı) bir ana bilgisayar sunucusu işletim sistemi olarak kaynaklanmaktadır. Örneğin, günlükler ve geçici veriler tipik olarak ayrılmıştır çünkü bu depolama alanları çok fazla aşınma ve yıpranma geçirmiştir, ancak kaybedilmeleri çok fazla bir sorun değildi.

Bir masaüstü sistemi inşa ediyorsanız, veri / veri / swap bölme işlemine giderim. Ciddiye almayı bekleyen bir sunucu oluşturmazsanız, ayrı / usr / yerel ve / var / tmp gibi şeyler bir boşluk ayırma baş ağrısı olur.


Günlüklerin ve geçici işlemlerin ayrı olduğunu söyleyebilirim, çünkü işletim sistemi genellikle paylaşılan, çok kullanıcılı bir ortam olduğu için haydut bir kullanıcının saçmalıklarıyla doldurma potansiyeli vardı. Güvenilirliğin bir faktör olduğundan emin değildim.
gbjbaanb

0

Bunun hala güzel olduğunu söyleyebilirim - 100 GB veriye sahip (çok fazla pr0n ahbabı :)) ve işletim sistemini yeniden yüklemeniz gerekir (veya Windows geçmişine uygun olarak, kurulumu kaldırmak için düzenli olarak yeniden kurun) kırılmadan) o zaman onu C bölmesinde de olduğu gibi sağlam tutmak için çok basit bir mesele.

Ancak, Windows'un özellikle C sürücüsündeki dizinlerdeki her türlü şeyi doldurmayı sevdiği için bir sorun olduğunu söyleyebilirim - sadece 'kullanıcılar' dizini değil, aynı zamanda tüm uygulama verilerini ve sıkışan bit ve parçaları ProgramData içinde de.

Ayrıca, başka bir faktör var - gerçekten büyük şeyler dışında (evet, yine pr0n) sürekli yedekleme yapan birçok çevrimiçi yedekleme aracı (veya yerel yedekleme aracı) var. Bunlar göz önüne alındığında, verileri ayırmak için bir öncelik değildir, çünkü bunu yedekleme konumundan kolayca geri yükleyebilirsiniz.

Şahsen, veri + işletim sistemini bölmeye çalışıyorum. Ayrıca işletim sistemimin yedeklemelerinin daha küçük olması için uygulamaları da farklı bir bölüme yerleştirmeye çalışıyorum.


0

Farklı bir düşünce okulu için şeytanın avukatı olacağım.

Performans nedenleriyle, satıcınızın işletim sistemi bölümünün "seyrek" olmadığını ve tam işletim sistemi bölümünü önceden tahsis etmenizi istediğini varsayalım. Bu, SAN sürücüde 10 Gb ila 20 Gb (veya daha fazla) kullanılmayan alan elde edilmesine neden olur.

Bu, tek bir VM için gayet iyi, ancak her birinin kendi 10 ila 20 Gb boş alanı olan birkaç "performans açısından kritik" sunucusuna sahip olma ihtimaliniz var. Çevremizde bu boşluk SAN diskimizin% 20'sini oluşturuyordu. SAN diskini doldurmamız gereken sınırlar olduğunu unutmayın (ancak bu başka bir hikaye).

Yönetim bir seçenek vardı

1) SAN'da, "beyaz alan" ın diğer gerekliliklerine ek olarak% 20 boşa alanını absorbe edin ve oluşabilecek "tam disk" senaryosunu izole edin

2) C: \ sürücüsündeki her şeyi yerleştirin ve uygulama günlükleri nedeniyle sürücünün dolma tehlikesi vardır.

Onlar ne yaptı?

Windows 2008R2'nin ana bilgisayar işletim sisteminin C: \ sürücüsünü dinamik olarak genişletebileceğini ve sürücüyü dolu olduğunda genişletebileceğini düşünerek, yönetim maliyeti "tasarruf" aldı ve SCOM gibi izleme araçlarına yeniden yatırdı.

Şimdi bir C: \ sürücü dolgusunun basit korumasından daha fazlasını alıyoruz, ancak gerçekleşmeden önce diğer endişeleri gidermek için daha eksiksiz bir sistem izlemesi var.


İnce provizyonlu SAN hacimleri, işletim sistemi içerisinde çalışan ve bir dosya silindiğinde SAN'a geri ileten bir yazılımınız olmadıkça, veri karmaşası nedeniyle yoğun provizyon alma alışkanlığına sahiptir. Dolayısıyla, bir SAN ortamında, yalnızca önyükleme sürücüsüne gerektiği kadar alan ayırmanız ve bunların zamanla kullanılacağını kabul etmekten daha iyidir. SAN bunu daha da karmaşık hale getiriyor, size bunu vereceğim! Belki hem C: hem de D: için tek bir SAN birimi (disk performansı ve iş yükü gereksinimleri gibi diğer pek çok faktöre bağlı olarak) tahsis etmiş olabilirsiniz.
Jeremy,
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.