MS 2012 Server Update unterbricht die Datenaufzeichnung

[Chemiker]

Hallo zusammen,

wir haben folgendes Problem:

Auf ein MS 2012 Server läuft in einer VM ein Firebird – Server, durch das Einspielen der MS Server – Updates (meist gegen 5°° sonntagsmorgens) ist der Firebird Server eine Zeitlang nicht erreichbar.
Auf dem Firebird Server werden im 24/7 Betrieb Messdaten abgespeichert. Kommt es zu einer Unterbrechung durch die Updates vom MS – Server wird ein Timeout ausgelöst und die Aufzeichnung der Messdaten wird unterbrochen und auch nach dem Update nicht wiederaufgenommen.

Die MS Updates müssen aus Sicherheitsgründen aufgespielt werden. Die Wahl der Uhrzeit und des Tags ist natürlich für die Verwaltung optimal, aber nicht für die Produktion.

Welche Möglichkeiten gibt es, dieses Problem zu umgehen, oder zu beseitigen?

Bis bald Chemiker

[RWarnecke]

Verursachen die Updates einen kompletten Neustart des Servers ? Wenn ja, dann hast Du meines Wissens nur eine Chance deine VM wieder per Aufgabenplanung zu starten.

[Bernhard Geyer]

Komplett verhindern wist du dies Abbrüche unter Windows nicht.
Nur verschieben so das du möglichst schnell reagieren kann.

Evtl wäre ein Linux-System für deine DB besser.

[Chemiker]

Hallo zusammen,

serverseitig kann ich keine Änderungen durchführen (man ist wenig kooperativ).

Als Lösung müsste ich eine Möglichkeit schaffen die Daten auf einen Client zwischen zu speichern. Als Worstcase-Szenario kann man davon ausgehen, dass ca. 100 Mio. Datensätze zwischen gespeichert werden müssen.

Grundsätzlich soll alles über den MS – Server laufen, damit die Daten an 28 Stellen abrufbar sind, steht dieser aber nicht zur Verfügung, währe gut wenigstens die Messdaten zu haben um sie später aufzuspielen.

Wie könnte man dieses Problem optimal lösen?

Bis bald Chemiker

[mensch72]

Zufällig habe ich für unsere 24x7 Finanzdaten gleiches Problem
1. kann bei uns jeder Client mit 2 Servern arbeiten
2. wenn es keine 2 kompletten Server gibt, konfiguruieren wir einen "intelligenten" FifoProxyServer als Extraanwendung(ne Kombi aus Server und Client mit FiFoPuffer und (Re)Sync-Logik dazwischen)... (wegen der möglichen großen Datenmengen kann dieser lokale Fifo oft nicht auf dem gleichem Client (I)PC mitlaufen, wo die Daten getrackt werden)

"Optimal lösen" ist schwer zu beantworten, denn hier muss im State "GapOutOfSync" unterschieden werden,
-> ob solange noch nicht weitergereichte FiFo Pufferdaten lokal vorhanden, man aktuelle Daten weiter erstmal nur in den lokalen FoFo gehen
* Vorteil: die HauptServerdaten sind immer seitweit irgendmöglich vollständig und es gibt dort keine DatenGaps die wenig später wieder weg sind
* Nachteil: es dauert etwas bis nach den Pufferdaten wieder Livedaten in der HauptDB ankommen
=> mit recht wenig Aufwand sehr betriebssicher zu realisieren

-> oder wenn Verbindung "wieder steht" trotz "Gap"(Weil "noch nicht" alle Pufferdaten eingetragen sind) aktuelle Daten schon wieder in die HauptDB reingehen
* Vorteil: in der HauptDB kommen "schnellst möglich" wieder aktuellste Daten an
* Nachteil: in der HauptDB gibt es temporäre Datengaps, was zu unterschiedlichen (Auswerte)Ergebnissen bei wiederholter Datenabfrage führen kann
=> es braucht im Server und in allen Clients recht viel Aufwand die States Offline,OutOfSync,GapOutOfSync,InSync sauber zu handeln


Wir haben je nach Funktion des Abfrageclients beides und auch noch über 2 Server realisiert
- Monitor/Trigger Clients arbeiten nur mit den neuesten Daten ohne History, also ohne Probleme bei Datengaps
- History/Archiv Clients arbeiten nur mit den jeweils als "vollständig" markierten HauptDB Daten (alle Abfrageergebnisse sind hier bei wiederholter Abfrage gleich)
- nur Rule/Function Clients nutzen "alle" unter Beachtung der verschiedenen SystemStates(also spziell ausprogrammierte Logik mit sich später möglicherweise noch mal veränderlichen Ergebnissen sinnvoll umzugehen)

[jobo]

Das ist schon eine etwas merkwürdige Sache oder?!
Im Grunde gibt es eine klare Antwort, wurde schon genannt und lautet Linux.

Es ist mir total schleierhaft, wie MS unter solchen Bedingungen überhaupt in der Lage ist, seinen Server als Server zu verkaufen, also als seriöses, professionelles System.
Und es ist mir auch schleierhaft, wie ein Unternehmen darauf bestehen kann, eine möglichst schlechte Lösung mit möglichst wenig Support an den Softwarelieferanten für die eigenen Daten zu betreiben.

Aber mal konstruktiv:
Auch wenn wenig entgegenkommen gezeigt wird und ich nicht weiß, welchen Spielraum ihr habt. Es gibt neuere Server Versionen als 2012 und - so war es zumindest mal- hat MS gemäß der Marktbedürfnisse oft Verbesserungen in Richtung Häufigkeit der Neustarts gebracht (u.a.). (Aber vielleicht ist das nicht mehr so, damit man ein kleines Druckmittel Richtung Cloud hat- wie geht das da bloß, dass die immer läuft- wirklich merkwürdig)
Läuft auf dem Server noch was anderes als der FB? 95% des Systems (GUI, Dienste, Domain, ..) werden wahrscheinlich dafür nicht gebraucht. Alles was nicht drauf ist, wird nicht aktualisiert, fehlt als Reboot Grund.
Ggf. kann man auch den Updateprozess selbst mal hinterfragen, hier wird ggF. mehr getan als notwendig / sinnvoll. Viele Updates kommen eigentlich ohne Reboot aus.


Naja und Stichwort Spielraum: Wenn ihr wenig habt, könnt Ihr natürlich clientseitige Lösungen für Serverausfall einbauen, das dürfte zumindest für reine Logdaten kaum dramatisch sein, da sie keine Datenkonflikten hervorrufen.