Architektur Empfehlung für Lastausgleich ASP.NET-Website

StackOverflow https://stackoverflow.com/questions/613568

Frage

UPDATE 2009-05-21

Ich habe die Prüfung der # 2 Verfahren zur Herstellung eines einzigen Netzwerkfreigabe verwenden. Es ist in einigen Problemen mit Windows Server 2003 unter Last resultierend:

http://support.microsoft.com/kb/810886

Ende update

Ich habe einen Vorschlag für eine ASP.NET-Website erhalten, die funktioniert wie folgt:

Hardware Loadbalancer -> 4 IIS6 Webserver -> SQL Server DB mit Failover-Cluster

Hier ist das Problem ...

Wir entscheiden, wo die Web-Dateien zu speichern (aspx, HTML, CSS, Bilder). Zwei Optionen sind vorgeschlagen worden:

1) Erstellen Sie identische Kopien der Web-Dateien auf jedem der vier IIS-Server.

Setzen Sie

2) eine einzige Kopie der Web-Dateien auf einer Netzwerkfreigabe zugänglich durch die 4 Web-Servern. Die webroots auf dem 4 IIS-Server werden auf die einzelne Netzwerkfreigabe zugeordnet werden.

Welches ist die bessere Lösung? Option 2 ist offensichtlich einfacher für Installationen, da sie das Kopieren von Dateien auf nur einen einzigen Standort erfordern. Allerdings frage ich mich, ob es Skalierbarkeitsprobleme seit vier Web-Server alle Zugriff auf einen einzigen Satz von Dateien sein. Wird IIS diese Dateien lokal zwischenspeichern? Wäre es die Netzwerkfreigabe auf jeder Client-Anfrage betroffen? Zugriff auch wird, immer zu einer Netzwerkfreigabe langsamer als eine Datei auf einer lokalen Festplatte zu bekommen? Ist die Belastung der Netzwerkfreigabe wird wesentlich schlechter, wenn mehr IIS-Server hinzugefügt werden?

Perspektive zu geben, dann ist dies für eine Website, die derzeit erhält ~ 20 Millionen Zugriffe pro Monat. Bei der letzten Peak, empfängt es etwa 200 Zugriffe pro Sekunde.

Bitte lassen Sie mich wissen, wenn Sie besondere Erfahrung mit einem solchen Aufbau haben. Vielen Dank für die Eingabe.

UPDATE 2009-03-05

Um meine Situation zu klären - die „Installationen“ in diesem System sind weit häufiger als eine typische Web-Anwendung. Die Website ist das Frontend für einen Back-Office-CMS. Jedes Mal, Inhalte im CMS veröffentlicht wird, neue Seiten (aspx, html, etc.) auf die Live-Website automatisch gedrückt. Die Einsätze sind im Grunde „on demand“. Theoretisch könnte dies Push mehrmals innerhalb einer Minute oder mehr passieren. Also ich bin nicht sicher, ob es sinnvoll wäre, einen Web-Server zum Zeitpunkt einzusetzen. Gedanken?

War es hilfreich?

Lösung

würde ich die Last zwischen dem 4-Server teilen. Es ist nicht so viele.

Sie wollen nicht, dass einzelnen Streitpunkt entweder bei der Bereitstellung von noch dieses Single Point of Failure in der Produktion.

Bei der Bereitstellung, können Sie sie 1 zu einem Zeitpunkt tun. Ihre Deployment-Tools sollten diese automatisieren, indem Sie den Load-Balancer darüber informiert, dass der Server sollte nicht verwendet werden, den Code bereitstellen, jede Vorkompilierung Arbeit benötigt wird, und schließlich den Load-Balancer darüber informiert, dass der Server bereit ist.

Wir haben diese Strategie in einer mehr als 200 Web-Server-Farm und es funktioniert gut ohne Betriebsunterbrechung für die Bereitstellung.

Andere Tipps

Wenn Ihr Hauptanliegen Leistung ist, die ich nehme an, es ist, da Sie all dieses Geld auf Hardware-Ausgaben sind, dann ist es nicht wirklich Sinn, ein Netzwerk-Dateisystem nur aus Bequemlichkeitsgründen zu teilen. Auch wenn die Netzlaufwerke extrem leistungsstark sind, werden sie nicht so gut wie nativer Antriebe durchführen.

Bereitstellen der Web-Assets ohnehin automatisiert sind (oder?) Tun es so ein Vielfaches ist nicht wirklich viel von einer Unannehmlichkeit.

Wenn es komplizierter, als du laesst auf, dann vielleicht so etwas wie Deltacopy würde nützlich sein, diese Platten synchron zu halten.

Ein Grund der zentrale Anteil schlecht ist, weil es die NIC auf dem Aktien Server der Engpass für die gesamte Farm macht und schafft einen Single Point of Failure.

Mit IIS6 und 7 wird das Szenario ein Netzwerk einzelne Aktie über N gebunden Web / app-Server-Maschinen der Verwendung wird ausdrücklich unterstützt. MS hat eine Tonne perf Tests um sicherzustellen, dass dieses Szenario gut funktioniert. Ja, Caching verwendet wird. Mit einem Dual-NIC-Server, eine für das öffentliche Internet und einem für das private Netzwerk, werden Sie wirklich gute Leistung. Der Einsatz ist kugelsicher.

Es lohnt sich, die Zeit zu Benchmark nehmen es.

Sie können auch eine ASP.NET Virtual Path Provider bewerten, mit dem Sie eine einzelne ZIP-Datei für die gesamte App bereitstellen würde ermöglichen. Oder mit einem CMS, können Sie Inhalte direkt aus einer Inhaltsdatenbank dienen, sondern als ein Dateisystem. Dies stellt ein paar wirklich nette Optionen für die Versionsverwaltung.

VPP Für ZIP über #ZipLib .

VPP für ZIP über DotNetZip .

In einer idealen Hochverfügbarkeitssituation, sollte es keinen Single Point of Failure sein.

Das bedeutet, dass eine einzige Box mit den Web-Seiten ist es ein No-No. getan HA Arbeit für einen großen Telco hat, würde ich zunächst vorschlagen, wie folgt vor:

  • Jeder der vier Server hat seine eigene Kopie der Daten.
  • in einer ruhigen Zeit, bringt zwei der Server off-line (das heißt, ändern Sie den HA-Balancer, sie zu entfernen).
  • Aktualisieren Sie die zwei Offline-Server.
  • Ändern Sie den HA-Balancer mit den beiden neuen Server zu starten und nicht die beiden alten Server.
  • Test, die Richtigkeit zu gewährleisten.
  • Aktualisieren Sie die beiden anderen Servern sie dann online schalten.

Das ist, wie man es ohne zusätzliche Hardware zu tun. In der anal-retentive Welt der Telco für die ich gearbeitet, hier ist, was wir getan haben würde:

  • Wir würden acht Server gehabt haben (zu der Zeit hatten wir mehr Geld, als Sie einen Stock an stecken könnten). Wenn die Zeit für den Übergang kommt, würde der vier Offline-Server mit den neuen Daten eingerichtet werden.
  • Dann würde der HA-Balancer die vier neuen Server zu verwenden, geändert werden und mit dem alten Server zu stoppen. Dies machte Umschaltung (und, was noch wichtiger ist, Spitzkehre, wenn wir verstopften) ein sehr schneller und schmerzlos.
  • Erst wenn der neue Server war für eine Weile laufen würden wir die nächste Umschaltung in Betracht ziehen. Bis zu diesem Zeitpunkt werden die vier alten Server wurden off-line gehalten, aber bereit, für alle Fälle.
  • Um den gleichen Effekt mit weniger finanziellen Aufwand zu erhalten, könnten Sie zusätzliche Festplatten haben, anstatt ganzen zusätzlichen Server. Eine Rückforderung würde nicht ganz so schnell sein, da Sie einen Server betreiben müssen Sie die alte Festplatte zurück zu setzen in, aber es wäre immer noch schneller sein als eine Wiederherstellungsoperation.

Ich war verantwortlich für die Entwicklung für ein Spiel Website, die 60 Millionen Zugriffe pro Monat hatte. Die Art, wie wir es taten, war die Option 1 aus. User haben die Möglichkeit haben, Bilder hochladen und so und diese wurden auf einem NAS setzen, die zwischen den Servern gemeinsam genutzt wurde. Es funktionierte ziemlich gut aus. Ich gehe davon aus, dass Sie auch Seiten-Caching tun, und so weiter, auf der Anwendungsseite des Hauses. Ich würde auch auf Anfrage bereitstellen, die neuen Seiten auf alle Server gleichzeitig.

Was Sie mit dem 4IIS auf NLB gewinnen Sie verlieren es mit dem Bottleneck mit dem App-Server.

Für Skalierbarkeit Ich werde die Anwendungen auf dem Front-End-Webserver empfehlen.

Hier in meiner Firma, die wir implementieren diese Lösung. Der .NET-App in den vorderen Enden und ein APP-Server für Sharepoint + ein SQL 2008-Cluster.

Hoffe, es hilft!

Grüße!

Wir haben eine ähnliche Situation für Sie und unsere Lösung ist ein Publisher / Subscriber-Modell zu verwenden. Unsere CMS App speichert die aktuellen Dateien in einer Datenbank und benachrichtigt einen Veröffentlichungsdienst, wenn eine Datei erstellt oder aktualisiert wurde. Dieser Verlag informiert dann alle abonnierenden Web-Anwendungen und sie dann gehen und die Datei aus der Datenbank erhalten und sie auf ihre Dateisysteme.

Wir haben die in einer Konfigurationsdatei festgelegt Abonnenten auf dem Verleger, aber man könnte das ganze Schwein und hat das Web-App kann das Abonnement selbst auf App Start gehen, um es noch einfacher zu verwalten zu machen.

Sie einen UNC für die Lagerung verwenden konnten, haben wir uns für eine DB für Komfort und Portabilität zwischen oder Produktions- und Testumgebung (wir die DB zurück kopieren Sie einfach und wir haben alle die Live-Website sowie die Datendateien).

Eine sehr einfache Methode, um mehrere Server der Bereitstellung (sobald die Knoten richtig eingerichtet sind) ist robocopy zu verwenden.

Vorzugsweise würden Sie einen kleinen Staging-Server zum Testen haben und dann Sie würde ‚Robocopy‘ für alle Bereitstellungsserver (statt eine Netzwerkfreigabe zu verwenden).

Robocopy ist in der MS ResourceKit -. verwenden sie es mit dem / MIR Schalter

Sie für Gedanken, etwas zu essen geben Sie an so etwas wie Microsofts Live Mesh aussehen könnte . Ich sage nicht, es ist die Antwort für Sie ist aber das Speichermodell kann es sein, verwendet.

Mit der Mesh-Download Sie einen kleinen Windows-Dienstes auf jede Windows-Maschine, die Sie in Ihrem Ineinander greifen wollen und dann nominieren Ordner auf Ihrem System, das Teil des Netzes ist. Wenn Sie eine Datei in einen Live Mesh-Ordner kopieren - die auf Ihrem System genau die gleiche Operation wie das Kopieren auf andere foler ist -. Der Service kümmert sich um die Synchronisierung, die auf alle anderen beteiligten Geräte-Datei

Als Beispiel ich alle meine Code halten Quelldateien in einem Mesh-Ordner und haben sie zwischen Arbeit und zu Hause synchronisiert. Ich muss gar nichts tun, um sie die Aktion synchron halten von einer Datei in VS.Net speichern, Notizblock oder jede andere App initiiert die Aktualisierung.

Wenn Sie eine Website mit häufig Dateien zu ändern, die auf mehrere Server gehen müssen, und vermutlich mutliple Autoren für diese Änderungen, dann könnten Sie den Mesh-Dienst auf jedem Webserver setzen und als Autoren hinzugefügt, geändert oder entfernt Dateien, die die Updates würde automatisch geschoben werden. Was die Autoren gehen würden sie nur ihre Dateien auf ihren Computer zu einem normalen alten Ordner werden zu speichern.

Verwenden eines Bereitstellungswerkzeug, mit einem Prozess, der einer nach dem anderen, und der Rest des Systems entfaltet hält arbeitet (wie Mufaka gesagt). Dies ist ein bewährtes Verfahren, das sowohl mit Content-Dateien arbeiten und jedes kompilierte Stück der Anwendung (die bewirkt, dass eine Rückführung des asp.net Prozesses bereitstellen).

Im Hinblick auf die Rate von Updates das ist etwas, das Sie kontrollieren können. Lassen Sie den Updates durchläuft eine Warteschlange und hat einen einzigen Bereitstellungsprozess, der steuert, wenn jedes Element einzusetzen. Achtung: Dies bedeutet nicht, dass Sie jedes Update einzeln bearbeiten, wie Sie die aktuellen Updates in der Warteschlange greifen und implementieren sie zusammen. Weitere Aktualisierungen der Warteschlange ankommen, und werden bei Ihnen abgeholt, sobald die aktuellen Updates zu Ende ist.

Update: über die Fragen in dem Kommentar. Dies ist eine individuelle Lösung auf meiner Erfahrung mit schweren / langen Prozessen basieren, die kontrollierte ihre Rate von Updates benötigt. Ich habe nicht die Notwendigkeit zu verwenden, diesen Ansatz für Einsatzszenarien hatte, wie für eine solche dynamische Inhalte, die ich in der Regel mit einer Kombination von DB und Cache auf verschiedenen Ebenen gehen.

Die Warteschlange muss nicht die vollständige Information halten, es muß nur die entsprechenden Informationen (ids / Pfade) haben, die Ihr Prozess die Informationen passieren lassen den Publishing-Prozess mit einem externen Tool zu starten. Wie es benutzerdefinierter Code ist, können Sie es die Informationen veröffentlicht haben kommen, so müssen Sie sich nicht in dem Publishing-Prozess / Werkzeug damit umgehen.

Die DB Änderungen würden während des Veröffentlichungsprozesses erfolgen, wieder Sie müssen nur wissen, wo die Informationen für die erforderlichen Änderungen und lassen Sie das Publishing-Prozess / Werkzeug damit umgehen. msmq und eine benutzerdefinierte Implementierung mit den Daten in SQL Server in Bezug auf was für die Warteschlange zu verwenden, ist die Haupt, die ich verwendet habe. Die Warteschlange ist gerade dort die Geschwindigkeit des Updates zu steuern, so dass Sie nicht speziell etwas brauchen bei Einsätzen ausgerichtet.

Update 2: stellen Sie sicher, Ihre DB Änderungen sind rückwärtskompatibel. Das ist wirklich wichtig, wenn Sie drängen Änderungen an verschiedenen Servern leben.

Ihre IIS-Server Unter der Annahme, Windows Server 2003 R2 oder besser, auf jeden Fall schauen Sie in DFS-Replikation . Jeder Server hat seine eigene Kopie der Dateien, die ein gemeinsames Netzwerk Engpass wie viele andere eliminieren gegen gewarnt hat. Die Bereitstellung ist so einfach, wie Sie Ihre Änderungen an einem der Server in der Replikationsgruppe kopieren (eine Full-Mesh-Topologie vorausgesetzt). Replikation kümmert sich um den Rest automatisch einschließlich Remote Differential-Komprimierung, um nur die Deltas von Dateien zu senden, die sich geändert haben.

Wir sind ziemlich glücklich mit 4 Web-Server mit jeweils einer lokalen Kopie der Seiten und einem SQL Server mit einem über die Cluster fehlschlagen.

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top