Bir SLES 10 Sunucusuna 60 TB Depolama Ekleme

Bir SLES 10 Sunucusuna arşiv \ aşamalı depolama eklemem gerekiyor. Gereksinim, büyük görüntü dosyaları (çoğunlukla 150Meg Tiff'lar) içeren arşiv verilerini depolamak için kullanılacak oldukça büyük hacimler (her biri yaklaşık 9-20 TB, toplamda 60 TB veya benzeri) sunmaktır. ve büyük tarballlar. Veriler, kesinlikle>% 95 ve muhtemelen% 99'un üzerinde G / Ç okumak için ezici bir şekilde taraflı olacaktır.

Depolama birimi zaten satın alındı ​​- 2 MD1000 ile 2 TB 7200 RPM SATA sürücüler, toplam 45 sürücü ile dolu bir Dell MD3000 SAS dizi papatya. Diziler yığını, iki adet çift portalı harici SAS adaptörü kullanılarak bağlanır, yani yığına 4 yol vardır.

Amacım bunları 4 RAID grubunda oturan ve dizi başına bir etkin yedek olan 4 ciltlik bir set olarak yapılandırmak. Tüm gruplar 7 veya 14 sürücülü RAID 6 olacak ve her RAID grubu bu gruptaki kapasitenin tümü kullanılarak tek bir LUN olarak sunulacak. SLES tarafında, bunların XFS birimleri olarak biçimlendirilmesi gerekir.

SLES (ve genel olarak Linux) ile sınırlı deneyimim var ve özellikle bu konuda bazı öneriler arıyorum:

1. Bu boyuttaki XFS hacimlerini SLES 10 altında yapılandırırken dikkat edilmesi gereken belirli bir şey var mı, yani GÇ profili göz önüne alındığında varsayılan ayarlar iyi olacak mı?
2. Bunları \ partition \ formatlamak için en iyi yol nedir? İlk testim için XFS birimini oluşturmak ve biçimlendirmek üzere Disk etiketini ve YAST Partition Manager'ı (tüm varsayılanları kabul ederek) ayarlamak için Parted kullandım.
3. Çoklu yolu nasıl kurarım? İlk test hacmini gösterdiğimde dört ayrı cihaz (/ dev / sdl, / dev / sdm, / dev / sdn ve / dev / sdn) olarak görünür. Bununla tek bir birim olarak çalışmak için ne yapmalıyım?
4. İlk testlerimde, 30Meg / sn civarında mevcut bir EMC Clariion SAN biriminden aktarım oranları görüyorum. Bu beklediğimden çok daha düşük, hatta 70-100Meg / sn'lik ballparkta bir şey görmeyi beklediğim RAID 6 yazma cezasını hesaba katmak bile.
5. Her şeyin yolunda olup olmadığını nasıl anlayabilirim - hataları \ uyarıları vb. Nerede arayabilirim? YAST Bölümü düzenleyicisinin başlatılması çok uzun sürüyor ve nedenini anlamak istiyorum.
6. Bunu farklı şekilde bölümler misiniz ve \ veya farklı bir dosya sistemi kullanır mısınız?

Sunucu bir Dell 2950 - Ayrıntılı özellikleri kontrol etmedim, ancak üst kısım en düşük tek basamakta gezinmeyi gösteriyor.

Önceki işimde de benzer bir sorun vardı. Planetaryumlar için üretim yapıyorduk ve her kare 64 MegaPiksel idi. Çok sayıda büyük resim. Bunlar, her bilgisayar için bir bilgisayar kümesi üzerinden çok agresif bir okuma işleminde işlenir.

Bu durumda sunucunun benzer bir depolama kurulumu vardı. Çoklu harici doğrudan bağlı RAID dizileri. Bunların her biri, ana bilgisayara maruz kalan RAID6 birimlerinde bulunmuş ve LVM (Mantıksal Birim Yöneticisi) altında bir VG'ye (Hacim Grubu) eklenmiştir. Her gösteri / prodüksiyon daha sonra projeyle gerektiği gibi büyüyeceğimiz kendi LV (Mantıksal Hacim), biçimlendirilmiş XFS'yi alacaktı.

Veri kümeleriniz oldukça statikse veya tahmin edilebilir bir şekilde büyüyorsa, bu yaklaşım sizin için iyi çalışmalıdır. Ancak dikkatli olun bu yaklaşımın bir dezavantajı vardır. Sonuç olarak depolama alanınızdaki LV'leri mikro olarak yönetmeniz gerekir. Bazı yöneticiler bunu bu şekilde tercih eder, ancak bazıları bundan kaçınmaya çalışır. Ancak bu, veri kümesi büyüdükçe her bir LV ve XFS dosya sistemini büyütmenize olanak tanır. Tamamlanması yıllar süren bir fsck ile takılıp kalmamak için XFS birimlerinizi mümkün olduğunca küçük tutun. Ve bir dosya sistemi güneye inerse hasar kontrolü görevi görebilir.

Yasal Uyarı: Bunu bugün kuracak olsaydım OpenSolaris ve ZFS kullanırdım. Temelde b / c mikro yönetim sorunlarını önler ve üstün bir dosya sistemi / birim yöneticisidir. Yani buna da bir göz atmak isteyebilirsiniz.

Daha fazla disk almak ve onları RAID 10 almak için çok daha fazla dahil olurdum.

Bir süre önce satın aldığımız yüzlerce 1 TB FATA (fiber bağlı SATA) diskle ilgili korkunç sorunlar yaşadım, bunlar her biri £ 1k ve ayda% 5 kaybediyorum! Temel olarak sadece 24x7 görev döngüsü için tasarlanmamıştır ve aynı sorunlara sahip olabilmeniz R10'u tavsiye etmemdir.

RAID6 doğru yönde atılmış bir adımdır, ancak yeteneğiniz varsa en az bir diski etkin yedek olarak bir kenara bırakırdım - bir disk dizinizin herhangi bir yerinde ölürse, atlamanız ve sizi beklerken şeritlenecektir arızalı diski değiştirin. Bu konuda, değiştirilmeye hazır en az 2 veya 3 yedek diskinizin bulunduğundan emin olun ve ayrıca 7x24 sorun olduğunda sizi bilgilendirmek için tüm uyarı ayarlarına sahip olduğunuzdan emin olun.

Performansa gelince, bu 2GB diskler 7.2k disk ve SAS için o kadar da hızlı değil, bu yüzden bahsettiğiniz sıralı okumalar için 70MBps'yi beklerim - açıkçası rastgele ve yazma işlemleri oldukça düşük olacaktır.

Üzgünüm, olumsuz görünüyorsa, yıllarca depolama alanı ile güreştim ve sadece kurumsal disk sistemleriyle kolayca uyuyabiliyorum - alt uç dişliyi sabitleyen çok fazla 48/72 saat vardiya çektim.