DE112010003372T5

DE112010003372T5 - Paketspiegelung zwischen primären und sekundären virtualisierten Software-Abbildern für verbesserte Systemausfallumschaltungsleistung

Info

Publication number: DE112010003372T5
Application number: DE112010003372T
Authority: DE
Inventors: Lee Hyoungjoo
Original assignee: Avaya Inc
Current assignee: Avaya Inc
Priority date: 2010-01-04
Filing date: 2010-12-13
Publication date: 2012-09-06
Also published as: CN102473105A; GB2483042B; GB2483042A; WO2011081888A1; KR101280754B1; KR20120016298A; CN102473105B; GB201122355D0; US20110167298A1; US8145945B2

Abstract

Es ergibt sich ein Paketverlust bei dem Bereitschaftsserver während der Ausfallumschaltung, wenn das Primäre ausfällt. Es gibt gegenwärtig immer eine gewisse Menge an bedeutsamem Paketverkehr, der bei dem Primären ankommt, der während des Ausfallumschaltungszeitraums verlorengeht. Bei den vorhandenen Lösungen ist dieser Paketverlust während der Ausfallumschaltung unvermeidlich. Das Problem ist, dass, wenn diese Informationen verlorengehen, die Bereitschaft den Zustand des letzten Commits hat, so dass die Bereitschaft die Zustandsinformationen haben wird, die alt sind und den Systemzustand darstellen, der genau nur dem Systemzustand zum Zeitpunkt des letzten Commits entspricht. Eine Lösung ist ein Verfahren, bei dem alle ankommenden Datenpakete, die darauf gerichtet sind, an eine primäre Software-Anwendung, wie beispielsweise eine virtualisierte Software-Anwendung, übermittelt zu werden, die in einer primären virtuellen Maschine läuft, fortlaufend überwacht und durch ein Netz-Replikationsgerät kopiert werden, für eine gleichzeitige Übermittlung an ein Sicherungsabbild der Software-Anwendung, das auf einem Bereitschaftssystem läuft.

Description

TECHNOLOGISCHES GEBIET
Ein beispielhafter Aspekt ist auf eine Verbesserung der System-Ausfallumschaltungsleistung gerichtet. Insbesondere ist ein beispielhafter Aspekt auf eine Verbesserung der System-Ausfallumschaltungsleistung in Software-Umgebungen mit Hochverfügbarkeit (High Availability – HA) gerichtet.
ALLGEMEINER STAND DER TECHNIK
Die Replikation von Software-Anwendungen unter Verwendung von Virtual-Machine-(VM-)Plattformen und -Technologien auf dem neuesten Stand der Technik ist eine sehr leistungsstarke und flexible Weise, Hochverfügbarkeitsgarantien für Anwender von Software-Anwendungen bereitzustellen. Anwendungsanbieter können Nutzen aus der VM-Technologie ziehen, um Zuverlässigkeit in ihre Lösungen einzubauen, durch das Erzeugen von mehreren Abbildern (oder Kopien) der Software-Anwendung, die gleichzeitig, aber unabhängig voneinander, laufen. Diese Abbilder können auf dem gleichen physischen Gerät, z. B. einem Allzweck-Anwendungsserver, oder innerhalb von mehreren, entkoppelten VM-Containern laufen, oder sie können über mehrere physische Rechner in entkoppelten VM-Containern entwickelt werden. Es gibt mehrere VM-Replikationsschemen, aber im Allgemeinen haben VM-Lösungen ein primäres Software-Abbild, das Software-Dienste für Anwender liefert, und dann ein sekundäres oder tertiäres Sicherungsabbild auf einem Bereitschaftsserver, das im Fall eines Ausfalls für das primäre übernehmen kann. Die Sicherungsabbilder werden im Allgemeinen in diskreten Zeitabständen synchronisiert, um die Datenstrukturen und die Datenbank der Sicherungsserver zu aktualisieren, um Veränderungen nachzuvollziehen, die seit dem letzten Zeitpunkt, an dem die Datensynchronisierungsaktualisierung stattfand, stattgefunden haben. Die Synchronisierung wird als „Commit” bezeichnet, und diese Lösungen gewährleisten für einen Software-Anwendungsanbieter drastische Verbesserungen bei der Fähigkeit, zu garantieren, dass seine Anwender einen zuverlässigen Zugang zu den Software-Anwendungsdiensten erhalten werden.
In Hochverfügbarkeitsumgebungen arbeiten ein primäres (aktives) und ein sekundäres (passives) System zusammen, um eine Zustandssynchronisierung sicherzustellen, entweder in engem Gleichschritt, wie beispielsweise fehlertolerante Tandem- und Stratus-Systeme, oder in loser Gleichschritt, wie beispielsweise weniger teure Cluster. Immer wenn es auf einer Ebene des Systems eine Zustandsveränderung gibt, sendet das Primäre den kurz gefassten Zustand an das Sekundäre, das seinen Zustand unter Verwendung des kurz gefassten Zustandes abstimmt, um sich mit dem Primären zu synchronisieren. Wenn das Primäre ausfällt, bevor es dazu in der Lage ist, irgendwelche Informationen zu übermitteln, die es seit der letzten Fixpunkt-Operation gesammelt hat, werden diese Informationen üblicherweise, auf der Grundlage des Datums, zu dem sie empfangen werden, lokal durch das Sekundäre wiedergegeben, und es versucht, sich selbst zu synchronisieren, bevor es als Primäres übernimmt.
ZUSAMMENFASSUNG
Es gibt jedoch ein kritisches Problem bei der VM-Replikation von Software-Anwendungen, das nach einer Lösung verlangt. Das Problem ist der Paketverlust bei dem Bereitschaftsserver während der Ausfallumschaltung, der sich ergibt, wenn das Primäre ausfällt. Es gibt gegenwärtig immer eine gewisse Menge an bedeutsamem Paketverkehr, der bei dem Primären ankommt, der während des Ausfallumschaltungszeitraums verlorengeht. Bei den vorhandenen Lösungen ist dieser Paketverlust während der Ausfallumschaltung unvermeidlich. Das Problem ist, dass, wenn diese Informationen verlorengehen, die Bereitschaft den Zustand des letzten Commits hat, so dass die Bereitschaft die Zustandsinformationen haben wird, die alt sind und den Systemzustand darstellen, der genau nur dem Systemzustand zum Zeitpunkt des letzten Commits entspricht.
Ein vorhandenes Beispiel für einen Versuch, dieses Problem zu überwinden, ist Link Bouncing. Remus (http://people.cs.ubc.ca/~brendan/papers/remus-nsdi08.pdf) versuchte, das gleiche Problem durch das Puffern der abgehenden Pakete in einem aktiven Puffer zu lösen. Jedoch leidet die Umsetzung von Remus unter einem großen Leistungshandicap, so dass sie in den meisten Produktionssoftware-Umgebungen nicht verwendbar ist. Bei Remus ist die Hauptursache des Leistungshandicaps, dass die Übertragung der Netzpakete, die dem Verlorengehen ausgesetzt sind, bis zu dem nächsten Fixpunkt/Commit verzögert wird.
Geschichtlich ist die Ausgangspraxis für eine Ausfallumschaltung mit Daten die Verwendung von Fixpunktintervallen, während derer die Daten auf den Sicherungsservern auf den aktuellen Stand gebracht werden. Jedoch verlieren, wie oben erörtert, die verfügbaren Lösungen entweder Daten während der Ausfallumschaltung oder, im besten Fall, falls sie ankommende Daten während der Ausfallumschaltung puffern, leiden sie unter einem enormen Leistungshandicap.
Nach einem Ausführungsbeispiel wird ein System oder ein Mechanismus konstruiert, das/der ein Verfahren umsetzt, bei dem alle ankommenden Datennetzpakete, die darauf gerichtet sind, an ein(e) primäre(s) Software-Anwendung oder -System, wie beispielsweise eine virtualisierte Software-Anwendung, die in einer primären virtuellen Maschine (VM) läuft, übermittelt zu werden, fortlaufend durch ein Netzreplikationsgerät oder einen -treiber (Network Replication Device or driver – NRD) überwacht und aufgespalten oder kopiert werden, für eine gleichzeitige Übermittlung an ein Sicherungsabbild der Software-Anwendung, das auf einem Bereitschaftssystem oder einer VM läuft. Diese Daten werden durch das NRD in Echtzeit oder nahezu Echtzeit aufgespalten oder kopiert und an das Bereitschaftsanwendungsabbild übermittelt, mit dem Ziel, eine verringerte oder keine Anwendungsausfallzeit zu erreichen. Ein zweiter beispielhafter Nutzen des NRD ist seine Fähigkeit, eine verringerte oder keine Anwendungsleistungsverschlechterung im Ergebnis des Paketverlustes während eines Ausfallumschaltungsereignisses zu ermöglichen. Ein Ausführungsbeispiel geht davon aus, dass die/das VM-Plattform/-System, worauf die Technologie angewendet werden wird, aktuelle Fixpunkt-Commit- und Störungserkennungsmechanismen „nach dem neuesten Stand der Technik” einschließt.
Wenn (ein) Fixpunkt-Commit- und Störungserkennungssystem(e) vorhanden ist/sind, kann die grundlegende Logik für die NRD-Netzreplikationstechniken als ein Netzreplikationstreiber umgesetzt werden, der vollständig in Hardware und/oder in Software, die koresident auf dem Server oder den Servern läuft, welche(r) die Software-Anwendungsabbilder und VMs hostet/hosten, umgesetzt wird. Alternativ dazu und vielleicht in einer anderen beispielhaften Umsetzung, könnte das NRD als (ein) selbständige(s) „Bump-in-the-Wire”-eingebettetes Datenverarbeitungsgerät(e) umgesetzt werden, das/die physisch unabhängig von dem Server oder den Servern, welche(r) die VM-Software-Anwendungsabbilder hostet/hosten, gespeist und eingesetzt wird/werden. In dem Obermengenfall von primären und sekundären physischen Servern, die primäre und sekundäre virtualisierte Abbilder der Software-Anwendung hosten, könnte ein Ausführungsbeispiel ebenfalls ein primäres (aktives) und ein sekundäres (Bereitschafts-)NRD einschließen.
Das NRD kann in dem/der aktiven und/oder dem/der Bereitschaftsserver oder -anwendung oder an einer anderen Position in dem Netz laufen. Nach einem Ausführungsbeispiel wird das aktive NRD die Pakete, die an der VM ankommen, kopieren, die Zieladresse zu einem Bereitschaftsziel verändern und die Pakete zu dem Bereitschaftsserverdienst weiterleiten. Bei diesem Ausführungsbeispiel könnte das Bereitschaftsziel eine DOM0-(Domäne-Null-)Position sein, wobei das System in einer Hypervisor-Umgebung umgesetzt wird. Jedoch könnte sich diese Position im Allgemeinen irgendwo innerhalb des Systems befinden. Das Bereitschafts-NRD wird die Pakete wie folgt Puffern:

– Beim Fixpunkt-Commit wird das Bereitschafts-NRD die Puffernetzpakete bis hin zu dem Commit löschen.
– Bei der Störungserkennung wird das Bereitschafts-NRD das Pufferpaket an das vor kurzem als virtuelle Maschine aktivierte Bereitschaftsgerät übermitteln.

Ein Ausführungsbeispiel verwendet einen Satz von entkoppelten, Bump-in-the-Wire-Puffergeräten, wobei die Funktionsweise konzeptionell identisch ist. Bei der Umsetzung jedoch werden die Pakete vor der Ankunft an dem primären Server, der die primäre VM laufen lässt, durch das primäre „Bump”-Gerät abgefangen. Danach werden sie zu dem sekundären Bump-in-the-Wire abgespalten, für das Puffern für das Sicherungs-/Bereitschaftssoftware-Abbild im Fall eines Ausfalls.
Bei der Bump-in-the-Wire-Umsetzung könnten, wenn das Primäre ausfällt, selbst wenn es ein katastrophaler Hardware-Ausfall ist, die Bump-Geräte sicherstellen, dass keines der ankommenden Pakete für das Primäre verlorengeht. Bei einem Ausfall könnte dann das sekundäre Abbild eingeleitet werden und beginnen, den Verkehr zu handhaben, mit der Fähigkeit den Zustand des Primären vollständig wiederherzustellen, weil keine ankommenden Pakete für das Primäre verlorengingen. Zusätzlich wird keine Leistung geopfert, weil die Bump-Geräte nicht auf das Spiegeln der Daten nur zu diskreten, Fixpunkt-Commit-Intervallen begrenzt sind. Als Teil dieses Szenarios könnten der sekundäre Bump und der primäre Bump bei einer Ausfallumschaltung die Rollen wechseln, von dem primären Bump zu dem sekundären und umgekehrt. Der sekundäre Bump, der nach dem Ausfall wie ein primärer agiert, könnte beginnen, Daten dorthin zu spiegeln, wo vorher der primäre Bump war, der nun die Rolle des sekundären spielt.
Inzwischen kann der primäre Server, der ausfiel, ersetzt und neu gestartet werden, während die beiden Bump-Geräte ihren ununterbrochenen Betrieb fortsetzen. Sobald der primäre Server ersetzt/neu gestartet ist, kann das System nun ein Wiederherstellungs-„Rücktausch” vornehmen, wobei der „Bereitschafts”-Server ein Commit von Zustand, Verkehr und Ownership-Session-Operationen zurück zu dem ersetzten/neu gestarteten „primären” Server vornimmt. Dies wäre wieder möglich, ohne irgendeine(n) Zustand oder Verfügbarkeit zu verlieren, wobei wieder die zwei physisch gesonderten Bump-Geräte wirksam eingesetzt werden.
Ein beispielhafter Vorteil dieser Herangehensweise gegenüber früheren Lösungen ist, dass sie es ermöglicht, dass eine virtualisierte Software-Anwendung mit mehreren Abbildern selbst angesichts eines katastrophalen Ausfalls der primären Hardware oder Software durchgehende und ununterbrochene Dienste für Anwender der Software-Anwendung bereitstellt.
Ein anderer beispielhafter Aspekt ist auf das Abkoppeln der Handhabung des ankommenden Verkehrs für ein virtualisiertes Software-Abbild von der primären Funktionsweise dieser virtualisierten Software-Anwendung gerichtet. Zusätzlich sind weitere interessante Aspekte in dem Gedanken zu finden, diese Verkehrshandhabung physisch zu einem Satz von unabhängig eingesetzten Bump-in-the-Wire-Geräten abzukoppeln, welche diese koordinierte Pufferungsoperation durchführen.
Ein anderes Ausführungsbeispiel ist auf eine Netzreplikation in einer VM-Umgebung, und insbesondere eine VM-Replikation, gerichtet. VM-Replikation, die in Puffer eines oder mehr von Netzinformationen, Anwendungsdaten und im Allgemeinen jegliche Art von Daten, Systemdaten usw. speichert, wird ein sehr beherrschender Weg für das Bereitstellen von hohem Zugang in virtualisierten Systemen. Es gibt jedoch ein großes Problem bei der VM-Replikation, und doch gibt es keine vollkommene Lösung. Das beispielhafte Problem ist der Paketverlust während der Ausfallumschaltung. Da es während der Ausfallumschaltung eine VM-Ausfallzeit gibt und die Bereitschaft typischerweise bei jedem Fixpunktintervall synchronisiert wird, ist ein Paketverlust während der Ausfallumschaltung unvermeidlich.
Daher ist es ein Ausführungsbeispiel, Netzpakete in Echtzeit bei (einem) Bereitschaftsserver(n) zu Puffern. Dies gewährleistet wenigstens eine beträchtliche Steigerung bei der Systemleistung. Diese Annahme ist jedoch darauf gegründet, dass das System mit Fixpunkt-Commit und Störungserkennung durch andere Mittel versehen ist.
Nach einem Ausführungsbeispiel kann die grundlegende Logik für die Netzreplikation als ein Netzreplikationstreiber umgesetzt werden. Das NRD kann in einem oder mehreren von dem aktiven und dem Bereitschaftsserver laufen und kann wahlweise an einer anderen Position innerhalb eines Kommunikations- oder Datenverarbeitungsnetzes angeordnet sein. Das aktive NRD wird die Pakete, die zu der VM kommen, kopieren, die Zieladresse zu einer Bereitschaftsadresse verändern und die Pakete zu dem Bereitschaftsgerät oder -server weiterleiten. Das Bereitschafts-NRD wird die Pakete Puffern und Folgendes tun:

– Beim Fixpunkt-Commit wird das Bereitschafts-NRD die gepufferten Netzpakete bis hin zu dem Fixpunkt löschen.
– Bei der Störungserkennung wird das Bereitschafts-NRD die gepufferten Pakete an die vor kurzem aktivierte virtuelle Maschine übermitteln.

Ein anderer Aspekt ist auf eine Technik gerichtet, wobei, anstatt abgehende Pakete zu Puffern, ankommende Netzpakete zu einer/m Bereitschaftsmaschine, -server, -gerät oder virtuellen Maschine kopiert werden. Einige der ankommenden Pakete erreichen während der Ausfallumschaltung unvermeidlich nicht die aktive Maschine, weil dieses Gerät zu dieser Zeit nicht vorhanden sein mag. Jedoch werden die Pakete in einem Puffer für die Bereitschaftsmaschine gesichert. Nachdem die Bereitschaftsmaschine übernimmt, können die gesicherten Netzpakete an die vor kurzem aktivierte Maschine oder virtuelle Maschinen zurückgespielt werden, so dass der Zustandsverlust auf Grund von Netzpaketverlust auf ein Minimum verringert wird.
Im Einzelnen tritt ein Zustandsverlust einer virtuellen Maschine auf die folgende Weise auf. Angenommen, es gibt nur eine Speicherreplikation der virtuellen Maschine durch Fixpunkt-Operation. Angenommen, zum Zeitpunkt T befindet sich das Aktive mitten in der N-ten Fixpunkt-Operation. Die Bereitschaft hat den Zustand des letzten Fixpunktes, der N – 1 ist. Während der N-ten Fixpunkt-Operation empfängt die aktive VM ein Paket, genannt „verlorenes Paket”, von einem dient, der dieses Paket quittiert, dann kommt sie irgendwie zum Stillstand, bevor sie das Commit für den aktuellen Fixpunkt durchführt. Dann wird die Bereitschaft von dem Zustand des letzten Fixpunktes N – 1 an übernehmen. Also hat die vor kurzem aktivierte VM nun das „verlorenes Paket” genannte Paket verloren. Nach einem Ausführungsbeispiel kann die Bereitschaft das verlorene Paket wiederherstellen durch das Wiedergeben oder Auslesen des Verlorenen Paketes, um den Zustand vor dem Ausfall wiederherzustellen.
In Hochverfügbarkeitsumgebungen arbeiten ein primäres (aktives) und ein sekundäres (passives) System zusammen, um eine Zustandssynchronisierung sicherzustellen, entweder in engem Gleichschritt, wie beispielsweise fehlertolerante Tandem- und Stratus-Systeme, oder in loser Gleichschritt, wie beispielsweise weniger teure Cluster. Immer wenn es auf einer Ebene des Systems eine Zustandsveränderung gibt, sendet das Primäre den kurz gefassten Zustand an das Sekundäre, das seinen Zustand unter Verwendung des kurz gefassten Zustandes abstimmt, um sich mit dem Primären zu synchronisieren. Wenn das Primäre ausfällt, bevor es dazu in der Lage ist, irgendwelche Informationen zu übermitteln, die es seit der letzten Fixpunkt-Operation gesammelt hat, werden diese Informationen üblicherweise, auf der Grundlage des Datums, zu dem sie empfangen werden, lokal durch das Sekundäre wiedergegeben, und es versucht, sich selbst mit dem Externen zu synchronisieren, bevor es als Primäres übernimmt. Es ist diese letztere Art von Nicht-Fixpunkt-Daten, die ein beispielhafter Aspekt der Technologie unmittelbar zu dem Sekundären repliziert, anstatt an den Daten festzuhalten und die Daten später von dem Primären aus zu senden, was zu zwei Nachteilen führt:
Einer ist, dass es die Sendewarteschlange beherrscht, und zweitens verursacht es einen zusätzlichen Stillstand, wenn ein Fixpunkt von dem Primären aus gesendet wird; im Fall einer Hochverfügbarkeit in der Art von Remus führt es zu Speicherressourcenabzug von dem aktiven Primären während der Zeiten einer hohen Aktivität.
Folglich wird das Übernehmen des anfänglichen Mehraufwandes des frühzeitigen Aufspaltens der Netzdatagramme zu dem Sekundären aufgewogen durch die Vorteile der Vermeidung der oben aufgezählten Nachteile. Selbstverständlich werden, wenn eine Zustandsfixpunkt-Meldung von dem Primären ankommt, diese gepufferten Datagramme durch das Sekundäre verworfen, nachdem es in sich ein Commit für diesen Zustand durchgeführt hat.
Die hierin beschriebenen Techniken können in Abhängigkeit von der besonderen Konfiguration eine Anzahl von Vorteilen bereitstellen. Diese und andere Vorteile werden aus der hierin enthaltenen Offenbarung offensichtlich werden.
Die Wendungen „wenigstens ein”, „ein oder mehr” und „und/oder” sind offene Ausdrücke, die in der Funktion sowohl verbindend als auch trennend sind. Zum Beispiel bedeutet jeder der Ausdrücke „wenigstens eines von A, B und C”, „wenigstens eines von A, B oder C”, „eines oder mehrere von A, B und C”, „eines oder mehrere von A, B oder C” und „A, B und/oder C” A allein, B allein, C allein, A und B zusammen, A und C zusammen, B und C zusammen oder A, B und C zusammen.
Der Begriff „ein” oder „eine” Einheit bezieht sich auf eine oder mehrere dieser Einheit. Daher können die Begriffe „ein” (oder „eine”), „ein und mehr” und „wenigstens ein” hierin gegenseitig austauschbar verwendet werden. Es ist ebenfalls zu bemerken, dass die Begriffe „umfassend”, „einschließlich” und „aufweisend” gegenseitig austauschbar verwendet werden können.
Der Begriff „selbsttätig” und Variationen desselben, wie sie hierin verwendet werden, beziehen sich auf jeglichen Ablauf oder Arbeitsgang, der ohne wesentliche menschliche Eingabe, wenn der Ablauf oder Arbeitsgang durchgeführt wird, vorgenommen wird. Jedoch kann ein Ablauf oder Arbeitsgang selbsttätig sein, selbst wenn die Durchführung des Ablaufs oder Arbeitsgangs eine wesentliche oder unwesentliche menschliche Eingabe verwendet, falls die Eingabe vor der Durchführung des Ablaufs oder Arbeitsgangs empfangen wird. Eine menschliche Eingabe ist als wesentlich anzusehen, falls eine solche Eingabe beeinflusst, wie der Ablauf oder Arbeitsgang durchgeführt wird. Eine menschliche Eingabe, die der Durchführung des Ablaufs oder Arbeitsgangs zustimmt, ist nicht als „wesentlich” anzusehen.
Der Begriff „rechnerlesbares Medium”, wie er hierin verwendet wird, bezieht sich auf jegliches dingliche Speicher- oder Verteilungsmedium, das an der Bereitstellung von Anweisungen an einen Prozessor zur Ausführung beteiligt ist. Ein solches Medium kann viele Formen annehmen, einschließlich von nicht flüchtigen Medien, flüchtigen Medien und Übertragungsmedien, aber ohne darauf begrenzt zu sein. Nicht flüchtige Medien schließen zum Beispiel NVRAM oder Magnet- oder optische Platten ein. Flüchtige Medien schließen dynamischen Speicher, wie beispielsweise Hauptspeicher, ein. Gebräuchliche Formen von rechnerlesbaren Medien schließen zum Beispiel eine Floppy-Disk, eine flexible Diskette, Festplatte, Magnetband oder ein beliebiges anderes magnetisches Medium, magneto-optisches Medium, eine CD-ROM, ein beliebiges anderes optisches Medium, Lochkarten, Papierband, ein beliebiges anderes physikalisches Medium mit Mustern aus Lächern, einen RAM, einen PROM und EPROM, einen FLASH-EPROM, ein Festkörpermedium, wie eine Speicherkarte, eine(n) beliebige(n) andere(n) Speicherchip oder -kassette, eine Trägerwelle, wie sie im Folgenden beschrieben wird, oder ein beliebiges anderes Medium, von dem ein Rechner lesen kann, ein. Ein digitaler Dateianhang an E-Mail oder ein anderes in sich geschlossenes Informationsarchiv oder eine Menge von Archiven ist als ein Verteilungsmedium, äquivalent zu einem dinglichen Speichermedium, zu betrachten. Wenn die rechnerlesbaren Medien als eine Datenbank konfiguriert sind, versteht es sich, dass die Datenbank eine beliebige Art von Datenbank, wie beispielsweise relational, hierarchisch, objektorientiert und/oder dergleichen, sein kann.
Während mit denn vorliegenden System leitungs- oder paketvermittelte Arten von Kommunikationsverbindungen verwendet werden können, sind die hierin offenbarten Konzepte und Techniken auf andere Protokolle anwendbar.
Dementsprechend ist davon auszugehen, dass die Offenbarung ein dingliche Speichermedium oder Verteilungsmedium und vom Stand der Technik anerkannte Äquivalente und Nachfolgemedien einschließt, in denen die Software-Umsetzungen der vorliegenden Technologie gespeichert sind.
Die Begriffe „bestimmen”, „berechnen” und „ausrechnen” und Variationen derselben, wie sie hierin verwendet werden, werden gegenseitig austauschbar verwendet und schliefen jegliche Art von Methodologie, Verfahren, mathematischer Operation oder Technik ein.
Der Begriff „Modul”, wie er hierin verwendet wird, bezieht sich auf jegliche bekannte oder später entwickelte Hardware, Software, Firmware, künstliche Intelligenz, unscharfe Logik oder Kombination von Hardware und Software, die dazu in der Lage ist, die mit diesem Element verbundene Funktionalität zu leisten. Außerdem sollte, während die Technologie bezogen auf Beispiele beschrieben wird, zu erkennen sein, dass einzelne Aspekte der Technologie gesondert beansprucht werden können.
Das Vorstehende ist eine vereinfachte Zusammenfassung der Technologie, um ein Verständnis einiger Aspekte derselben zu gewährleisten. Diese Zusammenfassung ist weder eine umfassende noch eine vollständige Übersicht der Technologie und ihrer verschiedenen Ausführungsformen. Sie ist weder dafür vorgesehen, entscheidende oder wesentliche Elemente der Technologie zu identifizieren, noch dafür, den Rahmen der Technologie zu umreißen, sondern dafür, ausgewählte Konzepte der Technologie in einer vereinfachten Form als eine Einführung zu der weiter unten dargestellten ausführlicheren Beschreibung zu geben. Wie zu erkennen sein wird, sind unter Benutzung eines oder mehrerer der weiter oben dargelegten oder weiter unten ausführlich beschriebenen Merkmale, allein oder in Kombination, andere Ausführungsformen der Technologie möglich.
KURZE BESCHREIBUNG DER ZEICHNUNGEN
Die vorliegende Offenbarung wird ausführlich beschrieben werden, unter Bezugnahme auf die folgenden Figuren, in denen:
1 ein beispielhaftes Ausfallumschaltungssystem illustriert,
2 bis 4 beispielhafte Zeitdiagramme illustrieren und
5 ein beispielhaftes Verfahren des Betriebs des Ausfallumschaltungssystems illustriert.
AUSFÜHRLICHE BESCHREIBUNG
Ein Ausführungsbeispiel der Technologie wird weiter unten in Bezug auf eine System-Ausfallumschaltungsumgebung beschrieben werden. Obwohl sie gut für eine Verwendung mit VMs geeignet sind, sind die beispielhaften Aspekte nicht auf eine Verwendung mit einer beliebigen bestimmten Art von Gerät oder von Systemelementen begrenzt. Die Fachleute auf dem Gebiet werden erkennen, dass die offenbarten Techniken in einer beliebigen Umgebung verwendet werden können, bei der es wünschenswert ist, eine System-Ausfallumschaltungswiederherstellung bereitzustellen.
Die beispielhaften Systeme und Verfahren werden ebenfalls in Bezug auf Software, Module und zugeordnete Hardware und Netz(e) beschrieben werden. Um ein unnötiges Verunklaren der vorliegenden Offenbarung zu vermeiden, lässt die folgende Beschreibung gut bekannte Strukturen, Komponenten und Geräte weg, die in Blockdiagrammform gezeigt werden können, gut bekannt sind oder auf andere Weise zusammengefasst werden.
Zu Zwecken der Erläuterung werden zahlreiche Einzelheiten dargelegt, um ein umfassendes Verständnis der vorliegenden Technologie zu gewährleisten. Es sollte jedoch zu erkennen sein, dass die Technologie in einer Vielzahl von Weisen über die hierin dargelegte Einzelheit hinaus umgesetzt werden kann.
Es kann eine Zahl von Variationen und Modifikationen verwendet werden. Es wäre möglich, einige Merkmale der Erfindung bereitrustellen oder zu beanspruchen, ohne andere bereitzustellen oder zu beanspruchen.
Die beispielhaften Systeme und Verfahren sind in Bezug auf Verbesserungen der System-Ausfallumschaltung beschrieben worden. Jedoch lässt die Beschreibung eine Anzahl von bekannten Strukturen und Geräten weg, um ein unnötiges Verunklaren der vorliegenden Offenbarung zu vermeiden. Dieses Weglassen ist nicht als eine Begrenzung des Rahmens der Ansprüche zu deuten. Es werden spezifische Einzelheiten dargelegt, um ein Verständnis der vorliegenden Technologie zu gewährleisten. Es sollte jedoch zu erkennen sein, dass die Technologie in einer Vielzahl von Weisen über die hierin dargelegte Einzalheit hinaus umgesetzt werden kann.
Ferner können, während die hierin illustrierten Ausführungsbeispiele verschiedene Komponenten des Systems nebeneinander stehend zeigen, bestimmte Komponenten des Systems entfernt, an entfernten Abschnitten eines verteilten Netzes, wie beispielsweise eines LAN, eines Kabelnetzes und/oder des Internets, oder innerhalb eines dedizierten Systems angeordnet sein. Folglich sollte zu erkennen sein, dass die Komponenten des Systems zu ein oder mehr Geräten, wie beispielsweise einem Gateway, kombiniert oder nebeneinander auf einem bestimmten Knoten eines verteilten Netzes, wie beispielsweise eines analogen und/oder eines digitalen Kommunikationsnetzes, eines paketvermittelten Netzes, eines leitungsvermittelten Netzes oder eines Kabelnetzes, stehen können.
1 umreißt eine beispielhafte Datenverarbeitungsumgebung 1. Die Datenverarbeitungsumgebung 1 schließt ein aktives Gerät 100 und ein Bereitschaftsgerät 200, die durch ein oder mehrere Netze 10 und Verbindungen 5 verbunden werden, ein. Sowohl das aktive Gerät 100 als auch das Bereitschaftsgerät 200 schließen ein Commit-Modul (110, 210), ein Gerätezustandsmodul (120, 220), (einen) Prozessor(en) (130, 230), Speicher (140, 240), Server (150, 250), (eine) Datenbank(en) (160, 260), einen wahlweisen Puffer (170, 270) und ein NRD-Modul (180, 280), die über ein oder mehrere Netze 10 und Verbindungen 5 verbunden sind, ein. Der wahlweise Puffer 175 kann ebenfalls irgendwo innerhalb einer Datenverarbeitungsumgebung 1 angeordnet sein, wobei das Gerät, das gegenwärtig aktiv ist, typischerweise Datenpakete von einem oder mehreren Clients über die Netze 10 und die Verbindungen 5 empfängt.
Im Betrieb wird ein primäres System aktiviert (aktives Gerät/System). Nach dem ersten Ausführungsbeispiel ist das aktive Gerät das Gerät 100, wobei das Bereitschaftsgerät das Gerät 200 ist. In Zusammenwirken mit dem Commit-Modul 110 führt das Commit-Modul 110 zu vorbestimmten Zeiten ein Commit durch, wodurch der Zustand des aktiven Gerätes 100 bewahrt wird (siehe 2–4). Nach dem Fertigstellen dieses Commits und in Zusammenwirken mit dem Prozessor 130 und dem wahlweisen Puffer 170 oder 175 werden alle ankommenden Datenpakete von den Clients 2 zu dem Bereitschaftsgerät 200 kopiert. Diese Pakete können in einem oder mehreren von dem Puffer selbst oder zum Beispiel in der Datenbank 260 gespeichert werden. Im Einzelnen überwacht das NRD-Modul 180 alle ankommenden Datenpakete von den Clients 2, die durch das NRD-Modul 180 fortlaufend überwacht und aufgespalten oder gespiegelt werden, für eine gleichzeitige Übermittlung an das Bereitschaftsgerät, das ein Sicherungsabbild der Software-Anwendung(en), die auf dem aktiven Gerät 100 läuft/laufen, verwaltet. Diese können durch das NRD-Modul 180 in Echtzeit aufgespalten und an das Bereitschaftsgerät 200 übermittelt werden, wobei ein beispielhaftes Ziel desselben ist, eine verringerte oder keine Anwendungsausfallzeit zwischen den zwei Geräten zu erreichen.
Wie erörtert, kann das NRD-Modul 180 in Hardware oder Software, die koresident auf dem Gerät oder dem/den Server(n) läuft, welche(s/r) die Abbilder von Software-Anwendung und VMs hostet/hosten. Bei einem anderen Ausführungsbeispiel kann das NRD als ein selbständiges „Bump-in-the-Wire”-eingebettetes Datenverarbeitungsgerät umgesetzt werden, das physisch unabhängig von dem Server oder den Servern, welche(r) die VM-Software-Anwendung über Abbilder hostet/hosten, gespeist und eingesetzt wird.
Im Fall eines Ausfalls gibt das Bereitschaftsgerät 200, in Zusammenwirken mit dem Prozessor 230 und dem Gerätezustandsmodul 220, die kopierten Pakete wieder, um von dem letzten Commit zu dem aktuellen Zustand wiederherzustellen. Danach ist es möglich, dass sich die Verarbeitung ohne einen Verlust von Datenpaketen von dem Ausfallumschaltungspunkt aus fortsetzt. An diesem Punkt ist das Bereitschaftsgerät 200 nun das „aktive Gerät” und agiert als das primäre System, bis das ausgefallene aktive Gerät 100 wiederhergestellt und wieder online gestellt ist. Sobald das ausgefallene aktive Gerät 100 wiederhergestellt/repariert/neu gestartet ist, kann das System wahlweise ein Wiederherstellungs-„Rücktausch” vornehmen, wobei das aktive Bereitschaftsgerät 200 ein Commit von Zustand, Verkehr und Ownership-Session-Operationen zurück zu dem ersetzten/reparierten/neu gestarteten aktiven Gerät 100 vornimmt. Wieder ist dies ohne einen Verlust von Zustand oder Datenpaketen möglich.
2 umreißt ein beispielhaftes Zeitdiagramm, das den Punkt und die Zeit, wo das letzte Commit vorgenommen wird, den Zeitraum, während dessen replizierte Pufferpakete gespeichert werden, und einen Punkt in der Zeit, zu dem die Bereitschaft die gepufferten Daten dazu verwendet, die Operationen von dem ausgefallenen Punkt an fortzusetzen, hervorhebt. 3 und 4 umreißen die beispielhaften Zeitdiagramme dazu, wie nach einem Ausfall des aktiven Geräts verschiedene Aktivitäten stattfinden, bis das ausgefallene Gerät reaktiviert worden ist. Im Allgemeinen heben 3 und 4 Prozesse hervor, die stattfinden, wenn zum Beispiel das Bereitschaftsgerät 200 als das „primäre oder aktive” Gerät agiert, in dem Fall, dass das aktive Gerät 100 ausgefallen ist. Die Prozesse für einen Wiederherstellungsrücktausch von dem Bereitschaftsgerät 200 zu dem aktiven Gerät 100 sind die gleichen, wie wenn das aktive Gerät 100 das „primäre oder aktive” Gerät oder System in Betrieb ist.
Wie erörtert können die Puffer (170, 175, 270) an einem beliebigen Punkt innerhalb der Datenverarbeitungsumgebung 1 angeordnet sein. Außerdem können nach Bedarf mehrere Puffer bereitgestellt werden, vorausgesetzt, der Puffer ist dazu in der Lage, im Fall eines Ausfalls des aktiven Gerätes replizierte gepufferte Pakete an das/die Bereitschaftsgerät(e) oder -system weiterzuleiten. Die Puffer können, in Abhängigkeit von der besonderen Umgebung des Datenverarbeitungssystems 1, ebenfalls mit einem oder mehreren von den Speichern 140, 240 und den Datenbanken 150, 260 zusammenwirken.
5 umreißt eine beispielhafte Methodologie für das Gewährleisten von Hochverfügbarkeit in einer Software-Anwendungsumgebung. Im Einzelnen beginnt die Steuerung in Schritt S100 und setzt sich fort zu Schritt S110. In Schritt S110 wird ein primäres System aktiviert. Als Nächstes wird in Schritt S120 durch das primäre System ein Commit durchgeführt, um den Zustand für ein Bereitschaftssystem zu bewahren. Danach wird in Schritt S130 der gesamte ankommende Verkehr an das primäre System zu einem oder mehreren Puffern oder dem Bereitschaftssystem kopiert. Danach schreitet die Steuerung fort zu Schritt S140.
In Schritt S140 wird eine Feststellung getroffen, ob ein Ausfall stattgefunden hat. Falls ein Ausfall stattgefunden hat, springt die Steuerung zu Schritt S142. Anderenfalls schreitet die Steuerung fort zu Schritt S150.
In Schritt S150 wird eine Feststellung getroffen, ob der nächste Commit-Zustand erreicht worden ist. Falls er erreicht worden ist, springt die Steuerung zurück zu Schritt S120, wobei die Steuerung anderenfalls fortschreitet zu Schritt S130.
In Schritt S142 werden die zum Nutzen des Bereitschaftssystems kopierten Pakete von dem letzten Commit zu dem aktuellen Zustand wiedergegeben. Danach ist das Bereitschaftssystem in Schritt S144 dazu in der Lage, die Verarbeitung ohne einen Verlust von jeglichen Datenpaketen von dem Ausfallumschaltungspunkt aus zu beginnen. Danach agiert das Bereitschaftssystem in Schritt S146 als das primäre System, wobei die Steuerung fortschreitet zu Schritt S148, wo die Steuerungsabfolge endet.
Aus der vorstehenden Beschreibung und aus Gründen der rechnerischen Effizienz wird zu erkennen sein, dass die Komponenten des Systems an einem beliebigen Ort innerhalb eines verteilten Netzes von Komponenten angeordnet sein können, ohne die Funktionsweise des Systems zu beeinträchtigen. Zum Beispiel können die verschiedenen Komponenten in einem Switch, wie beispielsweise einem PBX- und Medienserver, einem Gateway, einem Kabel-Diensteanbieter, einem Unternehmenssystem, einer Client-Server-Umgebung, einem Verteilernetz, das einen oder mehrere Server einschließt, in einem oder mehreren Kommunikationsgeräten, bei den Räumlichkeiten eines oder mehrerer Anwender(s) oder einer Kombination derselben angeordnet sein. Ähnlich könnten einer oder mehrere funktionelle Abschnitte des Systems zwischen (einem) Telekommunikationsgerät(en) und einem zugeordneten Datenverarbeitungsgerät verteilt sein.
Ferner sollte zu erkennen sein, dass die verschiedenen Verbindungen, wie beispielsweise die Verbindung 5, welche die Elemente verbinden, drahtgebundene oder drahtlose Verbindungen oder eine beliebige Kombination derselben oder (ein) beliebige(s) andere(s) bekannte(s) oder später entwickelte(s) Element(e) sein können, die dazu in der Lage sind, Daten zu und von den verbundenen Elementen zu liefern und/oder zu übermitteln. Diese drahtgebundenen oder drahtlosen Verbindungen können ebenfalls sichere Verbindungen sein und können dazu in der Lage sein, verschlüsselte Informationen zu übermitteln.
Übertragungsmedien, die als Verbindungen verwendet werden, können zum Beispiel ein beliebiger geeigneter Träger für elektrische Signale, einschließlich von Koaxialkabeln, Kupferdraht und Lichtwellenleitertechnik, sein und können die Form von akustischen oder Lichtwellen, wie beispielsweise der während Hochfrequenz- und Infrarot-Datenübertragungen erzeugten, annehmen.
Außerdem sollte, während die Ablaufdiagramme in Bezug auf eine bestimmte Abfolge von Ereignissen erörtert und illustriert worden sind, zu erkennen sein, dass Veränderungen, Hinzufügungen und Weglassungen an dieser Abfolge auftreten können, ohne die Funktionsweise der Erfindung erheblich zu beeinträchtigen.
Bei noch einer anderen Ausführungsform können die Systeme und Verfahren dieser Technologie in Verbindung mit einem Spezialrechner, einem programmierten Mikroprozessor oder Mikrokontroller und (einem) peripheren integrierten Schaltungselement(en), einem ASIC oder einer anderen integrierten Schaltung, einem digitalen Signalprozessor, einer festverdrahteten elektronischen oder logischen Schaltung, wie beispielsweise, einer Schaltung aus diskreten Bauelementen, einem programmierbaren Logikbaustein oder Gateway, wie beispielsweise einem PLD, PLA, FGPA, PAL, einem Spezialrechner, einem beliebigen vergleichbaren Mittel oder dergleichen umgesetzt werden. Im Allgemeinen können (ein) beliebige(s) Gerät(e) oder Mittel, die dazu in der Lage sind, die hierin illustrierte Methodologie umzusetzen, dazu verwendet werden, die verschiedenen Aspekte dieser Technologie umzusetzen.
Beispielhafte Hardware, die für das vorliegende System verwendet werden kann, schließt Rechner, in der Hand zu haltende Geräte und andere auf dem Gebiet bekannte Hardware ein. Einige dieser Geräte schließen Prozessoren (z. B. einen einzelnen oder mehrere Mikroprozessoren), Speicher, nicht flüchtigen Speicher, Eingabegeräte und Ausgabegeräte ein. Darüber hinaus können alternative Software-Umsetzungen, einschließlich von verteilter Verarbeitung oder komponenten-/objektverteilte Verarbeitung, parallele Verarbeitung oder virtuelle Maschinenverarbeitung, aber ohne darauf begrenzt zu sein, ebenfalls dafür aufgebaut werden, die hierin beschriebenen Verfahren umzusetzen.
Bei noch einer anderen Ausführungsform können die offenbarten Verfahren leicht in Software umgesetzt werden, unter Verwendung von Objekt- oder objektorientierten Software-Entwicklungsumgebungen, die portierbaren Software-Code bereitstellen, der auf einer Vielzahl von Rechner- oder Arbeitsstationsplattformen verwendet werden kann. Alternativ dazu kann das offenbarte System teilweise oder vollständig in Hardware umgesetzt werden, unter Verwendung von standardmäßigen Logikschaltungen oder einer VLSI-Konstruktion. Ob Software oder Hardware verwendet wird, um die Systeme nach dieser Technologie umzusetzen, hängt von den Geschwindigkeits- und/oder Effizienzanforderungen des Systems, der besonderen Funktion und den besonderen Software- oder Hardwaresystemen oder Mikroprozessor- oder Mikrorechnersystemen, die benutzt werden, ab.
Bei noch einer anderen Ausführungsform können die offenbarten Verfahren teilweise in Software umgesetzt werden, die auf einem rechnerlesbaren Speichermedium gespeichert, auf einem programmierten Allzweckrechner mit der Mitwirkung eines Steuergeräts und eines Speichers, einem Spezialrechner, einem Mikroprozessor oder dergleichen ausgeführt werden. In diesen Fällen können die Systeme und Verfahren dieser Technologie als auf einem Arbeitsplatzrechner eingebettetes Programm, wie beispielsweise als ein Applet, ein JAVA^®- oder CGI-Skript, als eine Ressource, die auf einem Server oder einer Rechnerarbeitsstation liegt, als eine in ein dediziertes Mess-System eingebettete Routine, eine Systemkomponente oder dergleichen umgesetzt werden. Das System kann ebenfalls durch physisches Einbeziehen des Systems und/oder des Verfahrens in ein Software- und/oder ein Hardwaresystem umgesetzt werden.
Obwohl die vorliegende Offenbarung Komponenten und Funktionen beschreibt, die bei den Ausführungsformen unter Bezugnahme auf bestimmte Standards und Protokolle umgesetzt werden, ist die Offenbarung nicht auf solche Standards und Protokolle begrenzt. Andere ähnliche Standards und Protokolle, die hierin nicht erwähnt werden, sind vorhanden und werden als in der vorliegenden Offenbarung eingeschlossen betrachtet. Darüber hinaus werden die hierin erwähnten Standards und Protokolle und andere ähnliche Standards und Protokolle, die hierin nicht erwähnt werden, in regelmäßigen Abständen durch schnellere oder effektivere Äquivalente abgelöst, die im Wesentlichen die gleichen Funktionen haben. Solche Ersatzstandards und -protokolle, welche die gleichen Funktionen haben, werden als in der vorliegenden Offenbarung eingeschlossene Äquivalente betrachtet.
Die vorliegende Offenbarung schließt, in verschiedenen Ausführungsformen, Konfigurationen und Aspekten, Komponenten, Verfahren, Prozesse, Systeme und/oder Vorrichtungen, im Wesentlichen, wie sie hierin abgebildet und beschrieben werden, einschließlich von verschiedenen Ausführungsformen, Unterkombinationen und Untermengen derselben, ein. Die Fachleute auf dem Gebiet werden nach dem Verstehen der vorliegenden Offenbarung verstehen, wie die vorliegende Technologie herzustellen und zu verwenden ist. Die vorliegende Technologie schließt, in verschiedenen Ausführungsformen, Konfigurationen und Aspekten, das Bereitstellen von Geräten und Prozessen ein, in der Abwesenheit von Gegenständen, die hierin oder in verschiedenen Ausführungsformen, Konfigurationen oder Aspekten hiervon nicht abgebildet und/oder beschrieben sind, einschließlich in der Abwesenheit von solchen Gegenständen, wie sie bei vorherigen Geräten oder Prozessen, z. B. zur Verbesserung der Leistung, Zum Erreichen von Einfachheit und/oder zum Verringern von Umsetzungskosten, verwendet worden sein können.
Die vorstehende Erörterung ist zu Zwecken der Illustration und Beschreibung dargeboten worden. Es ist nicht beabsichtigt, dass das Vorstehende die Offenbarung auf die hierin offenbarte(n) Form oder Formen begrenzt. In der vorstehenden Ausführlichen Beschreibung werden zum Beispiel zum Zweck des Straffens der Offenbarung verschiedene Merkmale der Technologie in einer oder mehreren Ausführungsformen, Konfigurationen und Aspekten zusammen gruppiert. Die Merkmale der Ausführungsformen, Konfigurationen und Aspekte der Technologie können in alternativen Ausführungsformen, Konfigurationen und Aspekten, die sich von den weiter oben erörterten unterscheiden, kombiniert werden. Dieses Verfahren der Offenbarung ist nicht so auszulegen, dass es eine Absicht widerspiegelt, dass die beanspruchte Technologie mehr Merkmale erfordert, als sie ausdrücklich in jedem Anspruch angeführt werden. Stattdessen liegen, wie es die folgenden Ansprüche widerspiegeln, die erfinderischen Aspekte in weniger als allen Merkmalen einer/eines einzelnen vorstehend offenbarten Ausführungsform, Konfiguration oder Aspekts. Folglich werden die folgenden Ansprüche hiermit in diese Ausführliche Beschreibung einbezogen, wobei jeder Anspruch für sich als eine gesonderte bevorzugte Ausführungsform steht.
Darüber hinaus liegen, obwohl die Beschreibung der Technologie die Beschreibung einer oder mehrerer Ausführungsformen, Konfigurationen oder Aspekte und bestimmter Variationen und Modifikationen eingeschlossen hat, andere Variationen, Kombinationen und Modifikationen innerhalb des Rahmen der Erfindung, wie sie z. B. nach dem Verstehen der vorliegenden Offenbarung innerhalb der Fähigkeit und des Wissens der Fachleute auf dem Gebiet liegen können. Es ist beabsichtigt, Rechte zu erwerben, die alternative Ausführungsformen, Konfigurationen oder Aspekte bis zu dem erlaubten Umfang einschließen, einschließlich von alternativen, wechselseitig austauschbaren und/oder äquivalenten Strukturen, Funktionen, Bereichen oder Schritten zu den beanspruchten, ob solche alternativen, wechselseitig austauschbaren und/oder äquivalenten Strukturen, Funktionen, Bereiche oder Schritte hierin offenbart werden oder nicht, und ohne zu beabsichtigen, öffentlich irgendeinen patentierbaren Gegenstand zu überlassen.
ZITATE ENTHALTEN IN DER BESCHREIBUNG
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
Zitierte Nicht-Patentliteratur

http://people.cs.ubc.ca/~brendan/papers/remus-nsdi08.pdf [0005]

Claims

Verfahren für das Bewahren eines Zustandes und das Verringern von Datenverlust, Folgendes umfassend: auf das Erkennen eines Commits in einem aktiven Gerät hin, das Kopieren des gesamten ankommenden Verkehrs zu einem oder mehreren Puffern bis zu einem nächsten Commit oder einem Ausfall, das Erkennen eines Ausfalls und das Wiedergeben des kopierten Datenverkehrs, um ein Bereitschaftsgerät zu einem aktuellen Stand eines ausgefallenen Gerätes wiederherzustellen.
Verfahren nach Anspruch 1, das ferner das Beginnen der Verarbeitung an dem Bereitschaftsgerät von einem Ausfallumschaltungspunkt aus umfasst.
Verfahren nach Anspruch 1, das ferner das Löschen des gesamten kopierten ankommenden Verkehrs bei dem nächsten Commit umfasst.
Verfahren nach Anspruch 1, das ferner einen Rücktausch von dem Bereitschaftsgerät zu dem aktiven Gerät umfasst.
Verfahren nach Anspruch 1, wobei das aktive Gerät eines oder mehrere von einer/einem oder mehreren virtuellen Maschinen, Servern und Rechnern ist.
Verfahren nach Anspruch 1, wobei das Bereitschaftsgerät eines oder mehrere von einer/einem oder mehreren virtuellen Maschinen, Servern und Rechnern ist.
Verfahren nach Anspruch 1, wobei ein Netz-Replikationsgerät das Kopieren durchführt.
Verfahren nach Anspruch 7, wobei das Netz-Replikationsgerät stromaufwärts von dem Bereitschaftsgerät angeordnet ist.
Ein oder mehrere Mittel für das Durchführen der Schritte nach Anspruch 1.
Rechnerlesbares Speichermedium, das in demselben Anweisungen gespeichert hat, die, wenn sie ausgeführt werden, bewirken, dass die Schritte nach Anspruch 1 durchgeführt werden.
System, das einen Zustand bewahrt und Datenverlust verringert, Folgendes umfassend: ein Netz-Replikationsmodul, das, auf das Erkennen eines Commits durch ein Commit-Modul in einem aktiven Gerät hin, den gesamten ankommenden Verkehr bis zu einem nächsten Commit oder einem Ausfall zu einem oder mehreren Puffern speichert, ein Gerätezustandsmodul, das einen Ausfall erkennt, und ein zweites Gerätezustandsmodul, das den kopierten Datenverkehr wiedergibt, um ein Bereitschaftsgerät zu einem aktuellen Stand eines ausgefallenen Gerätes wiederherzustellen.
System nach Anspruch 11, wobei die Verarbeitung an dem Bereitschaftsgerät von einem Ausfallumschaltungspunkt aus beginnt.
System nach Anspruch 11, wobei der gesamte kopierte ankommende Verkehr bei dem nächsten Commit gelöscht wird.
System nach Anspruch 11, wobei das Bereitschaftsgerät auf eine Korrektur des Ausfalls hin zu dem aktiven Gerät zurückgetauscht wird.
System nach Anspruch 11, wobei das aktive Gerät eines oder mehrere von einer/einem oder mehreren virtuellen Maschinen, Servern und Rechnern ist.
System nach Anspruch 11, wobei das Bereitschaftsgerät eines oder mehrere von einer/einem oder mehreren virtuellen Maschinen, Servern und Rechnern ist.
System nach Anspruch 11, wobei das Netz-Replikationsgerät das Kopieren zu dem einen oder den mehreren Puffern durchführt, wobei der eine oder die mehreren Puffer mit einem oder mehreren von dem aktiven Gerät, dem Bereitschaftsgerät nebeneinander stehen oder auf einem Netzknoten angeordnet sind.
System nach Anspruch 17, wobei das Netz-Replikationsgerät stromaufwärts von dem aktiven Gerät angeordnet ist.
System nach Anspruch 17, wobei das Netz-Replikationsgerät stromaufwärts von dem Bereitschaftsgerät angeordnet ist.
System nach Anspruch 11, wobei der gesamte ankommende Verkehr, der darauf gerichtet ist, an eine primäre Software-Anwendung übermittelt zu werden, die in einer primären virtuellen Maschine auf dem aktiven Gerät läuft, fortlaufend überwacht und durch das Netz-Replikationsmodul kopiert wird, für eine gleichzeitige Übermittlung an ein Sicherungsabbild der Software-Anwendung, das auf einem System oder einer virtuellen Maschine in Bereitschaft läuft.