Hi! Ein Windows-Programm soll hochverfügbar auf einem lokalen PC-System laufen und dabei auf einen Server im Internet zugreifen. Damit meine ich, dass das Programm auch bei einem Ausfall einer Hardwarekomponente, eines Internetzugangs oder der Stromversorgung fehlerfrei weiterlaufen soll. Kennt sich jemand mit so etwas aus? Ich habe etwas gegoogelt und den Begriff "Failover Cluster für Windows Server" gefunden, bin aber nicht sicher, ob es das Gewünschte ist. Ich stelle mir das so vor: 2 PCs, die über LAN verbunden sind, mit spezieller Virtualisierungs-Software (Hyper-V ?) auf der dann das Windows-Programm läuft. Einer mit Internetverbindung über den DSL-Router, der andere über UMTS. Einer mit unterbrechungsfreier Stromverorgung, der andere direkt am Stromnetz. Wenn jetzt an einem Gerät etwas ausfällt, übernimmt der andere PC... Sorry, falls das Blödsinn ist. Gibt es eigentlich Einsteiger-Literatur zu diesem Thema?
https://www.windowspro.de/marcel-kueppers/failover-cluster-einrichten-windows-server-2012-r2 Erforderliche Skills sind Windows Server, Powershell, Active Directory und Hyper-V. Hast DU diese Skills nicht, musst Du die eben auf dem Arbeitsmarkt einkaufen. Das ganze Zeug ist ausdrücklich NICHT anfängergeeignet. Und ja, die Server-Lizenzen und die zertifizierte Hardware ist erforderlich, und zwar in zweifacher, identischer Ausführung. Das ist die Basis. Dann muss Deine Anwendung natürlich clusterfähig sein, d.h. die entsprechenden Server-APIs nutzen, damit das Failover auch auf Applikationsebene funktioniert. Ohne das macht der ganze Aufwand keinen Sinn. Auch dieses Know-How wirst Du extern einkaufen müssen, wenn Du es nicht selber hast. Das ist jetzt vielleicht nicht die Antwort, die Du hören wolltest. fchk
:
Bearbeitet durch User
Kai Weller schrieb: > und dabei auf einen Server im Internet zugreifen Das kann schon der 2.Fehler sein, wenn dieser nicht ausreichend zuverlässig erreichbar ist. 3. Neben Cluster sollte auch Stromversorgung und Netzwerk genauer betrachtet werden (2 Wege).
Was ist bei Überschwemmung/Überspannung/Feuer? Für höchstverfügbar mindestens zwei Standorte.
Echte ausfallsicherheit setzt mindestens drei komplett Systeme vorraus, schliesslich könnte ja während der geplanten Wartung oder notwendiger Reparatur das 2te System ausfallen.
Kai Weller schrieb: > Ein Windows-Programm Welches? Gibt es das schon, oder wird es erst entwickelt? Was tut es? Nur lesen ist easy, aber wenn immer nur ein Client aktiv sein darf und einen immer völlig aktuellen Datenstand haben muss, dann wird es komplexer. Das Szenario von Frank K. ist in manchen Fällen das Richtige. Je nach Anforderung gibt es aber auch ganz andere, auch einfachere und für mache Zwecke bessere Möglichkeiten. Oder auch Komplexere, wenn nötig. Kann auch sein, dass du drei Systeme brauchst ("Split Brain" etc.), aber ohne deine Anforderung zu beschreiben werden 90% der Tipps hier nicht auf dein Problem passen.
Man kann das auf althergebrachte Weise mit Window Clustern machen. 2x Server in Blech plus separatem gemeinsamem Plattenspeicher via iSCSI/FC (diesen auch hochverfügbar zu machen ist wieder ein eigenes Kapitel). Ist nicht einmal so arg kompliziert, wenn man die Grundlagen verstanden hat. Kontinuierlicher Betrieb trotz Ausfall ist damit aber nicht möglich. Es führt nur dazu, dass der Dienst auf der anderen Maschine ggf. nachgestartet wird. Ein modernerer Weg führt über Virtualisierung. Beispiel VMware: Man kann ähnlich wie oben einen HA-Cluster aus >=2 ESXi Hosts bauen. Im einfachsten Fall werden VMs des ausgefallenen Hosts auf anderen Hosts des Clusters nachgestartet, mit entsprechender Unterbrechung im Minutenbereich. Für fast kontinuierlichen Betrieb kann man alternativ auf einem zweiten Host ein Spiegelsystem laufen lassen, dass alle Zustandsänderungen des Originalsystems innert Sekunden nachzieht. Vollständig kontinuierlich mitsamt allen Änderungen an jedweden Daten wäre dann die nächste Stufe. Aber die zu erklimmen ward mit bisher erspart. Direkt billig ist das nicht. Mit Linux kommt man günstiger weg, um den Preis innigerer Knowhow-Entwicklung.
Internet-Redundanz ist ein davon unabhängiges Thema. Hier noch relativ einfach, weil wie geschildert nur ausgehend aufgebaute Verbindungen redundant sein müssen. Dafür gibts ein paar Verfahren, die entsprechende Router voraussetzen. Redundanz bei eingehenden Verbindungen ist "etwas" komplizierter.
Heinz V. schrieb: > Echte ausfallsicherheit setzt mindestens drei komplett Systeme vorraus, > schliesslich könnte ja während der geplanten Wartung oder notwendiger > Reparatur das 2te System ausfallen. ... und während der Reparatur der ersten beiden das Dritte. Nope, so wird kein Schuh draus. Perfektion setzt unendlich viele Systeme voraus, weshalb man üblicherweise unabhängige Doppelfehler ausschliesst und bei 2 Systemen bleibt. Nützlich sind daher leidlich zuverlässige Systeme und entsprechende Wartungsverträge, also keine Home-PCs vom Kistenschieber.
Kai Weller schrieb: > Gibt es eigentlich Einsteiger-Literatur zu diesem Thema? Als Einsteiger in Systemtechnik generell? Dieses Thema setzt einige Grundkenntnis in Systemtechnik voraus, auch Netzwerk-Routing/Redundanz und Anbindung von Speichersystemen. Wenn das nicht solide da ist, dann wär erst einmal das zu erarbeiten. Oder man kauft das Knowhow ein. Wird möglicherweise einfacher und günstiger, wenn man diese Aufgabe nicht selbst hostet.
Danke erstmal. Das Windows-Programm ist zugekauft, nicht anpassbar und nicht clusterfähig. Wenn ich Frank richtig verstanden habe, fällt daher das Konzept mit dem Failover-Cluster weg. Ein Ausfall für 1min wäre tolerabel. Zudem kann das System über das Wochenende gewartet werden. A.K.s Lösung mit Vmware hört sich gut an. Werde mich dazu mal einlesen.
Kai Weller schrieb: > Einer mit Internetverbindung über den > DSL-Router, der andere über UMTS. Yep. Aber diese Router müssen entsprechende Techniken zur Übernahme einer gemeinsamen Routing-Adresse enthalten, oder man muss im Netz dynamisches Routing einrichten. Bei Fritzboxen dürfte es da mau aussehen.
Jan H. schrieb: > auch sein, dass du drei Systeme brauchst ("Split Brain" etc.), Split Brain lässt sich ggf. mit 2 Systemen verhindern, indem der übenehmende Host den anderen brachial abschiesst (STONITH = Shoot The Other Node In The Head). Rudimentäre Restkommunikation ist allerdings Grundvoraussetzung, denn zumindest diese Fähigkeit muss gewährleistet sein.
Kai Weller schrieb: > Ein Windows-Programm soll hochverfügbar auf einem lokalen PC-System > laufen und dabei auf einen Server im Internet zugreifen. Damit meine > ich, dass das Programm auch bei einem Ausfall einer Hardwarekomponente, > eines Internetzugangs oder der Stromversorgung fehlerfrei weiterlaufen > soll. Kennt sich jemand mit so etwas aus? Hochverfügbar und Windows schließt sich gegenseitig aus. Nicht weil Windows so schlecht sondern schlicht nicht dafür geeignet ist. Das ganze zu virtualisieren und parallelisieren macht die Sache nicht besser. Dann hast du noch mehr fehleranfällige Layer im System die zudem auch noch identisch sind. D.h. das Sie alle dann im Zweifel den gleichen Fehler haben und alle an der gleichen Stelle ausfallen. Wenn du die System wg. Hardwareausfällen redundant halten möchtest bis du mit einem NAS Cluster der untereinander repliziert evtl besser aufgestellt.
X4U schrieb: > Hochverfügbar und Windows schließt sich gegenseitig aus. Nicht weil > Windows so schlecht sondern schlicht nicht dafür geeignet ist. Die Zeiten von Windows 98 sind vorbei. Bitte auch beachten, dass "hochverfügbar" kein absoluter Begriff ist, sondern "höher verfügbar" meint. Es gibt nicht ein hochverfügbar, sondern unterschiedliche Wahrscheinlichkeiten für Ausfallszenarien, und den Versuch, sie auf verschiedene Weisen zu verbessern. > Das ganze zu virtualisieren und parallelisieren macht die Sache nicht > besser. Es macht sie einerseits einfacher. Es gibt keine Kopplung zwischen dem verfügbarer zu machenden Service und der Methode, dies durchzuführen. Die Methode funktioniert völlig unabhängig davon, welches Betriebssystem und welche Anwendung auf den VMs läuft. Es kann sie andererseits überhaupt erst möglich machen, wenn die eingesetzten Anwendungen nicht schon selbst entsprechende Verfahren vorsehen. Dass man bei einer konkreten Anwendung darauf achten muss, was in welchem Ausfall- und Übernahmeszenario geschehen wird, beispielsweise was Datenintegrität und ggf. Transaktionen angeht, ist klar. Aber dazu ist hier nicht genug bekannt. Übrigens: VMware HA-Cluster funktionieren. Man kann dadurch nicht alles abdecken, aber als einfache Methode, den IT-Zoo höher verfügbar zu machen, ist das sehr hilfreich und aufgrund des generischen Ansatzes recht universell - und ist insbesondere bei grösserer Anwendungsvielfalt wesentlich einfacher als jeweils spezialisierte Ansätze. > Wenn du die System wg. Hardwareausfällen redundant halten möchtest bis > du mit einem NAS Cluster der untereinander repliziert evtl besser > aufgestellt. Application HA und Storage HA sind zwei paar Stiefel. Im Anfangsartikel geht es erklärtermassen um eine Anwendung. HA Methoden können aber auch hochverfügbaren Storage benötigen, je nachdem wie das implementiert wird. Die erwähnten Methoden sind nicht unbedingt die einzig möglichen. Das sind typische Methoden für HA-Cluster, die im Einzelfall auch übertrieben sein können. Besonders bei Betrachtung der konkreten Anwendung sind möglicherweise auch andere Methoden denkbar, allerdings wird das durch eine fertig eingekaufte Anwendung nicht leichter. Und man muss dann mehr ins Detail. Wenn die Frage ist, eine bestimmte vorhandene Anwendung höher verfügbar zu machen, dann hilft eine Antwort nicht weiter, die darauf hinausläuft, diese Anwendung wegzuwerfen und es ganz anders zu machen. Es sei denn es wäre klar, dass es anders nicht geht.
:
Bearbeitet durch User
X4U schrieb: > D.h. das Sie alle dann im Zweifel den gleichen > Fehler haben und alle an der gleichen Stelle ausfallen. Yep. So wird beispielsweise ein defektes Filesystem durch die gezeigten Szenarien nicht repariert. Sowas ist glücklicherweise selten geworden. Nur muss man darauf erst einmal eine Antwort finden, die nicht auf "lass es, geht so nicht" rausläuft. Also: Gegen was will man sich absichern? Gegen alle denkbaren Eventualitäten? Das wäre klar die "lass es" Variante. Oder beispielsweise gezielt gegen Hardware- und Netzwerk-Ausfälle?
> > Also: Gegen was will man sich absichern? Gegen alle denkbaren > Eventualitäten? Das wäre klar die "lass es" Variante. Oder > beispielsweise gezielt gegen Hardware- und Netzwerk-Ausfälle? JA, erst einmal die Anforderungen an das System vollständig beschreiben! Dann vielleicht mal nachfragen wie die großen Wirtschaftskonzerne diese Problematik lösen... Ein Weltkonzern wie VW, Siemens, etc... müssten doch was in petto haben. ...
Kai Weller schrieb: > Einer mit Internetverbindung über den > DSL-Router, der andere über UMTS. Einer mit unterbrechungsfreier > Stromverorgung, der andere direkt am Stromnetz. Klingt jetzt nicht so nach dem Super HA-Setup. Vielleicht lohnt es sich für dich in die Cloud zu gehen. Es gibt Cloud-hoster welche Windows im Programm haben und bestrebt sind 24/7 zu ermöglichen. Deren Blech hat üblicherweise 2 unabhängige Stromkreise und sollte auch dicker, redundant am Internet hängen. Vielleicht lohnt es sich für dich Dort dein Service zu betreiben.
Eieiei schrieb: > Dann vielleicht mal nachfragen wie die großen Wirtschaftskonzerne diese > Problematik lösen... Die sind hier eigentlich die falsche Adresse. Wenn es um ein einzelnes System geht, bisher in Blech realisiert, betrachtet man solche Fragen stärker auf dieses spezielle System ausgerichtet, als wenn man sowieso schon einen Zoo von aberhunderten unterschiedlichster VMs in einer insgesamt bereits redundanten Umgebung hat. So haben grosse Umgebungen sowieso schon hochverfügbaren Storage, Virtualisierung und Redundanz in Netzwerk und Internet-Anbindung. HA über Virtualisierung ist da quasi ein Nebenprodukt und allenfalls eine Frage der richtigen VMware-Lizenz. Hier wäre eine speziell angepasste Lösung möglicherweise deutlich billiger, lässt sich aber ohne Blick auf die Details schlecht diskutieren. Imonbln schrieb: > Vielleicht lohnt es sich für dich in die Cloud zu gehen. Altmodisch ausgedrückt: externes Hosting. Würde ich hier auch mit in die Überlegungen einbeziehen. Dort sind die Redundanzen schon vorhanden, die man hier erst aufbauen müsste.
:
Bearbeitet durch User
Beitrag #4979463 wurde von einem Moderator gelöscht.
Beitrag #4979475 wurde von einem Moderator gelöscht.
Beitrag #4979479 wurde von einem Moderator gelöscht.
Beitrag #4979482 wurde von einem Moderator gelöscht.
Beitrag #4979508 wurde von einem Moderator gelöscht.
> Das Windows-Programm ist zugekauft, nicht anpassbar und nicht clusterfähig.
Und jetzt nimmt man einmal an, auf der richtigen Hardware, und dem
richtigen Setup sei es hochverfuegbar ... schoen. Ich wuerd's mal so
laufenlassen und annehmen, die jetzige Hardware sei auch schon
hochverfuegbar und mal die Fehlerfaelle aufzeichnen.
Ohne Mithilfe des Entwicklers ist nichts einfach hochverfuegbar.
Sapperlot W. schrieb: > Ohne Mithilfe des Entwicklers ist nichts einfach hochverfuegbar. Ist mir zu pauschal. Eine Kernfrage: Ist die Anwendung in der Lage, einen spontanen Reset (oder Abschaltung) der Serverhardware zu verdauen, ohne anschliessend eine manuelle Reparatur von Inhalten zu erzwingen? Ungefähr das ist es nämlich, was bei einem Restart einer VM oder eines Service aufgrund des Ausfalls eines Hosts passiert. Zwar weiss ein Entwickler das wohl besser, aber völlig aufgeschmissen ist man auf der Kundenseite nicht unbedingt. Vielleicht hat man eine Vorstellung vom Aufbau der Anwendung. Vielleicht hat man das auch schon ausprobiert. Bei negativem Ergebnis, also notwendiger anschliessender und manueller Datenreparatur, kann man sich diese Form der HA ohne Mitwirkung des Herstellers sparen. Und zur Arbeitsweise eines Spiegelservers in vSphere Fault Tolerance: http://nil.csail.mit.edu/6.824/2016/papers/vm-ft.pdf http://www.vmware.com/files/pdf/techpaper/VMware-vSphere6-FT-arch-perf.pdf Dieses Prinzip ist grundsätzlich anwendungsneutral, da der komplette Zustand des Primärservers mitgezogen wird und folglich nichts runterbricht und neu gestartet werden muss.
:
Bearbeitet durch User
>> Sapperlot W. schrieb: >> Ohne Mithilfe des Entwicklers ist nichts einfach hochverfuegbar. >Ist mir zu pauschal. Ok. Etwas detailierter. - Sind die verwendeten Kommunikations Protokolle zustandsbehaftet oder zustandslos. - Welche Kommunikationsredundanz ist vorhanden. - Welche Kommunikationssicherheit ist vorhanden. - wie schaut's mit dynamischem Speicher aus. Wenn man sich nicht Muehe gibt nimmt sich ein Programm immer mehr an Speicher. Bis es irgendwann instabil wird, oder blockiert. - Wartungsumgebung ? Wie schaut's mit einem Backup der Daten aus, und ja, bei laufenden Prozessen. - Wie setzt das Programm bei einem Restart wieder auf.
:
Bearbeitet durch User
A. K. schrieb: > Altmodisch ausgedrückt: externes Hosting. Würde ich hier auch mit in die > Überlegungen einbeziehen. Dort sind die Redundanzen schon vorhanden, die > man hier erst aufbauen müsste. Das Problem ist, dass er dann immerhin noch einen redundanten Client braucht
Sapperlot W. schrieb: > - Sind die verwendeten Kommunikations Protokolle > zustandsbehaftet oder zustandslos. > - Welche Kommunikationsredundanz ist vorhanden. > - Welche Kommunikationssicherheit ist vorhanden. Netzwerkredundanz lässt sich völlig unabhängig von Hochverfügbarkeit eines Servers lösen. Je nach HA-Verfahren tritt auch kein Ausfall von Paketen auf, weil ein entsprechend arbeitender Hypervisor damit sowohl das Primär- also auch das Spiegelsystem gleichermassen versorgen kann. Der Begriff "Hochverfügbarkeit" wird meist auf Absicherung gegen Ausfälle von Komponenten bezogen, nicht so sehr auf fehlerfreies Arbeiten der Anwendung. > - wie schaut's mit dynamischem Speicher aus. Wenn > man sich nicht Muehe gibt nimmt sich ein Programm > immer mehr an Speicher. Bis es irgendwann instabil > wird, oder blockiert. Kein halbwegs bei Verstand befindlicher Entwickler dieser Welt wird dir fehlerfreie Funktion garantieren. Natürlich kann man für entsprechende Anwendungen parallele Systeme aufbauen, um jene Fehler anzugehen, die durch Programmfehler in Anwendung oder Betriebssystem entstehen. Nur meisten beschränkt sich diese Redundanz dann auf die Middleware, nicht auf das Backend. Ob es sich hier um solche Middleware handelt ist unklar. > - Wartungsumgebung ? Wie schaut's mit einem Backup > der Daten aus, und ja, bei laufenden Prozessen. Auch das geht eher in Richtung zuverlässige Systeme, betrifft nicht so sehr die obige Interpretation von Hochverfügbarkeit. Hochverfügbarkeit ist ein Ansatz, für übliche Szenarien kein Backup/Restore zu benötigen. Wenn man sich durch inhaltliche Fehler, Programm oder Anwender, das System zerlegt, dann hilft keine Hochverfügbarkeit. > - Wie setzt das Programm bei einem Restart wieder auf. Yep, das hatte ich bereits erwähnt. Ist allerdings für vSphere FT nicht erforderlich, da kein Restart erfolgt. Allgemein: (1) Es kommt nicht selten vor, dass der Entwickler weniger Ahnung von komplexen Umgebungen hat, als ein Systemtechniker in einer bereits solche Methoden einsetzenden IT. Der Entwickler/Anbieter hat nämlich eine solche Umgebung nicht notwendigerweise selbst zur Verfügung. Hatte ich schon mehrfach, vom Entwicklungsbüro bis zum Grosskonzern als Lieferant. (2) Wie schon oben erwähnt: Vorweg steht immer die Frage, gegen was man sich absichern will. Absolute Antworten gibts in der Religion, absolute Sicherheit in der IT gibt es nirgends. Es gibt immer Szenarien, die zum Ausfall jenseits der Toleranzgrenze führen können. Man wird daher die Wahrscheinlichkeit eines Ausfalls reduzieren wollen, nicht aber eliminieren können.
Hans schrieb: > Das Problem ist, dass er dann immerhin noch einen redundanten Client > braucht Das ist im Vergleich mit allem, was hier bisher betrachtet wurde, die einfachste und billigste Frage. Wenn man mal voraussetzt, dass alle relevanten Daten auf dem Server liegen, und liegen bleiben, nicht nur auf einem Client. Redundante Internet-Anbindung gibts auch in allen Stufen. Im einfachsten Fall hast du einen PC und einen Laptop. Den Laptop auch mit Mobilfunk drin, mit anderem Provider als bei der Internet-Leitung. Hier freilich scheint eine Internet-Anbindung bereits erforderlich zu sein. Den Appserver auch ins Internet zu legen würde die Situation gegenüber einem lokalen Server also nicht wesentlich verschlechtern.
:
Bearbeitet durch User
> Kein halbwegs bei Verstand befindlicher Entwickler dieser Welt wird dir
fehlerfreie Funktion garantieren.
Naja .. garantieren. Trotzdem gibt es Software, die nie fuer Stabilitaet
entwickelt wurden, und ganz sicher ! abschmieren. Einfach den Prozess
restoren bringt da nichts.
ZB Firefox. Wenn der um die 2GB RAM und 2GB virtuell gezogen hat wird er
langsam und muss entweder manuell neu gestartet werden, oder er schmiert
ab. Ja, Firefox ist kein Serverprozess und er kostet auch nichts.
Wenn der Restartprozess dann nicht mehr geht, weil irgendwas falsch
laeuft hat man ein Problem. Daher ist Hochverfuegbarkeit nicht einfach
nur Hardware. Die Software muss dafuer ausgelegt worden sein, sonst ist
es Zufall.
Sapperlot W. schrieb: > Wenn der Restartprozess dann nicht mehr geht, weil irgendwas falsch > laeuft hat man ein Problem. Für Produktionsbetrieb vorgesehene Server-Software sollte i.d.R. dafür ausgelegt sein, mit einem Server automatisch starten zu können. Und zwar vorzugsweise auch dann, nachdem der mitten im Galopp hart einen Reset verpasst bekam - andernfalls taugt die Software oft auch nicht für non-HA Einsatz, weil der Experte dafür bestimmt grad Urlaub hat und der Kollege nicht weiss, welche Bits man umkippen muss. Wenn andererseits dieses Szenario sehr wahrscheinlich gewährleistet ist, dann ist ein HA-Szenario, das eine VM auf einem anderen Host nachstartet, durchaus bedenkenswert. Sapperlot W. schrieb: > Trotzdem gibt es Software, die nie fuer Stabilitaet > entwickelt wurden, und ganz sicher ! abschmieren. Stimmt. Aber das ist ein ziemlich anderes Szenario als die Frage von Verfügbarkeit bei Komponentenausfall. Man sollte die Begriffe nicht überlasten. Auch ich kenne natürlich solche Server-Software. Darunter leider auch welche im Produktionsprozess. HA hilft dagegen nicht. Verprügeln derjenigen, die sie entwickelt oder ausgesucht haben, leider auch nicht. Aber ich hoffe, das dies mit der Frage des Threads nicht gemeint ist. Andernfalls: Tonne auf, Software rein, Tonne zu.
:
Bearbeitet durch User
A. K. schrieb: > Sapperlot W. schrieb: >> Ohne Mithilfe des Entwicklers ist nichts einfach hochverfuegbar. > > Ist mir zu pauschal. Mir nicht, denn Sapperlot hat leider nicht ganz Unrecht. > Eine Kernfrage: Ist die Anwendung in der Lage, einen spontanen Reset > (oder Abschaltung) der Serverhardware zu verdauen, ohne anschliessend > eine manuelle Reparatur von Inhalten zu erzwingen? Die wichtigste, und damit die allererste Kernfrage ist: wie kannst Du einen Ausfall der Software erkennen? Da könnte man natürlich die Prozeßliste des Systems anschauen, aber das ist keine zuverlässige Lösung: Applikationen können einfach hängen bleiben, klassische Beispiele wären Deadlocks oder Situationen, die in Programmierlehrbüchern diplomatisch als "undefiniertes Verhalten" bezeichnet werden. Dann ist die Applikation zwar immer noch in unserer Prozeßliste vertreten, tut aber nichts mehr -- und das kommt bei eventbasierter Software wie klassischen GUI-Programmen leider öfter vor, als den Anwendern lieb ist. Oder gibt es hier jemanden, der es noch nie erlebt hat, daß ein Programm "hängt" und nicht mehr reagiert? ;-) In einer idealen Welt muß die Applikation daher ihren Gesundheitszustand überprüfen können und es ermöglichen, das Ergebnis dieser Prüfung extern abzufragen. Idealerweise werden Netzwerkverbindungen, Schreibzugriffe auf Festplatten etc. mit Timeouts versehen, und so weiter. Das ist ein recht hoher Aufwand für den Applikationsentwickler, der sich das meist erspart, sofern ein Clusterbetrieb nicht explizit vorgesehen ist.
A. K. schrieb: > Wenn andererseits dieses Szenario sehr wahrscheinlich gewährleistet ist, > dann ist ein HA-Szenario, das eine VM auf einem anderen Host > nachstartet, durchaus bedenkenswert. Was hast Du denn bloß immer mit Deinen VMs? ;-) Das ist doch nur wieder ein weiterer Komplexitätslayer, obwohl HA ohnehin schon komplex genug ist. Diese zusätzliche Komplexität kann zwar vielleicht die Manageability erhöhen, was sich in größeren Umgebungen auszahlen kann. Sie erhöht aber gleichzeitig die Fehleranfälligkeit und vermindert so wiederum die Robustheit und Resilienz des Gesamtsystems. Anders gesagt: wenn Du eine Applikation auf dem nackten Blech laufen läßt, dann können die Applikation selbst, das Betriebssystem, oder die Hardware ausfallen. Wenn Du eine Applikation in einer VM betreibst, dann können die Applikation selbst, das Gast-Betriebssystem, der Virtualisierungshypervisor, das Host-Betriebssystem, oder die Hardware ausfallen. Durch die Virtualisierung haben wir jetzt also noch mehr Komponenten, die ausfallen können -- von der zusätzlichen Ressourcenbelastung einmal ganz abgesehen. Insofern stellt sich die Frage, wo der Gewinn darin liegt, die Veranstaltung zu virtualisieren -- und ob dieser Gewinn die zusätzlichen Ausfallrisiken aufwiegen kann.
Sheeva P. schrieb: > Durch die Virtualisierung haben wir jetzt also noch mehr Komponenten, > die ausfallen können Wenn man diese Logik konsequent fortführt, gelangt man dann nicht zum Ergebnis, dass jede HA-Umgebung aufgrund der höheren Komplexität weniger verfügbar ist als ein einzelner Server? ;-)
:
Bearbeitet durch User
Sheeva P. schrieb: > Was hast Du denn bloß immer mit Deinen VMs? ;-) Ist halt meine Welt ;-). Ach ja: Und es ist auch mein Ansatz. Sonst kam eigentlich keiner, oder? Der klassische Cluster ist dran gescheitert, dass die Software zwingend mitspielen muss. Immer her mit den anderen Vorschlägen, jeder lebt etwas in seiner Welt. Meine kann etwas einseitig sein. Alternativ könnte der TE auch etwas deutlicher werden. Dass es vielleicht auch einfacher geht hatte ich bereits geschrieben. Aber da kam auch nichts.
:
Bearbeitet durch User
A. K. schrieb: > Der klassische Cluster ist dran gescheitert, dass die Software zwingend > mitspielen muss. A)Klassische Cluster haben auch schon oft genug gehangen oder alle ein krankes Update bekommen. Außerdem ist Cluster ein recht allgemeiner Begriff worüber andere Leute schon ganze Doktorarbeiten geschrieben haben. B)Bei VM sollte die SW auch die gesunden, AKTUELLEN Daten haben wenn man den Ersatz startet um gleich weiterzuarbeiten. Dabei ist auch wieder die Frage, ob sie noch gesund ist oder z.B. den gleichen SW-Fehler hat wie die kranke VM weswegen die Ersatz-VM überhaupt gestartet wurde. Dann hilft nur ein altes Backup.
oszi40 schrieb: > oder z.B. den gleichen SW-Fehler hat wie > die kranke VM weswegen die Ersatz-VM überhaupt gestartet wurde. Zum drölfzigsten Mal: Bei den von mir betrachteten HA-Modellen geht es um Hardware-Ausfälle, nicht um Software-Defekte. > Dann hilft nur ein altes Backup. In einer Minute? Eben deshalb harre ich gespannt einer Lösung, die mit einer nicht cluster-enabled Software deren Software-Probleme löst. Und beschränke mich selbst daher auf Hardware. In einer Minute kriegst du zwar einen Snapshot restored, aber eben mit dessen Stand der Daten. Geht, wenn die Software ein reiner Durchlauferhitzer ist, also keinen eigenen Datenbestand pflegt. Das würde sowieso einiges ändern.
:
Bearbeitet durch User
A. K. schrieb: > Sheeva P. schrieb: >> Durch die Virtualisierung haben wir jetzt also noch mehr Komponenten, >> die ausfallen können > > Wenn man diese Logik konsequent fortführt, gelangt man dann nicht zum > Ergebnis, dass jede HA-Umgebung aufgrund der höheren Komplexität weniger > verfügbar ist als ein einzelner Server? ;-) Gegeben sei a als Ausfallwahrscheinlichkeit für einen Server, so beträgt die Wahrscheinlichkeit eines Ausfalls bei n Servern natürlich n * a. Die Wahrscheinlichkeit jedoch, daß zu einem bestimmten Zeitpunkt alle Server ausfallen, beträgt für einen einzelnen Server allerdings ebenso a, für n Server hingegen a / n. Das ist ja auch schon der ganze Trick bei der Hochverfügbarkeit: durch die Redundanz erhöht man zwar die Wahrscheinlichkeit einzelner Ausfälle, jedoch vermindert man gleichzeitig die Wahrscheinlichkeit, daß die Funktion des Systems nichtverfügbar wird. Ohne diese Nachteile wäre Hochverfügbarkeit immer eine tolle Sache, aber im Ergebnis ist klassische HA auf Betriebssystemebene den Aufwand häufig nicht wert. Nach meiner Erfahrung sind die Aufwände für Setup und den Betrieb von klassischen HA-Lösungen leider oft höher als die Verluste und Aufwände, die bei einem Ausfall durch die Nichtverfügbarkeit sowie die Wiederherstellung der Funktion erforderlich sind. Dann ist HA leider schlicht unökonomisch. Andererseits hängt die Ökonomie an dieser Stelle natürlich immer von der Systemfunktion ab: wenn bei uns ein Dutzend Betrugsexperten ein oder zwei Stunden lang nicht arbeiten und keine neuen Erkennungsregeln einstellen kann, dann ist das zwar nicht schön und auch ziemlich teuer. Dennoch ist der Schaden in solchen Fällen (meistens) nicht so groß, daß dadurch die Aufwände einer hochverfügbaren Lösung rechtfertigt würden. Ganz anders sieht die Sache allerdings aus, wenn durch den Ausfall tausende Sachbearbeiter nicht arbeiten können. Wenn Schäden ein erhebliches oder gar ein existenzbedrohliches Ausmaß erreichen können, ist HA nicht nur äußerst sinnvoll, sondern natürlich absolute Pflicht! ;-)
Ich empfehle dir hier Xen Remus + Pacemaker/Corosync. Wie gesagt kann dir mit einem Active/Passive Cluster niemand garantieren, dass die Gast-VM heil bleibt und in deinem vorgegebenen Zeitfenster neustartet. VMware bietet zwar auch Active/Active aber für den Preis der Software + Hardware (SAN ist Teuer) kann sich da locker jemand einarbeiten (Müsste man so oder so) oder von extern jemanden heranziehen. https://wiki.xenproject.org/wiki/Remus
A. K. schrieb: > Sheeva P. schrieb: >> Was hast Du denn bloß immer mit Deinen VMs? ;-) > > Ist halt meine Welt ;-). We are living in a yellow Filterblase, ... ;-) > Ach ja: Und es ist auch mein Ansatz. Sonst kam eigentlich keiner, oder? Hm, da haste natürlich Recht. > Der klassische Cluster ist dran gescheitert, dass die Software zwingend > mitspielen muss. Ok, das habe ich wohl nicht richtig herausgearbeitet, aber das muß sie bei Deiner VM-Lösung ganz genauso. Denn die erste Frage bleibt ja, wie gesagt, wie ich einen Ausfall, also die Nichtverfügbarkeit der Software überhaupt zuverlässig erkennen kann. Für dieses Problem hat die VM leider auch keine Lösung -- beziehungsweise: wir wissen es nicht, da der TO die Vorgabe des §3a BDSG penibel beachtet. ;-) > Immer her mit den anderen Vorschlägen, jeder lebt etwas > in seiner Welt. Meine kann etwas einseitig sein. > > Alternativ könnte der TE auch etwas deutlicher werden. Dass es > vielleicht auch einfacher geht hatte ich bereits geschrieben. Aber da > kam auch nichts. Kein Thema, wir leben alle in unseren Welten. Daß der TO so undeutlich ist und bei seiner zweiten Wortmeldung erkennen läßt, daß er nicht einmal die ersten Ausführungen zum Thema verstanden hat (denn ein Failover-Cluster ist ja genau das, was er sucht), das hält mich dann auch davon ab, irgendwelche Vorschläge zu unterbreiten. Was soll ich bei dieser Informationslage auch schreiben? Eine Einführung in System- und Clustertheorie, und danach noch eine Liste von allen möglichen Lösungen für alle möglichen Szenarien? Ja, nee, is klaar.
A. K. schrieb: > Zum drölfzigsten Mal: Bei den von mir betrachteten HA-Modellen geht es > um Hardware-Ausfälle, nicht um Software-Defekte. Es ist ja die Kunst die Gesamtheit zu sehen. Da muß frühzeitig erkannt werden wooo es hängt und dann die Ersatzlösung so laufen, damit möglichst kein User von der Störung betroffen ist. Deshalb nützt es wenig, wenn ich NUR die HW automatisch umschalte und z.B. die laufenden Messdaten dabei teilweise in der DB VERLOREN gehen. Man wird wohl doch etwas mehr Geld und ein paar Profis mit ausreichender Erfahrung brauchen. .... wenn es wirtschaftlich sinnvoll ist (für Tetris lohnt es sich nicht). :-)
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.