ファイルレイアウトとサーバ設定のベストプラクティスは、ドキュメントで推奨されているものと同じ"ONTAP上のSQL Server"です。

スタンドアロン構成では、SQL Serverを1つのサイトでのみ実行できます。おそらく"均一（ Uniform ）"アクセスが使用されます。

アクセス方法が統一されていれば、どちらかのサイトでストレージ障害が発生してもデータベースの処理は中断されません。データベース・サーバを含むサイトで完全なサイト障害が発生すると'当然'システム停止が発生します

一部のお客様は、リモートサイトで実行されているOSを、構成済みのSQL Serverセットアップで構成し、本番インスタンスと同等のビルドバージョンで更新することもできます。フェイルオーバーを実行するには、代替サイトでSQL Serverのスタンドアロンインスタンスをアクティブ化し、LUNを検出して、データベースを起動する必要があります。ストレージ側からの操作が不要なため、Windows PowerShellコマンドレットを使用して完全なプロセスを自動化できます。

"不均一"アクセスも使用できますが、データベースにストレージへの使用可能なパスがないために、データベースサーバが配置されていたストレージシステムで障害が発生すると、データベースが停止します。これは、場合によっては許容される可能性があります。SnapMirrorのアクティブな同期では引き続きRPO=0のデータ保護が提供され、サイト障害が発生した場合でも、稼働しているコピーがアクティブになり、前述の統一されたアクセスと同じ手順で運用を再開できます。

シンプルで自動化されたフェイルオーバープロセスは、仮想化ホストを使用してより簡単に設定できます。たとえば、SQL ServerデータファイルをブートVMDKとともにセカンダリストレージに同期的にレプリケートする場合は、災害が発生したときに代替サイトで環境全体をアクティブ化できます。管理者は、サバイバーサイトでホストを手動でアクティブ化することも、VMware HAなどのサービスを使用してプロセスを自動化することもできます。

SQL Serverフェイルオーバーインスタンスは、物理サーバまたは仮想サーバ上でゲストオペレーティングシステムとして実行されているWindowsフェイルオーバークラスタでホストすることもできます。このマルチホストアーキテクチャは、SQL Serverインスタンスとストレージの耐障害性を提供します。このような導入は、強化されたパフォーマンスを維持しながら堅牢なフェイルオーバープロセスを必要とする、負荷の高い環境に役立ちます。フェイルオーバークラスタのセットアップでは、ホストまたはプライマリストレージが影響を受けると、SQLサービスがセカンダリホストにフェイルオーバーされ、同時にセカンダリストレージがIOを処理できるようになります。自動化スクリプトや管理者の介入は必要ありません。