Keine Ausfallzeiten für Uploads / Rollbacks in IIS

Ich bin mir nicht sicher, ob dies der richtige Weg ist, um diese Frage zu stellen, aber im Grunde möchte ich Folgendes tun:

1.) Übertragen Sie ein Changeset auf eine Site in IIS.
2.) Unterbrechen Sie die Benutzer nicht.
3.) Müheloses Zurückrollen.

Es gibt also ein paar Dinge, von denen ich weiß, dass sie passieren müssen:

1.) Out of Proc-Sitzung - behandelt
2.) Out of Proc-Cache - behandelt

Also die Fragen, die bleiben:
1.) Wie kann ich verhindern, dass die Benutzer unterbrochen werden? Wenn ich nur die Dateien in den Papierkorb hochlade, wird die App recycelt und es dauert mehr als 10 Sekunden, bis sie wieder online ist.
2.) Wie kann ich mühelos ein Rollback durchführen?

Ich dachte, eine mögliche Lösung wäre, zwei Sites in IIS einzurichten, eine öffentliche und eine private. Uploads gehen auf privat und werden aufgewärmt. Nach dem Aufwärmen werden die Sites getauscht. Ein Rollback beinhaltet nur das Wechseln zu privat ohne einen Upload.

Dies scheint in der Theorie solide zu sein, aber ich bin mir der Mechanik nicht sicher. Irgendwelche Ideen?

Hier ist, wie ich dieses Problem angehen würde - denken Sie daran, dass ich dies noch nie getan habe. Es handelt sich nur um Konzepte, die ich ein wenig in meiner Entwicklungsumgebung getestet habe. Sie sollten in der Lage sein, mit diesem und einigen Skripten in der Sprache Ihrer Wahl ein ziemlich robustes Framework einzurichten. Grundsätzlich werden wir eine Ghetto-Lastausgleichsumgebung einrichten und diese verwenden, um zwischen der neuen und der alten Site zu wechseln.

Um es einzurichten, benötigen Sie:

• ARR-Modul ( IIS Application Request Routing )
• IIS- Webbereitstellungstool (msdeploy)
• 3 verschiedene IIS-Websites (mit 3 verschiedenen IP-Adressen - nur die Verwendung von Ports oder Host-Headern funktioniert hier möglicherweise nicht)

Installieren Sie zunächst ARR.

Richten Sie die 3 Websites in IIS ein:

• Website 1 ist beispielsweise die Website, mit der Ihre Benutzer tatsächlich verbunden sind http://192.168.1.1/. Dies ist auch die ARR-Site. Richten Sie dazu einfach ein leeres Verzeichnis ein, auf das verwiesen werden soll, und legen Sie es in einem eigenen App-Pool ab. Richten Sie den App-Pool gemäß diesen Anweisungen so ein , dass keine Zeitüberschreitung auftritt .
• Website 2 und 3 sind die Websites, auf denen Ihre Inhalte tatsächlich gehostet werden. Diese müssen auf ihren eigenen IPs und aufgrund der Funktionsweise von ARR auf einem anderen Port als Website 1 sein. Sagen wir, sie sind http://192.168.1.2:8080und http://192.168.1.3:8080. Sie sollten sich auch in ihren eigenen App-Pools befinden und auf verschiedene Verzeichnisse im Dateisystem verweisen (normalerweise haben beide Verzeichnisse jedoch denselben Inhalt).

Nach der Installation von ARR gibt es im IIS-Manager eine neue Kategorie namens "Serverfarmen". Klicken Sie mit der rechten Maustaste darauf, und erstellen Sie eine neue Farm.

• Geben Sie ihm einen Namen, der für Sie von Bedeutung ist
• Fügen Sie Webserver 2 und Webserver 3 als Server hinzu. Klicken Sie auf die Schaltfläche "Erweiterte Einstellungen", öffnen Sie die Kategorie "applicationRequestRouting" und ändern Sie den httpPort für jeden Server auf 8080
• Beenden Sie den Assistenten. Sie werden gefragt, ob Sie URL-Rewrite-Regeln erstellen möchten. Klicken Sie auf Ja
• Sie haben jetzt eine Serverfarm. Um die Konfiguration abzuschließen, wechseln Sie zur Farm und klicken Sie auf die Schaltfläche "Proxy-Konfiguration". Aktivieren Sie "Host in Antwortheader umkehren" und übernehmen Sie die Änderungen
• Wechseln Sie im IIS-Manager zur Serverkategorie auf Stammebene und klicken Sie auf die Schaltfläche URL-Umschreiben. Es wird eine Regel für Ihre Farm erstellt
  • Doppelklicken Sie auf die Regel, um zu den Einstellungen zu gelangen
  • Öffnen Sie das Feld Bedingungen
  • Neue Bedingung hinzufügen für {SERVER_PORT}stimmt nicht mit 8080 überein
  • Übernehmen Sie die Änderungen

An diesem Punkt haben Sie die Grundlagen dessen, was wir benötigen, um Ihre Anfrage zu erfüllen. Wenn Sie zu gehen, erhalten http://192.168.1.1/Sie Ihre Website entweder von Website 1 oder von Website 2, aber es ist völlig nahtlos, dass es andere Websites gibt.

Sie können jetzt Folgendes tun, wenn Sie eine neue Version Ihrer Anwendung bereitstellen möchten:

• Beenden Sie 1 der Server in Ihrer Farm (wechseln Sie in den Serverfarmtools zu "Überwachung und Verwaltung", wählen Sie einen Server aus und klicken Sie auf "Server ordnungsgemäß nicht verfügbar machen".)
• Stellen Sie Ihre neue Version der Site auf dem System bereit, das offline ist
• wärmen Sie die Site, die offline ist, mit ihrer alternativen IP / ihrem alternativen Port auf
• Stellen Sie die Site der Farm wieder zur Verfügung
• Wiederholen Sie den Vorgang für den anderen Server

Das Web Deployment-Tool kommt zum Einsatz, wenn Sie über Skripten für all dies sprechen. Es ist sehr einfach, ein Paket für Ihre Anwendung zu erstellen und über die Befehlszeile bereitzustellen. Sie können das Paket dann auch problemlos zurücksetzen, wenn Probleme auftreten. ARR ist auch mit den Microsoft.Web.AdministrationDLLs skriptfähig .

Eine andere Sache - wenn Sie tatsächlich unter Windows 2008 R2 (IIS 7.5) arbeiten, werfen Sie einen Blick auf das Modul zum Aufwärmen von Anwendungen - sollte das Aufwärmen auch für Sie einfacher sein.

MattB schlug es aus dem Wasser. +1 Ich werde mit mehr Details antworten, aber ich werde nicht versuchen, seine Punkte zu sammeln. Ich werde hinzufügen, was er sagte.

Ich habe ein ähnliches Setup wie er es beschrieben hat und es funktioniert großartig. ARR ist der richtige Weg, auch auf einem einzelnen Server.

Ein paar Dinge möchte ich jedoch hinzufügen.

Erstellen Sie die beiden Sites, wie von Matt empfohlen. Nennen Sie sie so etwas wie yoursite.com01 und yoursite.com02.

Erstellen Sie zwei URL-Rewrite-Regeln. Eine für www.yourdomain.com und eine weitere für staging.yourdomain.com. Verwenden Sie für die Produktion {HTTP_HOST} mit einem Wert von (^ www.ihredomain.com $) | (yourIP). (oder welche Bindung Sie auch bevorzugen) Verwenden Sie zum Staging {HTTP_HOST} mit dem Wert (^ staging.yourdomain.com $). Rufen Sie die Regeln yoursite.com und staging.yoursite.com auf.

Binden Sie Rule = yoursite.com an site = yoursite.com01 und rule = staging.yoursite.com an site = yoursite.com02.

Richten Sie FTP auf staging.yoursite.com ein.

Der Produktionsdatenverkehr wird jetzt an Rule = staging.yoursite.com und Site = yoursite.com01 gesendet. Ins Gegenteil taumeln.

Sie können zu jedem Zeitpunkt zum Staging bereitstellen, testen, vorab starten, von anderen Personen testen lassen usw. Machen Sie dies tagsüber, es spielt keine Rolle. Stellen Sie jedes Mal auf demselben FTP-Konto bereit. Funktioniert hervorragend mit Build-Servern.

Nehmen Sie dann einfach drei Änderungen vor, wenn Sie bereit sind, live zu gehen: - Verschieben Sie die FTP-Bindung von yoursite.com02 auf yoursite.com01. - Ändern Sie die URL-Umschreiberegel yoursite.com so, dass sie auf yoursite.com02 verweist. yoursite.com zeigt auf yoursite.com01

Jetzt haben Sie keine Ausfallzeiten, sofortiges Umschalten und sofortige Rollback-Funktionalität!

Ihr einziger zu berücksichtigender Punkt ist der Sitzungsstatus außerhalb des Prozesses. Stellen Sie sicher, dass Ihr Statusserver beide Site-IDs akzeptiert, damit Sie den Sitzungsstatus während des Austauschs nicht verlieren.

Beachten Sie auch, dass dies nur Web ist und keine Datenbank.

Verwenden Sie für die Skripterstellung den Konfigurationseditor. Nehmen Sie die gewünschten Änderungen vor und klicken Sie dann auf "Skript generieren". Sie erhalten C # -, appcmd- oder AHAdmin-Code.

Ich habe dies für ein paar Monate mit einem Webseiten-Front-End eingerichtet, um Instanzen auszutauschen, und ich schaue nie zurück. Dadurch werden Bereitstellungen im Vergleich zu herkömmlichen Bereitstellungen so erfrischend.