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.

[mensch72]

egal ob Linux oder Windows Server als OS... ein OneWay "SingleClient"->"SingleServer" Konzept für 24x7 Datenaufzeichnung/Datenzugriff gilt per Definition als dafür untauglich.

Erst ab DoppelServer oder wenigstens separaten/lokalem Fifo-Puffer macht es praktisch überhaupt Sinn, sowas "als 24x7 fähig" zu benennen(verkaufen) und zu betreiben.
(lokaler FiFo dienst nebenbei auch als schneller Cache, wenn die Netzwerkverbindung zum Server mal voll ausgelastet)


Wer nicht selbst programmieren will, kann auch "nur Geld ausgeben"... ClusterKonfiguration mit passendem OS und passender ClusterDB wäre dann das Stichwort... das ist möglich und funktioniert dann mit passendem Hardware und Netzwerk konzept wirklich "garantiert(99,99%)" 24x7 unterbrechungsfrei.
Wenn mit Virtualisierung dann zusätzlich noch ClusterVMs, als mindestens 2 große VMwareServer mit Verwaltungsserver, um die VMs bei Bedarf "live" hin und her zu schieben... aber ganz ruckelfrei mit StandardDBs klappt das nicht... da braucht es doch noch einen eigenen externen FiFo Puffer.
(Wenn der Betreiber aber schon beim Server so auf Sparbrötchen setzt und unflexibel ist, fällt eben geschriebenes eh unter den Tisch)


Linux oder Windows als Server bleibt eine reine Geschmacksfrage, es kommt bei 24x7 auf ein vernünftiges möglichst eigensicheres(AutoReStart) System und Softwarekonzept an.
(Bei Windows kostet es nur am Anfang mehr wegen der Lizenzen und der etwas höheren OS eigenen Hardwareanforderungen. Diese Kosten sind bei 24x7 Systemen aber völlig unwichtig)


Wenn alles so bleibt, ist es doch aucht toll: der Kunde hat oft Datenlücken und ihr damit stets Supportaufträge, das manuell irgenwie immer wieder zu zu patchen/nachzutragen, damit die langzeit Auswertungen wenigstens einigermaßen stimmen... wenn ihr das bezahlt bekommt und die Zeit/Leute dafür habt, dann ist doch auch alles super:)

[generic]

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

Wir haben auch Microsoft Server und diese benötigen auch Windows Updates.
Unterschied ist wir haben keine Firebird Datenbank sondern betreiben eine im Cluster laufenden Microsoft SQL-Server.
Da lässt sich jeder Host nach belieben abschalten/updaten/runterfahren was auch immer.

Nur das spielt in einer anderen Preisklasse als der Firebird.

Aber m*72 hat es ja auch bereits durchblicken lassen.

Eine Software-Lizenzkosten günstige Variante wäre eine Entkopplung mit einen Message-Queue Server - den im Cluster betreiben und FB nur als Storage-Backend nehmen.
RabbitMQ wäre eine Variante: https://www.rabbitmq.com/clustering.html

Probleme lassen sich nur verschieben, dafür musst du Entwicklungskosten zahlen. Vermutlich teurer als ein MS-SQL Server Cluster.

[jobo]

Zitat:

Zitat von generic (Beitrag 1389195)

@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.