IIS Staging

Hi zusammen,

wir sind wieder von Azure auf eigene gewechselt, weil mir die Preis-Leisung einfach nicht zugesagt hat und der VerwaltungsaufwandServer bei Azure doch höher war als gedacht. Wie auch immer, das einzige Feature, das ich vermisse, ist das Staging. Das bedeutet, man stellt 2 Webseiten mit der gleichen Konfiguration zur Verfügung, deployment auf die Staging Umgebung und fährt die Webseite hoch und tauscht dann Staging mit Production.

Hat jemand eine Idee, wie man das nachbilden kann? wir haben 3 Server die per Shared Configuration und DFS synchronisiert werden. Man könnte für das Staging beispielsweise 2 Webseiten anlegen und das Binding und den Namen der Seiten swappen (dann bleibt der App-Pool gleich!). Allerdings muss das in der richtigen Reihenfolge und relativ unmittelbar passieren, weshalb man wohl 3 Agents laufen lassen müsste. Den Namen der Seite im IIS muss wegem Web Deployment geändert werden.

Der Loadbalancer ist gemanaged, evtl. könnte man hier auch ein Swapping einrichten. Dann müsste nur der Namen der Webseite geändert werden, was weniger kritisch als das Binding ist. Evtl. kann man auch eine Dummy-Webseite für das Web-Deployment anlegen, die immer auf das Staging-Verzeichnis weist.

Würde mich über eine Idee freuen.

Web Farm Framework verwende ich auf eigenen Servern.

Du definierst eine Master Instanz. Aktualisierst Du die, aktualisiert das Framework automatisiert alles andere.
Während dem Deployment sorgt das Framework dafür, dass Anfragen an andere Server weitergeleitet werden.

Du kannst dabei auch zwei Farmen aufsetzen: eine Staging Farm und eine Production Farm.
Über den Lastausgleich (evtl ein Service Server, der die Synchronisation übernimmt.) kannst Du anschließend eine sofortiges "Update" fahren.
Ob die Menge dann aber günstiger ist weiß ich nicht. Für so ein Szenario sind ja schon einige VMs nötig.

Ich dachte das wurde eingesellt, bzw. nur für IIS 7 verfügbar.

Es wurde nicht eingestellt, sondern glaube ich einfach vergessen 😃
Prinzipiell funktioniert es auf IIS7 super (habe noch 2008er R2 Server) - aber ja auf IIS 8 funktioniert das ganze nicht mehr.

Was Du als Alternative machst ist im Grundzug dann ja egal.
Du brauchst eben eine Staging- und eine Production-Umgebung.

Wie Du dann die Daten aktualisierst (Web Deploy, PowerShell, DFS) ist dann ja prinzipiell egal.
Am Ende wird das Load Balancing entweder nach Rechts oder Links gelenkt.

Ja, das Problem dabei ist, dass ich nur begrenzt Kontrolle über den LB habe. Deshalb die Idee, das Binding zu swappen. Dann hat man zwar keine 0-Downtime, aber besser als ohne.

Das geht auch über die WebAdministration-Tools für .NET, man muss dazu aber:

1. Alle Bindings löschen, dann Commit
2. Kurz warten
3. Alle Bindings neu setzen, dann Commit

Dann kommt der IIS aber je nach Timing durcheinander und stoppt die Webseite, was ziemlich nervig ist. Deshalb muss man sich dann entweder Remote oder über einen Agent auf jedem Server neu mit dem IIS verbinden und die Seite starten. Das ganze geht relativ schnell (2,3 Sek), ist aber aufwändiger als gedacht. Deshalb habe ich auf eine einfache Lösung gehofft.

Du hast nun weniger Ressourcen zur Verfügung, deswegen macht es das etwas problematischer.
Worauf ich hinaus will:

Wenn Du zwei Umgebungen hast (dazu müssen das im kleinsten Fall 3 Server sein) dann brauchst Du das Binding nicht anfassen, sondern nutzt den LB als Umschalter.
Der Schaltet auf einen Knopfdruck von Production auf Staging und zurück.

Dazu ist wie gesagt die Kopie der Produktivumgebung notwendig ink aller Bindings. Ich weiß, dass eine - ohne den Namen nennen zu wollen - Firma bei Dir in der Umgebung das so macht.
Der LB schiebt dann eben nicht mehr die Anfragen in Umgebung 1, sondern in Umgebung 2.

Mehr oder weniger macht das WFF ja auch nicht. Nur, dass er eben aus einer großen Umgebung kurzfristig zwei kleine, virtuelle Umgebungen macht.
Aus Farm-Sicht: aus einem riesen Acker werden kurz zwei kleine. Erst wird der eine gesäht, dann der andere. Und dann isses wieder ein großer Acker 😃

Edit:
IIS8 Web Farm
Wenn ich mir Scenario: Build a Web Farm with IIS Servers anschaue scheint das doch zu gehen.

The first step in installing and configuring an** IIS 8 web farm **is to install IIS on the web servers and load balancing server. Then install Application Request Routing (ARR) on the load balancing server. Finally, set up your website on one of the web servers.

Nur wohl direkt über ARR

Das ist mir schon klar, so viel Isolierung brauche ich gar nicht, dafür gibts ja Test-Umgebungen. Das wäre zwar schön, aber dafür ist mir der Aufwand zu hoch im Moment. Mir gehts nur um die letzten 10 Minuten vor Deployment mit Live-Daten.

Ich bin mir gerade nicht sicher, wie das bei Azure ist. Wenn ich das gerade richtig in Erinnerung habe, ist es bei Azure Websites so, dass dort das Staging nichts extra kostet, bei Web Roles verdoppeln sich die Kosten (wenn man nicht irgendwie clever hoch- und runter fährt). Ich gehe deshalb davon aus, dass bei Websites die gleichen Resourcen mitgenutzt werden. Evtl. kriege ich die Loadbalancer-Leute dazu, das für mich ein Url-Rewriting einzurichten, z.B. von staging.site.de auf site01.site.de etc.

In Azure ist das eine weitere, eigene Instanz. Da Du diese aber nur fürs Staging nutzen kannst hat diese ja zwangsläufig den gleichen Hit an Ressourcen.
Daher entstehen auch keine weiteren Kosten.

Hi zusammen,

Wie wäre es mit:

* Stage und Prod haben dieselben Bindings, aber terminiert auf unterschiedliche IP'S
* Stage und Prod benutzen dieselbe Session & DB
* IP's im LB sind je nach Anwendung getrennt
* Im LB von Prod auf Stage (rein Server basierend, auf IP) umschalten lassen (und das andere zurück)
* Prod und Stage "logisch" tauschen

Das hängt ein wenig von eurem LB ab. Am einfachsten wäre es wohl, wenn man Regeln für die URL zu den physischen Servern angeben könnte oder wenn ihr mehrere öffentliche IP's habt.

stage.example.com -> 141.1.1.1 -> Real 192.168.1.1
live.example.com -> 141.1.1.2 -> Real 192.168.1.2, Real 192.168.1.3

Dann im LB die Real-Server tauschen (lassen). Die User merken nix, außer die Session wird gekillt.

Ansonsten ist ein Ausfall für die User wohl nicht unbemerkt. Sanft kann man das noch mit einem ändern des DNS auf ne andere LB-IP erledigen, dann wandert die Last je nach TTL.

Macht ihr den Umstieg programmatisch über System.Web.Administration oder so? (die 2,3 Sekunden deuten darauf hin)

Ich hab den Thread jetzt nicht ganz nachvollzogen, da ich mit Farmbetrieb weniger Erfahrungen habe, wir regeln alles über LB.

😃

Xynratron

Die Situation war bisher, dass wir das nicht über den LoadBalancer machen können. Das hat sich geändert.

Die Idee ist jetzt wie folgt:

Es gibt 2 Webseiten mit folgenden Bindings:

stageA.XXX.de
stageB.XXX.de

der Loadbalancer hat folgende Konfiguration:

www.XXX.de -> stageA.XXX.de
staging.www.XXX.de -> stageB.XXX.de

Über ein Skript können wir diese Konfiguration einfach tauschen.

Außerdem gibt es eine Webseite, die nur für das WebDeployment zuständig ist und die Abwechselnd auf das Verzeichnis von stageA oder stageB verweist, aber von außen nicht erreichbar ist. Wir brauchen so nur minimale Änderungen am IIS und können auch weiterhin Web Deployment nutzen.

Jetzt würde ich gerne die ursprüngliche URL wieder herstellen, damit man als Anwendungsentwickler transparent Entscheidungen auf BAsis der URL/Host treffen kann, z.B. Culture, Währungen etc.

Das würde der Loadbalancer die OriginalUrl als Header mitschicken, über Url-Rewrite könnte man evtl. die Url wieder herstellen:

<rule name="Header" patternSyntax="ECMAScript" stopProcessing="true">
  <match url=".*" />
  <conditions>
    <add input="{HTTP_ORIGINAL_URL}" pattern=".+" />
  </conditions>
  <action type="Rewrite" url="{HTTP_ORIGINAL_URL}" appendQueryString="true" logRewrittenUrl="true" />
 </rule>

Leider bekomme ich immer ein 404.4. Mit ASP.NET vNext könnte man das auch einfach über eine Owin-Middleware realisieren, denke ich, aber hier habe ich gerade keine Idee.

BTW: Habe das Thema mit der Url-Rewrite regel auch bei SO eingestellt. Ich will bewusst keine starke Isolierung. Das ist kein Test-System, es geht darum, kurz vor dem Release einer neuen Version noch einmal Fehler feststellen zu können, die typisch für das Production-System sind, ich will wenig einrichten und die Downtime reduzieren. Wir haben auch ein isolierteres Test-System.