Perdenin arkasındaki SAN'a hiç dikkat etme


35

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 bölgedeki diğer kullanıcıları etkileyebileceği için yük testlerinde dikkatli olmalısınız - bu benim çevremdeki tecrübemdi.
Sam

Yapabilseydim, bu başlık için sana fazladan bir oy verirdim.
splattne

Yanıtlar:


16

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.


re: ayrı sürücüler Sunucumuzu hatırladım, bazı os seviyesi disk kuyrukları nedeniyle bunun performansı hızlandıracağını söyledim.
Sam,

6

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.


+1 kabul etti ve bu yüzden büyük bir EMC SAN ile bile tüm SQL sunucularım doğrudan bağlı depolama kullanıyor; bir değişkeni performans denkleminden siler. Tutarlı bir performans beklentisini seviyorum, paylaşılan bir ortamda elde edemeyeceğiniz bir şey.
SqlACID

Bir SAN kullanmamayacağımı söylemediğime dikkat edin. İşe yarayacak oldukça büyük veri merkezlerinden bazılarını denetledim. Daha önemlisi, IO'nun farklı seviyelerde nasıl çalıştığını daha iyi anlayabilmek ve birlikte iyi çalıştıklarından emin olmaktır.
Jauder Ho

Detaylı cevap için teşekkürler. Şu anda belirli (ölçülen) performans endişelerim olmadığını unutmayın . Birkaç sunucuda bazı temel kıyaslama için bir plan yapmaya çalışıyorum, çünkü bunları rutin olarak izlemiyoruz. Verileri desteklemeden elde eden "SAN ekibinin her şeyi kontrol altında tuttuğu" elle verilen yanıttan dolayı giderek daha rahatsız oldum. Ayrıca her şeyin her zaman en hızlı seçenek olmadığını bildiğim RAID 5 olarak yapılandırıldığını öğrendim.
BradC

Genel olarak, el dalgalanması genel olarak kötüdür =) Herhangi bir performans çalışmasında, her zaman bununla ilişkili ölçülebilir numaralar bulunmalıdır. RAID5 genel olarak DB iş yükü için kötü bir fikirdir. Ama bu sadece benim düşüncem.
Jauder Ho

Bunu daha önce HP EVA SAN'larla ilgili olarak görmüştüm (IIRC, bunlar aslında yeniden Hitachi kitidir). SAN'la ilgili performans sorunları yaşıyorsanız, doğrudan bağlı depolama ile bir referans sistemi bulmanızı ve her iki platformda da bazı açıklamaların thrash testini yapmanızı öneririm. Günlükleri, bir veritabanı üzerinde potansiyel bir darboğaz vardır. Genellikle bunların ayrı (ve sessiz) bir birime sahip olması en iyisi olarak görülür. Bu SAN'daki performans sorunlarını yük altında görmeyeceğinizden şüpheliyim, ancak denetleyicilerdeki büyük önbellek çoğu durumda G / Ç'yi düzgünleştirmelidir.
ConcOedOfTunbridgeWells

5

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.


1

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.


1

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 .


İlginç. Her bir Oracle db için SAN'daki özel sürücülerde her zaman ısrar ediyor.
BradC
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.