-
Hintergrund der Erfindung
-
Die
Erfindung bezieht sich auf störungsfeste
und störungstolerante
Rechenverfahren und -apparaturen.
-
Störungsfeste
Computersysteme sind in der Lage, ihren Betrieb auch im Falle von
Hardwareausfällen aufrecht
zu erhalten. Derartige Systeme arbeiten entweder in einem Verfügbarkeitsmodus
oder einem Integritätsmodus,
jedoch nicht in beiden. Ein System ist "verfügbar", wenn ein Hardwareausfall
keine unakzeptablen Verzögerungen
in Hinblick auf den Nutzerzugang verursacht und das im "Verfügbarkeitsmodus" arbeitende System
derartig konfiguriert ist, dass es – wenn möglich – "online" bleibt, sollte es mit einem Hardware
Fehler konfrontiert werden. Ein System besitzt Datenintegrität, wenn
ein Hardwareausfall keine Datenverluste oder Datenbeschädigungen
verursacht und das im "Integritätsmodus" arbeitende System
derartig konfiguriert ist, dass Datenverluste oder -beschädigungen
vermieden werden, selbst wenn das System dazu "offline" gehen muss.
-
Störungstolerante
Systeme beanspruchen sowohl Verfügbarkeit
als auch Integrität.
Ein störungstolerantes
System bleibt verfügbar
und behält
seine Datenintegrität,
wenn es mit einem einzelnen Hardwareausfall und in einigen Fällen mit
mehreren Hardwareausfällen
konfrontiert wird.
-
Katastrophentolerante
Systeme gehen noch einen Schritt weiter als störungstolerante Systeme und setzen
voraus, dass ein Verlust einer Computer-Installation bei Naturkatastrophen
oder bei durch menschliches Versagen verursachten Katastrophen nicht
die Systemverfügbarkeit
insgesamt unterbricht oder es zu Datenverlusten oder- beschädigungen
kommt.
-
Die
bisherigen Fehler-Toleranz-Verfahren enthalten einen Software-Checkpoint/Restart,
Dreifach Modular Redundanz und "Pair
and Spare"-Systeme.
-
Checkpoint/Restart-Systeme
verwenden zwei oder mehrere Rechenelemente, welche asynchron arbeiten
und verschiedene Anwendungen ausführen können. Jede Anwendung speichert
periodisch ein Bild des Zustandes des Rechenelements, auf welchem
sie läuft
(ein sog. Checkpoint). Wenn ein Fehler in einem Rechenelement entdeckt
wird, wird der "Checkpoint" dazu verwendet,
die Anwendung auf einem anderen Rechenelement neu zu starten (oder
auf demselben Rechenelement, sobald der Fehler behoben ist). Um
ein Checkpoint-Restart-System implementieren zu können, muss
jede Anwendung und/oder das Betriebssystem dahingehend modifiziert
werden, dass regelmäßige Zwischenspeicherungen
des Systemzustandes erfolgen. Zusätzlich muss das System "datensicherungs"-fähig sein.
(D. h. es muss in der Lage sein, die Wirkungen jeglicher Rechen-Operationen,
die aus dem neu zu startenden "Checkpoint" folgen, rückgängig zu
machen.) Bei Dreifach-Modular-Redundanz Systemen läuft dieselbe
Anwendung auf drei Rechenelementen, die in einem "Zyklus für Zyklus" Blockierschritt
betrieben werden. Sämtliche
Rechenelemente sind mit dem Baustein einer Abstimm-Schaltung verbunden,
welche die Ausgangswerte (d. h. die Memory Interfaces) der drei
Rechenelemente vergleicht und, wenn alle Ausgangswerte übereinstimmen,
mit der normalen Operation fortfährt.
Wenn einer der Ausgangswerte abweicht, fährt die Abstimm-Schaltung das
Rechenelement herunter, welches den abweichenden Ausgangswert produziert
hat. Die Abstimm-Schaltung, die zwischen den Rechenelementen und
dem Speicher positioniert ist, hat entscheidenden Einfluss auf die
Systemgeschwindigkeit.
-
"Pair and Spare" – Systeme enthalten zwei oder
mehrere Paare von Rechenelementen, auf denen dieselbe Anwendung
läuft und
die in einem "Zyklus
für Zyklus" Blockierschritt
gesteuert werden. Ein Controller überwa ht die Ausgangswerte
(d. h. die Memory Interfaces) von jedem der paarweise angeordneten
Rechenelemente. Wenn der Ausgangswert abweicht, werden beide paarweisen
Rechenelemente heruntergefahren.
-
-
Die
vorliegende Erfindung sorgt für
ein Computersystem, umfassend einen Controller, ein mit dem Controller
verbundenes erstes Rechenelement, ein mit dem Controller verbundenes
zweites Rechenelement, Mittel zum Unterbinden von I/O-Operationen
durch das erste und das zweite Rechenelement und Mittel zum Übertragen
der unterbundenen I/O Operationen an den Controller, wobei der Controller
Mittel zum Durchführen
der I/O Operationen umfasst, um – sofern vorhanden – die Ergebnisse
der I/O Operationen zumindest einem der Rechenelemente zur Verfügung zu
stellen, und zum Synchronisieren der Rechenelemente miteinander
nach jeder I/O Operation, wobei das erste Rechenelement jeden Befehl
seines Befehlssatzes in der gleichen Anzahl von Zyklen ausführt, wie
sie das zweiten Rechenelement für
die Ausführung
dieses Befehls benötigt.
-
Zusammenfassung der Erfindung
-
Gemäß der Erfindung
wird ein störungsfestes
oder störungstolerantes
System durch die Nutzung von mindestens zwei Rechenelementen ("CEs") geschaffen, die
asynchron in Echtzeit (d. h. von Zyklus zu Zyklus) und synchron
in den sog. Zwischen-Zeiten operieren. Die CEs werden in den Zwischen-Zeiten
synchronisiert, welche oft genug auftreten, so dass die Anwendungen,
die auf den entsprechenden CEs laufen, nicht divergieren, aber es
gestattet ist, dass diese asynchron zwischen den Zwischen-Zeiten
laufen. Beispielsweise könnten
die CEs einmal pro Sekunde synchronisiert werden und ansonsten asynchron
laufen. Da die CEs zu jeder Zwischen-Zeit resynchronisiert werden,
sagt man, die CEs operieren im sog. Zwischen-Zeit Blockierschritt.
-
In
besonderen Anwendungsformen, sind die Zwischen-Zeiten als die Zeiten
definiert, in denen die CEs I/O Operationen anfordern. In diesen
Anwendungsformen werden die CEs nach jeder I/O Operation synchronisiert
und laufen zwischen den I/O Operationen asynchron. Dieses Verfahren
ist anwendbar bei Systemen, in welchen mindestens zwei asynchrone
Rechenelemente, auf denen dieselbe Anwendung läuft, ständig I/O Anfragen in derselben
Reihenfolge generieren. Dieses Verfahren kann ferner auf Resynchronisationen
im Anschluss an lediglich solche I/O Anfragen, die die Rechenumgebung
modifizieren (d. h. die "Schreibanfragen"), beschränkt sein.
-
Die
Zwischenzeit-Synchronisation entsprechend der Erfindung wird erreicht
durch die Nutzung einer gepaarten Modular-Redundanz Architektur,
welche für
Anwendungen und die Software des Betriebssystems transparent ist.
Im Rahmen dieser Architektur ist jedes Rechenelement gepaart mit
einem Controller, auch bekannt als ein I/O Prozessor ("IOP"). Die IOPs führen jede
I/O Anfrage aus, die von einem Rechenelement gestellt oder zu einem
solchen weitergeleitet wird, spüren
Hardwarefehler auf und synchronisieren die Rechenelemente miteinander
im Anschluss an jede I/O Operation. In Systemen, in welchen I/O
Anfragen nicht mit zufriedenstelleneder Häufigkeit ergehen, synchronisieren
die IOPs die CEs periodisch in Überein stimmung
mit sogenannten Quantenunterbrechungen, erzeugt von Inter-Processor-Zwischenverbindungsmodulen
(IPI), die mit den CEs verbunden sind.
-
In
einer anderen besonderen Ausführungsform
der Erfindung werden die CEs anders als beim Synchronisieren basierend
auf jeder einzelnen I/O Operation auf der Grundlage eines Fensters
von I/O Operation synchronisiert. In diesem Verfahren wird eine
Liste von I/O Operationen für
jedes CE beibehalten und die CEs werden synchronisiert, wann immer
ein gemeinsamer Eintrag in allen Listen erscheint. Dieses Verfahren
gestattet eine Flexibilität
in Hinblick auf die Reihenfolge, in welcher die I/O Anfragen generiert
werden.
-
In
einer noch weiteren exemplarischen Ausführungsform der Erfindung werden
die CEs entweder basierend auf vom Betriebssystem periodisch generierten
Signalen oder basierend auf hardwaregenerierten Unterbrechungen
synchronisiert. So ist beispielsweise beim hardeware-generierten
Unterbrechungsverfahren ein Prozessor von jedem Rechenelement für die Erzeugung
einer Unterbrechung aller N Zyklen modifiziert, während die
CEs in Abhängigkeit
zu diesen Unterbrechungen synchronisiert werden.
-
Die
primären
Komponenten eines gepaarten Modular-Redundanz Systems enthalten
Software, "off-the-shelf" IOPs, "off-the-shelf" CEs und Paare speziell
zugeschnittener IPI Module, welche in den Expansions-Slots des IOP's und des CEs stecken
und über
ein Kabel miteinander zusammengeschaltet sind. Redundante I/O-Geräte können mit
einem oder mehreren der Rechenelemente oder IOPs verbunden werden,
um redundante I/O bereitzustellen und um bestimmte Merkmale anzubieten,
wie beispielsweise volume shadowing von Code-Massenspeicher-Einrichtungen. Ein
gepaartes Modular-Redundanz System kann jedes I/O-Gerät versorgen,
das kompatibel mit einem Prozessor ist, der als ausführender
IOP des Systems genutzt wird.
-
Die
gepaarte Modular-Redundanz Anordnung benötigt ein Minimum an Nutzersoftware
und Hardware um mindestens zwei kombinierte "off-the-shelf" Rechenelemente in Gang zu setzen für die Einbindung
in störungsfeste
oder -tolerante Systeme, die mit dem Industriestandard entsprechender
Betriebssoftware laufen, wie z. B. Windows NT, DOS, OS/2 oder UNIX
und unmodifizierten Anwendungen. Damit kann die Architektur sowohl
die hohen Kosten als auch die geringe Flexiblität der gewerblich geschützten Betriebssysteme,
Anwendungen und Prozessorgestaltungen in der Art und Weise ihrer
bisherigen Nutzung vermeiden.
-
Ein
weiterer Vorteil der gepaarten Modular-Redundanzarchitektur dieser
Erfindung ist, dass sie einen gewissen Grad an Software-Störungstoleranz
bietet. Die Mehrheit der Softwarefehler ist nicht algorithmischer Art.
Stattdessen werden die meisten Fehler durch die Asynchronität zwischen
dem Rechenelement und den I/O Geräten verursacht, was in Laufzeitbedingungen
mündet.
Durch eine Entkopplung der I/O-Anfragen von den Rechenelementen
reduziert die gepaarte Modular-Redundanzarchitektur in entscheidender
Weise die Anzahl sog. "Heisenbugscher" Software-Fehler,
die aus jener Asynchronität
resultieren.
-
Gemäß einem
Aspekt betrifft die Erfindung die Ausbildung eines störungstoleranten
oder störungsfesten
Computers durch Verwendung von wenigstens einem Controller, um zumindest
zwei Rechenelemente zu synchronisieren, die jeweils Taktgeber aufweisen
können,
die asynchron zu den Taktgebern der anderen Rechenelemente arbeiten.
Eines oder mehrere Signale, die als Zwischenzeit-Signale bezeichnet
werden, werden aus einer Gruppe von Signalen ausgewählt, die
von den Rechenelementen erzeugt werden. Danach werden die Rechenelemente überwacht,
um die Erzeugung von ausgewählten
Signalen durch eines der Rechenelemente zu detektieren. Sobald ein
ausgewähltes
Signal detektiert wurde, wartet das System auf die Erzeugung von
ausgewählten
Signalen durch die anderen Rechenelemente und überträgt nach dem Empfang der gewählten Signale
Echtzeit-Updates an jedes der Rechenelemente.
-
Bevorzugte
Ausführungsformen
der Erfindung umfassen die nachstehend aufgelisteten Merkmale. Zunächst sind
I/O-Anfragen die ausgewählten
Signale. Die I/O-Anfragen werden verarbeitet, um I/O-Antworten zu erzeugen,
die mit den Zeit-Updates übertragen
werden. Zusätzlich
zu den oder anstelle der I/O-Anfragen können Quantenunterbrechungen
die ausgewählten
Signale sein. Die Rechenelemente zählen entweder die ausgeführten Anweisungen
oder die Zyklen des Taktgebers, wie beispielsweise der Systemuhr
oder der BUS-Uhr
oder der I/O-Uhr und erzeugen Quantenunterbrechungen wann immer
eine vordefinierte Anzahl an Anweisungen oder Zyklen erfolgt. Wenn
sowohl die I/O-Anfragen als auch die Quantenunterbrechungen als die
ausgewählten
Signale benutzt werden, zählen
die Rechenelemente die Anzahl der Anweisungen oder Zyklen, die ohne
eine I/O-Anfrage erfolgen. Beispielsweise könnte ein Rechenelement derartig programmiert sein,
dass es Quantenunterbrechungen erzeugt, wann immer es 100 Zyklen
lang arbeitet, ohne eine I/O-Anfrage zu erzeugen.
-
In
einer Ausführungsform,
werden die Anweisungen gezählt,
indem ein Zähler
mit einem vorbestimmten Wert geladen wird, wobei der Zähler mit
der I/O Anfrage gestartet wird, der Wert des Zählers heruntergezählt wird
und eine Quantenunterbrechung signalisiert wird, wenn der Wert des
Zählers
Null erreicht. Bei einem anderen Verfahren werden Fehlersuch-Features
des Prozessors genutzt, um die Qunatenunterbrechungen zu erzeugen.
-
Zur
Fehlererkennung werden die ausgewählten Signale und die Begleitdaten – falls
vorhanden – aus jedem
der Rechenelemente verglichen. Wenn diese nicht übereinstimmen, wird ein Signal
erzeugt, welches das Auftreten eines Fehlers anzeigt.
-
In
einigen Ausführungsformen
warten die Rechenelemente auf Zeit-Updates, indem sie mit ihren
Operationen pausieren, nachdem die ausgewählten Signale produziert wurden.
Die Rechenelemente nehmen ihre Operationen nach dem Empfang des
Zeit-Updates wieder auf. In anderen Ausführungsformen setzen die Rechenelemente
nach der Erzeugung der ausgewählten
Signale den Betrieb fort.
-
Um
Probleme zu vermeiden, die aus den asynchronen Aktivitäten der
Rechenelemente folgen könnten,
werden diese asynchronen Aktivitäten
eingestellt. Die Funktionen der asynchronen Aktivitäten werden dann
ausgeführt,
wenn ein ausgewähltes
Signal erzeugt wird. So werden beispielsweise normale "Speicher-Refresh" Funktionen deaktiviert
und an ihrer Stelle jedesmal "Burst-Memory-Refreshes" ausgeführt, sobald
ein ausgewähltes
Signal – wie
z. B. eine I/O-Anfrage, oder eine Quantenunterbrechung erzeugt wird.
-
Die
Erfindung betrifft auch ein Verfahren zur Schaffung eines störungsfesten
oder störungstoleranten Computers,
indem ein erster Prozessor als Rechenelement, ein zweiter Prozessor
als Controller bestimmt und die Rechenelemente und der Controller
zur Bildung eines Modulpaares verbunden werden. Danach werden zumindest
zwei Modulpaare verbunden, um einen störungssicheren oder störungstoleranten
Computer zu bilden. Die für
die Rechenelemente verwendeten Prozessoren müssen nicht identisch sein,
sondern sie alle führen
vorzugsweise jeden Befehl ihrer Befehlsgruppe in einer Anzahl von
Zyklen aus, die die gleich ist wie die Anzahl von Zyklen, die die
anderen Prozessoren benötigen.
Normalerweise werden bei der Implementierung der Rechenelemente
und der Controller Prozessoren nach Industrienorm verwendet. Für die Desastertoleranz kann
zumindest eines der Modulpaare entfernt von den anderen Modulpaaren
angeordnet sein. Die Controller und die Rechenelemente können derart
ausgelegt sein, dass nichtmodifizierte Standardbetriebssysteme und -anwendungen
auf ihnen laufen. Darüber
hinaus können
die Controller derart ausgelegt sein, dass auf ihnen ein erstes
Betriebssystem läuft,
während
auf den Rechenelementen ein zweites Betriebssystem läuft.
-
Die
I/O-Störungsfestigkeit
wird erreicht, indem redundante I/O-Geräte
mit wenigstens zwei Modulpaaren verbunden werden und zumindest identische
I/O-Schreibanforderungen und Daten zu den redundanten I/O-Geräten übertragen
werden. Während
I/O-Schreibanforderungen nur zu einem der I/O-Geräte übertragen werden
müssen,
können
identische I/O-Leseanforderungen
zu mehr als einem der I/O-Geräte übertragen
werden, um die Datenintegrität
zu verifizieren. Wenn redundante I/O-Geräte mit drei oder mehr Modulpaaren
verbunden werden, erlaubt die Übertragung
von identischen I/O-Anforderungen die Identifizierung eines fehlerhaften
I/O-Geräts.
-
Gemäß einem
weiteren Aspekt betrifft die Erfindung allgemein die Isolierung
von I/O-Anforderungen von Rechenoperationen in einem Computer durch
die Verwendung von I/O-Weiterleitung. Normalerweise erfolgt der
Zugriff auf I/O-Geräte
entweder durch I/O-Anforderungen einer unteren Ebene oder durch
eine direkte Adressierung der I/O-Geräte.
I/O-Anforderungen einer unteren Ebene umfassen Anforderungen an
das Basis-Eingabe/Ausgabesystem des Systems (z. b. BIOS), Anforderungen
zum Booten von Hardware, Anforderungen zum Booten von Software und
Anforderungen an die Treibersoftware der physischen Vorrichtung
des Systems. Wenn ein Rechenelement eine niedere I/O-Anforderung erteilt,
sieht die Erfindung den Einsatz von Software vor, um die I/O-Anforderungen
an den I/O-Prozessor weiterzuleiten. Wenn das Rechenelement die physischen
I/O-Geräte
direkt adressiert, sieht die Erfindung vor, virtuelle I/O-Geräte vorzusehen,
die die Schnittstellen der physischen I/O-Geräte simulieren. Direkt adressierte
I/O-Anforderungen werden abgefangen und den virtuellen I/O-Geräten bereitgestellt.
Die Inhalte der virtuellen I/O-Geräte werden als I/O-Anforderungen
periodisch zu dem(den) I/O-Prozessoren) übertragen. An dem(den) I/O-Prozessoren)
werden die übertragenen
Inhalte der virtuellen I/O-Geräte
für die
physischen I/O-Geräte
bereitgestellt. Nachdem die angeforderten I/O-Operationen durchgeführt wurden,
werden die Ergebnisse der Operationen, sofern vorhanden, als Antwort
auf die I/O-Anforderung an die Rechenelemente zurückgereicht.
Normalerweise umfassen die virtuellen I/O-Geräte eine virtuelle Tastatur
und ein virtuelles Display.
-
Die
Erfindung betrifft auch die Erfassung und Diagnose von Fehlern in
einem Computersystem, das zumindest zwei Controller umfasst, die
miteinander und mit wenigstens zwei Rechenelementen verbunden sind,
und zumindest zwei Rechenelemente, die mit wenigstens zwei der Controller
verbunden sind. Jedes Rechenelement produziert Daten und generiert
einen Wert wie beispielsweise einen Fehlerprüfcode, der sich auf die Daten
bezieht. Jedes Rechenelement überträgt die Daten
dann zusammen mit ihrem entsprechenden Wert zu den wenigstens zwei
Controllern, mit denen es verbunden ist. Wenn die Controller die
Daten und die zugehörigen
Werte empfangen, übertragen
sie die Werte zu den anderen Controllern. Jeder Controller führt dann Berechnungen
an den Werten durch, die jedem Rechenelement entsprechen, und an
den Werten, die jedem Controller entsprechen. Wenn die Ergebnisse
der Berechnungen an den jedem Controller entsprechenden Werten gleich
sind und wenn die Berechnungen an jedem den jedem der Rechenelemente
entsprechenden Werten gleich sind, liegt keine Störung vor.
Andernfalls liegt eine Störung
vor. In manchen Fällen
kann es sich bei der Berechnung um einen simplen Vergleich Bit für Bit handeln.
-
Wenn
eine Störung
bzw. ein Fehler vorliegt, wird die Störungs- bzw. Fehleranalyse versucht, indem
für jeweils
ein Rechenelement sämtliche
der diesem einen Rechenelement entsprechenden Werte verglichen werden.
Wenn die jedem Rechenelement entsprechenden Werte bei jedem Rechenelement übereinstimmen, jedoch
für verschiedene
Rechenelemente nicht übereinstimmen,
so ist eines der Rechenelemente störungsbehaftet. Wenn die nur
einem der Rechenelemente entsprechenden Werte nicht übereinstimmen,
dann ist ein Pfad zu diesem Rechenelement störungsbehaftet. Wenn die mehreren
Rechenelementen entsprechenden Werte nicht übereinstimmen, dann unterliegt
der Controller, der mit dem nicht übereinstimmenden Rechenelement
verbunden ist, einer Störung.
Sobald das fehlerbehaftete bzw. gestörte Rechenelement identifiziert
ist, wird es gesperrt.
-
Ein
erfindungsgemäßes System
kann sich auf seine volle Leistungsfähigkeit selbst wiederherstellen, nachdem
ein fehlerhaftes Element (d. h. ein CE, ein IOP, eine Speichereinrichtung
etc.) repariert wurde. Das System macht das, indem es den Zustand
eines aktiven Elements auf ein repariertes Element überträgt und dann
das reparierte Element wieder aktiviert. Inaktive oder reparierte
Prozessoren werden durch den Transfer des Betriebszustands eines
aktiven Prozessors oder aktiver Prozessoren durch den Controller
auf den inaktiven Prozessor aktiviert. Wenn der inaktive Prozessor
ein Rechenelement ist, erfolgt die Übertragung des Betriebszustands
eines aktiven Rechenelements (oder aktiver Rechenelemente) durch
einen Controller. Wenn der inaktive Prozessor ein Controller ist,
wird de Betriebszustand eines aktiven Controllers direkt übertragen. Die Übertragung
kann entweder stattfinden, während
das System vorübergehend
unterbrochen ist, oder als ein Prozess, der im Hintergrund abläuft.
-
Diese
Wiederherstellbarkeit kann auch für online Upgrades von Hardware,
Software oder beidem genutzt werden, indem beispielsweise durch
Abschalten ein Ausfall eines Prozessors des Systems verursacht wird.
Das Upgrade wird dann durchgeführt,
indem der deaktivierte Prozessor entweder ersetzt oder modifiziert wird.
Der aufgerüstete
Prozessor wird dann wie vorstehend erläutert angeschaltet oder reaktiviert.
-
Die
Erfindung betrifft auch ein System mit nur einem Controller und
zwei Rechenelementen, bei dem ein Controller mit zwei Rechenelementen
verbunden ist. Bei diesem Computersystem werden I/O-Operationen von den
Rechenelementen abgefangen und an den Controller weitergeleitet.
Normalerweise enthalten der Controller und die beiden Rechenelemente
jeweils ein Standard-Motherboard und sie sind dafür ausgelegt, dass
nichtmodifizierte Standard-Betriebssysteme und Standard-Anwendungen
auf ihnen laufen können.
Darüber
hinaus ist der Controller dafür
geeignet, dass ein erstes Betriebssystem auf ihm laufen kann, während auf den
Rechensystemen gleichzeitig ein zweites Betriebssystem läuft.
-
Das
einzige Controllersystem kann erweitert werden und einen zweite
Controller umfassen, der sowohl mit dem ersten Controller als auch
mit den beiden Rechenelementen verbunden ist. Zum Zwecke der Schaffung
einer begrenzten Desasterfestigkeit können der erste Controller und
eines der Rechenelemente abseits von dem zweiten Controller und
dem anderen Rechenelement angeordnet und durch einen Kommunikationslink
mit dem zweiten Controller und dem anderen Rechenelement verbunden
sein.
-
Für eine verbesserte
Verfügbarkeit
und Leistung können
der duale Controller und das duale Rechenelementsystem mit einem
identischen zweiten System verbunden werden. Durch die beiden Systeme
läuft dann
ein verteilte Rechenumgebung, wobei auf einem der Systeme ein erster
Teil einer ersten Anwendung und auf dem anderen System entweder
eine zweite Anwendung oder ein zweiter Teil der ersten Anwendung
läuft.
-
In
einer weiteren Ausführungsform
betrifft die Erfindung ein Computersystem, das drei Controller umfasst,
die miteinander verbunden sind, und drei Rechenelemente, die jeweils
mit unterschiedlichen Paaren der drei Controller verbunden sind.
Wie die anderen Systeme, betrifft auch dieses System das Abfangen
von I/O-Operationen
durch die Rechenelemente und deren Weiterleitung an die Controller
zwecks Verarbeitung. Für
die Desastertoleranz sind der erste Controller und eines der Rechenelemente
an einer von den restlichen Controllern und Rechenelementen entfernten
Stelle angeordnet oder es ist jedes Paar aus Controller/Rechenelement
an einer anderen Stelle angeordnet.
-
Ein
desastertolerantes System wird geschaffen durch die Verbindung von
wenigstens zwei der vorstehend beschriebenen Controllersysteme.
Die drei Controllersysteme sind an voneinander entfernten Orten
angeordnet und durch einen Kommunikationslink miteinander verbunden.
-
Kurzbeschreibung der Zeichnungen
-
1 ist
ein Blockdiagramm eines teilweise störungsfesten Systems.
-
2 ist
ein Blockdiagramm der Systemsoftware des Systems aus 1.
-
3 ist einen Ablaufplan des von einem IOP-Monitor
der Systemsoftware genutzen Verfahrens nach 2.
-
4 ist
ein Blockdiagramm eines IPI-Moduls des Systems aus 1.
-
5 ist
eine Zustandsübergangstabelle
des Systems aus 1.
-
6 ist
ein Blockdiagramm eines fehlertoleranten Systems.
-
7 zeigt
ein Blockdiagramm eines gegliederten störungsfesten Systems.
-
8 ist
ein Blockdiagramm eines störungstoleranten
Systems.
-
9 ist
ein Ablaufplan eines Fehlerdiagnoseverfahrens, das durch die IOPs
des Systems nach 8 genutzt wird.
-
10 ist
ein Blockdiagramm eines katastrophentoleranten Systems.
-
Beschreibung der bevorzugten
Ausführungsformen
-
Wie
in 1. dargestellt, enthält ein störungsfestes System 10 einen
I/O-Prozessor ("IOP") 12 und zwei
Rechenelemente ("CEs") 14a, 14b (gemeinsam
bezeichnet als CEs 14). Da das System 10 nur einen
einzelnen IOP 12 enthält,
kann es sich nach einem Fehler im IOP 12 nicht wiederherstellen
und ist deshalb nicht vollständig
störungsfest.
-
IOP 12 enthält zwei
Inter-Prozessor-Zwischenverbindungsmodule (IPI) 16a, 16b,
die entsprechend mit korrespondierenden IPI Modulen 18a, 18b der
CEs 14 über
Kabel 20a, 20b verbunden sind. Das IOP 12 enthält außerdem einen
Prozessor 22, ein Speichersystem 24, zwei Festplattenlaufwerke 26, 28 und
ein Netzanschlussgerät 30.
Auf ähnliche
Weise enthält
jedes CE 14 einen Prozessor 32, ein Speichersystem 34 und
eine Stromversorgung 36. Separate Stromversorgungen 36 werden
benutzt, um die Störungsfestigkeit
im Falle eines Stromversorgungsausfalles sicherzustellen. Die Prozessoren 32a, 32b sind
insoweit "identisch", als dass für jede Instruktion,
die für
eine Ausführung
durch den Prozessor 32a benötigte Anzahl der Zyklen mit
der Anzahl der für
eine Ausführung
derselben Instruktion durch den Prozesser 32b benötigten Zyklen übereinstimmt. In
der dargestellten Ausführungsform
werden in System 10 auf Intel 486 Standard basierende
Motherboards für
die Prozessoren 22, 32 und 4 MB Speicherkapazität für jedes
der Speichersysteme 24,34 verwendet.
-
Auf
IOP 12 und CEs 14 läuft unmodifizierte System-
und Anwendungssoftware, wobei die Festplatte 26 als Bootdisk
für den
IOP und die Festplatte 28 als Bootdisk für die CEs 14 verwendet
wird. In wirklich störungsfesten
oder -toleranten Systemen, die mindestens 2 IOPs enthalten, würde auch
jede Festplatte doppelt vorhanden sein.
-
Bei
der dargestellten Ausführungsform
wird als Betriebssystem für
den IOP 12 und die CEs 14 DOS verwendet. Jedoch
können
auch andere Betriebssysteme zum Einsatz kommen. Außerdem kann
auf dem IOP 12 ein anderes Betriebssystem laufen, als auf
den CEs 14. So kann beispielsweise auf IOP 12 Unix
laufen, während
auf den CEs 14 DOS läuft.
Dieses Verfahren ist vorteilhaft, weil es den CEs gestattet, von
Betriebssystemen auf die Peripherie-(Geräte) zuzugreifen, welches diese
Peripherien-(Geräte)
nicht unterstützt.
Läuft auf
den CEs 14 beispielsweise ein Betriebssystem, welches keine
CD-ROM-Laufwerke unterstützt
und läuft dafür aber auf
dem IOP ein Betriebssystem, das dieses kann, so können die
CEs auf das CD-ROM Laufwerk zugreifen, indem sie I/O Anfragen ausgeben,
die zu denjenigen identisch sind, die z. B. für Festplattenzugriffe genutzt
werden. Der IOP 12 würde
dann die Übersetzung
der I/O Anfrage in eine für
den CD-ROM Zugriff geeignete Anfrage durchführen.
-
In
Bezug auf 2 enthält das System 10 eine
spezialisierte Systemsoftware 40 welche das Booten und
Synchronisieren der CEs 14 kontrolliert, die lokale Zeit
in den CEs ausschaltet, alle I/O-Anfragen
von den CEs 14 zum IOP 12 für die Ausführung umleitet und die Ergebnisse
der I/O Anfragen – sofern
vorhanden – vom
IOP zu den CEs zurückführt.
-
Die
Systemsoftware 40 enthält
zwei Sätze
von auf ROM basierenden IPI BIOS 42, welche jeweils im IPI
Modul 18 eines CE 14 angeordnet sind. Die IPI
BIOS 42 werden bei Aktivitäten in Bezug auf das Hochfahren
und Synchronisieren benutzt. Wenn ein CE 14 hochgefahren
wird, ersetzen die IPI BIOS 42 die I/O Unterbrechungsadressen
in der BIOS Unterbrechungstabelle mit Adressen, die von CE Treibern 44 kontrolliert
werden. Die Unterbrechungsadressen, die ersetzt werden, enthalten
jene, die den Videobetrieb, den Fixed-Disc-Betrieb, den seriellen
Kommunikationsbetrieb, den Keyboardbetrieb und den Tageszeitbetrieb
umfassen.
-
Die
IPI BIOS 42 schalten auch den normalen Memory-Refresh aus, um
sicherzustellen, dass jeglicher Memory-Refresh welcher sich auf
die Anzahl der Zyklen, während
derer ein CE 14 eigentlich arbeitet, auswirkt, durch die
Systemsoftware kontrolliert werden kann. Der Memory-Refresh wird
benötigt,
um die Speicherintegrität
beibehalten zu können.
Bei bekannten Refresh-Verfahren wird der Speicher periodisch erneuert,
wobei je ein Speicherblock am Ende einer Refresh-Periode erneuert ist. Die Dauer der
Refresh-Periode ist so ausgewählt,
dass der ganze Speicher innerhalb des Refresh-Limits des Speichers
erneuert wird. Wenn ein Speicher beispielsweise 256 Blöcke und
ein 8 ms Refresh-Limit hat, dann ist folglich die Refresh-Periode
31.25 μs (8
ms/256).
-
In
der beschriebenen Ausführungsform
schaltet das IPI BIOS 42 den Memory-Refresh dadurch aus, dass
ein vom Intel 486 Motherboard benutzter Zähler gesetzt
wird, um den Memory-Refresh in einem Modus zu steuern, was eine
Steuereingabe zum Zähler
erfordert, um diesen auf Vorwärtszählen zu
schalten. Da der Steuereingang typischerweise mit der Stromversorgung
verbunden ist, verändert
sich dieser Steuereingang niemals, und der Zähler ist wirksam ausgeschaltet.
-
Die
zwei CE-Treiber 44 der Systemsoftware 40 führen den
Memory-Refresh durch
stoßartiges
Erneuern von mehreren Speicherblöcken
bei jeder Generierung einer I/O-Anfrage oder einer Quantenunterbrechung durch.
Die CE-Treiber 44 sind auf der CE Boot-Diskette 28 gespeichert
und werden durch die CEs 14 gestartet. Zusätzlich zur
Durchführung
der stoßartigen
Speichererneuerung fangen die CE-Treiber die I/O-Anfragen an das System BIOS ab und leiten
diese durch die IPI Module 18 zur Ausführung weiter an den IOP 12.
Die CE-Treiber 44 antworten auch auf die Unterbrechungsanfragen
der IPI Module 18, schalten die Systemuhr aus und kontrollieren
-basierend auf Informationen von der IOP Kontrolleinrichtung 48 – die Tageszeit
der CEs 14.
-
Ein
auf der IOP Boot-Disk 26 befindlicher IOP-Treiber 46,
der vom IOP 12 gestartet wird, reagiert auf die I/O-Anfragen
von den CEs 14 indem er diese zur Verarbeitung an einen
IOP-Monitor 48 umleitet damit die Ergebnisse vom IOP-Monitor 48 verarbeitet
und an die CEs 14 übertragen
werden können.
Der IOP Treiber kommuniziert mit dem CE Treiber mittels eines Paket-Protokolls.
-
Der
IOP-Monitor 48 ist auf der Boot-Diskette 26 platziert
und wird vom IOP 12 gestartet. Der IOP-Monitor 48 kontrolliert
das System 10 und führt
die aktuellen I/O Anfragen durch, um die Ergebnisse zu produzieren,
die vom IOP-Treiber 46 zu den CEs 14 übertragen
werden.
-
Die
Systemsoftware 40 umfasst auch die Konsolensoftware 49,
die auf dem IOP 12 läuft
und die Nutzerkontrolle des Systems 10 ermöglicht. Über die
Konsolensoftware 49 kann ein Nutzer Resets, Boots und Synchronisationen
einer CE 14 vornehmen. Der Nutzer kann darüber hinaus
eine oder beide CEs 14 auf ein automatisches Booten (autoboot)
und/oder ein automatisches Synchronisieren (Autosync) schalten,
nachdem ein Reset durchgeführt
wurde, oder nach einem Startup. Die Fähigkeit, jede CE 14 kontrollieren
zu können,
ist sowohl während
des normalen Betriebes, als auch zu Testzwecken nützlich.
Mittels der Konsolensoftware 49 kann der Nutzer das System 10 auch
entweder in einen Integritätsmodus,
in welchem der IOP-Monitor 48 beide CEs 14 herunterfährt, sobald
sie mit einem nicht kompensierbaren Fehler konfrontiert wird, in
einen ersten Verfügbarkeitsmodus,
in welchem der IOP-Monitor 48 die CE 14a ausschaltet,
wenn sie mit einem nicht kompensierbaren Fehler konfrontiert wird,
oder in einen zweiten Verfügbarkeitsmodus,
in welchem der IOP-Monitor 48 die CE 14b ausschaltet,
wenn sie mit einem nicht kompensierbaren Fehler konfrontiert wird,
versetzen. Schließlich
ermöglicht
es die Konsolensoftware 49 dem Nutzer, den Systemstatus
des Systems 10 abzufragen. In einer alternativen Ausführungsform
könnte
die Konsolensoftware 49 auch einen separaten Prozessor nutzen,
der mit dem IOP 12 kommuniziert.
-
Auf
jedem CE 14 läuft
eine Kopie der gleichen Anwendung und des gleichen Betriebssystems,
das auch auf dem anderen CE 14 läuft. Darüber hinaus sind auch die Inhalte
des Speichersystems 34a und 34b die gleichen und
die Operationsumgebung der CEs 14 ist bei jedem Synchronisationstakt
die gleiche. Folglich sollte der IOP-Monitor 48 auch identische
Sequenzen der I/O-Anfragen von den CEs 14 erhalten.
-
3 zeigt die Prozesse des IOP-Monitors 48 und überwacht
die I/O-Anfragen gemäß einer
Prozedur 100. Zu Beginn wartet der I/O Monitor 48 auf
eine I/O Anfrage von einem der CEs 14 (Schritt 102).
Nach dem Empfang eines I/O Anfragepakets von beispielsweise CE 14b,
wartet der IOP-Monitor 48 entweder auf eine I/O Anfrage
von CE 14a, oder auf das Ende der Timeout-Periode (Schritt 104).
Da das System 10 mit dem DOS Betriebssystem arbeitet, welches
die Ausführung
einer Anwendung während
einer I/O-Anfrage anhält,
wird gewährleistet,
dass der IOP-Monitor 48 keine I/O Anfrage von CE 14b empfängt, während sie
auf eine Anfrage von CE 14a wartet (Schritt 104).
-
Als
nächstes
prüft der
IOP-Monitor 48, ob die Timeout-Periode beendet ist (Schritt 106).
Falls nicht, d. h. wenn also ein I/O-Anfragepaket von CE 14a eingetroffen
ist, vergleicht der IOP-Monitor 48 die Prüfsummen der
Pakete (Schritt 108) und bearbeitet die I/O-Anfrage, wenn die
Prüfsummen übereinstimmen
(Schritt 110). Nach der Bearbeitung der I/O-Anfrage gibt
der IOP Monitor eine Anfrage zur System BIOS des IOP 12 in
Bezug auf die aktuelle Tageszeit ab (Schritt 112).
-
Nach
dem Empfang der Tageszeit assembliert die IOP Kontrolleinrichtung 48 ein
IPI Paket, welches die Tageszeit und – falls vorhanden – die Ergebnisse
der I/O Anfragen enthält
(Schritt 114), und sendet dieses IPI Paket an den IOP Treiber 46 (Schritt 116)
zur weiteren Übertragung
an die CEs 14. Wenn die CEs 14 das IPI Paket empfangen,
verwenden sie die übertragene
Tageszeit, um ihre lokale Taktgeber zu aktualisieren, welche ansonsten – wie schon
beschrieben – ausgeschaltet
sind.
-
Wie
von DOS vorausgesetzt, wird die Ausführung in den CEs 14 ausgesetzt,
bis der IOP-Monitor 48 die Ergebnisse der I/O Anfrage durch
den IOP Treiber 46 zurückgibt.
Da, bevor die Ausführung
wieder aufgenommen wird, die Tageszeiten beider CEs 14 auf
einen gemeinsamen Wert (die übertragene
Tageszeit des IPI Pakets) hin aktualisiert werden, können die
CEs in zeitlicher Synchronisation mit der übertragenen und als Zwischen-Zeit
bezeichneten Tageszeit gehalten werden. Wenn ein multitaskmäßig operierendes
System in Betrieb wäre,
würde eine
Ausführung
in den CEs 14 nicht ausgesetzt werden, während die
IOP Kontrolleinrichtung 48 die I/O Anfrage durchführt. Stattdessen
würde die
Arbeit in den CEs 14 nur bis zum Empfang einer Bestätigung ausgesetzt
werden, welcher anzeigt, dass der IOP-Monitor 48 damit
begonnen hat, die I/O Anfrage zu bearbeiten (Schritt 110).
Die Bestätigung
enthielte dann die Tageszeit und würde von den CEs 14 dazu verwendet
werden, um ihren lokalen Taktgeber zu aktualisieren.
-
Nach
dem Senden des IPI Pakets zum IOP Treiber 46 prüft der IOP
Monitor 48, ob beide CEs 14 online sind (Schritt 118)
und wartet, falls dem so ist, auf eine weitere I/O Anfrage von einem
der CEs 14 (Schritt 102).
-
Wenn
die Timeout-Periode beendet ist (Schritt 106), schaltet
die IOP Kontrolleinrichtung 48 das CE 14 ab, welches
nicht geantwortet hat (Schritt 119) und bearbeitet die
I/O Anfrage (Schritt 110).
-
Wenn
es eine Abweichung zwischen der Prüfsumme der Pakete von den CEs 14 gibt
(Schritt 108), prüft
der IOP-Monitor 48, ob sich das System 10 im Verfügbarkeitsmodus
oder im Integritätsmodus
befindet (Schritt 120).
-
Falls
das System 10 im Verfügbarkeitsmodus
operiert, schaltet der IOP-Monitor 48 das passende CE 14 aus,
basierend auf dem gewählten
Verfügbarkeitsmodus
(Schritt 122) und bearbeitet die I/O-Anfrage (Schritt 110).
Danach prüft
der IOP-Monitor 48, ob beide CEs 14 online sind
(Schritt 118) und wartet dann auf eine I/O Anfrage von
dem CE 14, das online ist, vorausgesetzt, das ausgeschaltete
CE 14 wurde nicht repariert oder reaktiviert (Schritt 124).
Da das System 10 nicht länger störungsfest ist, wenn eine I/O
Anfrage empfangen wird, bearbeitet der IOP-Monitor 48 unverzüglich die
I/O Anfrage (Schritt 110).
-
Wenn
das System 10 im Integritätsmodus arbeitet, wenn eine
Abweichung entdeckt wird, wird der IOP-Monitor 48 beide
CEs ausschalten (Schritt 126) und stoppt die Abarbeitung
(Schritt 128).
-
Wie
weiter in 1 und 2 dargestellt,
führt die
System-BIOS, sobald eine Anwendung oder das Betriebssystem von beispielsweise
CE 14a einen Nicht-I/O Aufruf an die System-BIOS tätigt, die
Anfrage aus und führt
die Ergebnisse zurück
zu der Anwendung, ohne dabei die Systemsoftware 40 anzusprechen.
Gleichwohl unterbricht der CE Treiber 44a die I/O Anfrage,
wenn die Anwendung oder das Betriebssystem einen I/O BIOS Aufruf
tätigen.
Nachdem Abfangen der I/O Anfrage paketiert der CE Treiber 44a die
I/O Anfrage in ein IPI Paket und übermittelt das IPI Paket an
den IOP 12.
-
Wenn
das IPI Modul 16a des IOP 12 die Übertragung
eines IPI Pakets von CE 14a registriert, generiert es eine
Unterbrechung am IOP Treiber 16. Der IOP Treiber liest
daraufhin das IPI Paket.
-
Wie
bereits oben erläutert,
antwortet der IOP-Monitor 48 den IPI Paketen von CE 14a entsprechend der
Prozedur 100. Wie auch schon aufgezeigt, überträgt der IOP
Treiber 46 schließlich
ein IPI Paket, welches die Ergebnisse der I/O Anfrage und die Tageszeit
enthält
zu den CEs 14, vorausgesetzt, es treten keine Hardwarefehler
auf.
-
Die
IPI Module 18 der CEs 14 empfangen das IPI Paket
vom IOP 12. Die CE Treiber 44 entpacken das IPI
Paket, aktualisieren die Tageszeit der CEs 14 und geben
die Kontrolle der CEs 14 zurück an die auf den CEs 14 laufende
Anwendung, oder das Betriebssystem.
-
Wenn
keine I/O Anfragen innerhalb eines vorgegeben Zeitintervalls erfolgen,
generiert das IPI Modul 18 eines CE 14 eine sogenannte
Quantenunterbrechung, welche den CE Treiber 44 der CEs 14 an spricht.
In Erwiderung dessen erzeugt der CE Treiber 44 ein Quantenunterbrechungs-IPI-Paket
und überträgt dieses
zum IOP 12. Der IOP-Monitor 48 behandelt das Quantenunterbrechungs-IPI-Paket
als ein IPI Paket ohne eine I/O Anfrage. Folglich registriert der
IOP-Monitor 48 das hereinkommende Quantenunterbrechungspaket
(Schritt 102, 3) und veranlasst
eine Anfrage an die System BIOS des IOP 12 nach der aktuellen
Tageszeit (Schritt 112, 3),
wenn ein passendes Quantenunterbrechungs-IPI-Paket vom anderen CE 14 empfangen
wird (Schritte 104, 106 und 108, 3), veranlasst eine Anfrage an die System
BIOS von IOP 12 nach der geltenden Tageszeit (Schritt 112, 3). Der IOP-Monitor 48 packt
dann die aktuelle Tageszeit in ein Quanten-Antwort-IPI-Paket (Schritt 114, 3), welches der IOP Treiber 46 dann
zu den CEs 14 sendet (Schritt 116, 3). Die CE Treiber 44 reagieren
ihrerseits auf das Quanten-Antwort-IPI-Paket, indem sie die Tageszeit
aktualisieren und die Kontrolle über
die CEs 14 an die auf den CEs 14 laufende Anwendung
oder das Betriebssystem zurückgeben.
-
Falls
der IOP-Monitor 48 kein Quantenunterbrechungs-IPI-Paket
vom anderen CE 14 innerhalb einer vordefinierten Timeout-Periode
empfängt
(Schritt 106, 3), reagiert
der IOP-Monitor 48 indem er das nicht antwortende CE 14 abschaltet.
-
Wie
in 1 gezeigt, stellen die IPI Module 16, 18 und
die Kabel 20 die gesamte Hardware bereit, die erforderlich
ist, um ein störungsfestes
System herzustellen, das von auf Intel 486 Standard basierenden
Motherboards für
die Implementierung der Prozessoren 22, 32 verwendet
wird. Ein IPI Modul 16 und ein IPI Modul 18, welche
unter Verwendung identischer Boards implementiert sind, führen jeweils
gleiche Funktionen aus.
-
Wie
in 4 dargestellt, enthält ein IPI Modul 18 eine
Kontrollschaltung 50, die I/O-Anfragen und -Antworten zwischen
dem System BUS des Prozessors 32 eines CE 14 und
einer parallelen Schnittstelle 52 des IPI Moduls 18 überträgt. Die
parallele Schnittstelle 52 kommuniziert ihrerseits über ein
Kabel 20 mit einer parallelen Schnittstelle auf einem IPI-Modul 16.
Die parallele Schnittstelle 52 umfasst einen 16 Bit Datenausgangs-Anschluss 54,
einen 16 Bit Dateneingangs-Anschluss 56 und einen Steuerungsanschluss 58.
Das Kabel 20 ist dahingehend konfiguriert, dass der Datenausgangs-Anschluss 54 mit
dem Daten-Eingangs-Anschluss des IPI Moduls 16 verbunden
ist, der Dateneingangs-Anschluss 56 mit dem Datenausgangs-An schluss
des IPI Moduls 16 und der Steuerungsanschluss 58 mit
dem. Steuerungsanschluss des IPI Moduls 16 verbunden ist.
Der Steuerungsanschluss 58 führt ein Handshake-Protokoll
zwischen dem IPI Modul 18 und dem IPi Modul 16 aus.
-
Die
Kontrollschaltung 50 ist auch mit einem IPI BIOS ROM 60 verbunden.
Beim Startup überträgt die Kotrollschaltung 50 das
IPI BIOS 42 (2), den Inhalt des IPI BIOS
ROM 60 über
den System BUS des Prozessors 32 zum Prozessor 32.
-
Ein
ebenfalls auf dem IPI Modul 18 befindlicher QI-Zähler 62 generiert
Quantenunterbrechungen, wie oben erläutert. Der QI-Zähler 62 enthält einen
Takteingang 64, der mit der Systemuhr des Prozessors 32 verbunden
ist und einen Steuereingang 66, der mit der Kontrollschaltung 50 verbunden
ist. Der Steuereingang 66 wird zur Aktivierung und Rücksetzung
des Zählerwertes
des QI-Zählers 62 verwendet.
Wenn der QI-Zähler 62 aktiviert
ist, verringert er den Zählerwert
um jeweils eins pro Zyklus der Systemuhr des Prozessors 32.
Sobald der Zählerwert 0 erreicht,
erzeugt der QI-Zähler
eine Quantenunterbrechung, die – wie
bereits erläutert – den CE
Treiber 44 aktiviert (2).
-
Der
CE Treiber 44 deaktiviert den QI-Zähler 62 am Anfang
einer jeden I/O-Übertragung.
Der CE Treiber 44 deaktiviert den QI-Zähler 62 durch eine
I/O-Schreibanforderung an einer ersten Adresse, bekannt als die
QI-Deaktivierungsadresse. Die Kontrollschaltung 50 erkennt
die I/O-Schreibanforderung und deaktiviert den QI-Zähler 62 über den
Steuereingang 66. Da dieser besondere I/O-Schreibvorgang
allein für
Kontrollzwecke gedacht ist, leitet ihn die Kontrollschaltung 50 nicht
zur parallelen Schnittstelle 52. Am Schluss jeder I/O Übertragung
setzt der CE Treiber 44 den QI-Zähler 62 zurück und aktiviert
diesen mittels einer I/O-Schreibanforderung an einer zweiten Adresse,
bekannt als QI-Aktivierungsadresse. Die Kontrollschaltung 50 reagiert durch
Zurücksetzen
und Aktivieren des QI-Zählers 62.
-
In
einer alternativen Anwendung werden Quantenunterbrechungen durch
die Nutzung der Fehlersuchfunktion oder anderer Features, die im
Prozessor 32 verfügbar
sind, erzeugt. Einige für
gewöhnlich
erhältliche Prozessoren
enthalten Fehlersuch- oder Fangstellen-Anweisungen, die Fehler durch die Übertragung
der Steuerung des Prozessors auf ein festgelegtes Programm nach
dem Ablauf einer ausgewählten
Anzahl von auf die Fangstellen-Anweisung folgenden weiteren Anweisungen
abfangen. Bei diesem Verfahren veranlasst der CE Treiber 44 jedesmal,
wenn er die Kontrolle des Prozessors an die Anwendung oder das Betriebssystem zurückgibt,
eine Fangstellen-Anweisung, um anzuzeigen, dass die Kontrolle des
Prozessors 32 zum CE Treiber 44 nach dem Ablauf
von beispielsweise 300 Anweisungen gegeben werden soll.
Nachdem der Prozessor 32 die aufgezeigten 300 Anweisungen
abgeschlossen hat, führt
die Fangstellen-Anweisung zur Rückgabe
der Kontrolle des Prozessors 32 an den CE Treiber 44.
Für den
Fall, dass eine I/O-Anfrage den CE Treiber 44 vor dem Abschluss
der aufgezeigten Anzahl an Anweisungen aktiviert, veranlasst der
CE Treiber 44 eine Anweisung, die die Fangstellen-Anweisung
aufhebt.
-
Das
IPI-Modul 18 wird auch dazu verwendet, um ein offline-CE 14 zu
aktivieren. Wie noch aufzuzeigen sein wird, wird der Inhalt des
Speichersystems 34 des aktiven CE 14 in das Speichersystem
des 34 des offline-CE 14 kopiert, bevor das offline-CE 14 aktiviert
wird. Um die Auswirkungen dieses Kopiervorgangs am aktiven CE 14 zu
minimieren, ist es dem Prozessor 32 des aktiven CE 14 gestattet
weiterzuarbeiten und der Speicher wird nur in solchen Zyklen kopiert,
in denen der System BUS des Prozessors 32 des aktiven CE 14 nicht benutzt
wird.
-
Um
den Prozessor 32 in die Lage zu versetzen, weiterzuarbeiten,
während
der Speicher kopiert wird, legt das IPI Modul 18 die Speicherschreibvorgänge durch
den Prozessor 32 in Adressen ab, die bereits zum offline-CE 14 kopiert
wurden. Um dies durchzuführen,
regelt die Kontrollschaltung 50 den System BUS und speichert – falls
der Prozessor 32 an einer Speicheradresse schreibt, die
bereits kopiert wurde – diese
Adresse in einem FIFO 68. Sobald der Speichertransfer abgeschlossen,
oder der FIFO 68 voll ist, werden die Inhalte der Speicherstellen
zusammen mit den im FIFO 68 abgelegten Speicheradressen
zum offline-CE 14 kopiert und der FIFO 68 entleert.
Bei anderen Anwendungen ist der FIFO 68 dahingehend modifiziert,
dass er sowohl die Speicheradressen, als auch die Inhalte der mit
den Adressen zusammengeschlossenen Speicherstellen oder die Blockadressen
der Speicherblocks, zu denen die geschriebenen Speicheradressen
gehören,
ablegt.
-
Das
IPI Modul 18 kümmert
sich auch um Nicht-BIOS-I/O-Anfragen. In manchen Computersystemen ist
das BIOS zu langsam, um effektiv I/O-Operationen durchzuführen, wie z. B. Videoanzeigen.
Als Ergebnis gestatten es einige weniger strukturierte oder weniger
disziplinierte Betriebssysteme, wie etwa DOS oder UNIX den Anwendungen,
das BIOS zu überlisten
und Nicht-BIOS-I/O Anfragen durch das direkte Lesen von oder Schreiben
in den Adressen, die mit I/O Geräten
verbunden sind, durchzuführen.
Diese Nicht-BIOS-I/O-Anfragen, die nicht durch das Ändern der
Systemunterbrechungstabelle abgefangen werden können, so wie dies beispielsweise
im Zusammenhang mit I/O-Disk Lese- und Schreibvorgängen erfolgt,
sind für
ein System, in welchem die Synchronisation eine enge Kontrolle der
I/O-Schnittstellen verlangt, problematisch.
-
Um
dieses Problem zu beheben und um sicherzustellen, dass selbst Nicht-BIOS-I/O-Anfragen
durch den IOP 12 isoliert und verwaltet werden können, enthält das IPI
Modul 18 virtuelle I/O-Geräte, die die Hardwareschnittstellen
physischer I/O-Geräte
nachahmen. Diese virtuellen I/O-Geräte umfassen ein virtuelles
Display 70 und ein virtuelles Keyboard 72. Falls
nötig,
können
auch andere virtuelle I/O-Geräte,
wie z. B. eine virtuelle Maus, oder virtuelle serielle und parallele
Anschlüsse
verwendet werden.
-
In
der Praxis überwacht
die Kontrollschaltung 50 den System BUS in bezug auf Lese-
oder Schreiboperationen, die an Adressen gerichtet sind, die mit
Nicht-BIOS-I/O-Anfragen an System-I/O-Geräten verbunden sind. Sobald
die Kontrollschaltung 50 solch eine Operation entdeckt,
speichert die Kontrollschaltung die für eine Rekonstruktion der Operation
am entsprechenden virtuellen Gerät
notwendigen Information. So legt die Kontrollschaltung 50 beispielsweise,
wenn sie eine an die mit dem Display 70 verbundene Adresse
gerichtete Schreiboperation registriert, die für eine Rekonstruktion dieser
Operation am virtuellen Display 70 erforderlichen Informationen
ab. Jedes mal, wenn eine BIOS-I/O-Anfrage oder eine Quantenunterbrechung
auftritt, scannt der CE Treiber 44 die virtuellen I/O Geräte und stellt – wenn die
virtuellen Geräte
nicht leer sind – die in
den virtuellen Geräten
abgelegten Informationen in einem IPI-Paket zusammen und schickt
dieses zum IOP 12. Dieser behandelt das Paket unter Nutzung
des oben erörterten
Verfahrens 100 wie eine BIOS-I/O-Anfrage. Wenn die Kontrollschaltung 50 einen
an ein virtuelles I/O-Gerät
adressierten Lesevorgang registriert, assembliert die Kontrollschaltung 50 die
Leseanfrage in einem IPI Paket zur Weiterverarbeitung durch IOP 12.
Der IOP 12 behandelt das IPI-Paket wie eine Standard-BIOS-I/O-Anfrage. Wie in 5 gezeigt,
operiert jedes CE 14 ständig
in einem von acht Zuständen
und das System 10 – da
es nur eine limitierte Anzahl an zulässigen Zustands-Kombinationen
gibt – ständig in
einem von 14 Zuständen.
Die Haupt-CE-Operationszustände
sind OFFLINE, RTB (bereit zum Booten), BOOTING, ACTIVE, RTS (bereit
zum Synchronisieren), WAITING, M_SYNC (Synchronisieren als Master)
und S_SYNC (Synchronisieren als Slave). Die IOP-Kontrolleinrichtung 48 verändert die
Operationszustände
der CEs 14 basierend auf dem Status des Systems 10 und
der Nutzerkommandos von der Konsolensoftware 49. Über die
Konsolensoftware kann ein Nutzer ein CE 14 jederzeit zurücksetzen.
Wann immer ein Nutzer ein CE 14 zurücksetzt, oder eine Störung im
CE 14 auftritt, lässt
die IOP-Kontrolleinrichtung 48 das CE 14 in den
OFFLINE-Zustand wechseln.
-
Beim
Startup operiert das System 10 mit beiden CEs 14b OFFLINE
(Zustand 150). Das System 10 arbeitet in den oberen
Zuständen
der 5 (Zustände 152–162),
wenn das CE 14a vor CE 14b zu arbeiten anfängt und
in den unteren Zuständen
(Zustände 166–176),
wenn CE 14b zuerst den Betrieb aufnimmt. Wenn beide CE 14 simultan
zu operieren beginnen, wird dasjenige CE 14 als zuerst
operierendes behandelt, welches als erstes von der IOP-Kontrolleinrichtung 48 erkannt
wird.
-
Wenn
ein CE 14 durch eine Boot-Anfrage anzeigt, dass es bereit
zum booten ist, wechselt der Zustand des CE 14 zu RTB,
sofern das CE 14 nicht auf Autoboot gesetzt ist, oder zu
BOOTING, sofern es auf Autoboot gesetzt ist. Falls z. B. CE 14a eine
Bootanfrage veranlasst, wenn beide CEs 14 OFFLINE sind,
und CE 14a ist nicht auf Autoboot gesetzt, dann wechselt
der Zustand von CE 14a über
zu RTB (Zustand 152). Danach wartet der IOP-Monitor darauf,
dass der Nutzer über
die Konsolensoftware 49 das CE 14a bootet. Sobald
der Nutzer das CE 14a bootet, wechselt der Zustand von
CE 14a über
zu BOOTING (Zustand 154). Wenn der Nutzer das CE 14a zurücksetzt,
wechselt der Zustand des CE 14a über zu OFFLINE (Zustand 150).
-
Falls
beide CEs 14 offline sind, wenn CE 14a eine Boot-Anfrage
und CE 14a auf Autoboot gesetzt ist, wechselt der Zustand
von CE 14a über
zu BOOTING (Zustand 154). Falls CE 14a erfolgreich
bootet, wechselt der Zustand von CE 14a über zu ACTIVE
(Zustand 156).
-
Wenn
CE 14a ACTIVE ist und CE 14b eine Boot-Anfrage
ausgibt, oder wenn CE 14b bereits eine Boot-Anfrage ausgegeben
hat, während
der Zustand von CE 14a gerade von OFFLINE zu ACTIVE wechselte (Zustände 152–156),
wechselt der Zustand von CE 14b über zu RTS (Zustand 158)
sofern CE 14b auf Autosynchronisation gesetzt ist und anderenfalls
zu WAITING (Zustand 160). Falls der Zustand von CE 14b zu
RTS wechselt, wartet die IOP-Monitor auf den Nutzer, um ein Synchronisations-Kommando
anzugeben. Sofern der Nutzer ein solches Kommando veranlasst, wechselt
der Zustand von CE 14b über
zu WAITING. (Zustand 160).
-
Wenn
sich CE 14b im WAITING-Zustand befindet, kopiert der IOP-Monitor 48 die
Inhalte des Speichersystems 34a von CE 14a in
das Speichersystem 34b von CE 14b. Sobald der
Speichertransfer abgeschlossen ist, wartet der IOP-Monitor 48 auf
CE 14a, um eine Quantenunterbrechung oder ein I/O-Anfrage-IPI-Paket
zu übertragen.
Nach dem Erhalt eines solchen Pakets wechselt der IOP-Monitor 48 den
Zustand von CE 14a zu M_SYNC und den Zustand von CE 14b zu
S_SYNC (Zustand 162) und synchronisiert die CEs 14.
Diese Synchronisation reagiert auf jede Speicherveränderung,
die aufgetreten ist, während
der IOP-Monitor 48 auf CE 14a wartete, um eine
Quantenunterbrechung oder ein I/O Anfrage-IPI-Paket zu übertragen.
Nach der Beendigung der Synchronisation, wechseln die Zustände beider
CEs 14 über
zu ACTIVE (Zustand 164) und das System 10 kann
als vollständig
betriebsbereit angesehen werden.
-
In
einer alternativen Anordnung wartet der IOP-Monitor 48 nicht
auf den Abschluss des Speichertransfers bevor sie den Zustand des
CE 14a in M_SYNC und den Zustand von CE 14b in
S_SYNC (162) ändert. Stattdessen
macht der IOP-Monitor 48 diese Statusänderung erst nach dem Erhalt
eines IPI-Pakets von CE 14a und führt den Speichertransfer als
Teil des Synchronisationsprozesses durch.
-
Ähnliche
Zustandsübergänge treten
auf, wenn CE 14b als erstes eine Boot-Anfrage veranlasst.
Vorausgesetzt, CE 14b ist nicht auf Autoboot gesetzt, geht
CE 14b folglich von OFFLINE (Zustand 150) über zu RTC
(Zustand 166) über
zu BOOTING (Zustand 168) über zu ACTIVE (Zustand 170).
Ist CE 14b auf ähnliche Weise
erst einmal ACTIVE, geht CE 14a – und vorausgesetzt es ist
nicht auf Autosync gesetzt – vom
OFFLINE (Zustand 170) entsprechend über zu RTS (Zustand 172) über zu WAITING
(Zustand 174) über
zu S_SYNC (Zustand 176) über zu ACTIVE (Zustand 164).
-
In
anderen Ausführungsformen
der Erfindung, wie zum Beispiel in 6 dargestellt,
beinhaltet ein fehlerfestes System 200 zwei IOPs 202 und
zwei CEs 204. Jedes CE 204 ist über eine
IPI Karte 206 und ein Kabel 208 mit jeweils einer
IPI Karte 210 der IOPs 202 verbunden. Die IOPs 202 sind
redundant über
IPI Karten 210 und Kabel 212 miteinander verbunden.
Da jede Komponente des Systems 200 eine redundante Backup-Komponente
hat, ist dieses System vollkommen fehlerfest. In einer alternativen
Anwendung können
die Kabel 208 und 210 durch ein Paar lokaler Rechnernetze
ausgetauscht werden, mit welchen jeder IOP 202 und jedes
CE 204 verbunden sind. Tatsächlich können lokale Rechnernetze immer
Kabelverbindungen ersetzen.
-
Das
System 200 ist dahingehend unabhängig von Betriebssystem und
Anwendungssoftware, als dass es keiner Modifikationen am Betriebssystem,
oder der Anwendungssoftware bedarf, damit diese laufen. Jedes einzelne
Hardwareteil kann ohne eine Betriebsunterbrechung aufgewertet oder
repariert werden. Daher kann bei einem sequentiellen Ersetzen eines
jeden Hardwareteils, wobei es dem System 200 gestattet
ist, nach jeder Entfernung eine Synchronisation durchzuführen, die
Hardware in ihrer Gesamtheit ersetzt werden, ohne dass es zu einer
Betriebsunterbrechung kommt. Auf ähnliche Weise kann die Software
auf dem System 200 mit minimalen Betriebsunterbrechungen
aufgewertet werden. (d. h., dass während dem Software-Upgrade
die Anwendung für
eine akzeptable Zeitperiode von z. B. 2 Sekunden nicht verfügbar sein
wird). Vor dem Hintergrund der Verfügbarkeit kann auch Katastrophentoleranz
erlangt werden, indem man jedes IOP/CE Paar an separaten Orten platziert
und sie über
Kommunikationsverbindungen zusammenschließt.
-
Wie
in 7 dargestellt, enthält ein gegliedertes, störungsfestes
Hochleistungssystem 220 zwei Systeme 200, deren
IOPs 202 über
IPI-Module durch Kabel 222 miteinander verbunden sind.
Das System 220 nutzt eine gegliederte Rechnerumgebungssoftware,
um durch das Laufenlassen separater Teile der Anwendung auf jedem
der Systeme 200, die Hochleistung zu erreichen. Das System 220 ist
störungstolerant
und bietet die Fähigkeit
sowohl Hardware- als auch Software-Upgrades ohne eine Betriebsunterbrechung
durchzuführen.
-
Wie
in 8 gezeigt, beinhaltet ein störungstolerantes System 230 drei
IOPs (232, 234 und 236) und drei CEs
(238, 240 und 242). Über IPI-Module 244 und
Kabel 246 ist jeder IOP mit einem IOP-Modul 244 eines jeden
der anderen IOPs verbunden. Über
IPI-Module 248 und Kabel 250 ist jedes CE mit
einem IPI Modul 244 von einem der IOPs verbunden, wobei
CE 238 mit den IOPs 232 und 234, CE 240 mit
den IOPs 232 und 236 und CE 242 mit den
IOPs 234 und 236 verbunden ist. Ebenso wie das
System 200, gestattet das System 230 Hardware-Upgrades
und Software-Upgrades mit nur minimaler Betriebsunterbrechung.
-
Wie
aus einem Vergleich der 7 und 8 hervorgeht,
sind die CEs und IOPs der Systeme 200 und 300 identisch
konfiguriert. Als eine Folge davon bedarf es bei einer Aufstockung
des störungsfesten Systems 200 zu
einem störungstoleranten
System 230 keines Hardwareaustausches und beschränkt sich
auf den einfachen Vorgang des Hinzufügens eines weiteren CE/IOP
Paares, des Verbindens der Kabel und der Anpassung der Systemsoftware.
Diese Modularität
ist ein wichtiges Merkmal der erfindungsgemäßen Paar-Modular-Redundanz
Anordnung.
-
Da
die Komponenten des Systems 230 dreifach-redundant sind,
ist das System 230 eher dazu fähig, die Quelle einer Hardwarestörung zu
identifizieren, als dies beim System 10 der Fall ist. Während somit
das System 10 einfach eines oder beide der CEs 14 ausschaltet,
sobald ein Fehler registriert wird, bietet das System 230 einen
höheren
Grad an Fehlerdiagnose.
-
Wie
in 9 aufgezeigt, führt jedes der IOP (232, 234 und 236)
des Systems 230 die Fehlerdiagnose in Übereinstimmung mit einem Verfahren 300 aus.
Zuerst prüft
jeder IOP (232, 234, 236) die Hauptfehler
wie z. B. Leistungsverlust, gebrochene Kabel und nicht funktionstüchtige CEs
oder IOPs, wobei bekannte Techniken, wie beispielsweise Leistungsmessung,
Kabelmessung und Protocol Timeouts (Schritt 302) verwendet werden.
Wenn eine solche Störung
auftritt, schaltet jeder IOP das fehlerhafte Gerät und wenn nötig das
gesamte System aus.
-
Nach
der Prüfung
der Hauptfehler, wartet jeder IOP darauf, IPI Pakete (d. h. Quantenunterbrechungen oder
I/P Anfragen) von den zwei CEs, mit denen er verbunden ist, zu erhalten
(Schritt 304). So wartet IOP 232 beispielsweise
darauf, IPI-Pakete von den CEs 238 und 240 zu
erhalten. Nach dem Erhalt der IPI-Pakete von den beiden verbundenen
CEs, übermittelt
jeder IOP die Prüfsummen
("CRCs") dieser IPI-Pakete
zu den anderen zwei IOPs und wartet auf den Empfang der CRCs dieser
anderen beiden IOPs (Schritt 306).
-
Nach
dem Erhalt der CRCs von den anderen beiden IOPs, generiert jeder
IOP eine 3×3
Matrix in welcher jede Spalte einem CE, jede Zeile einem IOP und
jeder Eintrag einer CRC der CEs, die von den entsprechenden IOP's empfangen wurden
entspricht.
-
So
generiert IOP
232 beispielsweise die folgende Matrix.
| | CE 238 | CE 240 | CE 242 |
| IOP 232 | CRC | CRC | X |
| IOP 234 | CRC | X | CRC |
| IOP 236 | X | CRC | CRC |
-
Nach
dem Generieren der Matrix summiert IOP 232 die Einträge in jeder
Zeile und jeder Spalte der Matrix. Falls die drei Zeilensummen und
die drei Spaltensummen jeweils übereinstimmen
(Schritt 310), dann gibt es keine Störung und der IOP 232 prüft erneut
auf Hauptfehler Schritt 302).
-
Falls
aber entweder die drei Zeilensummen oder die drei Spaltensummen
voneinander abweichen (Schritt 310), dann vergleicht der
IOP 232 die CRC-Einträge
in jeder der Matrixspalten. Wenn die zwei CRC Einträge in jeder
Matrixspalte übereinstimmen
(Schritt 312), dann diagnostiziert der IOP 232,
dass eine CE-Störung
aufgetreten ist und schaltet das CE korrespondierend zu der Spalte,
in welcher die Summe nicht gleich den Summen der anderen Spalten
ist, ab (Schritt 314).
-
Wenn
die CRC Einträge
in einer oder mehreren der Matrixspalten nicht übereinstimmen (Schritt 312), dann
bestimmt der IOP 232, wie viele der Spalten abweichende
Einträge
enthalten. Falls die Matrix nur eine Spalte mit nicht übereinstimmenden
Einträgen
enthält
(Schritt 315), dann diagnostiziert der IOP 232,
dass die Leiterbahn zwischen dem IOP, entsprechend der Matrixzeilensumme,
die von den übrigen
Matrixzeilensummen abweicht und dem CE entsprechend der Matrixspalte,
die nicht übereinstimmende
Einträge
hat, gestört ist
und deaktiviert diese Leiterbahn (Schritt 316). Für Diagnosezwecke
umfasst die Leiterbahn das IPI-Modul 244 im IOP, das IPI-Modul 248 im
CE und das Kabel 250.
-
Falls
die Matrix mehr als eine Spalte mit nicht übereinstimmenden Einträgen enthält (Schritt 314),
bestätigt
der IOP 232, dass eine Matrixzeilensumme ungleich zu den übrigen Matrixzeilensummen
ist, diagnostiziert eine IOP-Störung
und schaltet den der Matrixzeilensumme, die von den übrigen abweicht,
entsprechenden IOP ab (Schritt 318).
-
Sofern
der IOP nach dem Diagnostizieren und dem Verbuchen entweder einer
CE-Störung
(Schritt 314), einer Leiterbahnstörung (Schritt 316)
oder einer IOP-Störung
(Schritt 318) feststellt, dass das System 300 noch
immer genügend
störungsfreie
Hardware enthält,
um arbeitsfähig
zu bleiben, prüft
der IOP 232 nochmals auf Hauptfehler (Schritt 302).
Da das System 230 dreifach redundant ist, kann das System 230 weiterarbeiten,
selbst wenn einige Komponenten ausgefallen sind. Um beispielweise
in einem Verfügbarkeitsmodus weiter
operieren zu können,
benötigt
das System 230 lediglich ein einzelnes funktionierendes
CE, einen einzelnen funktionierenden IOP und eine funktionstüchtige Leiterbahn
zwischen beiden.
-
Mittels
dem Verfahren 300, kann jeder IOP (232, 234, 236)
jede einzelne Störung
in einem vollständig arbeitsfähigem System 230 oder
in einem System 230, in welchem ein Element (d. h. ein
CE, ein IOP oder eine Leiterbahn) zuvor ausgeschaltet wurde, korrekt
diagnostizieren. In einem System 230, in welchen ein Element ausgeschaltet
wurde, verbucht jeder IOP die CRCs, die wegen dem ausgeschalteten
Element nicht empfangen wurden, mittels Nutzung von Werten, die
im Vergleich zu tatsächlich
empfangenen CRCs als korrekt erscheinen.
-
Das
Verfahren 300 ist nicht abhängig von einer besonderen Anordnung
oder Schaltverbindung der CEs oder IOPs. Um entsprechend zu funktionieren,
erfordert das Verfahren 300 lediglich, dass der Output
eines jeden CEs direkt von mindestens zwei IOPs überwacht wird. Daher kann das
Verfahren 300 bei einem System angewendet werden, das jede
Art von Schaltverbindungsmechanismen nutzt und erfordert keine Punkt
zu Punkt Verbindung zwischen den CEs und den IOPs. Beispielsweise
könnten
die CEs und die IOPs auch mit mindestens zwei lokalen Rechnernetzen
verbunden sein. Bei einer alternativen Anwendungen können, statt dem
Summieren der CRC-Werte in den Zeilen und Spalten der Matrix, diese
Werte auch einfach verglichen werden, und diejenigen Zeilen oder
Spalten, in welchen die Einträge
nicht übereinstimmen,
können
mit einer Übereinstimm/Abweich-Kennzeichnung
versehen werden.
-
Eine
vereinfachte Version des Verfahrens
300 kann in einem System
200 eingesetzt
werden. Bei diesem Verfahren generiert jeder IOP
202 des
Systems
200 eine 2×2
Matrix in welcher jede Spalte mit einem CE
204 und jede
Zeile mit einem IOP
202 korrespondiert.
| | CE 204 | CE 204 |
| IOP 202 | CRC | CRC |
| IOP 202 | CRC | CRC |
-
Nach
dem Generieren der Matrix fügt
jeder IOP 202 eine Abweich-Kennzeichnung in jede Zeile oder Spalte,
in welcher die zwei Einträge
abweichen.
-
Sofern
es keine solchen Abweich-Kennzeichnungen gibt, arbeitet das System 200 korrekt.
-
Wenn
keine Zeile und beide Spalten Abweich-Kennzeichnungen aufweisen,
dann wurde ein IOP 202 gestört. In Abhängigkeit vom Operationsmodus
des Systems 200 schaltet ein IOP 202 dann den
anderen IOP 202 oder das ganze System 200 ab.
Der abzuschaltende IOP 202 wird basierend auf vom Nutzer
bereitgestellten Parametern ausgewählt, ähnlich wie in den zwei Verfügbarkeitsmodi,
die in System 10 verwendet werden.
-
Wenn
beide Zeilen und keine Spalte Abweich-Kennzeichnungen aufweisen,
dann wurde ein CE 204 gestört. In diesem Fall reagieren
die IOPs 202, indem sie ein CE 204 abschalten,
falls das System 200 im Verfügbarkeitsmodus arbeitet, oder
fahren das System 200 herunter, falls das System 200 im
Integritätsmodus arbeitet.
Wenn beide Zeilen und eine Spalte Abweich-Kennzeichnungen aufweisen,
dann wurde eine der Leiterbahnen zwischen den IOPs 201 und
dem CE 204 entsprechend der abweichenden Spalte gestört. Je nach Operationsmodus
des Systems 200 schalten die IOPs 202 entweder
das CE 204 mit der fehlerhaften Leiterbahn ab oder fahren
das ganze System 200 herunter. Wenn beide Zeilen und beide
Spalten Abweich-Kennzeichnungen aufweisen, dann exisiert eine multiple
Störung
und die IOPs 202 fahren das System 200 herunter.
-
Wenn
eine Zeile und beide Spalten Abweich-Kennzeichnungen aufweisen,
dann wurde der der Abweichung entsprechende IOP 202 gestört. In Abhängigkeit
vom jeweiligen Operationsmodus des Systems 200 schalten
der andere IOP 202 entweder den fehlerhaften IOP 202 ab
oder fährt
das System 200 herunter. Wenn eine Zeile und eine Spalte
Abweich-Kennzeichnungen aufweisen, dann wurde die Leiterbahn zwischen
dem der abweichenden Zeile entsprechenden IOP 202 und dem
der abweichenden Spalte entsprechenden CE 204 gestört. In Abhängigkeit
vom Operationsmodus des Systems 200 verbuchen die IOPs 202 die
fehlerhafte Leiterbahn entweder in zukünftigen Prozessen, oder fahren
das System 200 herunter.
-
Wie
in 10 dargestellt, umfasst eine Ausführungsform
eines desastertoleranten Systems 260 zwei fehlertolerante
Systeme 230, die an voneinander entfernten Orten angeordnet
sind und über
Kommunikationsverbindungen 262, wie z. B. Ethernet oder
Glasfaser, zusammengeschlossen sind und miteinander in einem Zwischen-Zeit-Blockierschritt operieren.
Um einen Zwischen-Zeit- Blockierschritt zu erhalten, werden alle IPI-Pakete
zwischen den störungstoleranten
Systemen 230 übertragen.
Wie das System 220, gestattet auch das System 260 Hard-
und Software-Upgrades ohne eine Betriebsunter brechung.
-
Wie
gezeigt, erlaubt die gepaarte Modular-Redundanz Architektur die
Stufen der Störungsfestigkeit und
Störungstoleranz
durch die Verwendung von CEs, die asynchron in Echtzeit operieren
und von IOPs kontrolliert werden, damit sie synchron in der Zwischen-Zeit
operieren, zu variieren. Diese Architektur ist einfach und kostengünstig und
kann mit minimalem Aufwand erweitert oder aufgerüstet werden.