Was ist so schlimm daran, eine IIS-Webanwendung von einer UNC-Freigabe auszuführen, wie in DotNetNuke-Dokumenten vorgeschlagen?

Es gibt ein paar Dinge, die problematisch werden können, wenn es um diese Art der Konfiguration mit DOtNetNuke geht.

1. Diese Methode, obwohl ein "Webfarm" -Szenario zu einem einzigen Fehlerpunkt führt. Der UNC-Anteil wird zu Deinem Drosselpunkt und wenn er abfällt, gehen alle Knoten unter.
2. Disk IO und Konfiguration der Netzwerkkommunikation können ein Problem sein. Dies hängt mit der Anzahl der "File System Watchers" zusammen, die auf Remote-Inhalten geöffnet / verwaltet werden können. Dieses Problem ist in den meisten Fällen nicht allzu groß, aber es kann eine königliche PITA sein, wenn es passiert.
3. Sicherheit kann ein Problem sein, ist aber normalerweise etwas, mit dem Sie zu Beginn der Konfiguration Probleme haben. Sie müssen sicherstellen, dass Sie dem Benutzerkonto ordnungsgemäß Berechtigungen zuweisen, damit es vollständigen Zugriff auf die UNC-Freigabe haben kann.

Meine Vermutung, warum dies die "Standard" -Empfehlung von DotNetNuke Corporation ist, würde auf Folgendes zurückzuführen sein. HINWEIS: Das sind NUR meine Meinungen.

1. Diese Konfiguration bietet die "geringste" Komplikation bei der Synchronisation von Inhalten in Echtzeit. Mit nur einem Dateisystem brauchen Sie nicht über Replikation und solche Dinge zu sprechen.
2. Standard-Caching verwendet dateibasiertes Caching, wobei beide zum gleichen System-Cachespeicher Ablauf leicht zu verwalten sind. Wenn repliziert würde es nicht funktionieren.

An der Verwendung einer UNC-Freigabe liegt nichts an sich. Bei einer früheren Firma haben wir Dutzende von Webservern betrieben, und alle verwendeten UNC-Anteile (nicht bei DNN). Es gab über 80.000 zahlende Abonnenten, von denen zehntausende die Anwendungen jeden Tag nutzten. Es hat sehr gut funktioniert.

Um Mitchels Punkte anzusprechen:

1.) Single Point of Failure ist nur ein Problem, wenn Sie es zu einem Problem machen. In den verschiedenen SAN / NAS-Lösungen ist viel Redundanz verfügbar.

2.) IO wird kein Problem mit einem anständigen SAN oder NAS sein. Ich hatte noch nie ein Problem mit Dateisystembeobachtern. DNN verwendet keine direkt, im unwahrscheinlichen Fall, dass die integrierten ASP.Net-Watcher ein Problem verursachen, würde ich sie wahrscheinlich deaktivieren.

3.) Ich sehe Sicherheit nicht mehr als eine andere Lösung. Sie müssen sicherstellen, dass Sie den Zugriff auf Ihre Dateien und die Setup-Berechtigungen entsprechend kontrollieren. Mit lokalen Festplatten können Sie Berechtigungen offen lassen als in einem Netzwerk, aber Sie sollten beide gleichermaßen sichern. Es gibt einen zusätzlichen Konfigurationsschritt für die Verwendung eines UNC-Pfads. Der zusätzliche Aufwand bei der Konfiguration der Sicherheit ist im Vergleich zu den Wochen, wenn nicht gar Monaten, die beim Erstellen einer Website erforderlich sind, die einer Webfarm würdig ist, winzig.

Ich stimme mit den Meinungen von Mitchel voll und ganz überein, warum die Dateisynchronisierung nicht verwendet werden sollte.

Ich weiß, dass es Leute gibt, die DNN-Sites mit Dateisynchronisation betreiben. Ich kenne niemanden, der die Probleme, die durch die Dateisynchronisation verursacht wurden, nicht umgehen musste. Persönlich bezweifle ich, dass das Erhalten einer Website, die gut mit Dateisynchronisierung läuft, billiger ist als die Verwendung einer UNC in einem SAN, sobald Sie die Arbeit zählen, die für das Aussortieren der Macken der Dateisynchronisierung ausgegeben wird.