Entwickler-Ecke :: Thema anzeigen

Peter2002 - So 12.12.10 22:54
Titel: Hochverfügbarkeit

Hallo,

ich habe ein System, das in verschiedene Module (Windows-Dienste) aufgeteilt ist. Dieses System soll hoch verfügbar gemacht werden.

Habt ihr Strategien oder Konzepte, wie ich sowas veranstalten kann? Nur die Software betreffend.
Also, wie z.B. finde ich heraus, ob ein Dienst einen unerwarteten Fehler hat und deshalb seinen Aufgabe nicht mehr erfüllen kann? Oder ob er in eine Endlosschleife geraten ist? Um dann evtl. eine neue Instanz zu starten, die den Job übernimmt.

jaenicke - So 12.12.10 23:34

Ich würde einen Watchdog starten, der zweimal läuft. Wenn nur eine Instanz läuft, wird eine zweite gestartet. Eine der beiden kümmert sich dann um die Überwachung des zu überwachenden Programms. Zum Beispiel der Watchdog mit der höheren Process-ID.

Dem zu überwachenden Programm wird dann eine Message geschickt, auf die geantwortet werden muss. Kommt keine Antwort, reagiert das Programm nicht mehr.

So haben das sowohl Antivirenprogramme früher gemacht als auch Viren oft.

Quake User - Mo 13.12.10 04:58

Peter2002 hat folgendes geschrieben :

Hochverfügbarkeit bedeutet aber noch mehr. Warum lässt Du nicht 10 Instanzen Deiner Dienste laufen und programmierst einen Load Balancer, der die Anfragen entgegen nimmt und auf einen freien Dienst verteilt. Antwortet Das System zu langsam, startet der Load Balancer zusätzliche Dienste. Antwortet einer der Deinste nicht nach einem Timeout, wird er beendet und einer neuer gestartet.

Ein Watch Dog ist eine gute Idee, er müsste aber dann auf einem anderen Rechner laufen. Wenn der Rechner abstürzt, läuft auch der Watch Dog nicht mehr. Der Load Balancer könnte von vorn herein auf einem anderen Rechner laufen. So wäre Dein System noch durch den Einsatz von mehreren Servern skalierbar.

Hochverfügbarkeit bezeichnet die Fähigkeit eines Systems, trotz Ausfall von Komponenten (deffekt, beschäftigt, abgestürzt, Prozess unerwartet beendet...) mit einer hohen Wahrscheinlichkeit einen ununterbrochenen Betrieb zu gewährleisten.

Peter2002 - Mo 13.12.10 10:54

Momentan würde es vollkommen reichen, wenn ich sicherstellen kann, dass alle Prozesse laufen und ihren Job tuen. Auf einer einzigen Maschine.
Ist der ganze Rechner weg (Hardwarefehler), soll ein zweiter übernehemen. Das wäre dann ein Watchdog auf der 2. Maschine, die den Watchdog der 1. prüft?

Wie funktioniert ein solcher Watchdog? Wie kann ich erkennen, ob ein Thread sich verarbschiedet hat, obwohl er da sein sollte; ob er in einer Endlosschleife ist; unbehandelte Exceptions ...
Ob der Prozess vorhanden ist, ist ja recht leicht rauszufinden, aber ob er auch das tut, was er tun soll?

jaenicke - Mo 13.12.10 12:04

Peter2002 hat folgendes geschrieben :

Wie kann ich erkennen, ob ein Thread sich verarbschiedet hat, obwohl er da sein sollte; ob er in einer Endlosschleife ist; unbehandelte Exceptions ...

Wie gesagt:

jaenicke hat folgendes geschrieben :

Dem zu überwachenden Programm wird dann eine Message geschickt, auf die geantwortet werden muss. Kommt keine Antwort, reagiert das Programm nicht mehr.

Bei einer Antwort kannst du den Status ja mitschicken. Wenn das Programm antworten kann, weiß es auch in welchem Zustand es ist. Und wenn es nicht mehr antworten kann, ist eh alles klar.
Das gilt natürlich genauso für Threads innerhalb eines Programms.

Peter2002 - Mo 13.12.10 12:13

bummi hat folgendes geschrieben :

Die Idee mit dem Ringpuffer und Timestamps gefällt Dir nicht ?

Sorry. hab ich überlesen. Aber warum ein Ringpuffer?

@jaenicke: D.h. ein Dienst überwacht sich selbst? Also er checkt alle sein Threads und antwortet dem Watchdog?

Peter2002 - Di 21.12.10 20:09

Wenn ich nun einen Watchdog auf einer anderen Maschnine habe, der die primäre überwacht und feststellt, dass diese nicht mehr verfügbar ist, soll die sekundäre aktiviert werden. Die sollte sinnigerweise ja auf die gleiche IP reagieren, damit die Clients nichts davon mitbekommen.
Wie stelle ich nun sicher, dass ich mir keinen IP-Adressen-Konfilkt einhandle? Wenn der ausgefallenen Rechner wieder gestartet wird hat diese ja noch immer seine IP, weleche der sekundäre inzwischen ja auch hat.

jaenicke - Di 21.12.10 20:18

Wenn es auch um die Verfügbarkeit der Rechner selbst geht, kommen wir in Bereiche, in denen Virtualisierung sinnvoll ist. Denn anders kannst du nicht sicherstellen, dass du im Falle eines Absturzes automatisiert oder aus der Ferne eine Fehlerbehebung hinbekommst.

Wenn du virtuelle Server verwendest, kannst du diese von außen steuern und neustarten usw.

Je nach Anwendungsfall bietet es sich hier aber auch an direkt Server zu mieten. Denn in einem Rechenzentrum ist eine sehr hohe Verfügbarkeit gewährleistet und wenn etwas kaputtgeht, ist auch jemand da, der sich darum kümmern kann.

Die Cloud bzw. Cloud Computing ist auch ein Stichwort. Programmiersprachen wie Delphi unterstützen cloudbasierte Dienste direkt. Das heißt man kann sich entsprechende Kapazitäten von z.B. Amazon (Amazon Web Services) mieten und je nach Bedarf auch erweitern, wenn eine höhere Last anfällt bzw. erwartet wird.

Es ist alles eine Frage der Anforderungen und des finanziellen Rahmens.

Peter2002 - Di 21.12.10 20:59

Danke für die Hinweise.

Es geht hierbei um ein Etikettiersystem, welches in der Produktion in unterschiedlichen Takt-Zeiten (ca. 30 Sek.) verschiedene Etiketten drucken soll. Von daher ist es vermutlich sinnvoller, wenn alles innerhalb dieses Netzes läuft.
Cloud-Computing oder ext. Rechenzentren kommen für mich eher nicht in Frage.
Virtualisierung wär aber eine Option. Nur habe ich noch nicht begriffen, wie ich mit VMs das besser machen kann.
Die Situation bleibt doch die gleiche, A fällt aus, B übernimmt (auch die IP), A wird wieder gestartet und perfekt ist der IP-Konflikt?
Oder muss ich mit diesem Risiko einfach leben und sicher sein, dass A erst mal ohne Netzwerkanbindug startet.

Gerd Kayser - Di 21.12.10 23:22

Peter2002 hat folgendes geschrieben :

Die Situation bleibt doch die gleiche, A fällt aus, B übernimmt (auch die IP), A wird wieder gestartet und perfekt ist der IP-Konflikt?

Die einfachste Lösung wäre doch sicherlich, wenn die Clients beide IP-Adressen kennen (von Rechner A und B).

Peter2002 - Mi 22.12.10 10:22

Gerd Kayser hat folgendes geschrieben :

Die einfachste Lösung wäre doch sicherlich, wenn die Clients beide IP-Adressen kennen (von Rechner A und B).

Ja und nein. Genau das will ich eigentlich nicht. Kommt ein weiteres Programm hinzu, das mit dem Service kommunizieren will, fang ich wieder von vorn an, weil ich die Logik hier auch wieder brauch...
Viel schöner ist es doch, wenn die Clients gar nicht mitbekommen, dass jetzt ein anderer Rechner die Arbeit übernimmt.

Gerd Kayser - Mi 22.12.10 10:42

Peter2002 hat folgendes geschrieben :

Viel schöner ist es doch, wenn die Clients gar nicht mitbekommen, dass jetzt ein anderer Rechner die Arbeit übernimmt.

Bei Deiner Variante hast Du einen Rechner A, der evtl. durch zahlreiche Anfragen ins Schwitzen kommt, während Rechner B in der Ecke vor sich hin staubt.
Besser wäre es doch, wenn die Clients beide IP-Adressen kennen. Eine Hälfte der Clients rufen vorzugsweise Rechner A, die andere Hälfte vorzugsweise Rechner B. Nur wenn eine Verbindung z. B. durch Rechnerausfall nicht zustande kommt, wird die alternative Adresse (und damit der andere Rechner) gerufen.
Vorteil: Lastverteilung und beide Rechner im produktiven Einsatz. Wenn einer der Rechner ausfällt (geplant oder ungeplant), dann steht immer noch der andere Produktionsrechner bereit. Und beim Reaktivieren des ausgefallenen Rechners sind keine weiteren Maßnahmen erforderlich.

Peter2002 - Mi 22.12.10 11:37

OK. Im Sinne einer Lastverteilung und dass der zweite Rechner nicht ungenutzt bleibt, ist die Idee top.
Mein Problem ist nur, dass ich die bestehen Clients nicht unbedingt ändern möchte und ggf. andere Systeme Zufgriff haben sollen, auf die ich evtl. keinen Einfluss habe.
Von daher bevorzuge ich eine serverseitige Lösung, welche aber auch sicher funktionieren muss. Mit einem IP-Konfilikt z.B. hätte ich dann ja leider das Gegenteil erreicht.

jaenicke - Mi 22.12.10 12:01

Also grundsätzlich gibt es bei deiner Herangehensweise irgendein Gerät, welches das auch ist, das über die IP erreichbar ist und sein muss. Ob das jetzt die Zugriffe weiterleitet oder wie auch immer, irgendein Gerät muss über die eine IP angesprochen werden.

Eine Möglichkeit wäre ein elektronischer Schalter. Dann könnte ein zweiter Rechner den ersten überwachen. Funktioniert der nicht mehr, schaltet der zweite den Switch zum ersten Rechner aus und aktiviert eine zweite Netzwerkkarte, die mit der selben IP konfiguriert ist. Dann ist die IP wieder auf dem zweiten Rechner erreichbar.

Zudem muss der zweite Rechner natürlich sofort z.B. per E-Mail Bescheid geben, damit der Ausfall bekannt wird.

Auf diese Weise lässt sich das denke ich einfach und ohne große Kosten realisieren.

Eine andere Möglichkeit:
Ein Router wird über die IP auf dem Port angesprochen. Dort wird der Zugriff über eine Portweiterleitung auf einen PC weitergeleitet. Welcher das ist, ist dabei dann egal. Ein zweiter überwachender PC kann dann einfach die Portweiterleitung verändern.

Dass der Router selbst abschmiert, sollte bei einem guten Gerät sehr unwahrscheinlich sein, zudem kann man den auch an einen elektronischen Schalter anschließen, damit er von außen (durch einen der beiden PCs bei Nichterreichbarkeit) nach einem Absturz neugestartet werden kann.

Gerd Kayser - Mi 22.12.10 12:24

Peter2002 hat folgendes geschrieben :

OK. Im Sinne einer Lastverteilung und dass der zweite Rechner nicht ungenutzt bleibt, ist die Idee top.

Es gibt noch einen weiteren Vorteil meiner Lösung mit zwei produktiven PCs. Ein nicht genutzter PC weckt immer Begehrlichkeiten. Wenn kurzfristig für einen neuen Mitarbeiter ein PC benötigt wird, ist der Backup-Rechner meist im Gespräch, weil der andere PC ja bislang fehlerfrei lief. "Warum sollte genau in den nächsten Tagen der Produktionsrechner ausfallen?", wird sicherlich das Argument des Chefs sein. Ich kenne das noch aus meiner bisherigen Berufspraxis ...

Zitat:

Mein Problem ist nur, dass ich die bestehen Clients nicht unbedingt ändern möchte und ggf. andere Systeme Zufgriff haben sollen, auf die ich evtl. keinen Einfluss habe.

Auch eine einfache Hochverfügsbarkeitslösung ist nicht zum Nulltarif zu haben, sei es durch zusätzliche Hardware oder etwas höheren Programmieraufwand. Auch die Lösung von Jaenicke bedeutet, Geld in die Hand zu nehmen...

Peter2002 - Mi 22.12.10 14:24

jaenicke hat folgendes geschrieben :

[...]Eine Möglichkeit wäre ein elektronischer Schalter. [...]
Zudem muss der zweite Rechner natürlich sofort z.B. per E-Mail Bescheid geben, damit der Ausfall bekannt wird.[...]

Danke. Guter Hinweis mit der email.
Wie meinst du das mit dem elektronischen Schalter? Dem Ding einfach den Strom klauen?

Gerd Kayser hat folgendes geschrieben :

[...]weckt immer Begehrlichkeiten. Wenn kurzfristig für einen neuen Mitarbeiter ein PC benötigt wird, ist der Backup-Rechner meist im Gespräch, weil der andere PC ja bislang fehlerfrei lief. [...]

Sowas darfs aber nicht geben. Wenn gnadenlos Backup-Systeme abeschaltet werden, ist jede Diskusion bezüglich Hochverfügbarkeit hinfällig.

Gerd Kayser hat folgendes geschrieben :

Auch eine einfache Hochverfügsbarkeitslösung ist nicht zum Nulltarif zu haben [...]

Ja schon klar. Ich möchte aber Aufwand und Kosten möglichst gering halten.

jaenicke - Mi 22.12.10 14:36

Peter2002 hat folgendes geschrieben :

Wie meinst du das mit dem elektronischen Schalter? Dem Ding einfach den Strom klauen?

Ja. Dem Switch, nicht dem Rechner wohlgemerkt (abstürzen muss man den Rechner ja nicht). Damit kannst du von außen die Verbindung zum Netzwerk unterbrechen um selbst die IP zur Verfügung zu stellen, ohne dass es Konflikte gibt.

Zudem sind solche Schalter relativ günstig zu haben, so dass es auch nicht viel kostet.

Narses - Mi 22.12.10 14:39

Moin!

Peter2002 hat folgendes geschrieben :

Wie meinst du das mit dem elektronischen Schalter? Dem Ding einfach den Strom klauen?

Jup, genau so macht man das hardwarebasiert bei einem Cluster-System, mit z.B. sowas hier Suche bei Google

LEUNIG EPOWERSWITCH :lupe: :idea:

Peter2002 hat folgendes geschrieben :

Gerd Kayser hat folgendes geschrieben :

[...]weckt immer Begehrlichkeiten. Wenn kurzfristig für einen neuen Mitarbeiter ein PC benötigt wird, ist der Backup-Rechner meist im Gespräch, weil der andere PC ja bislang fehlerfrei lief. [...]

Sowas darfs aber nicht geben. Wenn gnadenlos Backup-Systeme abeschaltet werden, ist jede Diskusion bezüglich Hochverfügbarkeit hinfällig.

Tja, wenn der Chef ausreichend viel Chef und zuwenig Techniker ist, dann gibt´s das leider ganz schön viel zu oft... :roll:

Peter2002 hat folgendes geschrieben :

Ja schon klar. Ich möchte aber Aufwand und Kosten möglichst gering halten.

Die Kunst ist doch eigentlich nur, den SPoF zu vermeiden, egal wie. Das geht am besten (und billigsten) durch (ggfs. massive) Redundanz. Also die Diensteanbieter in einem Pool verfügbar halten und den Clients die Liste der Server im Pool zugänglich machen, ggfs. kann man da auf Konzepte von P2P-Netzen zurückgreifen, also andere Clients fragen, mit wem sie denn grade reden. Wenn ein Client keinen Server mehr findet, tut´s ein simpler UDP-Broadcast nach einem laufenden Server aber zur Not auch... :nixweiss:

cu
Narses

delphi10 - Do 23.12.10 05:18

Also als erstes sollte man mal definieren, was unter Hochverfügbarkeit verstanden wird.
99,9% Rechner in A-Kraft-Zentralen, meist dreifach plus Serverkoordinator(Server)
99-95% Hoher personeller Aufwand, Rufbereitschaft aus dem Werk, Zwei Rechner.Bei beiden HotStandBy-Maschinen und
95-90% Zwei Rechner, Rufbereitschaft von zu Haus
ab 89% einschalten und hoffen das es längerfristig geht.
Das Wichtigste: USV mit Standzeit min. vereinbarte Anrückzeit der Rufbereitschaft UND bis Vollbackup gelaufen ist, das wiederum hochverfügbar sein muß. Besonders abgesicherte Kabelverlegung.
Das ist wirklich nur ein winziger Bruchteil eines Lastenheftes zu Thema. Alles darunter ist Kindergeburtstag. Und
glaubt mit, es fallen Teile aus, an denen ihr nienimmernich gedacht hättet. Das Bedeutet, alle beteiligten Rechner alls Ersatzteile im Keller.
Eine gute Verfügbarkeit hat nichts mit Hochverfügbarkeit zu tun.EIn Hochverfügbarkeits Lastenheft kann schon mal einige 10 DINA4-Blätter enthalten.
Wenn ihr meint, das ist alles Blödsinn, dann redent nicht mehr von Hochverfügbarkeit

Peter2002 - Fr 24.12.10 12:33

delphi10 hat folgendes geschrieben :

Also als erstes sollte man mal definieren, was unter Hochverfügbarkeit verstanden wird.
99,9% Rechner in A-Kraft[...]

Wenn ich mir die Definitionen des BSI ansehe, stimmen deine Zahlen glaub nicht so ganz.
Ein Ausfall von 44 Min. im Monat dürftte hier wohl kaum akzeptabel sein. BSI Hochverfügbarkeitskompendium [https://www.bsi.bund.de/DE/Themen/weitereThemen/Hochverfuegbarkeit/HVKompendium/hvkompendium_node.html]

delphi10 hat folgendes geschrieben :

[...]Wenn ihr meint, das ist alles Blödsinn[...]

Hat das irgendwer behauptet?

platzwart - Fr 24.12.10 12:43

Mich würde auch mal interessieren, was genau du unter "Hochverfügbarkeit" verstehst. Geht es wirklich darum, dass dort eine riesige Produktionslinie von diesem einen Rechner abhängig ist oder droht nicht der finanzielle Ruin, wenn der Rechner mal 1 Minute nicht läuft?

platzwart - Fr 24.12.10 13:32

Dann mal eine ganz verrückte Idee: Du stellst ganz einfach zwei Rechner nebeneinander. Die kritischen Daten werden auf beiden Rechnern synchronisiert. Sobald ein Fehler auftritt, wird der Produktivrechner abgeklemmt und der Backuprechner bekommt dessen IP und wird angeklemmt. So sollte doch ein absolut minimaler Aufwand gegeben sein, und innerhalb von 5 Minuten hat man das auch umgestellt. Bei allem anderen wird der Aufwand so extrem hoch und es kommen so viele Fehlermöglichkeiten hinzu, dass es sich kaum lohnt?

Peter2002 - Fr 24.12.10 13:40

Genau so in etwa stell ich mir das vor.
Nur halt eben irgendwie automatisiert. Der Backuprechner muss selbständig übernehmen können.
Wenn der Primärrechner ausfällt und nicht sofort jemand greifbar ist, der "umklemmen" kann, wirds fast unmöglich die 5 Min. einzuhalten.

delphi10 - Fr 24.12.10 14:43

Peter2002 hat folgendes geschrieben :

delphi10 hat folgendes geschrieben :

Also als erstes sollte man mal definieren, was unter Hochverfügbarkeit verstanden wird.
99,9% Rechner in A-Kraft[...]

delphi10 hat folgendes geschrieben :

[...]Wenn ihr meint, das ist alles Blödsinn[...]

Hat das irgendwer behauptet?

Nö, aber meist werden die Zahlen ja angezweifelt außerhalb der betroffen Szene.
Und ja, Pro TAG 0,1% pro Tag 1,44min - noch schärfer kann es gehen bei Produktionsschicht, d.h. pro 6-8h. Das musste erstmal toppen, da dauert das Raussuchen des Handbuches schon länger.
Jeder manuelle Eingriff zu Störungsbeseitigung ist kontraproduktiv und sollte unbedingt auf maschineller Ebene automatisch gehandelt werden. Anders sind die geforderten Zeiten nicht zu schaffen. Denn sonst stehste da als externer Betreiber und überlegst, woher du die Pönnale kriegen sollst..

Narses - Fr 24.12.10 15:35

Moin!

Peter2002 hat folgendes geschrieben :

Nur halt eben irgendwie automatisiert. Der Backuprechner muss selbständig übernehmen können.

Ich stelle mir schon die ganze Zeit die Frage, ob du einen Hardware- oder einen Software-Ausfall absichern willst - oder beides? :gruebel:

Für einen Hardware-Ausfall würde ich heutzutage auf einen VM-Cluster aufsetzen, was anderes lohnt doch kaum. Vor allem musst du ja genau genommen noch ein Proof-of-Concept vorlegen, um im Falle eines Ausfalles nicht mit runtergelassener Hose darzustehen. Bei sowas würde ich lieber auf eine fertige und deshalb getestete Lösung aufsetzen. Wir betreiben einen VMware vCenter-Server mit zwei VMware-ESX-Hosts, die per Heartbeat synchron sind. Fällt eine Maschine aus, übernimmt die andere nahtlos in ca. 260ms, merkt man kaum ein "Ruckeln", ziemlich gut. Zugegeben, kostet zwar auch "etwas" Geld, aber das ist letztlich nur ein Rechenexempel, was der Ausfall des Produktiv-Systems kosten würde... ;)

Für die Absicherung eines Softwareausfalls ist das natürlich nix, hier hilft wirklich nur (möglichst massive) Redundanz. :idea:

Für eine saubere Absicherung brauchst du, ganz genau genommen, beides. :nixweiss:

cu
Narses

Peter2002 - Sa 25.12.10 15:25

Nun ja, absichern muss ich letztlich alles.
Momentan geht es mir aber ehere um die Software. Sprich wenn Dienst abstürzt, Deadlock, Endloschleife usw.
Jetzt muss ich ja irgendwie dafür sorgen können, dass es weitergeht. Den Fehler automatisch zu finden und zu behenben dürfte schwierig werden. Da ist es vermutlich einfacher ne Mail wegzuschicken und einen anderen übernehmen zu lassen.

Peter2002 - Di 15.02.11 16:27

Hallo,

Zur Realisierung der Hochverfügbarkeit habe ich eine neue Idee...
In wie weit müsste ich meine Dienste anpassen, damit diese in einem Windows 2008 R2 Failover-Cluster laufen.
Bzw. kann ich mit so einem Konstrukt überhaut einen Software-Ausfall abfangen?

Reinhard Kern - Di 15.02.11 17:17

bummi hat folgendes geschrieben :

Die Dienste könnten eine Statusliste mit Timestamp als Ringbuffer vorhalten, ein Watchdogdienst checkt regelmäßig den Ringbuffer.

Hallo,

und wer checkt den Watchdogdienst? Ich würde mir erst mal ein System aus 2 Diensten aufbauen und testen, die sich gegenseitig überwachen und restarten. Ist das nahezu unstörbar, kann man damit andere Dienste überwachen.

Ein wesentliches Problem ist auch, einen erkanntermassen nicht mehr funktionsfähigen Dienst völlig rückstandsfrei zu entfernen. Sonst hat es sich mit der Verfügbarkeit spätestens dann, wenn der verbleibende Müll alles andere zugeschüttet hat.

Gruss Reinhard

Entwickler-Ecke.de based on phpBB
Copyright 2002 - 2011 by Tino Teuber, Copyright 2011 - 2026 by Christian Stelzmann Alle Rechte vorbehalten.
Alle Beiträge stammen von dritten Personen und dürfen geltendes Recht nicht verletzen.
Entwickler-Ecke und die zugehörigen Webseiten distanzieren sich ausdrücklich von Fremdinhalten jeglicher Art!