Birkaç SSD sürücülü SAN mı yoksa eski moda HDD'ler mi?


9

Şirketim ne tür SAN satın alacağını bulmaya çalışıyor. Bu özellikle GÇ kısıtlamalı veritabanı sunucuları içindir (depolama alanı şu anda DAS'tır, ancak tek bir sunucunun sınırına ulaşıyoruz ve kümeleme de eklemek istiyoruz).

Yaklaşık 3000 IOPS uzun vadeli üretecek bir çözüme ihtiyacımız var (şu anda 1000 IOPS civarında zirve yapıyoruz). Veritabanı operasyonlarımızın çoğu küçük okuma / yazmadır. HP mühendisleri ve diğer çevrimiçi kişilerle yapılan görüşmelere dayanarak, RAID 10 yapılandırmasında 24 SAS HD'ye sahip bir HP P2000, bu hızın çok azını ~ 20K $ karşılığında sunacaktır. SAN'ı oluşturmak için denetleyicileri ve diğer öğeleri ekleyin, bizi doğrudan 30.000 dolarlık maksimum bütçemize yerleştirir.

Ancak çevrimiçi olarak, birçok SAS SSD'nin 80.000 IOPS + hızı sağladığını görüyorum. Bunu beklemek gerçekçi mi? Eğer öyleyse, bir P2000 veya benzer bir giriş seviyesi SAN almak ve oraya birkaç SSD atmak gerçekçi olur mu? Veritabanlarımız küçük, toplamda sadece birkaç TB. Bunu yapsaydık, aynalama / yük devretme için ikinci bir SAN satın almak için paraya sahip olurduk, bu ihtiyatlı görünüyor.


3
Buna kısa süre içinde cevap vereceğim.
ewwhite

Kullanmak istediğiniz belirli SAN modeline / tipine bağlanabilir misiniz? HP P2000 tarzı depolama dizileriyle birlikte gelen birçok uyarı vardır. Nasıl bağlanmayı planlıyorsunuz? iSCSI? Lif? SAS?
ewwhite

Ayrıca, bu hangi veritabanı platformu?
ewwhite

İşte farklı bir sürücü yapılandırmasıyla baktığım model: aventissystems.com/product-p/200385.htm . DBMS, SQL Server Standard 2008 R2'dir. İleride "ucuza" ölçekleyebildiğimiz ve mütevazı bütçemizi koruduğumuz sürece hemen hemen her yapılandırma / satıcıya gerçekten açığız.
Bip sesi

Ne kadar kapasiteye ihtiyacınız var?
ewwhite

Yanıtlar:


4

Yapmaya çalıştığınız şeyin özellikleri hakkında konuşabilirim. Dürüst olmak gerekirse, sizin için giriş seviyesi bir HP P2000 / MSA2000 düşünmüyorum.

Bu cihazların birçok sınırlaması vardır ve SAN özellik seti açısından, bir disk kutusundan başka bir şey değildir. Katmanlama yok, akıllı önbellek yok, Sanal Disk grubunda maksimum 16 disk , düşük IOPS özellikleri, zayıf SSD desteği (özellikle seçtiğiniz birimde).

SSD'lerle herhangi bir performans avantajı veya resmi destek görmek için HP MSA2040 ürününe geçmeniz gerekir . Ayrıca, gerçekten iSCSI kullanmak istiyor musunuz?

Yerel depolamayı tolere edebiliyorsanız DAS en iyi seçeneğiniz olabilir. PCIe flash depolama alanı bütçenizin altına gelecek, ancak kapasitenin dikkatle planlanması gerekecektir.

Gerçek sunucularınızın özelliklerini ayrıntılı olarak açıklayabilir misiniz? Marka / model vb.

Kümeleme zorunluysa, başka bir seçenek de HP MSA2040 birimini yapmaktır, ancak iSCSI yerine bir SAS birimi kullanmaktır. Bu, diğer modellerden daha ucuzdur, 4-8 sunucuyu bağlamanızı sağlar, düşük gecikme süresi ve mükemmel iş hacmi sunar ve yine de SSD'leri destekleyebilir. Fiber veya iSCSI modelleriyle bile, bu ünite size bağladığınızdan daha fazla esneklik sağlar.


Teşekkürler! Başta HP DL380'ler olmak üzere tüm HP sunucularımız var. İSCSI'yi düşünmemizin tek nedeni, 4 sunucuyu genişletmenin daha kolay görünmesi (diğer sunucu verilerini SAN'a göndermek istersek) ve biraz daha hızlı olması (10Gb'ye karşı 6Gb).
Bip sesi

Bununla birlikte, MSA2040'a bir bakacağım ... neden daha önce radarımızda ortaya çıkmadığından emin değilim.
Bip bip

Karışıklığı görebiliyorum ... 4 veya 8 sunucunun ötesine geçmeyi planlamıyorsanız, SAS oldukça iyi çalışıyor. Ve 10Gb'ye karşı 6Gb değil ... 10Gb'ye karşı 4 şeritli 12Gbps SAS (kasaya 48Gbps) arayüzü.
ewwhite

Remote Snap yazılımının yalnızca iSCSI veya FC'de çalıştığını gördüm ... sonunda SAN'ı felaket kurtarma için yansıtmak için uzak eki kullanmayı umuyorduk. Yoksa SAS üzerinden aynı kabiliyete izin verecek başka bir süreç var mı?
Bip bip

@Beepbeep Muhtemelen farklı bir DR işlemi kullanırım. Depolama cihazına veya SAN düzeyinde çoğaltmaya güvenmeme eğilimindeyim. Ancak MSA2040'ın 10GbE ve FC sürümleri sizin için daha uygun olabilir.
ewwhite

6

Disk IO için kullandığım başparmak kuralı:

  • SATA için iş mili başına 75 GİB.

  • FC / SAS için iş mili başına 150 IOP

  • SSD için iş mili başına 1500 GİB.

Dizi başına GİB'lerin yanı sıra terabayt başına GİB'i de dikkate alır. SATA + RAID6 yapıyorsa TB oranı başına çok kötü bir GİB ile sonuçlanması nadir değildir. Bu çok fazla gelmeyebilir, ancak genellikle bir dizide 'boş alan' tespit eden ve kullanmak istediğiniz bir kişiyle karşılaşırsınız. Çoğu kurumsal sistemde tam tersi olduğunda, insanların konser alması ve iops'u görmezden gelmesi yaygındır.

Ardından RAID için yazma cezası maliyetini ekleyin:

  • RAID1, RAID1 + 0 için 2
  • RAID5 için 4 (veya 4)
  • RAID6 için 6.

Yazma cezası kısmen güzel büyük yazma önbelleklerini ve doğru koşullarda hafifletilebilir. Çok sayıda ardışık yazma GÇ'niz varsa (DB günlükleri gibi), RAID 5 ve 6'daki bu yazma cezalarını önemli ölçüde azaltabilirsiniz. Tam bir şerit yazabiliyorsanız (örneğin, iş mili başına bir blok), eşitliği hesaplamak için okumak zorunda değilsiniz.

8 + 2 RAID 6 setini varsayalım. Tek bir yazma GÇ için normal çalışmada şunları yapmanız gerekir:

  • 'Güncellenmiş' bloğu okuyun.
  • İlk eşlik bloğunu okuyun
  • İkinci eşlik bloğunu okuyun
  • Eşliği yeniden hesapla.
  • tüm 3'ü yaz. (6 IO).

Önbelleğe alınmış tam şerit yazma ile - örneğin RAID şeridinin 8 ardışık 'parçası' ile bir okumaya gerek kalmadan tüm lottaki pariteyi hesaplayabilirsiniz. Yani sadece 10 yazma gerekir - her veriye bir tane ve iki parite.

Bu sizin yazma cezanızı yapar 1.2.

Ayrıca, IO'nun önbelleğe alınmasının kolay olduğunu aklınızda bulundurmanız gerekir - hemen diske almanıza gerek yoktur. Yumuşak bir zaman kısıtlaması altında çalışır - ortalama olarak gelen yazmalarınız iş mili hızını aşmadığı sürece, hepsi 'önbellek hızında' çalışabilir.

Öte yandan Okuma G / Ç, zor zaman kısıtlaması yaşar - veriler alınana kadar bir okumayı tamamlayamazsınız. Bu noktada okuma önbellekleme ve önbellek yükleme algoritmaları önem kazanır - tahmin edilebilir okuma kalıpları (örneğin yedeklemeden alacağınız sıralı) tahmin edilebilir ve önceden getirilebilir, ancak rastgele okuma kalıpları olamaz.

Veritabanları için genellikle şunları varsaymanızı öneririm:

  • 'veritabanı' ES'nizin çoğu rastgele okunur. (örneğin rastgele erişim için kötü). Ek yükü karşılayabiliyorsanız, RAID1 + 0 iyidir - çünkü yansıtılmış diskler iki okuma kaynağı sağlar.

  • 'log' IO'nuzun çoğu sıralı yazımdır. (ör. önbellekleme için iyidir ve birçok DBA'nın önereceğinin aksine, muhtemelen RAID10 yerine RAID50 kullanmak istersiniz).

İkisinin oranının zor olduğunu söylemek zor. DB'nin ne yaptığına bağlıdır.

Rastgele okuma IO, önbellekleme için en kötü durum olduğu için, SSD'nin gerçekten kendi başına geldiği yer - birçok üretici SSD'yi önbelleğe almayı rahatsız etmiyor çünkü zaten aynı hızda. Bu nedenle özellikle geçici veritabanları ve dizinler gibi şeyler için SSD iyi bir yatırım getirisi sağlar.


Teşekkürler,% 100 RAID10'uz çünkü veritabanlarına odaklandık.
Bip sesi

Bu yaygın, ama aynı zamanda bir yanlışlık. RAID10 aslında öncelikle yazma odaklı iş yükleri için oldukça israftır. Yazılan önbelleğe alınmış RAID5 / RAID6, örneğin veritabanı günlük dosyaları yazmak için daha düşük yazma cezasına sahiptir.
Sobrique

3

Analiziniz oldukça doğru.

Çok sayıda GB için birkaç HDD ve birkaç IOps için çok sayıda HDD kullanın.
Çok sayıda GİB için birkaç SSD ve birkaç GB için çok sayıda SSD kullanın

Hangisi sizin için daha önemli? GB başına fiyat çok daha yüksek olduğundan, alan SSD çözümleri için büyük maliyet sürücüsüdür. 200 GB'lik bir veritabanına ihtiyaç duyulan 4K GİB'lerden bahsediyorsanız, bir çift SSD sizi oraya götürecektir. Veya 15K sürücülerin 24 disk dizisi, toplu depolama için size çok fazla alan bırakır.

Bu SSD'lerden gerçekte kaç tane IOps alacağınız, depolama altyapısına bağlı olarak çok değişkendir (bunun üzerinde ayrıntılı olarak durulacaktır), ancak bu tür hızları elde etmek mantıklıdır. Özellikle paritenin hesaplanmadığı Raid10 ile.


Geri dönüşünüz için teşekkür ederiz! Tahrikleri karıştırmak makul mü? Performansa yönelik görevler için 4 SSD, daha sonra yığın depolama için bir sürü HDD mi kurdunuz?
Bip bip

3
@ Beepbeep Evet, ama ödünleşmeden haberdar ol. Birçok iops denetleyici kaynaklarını tüketir, yani HDD'lerden maksimum ardışık verim elde edemezsiniz. HDD'lerde çok sayıda sıralı işlem, kanal çekişmesi nedeniyle gecikmeyi artıran SSD'lerden IO'yu artırabilir. Bu sizin için önemliyse, ancak farklı kanallarda.
sysadmin1138

0

Geçenlerde işverenim için on iki 2 TB 7200 rpm Western Digital "SE" kurumsal SATA sürücüsüyle FreeBSD 10.1 çalıştıran Dell C2100 şasisini kullanarak bir çift depolama sunucusu oluşturdum. Sürücüler, iki adet 6 sürücülü RAIDZ-2 sanal aygıttan (vdevs) oluşan tek bir ZFS havuzundadır. Havuza bağlı olarak, güç kaybına karşı süper kapak korumalı bir çift Intel DC S3500 SSD vardır, bunlar hem SLOG hem de L2ARC olarak kullanılır. Bu sunucuyu iSCSI üzerinden yüklediğimde 7500-8200 IOPS vurabiliyordum. Sabit diskler dahil toplam maliyetimiz sunucu başına yaklaşık 2700 dolardı.

Bu BSD tabanlı sistemlerin çalıştığı sırada, HP MSA2012i SAN birimlerimizden birinde iki denetleyici hatası yaşandı ve diğer MSA2012i birimimiz, onarılması 12 saatlik kesinti süresi gerektiren büyük bir NTFS birimini bozdu.

Dell ve HP size asla kullanamayacağınız% 10 donanım ve% 90 destek sözü satıyor.


Bu doğru ... Bir parçam, MSA / P2000'den çok daha iyi performans göstereceği için ZFS (veya ZFS tabanlı bir cihaz işletim sistemi) çalıştıran bir HP sunucusu önermek istedim ... ama gitmek istemedim bir teğet üzerinde.
ewwhite

Oh, HP ile bir sorunum yok. HP ve dell mükemmel sunucu donanımı sağlar. Genellikle bazı whitebox iStarUSA veya Norco şasilerinden daha iyi yüklenir. Ancak kritik cihazlar söz konusu olduğunda (kitabımda SAN / NAS kritiktir), olabildiğince şeffaflığa sahip bir çözüm öneriyorum. SAN cihazları büyük kara kutulardır. Yapana kadar harika çalışıyorlar ve sonra dere kalıyorsunuz.
katot
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.