Hizmet durumu ve kullanılabilirlik Yalnızca kripto faturalandırma · KYC olmadan kayıt

Operatör kılavuzu · 4 dk okuma

Bir sunucu için hangi RAID düzeyi?

Sürücü sayısı, kullanılabilir kapasite, iş yükü ve tolere edilen arızalardan bir RAID düzeyi seçin. Düzen ayrıca izleme ve geri yükleme planınıza uymalıdır: tek bir sunucu içindeki yedeklilik yedek değildir.

Arıza modeliyle başlayın

RAID kullanılabilirliği ve kullanılabilir kapasiteyi değiştirir; yedek değildir. Bir seviye seçmeden önce dizinin kaç eşzamanlı sürücü arızasına dayanması gerektiğine, yazma performansının ne kadar önemli olduğuna ve yeniden yapılandırmanın ne kadar sürebileceğine karar verin.

SeviyeN eşit boyutlu S sürücüsüyle kullanılabilir kapasiteTipik ödünleşim
RAID 0N × SYedeklilik yok
RAID 1SBasit ayna
RAID 5(N − 1) × SBir eşlik sürücüsü; yazma cezası
RAID 6(N − 2) × Sİki sürücü toleransı
RAID 10(N ÷ 2) × SYansıtılmış çiftler ve güçlü rastgele G/Ç

Yeniden oluşturma riski önemlidir

Büyük HDD dizileri saatlerce yeniden oluşturabilir. Bu aralıkta kalan her aygıt meşguldür, bu da ikinci bir arızaya ve gizli okuma hatalarına maruziyeti artırır. RAID 6 genellikle büyük yedek kümeleri için muhafazakar bir kapasite düzenidir; RAID 10 genellikle yazma yoğun veritabanları için seçilir. Denetleyici, dosya sistemi ve kurtarma hedefine göre doğrulayın.

Bağımsız bir kopya saklayın

Bir dizi, silme, fidye yazılımı, dosya sistemi bozulması, denetleyici hataları veya site düzeyinde bir olaya karşı koruma sağlayamaz. Sürümlü yedek verileri başka bir arıza etki alanında tutun ve geri yüklemeleri test edin.

Daha derine in

Doğrulayabileceğiniz bir karar oluşturun.

4 minimum kılavuz

Önce kurtarma gereksinimini yazın

Hata modelini açık bir dille tanımlayın: bir aygıt, iki aygıt, bir denetleyici, yanlışlıkla silme veya tüm sunucu. RAID yalnızca bazı aygıt hatalarını ele alır. Hizmet geri yükleme için bir kurtarma süresi hedefi ve veri kaybı için bir kurtarma noktası hedefi belirleyin, ardından yerel dizinin hangi gereksinimi karşılayabileceğini ve hangisinin başka yerde çoğaltma veya yedekleme gerektirdiğini belirleyin.

Ayrıca sistemin bozulmuş durumdayken yazma kabul etmeye devam etmesi gerekip gerekmediğini kaydedin. Çoğunlukla okunan bir arşiv, yazma yoğun bir veritabanı ve atılabilir geçici alan aynı sayıda sürücü kullanabilir ancak farklı düzenlere ihtiyaç duyar. Kapasite verimliliği bu nedenle bir kısıttır, karar değildir.

Düzeni iş yüküne ve cihaz sayısına göre eşleştirin

Yansıtmalar iki cihazlı önyükleme veya veri kümesi için basittir ve bağımsız yansıtılmış grupların yararlı olduğu rastgele G/Ç'ye uyabilir. Eşlik düzenleri daha fazla kapasite için yazma işini ve yeniden yapılandırma karmaşıklığını takas eder. Çift eşlik geniş bir HDD kümesinde ek bir arıza payı koruyabilirken, RAID 10 ham kapasitenin yarısını yansıtılmış çiftler için takas eder. Bunlar tasarım eğilimleridir, performans garantisi değildir; denetleyici, dosya sistemi, kuyruk derinliği, kayıt boyutu ve uygulama deseni önemlidir.

Gerçek katalog topolojisini kullanın. 12 sürücülü ve 24 sürücülü depolama sunucuları, iki NVMe'li bir işlem sunucusunda bulunmayan seçeneklere izin verir. Ayrı NVMe önyükleme çiftini veri dizisi hesaplamasına katmayın ve hata etki alanlarını ve G/Ç davranışını modellemeden çok geniş bir grubun birkaç gruba tercih edileceğini varsaymayın.

Düzeni iş yüküne ve cihaz sayısına göre eşleştirin
İş yükü sorusuDeğerlendirilecek düzenDoğrulama nedeni
İki yerel cihaz ve süreklilik gerekliYansıtTek cihaz kapasitesi ve basit bir bozulmuş durum
İki arıza gereksinimli geniş HDD havuzuRAID 6 veya RAIDZ2Eşlik genişliği, yeniden oluşturma yükü ve dosya sistemi rehberi
Rastgele yazmalar ve birden çok çift sürücü çiftiRAID 10 veya yansıtılmış vdev'lerKapasite takası ve gerçek iş yükü gecikmesi
Yeniden üretilebilir kaynağı olan atılabilir verilerRAID 0 düşünülebilirHerhangi bir üye kaybı diziyi kaybeder

Yedekliliği sahiplenmek için bir katman seçin

Bir donanım denetleyicisinin mi, Linux MD'nin mi yoksa ZFS gibi bir dosya sisteminin mi düzeni sahipleneceğine karar verin. Sağlık ve değiştirme durumu belirsizleşebileceğinden, belgelenmiş bir neden olmadan bağımsız RAID katmanlarını üst üste yığmaktan kaçının. ZFS yedekliliği aynalar veya RAIDZ vdev'leri aracılığıyla ifade edilir ve sağlama toplamlarına dayanır; kaybolan üst düzey bir vdev havuzu kaybedebilir, bu nedenle aksi halde yedekli bir havuza tek başına yedeksiz bir aygıt eklemek arıza modelini değiştirir.

Diziyi oluşturmadan önce sürücü kimliğini, değiştirme prosedürünü, önyükleme davranışını ve işletim sisteminin neleri gözlemleyebileceğini onaylayın. Topolojiyi daha sonra değiştirmek, özellikle eşlik düzenleri için kısıtlı veya yıkıcı olabilir.

Bozulma ve yeniden yapılandırma penceresini planlayın

İzleme; sağlıklı, bozulmuş, yeniden yapılandırma ve tutarlılık kontrolü durumlarını ayırt etmelidir. Linux MD; resync, recover, check ve repair gibi eylemleri ortaya çıkarır; yalnızca birimin bağlı olduğunu bildirmek yerine ilerlemeyi ve uyumsuzlukları toplayın. Kirli ve bozulmuş bir RAID 5 veya 6 bozulma riski sunabilir, bu nedenle zorla birleştirme asla rutin bir kurtarma kısayolu olmamalıdır.

Uyarı yönlendirmeyi, yedek edinmeyi, değiştirme tanımlamayı, iş yükü kısıtlamayı ve geri yüklemenin devam etmekten daha güvenli olduğu noktayı belgeleyin. Teslim edilen cihazları, dizi yükünü ve denetleyiciyi ölçmeden asla bir yeniden oluşturma süresi vaat etmeyin.

Seçimi ve sınırlarını kaydedin

Tamamlanan tasarım, düzeni, eşit sürücü varsayımlarını, kullanılabilir kapasite tahminini, tolere edilen hataları, izleme kaynağını ve geri yükleme konumunu adlandırmalıdır. Sürümlü verileri başka bir hata etki alanında tutun ve bir geri yüklemeyi test edin. Beklenen sonuç, RAID'ın kaybı önlediği iddiası değildir; üretim verileri gelmeden önce hata davranışı ve kurtarma sorumluluğu anlaşılan bir dizidir.

Doğrudan yanıtlar

Bu rehber hakkında sorular

RAID 6 büyük bir HDD sunucusu için her zaman en iyi seçim midir?

Hayır. İki eşlik toleransı sunar, ancak iş yükü G/Ç'si, vdev veya dizi genişliği, denetleyici veya dosya sistemi rehberliği, yeniden oluşturma işlemleri ve kurtarma hedefi yine de düzeni belirler.

Sıcak yedek harici yedeğin yerini alabilir mi?

Hayır. Yedek, yeniden yapılandırmanın başlamasından önceki süreyi kısaltabilir, ancak aynı sunucuda kalır ve silme, ele geçirme, yığın boyunca yayılan bozulma veya site kaybına karşı koruma sağlamaz.