Diskleri işletim sisteminden ayırmak için günlük ve veri dosyalarını ayırmak için standart uygulaması (tempdb, yedekler ve takas dosyası) Ayrıca bu mantık, sürücülerinizin tümü SAN tabanlı olduğunda ve LUNS'niz belirli bir disk veya baskın setinde oyulmadığında anlamlıdır mı? - SAN'daki x sürücü sayısının sadece bir kısmı ve LUN sadece alan tahsisi
Yanıtlar:
Günlükler ve veri sürücüleri, bir sürücüyü paylaştıklarında birbirleriyle çakışan (en azından teoride) farklı veri erişim modellerine sahiptir.
Log Yazıyor
Kayıt girişi, çok sayıda küçük ardışık yazmadan oluşur. Biraz basit bir şekilde, DB kayıtları veri öğelerini diskteki belirli yerlere yazmak için talimatların listesini içeren halka arabellekleridir. Erişim kalıbı, tamamlanması garanti edilmesi gereken çok sayıda küçük ardışık yazıdan oluşur - bu yüzden diske yazılır.
İdeal olarak, günlükler sessiz olmalıdır (başka bir şeyle paylaşılmamalıdır) RAID-1 veya RAID-10 biriminde. Mantıksal olarak, süreci, günlük girişlerini ve günlükleri tüketen ve değişiklikleri veri disklerine yazan bir veya daha fazla günlük okuyucusu iş parçacığı yazan ana DBMS olarak görüntüleyebilirsiniz (pratikte, işlem veri yazmalarına olanak sağlayacak şekilde optimize edilmiştir. mümkünse hemen dışarı. Tomruk disklerinde başka trafik varsa, kafalar bu diğer erişimler tarafından hareket ettirilir ve sıralı log yazmaları rasgele log yazmaları olur. Bunlar daha yavaştır, bu nedenle meşgul kütük diskleri, tüm sistemde bir darboğaz gibi davranan bir sıcak nokta oluşturabilir.
Veri Yazıyor
(güncellendi) Bir işlemin geçerli ve uygun olması için günlük yazmaları diske (kararlı ortam olarak adlandırılır) gönderilmelidir. Bu mantıksal olarak, günlük girişleri yazılmış ve ardından zaman uyumsuz bir işlemle veri sayfalarını diske yazmak için talimatlar olarak kullanılabilir. Uygulamada, disk sayfası yazıları aslında günlük girişi yapıldığı sırada hazırlanır ve tamponlanır, ancak işlemin gerçekleşmesi için derhal yazılmaları gerekmez. Disk tamponları Yavaş yazan işlemiyle stabil medya (Disk) (bu out işaret Paul Randal sayesinde) dışarı yazılır Bu Technet makale biraz geçen daha detaylı.
Bu oldukça rasgele bir erişim şeklidir, bu nedenle aynı fiziksel diskleri günlüklerle paylaşmak sistem performansında yapay bir darboğaz yaratabilir. İşlemin yapılabilmesi için kayıt girişleri yazılmalıdır, bu nedenle rasgele aramalar bu süreci yavaşlatır (rastgele G / Ç, sıralı kütük G / Ç'den çok yavaştır) kütüğü sıradan bir rasgele erişim cihazına dönüştürür. Bu yoğun bir sistemde ciddi bir performans darboğazı yaratır ve kaçınılması gerekir. Aynısı geçici alanları log hacimleriyle paylaşırken de geçerlidir.
Önbelleğe alma rolü
SAN denetleyicileri, rasgele erişim trafiğini bir dereceye kadar emebilen büyük RAM önbelleklerine sahip olma eğilimindedir. Bununla birlikte, işlem bütünlüğü için, tamamlanma garantili bir DBMS'den disk yazması istenir. Bir denetleyici geri yazma önbelleğe almak için ayarlandığında, kirli bloklar önbelleğe alınır ve G / Ç çağrısı ana bilgisayara tam olarak bildirilir.
Bu, önbellek, aksi takdirde fiziksel diske gidecek çok fazla G / Ç'yi emebileceği için bir çok çekişme problemini düzeltebilir. Ayrıca, RAID-5 birimlerinin sahip olduğu performans üzerindeki etkisini azaltan, parite okumalarını ve RAID-5 için yazmayı da optimize edebilir.
'SAN'la başa çıkma' düşünce okulunu yönlendiren özellikler şunlardır: Bu görüşe göre bazı sınırlamalar vardır:
Geri yazma önbelleklemesi hala veri kaybedebilecek arıza modlarına sahiptir ve denetleyici, DBMS'ye liflendi ve blokların aslında olmadığı yerlerde diske yazıldığını söyledi. Bu nedenle, işlem bütünlüğü için geri yazma önbelleği kullanmak istemeyebilirsiniz, özellikle de veri bütünlüğü sorunlarının iş için ciddi sonuçları olabileceği görev kritik veya finansal verileri tutan bir şey.
SQL Server (özellikle), bir bayrak (FUA veya Zorla Güncelleme Erişimi olarak adlandırılır) çağrı geri dönmeden önce diske fiziksel yazmaya zorlayan bir modda G / Ç kullanır. Microsoft bir sertifika programına sahiptir ve birçok SAN satıcısı bu semantikleri onurlandıran donanımlar üretir ( burada özetlenen gereksinimler ). Bu durumda cache miktarı ne olursa günlük trafik demek olduğunu, disk yazma, optimize edecek edecek yoğun bir paylaşılan hacmi üzerinde bulunuyorsa, thrash.
Uygulama çok fazla disk trafiği oluşturursa, çalışma kümesi önbelleği aşabilir ve bu da yazma çekişmesi sorunlarına neden olabilir.
SAN başka uygulamalarla (özellikle aynı disk biriminde) paylaşılıyorsa, diğer uygulamalardan gelen trafik günlük darboğazları oluşturabilir.
Bazı uygulamalar (örn. Veri ambarları) SAN'larda oldukça anti-sosyal kılan büyük geçici yük artışları üretiyor.
Büyük bir SAN'da bile, ayrı kütük hacimleri hala uygulamada önerilir. Hafifçe kullanılan bir uygulamadaki düzen hakkında endişelenmemekle kurtulabilirsiniz. Gerçekten büyük uygulamalarda, birden fazla SAN denetleyicisinden bile yararlanabilirsiniz. Oracle, daha büyük yapılandırmaların bazılarının birden fazla denetleyiciyi içerdiği bir dizi veri ambarı yerleşim durumu çalışması yayınlamaktadır.
Ait olduğu performansın sorumluluğunu üstlenin
Büyük hacimli veya performansın sorun olabileceği bir konuda, SAN ekibini uygulamanın performansından sorumlu hale getirin. Yapılandırma konusundaki önerilerinizi görmezden geleceklerse, yönetimin bunun farkında olduğundan ve sistem performansı sorumluluğunun uygun yerde bulunduğundan emin olun. Özellikle, G / Ç bekleri veya sayfa mandalı bekleri veya kabul edilebilir uygulama G / Ç SLA'ları gibi temel DB performans istatistikleri için kabul edilebilir kurallar oluşturun.
Performansın birden fazla takım arasında paylaştırılması sorumluluğuna sahip olmanın, parmak uçlarına teşvik etmeyi ve parayı diğer takıma geçirmesini sağladığını unutmayın. Bu bilinen bir yönetim karşıtı kalıp ve hiç çözülmeden aylarca ya da yıllarca süren sorunlar için bir formül. İdeal olarak, uygulama, veritabanı ve SAN yapılandırma değişikliklerini belirtme yetkisi olan tek bir mimar bulunmalıdır.
Ayrıca, sistemi yük altında kıyaslayın. Düzenleyebilirseniz, ikinci el sunucular ve doğrudan bağlantı dizileri Ebay'den oldukça ucuza satın alınabilir. Bir veya iki disk dizisi ile böyle bir kutu kurarsanız, fiziksel disk yapılandırması ile frig yazabilir ve performans üzerindeki etkisini ölçebilirsiniz.
Örnek olarak, büyük bir SAN (bir IBM Shark) üzerinde çalışan bir uygulama ile doğrudan takılan U320 dizisine sahip iki soketli bir kutu arasında bir karşılaştırma yaptım. Bu durumda, ebay'dan satın alınan 3.000 £ değerinde donanım, kabaca eşdeğer CPU ve bellek konfigürasyonuna sahip bir ana bilgisayar üzerinde iki kat faktör ile 1 milyon £ 'luk bir yüksek seviye SAN'ı geride bıraktı.
Bu olaydan, böyle bir şeye sahip olmanın SAN yöneticilerini dürüst tutmanın çok iyi bir yolu olduğu söylenebilir.
Equallogic etiketinin ve isteğin içeriğinin bir Equallogic SAN hakkında endişelendiğiniz anlamına geldiğini farz ediyorum. Aşağıdakiler özellikle Equallogic ile ilgilidir ve diğer SAN tipleri için geçerli değildir.
Equallogic dizileriyle, birimler için kullanılan özel diskler EMC Clariion dizileriyle olduğu kadar kesin bir şekilde belirtilemez, bu nedenle yaklaşımın biraz farklı olması gerekir.
Equallogic mimarisi çok otomatik ve dinamiktir. Temel yapı bloğu, diğer SAN'larda görüldüğü gibi bir dizi içindeki RAID paketleri \ gruplarının olmadığı dizi birimidir. Her dizi, RAID 5, 6, 10 veya 50 için tamamen yapılandırılmıştır, ancak bu, dizi başına yalnızca bir RAID grubu olduğu anlamına gelmez, bu seviyeye asla karar veremez veya onlarla etkileşime giremezsiniz. Dizileri Depolama havuzlarına koyarsınız ve havuzlarınız daha sonra bir Depolama Grubuna aittir. Depolama Grubu, o gruptaki tüm birimler için iSCSI Keşif hedefi olarak kullandığınız bir cluster \ virtual ip adresine sahiptir - EQL Group yönetim yazılımı ve ana bilgisayar MPIO yığını, gerçekte en uygun bağlantı noktasına yönlendirmek için gereken ip düzeyi yeniden yönlendirme işlemini gerçekleştirir. Bireysel veri blokları talep ederken bireysel diziler ancak bu, kontrol edemediğiniz veya kontrol edemediğiniz bir şeydir.
Depolama birimleri, her havuzdaki toplam boş alandan atanır. Bir havuzdaki tüm hacimler, ağ IO'yu toplam ağ arayüzü sayısı (modele göre Eql dizisi başına 2-4) ve IO'ya dağıtmak için o havuzdaki tüm dizilere (en fazla 4 ayrı diziye kadar) yayılır. mümkün olduğu kadar çok sayıda kontrolör arasında. Equallogic yönetim yazılımı zaman içindeki hacim \ dizi performansını izler ve blokların üye diziler arasında dağıtımını dinamik olarak optimize eder. Genel olarak, ne yaptığınızı bilmiyorsanız, tüm dizileri tek bir havuza koymanız ve RAID 10 ile yüksek hızlı disklerinizi (SAS 10k \ 15k) RAID 10 ile orta hızda RAID 50 ile yapılandırmanızı sağlamak için bir şey yapmasını sağlamanız gerekir. veya 5, optimizasyon işleminin gerçekten de yüksek performanslı sürücüleri seçtiğinden emin olmak için.
Kaba bir yaklaşım için, sürücü tipine ve RAID tipine bağlı olarak PS dizisi başına 2500-5000 GİB arasında bir yere sahip olacaksınız. Yeterli toplam GİB sağlarsanız, o zaman tüm hacimleri tek bir havuza topladığınızda bile, otomatik yönetim süreci sonunda size iyi bir performans göstermelidir.
Ancak, günlüklerinizin, veritabanlarınızın, geçici mağazalarınızın, işletim sisteminizin vb. Gerçekten birbirinden izole edildiğini garanti etmek istiyorsanız, birkaç şey yapabilirsiniz. İlk olarak, belirli bir birimin her zaman yalnızca bu RAID türündeki dizilere depolanmasını garanti edecek bir birim için RAID tercihini tanımlayabilirsiniz (havuzun içinde bulundukları havuzda mevcutsa). İkincisi, yalnızca söz konusu katman için istediğiniz çeşitli performans derecelerini sağlayan dizileri içeren ve ardından hacimlerinizi uygun havuzlara dağıtan diziler içeren katmanlı depolama havuzlarını tanımlayabilirsiniz. Bu yaklaşımla gelen sağlık uyarısı, genel olarak daha iyi bir genel performans sağlamak için genellikle çok fazla diziye ihtiyaç duyacağınızdır - bu sizin kritik hacimlerinizdeki performansı güvence altına almaktan daha az önemli olabilir; tercih. Dell'in Oracle DB'ler için referans mimarisi, Veri, Oylama diski ve OCR için 2 RAID 10 dizili bir havuz ve Flash Kurtarma Alanı için tek bir RAID 5 dizisine sahip ayrı bir havuz kullanır.
Equallogic ile zamanın her noktasında, zorla bölümlendirmeyle ilgili aldığınız kararların mevcut ağ arayüzleri, disk milleri ve kontrolörler açısından hacimleriniz için daha iyi toplam performans sağlayıp sağlayamayacağını kendinize sormalısınız. Buna cevap veremiyorsanız, minimum sayıda havuzu seçin ve detayları açık bırakın ya da gerçek bir tasarım yapmak için bir Equallogic uzmanı edinin. Yalnızca bir diziniz varsa, ciltleri ayırma konusunda yapabileceğiniz hiçbir şey yoktur.
DB'lerimizi tek SAN kutularında saklıyoruz, ancak her biri farklı disk gruplarında ayrı veri, günlük ve yedekleme LUN'ları var; hızları katmanlı - RAID 10 15Krpm LUN'lar, RAID 1 10 / 15krpm LUN'lar üzerindeki veriler ve RAID üzerine yedekleriz. 5,2 kr / dk LUN. Ayrıca aynı SAN üzerindeki farklı denetleyiciler aracılığıyla günlükleri ve verileri sunuyoruz.
Harika soru!
Öncelikle bu konuda Brent Özar'ın "Çelik Kafes BlogMatch" tartışmasına bir göz atın .
Şirketimizde çoğu sunucu için aynı SAN sürücüsüne Veri ve Günlükleri koyar ve her şeyin doğru çalıştığından emin olmak için SAN ekibine bırakırız.
Bunun özellikle yüksek hacimli sunucular için en iyi strateji olmadığını düşünmeye başladım. Temel problem, SAN ekibinin ihtiyaç duyulan alan için yeterli diskleri bir araya getirmekten başka bir şey yapmadığını doğrulamak için gerçekten bir yolum olmaması. SAN sürücülerine karşı IO benchmarklarını bizim tarafımızdan veya herhangi bir şeyden çalıştırmıyoruz, sadece biraz saf olan "işlerini yaptıklarını" (alan yanı sıra performans için de ayarladıklarını) varsayıyoruz.
Diğer düşüncem, günlükler ve günlüklerin ihtiyaç duyduğu erişim türünün farklı olduğudur. Geçenlerde okuduğum makaleyi iki farklı sürücü tipinin gerçekten çok farklı şekillerde nasıl optimize edilmesi gerektiği hakkında konuşmaya çalışacağım (birinin ardışık yazmalar için optimizasyona ihtiyacı olduğunu düşünüyorum. .)
Kısacası, evet, SQL Server veri dosyaları, günlük dosyaları ve TempDB verileri ve günlük dosyaları için ayrı birimler oluşturacaksınız.
Sorunuzu Equallogic ile etiketlediğiniz için, lütfen ücretsiz Dell Referans Mimari Kılavuzu'nu okuyun: Çözümünüzü tasarlamadan önce Microsoft® SQL Server®'ı Dell ™ EqualLogic ™ PS5000 Serisi Depolama Dizileri (kayıt gerekir) ile dağıtma . Genellikle , belirli konfigürasyonlar hakkındaki rehberliğin, genel tavsiyelerden önemli ölçüde farklı olabileceğini göreceksiniz .
Performans açısından BradC (+1) ile aynı fikirdeyim. Genel olarak, iyi bir SAN kullanmak beklediğinizden daha fazla ham I / O'ya sahip olacaktır.
YEDEKLERİNİZİ canlı sisteminizden ayırmak hala iyi bir fikirdir (Açıkçası biliyorum, ama bunu her gördüğümde £ 1 varsa bunu ...
Ayrıca, tempdb'yi günlük dosyalarından uzak tutmanız önerilir. Kayıtlar, Veri ve Sıcaklık için "farklı kovalar" (teknik terim) istemeye başladığınızda, SAN adamının çadırı size gözlerini devirecek, ancak onlara söylerseniz, her bölgeye giden farklı veri miktarlarını ölçebilirsiniz. size onların fantezi performans grafiklerini göstermelerini sağlayın!
SAN adamının sizin için doğru şekilde ayarladığını kontrol edin. Eğer RAID 10'u istiyorsanız, RAID 5'in performans cezası olmadığını söyleyip durdukları halde ısrar ettim (ben yaptım).
("Dosya tabanlı" işlemler için RAID 5 gayet iyi. Yoğun yazma için, yazma tamponunu doldurur doldurmaz vidala!)
Buradaki terimlerin bütün karışımlarından haberdar olun.
Genellikle ve çok basit:
Aynı dizide birkaç cilde sahip olabilirsiniz, bu konuda tartışılan yüksek dereceli optimizasyonları yaparken hatırlamanız gereken bir şey.
Anahtar, başkalarının söylediği şeydir (unutma), sadece ayrı hacimlerde değil, farklı sürücü millerinde veri / log / yedeklemeyi ayırın.
Düzenleme: Yukarıdaki Helvick, Equallogic SAN'lar hakkında size harika bir cevap verdi!