SAN
ストレージについてあまり詳しくない。ストレージにSANを使用して物理マシンと仮想マシンを実行することについていくつか質問があります。
SAN物理サーバーに接続されたストレージからOSを起動することは可能ですか？ある場合、それにはマイナス面がありますか？OSに複数のドライブがあり、このサーバーにはSQL Serverがインストールされているとしましょうまた、データ、ログ、一時DB用のドライブはすべてSANからのものです。OSをローカルハードドライブから起動した場合、SQLを使用してそれを維持するよりもパフォーマンスが向上しますかSANデータファイル？高いIOPS？待ち時間？
以下の3つを比較して定量化してみます。
物理マシン-ローカルドライブからOSを起動し、その他をSANから起動する
物理マシン-SANからのOSおよびその他のドライブの起動
仮想マシン-Hyper-Vホストのローカルドライブ上の仮想ディスク、vSAN上のSQLデータ/ログ/一時
仮想マシン-vSAN内のすべての仮想ディスク、SQLデータ/ログ/一時
最後のものは他のものと比べてパフォーマンスが悪いでしょうか？
ありがとう
SANからのブートは最近では非常にまれです。私がよく見かけるハイパーバイザーはSDカードからブートされます。その後、VMのローカルストレージを100％使用するか、SAN VM専用。SDカードからの起動が適切でない場合は、ハイパーバイザーをPXE起動することも可能です。
特定の質問に対処するには：
SAN物理サーバーに接続されたストレージからOSを起動できますか？
はい、そうです。多くのデータセンター/エンタープライズネットワークカードには、これを容易にするために必要なiSCSIプロトコルが組み込まれています。
もしそうなら、それには欠点がありますか？
うん、たくさん。複雑さと脆弱性が最大です。実を言うと、それほど多くのメリットはありません。
OS用に複数のドライブがあり、このサーバーにはSQL Serverがインストールされており、データ、ログ、および一時DB用の他のドライブはすべてSANからのものであるとします。
OSがローカルハードドライブから起動した場合、SQLデータファイルを使用してOSを起動する場合よりもパフォーマンスが向上しますかSAN？
すべてのデータファイルをローカルストレージに保存することをお勧めします。データベースサーバーの場合、SAN=瀕死の媒体として表示されます。ローカルストレージはとてもより高速ですSANストレージ（ 40 Gbps接続）。2019クラスのハードウェア上の単一のNVMeドライブは、4 Gbps未満（30 Gbpsを超える）で限界に達する可能性があります。単一のドライブでは、それほど多くのお金がかかりません。将来的には、PCI-e 4.0が出荷されるようになりますAMD Epycサーバーは128 GBを超えるPCIe 4.0レーンを備えているため、250 GB /秒（2Tb /秒）を超える可能性がありますソケットごと。申し訳ありませんが、 SANを現代の死んだ媒体として参照してください。
さらに、MSSQLはクラスター化システムの共有ストレージを必要としなくなりました。 AlwaysOn高可用性を使用すると、共有ストレージのない高可用性SQLサーバーを取得できます（ただし、すべてのサーバーのストレージレイアウトは各ノードで同一に見える必要があります）。
最後のものは他のものと比べてパフォーマンスが悪いでしょうか？
それらはすべて、ローカルストレージに対してパフォーマンスが低下します。ただし、これは実際に尋ねている質問ではなく、2019年に新しいSAN=）を購入していないことと、引き続き再評価する機会があることを願っています。
これらについて見ていきましょう。
物理マシン-ローカルドライブからOSを起動し、その他はSANから起動する
現在、至る所でこのように実行されている多くのシステムがあります。特に、仮想化されていないデータベースサーバーはこのように機能します。最小のレイテンシが必要で、パフォーマンスの最後のすべての低下にアクセスする場合、CGIレンダーファームは非常に便利です。通常もこのように動作します。
物理マシン-SANからOSおよびその他のドライブを起動
私はこれを年に1〜2回実行しましたが、通常は思ったよりも少し「壊れやすい」ので、機能しますが、ローカルディスクオプションよりも多くの作業を行うことができます。実行することは、ブートペアとディスクコントローラーを購入しないことで、サーバーに少し余分を節約することです。個人的には、これを将来使用することはできません。
仮想マシン-Hyper-Vホストのローカルドライブ上の仮想ディスク、vSAN上のSQLデータ/ログ/一時
確かにこれは正常に機能します。このように実行されているVMはたくさんあります。AWSのVM /インスタンスのほとんどはこのように機能します。非常に人気があります。選択したハイパーバイザーでVMを1つのローカルディスクから別のホストとそのホストのディスクに移行できない場合、仮想化の利点の1つを逃してしまう可能性があります。ホストからすべてのVMを移行して、ユーザーに影響を与えずに修正、アップグレード、パッチを適用する。ここでvSANについて言及していますが、VMwareのvSAN製品について話している場合は、ディスクをローカルで実行し、障害から保護し、ホストからホストに移行することができるため、状況が変わります。それを片付けるために戻って？
仮想マシン-vSAN内のすべての仮想ディスク、SQLデータ/ログ/一時
企業環境では、おそらくこれが現在最も頻繁に使用され、信頼されている方法です（vSANなどの分散ファイルシステムが実際に普及するにつれて、変更される可能性があります）。
最後のオプションのパフォーマンスについては、使用する集中型ディスクアレイと、それらにアクセスするために使用する通信方法に完全に依存します。遅いディスクアレイに対して1 Gbpsイーサネットを使用する場合、ローカルディスクを使用するよりも明らかに遅くなります。40Gbps FCoEと組み合わせると、アレイメーカーは、サーバーバーのNVMeドライブに直接接続できるものよりもはるかに高速です。ですから、それは本当に集中型ストレージが何であるかに依存します。
これがあなたのオプションを明確にする助けになることを願っています。
この慣習がどれほど「まれ」であるかはわかりませんが、私はそれをたくさん見ましたが、環境に依存していると思います。
通常、Boot from SAN=はブレードサーバーを使用している場合です。通常のブレードサーバーにはディスク用のスロットが2つしかないため、これは、数テラバイトのデータベースサーバーのような場合にかなり制限される可能性があります。必要な場合もあります。さらに、ブレードを交換するだけで障害が発生したブレードをすばやく簡単に交換できます。ディスクを移動して正しいスロットに挿入しないようにするためにそのようなことをする人を心配する必要はありません。これには依然としてHBAが必要です構成する新しいブレードでは、以下で説明します。
SAN=からWindowsまたはLinuxを起動するのは簡単です。ストレージ管理者と協力して、HBAからWWNを提供する必要があります（通常、冗長パス用の2つのHBAインターフェイス）。）ブートLUNをプロビジョニングしたら、POST中にサーバーをブートし、HBA BIOSに入ります。利用可能なLUNをスキャンし、HBAを使用してブートするように指示します。HBAがブート順序の最初のデバイスであることを確認してください。それを見て、そのLUNにインストールすることを提案します。最初にブートLUNのみを構成し、次にOSのインストール後に必要な追加のデータLUNを追加するのが最も簡単な場合があります。