MS 2012 Server Update unterbricht die Datenaufzeichnung

[jobo]

Zitat von generic:

@Jobo es ist doch immer nur eine Frage der Technik.

Ja natürlich und eine Frage des Geldes wohl, wie man so lesen kann.
24x7x365 war allerdings nicht explizit gefragt.

Ich hab keine Ahnung, was der TE wirklich liefern muss, ob es eher ein kosmetisches Problem ist, nice to have, schwierige Vertragslage und was es da so alles gibt...
Kundensituation sind m.E. immer recht unterschiedlich, wenn man nicht eine absolute Standardsoftware verkauft, wo es einem "egal" sein kann. Die einen machen gut mit, kommunizieren klar und sind engagiert und bei den anderen hat man schon gar keine Lust mehr, weiter nach (faulen) Kompromissen zu suchen.

Es ändert alles schon mal nichts an der Haltung des Kunden selbst, der schon mit dem bestehenden System ja angeblich nicht sehr konstruktiv umgeht. Einfach unverständlich.

Etwas Geld in Hardware zu pumpen, plus mehrfach Lizenzen für OS /Clustersoftware usw. ist auch kein Problem, Geld kann man immer ausgeben. Aber wenn ich mich richtig erinnere war bereits von einem 2012er Server die Rede. Also nicht gerade der heiße Sch...
Sieht nach Sparlösung aus.

Ich meine, man kann auch mit bescheidenen Mitteln Tag und Nacht Logfiles schreiben. Ich würde es vielleicht nicht 24x7x365 nennen, aber evtl reicht ja x363. Das die letzten Prozent oder Promille von irgendwas in der EDV oft nicht lineare Kostensteigerungen bedeuten, ist ja doch den meisten klar.

Einen robusten Client mit Buffering zu haben, ist natürlich auch nicht verkehrt. Der ist offenbar nicht vorhanden und damit keine Sofortlösung.

[himitsu]

Den Server verdoppeln?

Das System live spiegeln und bei einem Update die IP auf den anderen Server umleiten. (oder die Clienten versuchen sich bei Trennung mit der jeweils anderen IP/Port zu verbinden)
Das Einspielen der Updates natürlich nicht gleichzeitig.

Und nebenbei habt ihr auch gleich ein Notfall-/Backupsystem.


Ein lokaler Cache in jedem Client wäre da aber doch bestimmt die kostengünstigere Lösung.
Falls die Anwendung nicht verändert werden kann, lokal einen kleinen DB-Server, der die Daten annimmt und auch zeitverzögert an den großen DB-Server weiterreicht. Der Client dann einfach auf localhost connecten.

[mensch72]

..."Ich meine, man kann auch mit bescheidenen Mitteln Tag und Nacht Logfiles schreiben. Ich würde es vielleicht nicht 24x7x365 nennen, aber evtl reicht ja x363. Das die letzten Prozent oder Promille von irgendwas in der EDV oft nicht lineare Kostensteigerungen bedeuten, ist ja doch den meisten klar."...

Exakt so argumentiere Ich auch!
- ...und setze mich so absichtlich oft in die Nesseln, weil ich eben absichtlich keine "99,9999..% Garantien" gebe, und nur mit dafür aber zumindest technisch/statistisch realisitischen Wahrscheinlichkeiten von ~98% argumentiere... wenn ein Kunde (bzw. dessen IT) sowas im Konsens auch so sieht und selbst zum "Restrisiko" ein technisch vernünftiges Konzept mitträgt und so beauftragt, werde ich im WorstCase den Kunden im Rahmen aller unserer technischem Möglichkeiten nicht hängen lassen!
- ... bei wieder besseres/dokumentiertes Wissen absichtlich so gewollten Sparbrötchen-Lösungen würde ich zwar selbst abunzu gerne "Nein" sagen, aber wenn der Kunde einen passenden Vertrag ohne "Garantien unsererseits" unbedingt so will, dann soll es eben so sein. WorstCase wird es dann aber sehr teuer und dauert eventuell sehr lange wenn unsererseits dann Lösungen "auch nur versucht" werden


Für unsere Kunden erarbeiten wir stets "Ergebnis offen" gemäß der "wirklichen Bedürfnisse" ein technisch vernünftiges Konzept... (Von "HighEnd" mit ClusterDB + ClusterOS + ClusterVMs + mehrfach redundanter PC & Netzwerkhardware bis "LowEnd" nur mit StreamingClient->FiFoBuffer->Single(DB)Server)... wenn ein Kunde uns das zahlt, ist es uns sogar egal ob er das dann mit uns realisiert, oder es extern vergibt.


..."Einen robusten Client mit Buffering zu haben, ist natürlich auch nicht verkehrt. Der ist offenbar nicht vorhanden und damit keine Sofortlösung."...
=> jo, aber aus meiner Sicht wäre dies unter Berücksichtigung aller gegebenen Info mit dem sturem Serverbetreiber hier eine der wohl "technisch sinnvollsten" Lösungen