Veritabanımı RAID 5 yapılandırmasından çalıştırmalı mıyım?


13

RAID 5'in yazma performansının bazen dehşet verici olabileceğini duydum. Sağladığı fazlalık isterken veritabanı ekleme / güncelleme sürelerimi feda etmek istemiyorum.

Bu endişelenmem gereken bir şey mi ve eğer öyleyse, iyi yazma performansı ile artıklık elde etmenin önerisi ne olur ?


1
Hangi DB? Oracle + RAID 5 eskiden hayırdı. Durumun hala böyle olduğundan emin değilim.
cagcowboy

Bu özel örnekte veritabanı MySql ve MSSQL üzerinde çalışır.
Scott Saad

Uygulama ile ilgili soruda biraz daha fazla özgüllük (DB okuma / yazma karışımı, çalışma süresi ve kurtarma süresi gereksinimleri) daha uygulanabilir bir cevap alabilir; bunlar en iyi çözümde fark yaratabilir.
Jay Stevens

Yanıtlar:


23

G / Ç çok rasgele olduğu için RAID 10 genellikle önerilir. İşte bir örnek. Hesaplamalar biraz basitleştirilmiş, ancak oldukça temsili.

Diyelim ki 6 sürücü diziniz var ve sürücüleriniz saniyede 100 I / O (IOPS) yapabilir. % 100 okumanız varsa, altı sürücünün tümü kullanılır ve hem RAID 10 hem de RAID 5 için yaklaşık 600 IOPS'ye sahip olursunuz.

En kötü senaryo% 100 yazıyor. Bu senaryoda, RAID 10'un performansı yarıya düşecektir (her yazma iki sürücüye gittiğinden), 300 IOPS alacaktır. RAID-5, her yazmayı iki okumaya ve ardından iki yazma haline dönüştürür, böylece performansı 1/4 veya yaklaşık 150 IOPS elde eder. Bu oldukça büyük bir hit.

Gerçek okuma / yazma düzeniniz bu iki uç arasında bir yerde olacaktır, ancak bu nedenle RAID 10 genellikle veritabanları için önerilir.

Ancak, meşgul bir veritabanı sunucunuz yoksa, RAID-6 bile yapabilirsiniz. Sık sık veritabanının darboğaz olmayacağını biliyorsanız, RAID 10 veya RAID 5'ten çok daha fazla güvenlik sağladığı için bunu yaparım.


22

İşlem veritabanları

RAID-5'in yazımı nispeten yavaştır, çünkü kontrolörün bir yazmadaki pariteyi yeniden hesaplamak için yeterli veri yüklemesi gerekir. Yazma işlemleri en az dört disk işlemi gerektirir:

  • Eşlik bloğunda okuma

  • Parite bloğu ile değeri XOR'a eski blokta okuma (zaten önbellekte olmadığı varsayılarak).

  • Yeni eşlik bloğunun yazılması (eski eşlik bloğu XOR eski veri bloğu XOR yeni veri bloğu)

  • Yeni veri bloğunun yazılması.

Sistem geri yazma önbelleği kullanmazsa, bu seçeneklerin tümü G / Ç tamamlanması için kritik yolda olduğu anlamına gelir. Genellikle, veritabanı yazarlarında durum böyledir - aslında, Microsoft'un (örneğin), satıcıların bu davranışı garanti etmesini gerektiren SQL sunucusuyla kullanım için SAN ekipmanı için bir sertifika programı vardır. Bazen eski RAID-5 ekipmanı bu optimizasyonu kullanmadı ve pariteyi tüm şeritten yeniden hesaplamak zorunda kaldı.

RAID-10'un her bir sürücü için bir aynası vardır ve eşlik hesaplamak için ek verileri okumasına gerek yoktur. Bu, yazma işlemlerinin daha az fiziksel G / Ç'ye ihtiyaç duyduğu anlamına gelir.

RAID-50 , ortada bir yerde oturur ve hacim sırayla çizgili olan birden fazla RAID-5 birimine bölünür. 3 + 1 şemasında çizgili gruplardan yapılan bir RAID-50'de bir yazma en fazla üç ek disk G / Ç isteği oluşturur. Çok eğimli hissediyorsanız, RAID-5 ve RAID-10'u RAID-50'nin özel durumları olarak görebilirsiniz. RAID-50 temel olarak birçok fiziksel diskte büyük hacimler sağlamak için kullanılır

RAID-6 (set başına iki yedek diske sahip bir eşlik şeması) gibi diğer eşlik şemaları da mevcuttur, Modern diskler, bir dizinin yeniden oluşturulmasının oldukça uzun bir zaman alabileceği kadar büyüktür - bu işlem sırasında ikinci bir disk arızası riski yeniden inşa oldukça önemlidir. RAID-6, veri kaybına neden olması için üç disk arızası gerektiren ikinci bir eşlik diskine sahip olarak bu riski azaltır. RAID-60 şemalarına benzer bir hile, RAID-60 dizileri yapmak için kullanılabilir.

Son olarak, tek bir yansıtılmış çift (RAID-1 olarak bilinir), bazı görevler için yedeklilik ve yeterince iyi performans sağlayabilir. Özellikle, RAID-1'in oldukça fazla veritabanı günlüğü trafiği için yeterli verimi sağladığını göreceksiniz. Bu konuda daha fazlası aşağıda.

Yazma ağır bir iş yükünüz varsa, büyük olasılıkla RAID-10 biriminden bir performans kazancı elde edersiniz. Muhtemelen daha az sayıda fiziksel diskten gerekli verimi alabileceğiniz için, disklerin yeterli alana sahip olduğu varsayılarak bu bir kazanç olabilir). Veritabanı sunucusundaki günlükler veya geçici alanlar gibi bazı öğelerin RAID-1 veya RAID-10 birimlerinde olması gerekir, çünkü bunlar çok fazla yazma trafiği alır.

Kütükler

Günlük hacimleri çoğunlukla sıralı bir veri erişim modeli ile karakterize edilir ve esasen 'bu verileri bu bloğa yaz' satırları boyunca komutlardan oluşan bir halka tamponudur Çekirdek DBMS motoru tarafından bir üretici olarak yazılır ve bir tüketici olarak işlenir günlük okuyucu işlevi tarafından. Tek bir yansıtılmış çift aslında oldukça fazla günlük trafiği işleyecektir.

Ağır okuma sistemleri ve dosya sunucuları

Veri ambarı gibi ağır bir sistemde bir veya daha fazla RAID-5 birimi kullanmak isteyebilirsiniz. Bir dosya sunucusunda, disk erişimleri büyük ölçüde tüm dosya bazında yapılacaktır, bu nedenle yazmalar muhtemelen yine de eşlik bloğunu oluşturan blokların çoğunu yazacaktır. Bu durumda RAID-5 için performans cezası daha hafif olacaktır.

Geçmişte diskteki maliyet tasarrufları önemli olabilirdi, ancak şimdi bu bir sorun olma olasılığı daha düşüktür.

Geri yazma önbelleği ve RAID-5

Pil destekli önbelleğe sahip bir SAN veya dahili RAID denetleyicisinde 'Geri yazma' önbelleğini etkinleştirebilirsiniz. Bu önbellekler yazma ve denetim uygulamaya döndürür. I / O kontrolör tarafından tamamlanmış olarak rapor edilir. Ancak, verileri derhal diske yazması gerekmez. Bu özellik, RAID-5 eşlik okuma / yazma işlemlerinin büyük ölçüde optimize edilmesine olanak tanır ve RAID-5x birimleri için yazma performansı cezasını yumuşatabilir.

Bununla birlikte, bu hala veri bütünlüğü sorunları için küçük bir risk taşır. Ana bilgisayar sistemine, bu yazının gerçekte böyle olmadığı zaman tamamlandığı söylendi. Bir donanım arızasının bir veritabanı sunucusundaki (örneğin) günlük ile veri birimleri arasında veri tutarsızlıkları yaratması mümkündür. Bu nedenle, ETL işlemi gibi bir şey için bir performans kazancı olsa da, işlem sistemleri için geri yazma önbelleği önerilmez.

özet

Disk alanı günümüzde o kadar ucuz ki, işlem sistemleri günlük birimleri için muhtemelen RAID-1 veya RAID-10 ve veri birimleri için RAID-10 kullanmalıdır. Fiziksel disk boyutunun veritabanından çok daha büyük olması muhtemeldir ve RAID-10 aynı sayıda disk için daha fazla yazma işlemine izin verir ve bu da sistemi desteklemek için gereken disk birimlerinin sayısını azaltır.

Bir veri ambarı gibi bir şeyde, büyük, yoğun bir şekilde dizine alınmış olgu tablolarıyla alanı çiğneyebilirsiniz, böylece RAID-5 veya RAID-50 veri hacimleriyle küçük bir fiyat kazanabilirsiniz. Ancak günlükler ve tempdb, RAI-10 birimine yerleştirilmeli, çünkü ETL işleme sırasında büyük olasılıkla çok fazla iş alacaklardır. Bununla birlikte, diskteki maliyet tasarrufunun oldukça küçük olması muhtemeldir.


Geri yazma önbelleği: "Pil destekli" geri yazma önbelleğine sahip bir RAID denetleyicisi satın alıyorsanız, pilin ürünle birlikte gelmediğini unutmayın. Tedarikçinizden bir tane eklemesini sağlayın.
David Hicks

Bazıları yapar, bazıları yapmaz. Pillerle birlikte gelmeyen birkaç Adaptec 2200'üm var. Bazıları standart olarak onlarla birlikte gelir.
EndişeliOfTunbridgeWells

1
Yanıtınızda bir hata var. Sen do not yeniden hesaplamak parite için her sürücü okumak gerekir. Bir yazma 2 okuma ve 2 yazma olur. Örnek 14-sürücü dizinizdeki diğer 12 sürücüye RAID5 dokunmaz.
TorgoGuy

Aslında, adamın haklı olduğuna inanıyorum. Pariteyi eski bloğun değeriyle ve yine bloğun yeni değeri ile okuyabilir ve XOR okuyabilirsiniz. Daha önce tarif edileni hiç görmedim ama işe yarayacaktı.
ConcernedOfTunbridgeWells

3

Bu, büyük ölçüde hata / risk toleransınıza bağlıdır. RAID5'in birçok sorunu var . DB sunucum şu anda iki yansıtılmış sürücüye sahip ve bunu ölçeklendirirsem, daha fazla eşlikli, muhtemelen RAID6 veya RAID10 olan bir şey için giderdim.

Ayrıca, uygulamanız çalışma süresi açısından kritikse, büyük olasılıkla master-master veya hot backup veya her neyse replikasyona sahip iki veritabanı sunucusuna sahip olmanızı öneririm. RAID yalnızca disk arızalarına karşı yardımcı olur, ancak bir sunucuda yanlış gidebilecek çok daha fazlası vardır :)


3

Ne kadar yazdığınıza bağlı.

Oldukça hafif bir "web uygulaması" ise, RAID5'te herhangi bir performans görmeniz pek olası değildir.

Büyük ETL'lere sahip çok GB'lı bir veri ambarı oluşturuyorsanız, RAID 5'teki yazma arabelleği hızla taşacak ve doğrudan RAID 5'in "düşük yazma performansı" na gireceksiniz.

Her RAID5 yazma işlemi en az 3 yazma işlemine neden olur (artı bir CRC hesaplaması). Arabelleklendiğinde, bu iyi ve hızlıdır (küçük kısa aktivite patlamaları - tek kayıt güncellemeleri ve ekler). Bu uzun süreli yazma işlemleri (büyük yığın ekleme / güncelleme) yapılırsa fark edilir.

Performans ve mekan arasında bir denge. RAID 10 (şeritli sürücülerin aynası) hem performans hem de esneklik sağlar, ancak kapasitede% 50 azalma sağlar.

RAID5 daha yüksek kapasite, iyi okuma performansı ancak zayıf (büyük) yazma performansı sağlar.


2

RAID 1, bu benim son cevabım

Nedenleri:

yansıtılmış çift arızalı diskler için yeterli yedeklilik sağlar ve RAID son diske çalışmaya devam eder.

yansıtılmış çift, verilerinizi ve dizinlerinizi dikkatlice yerleştirirseniz, okumalar için daha fazla G / Ç performansı sağlar ... [ipucu: Veriler ve dizinleri için ayrı hacimler kullanın]. Denetleyicilerinizi dupleksleyerek daha da fazla performans elde edebilirsiniz.


Neden RAID 1 + 0 olmasın?
Brian Knoblauch


2

Kısa cevap: hayır.

Uzun cevap: çok küçük bir veritabanınız veya çok az gereksiniminiz yoksa, hayır. Veri alma, büyük ölçüde saniye başına disk G / Ç işlemlerine bağlıdır ve şeritleme yükü, özellikle uzun sorgu çalışmalarında , disk erişiminizi zaman içinde tüketir . Çoğu veritabanı, RAID 10 stili bir kurulumda veya verilerin bölümlerini tutan belirli birimlerde çalıştırılır. Evet, RAID 10 sen şöyle yazıyor mal olacak, ama (sağ kurulum ile) sizin okuma performansı gidecek şekilde yukarı .


1

iyi yazma performansı ile artıklık elde etmenizi önerir mi?

Büyük bir geri yazma önbelleği. Donanım RAID denetleyicinizdeki RAM'i veya yazılım RAID çözümünüzün kullanabileceği RAM'i artırın (yani Linux'un MDADM'si için sistem RAM'ini artırın, MDADM balonları aksi takdirde kullanılmayan sistem RAM'ini yazma önbelleği olarak kullanın). Bu tavsiye, verilen "büyük" değerleri için geçerlidir - sık sık (zamanın% 5'i?) Veri yazma önbelleğini dolduracak kadar hızlı bir hızda yazarsanız, ne kadar büyük olursa olsun, bu çok az fark yaratacaktır.


1

Gerçekten onun veri dosyaları, günlük dosyaları, OS dosyasından ayırma hakkında. Günlükler sıralı olarak yazılır Veriler çok sayıda rastgele okuma ve bazı rastgele yazmalara neden olur

Bu özellikleri destekleyen RAID yapılandırmaları oluşturarak performansı büyük ölçüde artırırsınız

Raid 1 - yansıtma günlük dosyaları için mükemmeldir Raid 10 veri dosyalarınız için iyidir. Ayrıca TempbDB ve yedekleri ayrı sürücülere ayırmaya bakmaya değer. Dosya grupları eklemek, performansı artırmanın başka bir yoludur. SAN'lar söz konusu olduğunda bu çok açık değil. Her LUN için özel baskın yapılandırmaları oluşturmanıza veya iş mili sayısına bağlı olup olmadığınıza bağlıdır.


0

Ruhuyla son StackOverflow blog makalesinde Internet üzerinde zaten mevcut cevapları-present re gerektiğini söyleyerek, ben sizi işaret bu

RAID-5 sağladığı yedekleme açısından benzersiz değildir, sadece bazı alternatiflerden daha az ek disk tüketirken yapar. Eşit veya daha iyi yedeklilik ve daha iyi yazma performansı ile başka bir şey seçebilirsiniz


0

RAID5'ten bir veritabanı çalıştırmak genellikle bir hatadır. Sadece iki durumda yapıldığını gördüm - az sayıda yazım ile yoğun okuma gerektiren iyi tasarlanmış veritabanları ve RAID5 nedeniyle "alan israfının" politik olarak uygun olmadığı veritabanları.

RAID5 işlemsel performansı yok edecektir.

Ayrıca, RAID5'i düşünüyorsanız, RAID6'nın çalışıp çalışmadığını kontrol edin. Teorik güvenilirlik çok daha iyidir, ancak gerçek dünyadaki güvenilirlik, olgunlaşmamış uygulamalar nedeniyle genellikle daha kötüdür.

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.