SQL Server'ımdaki RAID dizi SSD sürücülerini nasıl yapılandırmalıyım?

48 GB RAM, 1 CPU ve 8 SATA III (6 GB / s) SSD sürücüler (128 GB Crucial m4) ve bir LSI MegaRAID denetleyicisi (SAS 9265-8i) içeren bir SQL Server oluşturuyorum. Tipik iş yükünün daha çok okunmasını bekliyorum. Bazı daha yoğun yazma etkinlikleri (3. parti veri sağlayıcıları ile saatlik veri senkronizasyonu - gece yedekleri) olacak, ancak tipik okuma / yazma oranının yaklaşık% 90 okuma /% 10 yazma olduğundan şüpheleniyorum.

Seçenek 1:
Mantıksal Sürücü C: - RAID 1 (2 fiziksel sürücü) - OS
Mantıksal Sürücü D: - RAID 10 (6 fiziksel sürücü) - DB dosyaları / günlükleri / tempdb / yedekleri?

VEYA

Seçenek 2:
Mantıksal Sürücü C: - RAID 1 (2 fiziksel sürücü) - OS
Mantıksal Sürücü D: - RAID 1 (2 fiziksel sürücü) - Db Dosyaları
Mantıksal Sürücü E: - RAID 1 (2 fiziksel sürücü) - günlük dosyaları / yedeklemeler?
Mantıksal Sürücü F: - RAID 1 (2 fiziksel sürücü) - tempdb

VEYA

Seçenek 3:
Diğer öneriler?

Seçenek 2 bana daha iyi bir performans verecek düşünüyorum, çünkü tüm DB etkinliği 3 sürücü (ve dizideki diğer 3 arasında yansıtılmış) çizgili olacaktır, ancak seçenek 2 geleneksel bilgeliği taklit gibi görünüyor (mekanik daha fazla gibi görünüyor) SSD'lerden daha fazla sürücü). Stack Overflow seçenek 1 ile gitmiş gibi görünüyor .

SSD'lerle tahmin ediyorum, sunucunuz muhtemelen bu noktada G / Ç kısıtlaması yerine daha fazla CPU kısıtlı olduğundan, her şeyi tek bir mantıksal sürücüye koymak sorun değil mi?

Başka bir sorum var, gece yedeklerini nereye koymalıyım? Yedeklemelerin SQL sunucusunun geri kalanını yavaşlatmasını istemiyoruz ve her iki durumda da okuma / yazma davranışı sıralı yazmalar olduğu için yedekleri günlüklerle aynı konuma yazmak iyi bir uygulamadır.

RAID hakkındaki geleneksel bilgelik SSD'ler için geçerli değildir. Gerçekten şeritlemeye (RAID0) ihtiyaç duymazlar. Bunlar tasarımdan kaynaklanan arızaları eğilimli olmakla RAID-1 genellikle iki nedenle SSD için doğru cevap değil: a) savurgan olduğunu yarıları SSD dizinin kapasitesi (ve onlar vardır pahalı) ve 2) SSD'lerin başarısızlık karakteristikleri potansiyel müşteriler doğru hem aynaya sürücüler (yani. bağıntılı arızaları) çok yakın aralıklarla başarısız ve böylece tüm dizi faydasız hale. Daha uzun bir tartışma için bkz. Diferansiyel RAID: SSD Güvenilirliği için RAID'i Yeniden Düşünme . Bazıları SSD'ler için Raid-6 kullanmanızı tavsiye etti .

Ayrıca, geleneksel SQL Server dosya düzeni bilgeliği SSD'ler için geçerli değildir. SSD'lerde SQL'i izlemenizi öneririm : Hot and Crazy Love ve bu cevapta kıyaslama bağlantılarını gözden geçirin .

Veriler için rasgele IO kalıplarını günlüklerin sıralamasından ayırmanın standart yaklaşımı SSD'ler için geçerli değildir, bu nedenle seçenek 1'i uyarılarla seçerim:

• Yedeklemeler ayrı bir makinede OLMALIDIR. Sunucunun duman çıkması durumunda erişemediğiniz yedeklere sahip olmanın çok az bir anlamı vardır.
• Veri dizisinin ve veri sürücülerinin ayrılmasında, veri dizisinin başarısız olması, günlük yedekleme kuyruğu almanıza izin verecek bir değer vardır.
• Etkin yedeğiniz olmadığına dikkat edin.
• Tüketici düzeyinde sürücülerinizin olduğunu unutmayın. Maliyetin katında işletme eşdeğerleri kadar güvenilir olacaklarını varsaymayın.
• Brent Ozar'ın SSD'lerle ilgili eğlenceli ve çok bilgilendirici SQL'i izleyin : Hot and Crazy Love .

Günlükleri SSD'lerin kullanıldığı verilerden ayırma sorunu, performanstan ziyade sistem için bir RPO (kurtarma noktası hedefi) meselesidir. RPO dakika olarak tanımlanmışsa, bir paylaşılan dizi ile gidin ve her [RPO] dakikada bir günlük yedekleri alın. RPO saniye olarak tanımlanmışsa, ayrı dizilerle devam edin.

Dürüst olmak gerekirse, RPO sıkı olsaydı, veri dizisi için SSD'leri tutardım ve günlük için yansıtılmış bir çift pahalı (kurumsal) güvenilir iplikçi kullanırdım.

Aşağıdaki gibi seçenek 2 ile gitmelisiniz:

Logical Drive - RAID 1 (2 physical drives)
 1 partition C: OS
 2 partition D: backups / log files
Logical Drive E: - RAID 1 (2 physical drives) - DATA files
Logical Drive F: - RAID 1 (2 physical drives) - INDEX files
Logical Drive G: - RAID 1 (2 physical drives) - tempdb

Verilerinizi ve dizinlerinizi daha sonra 2 farklı fiziksel mantıksal sürücüde saklanan 2 farklı veri dosyasında ayırarak, disk io'da büyük bir artış elde edersiniz, çünkü sorguladığınızda tablo verileriniz için bir disk ve başka bir disk döndürürsünüz. dizininiz için aynı anda dönüyor.

Tempdb'i yedeklerinizden ayrı tutun, çünkü orada da çok fazla şey olur. Yedeklemelerinizi ve veri dosyanızı karıştırmayın. yedeklemeler günlük olarak yapılmasa da, gerçekleştiklerinde IO'nuza büyük bir darbe alırlar. İşinize ve veritabanınızı kullanmanıza bağlı olarak, bazı kişiler veya bir çok kişi yedekleme süresi içinde şikayet edebilir.

Bu yardımcı olur umarım