marathon-laufen

> Office-Software ist wohl eher nicht mit den erforderlichen
> Features ausgestattet.
>
> Du hast im Prinzip zwei Möglichkeiten: die “Aufgabe” ist
> ohnehin stateless (Webserver z.B.); dann sind Failovers
> eh kein Problem. Oder die Software schreibt Snapshots,
> so daß ein anderer Server dort weitermachen kann.
>
> Datenbanksysteme sind ein gutes Beispiel — wenn eine
> Transaktion das Commit mit “OK” bestätigt hat dann ist
> garantiert daß die Transaktion permanent gespeichert ist.
> Fällt also ein Server aus dann werden dessen offene
> Transaktionen einfach zurückgesetzt, und eine andere
> Maschine fängt halt an neue Transaktionen anzunehmen.
> Mit etwas Trickserei würde man es sicherlich sogar
> hinbekommen einen Teil der offenen Transaktionen auf
> den neuen Server mitzunehmen; ob man diesen Aufwand
> allerdings treiben will…
Ist ja vielleicht ein wenig spät….
Marathon Technology hat schon vor Jahren eine Lösung erdacht, die im
wesentlichen darauf hinauslief, den IO für zwei Rechner zu
duplizieren und diese so synchron zu halten. Ursprünglich eine
Hardwarelösung mit vier physischen Rechnern für einen
fehlertoleranten logischen Server (zwei I/O nodes, zwei Processing
Nodes), haben sie meinen Vorschlag (von März 2000!) die Processing
Nodes in einem Hypervisor in den I/O nodes laufen zu lassen später
wohl aufgenommen und bieten everRun ohne spezielle Hardware an.
Inzwischen scheinen sie sich auch vom proprietären Hypervisor zu
verabschieden und arbeiten mit Xen zusammen.
Vielleicht ein wenig spät, denn inzwischen bietet VMware unter 3i
eine ähnliche Funktionalität auf Basis des VM-Recorders an.
Möglicherweise geht das dort sogar ohne hot-standby, d.h. der
Ersatzrechner kann anhand des Transaktionsprotokolles des
Primärrechners nachgefahren werden (solange die Storage überlebt).
Gegen den Ausfall eines ganzen Rechenzentrums hilft aber nur die
hot-Variante.
>
> Christian