Ausfallsicheres System für Windows-Anwendung

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

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.

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.

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.

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?

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.

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

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

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.

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

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? ;-)

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.

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.

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.