Vorgehensweise bei einem WCF Server Update
Ich hätte da mal ein grundsätzliches Problem.
Ich bin in letzter Zeit immer mehr in Genuss von WCF gekommen, bin davon begeistert. Jetzt steh ich aber kurz vor dem Problem, dass ich den WCF Server updaten muss (kleiner Bugfix und es kommt eine neue Methode hinzu). Grundsätzlich ist das kein Problem, allerdings laufen wir im 24/24 Modus, und es können permament zahlreiche Anwendungen an dem WCF Service gebunden sein. Wenn ich jetzt den WCF update, muss ich dafür den Windows Service stoppen, in dem der WCF Server gehostet ist, meine Dateien updaten, und den Server wieder starten. Dadurch werden aber sämtliche offenen Sessions unbrauchbar, und die Clients legen sich auf die Nase. Ich könnte natürlich ein neues Connect beim Client durchführen, dadurch sind meine bestehenden serverseitigen Parameter aber flöten.
Wie geh ich da am besten vor, ohne jetzt extra einen riesen Aufwand für irgendwelche Recovery Massnahmen zu betreiben?
Hmm...ich glaube fast, dass du keine Chance hast. Du musst die Dienste kurz anhalten, beim WCF zumindest die *.dll ersetzen und dann starten (Das ist ja keine lange Zeit), trotzdem kommst du mMn nicht um ein stopp-copy-start nicht drumrum.
Eventuell Nachts machen? Wenn vermeidlich wenig Clients da sind und vorher Bescheid sagen (a la "Downtime von 10 Minuten")
gruß
nitro
wie wäre es die serverseitigen daten in einer XML vor dem / beim ausschalten wegzuschreiben und beim erneuten start wieder zu laden...
Von all den Sachen, die mir verloren gegangen, hab ich am meisten an meinem Verstand gehangen... MfG...
Dann hättest du trotzdem den Downtime, in der der Dienst "nix" tut...aber zumindest könntest du da weitermachen, wo du aufgehört hast...
Du könntest Durable Services verwenden, die die Session-Informationen in einer DB ablegen. Dann brauchst du noch einen HTTP-Proxy vor den WCF-Servern. Die neue Version eines Servers läuft dann auf einem anderen Port (bzw. Rechner) und mit dem Proxy schaltest du einfach die WCF-Server um.
Aber: Durable Services sind nicht wirklich interoperabel. Falls du du non-WCF-Client hast, musst du das Sessionshandling mit der DB per Hand implementieren (auch nicht weiter wild).
Was du damit natürlich nicht vermeiden kannst ist, dass laufende Request auf dem alten Server ins Leere laufen. Aber die Sessions sind wenigstens bei erneuter Anfrage wieder da.
Ansonsten bietet der neue HPC-Server Unterstützung für Failover und Load-Balancing von SOA-Architekturen. Guckst du hier:
Damit hast du die Möglichkeit zwischen WCF-Servern Sessions zu sharen. Wäre IMHO eine bessere Alternative als die Durable Sessions. Denn im Prinzip ist dein 24/7-Problem kein Problem des Services selbst und sollte daher eher durch die Infrastruktur - also den Cluster - behandelt werden.
Der Vorteil wäre hier auch: Falls neuer und alter Server parallel betrieben werden können, gehen neue Requests auf den neuen Server und die laufenden auf dem alten werden noch zuende gebracht. Erst wenn alle Sessions auf dem alten Server abgelaufen sind schaltest du ihn ab.
Ich persönlich würde dir bei hartem 24/7 unbedingt zu HPC raten, z.B. auch für Hot Failover.
Das Ganze ist mir eine recht difficile Thematik. Von HPC hab ich zwar vorher noch nie was gehört, scheint aber auch für uns hier auszuscheiden, da wohl ein Windows 2008 dienen muss, wir jedoch noch auf Windows 2003 setzen. Das ändert sich zwar höchstwahrscheinlich in den nächsten 12 Monaten, aber sicher ist das noch nicht.
Ich hab vorhin schonmal einen Beitrag hier geantwortert, der taucht aber nicht mehr auf. Deshalb gerne nochmal: Da der Service keine prozesskritischen Arbeiten ausführen muss, sondern nur dafür gedacht ist, einen Fingerprint Hash zu erhalten und daraus den User zu ermitteln, und dann die Rechte für eine gegebene Anwendung kontrolliert, ist das insofern nicht weiter kritisch, wenn der Server mal gestoppt wird. Den Client kann ich ja problemlos so aufbauen, dass der Anwender sich halt nochmalsauthentifizieren muss. Das its ja in 2 Sekunden erledigt. Und mehr Daten muss der WCF Server in diesem Fall nicht verwalten. Das Auslesen der Rechte ist zwar eine recht komlexe Thematik, aber als einziger Input dafür ist die ApplicationId und eine Fingerprint Hash nötig. Und wie gesagt, die kann der Client gegegenfalls ja nochmals liefern. Eine neue Fingerprintentnahme ist noch nicht mal zwingend notwendig, wenn sich der Client selbst den Hash merkt.
Dieses HPC schau ich mir aber auf jeden Fall trotzdem mal an, falls mal ein Wechsel auf Win2008 ansteht. Also vielen Dank für den Link zum PDF.
Da der Service keine prozesskritischen Arbeiten ausführen muss, sondern nur dafür gedacht ist, einen Fingerprint Hash zu erhalten und daraus den User zu ermitteln
Inwiefern sind da Sessions im Spiel? Oder meintest du damit einfach nur die aktuell laufenden Requests? Ohne Sessions ist das natürlich nur ein reines Failover-Szenario. Das kann du auch einfach mit einem Proxy abfackeln....
Inwiefern sind da Sessions im Spiel?
Durch den Hash wird der User authentifiziert, und der Server lädt die vordefinierten Rechte aus einer Datenbank für den authentifizierten Benutzer, und legt diese in einem Dictionary ab. Das Laden der Rechte ist ein recht aufwändiger Prozess, bei dem viele Faktoren mitspielen, und kann sogar an dynamische Bedingungen anknüpfe, die mittels eines Plugin Systems mit berücksichtigt werden. Dieses Laden der Benutzerrechte dauert in der Regel zwischen 1 und 2 Sekunden. Das beinhaltet auch das Authentifizieren des Benutzers über seinen Hash mittels einer COM Bibliothek.
Sind die Rechte aber einmal in der Dictionary geladen, so kann der Client schnell über ein CheckPolicy den Server abfragen, ob der authentifzierte User ein gewisses Recht hat oder nicht, indem der Server einfach in der vorgehaltenen Dictionary nachschaut. Un da sehr viele CheckPolicy durhcgeführt werden, würde das ständige Neuauthentifizieren und Nachladen aus der DB zu sehr auf die Performance drücken.