Perdenin arkasındaki SAN'a hiç dikkat etme

Bir zamanlar kendi SQL sunucularını kurdum ve sürücü yapılandırmasını, RAID seviyelerini vs. kontrol ettim. Verilerin, günlüklerin, tempdb'nin, yedeklemelerin (bütçeye bağlı olarak!) Ayrılmasının geleneksel tavsiyesi her zaman oldukça önemli bir parçasıydı. SQL server tasarım sürecinin.

Artık şirket düzeyinde bir SAN ile veri, yedeklemeler ve dosya paylaşımları için mantıksal sürücülere bölünmüş yeni bir SQL sunucusu için belirli bir miktar sürücü alanı istiyorum. Kesinlikle işimi kolaylaştırıyor, ancak gerçekten orada olup bitenleri görmek için gerçekten "perdenin arkasına" bakamadığım için kendimi tamamen rahat hissetmeyen bir parçam var.

Anladığım kadarıyla, SAN takımı farklı "tür" sürücüleri farklı şekilde yapılandırmıyor (veri sürücülerini rasgele erişim için veya veri akışı için günlük sürücüler için optimize ediyor). Bunların bir kısmı SAN ürününün kendisine bağlı olabilir (bizde bir HP XP12000 ve bir HP XP24000 var), ancak HP yazılımının her türlü dinamik performans yapılandırmasını yaptığından (IO sıcak noktalarını izleyerek ve anında Bu LUN'ları optimize et), böylece uygulama ekipleri ve DBA'ların bu konulardan endişelenmesine gerek kalmaz. "Tüm sunucuların yükünü çok sayıda iğ üzerine yaymak" veya bunun gibi bir şey.

Sorularım / tartışmam:

1. SAN ekibine düşman yapmadan kendime ve uygulama geliştiricilere SQL sunucularımızın kötü yapılandırılmış depolama sorunlarından muzdarip olmadığından nasıl emin olabilirim? Sadece perfmon istatistiklerini kullan? Sqlio gibi diğer kıyaslamalar?

2. Bu SAN sürücülerine test yüklersem, bu gerçekten yaşadığımda göreceklerimin güvenilir ve tekrarlanabilir bir ölçümünü sağlıyor mu? (SAN yazılımının zaman içindeki farklı noktalarda farklı şekilde "dinamik olarak yapılandırılabileceğini" varsayarak).

3. SAN'ın bir bölümündeki ağır GÇ (Exchange sunucusu) SQL sunucularımı etkiler mi? (her sunucuya ayrı ayrı diskler vermediklerini varsayarsak, bana söylenmemiş)

4. Farklı fonksiyonlar için mantıksal sürücülerin ayrılmasını talep etmek mantıksal sürücüler (data vs log vs tempdb) burada yardımcı olabilir mi? SAN bunlar üzerinde farklı IO faaliyetlerini görür ve bunları farklı şekilde yapılandırır mı?

5. Şu an biraz boşluk gibiyiz. Uygulama ekiplerine veri arşivlerini vb. Kırpmaları söyleniyor. Alandaki endişeler SAN ekibinin sunucumun performansını etkileyebilecek dahili depolamayı (RAID düzeyleri vb.) Nasıl yapılandırdıkları konusunda farklı kararlar vermesine neden olur mu?

Düşünceleriniz için teşekkürler ( bu SF sorusunda kısaca tartışılan benzer konu )

SAN ekibine düşman yapmadan kendime ve uygulama geliştiricilere SQL sunucularımızın kötü yapılandırılmış depolama sorunlarından muzdarip olmadığından nasıl emin olabilirim? Sadece perfmon istatistiklerini kullan? Sqlio gibi diğer kıyaslamalar?

Kısacası, gerçekten emin olmanın bir yolu yoktur. Söyleyeceğim şey, bir SAN yöneticisiyim, eğer uygulamalarınız beklentilerinizi karşılıyorsa, endişelenmeyin. SAN / Disk G / Ç performansı ile ilgili olabileceğine inandığınız performans sorunlarını görmeye başlarsanız, sormanız akıllıca olabilir. Sizin gibi çok fazla HP depolama alanı kullanmıyorum, ancak IBM / NetApp dünyasında, deneyimden şunu söyleyebilirim ki, "kötü bir şekilde" yapılandırmanıza izin verecek birçok seçenek bulunmuyor. Bugünlerde çoğu kurumsal depolama, baskın dizileri oluşturmaktan çok fazla tahminde bulunmakta ve bunu yanlış yapmanıza gerçekten izin vermemektedir. Aynı hızda sürüş hızlarını ve kapasitelerini karıştırmazlarsa, çoğu durumda diskinizin iyi çalıştığından emin olabilirsiniz.

Bu SAN sürücülerine test yüklersem, bu gerçekten yaşadığımda göreceklerimin güvenilir ve tekrarlanabilir bir ölçümünü sağlıyor mu? (SAN yazılımının zaman içindeki farklı noktalarda farklı şekilde "dinamik olarak yapılandırılabileceğini" varsayarak).

Yük testi çok güvenilir olmalıdır. Bir kutuyu test ederken, paylaşılan bir SAN / Disk Dizisi üzerinde olmanın, aynı depolama alanını kullanan diğer sistemlerden etkilenebileceğini (ve etkileyeceğini) unutmayın.

SAN'ın bir bölümündeki ağır GÇ (Exchange sunucusu) SQL sunucularımı etkiler mi? (her sunucuya ayrı ayrı diskler vermediklerini varsayarsak, bana söylenmemiş)

Yapabilir. Her şey disklerle ilgili değil veya sunucuların açık olduğu disklerle ilgili değil. Verilerin tümü bir disk denetleyicisi ve ardından bir SAN düğmesi ile sunuluyor. Büyük ölçüde göreceğiniz performans, disk denetleyicisinin nasıl bağlandığı ile ilgili disk raflarına ve ilgili SAN'a bağlıdır. Dizinin tamamı, 4 gb / sn fiberden bir tek iplikçikteki omurga SAN'ına bağlanırsa, performans açıkça etkilenir. Dizi, yüke karşı dengeli iki yedek SAN'a bağlanmış, bağlantı verilen bağlantılar kullanılarak bağlanmışsa, yalnızca değişimin çok fazla bant genişliğini emmesi imkansız olur. Dikkate alınması gereken bir başka şey, dizinin kaç IO / sn kapasitesine sahip olabileceğidir. Dizi ve bağlı olduğu SAN doğru şekilde ölçeklendiği sürece,

Farklı fonksiyonlar için mantıksal sürücülerin ayrılmasını talep etmek mantıksal sürücüler (data vs log vs tempdb) burada yardımcı olabilir mi? SAN bunlar üzerinde farklı IO faaliyetlerini görür ve bunları farklı şekilde yapılandırır mı?

Bu muhtemelen bir tercih meselesidir ve büyük ölçüde depolama yöneticilerinizin onu nasıl yapılandırdığına da bağlıdır. Aynı dizide veya hacimde üç LUN verebilirler, bu durumda yine de hepsi aynıdır. Size farklı dizilerde, farklı hacimlerde (fiziksel olarak farklı disklerde) bireysel LUN'lar verdilerse, onları ayırmanız sizin için faydalı olabilir.

Şu an biraz boşluk gibiyiz. Uygulama ekiplerine veri arşivlerini vb. Kırpmaları söyleniyor. Alandaki endişeler SAN ekibinin sunucumun performansını etkileyebilecek dahili depolamayı (RAID düzeyleri vb.) Nasıl yapılandırdıkları konusunda farklı kararlar vermesine neden olur mu?

Depolama yöneticinizin, yer açmak için baskın seviyesini değiştireceğini sanmıyorum. Olursa, muhtemelen kovulmalı. Alan kaygıları, işleri farklı şekilde yapılandırmaya yönlendirebilir, ancak performansı etkileyici bir şekilde normal şekilde değil. Sadece size ne kadar yer verdikleri konusunda biraz daha sıkı olabilirler. İşlemin çalışması sırasında dizinin performansını engelleyebilecek, ancak günün her saati değil, veri çoğaltma (dizi destekliyorsa) gibi özellikleri etkinleştirebilirler.

SAN ekibinin, uygulamanızın etkin nokta olup olmadığını ortaya çıkarmanıza yardımcı olacak araçlara sahip olması gerekir. Açıkçası, sonunu da izlemeli ve ölçmelisin.

Deneyimlerimin çoğu EMC'de yani YMMV'de. Ancak, çoğu SAN ekipmanı için aşağıdakiler geçerli olmalıdır.

Diziye girecek çok fazla sayıda bağlantı noktası var. Bazen bölgeleri tanımlayabileceğiniz bir SAN anahtarı vardır. Dizinin temelde büyük bir depolama havuzu olması, GÇ performansı konusunda endişelenmemeniz gerektiği anlamına gelmez.

Yani, GÇ sorunlarınız olduğunu düşünüyorsanız, darboğazın nerede olduğunu daraltmanız gerekir. HBA ile dizi arasında bir yerdeyse, HBA'nın maksimuma çıkıp çıkmadığını veya anahtar / dizi tarafındaki SAN bağlantı noktasının abonelikten çıkıp çıkmadığını anlayabilirsiniz. Ek olarak, SAN ekibinin uygulamanız için erişim biçimlerini, hem soğuk hem de sıcakken izlemesini sağlamalısınız.

Açıkçası, altta yatan depolama, bir aradaki farklı önbellek seviyelerinden bağımsız olarak diske vurmak zorunda kalacağınız için hızlı RAID10'a kıyasla yavaş büyük RAID5 çalıştırmanın bir fark yarattığını söylüyor.

HTH. Kazmak biraz zaman alabilir gibi belirli bir sorun varsa beni çevrimdışı ping.

SAN ekibine düşman yapmadan kendime ve uygulama geliştiricilere SQL sunucularımızın kötü yapılandırılmış depolama sorunlarından muzdarip olmadığından nasıl emin olabilirim? Sadece perfmon istatistiklerini kullan? Sqlio gibi diğer kıyaslamalar?

Herhangi bir kıyaslama yapmadan önce bilmeniz gereken ilk şey, kendi iş yükünüzün hangi toleransla çalışması gerektiğine ilişkindir. Bu nedenle, yeni sistemi kontrol etmeden önce kendi malzemelerinizi kıyaslayın. Bu şekilde, en yüksek yükler sırasında (yedekler?) Maksimum 56 MB / sn bastırdığınızı tespit ederseniz, SAN'a bağlı disk dizisinin 'sadece' olanının, simüle edilmiş zirve yükleri altında 110 MB / sn ittiğini öğrenirseniz, limitin G / Ç kanalı olmayacağına dair güvence verdi.

Yeni bir disk dizisini kontrol ederken bu tür performans testlerini yaptım. Yeni dizi, fiber kanal (SCSI) sürücüler yerine SATA sürücüleri kullandı ve ortamımda çalışacağını temin etmek için kendime ihtiyacım vardı. Çok şüpheliydim. Ancak, karakterizasyondan sonra, yeni sistemin daha güvenilir disklerde ölçülen zirveye yetişmek için zirve altında yeterli G / Ç yükü bulunduğunu öğrendim. Beni şaşırttı.

Bu SAN sürücülerine test yüklersem, bu gerçekten yaşadığımda göreceklerimin güvenilir ve tekrarlanabilir bir ölçümünü sağlıyor mu? (SAN yazılımının zaman içindeki farklı noktalarda farklı şekilde "dinamik olarak yapılandırılabileceğini" varsayarak).

SAN bağlı disk dizilerinin paylaşılan doğası nedeniyle, performans hafta boyunca değişkenlik gösterir. Yoğun G / Ç yükünüzün ne zaman olduğunu zaten biliyorsanız, gün içerisinde yoğun G / Ç yükünüzün olduğu bir seri yük testi yapın. Bu şekilde, en çok ilgilendiğiniz dönemlerde ne tür G / Ç yüklerinin kullanılabileceğini daha iyi tanımlayabilirsiniz. Yoğun olmayan zamanlarda yapılan testler, 'hızlı' işlerin nasıl olacağı konusunda bir fikir verecektir, ancak en yüksek test size gerçek sınırları kontrol etme.

SAN'ın bir bölümündeki ağır GÇ (Exchange sunucusu) SQL sunucularımı etkiler mi? (her sunucuya ayrı ayrı diskler vermediklerini varsayarsak, bana söylenmemiş)

Exchange LUN'ları, SQL LUN'larınızla diskleri paylaşıyorsa, kesinlikle olacaktır. XP kullanıyoruz, HP EVA kullanıyoruz, ancak aynı "disk grubu" terimlerini kullanıyorlar. Aynı disk grubundaki LUN'lar diskleri paylaşır ve bu nedenle bu fiziksel aygıtlarda G / Ç için mücadele eder. Bir disk grubuna ne kadar çok disk yerleştirirseniz, dizinin G / Ç ile oynaması için o kadar fazla kıkırdama odası vardır. Diziler (en azından EVA bunu yapıyor ve daha pahalı olan XP'lerin de aynı şeyi yaptığını tahmin ediyorum) mantıksal LUN bloklarını fiziksel diskler arasında sıralı olmayan bir şekilde dağıtıyorlar. Bu, paralelliği artırmak ve disk seviyesindeki G / Ç çekişmesini azaltmak için sık erişilen blok gruplarını dinamik olarak farklı fiziksel cihazlara dağıtan önerinizi yapmanıza izin verir.

Sorulması gereken soru, bu disk grubunun ne kadar G / Ç bütçesine sahip olduğu ve bu LUN'ları kullanan uygulamaların G / Ç için aboneliğinin olup olmadığıdır. Bu, depolama yöneticilerinin takip etmesi gereken bir soru. Exchange için en yüksek G / Ç'nin (muhtemelen yedeklemeler sırasında) SQL yükleriyle çakışmayacağı ve her iki sistemin de bir arada var olabileceği olabilir.

Farklı fonksiyonlar için mantıksal sürücülerin ayrılmasını talep etmek mantıksal sürücüler (data vs log vs tempdb) burada yardımcı olabilir mi? SAN bunlar üzerinde farklı IO faaliyetlerini görür ve bunları farklı şekilde yapılandırır mı?

HP dizileri için, farklı G / Ç modellerini LUN'lar yerine farklı disk gruplarına yerleştirmeniz gerekir . Veritabanı G / Ç kalıpları, örneğin web sunumu erişim kalıplarıyla bir arada bulunmamalıdır. Farklı LUN'lar, farklı disk gruplarında olmadıkça performansınızı önemli ölçüde artırmaz. Aynı disk grubundalarsa, tek gerçek avantaj, disk alt sistemine paralelliği geliştirmek için çekirdekte G / Ç programlaması yapabileceği işletim sistemidir. Bahsedilen...

Yine de, benim anladığım kadarıyla, HP dizileri LUN'lardaki farklı erişim modellerinin farkındadır, ancak gerçek mantıksal bloklara çok dikkat etmektedir. Günlükleri farklı bir LUN'a koymak, bu tür G / Ç trafiğini alacak ve fiziksel disklerdeki mantıksal blokları doğru şekilde sıralama görevini kolaylaştıracak mantıksal bloklara bir sınır koyar.

Şu an biraz boşluk gibiyiz. Uygulama ekiplerine veri arşivlerini vb. Kırpmaları söyleniyor. Alandaki endişeler SAN ekibinin sunucumun performansını etkileyebilecek dahili depolamayı (RAID düzeyleri vb.) Nasıl yapılandırdıkları konusunda farklı kararlar vermesine neden olur mu?

Kesinlikle. Alanınız kısıtlıysa, G / Ç'niz için özel disk grupları almayacaksınız (depolama ortamınız özel kullanımınız için 7TB'lık fiziksel diski tahsis etmeyi haklı çıkaracak kadar büyük değilse, bu durumda ). Raid5 / Raid10 tartışması, büyük ölçüde organizasyonun politikalarına bağlıdır ve sormak en iyi bahistir.

Endişelerinizi gidermek için SAN Ekibinizle ve satıcınızla bir iletişim kutusu açmanızı öneririm. Kendi referans ölçütlerinizi kullanmakta yaşayacağınız sorunlardan biri, testlerinizin, özellikle en yüksek yüklerde, üretimde olanları etkilemeyebileceğidir. SAN'ların çoğunda tonlarca pil destekli önbellek bulunur; bu, çoğu durumda (özellikle sentetik ölçütler çalıştırdığınızda), RAM'e yazdığınız ve tekme performansı aldığınız anlamına gelir.

Ortamınıza ve kullandığınız çözüme bağlı olarak, bazı CE satıcıları, SAN'ı tercih ettiği standartlara göre ayarlamış ve ayarlamış olabilir. Bu düşündüğünden daha fazla olur. Çözümün gereksinimlerinizi karşıladığına emin olana kadar "SAN ekibi her şeyi bilir" kabuğuna dokunmanız gerekecek.

İyi şanslar.

Veritabanları için sane SAN - Bu konuda bir konuşma ile bir zamanlar bir konferansta oldu.

Konuşmanın özeti bu PDF dosyasında veya buradaki yazarların sitesinde bulunabilir .