SQL Server Files LocalまたはNASまたはSAN？

SQL Server 2008を備えた新しいサーバーをインストールする必要があります。Raid10またはNAS内のファイルを備えた1つのサーバーをお勧めしますか？

iSCSIについてはどうすればいいですか？

SANはどうですか？

サーバーには4GbのRAMがあり、そのデータベースファイルは約2GBです。

今日、サーバーにRAIDがないことを明確にするために、何らかの戦略を実装する必要があります。何か問題が発生した場合、ファイルを安全に保管できます。ローカルファイル、NAS、SANを選択する必要があります。どのオプションが最もパフォーマンスが高く、どのオプションがより安全ですか？

NAS

SQL Server用のNASではありません。SMB / CIFSは、DBMSをサポートするためのファイルロックを適切にサポートしていません（少なくとも数年前、約2002-2003年はそうでした）。NFS はそうであり、NFSサーバー上のOracleで実際にこれを行うことができることに注意してください。ただし、プロトコルの制限により、CIFS共有上のSQL Serverは信頼できません。CIFSでマウントされた共有にファイルを配置することさえできません。

さん

RAIDコントローラーのキャッシュは非常に大きなワーキングセットを吸収できるため、これはトランザクションアプリケーションに適しています。SAN RAIDコントローラーは、通常、ホストベースのRAIDコントローラーよりも多くのキャッシュをサポートします。特に、RAIDコントローラーがサーバーと同じくらい強力なマルチプロセッサボックスであるハイエンドキットではそうです。

また、デュアルコントローラーを備えたSANは、単一障害点のないアーキテクチャを備えており、ホットバックアップの多くのオプションを提供します。これは、管理性と信頼性の観点から彼らを勝利にします。ただし、それらは高価であり、ストリーミングデータボリュームには制約がありますが、後者はトランザクションシステムでは問題になりそうにありません。

運用システムの場合、ほとんどの場合、SANが最良の選択です。また、低中ボリュームシステムを実行している複数のサーバー間で共有することもできます。しかし、彼らは技術が使用できる最小のシステムにかなり実質的な下限を置く値札が付いています。

直接接続

場合によっては、直接接続ストレージが最適です。1つの可能性は、帯域幅が制限されたストリーミングアプリケーションです。このアプリケーションでは、ファイバーチャネル接続の数が限られているため、利用可能な帯域幅がハイエンドSASコントローラーで可能な帯域幅よりも少なく制限されます。ただし、これらは、シェアードナッシングアーキテクチャが最高のスループットを提供するような非常に大きなデータウェアハウスなど、かなり特殊なアプリケーションである可能性があります。

実際、多くの理由から、データウェアハウスシステムの場合、直接接続ストレージはSANよりも優れていることがよくあります。

• データウェアハウスは、ディスクサブシステムに大きな一時的な負荷スパイクを与えます。これは、SAN上の他のシステムのパフォーマンスに影響を与える可能性があるため、SANで非常に反社会的です。

• 前述のストリーミングのボトルネック。

• 直接接続ストレージは、SANストレージよりもかなり安価です。

直接接続型ストレージのもう1つの市場は、SANに十分なお金を払わない市場に販売する場合です。これは、SMBの顧客に販売されるアプリケーションによく当てはまります。6人のユーザーがいるPOSシステムまたは実務管理システムの場合、SANはおそらく過剰です。このタイプの状況では、いくつかの内部ディスクを備えた小型のスタンドアロンタワーサーバーがはるかに適切なソリューションです。

ローカルまたはSANがパフォーマンスを維持する唯一の方法です。場合によっては、書き込みキャッシュと並列ディスクのスループット構成が大きくなるため、SANはローカルディスクよりも高速になることがあります。

Windows共有上で高性能のファイルI / Oを実行しないでください。スループットが劇的に低下するプロトコルオーバーヘッドが大量にあります。たとえば、数年前、私はWANを介した大規模なファイル転送が、Windows over FTP共有を使用した場合に最大50％高速であることを測定しました。

NASを使用しないでください。

ローカル（良いRAIDコントローラーで中期的にはOK）を使用しますが、予算が許せば、まともなSANを使用します。運が良ければ、他のシステムとSANを「共有」し、初期費用の多くを回収することができます。

4GB RAMは、専用のSQL Serverである限り、ほとんどのシステムで問題ありません（常にそうである必要があります）。まだ検討していない場合は、64ビットOSとSQLサーバーを使用して、PAE / AWEをいじることなく、より多くのRAMを簡単に投入できるようにしてください。

仮想化についても考えてください。テストサーバーが必要ですか？開発サーバー？SP1のインストールをテストしますか？（以前の投稿の恥知らずなプラス：sql-server-in-vmware）

データベースサイズが2Gbの場合、SANを検討する理由さえありません。NASは機能しません。バックアップにNASを使用することだけを考えて、データと同じマシンにバックアップを保存しないようにしてください。また、オフサイトストレージ用にNASからコピーを作成するのは簡単です。

小さなデータベースでは、RAID 1またはRAID 10でローカルディスクを使用するだけです。データベースがRAMに収まる場合、IOパフォーマンスをそれほど心配する必要はありません。64ビットウィンドウを使用して、8つのギグをそこに入れます。これにより、OSに十分な余裕が生まれ、成長の余地が与えられます。

ローカルRAIDディスクとファイバー接続SANの両方を使用するシステムを使用しています。前者がより新しくより高速なマシンであっても、SANのパフォーマンスは向上しているようです。重要な要因は、ローカルディスク配置が単一のドライブであるため、SQLがOSおよびスワップファイルとディスクI / Oを共有していることです。これはおそらくドラッグに大きく貢献しています。

@spoulsonが言及したように、SANははるかに優れたディスクパフォ​​ーマンスを提供できます。別のドライブであるだけでなく、はるかに高速なディスクハードウェア上にある可能性があります。

この例では、SANを使用しています。これは、SANを使用すると、自動フェールオーバーVERITAS SQL Serverサービスグル​​ープ用の中央ストレージエリアが提供されるためです。プライマリマシンに障害が発生すると、SANにマウントされたWindowsドライブがホットバックアップマシンに再マウントされ、サーバーが非常にすばやく復旧します。もちろん、これにはVERITASに似たシステムが必要です。これは、サービスグル​​ープ管理のために、対象範囲外になる場合があります。

苦労した1つの注意点は、SANディスク領域の割り当てが保守的に処理されることです。高価なため、気まぐれに振る舞いません。使用するEMC SANでは、LUN全体をダンプせずに割り当てられたスペースを再生することはできません。そのため、割り当てられたスペースが必要以上であり、そのスペースの一部を別のLUNに使用したい場合、オーバーサイズのスペースを縮小することはできません。削除して再割り当てする必要があります。これは、実稼働環境ではあまりうまく機能しません。

他の人が示唆したように、NASを避けてください。データファイルをUSB外付けハードドライブに置くこともできます。

小規模な2GBデータベースの場合、SANは過剰になります。

一般的に、SQLドライブを他のアプリケーションと共有することは望ましくありません。同様に、ファイルを広めることができるスピンドル（ディスク）が多いほど良いです。繰り返しますが、説明したような小さなデータベースでは、必要なものをすべてRAMに収めることができるため、ディスクのパフォーマンスはそれほど重要ではありません。

ただし、単一のRAID-10ボリュームを作成して、すべてのデータベースファイルをそのボリュームに配置しないでください。次のようなシンプルなものから始めることができます：データ-2x 73GB 15K RPM、RAID1ログ-2x 73GB 15K RPM、RAID1バックアップ-単一の大きな7200 RPMまたはRAID1のペア

アップグレードする予算がある場合は、TempDBに別のボリュームを追加する（複雑なレポート/分析クエリを行う場合）か、ログボリュームにディスクを追加し、システムが高ボリュームでトランザクションが多い場合はRAID10として構成する更新の。

SANは、同じ数のドライブの直接接続ストレージの3〜4倍のコストがかかる可能性があります。SANは、バックアップ/スナップショット、クラスタリングのサポート、LUNの移行と拡張のための多くの高度な機能を提供します。これらがあなたにとって重要である場合、追加費用の価値があるかもしれません。

免責事項： SQL ServerデータベースファイルのNASへの保存には、多くの深刻な問題があります。他のすべてのオプションが等しい場合、SANオプションを選択するのが正しいです。関連する問題の詳細な説明は、MS KB304261にあります。しかし、このスレッドは、ネットワーク共有上のSQL Serverに関する他の質問のすべてのキャッチになりました。SQLServerバージョンのNASサポートの状態への参照を投稿したいと思います。

かなり少数の人々が、MS SQLでNASを使用して実験しています。

これはデフォルトで禁止されていましたが、MS SQL 2008およびMS SQL 2005の制限を解除できました。MSSQL 2008 R2以降、このような制限はありません。

MS SQL 2005および2008では、キーはネットワーク共有の使用を禁止するトレースフラグです。発行できる

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

詳細については、Varun DhawanのMSDNブログの2010年9月の投稿を参照してください。

少なくとも技術的にNAS上でSQL Serverを実行することは可能です。選択は多くの要因に依存し、NASでデータベースのストレージがすぐに利用できる状況を想像するのは難しくありません。