私は過去に、UNC共有からWebアプリケーションを実行することが賢明ではないことを教えてきました。私が覚えている理由は、セキュリティ、権利、権限の問題とパフォーマンスです。しかし、the DotNetNuke documentation it saysに：DotNetNukeドキュメントで提案されているように、UNC共有からIIS Webアプリケーションを実行するのはどうですか？
DotNetNukeのは、最初にサポートするWebファーム構成は、そのIIS Webサイトのルート ディレクトリは上の一般的なUNC共有にマッピングされている 2以上のフロントエンドWebサーバー（「ウェブ・ヘッド」）が含まリモートファイルサーバー。 UNC共有には、アプリケーションソースコードと、個々のサイトの静的コンテンツである が含まれています。
これは何とか私にとっては貧弱な設定のように聞こえ、潜在的なパンドラの箱を開くような気がします。ここでDotNetNuke Corpの提案に従うことが賢明ですか？
DOtNetNukeを使用したこのタイプの設定では、問題が発生することがあります。
これがDotNetNuke社の「デフォルト」勧告であると私が推測するのは、以下の理由によるものです。注：これらは私の意見です。
UNC共有の使用には本質的に問題はありません。以前の会社では、数十のWebサーバーを運用していましたが、すべてUNCシェアを使用していました（DNNではなく）。 80,000人を超える有料加入者がいました。そのうちの10人が毎日アプリケーションを使用していました。それはとてもうまくいった。ミッチェルのポイント対処するため
：失敗の
1）を単一のポイントは、あなたがそれ問題にする場合にのみ問題です。さまざまなSAN/NASソリューションには多くの冗長性があります。
2.）IOはまともなSANまたはNASでは問題になりません。私はファイルシステムのウォッチャーには一度も問題がなかった。万一DNNが直接使用していないのであれば、おそらく、組み込みのASP.Netウォッチャーが問題を作り出している可能性があります。
3）私はセキュリティが他の解決策よりも問題ではないと考えています。ファイルへのアクセスを制御し、アクセス許可を適切に設定する必要があります。ローカルディスクを使用すると、ネットワークよりもより多くの権限を開いたままにすることができますが、両者を同じようにしっかりと保護する必要があります。 UNCパスの使用に関連する追加の構成ステップがあります。 Webファームにふさわしいサイトを作成するのに何週間もの努力をしていなければ、セキュリティを構成するための余計な努力は数週間と比べてほんのわずかです。
私は、ファイル同期を使用しない理由についてのMitchelの意見に完全に同意します。
私はそこにファイル同期を持つDNNサイトを実行している人がいることは知っています。私は、ファイル同期によって引き起こされる問題を回避する必要がなかった人は誰も知らない。個人的には、ファイル同期の奇妙な点を整理した後、SAN上でUNCを使用するよりも、ファイル同期でうまく動作するサイトを取得するほうが安いことに個人的には疑いがあります。
ミッチェルの点を詳述してくれてありがとう。ただし、SAN/NASソリューションを選択した場合でも、コアWebサイトをアップグレードする場合でも、SPoFは問題になります。 – Abel
@ScottS - ＃2に関しては、ファイルウォッチャー（ファイルベースのキャッシュとASP.NETプロセスの監視）の数に関するWINDOWSの制限であるSANに関する問題ではありません。 –
私は、各システムで分割払いを使用すると、1つを更新し、もう1つは実行してから、もう一方を更新してアップグレード中に100％の稼働時間を持つ可能性があるという印象を受けました。 UNCを使用すると、（1）で言及したように、単一障害点が作成されます。 – Abel
データベースが更新され、サイトファイルがシステムをlimboに配置しないため、アップグレードシナリオは機能しません。 –
良い点は、シナリオが徹底的に練られていなければならないと推測します。これは受け入れられた答えですが、多くの情報はScottSによる2番目の回答にもあります。お互いに感謝します。 – Abel