Was ist so schlimm daran, eine IIS-Webanwendung von einer UNC-Freigabe aus laufen zu lassen, wie in den DotNetNuke-Dokumenten vorgeschlagen?

Question

In der Vergangenheit wurde mir beigebracht, dass es unklug ist, eine Webanwendung über eine UNC-Freigabe auszuführen. Die Gründe, an die ich mich erinnere, sind Sicherheit, Probleme mit Rechten und Berechtigungen und Leistung. Doch in In der DotNetNuke-Dokumentation heißt es :

Die Webfarm-Konfiguration, die DotNetNuke anfänglich unterstützt, umfasst zwei oder mehr Front-End-Webserver ("Web-Heads"), deren IIS-Website Root Verzeichnisse auf eine gemeinsame UNC-Freigabe auf einem entfernten Dateiserver abgebildet werden. Die UNC-Freigabe enthält den Quellcode der Anwendung sowie alle statische Inhalte für die einzelnen Sites.

Irgendwie klingt das für mich wie eine "Arme-Leute-Konfiguration", und ich habe das Gefühl, eine potenzielle Büchse der Pandora zu öffnen. Ist es klug, hier dem Vorschlag der DotNetNuke Corp. zu folgen?

Answer 1

Gegen die Verwendung einer UNC-Freigabe ist an sich nichts einzuwenden. In einem früheren Unternehmen betrieben wir Dutzende von Webservern, die alle UNC-Freigaben verwendeten (nicht bei DNN). Wir hatten über 80.000 zahlende Abonnenten, von denen 10.000 die Anwendungen täglich nutzten. Das hat sehr gut funktioniert.

Um auf die Punkte von Mitchel einzugehen:

1.) Ein einziger Fehlerpunkt ist nur dann ein Problem, wenn man ihn zu einem Problem macht. In den verschiedenen SAN/NAS-Lösungen ist reichlich Redundanz vorhanden.

2.) IO wird mit jedem anständigen SAN oder NAS kein Problem sein. Ich hatte noch nie ein Problem mit Dateisystemüberwachungen. DNN verwendet nicht direkt welche, in dem unwahrscheinlichen Fall, dass die eingebauten ASP.Net Watcher ein Problem verursachen, würde ich sie wahrscheinlich deaktivieren.

3.) Ich sehe die Sicherheit nicht als ein größeres Problem an als bei anderen Lösungen. Sie müssen sicherstellen, dass Sie den Zugriff auf Ihre Dateien kontrollieren und die Berechtigungen entsprechend einrichten. Bei lokalen Festplatten können Sie die Berechtigungen offener lassen als in einem Netzwerk, aber Sie sollten wahrscheinlich beide gleich gut absichern. Bei der Verwendung eines UNC-Pfads ist ein zusätzlicher Konfigurationsschritt erforderlich. Der zusätzliche Aufwand für die Sicherheitskonfiguration ist im Vergleich zu den Wochen, wenn nicht Monaten, die für die Erstellung einer Website erforderlich sind, die einer Webfarm würdig ist, verschwindend gering.

Ich schließe mich Mitchels Meinung an, warum man die Dateisynchronisation nicht verwenden sollte.

Ich weiß, dass es einige Leute gibt, die DNN-Sites mit Dateisynchronisierung betreiben. Ich kenne niemanden, der nicht mit Problemen zu kämpfen hatte, die durch die Dateisynchronisation verursacht wurden. Ich persönlich bezweifle, dass es billiger ist, eine Site mit Dateisynchronisation zum Laufen zu bringen, als ein UNC auf einem SAN zu verwenden, wenn man den Arbeitsaufwand für das Aussortieren der Macken der Dateisynchronisation berücksichtigt.

Answer 2

Es gibt ein paar Dinge, die bei dieser Art der Konfiguration mit DOtNetNuke problematisch werden können.

1. Diese Methode, obwohl ein "Web-Farm"-Szenario, führt zu einem einzigen Ausfallpunkt. Die UNC-Freigabe wird zum "Choke Point", und wenn sie ausfällt, fallen alle Knoten aus.
2. Festplatten-IO und Konfiguration der Netzwerkkommunikation können ein Problem darstellen. Dies hängt mit der Anzahl der "File System Watchers" zusammen, die für entfernte Inhalte geöffnet/gepflegt werden können. Dieses Problem ist in den MEISTEN Fällen keine große Sache, kann aber eine echte PITA sein, wenn es passiert.
3. Die Sicherheit kann ein Thema sein, ist aber in der Regel etwas, mit dem man nur zu Beginn der Konfiguration Probleme hat. Sie müssen sicherstellen, dass Sie dem Benutzerkonto ordnungsgemäß Berechtigungen zuweisen, damit es vollen Zugriff auf die UNC-Freigabe hat.

Meine Vermutung, warum dies die "Standard"-Empfehlung der DotNetNuke Corporation ist, hat folgende Gründe. HINWEIS: Dies sind NUR meine Meinungen.

1. Diese Konfiguration bietet die "geringsten" Komplikationen, wenn es um die Synchronisierung von Inhalten in Echtzeit geht. Da es nur ein Dateisystem gibt, ist es nicht notwendig, über Replikation und dergleichen zu sprechen.
2. Das Standard-Caching verwendet dateibasiertes Caching, wobei beide in denselben System-Cache gehen, dessen Ablauf leicht zu verwalten ist. Bei einer Replikation würde es nicht funktionieren.