SQL Server Dosyaları Yerel mi, NAS mı yoksa SAN mı?

SQL Server 2008 ile yeni bir Sunucu kurmalıyım, Ne önerirsiniz, Raid 10 ile bir sunucu veya NAS'daki Dosyalar?

İSCSI ne kullanmalıyım?

SAN ne olacak?

Sunucuda 4Gb RAM var ve bu veritabanı dosyası yaklaşık 2GB.

Kendimi bugün netleştirmek için sunucunun RAID'si yok, bir tür strateji uygulamak zorundayım, böylece bir şey olursa dosyalarımı güvende tutabilirim, bu yüzden Yerel Dosyalar, NAS, SAN'ı ne seçmeliyim? Hangi seçenek en yüksek performansa sahiptir, daha güvenli olan nedir?

NAS

SQL Server için kesinlikle NAS değil. SMB / CIFS, DBMS'yi desteklemek için dosya kilitleme için yeterli desteğe sahip değildir (en azından birkaç yıl önce, 2002-2003 civarı). NFS'nin bunu yaptığını ve bunu bir NFS sunucusundaki Oracle ile yapabileceğinizi unutmayın . Ancak, CIFS paylaşımındaki SQL Server, protokolün sınırlamaları nedeniyle güvenilir değildir. CIFS'ye bağlı paylaşımlara dosya koymanıza bile izin vermeyebilir.

SAN

Bu, RAID denetleyicilerindeki önbellek oldukça büyük çalışma kümelerini emebildiğinden işlem uygulamaları için iyidir. SAN RAID denetleyicileri, özellikle RAID denetleyicisinin bir sunucu kadar güçlü olan çok işlemcili bir kutu olabileceği ileri teknoloji kitlerde, ana bilgisayar tabanlı RAID denetleyicilerinden daha fazla önbelleği destekler.

Çift denetleyicili SAN'lar ayrıca tek bir hata noktası olmayan bir mimariye sahiptir ve sıcak yedekleme için birçok seçenek sunar. Bu onları yönetilebilirlik ve güvenilirlik perspektifinden kazanmalarını sağlar. Bununla birlikte, bunlar, veri işlem hacimleri için pahalı ve kısıtlıdır, ancak bunların bir işlem sisteminde bir sorun olması muhtemel değildir.

Operasyonel sistemler için SAN'lar varsa hemen hemen her zaman en iyi seçimdir. Ayrıca düşük-orta hacimli sistemler çalıştıran birden çok sunucu arasında paylaşılabilirler. Bununla birlikte, teknolojinin kullanılabileceği en küçük sisteme oldukça düşük bir alt sınır koyan bir fiyat etiketi ile birlikte gelirler.

Doğrudan Bağlama

Bazı durumlarda, doğrudan bağlanan depolama en iyisidir. Bir olasılık, sınırlı sayıda fiber kanal bağlantısının, mevcut bant genişliğini üst düzey bir SAS denetleyicisiyle mümkün olandan daha düşük bir seviyede sınırlayacağı bant genişliği kısıtlı akış uygulamalarıdır. Ancak, bunların paylaşılan bir şey mimarisinin en iyi verimi sağlayabileceği çok büyük veri ambarları gibi oldukça uzmanlaşmış uygulamalar olması muhtemeldir .

Aslında, doğrudan bağlanan depolama alanı, birçok nedenden dolayı veri ambarı sistemleri için bir SAN'dan genellikle daha iyidir:

• Veri ambarları, disk alt sistemlerine büyük miktarda geçici yük artışı sağlar. Bu, SAN'daki diğer sistemlerin performansını etkileyebildikleri için SAN'larda oldukça anti-sosyal hale getirir.

• Sözü edilen akış darboğazı.

• Doğrudan bağlanan depolama alanı, SAN depolama biriminden çok daha ucuzdur.

Doğrudan bağlı depolama için başka bir pazar, bir SAN için yeterli para ödemeyecek bir pazara sattığınız zamandır. Bu genellikle KOBİ müşterilerine satılan uygulamalar için geçerlidir. Altı kullanıcıya sahip olacak bir satış noktası sistemi veya uygulama yönetim sistemi için bir SAN muhtemelen aşırıya kaçmıştır. Bu tür durumlarda, bazı dahili disklere sahip küçük bir bağımsız kule sunucusu çok daha uygun bir çözümdür.

Yerel veya SAN performansı korumanın tek yoludur. Bazı durumlarda, daha büyük yazma önbelleği ve paralel disk çıkış yapılandırması nedeniyle SAN yerel diskten daha hızlı olabilir.

Windows paylaşımları üzerinde herhangi bir yüksek performanslı dosya G / Ç yapmaktan kaçının. Verimi önemli ölçüde yavaşlatacak çok miktarda protokol yükü var. Örneğin, yıllar önce WAN üzerinden büyük bir dosya aktarımının Windows paylaşımları üzerinden FTP kullanılarak ~% 50 daha hızlı olduğunu ölçtüm.

NAS kullanmayın.

Yerel kullanın (iyi bir RAID denetleyicisiyle orta vadede Tamam) ancak bütçe izin veriyorsa iyi bir SAN için gidin. Şans ile SAN'ı diğer sistemlerle "paylaşmaya" başlayabilir ve ilk harcamaların çoğunu geri alabilirsiniz.

4GB RAM, özel bir SQL Server olduğu sürece çoğu sistem için iyidir (ve her zaman olması gerekir). Henüz dikkate almadıysanız, PAE / AWE öğeleriyle uğraşmadan kolayca daha fazla RAM atayabilmeniz için 64bit OS ve SQL sunucusunu kullanın.

Ayrıca sanallaştırmayı da düşünün. Bir test sunucusuna mı ihtiyacınız var? Bir dev sunucusu mu? SP1 kurulumunu test ettiniz mi? (Önceki yazı için utanmaz artı: sql-server-in-vmware )

Veritabanı boyutu 2 Gb olduğunda, SAN'ı düşünmek için hiçbir neden yoktur. Bir NAS çalışmaz, yalnızca yedeklemeler için bir NAS kullanmayı düşünmelisiniz, böylece yedekleri verilerinizle aynı makinede saklamıyorsunuz ve site dışı depolama için NAS'dan kopyalar almak kolaydır.

Küçük bir veritabanıyla, RAID 1 veya RAID 10'da yerel diskleri kullanın. Veritabanınız RAM'e sığarsa, GÇ performansı konusunda endişelenmenize gerek yoktur. 64-bit pencereler kullanın ve buraya 8 konser yerleştirin. Bu işletim sistemi için bol miktarda bırakacak ve size büyümek için yer verecektir.

Hem yerel RAID disk hem de fiber bağlantılı SAN kullanan sistemlerle çalışıyorum. SAN, daha yeni ve daha hızlı bir makine olmasına rağmen daha iyi performans gösteriyor. Önemli bir faktör yerel disk düzenleme tek bir sürücü olduğunu düşünüyorum böylece SQL disk I / O işletim sistemi ve takas dosyası ile paylaşıyor. Bu muhtemelen sürüklemeye büyük katkıda bulunuyor.

@Spoulson'un belirttiği gibi, SAN çok daha iyi disk performansı sağlayabilir. Sadece ayrı bir sürücü değil, aynı zamanda çok daha hızlı disk donanımında da.

Bizim durumumuzda, otomatik yük devretme VERITAS SQL Server hizmet grupları için merkezi bir depolama alanı sağladığı için SAN kullanıyoruz. Birincil makine arızalandığında, SAN üzerine monte edilen windows sürücüleri, sıcak yedekleme makinesine yeniden monte edilir ve sunucu oldukça hızlı bir şekilde geri gelir. Tabii ki, bu hizmet kapsamı dışında hizmet grubu yönetimi için VERITAS benzeri bir sistem gerektirir.

Mücadele ettiğimiz tek uyarı SAN disk alanı atamasının muhafazakar bir şekilde ele alınması. Çünkü pahalı bir heves bulaşık yok. Kullandığımız EMC SAN ile, tüm LUN'u boşaltmadan atanmış alanı geri alamazsınız. Ayrılan alanın ihtiyaç duyduğumuzdan daha fazla olduğunu tespit edersek ve bu alanın bir kısmını başka bir LUN için kullanmak istiyorsak, sadece büyük olanı küçültemeziz. Onu bırakıp yeniden atamalıyız. Üretim ortamında bu pek işe yaramaz.

Diğerlerinin önerdiği gibi NAS'dan kaçının. Veri dosyalarınızı bir USB harici sabit sürücüye de koyabilirsiniz.

Küçük bir 2GB veritabanı için bir SAN aşırıya kaçabilir.

Genel olarak, SQL sürücülerinizin başka herhangi bir uygulamayla paylaşılmasını istemezsiniz. Aynı şekilde, dosyalarınızı ne kadar çok dağıtabiliyorsanız, o kadar iyi olur. Yine, açıkladığınız gibi küçük bir veritabanı ile, RAM'de ihtiyacınız olan her şeyi sığdırabileceksiniz, böylece disk performansı daha az faktör olacaktır.

Bununla birlikte, tek bir RAID-10 birimi oluşturmayın ve TÜM veritabanı dosyalarınızı üzerine koyun. Şunun gibi basit bir şeyle başlayabilirsiniz: Veri - 2x 73GB 15K RPM, RAID1 Günlükleri - 2x 73GB 15K RPM, RAID1 Yedeklemeler - tek büyük 7200 RPM veya RAID1'de bir çift

Yükseltme bütçeniz varsa, TempDB için başka bir ayrı birim ekleyin (herhangi bir karmaşık raporlama / analitik sorgu yaparsanız) veya Günlük birimine daha fazla disk verin ve sisteminiz yüksek bir hacimle daha fazla işlem yapıyorsa RAID10 olarak yapılandırın / güncelleştirmeleri.

Bir SAN muhtemelen eşdeğer sayıda sürücü için doğrudan bağlı depolama alanının 3-4 katına mal olur. SAN'lar yedekleme / anlık görüntü alma, kümeleme desteği ve LUN taşıma ve genişletme için birçok gelişmiş özellik sunar. Bunlar sizin için önemliyse, ek masrafa değebilir.

Yasal Uyarı: SQL Server veritabanı dosyalarını bir NAS'ta depolamakla ilgili birçok ciddi sorun vardır. Diğer tüm seçenekler eşit olduğundan SAN seçeneğini seçmek doğrudur. İlgili konuların ayrıntılı bir tartışması MS KB304261'de bulunmaktadır . Yine de bu iş parçacığı bir ağ paylaşımında SQL Server ile ilgili diğer sorular için bir catch haline geldi, ben yerine SQL Server sürümlerinde NAS destek durumuna referanslar göndermek istiyorum.

Oldukça az insan NAS'ı MS SQL ile kullanmayı deniyor.

Bu varsayılan olarak yasaklanmıştı, ancak MS SQL 2008 ve MS SQL 2005'teki kısıtlama kaldırılabilir. MS SQL 2008 R2'den beri böyle bir kısıtlama yoktur.

MS SQL 2005 ve 2008'de anahtar, ağ paylaşımlarının kullanımını yasaklayan izleme işaretidir. Biri yayınlayabilir

 DBCC TRACEON(1807, -1)
 CREATE DATABASE [test] ON  PRIMARY 
 ( NAME = N'test', FILENAME = N'\\storage\mssql_db\test.mdf' )

Varun Dhawan'ın MSDN blogundaki Eylül 2010 yayınında daha fazla ayrıntı bulabilirsiniz .

En azından teknik olarak SQL Server'ı bir NAS üzerinde çalıştırmak mümkündür. Seçim birçok faktöre bağlıdır ve bir veritabanı için depolama alanının bir NAS üzerinde hazır olduğu bir durumu hayal etmek zor değildir.