RAID1 veya 5 yerine RAID0, bu çılgınca mı?

SQL Server kümelerimizden biri için bir RAID0 kurulumu kullanmayı düşünüyorum. Durumun ana hatlarını çizeceğim ve bunun neden kötü bir fikir olabileceğini araştıracağım. Ayrıca birileri vakaları, teknik incelemeleri veya diğer belgeleri kullandığınızda bu konuyu bana yönlendirebilirsiniz, bu harika olurdu.

Bir SQL kümesinin parçası olan 2 veri merkezinde 3 sunucumuz var. Hepsi bir kullanılabilirlik grubunda SQL Server çalıştırıyor. Birincil, hemen yanında, diğer veri merkezinde ise bir kopyaya sahiptir. Otomatik yük devretme ile eşzamanlı çoğaltma çalıştırıyorlar. Tüm sürücüler kurumsal sınıf SSD'lerdir. SQL Server 2017 veya 2019 çalıştıracaklar.

Onları RAID0 dizilerinde, diğer yöntemlere göre, gerçek dezavantajları olan birkaç yöntemle çalıştırmanın birçok faydası olacağını düşünüyorum. Şu anda gördüğüm tek negatif birincil sunucuda fazlalık olmaması, bu yüzden başarısız artar. Profesyoneller olarak:

1. Bir sürücü el ile hareket ettiğine dair bir bildirim alana kadar bir sürücü yavaşlamış, bozulmuş bir durumda çalışmak yerine başarısız olursa, sunucu tam çalışma kapasitesini koruyan bir ikincil duruma geçemez. Bunun, bir yük devretme konusunda bizi bilgilendirmesinin ek bir yararı olacaktır.

2. TB kapasitesi başına toplam arıza olasılığını azaltır. Eşlik veya yansıtma sürücülerine ihtiyacımız olmadığından, dizi başına sürücü sayısını azaltırız. Daha az sayıda sürücüde, bir sürücü arızası olasılığı daha azdır.

3. O daha ucuz. Gerekli kapasitemiz için daha az sürücüye ihtiyaç duyulması elbette daha az maliyetli.

Bunun geleneksel iş düşüncesi olmadığını biliyorum, ama düşünmediğim bir şey var mı? Pro ya da con herhangi bir girdi isterim.

Anlamlı olanlar onları işaret için çekinmeyin olsa, sorgu performans kazançları için bunu yapmaya çalışmıyorum. Temel kaygım, düşünmediğim bir güvenilirlik veya artıklık sorununu dikkate almamak veya ele almamaktır.

İşletim sistemi ayrı bir yansıtılmış sürücüde olduğundan, sunucunun kendisi kalmalıdır. Bu sürücülerden biri değiştirilebilir ve yeniden yansıtılabilir. Küçüktür ve üzerinde sistem DB'leri dışında herhangi bir veritabanı dosyası yoktur. Birkaç dakikadan fazla sürdüğünü hayal edemiyorum. Veri dizilerinden biri başarısız olursa, sürücüyü değiştiririz, diziyi yeniden oluştururuz, geri yükler ve AG ile yeniden senkronize ederiz. Kişisel deneyimime göre, geri yükleme işlemi RAID5 disk yeniden yapılandırmasından çok daha hızlıydı. Hiç RAID1 hatası yaşamadım, bu yüzden yeniden oluşturmanın daha hızlı olup olmayacağını bilmiyorum. Geri yüklemeler bir yedeklemeden gelecek ve birincil ile eşleşecek şekilde ileriye doğru döndürülecektir, bu nedenle birincil sunucudaki yük artışı, yalnızca günlüklerin son birkaç dakikasını kurtarılan çoğaltma ile eşitlemek için çok az olmalıdır.

Değerlendirmenizde eksik olduğunuzu düşündüğüm çok önemli bir nokta var:

Nasıl iyileşmeyi planlıyorsunuz?

Raid5 bir sürücüyü kaybettiğinde, otomatik olarak iyileşene kadar bozulmuş durumda çalışır. (En azından elinizde yedek bir yedek varsa.)

Bir baskın0 bir sürücüyü kaybettiğinde, hiçbir zaman iyileşemez. Bu, artıklığı kaybettiğiniz anlamına gelir ve onu kurtarmak için, raid0'inizi yeniden oluşturmanız ve tüm verileri (sadece bozuk sürücüdeki verileri değil), şimdi üretim yükü altındaki ikincilden geri kopyalamanız gerekir . Yani, tek bozulmuş raid5 dizisi yerine, şimdi performans isabetini alan tüm üretim kurulumunuz.

Raid5 (veya raid6) bozulmuş durum performansı cezası başa çıkabileceğiniz bir şey değilse, muhtemelen 1 + 0 baskını yapmanız gerekir . Evet, daha pahalıya mal oluyor, ama disk fiyatları oldukları gibi, iyi harcanan para olacak.

Belki de "raid5 durumunu aktif olarak izleyin ve bir sürücü arızalandığında yükü primerden aktarın" size herhangi bir dezavantaj olmadan avantajların çoğunu sağlayan çözümdür? (Tabii ki herhangi bir yerel artıklık olmadan çalışma serinlik faktörünü kaybetmenin yanı sıra.) Raid5 sürücü kurtarma işleminiz tam bir veritabanı veri senkronizasyonundan çok daha uzun sürüyorsa, raid yazılımınız garip davranıyorsa veya ciddi boyutta diskleriniz varsa, Düşünürdüm.

Sürücü arızası burada dikkate alınmalıdır.

Bir saniye için sürücülerimizin 1/1000 arıza oranına sahip olduğunu düşünün. Öyleyse 3 dizimizin her birinde 20 sürücümüz olduğunu hayal edin.

Bu nedenle, bir dizide tek bir sürücünün arızalanma olasılığı 20/1000 = 1/50'dir. Aynı dizide iki sürücünün arızalanma olasılığı 20/1000 * 20/1000 / 2 = 200/1000000 = 1/5000'e yakındır. Bu nedenle RAID 0'dan RAID 5'e geçerek dizilerimizden birini öldürme olasılığımız oldukça düşüktür.

Bunu daha da ileriye götürebiliriz - bir dizinin başarısız olma olasılığı 1/50 ise, günde iki dizinin başarısız olma olasılığı 1 / (50 * 50) = 1/2500 olur. İki özdeş RAID 0 dizisinin başarısız olma olasılığı, aynı disk setini varsayarak bir RAID 5 dizisinin başarısız olmasının iki katıdır. Hata olasılığındaki bu üstel artış, aynı anda birden fazla dizinin başarısız olma olasılığını büyük ölçüde artırdığı için sizi ilgilendirmelidir .

Bu disklerin uzun ömürlü olması muhtemel olduğundan, sayıları yukarıdaki gibi çalıştırabilir ve bunun güvenilirlik üzerinde ne gibi bir etkisi olacağını doğrudan görebilirsiniz - sürücü özelliklerini gönderebilirseniz bu hesaplamayı bu yazıya ekleyebilirim. O zaman riskin kabul edilebilir olup olmadığı, kuruluşunuzun karar vermesidir.

Dikkat edilmesi gereken bir diğer nokta, aynı parti (aynı fabrika, aynı zamanda) içinde üretilen SSD'ler kullanılarak sürücü arızası olasılığının artırılabileceğidir. Dikkatli olmazsanız, bu sorun nedeniyle 3 düğümün tümü düşebilir.

Feragatname: Yukarıdaki hesaplamalar basitleştirilmiştir - hala nispeten doğrudur.

Onları RAID0 dizilerinde, diğer yöntemlere göre, gerçek dezavantajları olan birkaç yöntemle çalıştırmanın birçok faydası olacağını düşünüyorum.

Bu, AG'leri dahili / doğrudan bağlı depolama sürücüleri ile çalıştırırken oldukça yaygın bir yapılandırmadır. Özellikle NVMe veya diğer PCI tabanlı flash depolama aygıtları ile.

Bir sürücü arızasını bir sunucu arızası gibi ele almak anlamına gelir. Az sayıda katı hal sürücüsü ile, sürücüler için sunucunun diğer katı hal bileşenleri için olduğundan çok daha düşük bir MTBF'ye sahip değilsiniz ve böylece her sürücüyü ve sürücü arızası durumunda sunucuyu değiştirin / yeniden oluşturun.

Neyi başarmaya çalıştığınıza meraklıyım? Bu kurulumdan performans kazancı elde etmeye çalışmadığınızı söylüyorsunuz, o zaman ne kazanmaya çalışıyorsunuz?

Performans sorunuyla ilgili not: Enterprise Class SSD'leri kullanıyorsanız, RAID hesaplamanız gerçekten bunu geliştirmek için gereken bir darboğazdan mı ibarettir?

3 profesyonelinizi alarak, yeterince düşündüğünüzü sanmıyorum:

1. SQL yük devretme hemen gerçekleşecek mi? Yük devretmenin otomatik olarak tetiklenmesine ne sebep olur? Birisi vurur vurmaz sunucu sürücüyü çevrimdışına alır mı? Ya bir diskte sadece kötü bir sektörse? SQL kötü sektöre çarpmazsa, yük devretme olur mu? Bundan% 100 emin değilim.

2. TB kapasitesi başına toplam arıza olasılığını azaltır mı? Düşünceleriniz daha az disk gibi görünüyor, daha az başarısızlık demektir, ama bunun doğru olduğunu düşünmüyorum. 1 disk veya 10 disk (veya 100 disk) varsa, 1 diskin başarısız olma olasılığı aynı kalır, ancak RAID 0 ile bu aynı zamanda felaketli bir arıza olduğu anlamına gelir.

3. Bir ekstra SSD, RAID5'i almanız için çok daha pahalıya mal olacak mı? Nasıl RAID1 VEYA 1 + 0 bütçe, ama 1 ekstra disk darbe alabilirim?

Artıklık olmadan, bir disk arızalanırsa ve RAID çevrimdışı olursa, RAID yeniden oluşturulana ve tüm veritabanlarınızı sıfırdan geri yükleyene kadar bu düğüm çevrimdışı olur. Bunun gerçekleşmesi için hangi süreci gerçekleştireceksiniz? Veritabanını Kullanılabilirlik Grubu'ndan kaldıramazsınız, çünkü bu DR çoğaltmasını durduracaktır, ancak herhangi bir işlem yapmazsanız, diğer iki sunucu günlük dosyalarını kesemez. Bu tamam mı? Uzun bir haftasonunun Cuma gecesi başarısız olursa ne olur? Hala iyi mi? İkincilleriniz bu miktarda veri birikimi ile başa çıkabilir mi?

Son sorularım, bahsettiğiniz yeniden oluşturma süresi etrafında daha hızlı olacaktır. Daha hızlı olacağından% 100 emin misiniz? Ne kadar hızlı?

Brent Ozar sunucu kurulumu hala yeni SQL örnekleri kurmak için benim kılavuzumdur. Kılavuzdaki ilk nokta, RAID0'ı herhangi bir sürücü için kullanmadığınızı doğrulamaktır.

==== GÜNCELLEME ====

Fazladan bir düşünce, ikincil sunucularınız birincil sunucunuzla senkronize olmadığında ne olur? Eşzamanlı Çoğaltma ile bile, ikincil öğeleriniz otomatik olarak zaman uyumsuzluğa dönebilir ve bir kez yüklendikten sonra herhangi bir yük devretme veri kaybına neden olacağı için otomatik yük devretme yeteneğini kaybedersiniz. Bunun olabileceği birkaç örnek:

1. Çok büyük bir endeksi yeniden oluşturmak - çoğaltma, ikincil bir veya daha fazlasında geride kalabilir
2. İkincil yama yapılırken RAID0'da disk hatası. Düzeltme eki kullandığınız sunucu, birincil çevrim dışı olması nedeniyle tekrar çevrimiçi olamayabilir.

Bunlar uç vakalardır, ancak o zamanlarda kaybedilene bağlı olarak catestrofik olabilirler.