-
Die
vorliegende Erfindung betrifft allgemein Rechnersysteme und insbesondere
ein Verfahren zur Bereitstellung eines Namensdienstes zur Speicherung
in einem hoch-konfigurierbaren Vielknoten-Verarbeitungssystem.
-
Technologische
Evolution resultiert häufig
aus einer Reihe scheinbar nicht zusammenhängender technischer Entwicklungen.
Obwohl diese nicht zusammenhängenden
Entwicklungen jeweils für
sich bedeutend sein können,
können
sie kombiniert das Fundament einer wichtigen technologischen Evolution
bilden. Historisch gesehen ist das technologische Wachstum von Komponenten
in großen
komplexen Rechnersystemen ungleichmäßig verlaufen, einschließlich beispielsweise
(1) der im Vergleich zum Leistungsvermögen der Festplatteneingabe/-ausgabe
rasante Fortschritt beim Zentrale-Verarbeitungseinheit-(CPU-)Leistungsvermögen, (2)
der Entwicklung interner CPU-Architekturen und (3) von Verbindungsstrukturen.
-
Im
Verlauf der letzten zehn Jahre ist das Leistungsvermögen der
Festplatteneingabe/-ausgabe insgesamt sehr viel langsamer angewachsen
als das des Netzknotens. Das CPU-Leistungsvermögen wurde mit einer Geschwindigkeit
von jährlich
40 bis 100 % pro Jahr erhöht,
während
sich die Festplattensuchzeiten lediglich um 7 % jährlich verbessert
haben. Wenn sich dieser Trend erwartungsgemäß fortsetzt, wächst die
Anzahl von Festplattenlaufwerken, die ein typischer Serverknoten
betreiben kann, soweit an, dass die Festplattenlaufwerke in den
meisten großen
Systemen zu einer dominierenden Komponente sowohl in Bezug auf Quantität als auch
Wert werden. Dieses Phänomen
hat sich bereits in bestehenden Großsystemanlagen bemerkbar gemacht.
-
Dokument
US-A-5 671 441 offenbart Verfahren zum automatischen identifizieren
von I/O-Komponenten, wie z.B. dynami schen Schaltern, einer Kontrolleinheit
und anderen Einrichtungen, die durch andere I/O-Komponenten geteilt
werden, die mit einem oder mehreren Computersystemen verbunden sind.
Dokument EP-A-0 365 115 offenbart einen Identifizierer-Generator,
der Objekt-Identifizierer er-zeugt, die hinsichtlich Raum und Zeit
eindeutig sind.
-
Ungleiche
Leistungsstaffelung tritt auch innerhalb der CPU auf. Um das CPU-Leistungsvermögen zu verbessern,
haben CPU-Anbieter
eine Kombination von höheren
Taktgeschwindigkeiten und Architekturänderungen angewendet. Bei vielen
dieser Architekturänderungen
handelt es sich um erprobte Technologien, die aus dem Bereich der
Parallelverarbeitung wirksam eingesetzt wurden. Diese Änderungen
können
ein unausgeglichenes Leistungsvermögen verursachen, was zu einer
Steigerung des Leistungsvermögens
führt,
die nicht so hoch wie erwartet ausfällt. Ein einfaches Beispiel:
Die Grundbefehle ändern
sich nicht mit derselben Rate wie die Geschwindigkeit, mit der eine
CPU Interrupts vektorisieren kann. Somit ändern sich Systemfunktionen,
die vom Interrupt-Leistungsvermögen
(wie beispielsweise Eingabe/Ausgabe, E/A) abhängig sind, nicht auf gleiche
Weise mit der Rechnerleistung.
-
Auch
Verbindungsstrukturen zeigen ungleiche Charakteristika in Bezug
auf das Technologiewachstum auf. Jahrelang befand sich ihr Leistungsniveau
in einem Bereich von 10 – 20
MB/Sek. Im letzten Jahr traten dann auch hier erhebliche Sprünge in Bezug
auf die Bandbreite auf ein Niveau von 100 MB/Sek. (und mehr) auf.
Dieser große
Leistungszuwachs ermöglicht
die wirtschaftliche Entwicklung von Systemen mit massiver Parallelverarbeitung.
-
Dieses
ungleichmäßige Leistungsvermögen wirkt
sich auf Anwendungsarchitekturen und Systemkonfigurationsoptionen
negativ aus. In Bezug auf das Leistungsvermögen von Anwendungen beispielsweise
werden Versuche, die Arbeitslast zu erhöhen, um dadurch die Verbesserung
des Leistungsvermögens
in einem Teil des Systems, wie beispielsweise ein erhöhtes CPU-Leistungsvermögen, vorteilhaft
auszunutzen, oftmals durch den Mangel an einer äquivalenten Verbesserung des
Leistungsvermögens
im Festplattenteilsystem erschwert. Während die CPU die doppelte
Anzahl an Transaktionen pro Sekunde erstellen könnte, kann das Festplattenteilsystem
nur einen Bruchteil dieser Erhöhung
verarbeiten. Die CPU wartet ständig
auf das Speichersystem. Der Gesamteffekt eines ungleichen Wachstums
des Hardwareleistungsvermögens
besteht darin, dass das Leistungsvermögen von Anwendungen eine zunehmende
Abhängigkeit
von den Eigenschaften bestimmter Arbeitslasten erfährt.
-
Ungleichmäßiges Wachstum
bei den Plattformhardwaretechnologien kann ebenfalls in anderen schwerwiegenden
Problemen resultieren: einer Verringerung der Anzahl verfügbarer Optionen
zur Konfigurierung von Mehrknotensystemen. Ein gutes Beispiel ist
die Art und Weise, auf die die Softwarearchitektur einer TERADATA®-Vierknoten-Clique
durch Änderungen
der Technologie der Speicherverbindungen beeinflusst wird. Das TERADATA®-Cliquenmodell
erwartet eine einheitliche Speicherkonnektivität zwischen den Knoten in einer
einzigen Clique: Von jedem Knoten aus kann auf jede Festplatte zugegriffen
werden. Wenn ein Knoten ausfällt,
kann daher der diesem Knoten zugeordnete Speicher auf die übrigen Knoten
aufgeteilt werden. Das ungleichmäßige Wachstum
bei der Speicher- und der Knotentechnologie schränkt die Anzahl an Festplatten ein,
die pro Knoten in einer Umgebung mit geteiltem Speicher angeschlossen
werden können.
Diese Einschränkung
entsteht aus der Anzahl an Festplattenlaufwerken, die an einen E/A-Kanal
angeschlossen werden können,
und der physischen Anzahl an Bussen, die in einer E/A-Topologie
mit Aufteilung auf vier Knoten angeschlossen werden können. Aufgrund
der zunehmenden Verbesserung des Leistungsvermögens der Knoten muss die Anzahl
an Festplattenspindeln, die pro Knoten angeschlossen werden, erhöht werden,
um die Leistungssteigerung umzusetzen.
-
Gestaltungen
mit Clustern und massiver Parallelverarbeitung (massively parallel
processing, MPP) sind Beispiele von Gestaltungen von Mehrknotensystemen,
die die vorhergehenden Probleme zu lösen versuchen. Cluster leiden
unter begrenzter Erweiterbarkeit, während die MPP-Systeme zusätzliche
Software erfordern, um ein ausreichend einfaches Anwendungsmodell
zu bieten (in handelsüblichen
MPP-Systemen handelt es sich bei dieser Software für gewöhnlich um
ein Datenbankverwaltungssystem). MPP-Systeme benötigen außerdem eine Form interner Clusteringbildung
(Cliquen), um eine sehr hohe Verfügbarkeit bereitzustellen. Beide
Lösungen
resultieren noch immer in Herausforderungen in Bezug auf die Verwaltung
der potentiell großen
Anzahl an Festplattenlaufwerken, die als elektromechanische Einrichtungen
ziemlich vorhersagbare Ausfallraten auf-weisen. Die Probleme bei
der Knotenverbindung werden in MPP-Systemen verschlimmert, da die Anzahl
an Knoten für
gewöhnlich
viel größer ist.
Beide Ansätze
resultieren außerdem
in Herausforderungen in Bezug auf die Festplattenkonnektivität, die erneut
durch die große
Anzahl an Festplatten, die zum Speichern sehr großer Datenbanken
erforderlich sind, verstärkt
werden.
-
Die
vorhergehenden Probleme werden in einer Architektur verbessert,
in der Speicherinstanzen und Rechnerinstanzen, die Berechnungen
mittels einer Hochleistungsverbindungsstruktur ausführen, als
Architektur-Peers agieren. Diese Architektur ermöglicht eine erhöhte Flexibilität beim Verwalten
von Speicher- und Rechnerressourcen. Diese Flexibilität resultiert
jedoch in einigen einzigartigen Systemverwaltungsproblemen. Ein
derartiges Problem ist die Benennung von Speichergrößen, auf
die durch die Prozessoren zugegriffen werden soll. Eine potentielle
Lösung
dieses Problems ist ein zentralisierter Namensdienst, der Namen
für alle Speichergrößen erzeugt
und zuordnet. Ein derarti ges System ist jedoch für Einzelpunktfehler anfällig und
gegensätzlich
zur flexiblen Expandierbarkeit, die durch ein Peer-to-Peer-Vielknotensystem
ermöglicht
wird. Die vorliegende Erfindung löst dieses Problem durch die
Bereitstellung der selbständigen
Erzeugung eines global eindeutigen Namens für einen Speicherumfang (die
Datenwerte oder zugewiesene Blöcke
von Daten umfassen kann) durch jeden der Speicherknoten.
-
Die
vorliegende Erfindung stellt ein Verfahren und eine Vorrichtung
zum Übermitteln
von Daten in einer parallel Verarbeitungs-Computerarchitektur bereit.
Das Verfahren umfasst die Schritte des Erzeugens einer global-eindeutigen
ID in den I/O-Knoten für
einen Datenumfang, der physikalisch in der Vielzahl von Speichereinrichtungen
gespeichert ist, ein Binden des global eindeutigen ID zu dem Datenumfang,
und ein Exportieren der global eindeutigen ID zu den Computerknoten über die
Verbindungsstruktur. In einer Ausführungsform wird die global
eindeutige ID aus einem global eindeutigen I/O-Knoten-Identifizierer
und einem lokal eindeutigen Datenumfassungs-Identifizierer erzeugt.
-
Ein
lokaler Eingabepunkt wird in dem Computerknoten für die Daten
erzeugt, die mit der global eindeutigen ID verbunden sind, wodurch
die global eindeutige ID als ein Einrichtungspunkt im Computerknoten präsentiert
wird. In einer Ausführungsform
umfasst der Schritt des Exportierens der global eindeutigen ID zu den
Computerknoten den Schritt eines Empfangs einer Nachricht von den
Computerknoten, die eine Signatur umfasst, die sie sicher für den I/O-Knoten
identifiziert, ein Authentifizieren der Quelle der Nachricht unter
Verwendung der Signatur und ein Übertragen
der global eindeutigen ID, die Daten umfasst, die lokale Zugriffsrechte
für die
Daten spezifiziert, die durch die global eindeutige ID repräsentiert
werden, von dem I/O-Knoten zu
den Computerknoten.
-
Weitere
vorteilhafte Merkmale sind durch die ergänzenden Ansprüche definiert.
-
Es
werden nun mit Bezugnahme auf die begleitenden Zeichnungen bevorzugte
Ausführungsformen der
vorliegenden Erfindung beschrieben. Es zeigen:
-
1 ein
Blockschema der obersten Ebene einer Ausführungsform der vorliegenden
Erfindung, das die Architektur-Hauptelemente
zeigt;
-
2 ein
Blockschema des Systems einer Ausführungsform der vorliegenden
Erfindung;
-
3 ein
Blockschema, das die Struktur der IONs und der Systemverbindung
zeigt;
-
4 ein
Blockschema der Elemente in einem JBOD-Gehäuse;
-
5 ein
Funktionsblockschema des physischen ION-Festplattentreibers;
-
6 ein
Schaubild, das die Struktur strukturspezifischer IDs zeigt;
-
7 ein
Funktionsblockschema, das die Beziehungen zwischen den ION-Gehäuseverwaltungsmodulen
und dem physischen ION-Festplattentreiber zeigt;
-
8 ein
Schaubild der BYNET-Schnittstelle und von zugehörigen Schnittstellen;
-
9 ein
Schaubild des PIT-Kopfteils;
-
10 ein Blockschema der Funktionsmodule des ION 212;
-
11 ein Schaubild, das das ION-Dipolprotokoll zeigt;
-
12 ein Flussdiagramm, das die Operationen zeigt,
die beim Praktizieren einer Ausführungsform der
vorliegenden Erfindung durchgeführt
werden;
-
13 ein Flussdiagramm, das Operationen zeigt, die
beim Erzeugen einer global eindeutigen ID-Nummer ausgeführt werden;
und
-
14 ein Flussdiagramm, das Operationen zeigt, die
bei Exportieren der global eindeutigen ID zu den Computerknoten
durchgeführt
werden.
-
ÜBERBLICK
-
1 ist
ein Überblick über die
Peer-to-Peer-Architektur einer Ausführungsform der vorliegenden
Erfindung. Diese Architektur umfasst eine oder mehrere Rechnerressourcen 102 und
eine oder mehrere Speicherressourcen 104, die mittels einer
oder mehrerer Verbindungsstrukturen 106 und einen oder
mehrere Kommunikationswege 108 kommunikativ an die Rechnerressourcen 102 gekoppelt
sind. Die Strukturen 106 stellen das Kommunikationsmedium
zwischen allen Knoten und allen Speichern bereit, wodurch ein einheitlicher Peer-Zugriff zwischen
den Rechnerressourcen 102 und den Speicherressourcen 104 umgesetzt
wird.
-
In
der in 1 gezeigten Architektur ist
der Speicher nicht mehr an einen einzigen Satz von Knoten gebunden,
wie es in derzeitigen knotenzentrierten Architekturen der Fall ist,
und ein beliebiger Knoten kann mit allen Speichern kommunizieren.
Dies steht im Gegensatz zu heutigen Mehrknotensystemen, in denen
die physische Systemtopologie die Kommunikation zwischen Speicher
und Knoten einschränkt,
und es waren oft unterschiedliche Topologien erforderlich, um den
unterschiedlichen Arbeitslasten zu entsprechen. Die in 1 gezeigte
Architektur ermöglicht
den Kommunikationsmustern der Anwendungssoftware, die Topologie
des Systems zu einem beliebigen gegebenen Zeitpunkt zu bestimmen,
indem sie eine einzige physische Architektur bereitstellt, die ein
breites Spektrum an Systemtopologien unterstützt und ungleichmäßiges Technologiewachstum
zusammenfasst. Die von der Struktur 106 bereitgestellte
Trennung ermöglicht
eine feine Staffelung für
jede der primären
Systemkomponenten.
-
2 stellt
eine detaillierte Beschreibung der Peer-to-Peer-Architektur der vorliegenden Erfindung dar.
Die Rechnerressourcen 102 sind durch einen oder mehrere
Rechnerknoten 200 definiert, wobei jeder mit einem oder
mehreren Prozessoren 216 eine oder mehrere Anwendungen 204 unter
der Steuerung eines Betriebssystems 202 umsetzt. Peripheriegeräte 208,
wie beispielsweise Bandlaufwerke, Drucker oder andere Netzwerke,
sind operativ an den Rechnerknoten 200 gekoppelt. Ebenfalls
operativ an den Rechnerknoten 200 gekoppelt sind lokale
Speichereinrichtungen 210, wie beispielsweise Festplattenlaufwerke,
die die spezifischen Informationen, wie beispielsweise die Befehle,
die das Betriebssystem 202, die Anwendungen 204 oder andere
Informationen umfassen, des Rechnerknotens 200 speichern.
Anwendungsbefehle können
gespeichert und/oder über
mehr als einen der Rechnerknoten 200 auf Art der verteilten
Verarbeitung ausgeführt
werden. In einer Ausführungsform
umfasst der Prozessor 216 einen serienmäßig produzierten, handelsüblich erhältlichen
Mehrzweckprozessor, wie beispielsweise den INTEL P6, und zugehörige Speicher-
und E/A-Elemente.
-
Die
Speicherressourcen 104 sind durch Cliquen 226 definiert,
wobei jede einen ersten E/A-Knoten bzw. ION (I/O node) 212 und
einen zweiten E/A-Knoten bzw. ION 214 enthält, von
denen jeder durch eine Systemverbindung 228 operativ an
jede der Verbindungsstrukturen 106 gekoppelt ist. Der erste
ION 212 und der zweite ION 214 sind operativ an
eine oder mehrere Speicherfestplatten 224 (als „just a
bunch of disks" (lediglich
ein Bündel
Festplatten) bzw. JBOD bekannt) gekoppelt, die einem JBOD-Gehäuse 222 zugeordnet
sind.
-
2 stellt
ein System mittlerer Größe mit einem
typischen Zwei-zu-Eins-Verhältnis
vom ION 212 zu den Rechnerknoten bildlich dar. Die Clique 226 der
vorliegenden Erfindung könnte
auch mit drei oder mehr IONs 214 oder, unter geringem Verlust
bei der Speicherknotenverfügbarkeit,
mit einem einzigen ION 212 umgesetzt werden. Die Besetzung
der Clique 226 ist eine reine Softwareangelegenheit, da
zwischen den IONs 212 keine geteilte Hardware vorliegt.
Paarweise IONs 212 können
als „Dipole" bezeichnet werden.
-
Die
vorliegende Erfindung umfasst des Weiteren eine Verwaltungskomponente
bzw. einen Systemadministrator 230, der mit den Rechnerknoten 200,
den IONs 212 und den Verbindungsstrukturen 106 verbunden ist.
-
Die
Konnektivität
zwischen den IONs 212 und den JBODs 222 ist hier
in vereinfachter Form gezeigt. Die tatsächliche Konnektivität setzt
Fibre Channel-Kabel zu jeder der Ebenen (Reihen; hier vier Reihen)
der Speicherfestplatten 224 in der dargestellten Konfiguration
ein. In der Praxis ist es wahrscheinlich, dass jeder ION 212 zwischen
vierzig und achtzig Festplatten 224 anstelle der in der
dargestellten Ausführungsform
gezeigten zwanzig verwalten würde.
-
ION (Speicherknoten)
-
Interne Architektur
-
Hardwarearchitektur
-
3 ist
ein Schaubild, das weitere Einzelheiten in Bezug auf die Konfiguration
des ION 212 und dessen Schnittstelle mit den JBODs 222 zeigt.
Jeder ION 212 umfasst ein E/A-Verbindungsmodul 302 zum kommunikativen
Koppeln mit jeder Speicherplatte 224 in der Anordnung der
JBOD 222 mittels einer JBOD-Verbindung 206, eine
CPU mit Speicher 304 zum Durchführen der Funktionen des ION 212 und
Umsetzen der hierin beschriebenen physischen ION-Festplattentreiber 500 und
ein Energiemodul 306 zum Liefern von Energie, um den Betrieb
des ION 212 zu unterstützen.
-
JBODs
-
4 ist
ein Schaubild, das weitere Einzelheiten in Bezug auf das JBOD-Gehäuse 222 zeigt.
Alle Komponenten in einem JBOD-Gehäuse 222, die überwacht
oder gesteuert werden können,
werden Elemente 402 – 424 benannt.
Alle Elemente 402 – 424 eines
gegebenen JBOD-Gehäuses
werden durch einen Befehl Diagnoseergebnisse empfangen mit dem Konfigurationsseitencode
zurückgeleitet.
Der ION 212 verwendet diese Liste von Elementen zum Nummerieren
der Elemente. Das erste beschriebene Element 402 ist Element 0,
das zweite Element 404 ist Element 1, usw. Diese Elementnummern
werden beim Erstellen von LUN_Cs verwendet, die von der hierin beschriebenen
Verwaltungsdienstschicht 706 zum Ansteuern von Komponenten verwendet
werden.
-
-
Innerhalb
des Gehäuses
ist die Lage des Elements durch die Ebenen-, die Unterbau- und die
Elementnummer, wie in der obigen Tabelle I gezeigt, spezifiziert.
Ebenennummer ist eine interne Nummer des Dipols, die einer Ebene
zugeordnet ist, die zum Dipol gehört. Unterbauposition bezieht
sich auf die von den Zellenverwaltungseinrichtungen berichtete Höhe. Die
Elementnummer ist ein Index, der durch die SES-Konfigurationsseite in die Elementliste
zurückgeleitet
wurde. Diese Felder machen das LUN_C-Format aus.
-
E/A-Schnittstellentreiberarchitektur
-
5 ist
ein Schaubild, das die E/A-Architektur des ION 212 zeigt,
einschließlich
des physischen ION-Festplattentreibers 500, der für den ION 212 als
ein „SCSI-Treiber" agiert. Der physische
ION-Festplattentreiber 500 zeichnet für das Annehmen von E/A-Anforderungen
von den RAID-Softwaretreibern
(RAID = redundant array of inexpensive disks, redundante Anordnung
preisgünstiger
Festplatten) oder den Verwaltungsdienstprogrammen im Systemadministrator 230 und
das Ausführen
der Anforderung auf einer Einrichtung auf der Einrichtungsseite
der JBOD-Verbindung 206 verantwortlich.
-
Der
physische Festplattentreiber 500 der vorliegenden Erfindung
enthält
drei Hauptkomponenten: einen High-Level-Treiber (high level driver, HLD) 502 und
einen Low-Level-Treiber.
Der HLD 502 umfasst einen gemeinsamen Abschnitt 503 und
einen einrichtungsspezifischen High-Level-Abschnitt 504 und
den Low-Level-Treiber 506. Der gemeinsame Abschnitt 502 und
der einrichtungsspezifische High-Level-Abschnitt 504 sind
vom Adapter unabhängig
und erfordern bei neuen Adaptertypen keine Modifizierung. Der Low-Level-Treiber
der Fibre Channel-Schnittstelle (Fibre Channel Interface, FCI) 506 unterstützt Fibre
Channel-Adapter und ist daher eher protokollspezifisch als adapterspezifisch.
-
Der
FCI-Low-Level-Treiber 506 übersetzt SCSI-Anforderungen
in FCP-Frames und bearbeitet gemeinsame Fibre Channel-Dienste wie Login
und Prozess-Login. An den FCI-Low-Level-Treiber 506 ist eine HIM-Schnittstelle
(HIM = hardware interface module, Hardwareschnittstellenmodul) 508,
die die Fibre Channel-Protokollhandhabung aus den adapter spezifischen
Routinen splittet, operativ gekoppelt. Eine ausführlichere Beschreibung der
vorhergehenden Komponenten wird im Folgenden dargestellt.
-
HIGH-LEVEL-TREIBER
-
Der
High-Level-Treiber (High Level Driver, HLD) 502 ist der
Eingangspunkt für
alle Anforderungen an den ION 212, gleich auf welche Einrichtungsart
zugegriffen wird. Wenn eine Einrichtung geöffnet wird, verknüpft der
HLD 502 Befehlsseiten mit der Einrichtung. Diese anbieterspezifischen
Befehlsseiten diktieren, wie ein SCSI-Befehlsdeskriptorblock für eine spezifische
SCSI-Funktion anzulegen ist. Befehlsseiten ermöglichen dem Treiber, Einrichtungen,
die bestimmte SCSI-Funktionen
anders als von den SCSI-Spezifikationen spezifiziert bearbeiten,
problemlos zu unterstützen.
-
GEMEINSAMER (NICHT EINRICHTUNGSSPEZIFISCHER)
ABSCHNITT
-
Der
gemeinsame Abschnitt des HLD 502 enthält die folgenden Eingangspunkte:
- • cs_init – Initialisieren
von Treiberstrukturen und Zuweisen von Ressourcen.
- • cs_open – Vorbereiten
einer Einrichtung zur Verwendung.
- • cs_close – Abschließen von
E/A und Entfernen einer •Einrichtung
vom Dienst.
- • cs_strategy – Blockieren
von Einrichtungs-Lese-/Schreibeintrag
(Buf_t-Schnittstelle).
- • cs_intr – Warten
eines Hardware-Interrupts.
-
Diese
Routinen führen
für alle
Einrichtungstypen dieselben Funktionen durch. Die meisten dieser
Routinen rufen einrichtungsspezifische Routinen auf, um etwaige
einrichtungsspezifische Anforderungen mittels einer durch den Einrichtungstyp
(Festplatte, Band, WORM, CD-ROM usw.) indizierten Umschalttabelle
zu bearbeiten.
-
Die
Funktion cs_open stellt sicher, dass die Einrichtung existiert und
für an
ihr durchzuführende E/A-Vorgänge bereit
ist. Im Gegensatz zu derzeitigen Systemarchitekturen erstellt der
gemeinsame Abschnitt 503 während der Initialisierung des
Betriebssystems (operating system, OS) keine Tabelle bekannter Einrichtungen.
Stattdessen ist der gemeinsame Abschnitt 503 des Treibers
selbstkonfigurierend: der gemeinsame Abschnitt 503 des
Treibers bestimmt den Zustand der Einrichtung während des anfänglichen Öffnens dieser Einrichtung.
Das ermöglicht
dem gemeinsamen Abschnitt 503 des Treibers, die Einrichtungen
zu „sehen", die nach der Initialisierungsphase
des OS 202 möglicherweise
auf online geschaltet worden sein könnten.
-
Während des
anfänglichen Öffnens werden
SCSI-Einrichtungen durch Liefern eines SCSI-Anfrage-Befehls an die
Zieleinrichtung mit einer Befehlsseite verknüpft. Wenn die Einrichtung positiv
antwortet, werden die Antwortdaten (die Informationen wie beispielsweise
die Anbieter-ID, Produkt-ID
und das Firmwareversionslevel enthalten) mit einer Tabelle bekannter
Einrichtungen innerhalb des SCSI-Konfigurationsmoduls 516 verglichen.
Wenn eine Übereinstimmung
festgestellt wird, wird die Einrichtung mit der in diesem Tabelleneintrag
spezifizierten Befehlsseite explizit verknüpft. Wenn keine Übereinstimmung
festgestellt wird, wird die Einrichtung mit einer auf dem Antwortdatenformat
basierenden generischen CCS-Befehlsseite (CCS = Common Command Set,
standardisierter Befehlssatz) oder einer SCSI-II-Befehlsseite implizit verknüpft.
-
Der
gemeinsame Abschnitt 503 des Treibers enthält vom Low-Level-Treiber 506 verwendete
Routinen und Befehlsseitenfunktionen zum Zuweisen von Ressourcen,
um eine DMA-Liste für
Scatter/Gather-Vorgänge zu
erstellen und einen SCSI-Vorgang
abzuschließen.
-
Alle
Routinen des FCI-Low-Level-Treibers 506 werden vom gemeinsamen
Abschnitt 503 des Treibers aufgerufen. Beim gemeinsamen
Abschnitt 503 des Treibers handelt es sich um die einzige
Schicht, die tatsächlich
einen SCSI-Vorgang durch Aufrufen der entsprechenden Routine des
Low-Level-Treibers
(low level driver, LLD) initiiert, um die Hardware einzurichten
und den Vorgang zu starten. Es wird auch mittels einer durch eine
Treiber-ID, die während
der Konfiguration vom SCSI-Konfigurationsmodul 516 zugeordnet
wurde, indizierten Umschalttabelle auf die LLD-Routinen zugegriffen.
-
EINRICHTUNGSSPEZIFISCHER
ABSCHNITT
-
Die
Schnittstellen zwischen dem gemeinsamen Abschnitt 502 und
den einrichtungsspezifischen Routinen 504 sind den Schnittstellen
zum gemeinsamen Abschnitt ähnlich
und enthalten cssx_init-, csxx_open-, csxx_close- und csxx_strategy-Befehle.
Die Kennzeichnung „xx" zeigt den Speichereinrichtungstyp
(z. B. „dk" für Festplatte
(disk) oder „tp" für Band (tage))
an. Diese Routinen bearbeiten alle einrichtungsspezifischen Anforderungen.
Wenn es sich bei der Einrichtung beispielsweise um eine Festplatte
handelt, muss csdk_open die Aufteilungstabelleninformationen aus
einem spezifischen Bereich der Festplatte auslesen und csdk_strategy muss
die Aufteilungstabelleninformationen verwenden, um zu bestimmen,
ob ein Block tabu ist. (Aufteilungstabellen definieren das Mapping
von logischem zu physischem Festplattenblock für jede spezifische physische
Festplatte.)
-
HIGH-LEVEL-TREIBER-FEHLER/AUSFALLSICHERUNGSHANDHABUNG
-
Fehlerhandhabung
-
Wiederholungen
-
Das üblichste
Wiederherstellungsverfahren des HLD 502 geschieht durch
Wiederholen der fehlgeschlagenen E/As. Die Anzahl der Wiederholungen
für einen
gegebenen Befehlstyp ist durch die Befehlsseite spezifiziert. Da
beispielsweise ein Lese- oder Schreibbefehl als sehr wichtig erachtet
wird, können
dessen zugehörige
Befehlsseiten den Wiederholungszählwert
auf 3 einstellen. Ein Anfragebefehl ist nicht so wichtig, ständige Neuversuche
während
der Vorgänge
beim Hochfahren (Start of Day) könnten
jedoch das System verlangsamen, daher könnte sein Wiederholungszählwert Null
sein.
-
Wenn
eine Anforderung zum ersten Mal ausgegeben wird, wird ihr Wiederholungszählwert auf
Null eingestellt. Jedes Mal, wenn die Anforderung fehlschlägt und das
Wiederherstellungsschema eine Wiederholung durchführen wird,
wird der Wiederholungszählwert
erhöht.
Wenn der Wiederholungszählwert
größer als der
durch die Befehlsseite spezifizierte maximale Wiederholungszählwert ist,
ist die E/A fehlgeschlagen und eine Nachricht wird zum Anforderer
zurück übertragen.
Andernfalls wird sie erneut ausgegeben. Die einzige Ausnahme von
dieser Regel besteht für „Unit Attentions" (Einheitswarnungen),
bei denen es sich in der Regel um Ereignisbenachrichtigungen und
nicht um Fehler handelt. Wenn für
einen Befehl eine Unit Attention empfangen wird und sein Wiederholungsmaximum
auf Null oder Eins eingestellt ist, stellt der High-Level-Treiber 502 das
Wiederholungsmaximum für
diese spezifische E/A auf 2. Dies hindert einen E/A daran, vorzeitig
aufgrund einer Unit Attention-Kondition
abgelehnt zu werden.
-
Eine
verzögerte
Wiederholung wird analog zum oben beschrie benen Wiederholungsschema
bearbeitet, mit der Ausnahme, dass die Wiederholung nicht eine spezifizierte
Zeitspanne lang in der Warteschlange ersetzt wird.
-
Fehlgeschlagene
Scsi_ops
-
Ein
an den FCI-Low-Level-Treiber 506 ausgegebener Scsi_op kann
aufgrund mehrerer Umstände fehlschlagen.
Die folgende Tabelle II zeigt mögliche
Fehlschlagstypen, die der FCI-Low-Level-Treiber 506 an den
HLD 402 zurückleiten
kann.
-
-
-
-
Tabelle
II: Fehlerkonditionen des Low-Level-Treibers
-
UNZUREICHENDE RESSOURCEN
-
Fehler
bezüglich
unzureichender Ressourcen treten auf, wenn eine beliebige gewünschte Ressource zur
angeforderten Zeit nicht zur Verfügung steht. In der Regel handelt
es sich bei diesen Ressourcen um den Systemspeicher und den Treiberstrukurspeicher.
-
Die
Handhabung von unzureichendem Systemspeicher wird durch Blockieren
von Semaphoren umgesetzt. Ein Thread, der auf einer Speicherressource
blockiert, wird verhindern, dass etwaige neue E/As ausgegeben werden.
Der Thread wird solange blockiert bleiben, bis der Abschluss einer
E/A Speicher freigibt.
-
Treiberstrukturressourcen
stehen mit den Listendatenbasen des Scsi_op und des IOV in Zusammenhang.
Die IOV-Liste ist eine Liste von Speicherstart- und Längenwerten,
die zu oder von der Festplatte übermittelt
werden. Diese Speicherdatenbasen werden beim Hochfahren (Start of
Day) durch Verwenden eines abstimmbaren Parameters initialisiert,
um den Umfang der Datenbasen zu spezifizieren. Wenn die Scsi_op-
oder die IOV-Datenbasis leer ist, wird eine neue E/A im Wachstum
dieser Datenbasen resultieren. Eine Speicherseite (4096 Byte) wird
zu einem Zeitpunkt zugewiesen, um eine der Datenbasen anwachsen
zu lassen. Die Seite wird nicht freigegeben, bevor nicht alle Scsi_ops
oder IOV von der neuen Seite freigegeben werden. Wenn ein ION 212 dauerhaft
Seiten für
Scsi_ops oder Seiten zuweist und freigibt, kann es wünschenswert sein,
die zugehörigen
Parameter abzustimmen.
-
Die
gesamte Handhabung von unzureichenden Ressourcen wird durch Ereignisse
protokolliert.
-
"START OF DAY"-HANDHABUNG
-
Beim
Hochfahren (Start of Day) initialisiert der HLD 502 seine
erforderlichen Strukturen und Datenbasen und führt Aufrufe aus, um adapterspezifische
Treiber und Hardware zu initialisieren. „Start of Day"-Handhabung wird
durch einen Aufruf von cs_init() gestartet, der (1) Scsi_op-Datenbasen
zuweist; (2) IOV-Datenbasen zuweist; (3) Aufrufe von FCIhw_init()
ausführt,
um Fibre Channel-Strukturen und -Hardware zu initialisieren; und
(4) die Interrupt-Dienstroutine
cs_intr() mit geeigneten Interrupt-Vektoren verknüpft.
-
AUSFALLSICHERUNGSHANDHABUNG
-
Die
zwei Hälften
des Dipols von ION 212 werden mit einem herkömmlichen
Satz von Festplatteneinrichtungen verbunden. Beide IONs 212 und 214 in
einem Dipol 226 müssen
zu einem beliebigen gegebenen Zeitpunkt in der Lage sein, auf alle
Einrichtungen zuzugreifen. Aus Perspektive des HLD 502 gibt
es keine spezielle Handhabung von Ausfallsicherungen.
-
BEFEHLSSEITEN
-
Die
IONs 212 der vorliegenden Erfindung verwenden ein Befehlsseitenverfahren,
das den gemeinsamen Abschnitt und die einrichtungsspezifischen Abschnitte
vom tatsächlichen
Anlegen des SCSI-Befehls absondert. Bei einer Befehlsseite handelt
es sich um eine Liste von Zeigern auf Funktionen, wobei jede Funktion einen
SCSI-Befehl (z. B. SCSI_2_Test_Unit_Ready) darstellt. Wie oben erwähnt wird
eine spezifische Befehlsseite beim anfänglichen Öffnen oder Zugriff auf eine
Einrichtung mit dieser Einrichtung verknüpft. Alle anbietereigenen und
nicht-konformen SCSI- Einrichtungseigenarten
werden durch die mittels der spezifischen Befehlsseite dieser Einrichtung
referenzierten Funktionen verwaltet. Ein typisches System würde mit
CCS – (command
control set, Befehlssteuersatz), SCSI I- und SCSI II-Seiten und
anbietereigenen Seiten geliefert werden, um eine Integrierung nicht-konformer
SCSI-Einrichtungen oder anbietereigener SCSI-Befehle zu ermöglichen.
-
Befehlsseitenfunktionen
werden von dem gemeinsamen Abschnitt 503 der Einrichtung,
dem einrichtungsspezifischen Abschnitt 504 und dem FCI-Low-Level-Treiber 506 (Request
Sense, Erfassung anfordern) durch eine als VirtualDEVice-Schnittstelle (VDEV-Schnittstelle)
bezeichnete Schnittstelle aufgerufen. In diesen Ebenen interessiert
es die Software nicht, welchen SCSI-Dialekt die Einrichtung verwendet,
sondern nur, dass die Einrichtung die geplante Funktion durchführt.
-
Jede
Befehlsseitenfunktion legt einen SCSI-Befehl an und weist gegebenenfalls
Speicher für
Datenübermittlungen
mit direktem Speicherzugriff (direct memory access, DMA) zu. Die
Funktion gibt dann die Steuerung zurück an den gemeinsamen Abschnitt 503 des
Treibers. Der gemeinsame Abschnitt 503 des Treibers führt anschließend den
Befehl aus, indem er den SCSI-Vorgang in eine Warteschlange setzt
(gegebenenfalls wird hier eine Sortierung vorgenommen) und ruft
die Start-Routine des FCI-Low-Level-Treibers 506 auf. Nachdem
der Befehl ausgeführt
wurde, wird, wenn in der Befehlsseitenfunktion eine „COI"-Routine (COI = Call
on Interrupt, Aufruf auf Interrupt) existiert, die COI aufgerufen,
bevor der gemeinsame Abschnitt 503 des Treibers die Daten/Informationen
des abgeschlossenen Befehls überprüft. Durch
Mitteilen der zurückgeleiteten
Daten/Infor-mationen kann die COI nicht-übereinstimmende SCSI-Daten/Informationen
in Standard-SCSI-Daten/Informationen umwandeln. Wenn beispielsweise
die Anfragedaten einer Einrichtung, die in Byte 12 anstelle
von Byte 8 startende Anbieter-ID enthalten, wird die Befehlsseitenfunktion
für Anfrage
eine COI enthalten, die die Anbieter-ID in Byte 8 der zurückgeleiteten
Anfragedaten verschiebt. Der gemein-same Abschnitt 503 des
Treibers wird stets die bei Byte 8 beginnende Anbieter-ID-Information extrahieren
und benötigt
daher keine Informationen zur nicht-übereinstimmenden Einrichtung.
-
JBOD- UND
SCSI-KONFIGURATIONSMODUL
-
Eine
wichtige Funktion von RAID-Kontrollern besteht darin, Daten vor
Verlust zu sichern. Um diese Funktion durchzuführen, muss die RAID-Software
physisch wissen, wo sich eine Festplatteneinrichtung befindet und
auf welche Weise deren Verkabelung sich mit ihr verbindet. Daher
ist eine wichtige Voraussetzung beim Umsetzen von RAID-Kontrollertechniken
die Fähigkeit
zum Steuern der Konfiguration der Speichereinrichtungen. Der JBOD-Abschnitt
des JBOD- und SCSI-Konfigurationsmoduls 516 ist mit dem
Definieren einer statischen JBOD-Konfiguration für den ION 212 beschäftigt. Vom
JBOD- und SCSI-Konfigurationsmodul 516 beschriebene
Konfigurationsinformationen sind in Tabelle III gezeigt.
-
-
-
Zusätzlich zur
Information der physischen Lage der Adapter, des JBOD-Gehäuses 222 und
der Speicherplatten 224 müssen andere Konfigurationsinformationen
wie die Eingangspunkte des FCI-Low-Level-Treibers 506 und
des einrichtungsspezifischen Abschnitts 504 des Treibers
sowie Befehlsseitendefinitionen beschrieben sein. Zum Bereitstellen
dieser Informationen wird eine space.c-Datei verwendet und der ION 212 legt
die Konfigurationsinformationen bei der Kompilationszeit des physischen
ION-Festplattentreibers 500 an. In den Fällen, in
denen die unterstützten
Konfigurationen des ION 212 geändert werden, muss eine neue
Version der physischen ION-Festplattentreiber 500 kompiliert
werden.
-
LOW-LEVEL-TREIBER DER
FIBRE CHANNEL-SCHNITTSTELLE (FIBRE CHANNEL INTERFACE, FCI)
-
Der
FCI-Low-Level-Treiber 506 verwaltet die SCSI-Schnittstelle
für den
High-Level-Treiber 502. Die Schnittstelle zwischen dem
gemeinsamen Abschnitt 503 des Treibers und dem FCI-Low-Level-Treiber 506 beinhaltet
die folgenden Routinen, wobei es sich bei der Kennzeichnung „xx" um eine eindeutige
Kennung für
die Hardware, die der FCI-Low-Level-Treiber 506 steuert (z. B.
FCIhw_init), handelt:
- • xxhw_init – Initialisiert die Hardware.
- • xxhw_open – Bestimmt
den aktuellen Status des Host-Adapters.
- • xxhw_config – Einrichten
der Konfigurationsinformationen des Host-Adapters (SCSI-ID, usw.)
- • xxhw_start – Initiiert
einen SCSI-Vorgang, falls möglich.
- • xxhw_intr – Verarbeiten
aller SCSI-Interrupts.
-
Beim
Low-Level-Treiber handelt es sich in der Hinsicht um einen reinen
SCSI-Treiber, dass er weder von den Besonderheiten einer Einrichtung
weiß noch
dass ihn diese interessieren; er ist stattdessen einfach eine Leitung
für die
SCSI-Befehle vom oberen Level. Die Interrupt-Dienstroutinen, die
Hardwareinitialisierungs-, Mapping- und Adressübersetzungs- und die Fehlerwiederherstellungs-routinen
befinden sich in dieser Schicht. Darüber hinaus können mehrere
Arten von Low-Level-Treibern im selben System koexistieren. Diese Aufteilung
zwischen der hardwaresteuernden Schicht und dem Rest des Treibers
ermöglicht
es, dass auf verschiedenen Maschinen derselbe High-Level-Treiber
ausgeführt
werden kann.
-
Die
grundlegenden Funktionen des FCI-Moduls sind (1) sich mit dem SCSI-High-Level-Treiber
(SHLD) zu verbinden, um SCSI_ops in eine FCI-Arbeitsobjektstrukutr
(E/A-Block (I/O Block, IOB)) zu übersetzen;
(2) eine gemeinsame Schnittstelle bereitzustellen, um die Unterstützung der
neuen Fibre Channel-Adapter durch verschiedene HIMs 508 zu
vereinfachen; (3) gemeinsame FC-3-Dienste bereitzustellen, die von
einer beliebigen FC-4-Protokollschicht (in der dargestellten Ausführungsform
Fibre Channel-Protokoll (FCP)) verwendet werden kann; (4) Taktgeberdienste
bereitzustellen, um zum HIM gesendete asynchrone Befehle (z. B. FCP-Befehle, FC-3-Befehle,
LIP-Befehle) in dem Fall zu schützen,
dass das HIM 508 oder die Hardware nicht antwortet; (5)
Ressourcen für
den gesamten Fibre Channel-Treiber (FCI und HIM) zu verwalten, einschließlich (a)
E/A-Anforderungsblöcken
(IOB), (b) Vektortabellen, (c) Ressourcen des HIM 508 (z.
B. Host-Adapterspeicher, DMA-Kanäle,
E/A-Anschlüsse,
Scratch-Speicher); (6) für
die Verwendung einer Fibre Channel-„Arbitrated Loop" zu optimieren (im
Gegensatz zur Fibre Channel-Struktur).
-
Eine
Liste wichtiger Datenstrukturen für den FCI-Low-Level-Treiber
506 ist
in der folgenden Tabelle IV angegeben:
Tabelle
IV FC-Hauptdatenstrukturen
-
FEHLERHANDHABUNG
-
Fehler,
die der FCI-Low-Level-Treiber 506 bearbeitet, tendieren
dazu, in Bezug auf den Fibre Channel und/oder die FCI selbst fehlerspezifisch
zu sein.
-
MEHRSTUFENFEHLERHANDHABUNG
-
Der
FCI-Low-Level-Treiber 506 bearbeitet bestimmte Fehler mit
Mehrstufenhandhabung. Dies ermöglicht,
Fehlerhand habungstechniken auf den Fehlertyp zu optimieren. Wenn
beispielsweise eine weniger destruktive Methode angewendet wird
und diese nicht funktioniert, können
drastischere Fehlerhandhabungsmaßnahmen unternommen werden.
-
FEHLGESCHLAGENE
IOB
-
Alle
E/A-Anforderungen werden durch einen E/A-Anforderungsblock zum HIM 508 gesendet.
Bei den folgenden Fehlern handelt es sich um mögliche Fehler, die das HIM 508 zurücksenden
kann.
-
-
-
Tabelle
V: HIM-Fehlerkonditionen
-
UNZUREICHENDE RESSOURCEN
-
Der
FCI-Low-Level-Treiber 506 verwaltet Ressourcendatenbasen
für IOB
und Vektortabellen. Da der Umfang dieser Datenbasen auf die Konfiguration
des ION 212 abgestimmt wird, sollte es nicht möglich sein, dass
diese Ressourcen ausgehen, und es werden einfache Wiederherstellungsmethoden
umgesetzt.
-
Wenn
eine Anforderung nach einem IOB oder einer Vektortabelle gemacht
wird und nicht genügend Ressourcen
vorliegen, um der Anforderung nachzukommen, wird die E/A wieder in
die Warteschlange gesetzt und ein Taktgeber wird zum erneuten Starten
der E/A eingestellt. Vorkommnisse mit unzureichenden Ressourcen
werden protokolliert.
-
"START OF DAY"-HANDHABUNG
-
Beim
Hochfahren (Start of Day) führt
der High-Level-Treiber 502 einen Aufruf an jeden unterstützten Low-Level-Treiber
(einschließlich
des FCI-Low-Level-Treibers 506) aus. Die „Start
of Day"-Handhabung
des Low-Level-Treibers der FCI 506 beginnt mit einem Aufruf
von der FCIhw_init()-Routine, die die folgenden Vorgänge ausführt.
-
Zunächst wird
für eine
spezifische PCI-Bus-Einrichtung eine HIM_FindController()-Funktion
aufgerufen. Dies ruft eine Version von FindController() auf. Das
JBOD- und SCSI-Konfigurationsmodul 516 spezifiziert die
zu durchsuchenden PCI-Bus-Einrichtungen.
Als Nächstes
wird, wenn ein Adapter (wie beispielsweise von ADAPTEC erhältliche)
gefunden wird, ein HCB zugewiesen und für den Adapter initialisiert.
Dann wird HIM_GetConfiguration() aufgerufen, um die adapterspezifischen
Ressourcen wie Scratch-Speicher, speicherabgebildete E/A und DMA-Kanäle zu erhalten.
Als Nächstes
werden Ressourcen zugewiesen und initialisiert und HIM_Initialize()
wird aufgerufen, um das HIM von ADAPTEC und die Hardware zu initialisieren.
Schließlich werden
IOB und Vektortabellen zugewiesen und initialisiert.
-
AUSFALLSICHERUNGSHANDHABUNG
-
Die
zwei Hälften
des Dipols von ION 212 werden mit einem herkömmlichen
Satz von Festplatteneinrichtungen verbunden. Beide IONs 212 müssen zu
einem beliebigen gegebenen Zeitpunkt in der Lage sein, auf alle
Einrichtungen zuzugreifen. Aus der Sichtweise des FCI-Low-Level-Treibers 506 gibt
es keine spezielle Handhabung von Ausfallsicherungen.
-
HARDWARESCHNITTSTELLENMODUL
(HARDWARE INTERFACE MODULE, HIM)
-
Das
Hardwareschnittstellenmodul (Hardware Interface Module, HIM) 508 ist
zum Verbinden mit dem SlimHIM 509 von ADAPTEC konzipiert.
Das HIM-Modul 508 hat als primäre Verantwortlichkeit, Anforderungen vom
FCI-Low-Level-Treiber 506 in eine Anforderung zu übersetzen,
die das SlimHIM 509 verstehen und zur Hardware ausgeben
kann. Dies umfasst das Annehmen von IOB-Anforderungen (IOB = I/O
Block, E/A-Block) und das Übersetzen
dieser in entsprechende TCB-Anforderungen (TCB = Transfer Control
Block, Übermittlungssteuerblock),
die vom SlimHIM 509 verstanden werden.
-
Die
grundlegenden Funktionen des HIM 508 beinhalten: (1) das
Definieren einer Low-Level-API (API = application program interface,
Anwendungsprogrammschnittstelle) zu hardwarespezifischen Funktionen,
die E/A finden, konfigurieren, initialisieren und zum Adapter senden
(Find, Configure, Initialize and Send), (2) das Verbinden mit dem
FCI-Low-Level-Treiber 506,
um E/A-Blöcke
(I/O Blocks, IOBs) in TCB-Anforderungen zu übersetzen, die das SlimHIM/die
Hardware verstehen kann (z. B. primitive FC-TCBs, FC-ELS-TCBs (ELS
= Extended Link Services, erweiterte Verknüpfungsdienste) und SCSI-FCP-Vorgangs-TCBs);
(3) das Verfolgen der Lieferung und des Abschlusses von an das SlimHIM
ausgegebenen Befehlen (TCB); (4) das Interpretieren von Interrupt-
und Ereignisinformationen vom SlimHIM 509 und Initiieren
der entsprechenden Interrupt-Handhabung und/oder Fehlerwiederherstellung
in Verbindung mit dem FCI-Low-Level-Treiber 506.
Die Datenstruktur des TCB ist in der folgenden Tabelle VI dargestellt.
-
Tabelle
VI: HIM-Hauptstrukturen
-
"START OF DAY"-HANDHABUNG
-
Das
HIM 508 definiert drei beim Hochfahren („Start
of Day") verwendete
Eingangspunkte. Der erste Eingangspunkt ist der HIM_FindAdapter,
der durch FCIhw_init() aufgerufen wird, und verwendet PCI-BIOS-Routinen,
um zu bestimmen, ob sich auf der gegebenen PCI-Bus-Einrichtung ein
Adapter befindet. Die PCI-Anbieter- und -Produkt-ID für den Adapter
wird verwendet, um zu bestimmen, ob der Adapter vorliegt.
-
Der
zweite Eingangspunkt ist der HIM_GetConfiguration, der durch FCIhw_init()
aufgerufen wird, wenn ein Adapter vorliegt, und setzt Ressourcenerfordernisse
in den bereitgestellten HCB. Beim ADAPTEC-Adapter beinhalten diese
Ressourcen IRQ-, Scratch- und TCB-Speicher. Diese Information wird
durch Ausführen
von Aufrufen an das SlimHIM 509 gefunden.
-
Der
dritte Eingangspunkt ist der HIM_Initialize, der durch FCIhw_init()
aufgerufen wird, nachdem Ressourcen zugewiesen und initialisiert
wurden, und die initalisierte TCB-Speicherdatenbasis ruft das SlimHIM auf,
um den Scratch-Speicher,
die TCB und die Hardware zu initialisieren.
-
AUSFALLSICHERUNGSHANDHRBUNG
-
Die
zwei Hälften
des ION-Dipols 226 werden mit einem gemeinsamen Satz von
Festplatteneinrichtungen verbunden. Beide IONs 212, 214 müssen zu
einem beliebigen gegebenen Zeitpunkt in der Lage sein, auf alle
Einrichtungen zuzugreifen. Aus der Sichtweise des HIM 509 gibt
es keine spezielle Handhabung von Ausfallsicherungen.
-
AIC-1160-SlimHIM
-
Das
Modul SlimHIM 509 hat als Gesamtzielsetzung, eine Hardwareabziehung
des Adapters (in der dargestellten Ausführungsform der AIC-1160 von
ADAPTEC) bereitzustellen. Das SlimHIM 509 hat die primäre Rolle
des Transportierens von Fibre Channel-Anforderungen zum AIC-1160-Adapter,
des Bedienens von Interrupts und des Berichterstattens des Status
zurück
zum HIM-Modul durch die Schnittstelle des SlimHIM 509.
-
Das
SlimHIM 509 nimmt außerdem
die Steuerung der AIC-1160-Hardware
an sich und initialisiert diese, lädt die Firmware, startet Laufzeitvorgänge und übernimmt
die Steuerung der AIC-1160-Hardware beim Ereignis eines AIC-1160-Fehlers.
-
Externe Schnittstellen
und Protokolle
-
Alle
Anforderungen des physischen ION-Festplattentreiberteilsystems 500 werden
durch den gemeinsamen High-Level-Treiber 502 vorgenommen.
-
Initialisierung (cs_init)
-
Ein
einziger Aufruf in das Teilsystem führt die gesamte Initialisierung
durch, die für
das Vorbereiten einer Einrichtung auf E/As erforderlich ist. Während der
Initialisierung des Teilsystems werden alle Treiberstrukturen zuge wiesen
und initialisiert sowie jegliche Einrichtungs- oder Adapterhardware
initialisiert.
-
Open/Close (cs_open/cs_close)
-
Die
Open/Close-Schnittstelle 510 initialisiert zum Zugriff
auf eine Einrichtung erforderliche Strukturen und analysiert diese.
Die Schnittstelle 510 ist typischen Open/-Close-Routinen unähnlich,
da alle „opens" (Öffnen) und „closes" (Schließen) implizit
geschichtet sind. Daraus folgernd muss jedes vom physischen E/A-Schnittstellentreiber 500 empfangene „open" von einem empfangenen
und zugehörigen „close" begleitet sein,
und einrichtungsbezogene Strukturen werden solange nicht freigegeben,
bis alle „opens" „geschlossen" (closed) wurden.
Die Open/Close-Schnittstellen 510 sind
insofern synchron, dass das Zurückleiten
des „open" oder des „close" den Abschluss der
Anforderung anzeigt.
-
Buf_t (cs_strategy)
-
Die
Buf_t-Schnittstelle 512 ermöglicht das Ausgeben von Lese-
und Schreibanforderungen des logischen Blocks an Einrichtungen.
Der Anforderer läuft
eine Buf_t-Struktur hinunter, die die E/A beschreibt. Attribute
wie die Einrichtungs-ID, die Adresse des logischen Blocks, die Datenadressen,
der E/A-Typ (Lesen/Schreiben) und die Rückrufroutinen werden durch
die Buf_t beschrieben. Nach Abschluss der Anforderung wird eine
durch den Rückruf
vom Anforderer spezifizierte Funktion aufgerufen. Die Buf_t-Schnittstelle 512 ist
eine asynchrone Schnittstelle. Das Zurückleiten der Funktion zum Anforderer
zeigt nicht an, dass die Anforderung abgeschlossen ist. Wenn die
Funktion zurückkommt,
kann die E/A auf der Einrichtung ausgeführt werden oder auch nicht.
Die Anforderung kann in einer Warteschlange darauf warten, ausgeführt zu werden.
Die Anforderung ist solange nicht abgeschlossen, bis die Rückruffunktion
aufgerufen wird.
-
SCSILib
-
SCSILib 514 stellt
eine Schnittstelle bereit, die es ermöglicht, SCSI-Befehlsdeskriptorblöcke (command
descriptor blocks, CDB) mit Ausnahme von normalen Lese- und Schreibvorgängen an
Einrichtungen zu senden. Durch diese Schnittstelle werden Anforderungen
wie Einheit Starten und Einheit Stoppen verwendet werden, um Festplatten
zu spulen und herunterzuspulen, und Sende- und Empfangen-Diagnosefunktionen werden
zum Überwachen
und Steuern von Gehäuseeinrichtungen
verwendet. Alle SCSILib-Routinen sind synchron. Das Zurückleiten
der aufgerufenen Funktion zeigt den Abschluss der Anforderung an.
-
Interrupts (cs_intr)
-
Der
physische ION-Festplattentreiber 500 ist der zentrale Versender
für alle
SCSI- und Fibre Channel-Adapterinterrupts. In einer Ausführungsform
wird ein Front-End/Back-End-Interruptschema
eingesetzt. In den Fällen,
in denen ein Interrupt bedient wird, wird eine Front-End-Interruptdienstroutine
aufgerufen. Das Front-End wird vom Interrupt-Stapelspeicher ausgeführt und
zeichnet verantwortlich für
das Leeren der Quelle des Interrupts, wobei der Adapter deaktiviert
wird, so dass er keine weiteren Interrupts erzeugen kann, und eine
Back-End-Interruptdienstroutine eingeplant wird. Das Back-End wird
als eine Aufgabe hoher Priorität
ausgeführt,
die den Interrupt (zusammen mit etwaigen anderen Interrupts, die
zwischen dem Deaktivieren der Adapterinterrupts und dem Starten
der Back-End-Aufgabe erfolgt sein könnten) tatsächlich bearbeitet. Vor dem Verlassen
des Back-Ends werden die Interrupts auf dem Adapter reaktiviert.
-
ION-Funktionen
-
Die
IONs 212 führen
fünf primäre Funktionen
durch. Diese Funktionen beinhalten:
Speicherbenennung und Projektion:
Koordiniert mit den Rechnerknoten 200, um eine einheitliche
und konsistente Benennung von Speicher bereitzustellen, indem Bilder
von auf den Speicherplatten 224 gespeicherten Speicherressourcenobjekten
zu den Rechnerknoten 200 projiziert werden;
Festplattenverwaltung:
Setzt Datenverteilungs- und Datenredundanztechniken mit den Speicherplattenlaufwerken 224,
die operativ an den ION 212 gekoppelt sind, um;
Speicherverwaltung:
Zur Handhabung der Speichereinrichtung, Datenbewegung, einschließlich der
Verarbeitung von E/A-Anforderungen
von den Rechnerknoten 200; Leistungsinstrumentation und
Ereignisverteilung.
Cache-Speicherverwaltung: Zum Lesen und
Schreiben von Daten-Cache-Speicherung, einschließlich von Cache-Speicher-Füllvorgängen, wie beispielsweise Anwendungs-Hint-Prefetch.
Verbindungsverwaltung:
Zum Steuern des Datenflusses zu und von den Rechnerknoten 200,
um die Leistung zu optimieren; steuert außerdem das Routing von Anforderungen
und somit die Verteilung von Speicher zwischen den zwei IONs 212 in
einem Dipol 226.
-
Speicherbenennung
und Projektion
-
Die
IONs 212 projizieren Bilder von auf den Speicherplatten 224 gespeicherten
Speicherressourcenobjekten zu den Rechnerknoten 200. Ein
wichtiger Teil dieser Funktion ist das Erstellen und Zuweisen von
global eindeutigen Namen, struk tureindeutigen IDs oder Volumensatzkennungen
(volume set identifiers, VSIs) 602 für jede Speicherressource (einschließlich Festplatten
der virtuellen Struktur), die vom ION 212 verwaltet werden.
-
6 ist
ein Schaubild, das die Struktur und den Inhalt der VSI 602 und
zugehöriger
Daten zeigt. Da es wichtig ist, dass die VSIs 602 eindeutig
sind und nicht übereinstimmen,
zeichnet jeder ION 212 für das Erstellen und Zuweisen
von global eindeutigen Namen für
die Speicherressourcen, die lokal von jenem ION 212 verwaltet
werden, verantwortlich und nur dem ION 212, der die Speicherressource
verwaltet, die das Speicherressourcenobjekt speichert, ist es gestattet,
dieser Speicherressource eine VSI 602 zuzuweisen. Obwohl
nur der ION 212, der derzeit die residente Speicherressource
verwaltet, eine VSI 602 erstellen und zuweisen kann, können andere
IONs 212 danach das Speichern und Abrufen dieser Speicherressourcen
verwalten. Dies liegt daran, dass die VSI 602 für ein bestimmtes
Datenobjekt sich nicht ändern
muss, wenn eine durch einen ION zugeteilte VSI 602 später in eine
Speicherressource verschoben wird, die von einem anderen ION verwaltet wird.
-
Die
VSI 602 ist als eine 64-Bit-Zahl umgesetzt, die zwei Teile
beinhaltet: eine ION-Kennung 604 und eine Sequenznummer 506.
Die ION-Kennung 604 ist eine global eindeutige Identifikationsnummer,
die jedem ION 212 zugeteilt wird. Eine Technik zum Erhalten
einer global eindeutigen ION-Kennung 604 besteht
darin, die elektronisch lesbare Hauptplatinenseriennummer zu verwenden,
die häufig
im Echtzeittakt-Chip gespeichert ist. Diese Seriennummer ist eindeutig,
da sie nur einer Hauptplatine zugeteilt wurde. Da die ION-Kennung 604 eine
global eindeutige Nummer ist, kann jeder ION 212 eine Sequenznummer 606 zuordnen,
die nur lokal eindeutig ist, und trotzdem noch eine global eindeutige
VSI 602 erstellen.
-
Nachdem
die VSI 602 an eine Speicherressource auf dem ION 212 gebunden
wurde, exportiert der ION 212 die VSI 602 durch
eine Rundrufnachricht an alle Knoten auf der Struktur, um den Zugriff
auf die Speicherressource 104 zu ermöglichen. Dieser Prozess wird
hierin im Abschnitt zum ION-Namenexport
weiter erörtet.
-
Unter
Verwendung der exportierten VSI 602 erstellt die Software
des Rechnerknotens 200 dann einen lokalen Eingangspunkt
für diese
Speicherressource, der insofern semantisch transparent ist, als
dass er von einer beliebigen anderen, lokal angeschlossenen Speichereinrichtung
nicht zu unterscheiden ist. Wenn das Betriebssystem 202 des
Rechnerknotens beispielsweise UNIX wäre, werden sowohl der Eingangspunkt
der Blockeinrichtung als auch der der Roheinrichtung im Einrichtungsverzeichnis
analog zu einer lokal angeschlossenen Einrichtung, wie beispielsweise
den Peripheriegeräten 208 oder
den Festplatten 210, erstellt. Bei anderen Betriebssystemen 202 werden ähnliche
semantische Äquivalenzen
befolgt. Bei den unter den Rechnerknoten 200 laufenden,
verschiedenen Betriebssysteme 202 wird eine Stammnamenskonsistenz
beibehalten, um die heterogene Rechenumgebung am besten zu unterstützen. Lokale
Eingangspunkte in den Rechnerknoten 200 werden durch den
ION 212 dynamisch aktualisiert, um die derzeitige Verfügbarkeit
der exportierten Speicherressourcen 104 zu verfolgen. Die
VSI 602 wird von einem vom OS abhängigen Algorithmus verwendet,
der auf dem Rechnerknoten 200 läuft, um Einrichtungseingangspunktnamen
für importierte
Speicherressourcen zu erstellen. Dieser Ansatz gewährleistet
eine Namenskonsistenz bei den Knoten, die sich ein gemeinsames Betriebssystem
teilen. Dies ermöglicht
dem System, eine Stammnamenskonsistenz beizubehalten, um durch dynamisches
(anstelle von statischem) Erstellen von lokalen Eingangspunkten
für global
benannte Speicherressourcen auf jedem Rechnerknoten 200 eine
heterogene Rechenumgebung zu unterstützen.
-
Wie
oben erörtert
werden die Einzelheiten des Erstellens der VSI 602 für die Speicherressource 104 direkt
von dem ION 212 gesteuert, der die Speicherressource 104 exportiert.
Um potentielle Unterschiede des Betriebssystems 202 unter
den Rechnerknoten 200 zu berücksichtigen, wird jeder VSI 602 ein
oder mehrere deskriptive Kopfteile zugeordnet, das/die mit der VSI 602 auf
dem ION 212 gespeichert wird/werden. Jeder Deskriptor 608 der
VSI 602 enthält
einen vom Betriebssystem (operating System, OS) abhängigen Datenabschnitt 610 zum
Speichern von genügend
vom OS 202 abhängigen.
Daten, die für
das konsistente (sowohl der Name als auch die Betriebssemantik sind über die
Rechnerknoten 200 hinweg dieselben) Erstellen von Einrichtungseingangspunkten
auf den Rechnerknoten 200 für diese bestimmte VSI 602 erforderlich
sind. Diese vom OS abhängigen
Daten 610 enthalten beispielsweise lokale Zugriffsrechte
beschreibende Daten 612 und Besitzinformationen 614.
Nachdem eine VSI 602 durch den ION 212 errichtet
und vom Rechnerknoten 200 importiert wurde, jedoch bevor
der Eingangspunkt für
diese Speicherressource 104, die der VSI 602 zugeordnet
ist, erstellt werden kann, werden die entsprechenden OS-spezifischen
Daten 610 durch den ION 212 zum Rechnerknoten 200 gesendet.
Die mehreren deskriptiven Kopfteile ermöglichen über die VSI 602 sowohl
simultane Unterstützung
mehrerer Rechnerknoten 200, die unter verschiedenen Betriebssystemen
laufen (jedes OS hat seinen eigenen Deskriptorkopfteil) als auch
die Unterstützung
von disjunkten Zugriffsrechten unter verschiedenen Gruppen von Rechnerknoten 200.
Rechnerknoten 200, die sich denselben Deskriptorkopfteil
teilen, teilen sich ein gemeinsames und konsistentes Erstellen von
Einrichtungseingangspunkten. Somit können sowohl der Name als auch
die Betriebssemantik auf allen Rechnerknoten 200, die sich
einen gemeinsamen Satz von Zugriffsrechten teilen, konsistent gehalten
werden.
-
Der
VSI-Deskriptor 608 umfasst außerdem ein Alias-Feld 616,
das zum Bieten eines von einem Menschen lesbaren Namens der VSI 602 auf
den Rechnerknoten 200 verwendet werden kann. Wenn der Alias
für die
VSI 1984 beispielsweise „soma" ist, wird der Rechnerknoten 200 sowohl
für 1984
als auch für „soma" Verzeichniseinträge aufweisen.
Da der VSI-Deskriptor 608 mit der VSI 602 auf
dem ION 212 gespeichert wird, werden auf jedem Rechnerknoten 200,
der die VSI 602 importiert, dieselben Aliasse und lokalen
Zugriffsrechte erscheinen.
-
Wie
oben beschrieben verwendet die vorliegende Erfindung einen für ein verteiltes
Zuweisungsschema geeigneten Benennungsansatz. Bei diesem Ansatz
werden Namen unter Befolgung eines Algorithmus, der globale Eindeutigkeit
gewährleistet,
lokal erzeugt. Obwohl Variationen davon einen lokal zentralisierten
Ansatz befolgen könnten,
verschieben die Anforderungen in Bezug auf Verfügbarkeit und Robustheit die
Gewichtung stark in Richtung eines rein verteilten Ansatzes. Unter
Verwendung des Vorhergehenden ist die vorliegende Erfindung in der
Lage, einen lokal ausgeführten
Algorithmus zu erstellen, der globale Eindeutigkeit gewährleistet.
-
Das
Erstellen eines global konsistenten Speichersystems erfordert mehr
Unterstützung
als einfaches Einhalten von Namenskonsistenz über die Rechnerknoten 200 hinweg.
Zusammen mit den Namen gehen die Sicherheitsprobleme einher, die
in der vorliegenden Erfindung zwei Formen annehmen. Erstens ist
das die Sicherheit der Schnittstelle zwischen den IONs 212 und
den Rechnerknoten 200; zweitens ist das die Sicherheit der
Speicherung aus dem Rechnerknoten 200 heraus.
-
Speicherauthentifizierung
und -autorisierung
-
Eine
Ressource der VSI 602 ist durch zwei verschiedene Mechanismen
geschützt,
die Authentifizierung und die Autorisierung. Wenn ein Rechnerknoten 200 vom
ION 212 authentifiziert wird, wird der VSI-Name zum Rechnerknoten 200 exportiert.
Eine exportierte VSI 602 erscheint auf dem Rechnerknoten 200 als
ein Einrichtungsname. Auf einem Rechnerknoten 200 laufende
Anwendungsthreads können
versuchen, Vorgänge auf
diesem Einrichtungsnamen durchzuführen. Die Zugriffsrechte des
Einrichtungseingangspunkts und der OS-Semantik der Rechnerknoten 200 bestimmt,
ob ein Anwendungsthread dazu autorisiert ist, eine beliebige gegebene
Autorisierung durchzuführen.
-
Dieser
Ansatz zur Autorisierung erweitert die Autorisierung des Rechnerknoten 200 auf
die Speicherressourcen 104, die an einem beliebigen Ort
angeordnet sind, auf den die Verbindungsstruktur 106 zugreifen kann.
Die vorliegende Erfindung unterscheidet sich jedoch insofern von
anderen Computerarchitekturen, dass die Speicherressourcen 104 in
der vorliegenden Erfindung nicht direkt von den Rechnerknoten 200 verwaltet werden.
Dieser Unterschied macht es unpraktisch, lokale Autorisierungsdaten
einfach mit Dateisystemeinheiten zu verbinden. Stattdessen verbindet
die vorliegende Erfindung die Autorisierungsstrategiedaten des Rechnerknotens 200 mit
der VSI 602 am ION 212 und verwendet einen Zweistufenansatz,
in dem sich der Rechnerknoten 200 und der ION 212 eine
Ebene gegenseitigen Vertrauens teilen. Ein ION 212 autorisiert
jeden Computerknoten 200 zum Zugriff auf eine spezifische
VSI 602, eine weitere Verfeinerung der Autorisierung eines
spezifischen Anwendungsthreads auf die durch die VSI bezeichneten
Daten liegt jedoch in der Verantwortung des Rechnerknotens 200.
Die Rechnerknoten 200 setzen dann die Autorisierungsstrategie
für die
Speichereinheiten 104 durch, indem sie die in den vom ION 212 gespeicherten
Autorisierungsmetadaten enthaltenen Strategien verwenden. Deshalb
müssen
die Rechnerknoten 200 dem ION 212 dahingehend
vertrauen, dass er die Metadaten bewahrt, und der ION 212 muss
dem Computerknoten 200 dahingehend vertrauen, dass dieser
die Autorisierung durchsetzt. Ein Vorteil dieses Ansatzes besteht
darin, dass er nicht erforderlich macht, dass der ION 212 Kenntnis
in Bezug darauf besitzt, wie die Metadaten zu interpretieren sind.
Somit ist der ION 212 von durchsetzender spezifischer Autorisierungssemantik
getrennt, die von verschiedenen Autorisierungssemantika auferlegt
wird, die vom von den Rechnerknoten 200 verwendeten verschiedenen
Betriebssystemen 202 auferlegt werden.
-
Alle
einer VSI 602 zugeordneten Daten (einschließlich der
Zugriffsrechte) werden auf dem ION 212 gespeichert, die
Belastung des Verwaltens des Inhalts der Zugriffsrechtsdaten wird
jedoch auf die Rechnerknoten 200 gelegt. Genauer ausgedrückt werden,
wenn die von einem ION 212 exportierte Liste der VSIs 602 an
einen Rechnerknoten 200 gesendet wird, dem jede VSI 602 zugeordnet
ist, alle OS-spezifischen Daten vom Rechnerknoten 200 benötigt, um
die lokale Autorisierung durchzusetzen. Einem unter UNIX laufenden
Rechnerknoten 200 beispielsweise würden der Name, der Gruppenname,
die Benutzer-ID und die Modusbits gesendet; Daten, die dazu ausreichen,
einen Einrichtungseingangsknoten in einem Dateisystem zu erstellen.
Alternative Namen für
eine für
diese Klasse von Rechnerknoten-Betriebssystemen 202 spezifische
(oder lediglich für
diesen Rechnerknoten 200 spezifische) VSI 602 sind
in jede VSI 602 eingebunden. Lokale OS-spezifische Befehle,
die die Zugriffsrechte einer Speichereinrichtung verändern, werden
von der Software des Rechnerknotens 200 erfasst und in
eine Nachricht umgewandelt, die an den ION 212 gesendet
wird. Diese Nachricht aktualisiert die für die OS-Version spezifischen
VSI-Zugriffsrechtsdaten.
Wenn diese Änderung
abgeschlossen wurde, überträgt der ION 212 die
Aktualisierung unter Verwendung dieses OS im System an alle Rechnerknoten 200.
-
Wenn
ein Rechnerknoten (compute node, CN) 200 online geschaltet
wird, übermittelt
er eine „Ich
bin hier"-Nachricht
an jeden ION 212. Diese Nachricht enthält eine digitale Signatur,
die den Rechnerknoten 200 identifiziert. Wenn der Rechnerknoten 200 dem
ION 212 bekannt ist (der ION 212 authentifiziert
den Rechnerknoten 200), exportiert der ION 212 jeden
VSI-Namen, für
den der Rechnerknoten 200 über Zugriffsrechte verfügt. Der
Rechnerknoten 200 verwendet diese Listen von Namen der
VSI 602 zum Errichten der lokalen Zugriffseingangspunkte
für den
Systemspeicher. Wenn eine im Rechnerknoten 200 laufende
Anwendung 204 zunächst
den lokalen Endpunkt referenziert, stellt der Rechnerknoten 200 eine
Anforderung an den ION 212, indem er eine Nachricht über die
Verbindungsstruktur 106 hinweg für die Beschreibungsdaten der
Zugriffsrechte für
diese VSI 602 übermittelt.
Die Anforderungsnachricht enthält
eine digitale Signatur für
den anfordernden Rechnerknoten 200. Der ION 212 empfängt die
Nachricht, verwendet die digitale Signatur zum Auffinden des passenden
Satzes von VSI-Zugriffsrechten, der als Antwort gesendet werden
soll, und übermittelt
diese Daten über
die Verbindungsstruktur 106 an den anfordernden Rechnerknoten 200.
Der ION 212 interpretiert die an den Rechnerknoten 200 gesendeten
Zugriffsrechte nicht, sendet jedoch einfach die Daten. Die Software
des Rechnerknotens 200 verwendet diese Daten, um den passenden
Satz von lokalen Zugriffsrechten mit dem lokalen Eingangspunkt für dieses
betreffende Speicherobjekt zu verbinden.
-
Ein
Satz von Rechnerknoten 200 kann sich denselben Satz von
Zugriffsrechten teilen, indem er entweder dieselbe digitale Signatur
verwendet oder den ION 212 mehrere digitale Signaturen
mit demselben Satz von Zugriffsrechten verbinden lässt. Die
vorliegende Erfindung verwendet die Authentifizierung sowohl zum Identifizieren
des Rechnerknotens 200 als auch zum Spezifizieren, welcher
Satz von lokalen Autorisierungsdaten zum Erstellen des lokalen Eingangspunkts
verwendet werden wird. Die Autorisierungsdaten werden nur dann zum
Rechnerknoten gezogen, wenn die VSI 602 zunächst durch
eine Anwendung referenziert wird. Dieses Modell des „Ziehens
bei Bedarf" vermeidet
die Kosten des Verschiebens großer
Mengen von Zugriffsrechtsmetadaten auf sehr großen Systemen beim Starten.
-
Wenn
ein Rechnerknoten 200 die Authentifizierung nicht besteht,
sendet der ION 212 eine Nachricht ohne Namen der VSI 602 zurück und es
wird ein Authentifizierung fehlgeschlagen-Flag gesetzt. Der Rechnerknoten 200 kann
schweigend ohne VSI-Einrichtungsnamen von diesem ION 212 fortfahren
und die fehlgeschlagene Authentifizierung je nach den Wünschen des
Systemadministrators melden. Selbst eine erfolgreiche Authentifizierung
kann natürlich
darin resultieren, dass keine Übertragung
von VSI-Einrichtungsnamen an den Rechnerknoten erfolgt.
-
Konfliktlösung beim
Starten
-
Wenn
ein ION 212 startet, versucht er, eine VSI 602 zur
Verbindungsstruktur 106 zu exportieren. In derartigen Fällen muss
die Datenintegrität
des Systems vor jeglicher Störung
durch den neuen ION 212 bewahrt werden. Um dies zu erreichen,
wird der neue ION 212 überprüft, bevor
ihm ermöglicht
wird, Speicher zu exportieren. Dies wird folgendermaßen umgesetzt:
Zunächst
untersucht der ION 212 seinen lokalen Speicher, um eine
Liste von VSI 602 zu erstellen, die er exportieren kann.
Die Metadaten der VSI 602 enthalten eine VSI-Erstellungs-
oder -Mutationsnummer. Die VSI-Mutationsnummer
wird jedes Mal erhöht,
wenn eine diese VSI 602 betreffende bedeutende Statusänderung
erfolgt (wie beispielsweise wenn eine VSI erfolgreich zu einem Netzwerk
exportiert wird). Alle Knoten, die bei der VSI-Konflikterkennung
eine Rolle spielen, einschließlich
der Rechnerknoten 200 und der ION 212, unterhalten
im Speicher eine Vorgeschichte von exportierten VSIs und deren Mutationsnummern.
Alle Knoten auf der Verbindungsstruktur 106 müssen exportierte
VSI 602 ständig
auf VSI-Konflikte überwachen.
Die VSI-Mutationsnummer wird anfangs (wenn das Speicherausmaß zum ersten
Mal erstellt wird) auf Null gesetzt. Die Mutationsnummer stellt
insofern eine Konfliktlösungsreferenz bereit,
dass von einer exportierten VSI 602 mit einer Mutationsnummer,
die niedriger ist als zum vorherigen Zeit punkt, zu dem sie exportiert
wurde, angenommen wird, dass sie eine Hochstapler-VSI ist, selbst
wenn der der echten VSI 602 zugehörige ION 212 außer Dienst
ist. Eine an einen ION 212 angehängte Hochstapler-VSI 602 mit
einer höheren
Mutantennummer als die der echten VSI 602 zugehörigen Mutantennummer
wird als die echte VSI 512 erachtet, außer wenn bereits E/A auf der
echten VSI 602 durchgeführt
wurden. Ein neu in die Verbindungsstruktur 106 eingeführter ION 212 muss
eine Mutantennummer aufweisen, die mit 0 beginnt.
-
Nachdem
der ION 212 ankündigt
hat, dass er sich dem System anschließen möchte, übermittelt er seine Liste von
VSI 602 und der zugehörigen
Mutantennummern. Alle anderen IONs 212 und alle Rechnerknoten 200 erhalten
diese Liste und überprüfen dann
die Bonität
des ION 212, die Liste der VSI 602 zu exportieren.
-
Von
anderen IONs, die derzeit dieselbe VSI 602 exportieren,
wird angenommen, dass sie gültig
sind, und diese senden dem neuen ION 512 eine Nachricht,
die den Export der einen Konflikt verursachenden spezifischen einen
oder mehreren VSI verbietet. Wenn der neue ION 512 eine
Erstellungs- oder Mutationsnummer aufweist, die höher als
die derzeit im System verwendete ist (ein Ereignis, das im gewöhnlichen
Betrieb nicht auftreten sollte, da VSI global eindeutig sind), wird
dies vermerkt und dem Systemadministrator gemeldet, der die jeweils
erforderliche Maßnahme
ergreifen wird. Wenn keine Konflikte vorliegen, wird jeder ION 212 und
jeder Rechnerknoten 200 mit einem Fortfahrvotum antworten.
Wenn die Antworten von allen IONs 212 und allen Rechnerknoten 200 empfangen
worden sind, wird die Erstellungsnummer aller VSIs 602 der
neuen IONs 212, die keinen Konflikt verursachen, erhöht und dem
System zum Exportieren zur Verfügung
gestellt.
-
Wenn
ein Rechnerknoten 200 über
eine Anwendungsreferenz und Zugriff auf eine VSI 602 verfügt, wird
der Rechnerknoten 200 die aktuelle Erstellungsnummer lokal
verfolgen. Jedes Mal, wenn ein neuer ION 212 eine VSI 602 anpreist
(zu exportieren versucht), vergleicht der Rechnerknoten 200 die
von der VSI 602 angepriesene Erstellungsnummer mit der
lokal für
diese VSI 602 gespeicherten Erstellungsnummer. Wenn die Erstellungsnummern übereinstimmen,
wird der Rechnerknoten für
das Fortfahren stimmen. Wenn die Erstellungsnummern im Widerspruch
zueinander stehen (wie es beispielsweise der Fall wäre, wenn
eine ältere
Version der VSI online geschaltet worden ist), wird der Rechnerknoten 200 eine
Verbotsnachricht senden. Die Rechnerknoten 200, die Erstellungsnummern
aufweisen, die älter
als die vom neuen ION 212 angepriesene Erstellungsnummer
für diese
VSI 602 sind, würden
für das
Fortfahren stimmen und die lokale Version der Erstellungsnummer
für diese
VSI 602 aktualisieren. Die Rechnerknoten bewahren die Erstellungsnummer
zwischen Neustarts nicht, da das grundlegende Design so gestaltet
ist, dass das System über
die Verbindungsstruktur 106 hinweg stabil ist und alle
Neulinge, einschließlich
der Rechnerknoten 200 und der IONs 212, auf Konsistenz überprüft werden.
-
Das
erste Hochfahren kann einige Situationen hervorrufen, bei denen
die Namensraumstabilität
für die VSI 602 in
Frage gestellt sein könnte.
Dieses Problem wird dadurch adressiert, dass die IONs 212 zuerst
hochgefahren werden und ihnen ermöglicht wird, mit dem Lösen von
Namenskonflikten fortzufahren, bevor die Rechnerknoten 200 sich
ihnen anschließen
dürfen.
Veraltete Versionen der VSIs 602 (aus alten Daten auf Festplattenlaufwerken
und anderen degenerativen Konditionen) können dann mittels der Erstellungsnummer aufgelöst werden.
Solange keine Rechnerknoten 200 die VSI 602 verwenden,
kann einem Neuling mit einer höheren
Erstellungsnummer ermöglicht
werden, den aktuellen Exporteur einer spezifischen VSI 602 für ungültig zu
erklären.
-
NAMENSDIENST
ION-Namen-Export
-
Ein
ION 212 exportiert den Arbeitssatz der VSIs 602,
den er exklusiv besitzt, um den Zugriff auf den zugehörigen Speicher
zu ermöglichen.
Der von einem ION 212 exportierte Arbeitssatz von VSIs
wird durch Verhandlungen über
den Besitz der VSI mit dem Buddy-ION (dem anderen ION 212 im
Dipol 226, als 214 gekennzeichnet) dynamisch bestimmt
und sollte innerhalb aller mit der Verbindungsstruktur 106 kommunizierenden
Knoten global eindeutig sein. Bei dem Satz handelt es sich in der
Regel um den Standard- oder PRIMÄR-Satz der dem ION 212 zugeordneten
VSIs 602. Die VSI-Übergabe
für Dynamischen
Lastenausgleich und Ausnahmekonditionen, die den Ausfall des Buddy-ION 214 und
den Ausfall des E/A-Pfads beinhalten, kann darin resultieren, dass
der exportierte Satz der VSI 602 sich vom PRIMÄR-Satz unterscheidet.
-
Der
Arbeitssatz von VSI wird jedes Mal vom ION 212 mittels
einer Rundrufnachricht exportiert, wenn der Arbeitssatz sich ändert, um
die Rechnerknoten 200 mit der neuesten Konfiguration der
VSI 602 auszustatten. Ein Rechnerknoten 200 kann
auch einen ION 212 nach seinem Arbeitssatz der VSI 602 befragen.
Der E/A-Zugriff auf die VSIs 602 kann von den Rechnerknoten 200 initiiert
werden, nachdem der ION 212 in den Online-Status für die exportierten
VSIs 602 eintritt oder wiedereintritt. Wie zuvor beschrieben
kann einem ION 212 nicht gestattet sin, in den Online-Status
einzutreten, wenn in den exportierten VSIs 602 etwaige
Konflikte vorliegen. Die einem „Speicherbrocken" zugeordneten VSI 602 sollten
alle eindeutig sein; es besteht jedoch die Möglichkeit, dass Konflikte auftreten
können
(beispielsweise wenn die VSI aus einer eindeutigen ID aufgebaut
wurden, die der Hardware des ION 212 zugeordnet ist, und
eine vom ION 212 verwaltete Sequenznummer und die Hardware
des ION 212 physisch bewegt wurden), wobei mehrere Speicherbrocken
dieselbe VSI aufweisen können.
-
Nachdem
der Arbeitssatz exportiert worden ist, stellt der exportierende
ION 212 einen Konfliktüberprüfungstimer
(2 Sekunden) ein, bevor er in den Online-Status eintritt,
um den E/A-Zugriff auf die exportierten VSI 602 zu ermöglichen.
Der Konfliktüberprüfungstimer
versucht, den Importeuren genug Zeit zum Ausführen der Konflikt-überprüfungsverarbeitung
zu geben und den Exporteur über
Konflikte zu zu informieren; dies kann jedoch nicht gewährleistet
werden, außer
wenn der Timer auf einen sehr hohen Wert eingestellt wird. Daher muss
ein ION 212 von allen Knoten (den Rechnerknoten 200 und
den IONs 212) eine explizite Genehmigung erhalten, um sich
offiziell online zu schalten. Die Online-Rundrufnachricht wird von
allen Knoten synchron beantwortet und das Resultat wird fusioniert
und per Rundruf zurückgesendet.
Ein ION 212 tritt offiziell in den Online-Status ein, wenn
es sich bei der fusionierten Antwort um eine ACK handelt. Wenn dem
ION 212 nicht gestattet wird, sich online zu schalten,
kann nicht auf den neu exportierten Satz der VSIs 602 zugegriffen
werden. Der/die Knoten, der/die die NAK gesendet hat/haben, sendet/senden
anschließend
außerdem
eine VSI-Konflikt-Nachricht an den Exporteur, damit dieser den Konflikt
löst. Nachdem
der Konflikt gelöst
wurde, exportiert der ION 212 seinen angepassten Arbeitssatz
und versucht erneut, sich online zu schalten.
-
CN-NAMEN-IMPORT
-
Die
Rechnerknoten 200 zeichnen dafür verantwortlich, Maßnahmen
zum Importieren aller von allen IONs 212 exportierten VSIs 504 zu
ergreifen. Während
der Verarbeitung am Tagesanfang („Start of Day") fordert ein Rechnerknoten 200 von
allen online geschalteten IONs 212 VSIs 602 an,
die zuvor exportiert wurden, so dass er eine aktuelle Ansicht des
Namensraums erhalten kann. Von diesem Punkt an horcht ein Rechnerknoten 200 nach
Exporten von VSI 602.
-
Einer
VSI 602 zugeordnete Steuerinformationen sind in einem „vsnode" enthalten, der vom
ION 212 unterhalten wird. Der Teil des Rechnerknotens 200 des
vsnode enthält
Informationen, die zum Aufbauen und Verwalten der den Anwendungen 204 dargebotenen
Namen verwendet werden. Die vsnode-Informationen enthalten Benutzerzugriffsrechte
und Namensaliasse.
-
Namensdomäne und -aliasse
-
Die
VSIs 602 können
so eingerichtet werden, dass sie einen anwendungsdefinierten Namensalias
aufweisen, der einen alternativen Namen zum Zugreifen auf den zugehörigen Speicher
bereitstellt. Die Namensaliasse können an eine virtuelle Speicherdomäne angehängt sein,
um einen Satz von Namen logisch zu unterteilen. Namensaliasse müssen innerhalb
einer virtuellen Speicherdomäne
eindeutig sein.
-
VSNODE
-
Modifikationen
am vsnode durch einen Rechnerknoten 200 werden zu dem Besitzer-ION 212 zur
sofortigen Aktualisierung und Verarbeitung gesendet. Die Änderungen
am vsnode werden dann vom ION 212 an alle Knoten weiterverbreitet,
indem er die Änderungen
exportiert und wieder in den Online-Status eintritt.
-
Speicherplattenverwaltung
-
Das
JBOD-Gehäuse 222 zeichnet
sich für
das Bereitstellen der physischen Umgebung der Festplatteneinrichtungen
sowie das Bereitstellen mehrerer Dienste für Festplatteneinrichtungen
und Gehäuseverwaltungsanwendungen
verantwortlich. Einige dieser Dienste beinhalten (1) das Benachrichtigen über das
Versagen von Komponenten (Stromversorgung, Gebläse, usw.); (2) das Benachrichtigen über Grenzwerte
(Temperatur und Spannung); (3) das Aktivieren und Deaktivieren von
Fehler- und Status-LEDs; (4) das Aktivieren und Deaktivieren von
hörbaren
Alarmsignalen; (5) das Einstellen von Einrichtungs-IDs für Festplatteneinrichtungen.
-
In
der Vergangenheit waren Verwaltungsanwendungen in der Regel über eine
bandexterne Verbindung mit Gehäusen
verbunden. Ein serieller oder Ethernet-Anhang an das entfernte Gehäuse in Kombination mit
der Verwendung von Protokollen wie dem einfachen Netzwerkverwaltungsprotokoll
(simple network management protocol, SNMP) ermöglichten das Empfangen von
Statusinformationen, die das Befinden eines Gehäuses betrafen. In der vorliegenden
Erfindung können
sich Festplattengehäuse
vom Host-System physisch entfernt befinden, so dass es es nicht
praktisch ist, die Gehäusekonfiguration
und den Gehäusestatus über eine
direkte Verbindung, wie beispielsweise einen separaten seriellen
Pfad, zu überwachen.
Um zusätzliche Verkabelung
zu vermeiden, verwendet die vorliegende Erfindung eine bandinterne
Verbindung, die für
das Überwachen
des Gehäusestatus
und das Regeln der Gehäusekonfiguration über die
normale bestehende Fibre Channel-Schleife sorgt.
-
Die
bandinterne Verbindung verwendet einen Satz von vom Host stammenden
SCSI-Befehlen, die an eine SCSI-Einrichtung zum Abfragen und Regeln
des Konfigurationsstatus gesendet werden, und einen Mechanismus
für eine
Einrichtung, um diese Informationen dem Gehäuse selbst zu vermitteln. Der
Teil des Protokolls zwischen dem Host und den Festplattenlaufwerken
ist in der SCSI-3-Gehäusedienst-spezifikation
(SCSI-3 Enclosure Services, SES) ausführlich dargestellt, die hiermit
durch Bezugnahme einbezogen wird.
-
Drei
SCSI-Befehle werden zum Umsetzen der SES-Schnittstelle verwendet:
ABFRAGEN, DIAGNOSE SENDEN und DIAGNOSEERGEBNISSE EMPFANGEN. Der
ABFRAGEN-Befehl spezifiziert, ob die spezi fische Einrichtung entweder
eine Gehäusediensteinrichtung
oder eine Einrichtung, die SES-Befehle zu einem Gehäusedienstprozess
transportieren kann, ist. Die DIAGNOSE SENDEN und DIAGNOSEERGEBNISSE EMPFANGEN
werden zum Regeln bzw. Empfangen von Statusinformationen von Gehäuseelementen
verwendet.
-
Beim
Verwenden des Befehls DIAGNOSE SENDEN oder des Befehls DIAGNOSEERGEBNISSE EMPFANGEN
muss ein Seitencode spezifiziert werden. Der Seitencode spezifiert,
welcher Status- oder
Informationstyp angefordert wird. Der vollständige Satz von definierten
SES-Seiten, der mittels des Befehls DIAGNOSE SENDEN und des Befehls
DIAGNOSEERGEBNISSE EMPFANGEN angefordert werden kann, ist in der
folgenden Tabelle VII ausführlich
dargestellt. Die fettgedruckten Einträge werden von der SES-Ereignisüberwachung
benötigt.
-
-
Der
Anwendungs-Client kann das Gehäuse
regelmäßig abfragen,
indem er einen DIAGNOSEERGEBNISSE LESEN-Befehl mit einer Mindestzuteilungslänge von
mehr als 1 ausführt,
der eine Gehäusestatusseite anfordert.
Die in dem 1 Byte zurückgesendete
Information enthält
5 Bits, die den Status des Gehäuses
zusammenfassen. Wenn eines dieser Bits gesetzt ist, kann der Anwendungs-Client
den Befehl erneut mit einer größeren Zuteilungslänge ausgeben,
um den kompletten Status zu erhalten.
-
ION-Gehäuseverwaltung
-
7 zeigt
die Beziehungen zwischen den Gehäuseverwaltungsmodulen
der ION und der Architektur des physischen ION-Festplattentreibers 500.
Dieses Untersystem setzt sich aus zwei Komponenten zusammen – der SES-Ereignisüberwachung 702 und
der SCC2+-zu-SES-Packung 704. Die SES-Ereignisüberwachung 702 zeichnet
sich für
das Überwachen
aller angehängten
Gehäusedienstprozesse
und beim Ereignis einer Statusänderung
für das
Melden dieser mittels eines Ereignisprotokollieruntersystems verantwortlich.
Diese Meldung kann gegebenenfalls zu einer Verwaltungs-dienstschicht 706 weitergeleitet
werden. Die Komponente SCC2+-zu-SES-Packung 704 zeichnet
sich für
das Übersetzen
von SCC2+-Befehlen,
die von Konfigurations- und Verwaltungsanwendungen kommen, und das Übersetzen
dieser in einen oder mehrere SES-Befehle zum Gehäusedienstprozess verantwortlich.
Dadurch wird bewirkt, dass der Anwendungs-Client nicht mehr die
Besonderheiten der JBOD-Konfiguration kennen braucht.
-
SES-Ereignisüberwachung
-
Die
SES-Ereignisüberwachung 702 meldet
Dienstprozessstatusänderungen
des Gehäuses 222 zur Verwaltungsdienstschicht 706 zurück. Die
Statusinformation wird mittels eines Ereignisprotokollieruntersystems
gemeldet. Die SES-Ereignisüber wachung 702 fragt
jeden Gehäuseprozess
regelmäßig ab,
indem er einen DIAGNOSEERGEBNISSE LESEN-Befehl ausführt, der
die Gehäusestatusseite
anfordert. Der DIAGNOSEERGEBNISSE LESEN-Befehl wird mittels der vom physischen
ION-Einrichtungsfestplattentreiber 500 bereitgestellten
SCSILib-Schnittstelle 514 gesendet. Statuszustände, die
gemeldet werden können,
beinhalten Statuselemente, die in der folgenden Tabelle VIII aufgeführt sind.
-
-
Tabelle
VIII: Gehäusestatuswerte
-
Wenn
die SES-Ereignisüberwachung 702 startet,
liest sie den Status für
jedes im Gehäuse
enthaltene Element 402 – 424 aus. Dieser
Status ist der Aktuelle Status. Wenn eine Statusänderung erkannt wird, wird jeder
Status, der sich vom Aktuellen Status geändert hat, zur Verwaltungsdienstschicht 706 zurückgemeldet. Dieser
neue Status ist nun der Aktuelle Status. Wenn der aktuelle Status
für ein
Gebläseelement
beispielsweise „OK" ist und eine Statusänderung
das Element nun als „Gebläseversagen" meldet, wird ein
Ereignis gemeldet, das ein Gebläseversagen
spezifiziert. Wenn eine andere Statusänderung nun spezifiziert, dass
das Element „Nicht
installiert" ist,
wird ein anderes Ereignis gemeldet, das spezifiziert, dass das Gebläse vom Gehäuse entfernt
worden ist. Wenn eine andere Statusänderung spezifiziert, dass
das Gebläseelement „OK" ist, wird hin anderes
Ereignis erstellt, das spezifiziert, dass ein Gebläse im Betrieb
eingesteckt worden ist und ordnungsgemäß arbeitet.
-
"Start of Day"-Handhabung
-
Die
SES-Ereignisüberwachung 702 wird
nach der erfolgreichen Initialisierung des physischen ION-Festplattentreibers 500 gestartet.
Nach dem Starten liest die SES-Ereignisüberwachung 702 das
JBOD- und SCSI-Konfigurationsmodul 516, um die Korrelation
der Festplatteneinrichtungen und der Gehäusediensteinrichtungen zu finden
und wie die Einrichtungen adressiert werden. Als Nächstes wird
der Status jeder Gehäusestatuseinrichtung
gelesen. Dann werden Ereignisse für alle Fehlerkonditionen und
fehlenden Elemente erstellt. Wenn diese Schritte abgeschlossen wurden,
ist der Status dann der Aktuelle Status und die Abfrage beginnt.
-
SCC2+-zu-SES-Packung
-
Bei
SCC2+ handelt es sich um das vom ION 212 zum Konfigurieren
und Verwalten virtueller und physischer Einrichtungen verwendete
Protokoll. Das Pluszeichen „+" in SCC2+ steht für die Additionen
zum SCC2, die eine vollständige
Handhabbarkeit der Einrichtungen und Komponenten des ION 212 und
ein konsistentes Mapping von durch SCC2 definierten Befehlen auf
SES ermöglichen.
-
Die
Dienstschicht 706 adressiert die Elemente des JBOD-Gehäuses 222 über die
Befehle SCC2-WARTUNG EIN und SCC2-WARTUNG AUS. Die folgenden Abschnitte
beschreiben die Dienstaktionen, die den Mechanismus zum Konfigurieren,
Steuern und Berichten des Status der Komponenten bereitstellen. Jeder
dieser Befehle wird auf dem ION 212 als eine Reihe von
DIAGNOSE SENDEN- und DIAGNOSEERGEBNISSE EMPFANGEN-SCSI-Befehlen
umgesetzt.
-
Das
Konfigurieren von Komponenten wird unter Verwendung der folgenden
Dienstaktionen durchgeführt.
-
KOMPONENTENEINRICHTUNG
HINZUFÜGEN – Der KOMPONENTENEINRICHTUNG
HINZUFÜGEN-Befehl
wird zum Einrichten von Komponenteneinrichtungen in dem System und
zum Definieren von deren LUN-Adressen verwendet. Die LUN-Adresse
wird vom ION 212 auf Grundlage der Position der Komponente
in der SES-Konfigurationsseite
zugeordnet. Die KOMPONENTENEINRICHTUNG MELDEN-Dienstaktion wird
unter Befolgung dieses Befehls durchgeführt, um die Ergebnisse der
LUN-Zuordnungen zu erhalten.
-
KOMPONENTENEINRICHTUNG
MELDEN – Bei
der Dienstaktion KOMPONENTENEINRICHTUNGSSTATUS MELDEN handelt es
sich um einen anbietereindeutigen Befehl, der vollständige Statusinformationen
zu einer Komponenteneinrichtung abrufen soll. SES stellt für jeden
Elementtyp vier Status-Byte bereit. Dieser neue Befehl ist erforderlich,
da die Dienstaktionen ZUSTÄNDE
MELDEN und KOMPONENTENEINRICHTUNG MELDEN für die Statusinformationen nur
einen Byte zuteilen und die definierten Statuscodes mit den vom
SES-Standard definierten im Widerspruch stehen.
-
KOMPONENTENEINRICHTUNG
ANHÄNGEN – Die Dienstaktion
KOMPONENTENEINRICHTUNG ANHÄNGEN
fordert an, dass eine oder mehrere logische Einheiten logisch an
die spezifizierte Komponenteneinrichtung angehängt werden. Dieser Befehl kann
zum Bilden von logischen Verbindungen zwischen Volumensätzen und
den Komponenteneinrichtungen, von denen sie abhängig sind, wie beispielsweise
Gebläsen, Stromversorgungen,
usw., verwendet werden.
-
KOMPONENTENEINRICHTUNG
AUSTAUSCHEN – Die
Dienstaktion KOMPONENTENEINRICHTUNG AUSTAUSCHEN fordert an, dass
eine Komponenteneinrichtung durch eine andere ausgetauscht wird.
-
KOMPONENTENEINRICHTUNG
ENTFERNEN – Die
Dienstaktion PERIPHERIEEINRICHTUNG ENTFERNEN/KOMPONENTENEINRICHTUNG
ENTFERNEN fordert an, dass eine Peripherieeinrichtung oder eine
Komponenteneinrichtung aus der Systemkonfiguration entfernt wird.
Wenn eine Komponenteneinrichtung entfernt wird, an die logische
Einheiten angehängt
sind, wird der Befehl mit einem KONDITION ÜBERPRÜFEN abgebrochen. Der Erfassungsschlüssel wird
ILLEGALE ANFORDERUNG sein, mit einem zusätzlichen Erfassungsvermerk
ENTFERNEN VON LOGISCHER EINHEIT FEHLGESCHLAGEN.
-
Statusinformationen
und andere Informationen zu einer Komponente können über die folgenden Dienstaktionen
erhalten werden:
KOMPONENTENSTATUS MELDEN – Bei der Dienstaktion KOMPONENTENEINRICHTUNGSSTATUS
MELDEN handelt es sich um einen anbietereindeutigen Befehl, der
vollständige
Statusinforma tionen zu einer Komponenteneinrichtung abrufen soll.
SES stellt für
jeden Elementtyp vier Status-Byte bereit. Die Dienstaktionen ZUSTÄNDE MELDEN
und KOMPONENTENEINRICHTUNG MELDEN teilen für die Statusinformationen nur einen
Byte zu und die definierten Statuscodes stehen mit den vom SES-Standard definierten
im Widerspruch. Daher ist dieser neue Befehl erforderlich.
-
ZUSTÄNDE MELDEN – Die Dienstaktion
ZUSTÄNDE
MELDEN fordert Statusinformationen über die ausgewählten logischen
Einheiten an. Eine Liste von einem oder mehreren Zuständen für jede logische
Einheit wird zurückgesendet
werden.
-
KOMPONENTENEINRICHTUNG
MELDEN – Die
Dienstaktion KOMPONENTENEINRICHTUNG MELDEN fordert eine/mehrere
Komponenteneinrichtung/en innerhalb des JBOD betreffende Informationen an.
Es wird eine geordnete Liste von LUN-Deskriptoren zurückgesendet,
die die LUN-Adresse, den Komponententyp und den Gesamtstatus meldet.
Dieser Befehl wird als Teil des anfänglichen Konfigurationsprozesses
zum Bestimmen der durch die Dienstaktion KOMPONENTENEINRICHTUNG
HINZUFÜGEN
zugeordneten LUN-Adresse verwendet.
-
KOMPONENTENEINRICHTUNGSANHÄNGE MELDEN – Die Dienstaktion
KOMPONENTENEINRICHTUNGSANHÄNGE
MELDEN fordert Informationen an, die an die spezifizierte/n Komponenteneinrichtung/en
angehängte
logische Einheiten betreffen. Es wird eine Liste von Komponenteneinrichtungsdeskriptoren
zurückgesendet,
von denen jede eine Liste von LUN-Deskriptoren enthält. Die
LUN-Deskriptoren spezifizieren den Typ und die LUN-Adresse für jede an
die entsprechende Komponente angehängte logische Einheit.
-
KOMPONENTENEINRICHTUNGSKENNUNG
MELDEN – Die
Dienstaktion KOMPONENTENEINRICHTUNGSKENNUNG MELDEN fordert den Ort
der spezifizierten Komponenteneinrichtung an. Es wird ein ASCII-Wert
zurückgesendet,
der die Position der Komponente anzeigt. Dieser Wert muss zuvor
von der Dienstaktion KOMPONENTENEINRICHTUNGSKENNUNG EINSTELLEN eingestellt
worden sein.
-
Die
Verwaltung von Komponenten wird über
die folgenden Aktionen durchgeführt:
KOMPONENTENEINRICHTUNG
INSTRUIEREN – Der
Befehl KOMPONENTENEINRICHTUNG INSTRUIEREN wird zum Senden von Steuerinstruktionen,
wie beispielsweise Ein- oder Ausschalten, an eine Komponenteneinrichtung
verwendet. Die Aktionen, die auf eine bestimmte Einrichtung angewendet
werden können,
variieren je nach Komponententyp und sind anbieterspezifisch.
-
KOMPONENTENEINRICHTUNG
ABBRECHEN – Die
Dienstaktion KOMPONENTENEINRICHTUNG ABBRECHEN platziert die spezifizierte/n
Komponente/n in den abgebrochenen (ausgefallenen) Zustand.
-
VERBINDUNGSSTRUKTUR Überblick
-
Da
das an eine Struktur angehängte
Speichermodell der vorliegenden Erfindung mehr Datenbewegung ermöglicht,
muss es sich mit den Bedenken in Bezug auf die E/A-Leistung aufgrund
von Datenkopien und Interrupt-Verarbeitungskosten befassen. Datenkopie-,
Interrupt- und Flusssteuerungsprobleme werden in der vorliegenden
Erfindung durch eine einzigartige Kombination von Verfahren angegangen.
Im Gegensatz zum von den meisten Netzwerken verwendeten Modell der
zielortbasierten Adressierung verwendet die vorliegende Erfindung
ein Modell der senderbasierten Adressierung, bei dem der Sender
den Zielpuffer auf dem Zielort auswählt, bevor die Daten über die
Struktur übermittelt
werden. In einem senderbasierten Modell übermittelt der Zielort dem
Sender eine Liste von Zielortadressen, an die Nachrichten gesendet
werden können, bevor
die Nachrichten gesendet werden. Um eine Nachricht zu senden, muss
der Sender zunächst
aus dieser Liste einen Zielortpuffer auswählen. Dies ist möglich, da
die zielseitige Anwendung dem OS bereits die Adressen für diese
Puffer zur Verwendung durch die Hardware des Zielnetzwerks gegeben
hat und der Netzwerkhardware daher genügend Informationen gegeben
werden, um die Daten mittels eines DMA-Vorgangs ohne eine Kopie
direkt in den korrekten Zielpuffer zu übertragen.
-
Obwohl
die senderbasierte Adressierung in mancher Hinsicht vorteilhaft
ist, hängen
mit dieser mehrere Probleme zusammen. Erstens erweitert die senderbasierte
Adressierung die Schutzdomäne
vom Zielort aus über
die Struktur hinweg, um den Sender einzubinden, wodurch ein allgemeiner
Mangel an Trennung erzeugt wird und Bedenken in Bezug auf die Datensicherheit
und Integrität
an den Tag treten. Eine reine senderbasierte Adressierung gibt Speicheradressen
an den Sender ab, was erforderlich macht, dass der Zielort dem Sender vertraut,
ein großes
Problem in einem System mit hoher Verfügbarkeit. Man nehme beispielsweise
den Fall an, dass der Zielortknoten dem Sender eine Liste von Zielortadressen
gegeben hat. Bevor der Sender all diese Adressen verwendet, stürzt der
Zielortknoten ab und startet dann neu. Die Sendeseite weist nun
einen Satz von Adresspuffern auf, die nicht länger gültig sind. Der Zielort verwendet
diese Adressen möglicherweise
für einen
anderen Zweck. Eine zu einem beliebigen dieser gesendete Nachricht
könnte
schwerwiegende Konsequenzen nach sich ziehen, da kritische Daten
am Zielort zerstört
werden könnten.
-
Zweitens
macht das Umsetzen einer senderbasierten Adressierung die Kooperation
des Netzwerks erforderlich, insofern dass dieses die Zielortadresse
aus der Nachricht extrahiert, bevor sie die DMA der Daten initiieren
kann; die meisten Netzwerkschnittstellen sind nicht für einen
derartigen Betrieb konzipiert.
-
Es
wird daher ein Adressiermodell benötigt, dass die Vorteile eines
senderbasierten Modells umfasst, jedoch die Probleme umgeht. Die
vorliegende Erfindung löst
dieses Problem mit einem Hybrid-Adressiermodell mit einem eindeutigen
PIT-Protokoll (PIT = put it there, leg es dort ab), das eine auf
dem BYNET basierende Verbindungsstruktur verwendet.
-
BYNET und
die BYNET-Schnittstelle
-
BYNET
weist drei wichtige Attribute auf, die beim Umsetzen der vorliegenden
Erfindung von Nutzen sind.
-
Erstens
ist BYNET inhärent
skalierbar – zusätzliche
Konnektivität
oder Bandbreite kann problemlos eingeführt werden und steht allen
Einheiten im System sofort zur Verfügung. Dies steht im Kontrast
zu anderen, auf den Bus ausgerichteten Verbindungstechnologien,
die keine Bandbreite als Ergebnis des Hinzufügens von Verbindungen hinzufügen. Beim
Vergleich mit anderen Verbindungen skaliert BYNET nicht nur im Hinblick auf
fan-out (die Anzahl der in einer einzigen Struktur verfügbaren Anschlüsse), sondern
weist außerdem
eine Bisektionsbandbreite auf, die mit fan-out skaliert.
-
Zweitens
kann BYNET durch Software zu einer aktiven Nachricht-Verbindung
verstärkt
werden – unter den
Anweisungen seiner Benutzer (d. h. der Rechnerressourcen 102 und
der Speicherressourcen 104) kann es Daten zwischen Knoten
bei minimaler Störung
von deren Vorgängen
verschieben. Es verwendet DMA, um Daten direkt zu vorbestimmten
Speicheradressen zu verschieben, wodurch unnötige Interupts und internes Datenkopieren
vermieden wird. Diese grundlegende Technik kann erweitert werden,
um das Verschieben kleiner Datenblöcke zu optimieren, indem diese
in eine größere Verbindungsnachricht
gemultiplext werden. Jeder einzelne Datenblock kann unter Verwendung
einer Modifikation der DMA-basierten Technik verarbeitet werden,
wobei die Vortei le der Knotenbetriebseffizienz beibehalten werden
und gleichzeitig die Verbindungsverwendung optimiert wird.
-
Drittens
ist es, da das BYNET auf das Bereitstellen mehrerer Strukturen eingerichtet
werden kann, möglich,
unter Verwendung von Verkehrsgestaltung für weitere Verbindungsoptimierung
zu sorgen. Dabei handelt es sich im Wesentlichen um einen von der
BYNET-Software bereitgestellten Mechanismus, um bestimmten Verbindungskanälen (Strukturen)
bestimmte Verkehrsarten zuzuweisen, beispielsweise dem Vermindern der
Interferenzen, die zufällige
Kombinationen von langen und kurzen Nachrichten in stark verwendeten
geteilten Kanälen
erzeugen können.
Die Verkehrsgestaltung wird vom BYNET aktiviert und kann für vorhersagbare
Verkehrsmuster vom Benutzer auswählbar
sein.
-
8 zeigt
ein Schaubild des BYNET und seiner hostseitigen Schnittstelle 802.
Die hostseitige BYNET-Schnittstelle 802 enthält einen
Prozessor 804, der jedes Mal Kanalprogramme ausführt, wenn
ein Kreislauf erstellt wird. Die Kanalprogramme werden von diesem
Prozessor 804 sowohl an der Sende-Schnittstelle 806 als
auch der Zielort-Schnittstelle 808 für jeden
Knoten ausgeführt.
Die Hardware der sendeseitigen Schnittstelle 806 führt ein
Kanalprogramm aus, das am Downcall erstellt wurde, der die Erstellung
des Kreislaufs, die Übermittlung
der Daten und das schlußendliche
Herunterfahren des Kreislaufs steuert. Die Hardware der zielortseitigen
Schnittstelle 808 führt
ein Kanalprogramm aus, um die Daten in den Speicher am Zielort abzugeben
und dann den Kreislauf abzuschließen.
-
Das
BYNET umfasst ein Netzwerk zum Verbinden der Rechnerknoten 200 und
der IONs 212, die im Netzwerk als Prozessoren arbeiten.
Das BYNET umfasst mehrere Schaltungsknoten 810 mit Eingangs-/Ausgangsanschlüssen 814.
Die Schaltungsknoten 810 sind in mehr als g(logbN) Schaltungsknotenstufen 812 angeordnet,
wobei b die Gesamtanzahl der Eingangs-/Aus gangsanschlüsse der
Schaltungsknoten, N die Gesamtanzahl der Eingangs-/Ausgangsanschlüsse des
Netzwerks 816 und g(x) eine Dachfunktion ist, die die kleinste
ganze Zahl bereitstellt, die nicht größer als das Argument x ist.
Die Schaltungsknoten 810 stellen somit mehrere Pfade zwischen
einem beliebigen Netzwerkeingangsanschluss 816 und einem
beliebigen Netzwerkausgangsanschluss 816 bereit, um die
Fehlertoleranz zu verstärken
und die Konkurrenzsituation zu vermindern. Das BYNET umfasst außerdem mehrere
Bounceback-Punkte in der Bounceback-Ebene 818 entlang der höchsten Schaltungsknotenstufe
des Netzwerks zum Steuern der Übermittlung
der Nachrichten durch das Netzwerk hindurch. Die Bounceback-Punkte
unterscheiden logisch zwischen den Schaltungsknoten 810,
die Ausgleichsnachrichten durch das Netzwerk von den Schaltungsknoten 810 laden,
die Nachrichten zu empfangenden Prozessoren steuern.
-
In
Knoten, wie beispielsweise dem Rechnerknoten 200 und dem
ION 212, umgesetzte Prozessoren können in ein oder mehrere Supercluster
aufgeteilt sein, die logisch unabhängige vordefinierte Teilsätze von Prozessoren
umfassen. Kommunikationen zwischen Prozessoren können Punkt-zu-Punkt oder ein
Gruppenruf sein. Im Gruppenruf-Kommunikationsmodus kann ein einziger
Prozessor eine Nachricht an alle anderen Prozessoren oder an Supercluster
rundsenden. Gruppenruf-Befehle
in verschiedenen Superclustern können gleichzeitig
erfolgen. Der sendende Prozessor übermittelt seinen Gruppenruf-Befehl,
der sich durch den Vorwärtskanal
an alle Prozessoren oder die Gruppe von Prozessoren weiterverbreitet.
Gruppenruf-Nachrichten werden zum anschließenden Routing zu den Prozessoren
im Supercluster zu einem bestimmten Bounceback-Punkt in einer Bounceback-Ebene
818 im Netzwerk gesteuert. Dies verhindert den Stillstand des Netzwerks,
da es jeweils nur eine Gruppenruf-Nachricht durch den bestimmten
Bounceback-Punkt zulässt
und verhindert, dass Gruppenruf-Nachrichten an verschiedene Supercluster
einander stören.
Die Prozessoren, die die Gruppen ruf-Nachrichten empfangen, antworten
auf diese, indem sie beispielsweise ihren aktuellen Status durch
den Rückkanal übertragen.
Das BYNET kann so arbeiten, dass die Antworten auf verschiedene
Weisen kombiniert werden.
-
BYNET
unterstützt
derzeit zwei grundlegende Nachrichtentypen, eine bandinterne Nachricht
und eine bandexterne Nachricht. Eine bandinterne BYNET-Nachricht
liefert die Nachricht in einen Kernelpuffer (oder mehrere Kernelpuffer)
am Speicher des Zielorthosts, schließt den Kreislauf ab und schickt
einen Upcall-Interrupt ab. Bei einer bandexternen BYNET-Nachricht
bewirken die Kopfteildaten in einer Kreislaufnachricht, dass das
Interrupt-Steuerungsprogramm im BYNET-Treiber das Kanalprogramm
erstellt, das zum Verarbeiten des Rests der empfangenen Kreislaufdaten
verwendet wird. Bei beiden Nachrichtentypen wird der Erfolg oder
das Fehlschlagen eines Kanalprogramms mittels einer kleinen Nachricht
auf dem BYNET-Rückkanal
an den Sender zurückgeleitet.
Diese Rückkanalnachricht
wird vom Kanalprogramm am Sender als Teil des Kreislaufherunterfahrvorgangs
verarbeitet. (Der Rückkanal
ist der Rückleitungspfad
geringer Bandbreite in einem BYNET-Kreislauf.) Nachdem der Kreislauf
heruntergefahren wurde, wird (optional) ein Upcall-Interrupt am
Zielort abgeschickt, um das Eintreffen einer neuen Nachricht zu
signalisieren.
-
Die
Verwendung von bandexternen BYNET-Nachrichten ist keine optimale
Konfiguration, da die Sendeseite darauf wartet, dass das Kanalprogramm
zunächst
erstellt und dann ausgeführt
wird. Bandinterne BYNET-Nachrichten ermöglichen dem Sender nicht, direkt
auf die Anwendungspuffer abzuzielen, und machen daher eine Datenkopie
erforderlich. Um dieses Problem zu lösen, verwendet die vorliegende
Erfindung die BYNET-Hardware auf eine einzigartige Weise. Anstatt
die zielortseitige Schnittstelle 808 das Kanalprogramm
erstellen zu lassen, das sie zum Verarbeiten der Daten benötigt, erstellt
die sendeseitige Schnittstelle 806 sowohl das sendeseitige
als auch das zielortseitige Kanalprogramm. Das sendeseitige Kanalprogramm überträgt ein sehr
kleines Kanalprogramm als Teil der Nachricht, das die Zielortseite
ausführen
wird. Dieses Kanalprogramm beschreibt, wie die Zielortseite die
Daten in den spezifizierten Zielortpuffer des Zielanwendungsthreads
zu verschieben hat. Da der Sender den Zielortthread kennt, an den
diese Nachricht geliefert werden soll, ermöglicht diese Technik der Sendeseite,
sowohl das Wie als auch das Wohin der Lieferung einer Nachricht
zu steuern, wodurch der Großteil
des Traumas der herkömmlichen
Upcall-Verarbeitung auf der Zielortseite vermieden wird. Diese Form
von BYNET-Nachrichten wird als bandgesteuerte Nachricht bezeichnet.
Im Gegensatz zu einer in der aktiven Nachricht verwendeten aktiven
Nachricht, dem Interprozesskommunikationsmodell, das die Daten und
eine kleine Nachrichthandhabungsroutine, die zum Verarbeiten der
Nachricht am Zielort verwendet wird, enthält, verwendet die vorliegenden
Erfindung bandgesteuerte BYNET-Nachrichten, indem der BYNET-E/A-Prozessor
das einfache Kanalprogramm ausführt,
während
bei aktiven Nachrichten die Host-CPU für gewöhnlich das Steuerungsprogramm
für aktive
Nachrichten ausführt.
-
Die
Verwendung des Rückkanals
ermöglicht
der sendeseitigen Schnittstelle, das herkömmliche Interrupt-Verfahren
zum Signalisieren des Nachrichtenlieferungsabschlusses zu unterdrücken. Sowohl
bei bandexternen als auch bandgesteuerten Nachrichten zeigt ein
Hinweis auf einen erfolgreichen Abschluss an der Sendeseite lediglich
an, dass die Nachricht auf zuverlässige Weise in den Speicher
des Zielorts geliefert worden ist.
-
Obwohl
dies das zuverlässige
Verschieben einer Nachricht in den Speicherplatz am Zielortknoten
gewährleistet,
gewährleistet
es nicht die Verarbeitung der Nachricht durch die Zielortanwendung.
Ein Zielortknoten könnte
beispielsweise ein funktionelles Speichersystem haben, jedoch einen
Fehler im Zielortanwendungsthread aufweisen, der verhindern könnte, dass
die Nachricht jemals verarbeitet wird. Um die zuverlässige Verarbeitung
von Nachrichten in der vorliegenden Erfindung handzuhaben, werden
mehrere Verfahren unabhängig
voneinander sowohl zum Erkennen als auch zum Korrigieren von Fehlern
in der Nachrichtenverarbeitung eingesetzt. In Hinsicht auf das Kommunikationsprotokoll
für die
vorliegende Erfindung werden an der Sendeseite Zeitsperren verwendet,
um verlorene Nachrichten aufzufinden. Je nach Bedarf erfolgt eine
erneute Übermittlung,
die Wiederherstellungsvorgänge
auslösen
kann, wenn Software- oder Hardwarefehler erkannt werden.
-
Selbst
bei bandgesteuerten Nachrichten muss die vorliegende Erfindung die
Nachrichtenlieferung an ein spezifisches Ziel am Zielort und einen
Mechanismus, der dem Sender genügend
Daten gibt, um eine Nachricht zum richtigen Zielanwendungsthreadpuffer
zu senden, ermöglichen.
Die vorliegende Erfindung vollbringt diese Leistung mit einem Schema
ticketbasierter Authentifizierung. Ein Ticket ist eine Datenstruktur,
die nicht gefälscht
werden kann und dem Inhaber Rechte erteilt. Im Wesentlichen sind
Tickets Einfachgenehmigungen bzw. -rechte zur Verwendung bestimmter
Ressourcen. In der vorliegenden Erfindung können die IONs 212 die Dienstverteilung
an die Rechnerknoten 200 durch Ticketverteilung steuern.
Darüber
hinaus spezifizieren die Tickets ein spezifisches Ziel, was beim
Umsetzen eines senderbasierten Flusssteuerungsmodell eine notwendige
Voraussetzung ist.
-
Das PIT-Protokoll
-
- (PIT = put it there, leg es dort ab)
-
Überblick
-
Das
PIT-Protokoll ist ein Schema ticketbasierter Authentifizierung,
in dem das Ticket und die Datennutzlast unter Verwendung des Protokolls
der bandgesteuerten BYNET-Nachricht in einer aktiven Nachricht übermittelt
werden. Das PIT-Protokoll ist eine einzigartige Mischung aus ticketbasierter
Authentifizierung, senderbasierter Adressierung, Lastschrift/Gutschrift-Flusssteuerung,
Nullspeicherkopie und aktiven Nachrichten.
-
PIT-Nachrichten
-
9 zeigt
die grundlegenden Merkmale einer PIT-Nachricht bzw. eines PIT-Pakets 901,
die/das einen PIT-Kopfteil 902, gefolgt von Nutzlastdaten 904 enthält. Der
PIT-Kopfteil 902 umfasst eine PIT-ID 906, die eine
Abstraktion des Zieldatenpuffers darstellt und ein Ticket mit begrenzter
Lebensdauer ist, das Zugriffsrechte auf einen angehefteten Puffer
eines spezifizierten Umfangs darstellt. Elemente, die die PIT-ID 906 besitzen, sind
jene, die das Recht zur Verwendung des Puffers haben, und eine PIT-ID
muss preisgegeben werden, wenn der PIT-Puffer verwendet wird. Wenn
ein Zielort eine PIT-Nachricht empfängt, spezifiziert die PIT-ID 906 im
PIT-Kopfteil der BYNET-Hardware den Zielpuffer, wohin die Nutzlast
mittels eines DMA-Vorgangs zu verschieben ist.
-
Bei
der Flusssteuerung unter dem PIT-Protokoll handelt es sich um ein
Lastschrift/Gutschrift-Modell mit senderbasierter Adressierung.
Wenn eine PIT-Nachricht gesendet wurde, stellt sie für den Sender
eine Flusssteuerungslastschrift und für den Zielort eine Flusssteuerungsgutschrift
dar. Anders ausgedrückt
wird, wenn eine Einrichtung eine PIT-ID 906 an einen Thread
sendet, diesem Thread im Adressraum ein PIT-Puffer gutgeschrieben.
Wenn die Einrichtung eine PIT-ID 906 zu ihrem Sender zurücksendet,
gibt die Einrichtung entweder ihre Rechte auf oder gibt den von
der PIT-ID 906 spezifizierten Puffer frei. Wenn eine Einrichtung
eine Nachricht an einen von der PIT-ID 906 abstrahierten
Zielortpuffer sendet, gibt die Einrichtung ebenfalls ihre Rechte
am PIT-Puffer auf. Wenn eine Einrichtung eine PIT-ID 906 empfängt, bedeutet
dies eine Gutschrift für einen
PIT-Puffer im Adressraum des Senders (außer wenn die zurückgesendete
PIT-ID 906 die PIT-ID 906 der Einrichtung ist).
-
An
der Oberseite des Kopfteils 902 befindet sich das BYNET-Kanalprogramm 908 (Sendeseite
und Zielortseite), das das PIT-Paket 901 verarbeiten wird.
Als Nächstes
folgen zwei Felder zum Übermitteln
von PIT-ID-Tickets: das Gutschriftenfeld 910 und das Lastschriftenfeld 912.
Das Lastschriftenfeld 912 enthält eine PIT-ID 906,
wobei die Nutzlastdaten von der Zielortnetzwerkschnittstelle mittels
des Kanalprogramms übertragen
werden. Es wird Lastschriftenfeld genannt, weil die PIT-ID 906 für den sendenden
Anwendungsthread eine Lastschrift darstellt (eine Gutschrift für den Zielortthread).
Das Gutschriftenfeld 910 befindet sich dort, wohin der
sendende Thread einen PIT-Puffer übermittelt
oder diesen dem Zielortthread gutschreibt. Das Gutschriftenfeld 910 hält in der
Regel die PIT-ID 906, wobei der sendende Thread erwartet,
eine Rücknachricht
gesendet zu bekommen. Dieser Einsatz des Gutschriften-PIT wird auch
als SASE-PIT (SASE = self-addressed stamped envelope, frankierter
Rückumschlag)
bezeichnet. Das Befehlsfeld 914 beschreibt den Vorgang,
den das Ziel an den Nutzlastdaten 904 ausführen wird
(beispielsweise einen Festplattenlese- oder -schreibbefehl). Die Argumentfelder 916 sind
den Befehl betreffende Daten (beispielsweise die Festplatten- und
Blocknummer auf der Festplatte zum Ausführen des Lese- oder Schreibvorgangs).
Die Sequenznummer 918 ist eine sich monoton erhöhende ganze
Zahl, die für
jedes Paar aus Quellen- und Zielort knoten eindeutig ist. (Jedes
Knotenpaar weist eine Sequenznummer für jede Richtung auf.) Das Längenfeld 920 spezifiziert
die Länge
der PIT-Nutzlastdaten 904 in
Byte. Das Flagfeld 922 enthält verschiedene Flags, die
die Verarbeitung der PIT-Nachricht modifizieren. Eine Beispiel ist
das Dublettennachricht- Flag.
Dieses wird bei der erneuten Übermittlung
potentiell verlorener Nachrichten verwendet, um zu verhindern, dass
ein Ereignis mehr als einmal verarbeitet wird.
-
Wenn
das System zum ersten Mal hochgefahren wird, weist kein Knoten PIT-IDs 906 für einen
beliebigen anderen Knoten auf. Der BYNET-Softwaretreiber verhindert
die Lieferung von etwaigen bandgesteuerten Nachrichten, bis das
PIT-Protokoll für
das erstmalige Öffnen
abgeschlossen ist. Die Verteilung von PIT-IDs 906 wird
initiiert, wenn ein Anwendungsthread auf einem Rechnerknoten 200 das
erstmalige Öffnen
für eine beliebige,
auf einem ION 212 angeordnete virtuelle Festplatteneinrichtung
ausführt.
Während
des erstmaligen Öffnens
treten der ION 212 und der Rechnerknoten 200 in
eine Übertragungsstufe
ein, in der Betriebsparameter ausgetauscht werden. Ein Teil des
Protokolls für
das erstmalige Öffnen
ist der Austausch von PIT-IDs 906. PIT-IDs 906 können auf
mehr als einen einzigen Puffer zeigen, da die Schnittstelle sowohl
Gather-DMA am Sender als auch Scatter-DMA am Zielort unterstützt. Die
Anwendung kann die PIT-ID 906 frei an eine beliebige Anwendung
auf einen beliebigen anderen Knoten verteilen.
-
Der
Umfang und die Anzahl von zwischen diesem Rechnerknoten 200 und
dem ION 212 auszutauschenden PIT-Puffern sind abstimmbare
Werte. Der Austausch von Gutschrift- und Lastschrift-PIT-IDs 906 (jenen
im Lastschriftenfeld 912 und im Gutschriftenfeld 910)
bildet die Grundlage des Flusssteuerungsmodells für das System.
Ein Sender kann nur so viele Nachrichten an den Zielort senden,
wie gutgeschriebene PIT-IDs 906 vorliegen.
Dies begrenzt die Anzahl von Nachrichten, die ein gegebener Host
senden kann. Es stellt außerdem
insofern Gerechtigkeit sicher, dass jeder Sender höchstens
nur die PIT-IDs 906 ausreizen kann, die ihm zugeordnet
wurden, da jeder Knoten seine eigene Datenbasis von PIT-IDs 906 aufweist.
-
Der
ION 212 kontrolliert die Datenbasis von PIT-Tickets, die
er an die Rechnerknoten 200 ausgegeben hat. Die anfängliche
Zuteilung von PIT-IDs 906 an einen Rechnerknoten 200 erfolgt
während
des Protokolls für
das erstmalige Öffnen.
Die Anzahl von verteilten PIT-IDs 906 basiert auf einem
Schätzwert
der Anzahl der simultan aktiven Rechnerknoten 200, die
den ION 212 gleichzeitig verwenden, und der Speicherressourcen
im ION 212. Da es sich dabei nur um einen Schätzwert handelt,
kann der Umfang der PIT-Datenbasis auch während des Vorgangs vom ION 212 dynamisch
angepasst werden. Diese Neuverteilung von PIT-Ressourcen ist erforderlich,
um eine Gerechtigkeit beim Bedienen von Anforderungen von mehreren
Rechnerknoten 200 sicherzustellen.
-
Die
PIT-Neuzuteilung für
aktive Rechnerknoten 200 wird folgendermaßen vorgenommen:
Da aktive Rechnerknoten 200 ständig E/A-Anforderungen stellen,
werden die PIT-Ressourcen neu unter ihnen verteilt, indem der Fluss
von PIT-Gutschriften
in abgeschlossenen E/A-Nachrichten gesteuert wird. Bis das korrekte Niveau
erreicht worden ist, werden keine PIT-Gutschriften mit Abschlüssen des
ION 212 gesendet (wodurch die PIT-Datenbasis für diesen
Rechnerknoten 200 verringert wird). Eine schwierigere Situation
stellt sich bei Rechnerknoten 200 dar, die bereits eine
PIT-Zuteilung aufweisen, aber inaktiv sind (und die Ressourcen binden).
In derartigen Fällen
kann der ION 212 an jeden untätigen Rechnerknoten 200 eine
Nachricht zum Annullieren des PIT (oder einer Liste von PIT-IDs)
senden. Wenn ein untätiger
Rechnerknoten 200 nicht antwortet, kann der ION 212 alle
PIT-IDs für
diesen Knoten annullieren und dann die PIT-IDs neu an andere Rechnerknoten 200 verteilen.
Wenn ein untätiger
Rechnerknoten 200 versucht, ein neu zugeteiltes PIT zu
verwenden, wird der Rechnerknoten 200 in das Protokoll
für das
erstmalige Öffnen
zurückgedrängt.
-
Das
Erzielen des Erhöhens
der PIT-Zuteilung an einen Rechnerknoten 200 ist im Folgenden
beschrieben. Zum Senden neu zugeteilter PIT-IDs an einen beliebigen
Rechnerknoten kann eine PIT-Zuteilungsnachricht verwendet werden.
Eine alternative Technik bestünde
darin, in jeder E/A-Abschlussnachricht mehr als eine PIT-Gutschrift
zu senden.
-
PIT-Protokoll
in Aktion – Festplattenlese-
und -schreibvorgang
-
Um
das PIT-Protokoll zu veranschaulichen, wird eine Erörterung
einer Anforderung eines Rechnerknotens 200 nach einem Lesevorgang
an einer Speicherplatte 224 von einem ION 212 dargestellt.
Hier wird angenommen, dass das erstmalige Öffnen bereits erfolgt ist und
auf sowohl dem Rechnerknoten 200 als auch dem ION 212 genügend freie
PIT-Puffer vorliegen. Ein Anwendungsthread führt einen Lese-System-Aufruf durch,
wobei er die Adresse eines Puffers weitergibt und die Festplattendaten
an einen SCSI-High-Level-Treiber des Rechnerknotens (Treiber des
virtuellen Speicher-Verbindungsprotokolls) übertragen
werden sollen. Der CN-Systemtreiber
erstellt ein PIT-Paket, das diese Anforderung (einschließlich des
Namens der virtuellen Festplatte, der Blocknummer und der Datenlänge) enthält. Die
obere Hälfte
des CN-Systemtreibers füllt
dann das Lastschriften-PIT-ID-Feld 910 und
das Gutschriften-PIT-ID-Feld 912 aus. Beim Lastschriften-PIT-Feld 912 handelt
es sich um die PIT-ID 906 am Zielort-ION 212,
an den diese Leseanforderung gesendet wird. Da es sich hierbei um
eine Leseanforderung handelt, benötigt der ION 212 einen
Weg, den Puffer der Anwendung (denjenigen, der als Teil des Lese-System-Aufrufs
bereitgestellt wurde) zu spezifizieren. Da PIT-Pakete senderbasierte
Adressierung verwenden, kann der ION 212 nur dann den Anwendungspuffer
adressieren, wenn er eine PIT-ID 906 aufweist. Da der Anwendungspuffer
nicht Teil der normalen PIT-Datenbasis ist, wird der Puffer im Speicher
angeheftet und für
den Puffer wird eine PIT-ID 906 erstellt. Da die Leseanforderung
auch den Rückmeldestatus
aus dem Festplattenvorgang benötigt,
wird für
das PIT ein Scatter- Puffer
zum Enthalten des Rückmeldestatus
erstellt. Dieses SASE-PIT wird im Gutschriftenfeld als Teil des
gelesenen PIT-Pakets gesendet. Das PIT-Paket wird dann auf der abgehenden
Warteschlange platziert. Wenn die BYNET-Schnittstelle 802 das
PIT-Paket sendet, verschiebt es dieses mittels eines DMA-Vorgangs
von der Sendeseite und überträgt es dann über die
Verbindungsstruktur 106 hinweg. Wenn das PIT-Paket an der
zielortseitigen BYNET-Schnittstelle 808 ankommt, löst es die
Ausführung
des PIT-Kanalprogramms durch einen BYNET-Kanal-Prozessor 804 aus.
Der BYNET-Kanal-Prozessor 804 in
der hostseitigen Schnittstelle 802 extrahiert die Lastschriften-PIT-ID 906,
um den Endpunkt auf dem ION 212 aufzufinden. Das Kanalprogramm
extrahiert die Pufferadresse und programmiert die Schnittstellen-DMA-Engine
darauf, die Nutzlastdaten direkt in den PIT-Puffer zu verschieben – womit
dem PIT-Protokoll ermöglicht
wird, die Nulldatenkopiesemantik bereitzustellen. Die BYNET-Schnittstelle 802 schickt
auf dem ION 212 einen Interrupt an die empfangende Anwendung
ab. Am Rechnerknoten 200 erfolgt kein Interrupt. Wenn die
Rückkanalnachricht
anzeigt, dass die Übertragung
fehlgeschlagen ist, dann wird die E/A in Abhängigkeit vom Grund für das Fehlschlagen
wiederholt. Nach mehreren Versuchen wird ein Fehlerzustand des ION 212 eingegeben
(spezifische Einzelheiten dazu sind hierin unter den Wiederherstellungs-
und Ausfallsicherungsvorgängen
des ION 212 zu finden) und der Rechnerknoten 200 versucht
möglicherweise,
die Anforderung von dem anderen ION (z. B ION 214) in dem
Dipol bearbeiten zu lassen. Wenn die Nachricht zuverlässig in
den Zielortknotenspeicher geliefert wurde, richtet die Hostseite
dann eine Neuübermittlungszeitsperre
ein (die länger
als die im ungünstigsten
Fall auftretenden E/A-Bedienzeiten ist), um sicherzustellen, dass
der ION 212 die Nachricht erfolgreich verarbeitet. Wenn
dieser Timer abläuft,
wird die PIT-Nachricht vom Rechnerknoten erneut an den ION 212 gesendet.
Wenn die E/A noch immer durchgeführt wird,
wird die Dublettenanforderung einfach fallen gelassen, andernfalls
wird die erneut gesendete Anforderung normal verarbeitet. Optional
könnte
das Protokoll auch eine explizite Bestätigung der erneut gesendeten Anforderung
erfordern, um den Ablauftimer neu einzustellen und das Trauma eines
Fehlschlagens der E/A in Bezug auf die Anwendung zu vermeiden.
-
10 ist ein Blockschema der Funktionsmodule des
ION 212. Eingaben in die IONs 212 und 214 sind
die Datenleitungen 1002 und 1004 und die Steuerleitungen 1006.
Jedes Modul im ION 212 umfasst ein Steuermodul 1008,
das mit den Steuerleitungen 1006 in Verbindung steht. Die
Steuermodule 1008 nehmen von den Datenleitungen 1002 Befehle
an und stellen Modulsteuerfunktionen bereit. Ein Systemfunktionsmodul 1010 setzt
die hierin beschriebenen ION-Funktionen um. Die IONs 212 und 214 umfassen
ein Strukturmodul 1020, ein Cache-Speichermodul 1014, ein Datenrückfederungsmodul 1016 und
ein Speichermodul 1018. Jedes dieser Module umfasst ein
Steuermodul, einen Arbeitslastinjektor 1020 zum Einfügen und
Abrufen von Daten aus den Datenleitungen 1002 und 1004 und
ein Datengitter 1022 zum Blockieren der Datenpassage.
-
Nachdem
eine PIT-Leseanforderung an den ION 212 gesendet wurde,
wird diese zum Arbeitslastinjektor des ION-Cache-Speichermoduls 1014 übertragen.
Der Arbeitslastinjektor führt
Anforderungen in ein ION-Cache-Speichermodul 1014 ein,
das die Daten direkt zurücksenden
kann, wenn diese zwischengespeichert wurden, oder den Daten einen
Puffer zuteilt und sie an das ION-Speichermodul 1018 weitergibt.
Das ION-Speichersystemmodul 1018 übersetzt diese Anforderung
in eine (oder mehrere) Anforderung/en an die physische Festplatte
und sendet die Anforderung/en an das/die entsprechende/n Festplattenlaufwerk/e 224. Wenn
der/die Festplattenlesevorgang/vorgänge abgeschlossen wer-den,
schickt der Festplattenkontroller einen Interrupt ab, um den Abschluss
des Festplattenlesevorgangs zu signali-sieren. Der ION-Arbeitslastinjektor erstellt
ein E/A-Abschluss-PIT-Paket.
Die (im Lastschriftenfeld 912 gespeicherte) Last schriften-PIT-ID
ist die (im Gutschrif-tenfeld 910 gespeicherte) Gutschriften-PIT-ID
aus dem SASE-PIT in der Leseanforderung (dies ist, wo die Anwendung
die Festplattendaten platziert haben will). Die Gutschriften-PIT-ID
ist entweder dieselbe PIT-ID, an die der Rech-nerknoten 200 diese
Anforderung gesendet hat, oder eine Ersatz-PIT-ID, wenn dieser Puffer
nicht frei ist. Dieses Gutschriften-PIT wird dem Rechnerknoten für das Senden
einer zukünftigen
Anforderung eine Gutschrift geben (diese aktuelle PIT-Anforderung ist gerade
abgeschlossen worden, so dass sie die Warteschlangentiefe für diesen
Rechner-knoten 200 zu diesem ION 212 um Eins erhöht). Es
gibt drei Gründe,
warum ein ION 212 eine PIT-Gutschrift mögli-cherweise nach dem Verarbeiten
eines PIT nicht zurücksendet.
Der erste besteht darin, dass der ION 212 die Anzahl ausstehender
Anforderungen, die von diesem Rechnerknoten 200 in die
Warteschlange gesetzt wurden, reduzieren will. Der zweite Grund
ist, dass der ION 212 die PIT-Gutschrift neu an einen anderen
Rechnerknoten 200 verteilen will. Der dritte Grund besteht
darin, dass möglicherweise
mehrere in ein einziges PIT-Paket
verkapselte Anforderungen vorliegen (siehe dazu die Erörterung
der Super-PIT-Pakete hierin). Das Befehlsfeld 914 ist eine
Lesevorgangsabschlussnachricht und beim Argument handelt es sich
um den Rücksendecode
aus dem Festplattenlaufwerklesevorgang. Dieses PIT-Paket wird dann
zum Zurücksenden
zum Rechnerknoten 200 in eine Warteschlange zur BYNET-Schnittstelle 802 gesetzt.
Die BYNET-Hardware verschiebt anschließend dieses PIT-Paket mittels
eines DMA zum Rechnerknoten 200. Dies veranlasst das BYNET-Kanalprogramm
des Rechnerknotens 200, die Lastschriften-PIT-ID 912 zu
extrahieren und validieren, bevor der DMA auf den Ziel-PIT-Puffer
gestartet wird (bei dem es sich in diesem Fall um den angehefteten
Puffer der Anwendung handelt). Wenn der DMA abgeschlossen ist, löst die BYNET-Hardware
des Rechnerknotens einen Interrupt aus, um der Anwendung zu signalisieren,
dass der Festplattenlesevorgang abgeschlos sen ist. Der BYNET-Treiber
sendet am ION 212 den Puffer zum Cache-Speichersystem zurück.
-
Die
bei einer Schreibanforderung durchgeführten Vorgänge sind den beim Lesevorgang
durchgeführten ähnlich.
Die Anwendung ruft den CN-High-Level-Treiber (VSIP) auf, wobei sie
die Adresse weitergibt, die die Daten, den Namen der virtuellen
Festplatte, die Festplattenblocknummer und die Datenlänge enthält. Der CN-High-Level-Treiber
wählt eine
PIT-ID 906 auf dem Zielort-ION 212 aus und verwendet
diese Daten zum Erstellen einer PIT-Schreibanforderung. Das SASE-PIT wird nur den
Rückmeldestatus
des Schreibvorgangs aus dem ION 212 enthalten. Wenn das
PIT-Paket ankommt, wird am ION 212 ein Interrupt abgeschickt.
Diese Anforderung wird auf dieselbe Art und Weise wie ein PIT-Lesevorgang
verarbeitet; die Schreibanforderung wird zu den Cache-Speicherroutinen
weitergegeben, die schließlich
die Daten auf die Festplatte schreiben. Wenn der Festplattenschreibvorgang
abgeschlossen wird (oder die Daten im Schreib-Cache-Speicher beider ION-Knoten 212 und 214 sicher
gespeichert sind), wird eine E/A-Abschlussnachricht zurück an den
Rechnerknoten 200 gesendet. Wenn der ION 212 mit
aktiviertem Schreib-Cache-Speicher läuft, sendet der andere ION 214 im
Dipol anstelle des ION 212, an den die Anforderung gesendet
wurde, die E/A-Abschlussnachricht zurück. Dies wird hierin mit Bezug
auf das Bermudadreieck-Protokoll weiter beschrieben.
-
Abgelaufene PIT-IDs und
Fehlerwiederherstellungsprobleme
-
Beim
Austausch von PIT-IDs während
des erstmaligen Öffnens
handelt es sich um den Mechanismus, über den abgelaufene PIT-IDs 906,
die entweder durch einen Hardwarefehler oder einen Softwarefehler
erzeugt wurden, annulliert werden. Man ziehe die Situation in Betracht,
dass ein ION 212 und ein Rechnerknoten 200 PIT-IDs
ausgetauscht haben und der ION 212 plötzlich abstürzt. Die PIT-IDs 906 stellen
im Speicher angeheftete Zielpuffer dar und solange ausstehende PIT-IDs 906 für entweder
einen ION 212 oder einen gerade neugestarteten Rechnerknoten 200 nicht
annulliert werden, könnten
sie aufgrund von PIT-IDs, die nicht länger gültig bzw. abgelaufen sind,
ein erhebliches Softwareintegritätsproblem
verursachen. Die Unterstützung
durch die BYNET-Hardware und die bandgesteuerte Nachricht stellen
den wesentlichen Mechanismus für
das Annullieren abgelaufener PIT-IDs 906 bereit.
-
Am
Ende des Protokolls für
das erstmalige Öffnen
muss jede Seite dem CN-High-Level-SCSI-Treiber eine Liste von Hosts
geben, an die die PIT-IDs 906 verteilt werden. Anders ausgedrückt gibt
der Host dem CN-High-Level-SCSI-Treiber eine Liste von Hosts, von
denen dieser PIT-Pakete annehmen wird. Der Rechnerknoten-High-Level-Treiber
verwendet diese Liste dann zum Erstellen einer Tabelle, die die
Lieferung bandgesteuerter Nachrichten steuert. Diese Tabelle spezifiziert
die Kombinationen von Paaren von IONs 212, die es ermöglichen,
dass bandgesteuerte Nachrichten einander gesendet werden können. (Die
Tabelle kann außerdem
Einweg-PIT-Nachrich-tenflüsse spezifizieren.)
Der High-Level-Treiber
des Rechnerknotens behält
diese Tabelle als Teil des BYNET-Konfigurationsprozesses intern
auf den Hosts (als für
den Treiber private Daten). Hosts können zu einem beliebigen Zeitpunkt
vom PIT-Protokoll durch eine einfache Benachrichtigungsnachricht
an den High-Level-Treiber des Rechnerknotens dieser Liste hinzugefügt oder
von dieser abgezogen werden. Wenn ein Knoten versagt, heruntergefahren
wird oder nicht antwortet, erkennt die BYNET-Hardware dies und wird
alle anderen Knoten auf der Struktur benachrichtigen. Der BYNET-Host-Treiber
an jedem Knoten antwortet auf diese Benachrichtigung und löscht alle
Hinweise auf diesen Hort aus der Tabelle bandgesteuerter Hosts.
Diese Aktion annulliert alle PIT-IDs 906, die dieser Host
an einen beliebigen anderen Host verteilt haben könnte. Hierbei
handelt es sich um den Schlüssel
zum Schützen
eines Knotens vor zuvor verteilten PIT-Paketen. Bis der CN-High-Level-Treiber auf diesem
Host neu konfiguriert worden ist, wird das BYNET alle Nachrichten
abweisen, die zu diesem Host gesendet werden. Selbst nach der ersten
Neukonfiguration wird das BYNET, bis er über das lokale PIT-Protokoll
unterrichtet wird, nicht gestatten, dass eine beliebige bandgesteuerte Nachricht
an diesen gerade neugestarteten oder neukonfigurierten Host gesendet
wird. Dies schützt
vor der Lieferung von etwaigen abgelaufenen PIT-Paketen, bis das
PIT-Protokoll durch das Protokoll für das erstmalige Öffnen korrekt
initialisiert wurde.
-
Wenn
ein Host versucht, eine bandgesteuerte Nachricht an einen ungültigen Host
zu senden (unter Verwendung einer nun annullierten PIT-ID 906),
lehnt der sendeseitige High-Level-Treiber
des Rechnerknotens die Nachricht mit einer Fehlerkondition an den
Sender ab. Diese Ablehnung wird veranlassen, dass die Quittung für das erstmalige Öffnen zwischen
den zwei Knoten aufgerufen wird. Nachdem die Quittung für das erstmalige Öffnen abgeschlossen
wurde, werden etwaige E/A-Vorgänge
für den
ION 212, die noch immer anstehen (aus der Sichtweise des
Rechnerknotens 200) erneut gesendet werden müssen. Sofern
es sich jedoch nicht um einen Neustart im Betrieb gehandelt hat,
ist es wahrscheinlich, dass der ION 212 lange außer Betrieb war,
so dass etwaige anstehende E/A-Vorgänge als Teil der Ausfallsicherungsverarbeitung
neu gestartet und zum anderen ION 212 im Dipol gesendet
worden wären.
(Weitere Einzelheiten dazu sind in den Abschnitten zur ION-Fehlerhandhabung
zu finden.) Wenn der abgestürzte
Knoten ein Rechnerknoten 200 war, wird das unerwartete
Eintreffen einer Anforderung nach einem erstmaligen Öffnen am
ION 212 für
einen Rechnerknoten 200, der bereits ein erstmaliges Öffnen durchlaufen
hat, PIT-ID-Wiederherstellungsvorgänge auslösen. Der ION 212 wird
alle PIT-IDs 906 annullieren, die dem Rechnerknoten 200 gutgeschrieben
wurden (oder in Wirklichkeit wahrscheinlich einfach die alten erneut
ausgeben). Einem anstehenden E/A-Vorgang für diesen Rechnerknoten 200 wird
der Abschluss ermöglicht
(obwohl es sich dabei um ein unwahrscheinliches Ereignis handelt,
außer
wenn ein Knotenneustart äußerst schnell
abgelaufen ist). Abschlussnachrichten werden fallen gelassen werden
müssen,
da das SASE-PIT, das er verwendet, abgelaufen sein würde (und
der Anwendungsthread, der die E/A-Anforderung ausgegeben hatte,
nicht länger
existieren würde).
-
Super-PIT – Verbessern
der Leistung kleiner E/A
-
Das
PIT-Protokoll hat einen Vorteil gegenüber normalen SCSI-Befehlen.
Da das Kernstück
der vorliegenden Erfindung ein Kommunikationsnetzwerk, nicht ein
Speichernetzwerk ist, kann das System Netzwerkprotokolle verwenden,
um die Leistung stärker
zu verbessern, als ein Speichermodell zulassen würde. Der Verarbeitungsoverhead
der Handhabung von Upcalls stellt für von kleinen E/A-Anforderungen
dominierten Arbeitslasten eine Leistungswand dar. Es gibt mehrere
Ansätze
zum Verbessern der Leistung von kleinen E/A. Ein Ansatz besteht
darin, die Pfadlänge
des Interrupt-Handhabungscodes zu verbessern. Der zweite ist, das Leiten
mehrerer Interrupts in einen einzigen Aufruf der Interrupt-Programmsteuerung
unter Verwendung von den in Einrichtungstreibern eingesetzten ähnlichen
Techniken kollabieren zu lassen. Der dritte Ansatz besteht darin,
die Anzahl individueller E/A-Vorgänge zu vermindern und sie in
eine einzige Anforderung zu clustern (bzw. zu Convoys zusammenzufassen).
Knoten, die eingehende und abgehende Datenflüsse aufgrund von verschiedenen
MTU-Größen an physischen
Quellen- und Zielortsverknüpfungen
neu verpacken müssen,
tendieren dazu, Daten zu sammeln. Dieses Problem wird auch durch
Geschwindigkeitsungleichgewichte zwischen dem sendenden Netzwerk
und dem Zielortnetzwerk (insbesondere in dem Fall, in dem das Zielortnetzwerk
langsamer ist) verschlimmert. Diese Knoten werden ständig einer
Flusssteuerung vom Zielort unterworfen. Das Ergebnis ist Verkehr,
der aus dem Router in Bursts herausfließt. Dies wird Datenconvoying
genannt. Die vorliegende Erfindung zieht aus Datenconvoys als einer
Technik zum Vermindern der Anzahl von durch Upcalls erzeugten Interrupts
in sowohl dem ION 212 als auch dem Rechnerknoten 200 Vorteile.
Zur Veranschaulichung ziehe man den Datenfluss von einem ION 212 zu
einem Rechnerknoten 200 in Betracht. Im von der vorliegenden
Erfindung verwendeten Lastschrift/Gutschrift-Modell für die Flusssteuerung
reihen sich E/A-Anforderungen sowohl am Rechnerknoten 200 als
auch am ION 212 in eine Warteschlange ein. Das Einreihen
in einer Warteschlange startet mit im ION 212 gespeicherten
PIT-Paketen und fährt,
wenn dies erschöpft
ist, zurück
am Rechnerknoten 200 fort. Dies wird eine Überlaufkondition
genannt. In der Regel tritt ein Überlauf
auf, wenn ein Knoten über
mehr Anforderungen als PIT-Gutschriften verfügt. Jedes Mal, wenn eine E/A
abgeschlossen wird, sendet der ION 212 eine Abschlussnachricht
zurück
an den Rechnerknoten 200. In der Regel enthält diese
Abschlussnachricht eine Gutschrift für die gerade freigegebene PIT-Pufferressource. Hierbei
handelt es sich um die Grundlage der Lastschrift/Gutschrift-Flusssteuerung.
Wenn das System mit E/A-Anforderungen überschwemmt wird, wird jeder
E/A-Abschluss unverzüglich am
ION 212 durch eine neue E/A-Anforderung ersetzt. Somit fließen E/A-Anforderungen
bei Perioden hoher Last jeweils einzeln zum ION 212 und
reihen sich im ION 212 für eine unbestimmte Zeitspanne
in einer Warteschlange ein. Jede dieser Anforderungen erstellt einen
Upcall-Interrupt, wodurch die Last auf dem ION 212 erhöht wird.
-
Dieses
Dualwarteschlangen-Modell hat eine Reihe von Vorteilen. Bei der
Anzahl der einem Rechnerknoten 212 zugeteilten PIT-Puffer
handelt es sich um einen umsichtigen Kompromiss. Es sollte genügend Arbeitslast
vorliegen, die lokal zum ION 212 in einer Warteschlange
eingereiht ist, so dass, wenn Anforderungen abgeschlossen werden,
neue Arbeit schnell entsendet werden kann. Von in der Warteschlange
eingereih ten Anforderungen am ION 212 verbrauchte Speicherressourcen
können
jedoch besser eingesetzt werden, wenn sie einem Cache-Speichersystem
zugeordnet werden. Wenn PIT-Warteschlangen am ION 212 kurz
gehalten werden, um Speicher zu bewahren, kann die Leistung darunter
leiden, wenn der ION 212 nicht genutzt wird und darauf
warten muss, dass ihm von den Rechnerknoten 200 Arbeit
gesendet wird.
-
Super-PIT
ist ein Aspekt des PIT-Protokolls, das darauf konzipiert wurde,
einen Vorteil aus der Flusssteuerung eines Lastschrift/Gutschrift-Systems
bei hohen Lasten zu ziehen, um die Anzahl von Upcall-Interrupts
zu vermindern. Das Super-PIT verbessert die Leistung von OLTP und ähnlichen
Arbeitslasten, die von hohen Raten relativ kleiner E/As dominiert
werden. Anstatt Anforderungen jeweils einzeln zu senden, handelt es
sich bei einem Super-PIT-Paket um eine Sammlung von E/A-Anforderungen,
die alle in einer einzigen, größeren Super-PIT-Anforderung
geliefert werden. Jedes Super-PIT-Paket wird auf dieselbe Art und
Weise wie ein regulärer
PIT-Puffer transportiert. In dem Super-PIT-Paket enthaltene individuelle E/A-Anforderungen
werden dann extrahiert und vom PIT-Arbeitslastinjektor in den normalen
Warteschlangenmechanismus des ION 212 eingeführt, wenn
Ressourcen des ION 212 verfügbar werden. Diese individuellen
E/A-Anforderungen können
entweder Lese- oder Schreibanforderungen sein.
-
Der
PIT-Arbeitslastinjektor agiert als lokaler Bevollmächtigter
(auf dem ION 212) für
zum ION 212 transportierte Anwendungsanforderungen. Der
PIT-Arbeits-lastinjektor wird auch von den RT-PIT- und FRAG-PIT-Protokollen,
die in einem folgenden Abschnitt erörtert werden, verwendet. Wenn
das Super-PIT die individuellen Anforderungen erschöpft hat,
wird die Ressource vom Rechnerknoten freigegeben und es kann ein
anderes Super-PIT-Paket gesendet werden, um das vorherige zu ersetzen.
Die Anzahl von pro Host erlaubten Super-PIT-Paketen wird bei der Übertragung
beim erstmaligen Öffnen
bestimmt. Offensichtlich muss die Menge an auf dem ION 212 in
einer Warteschlange eingereihter Arbeit genügen, um den ION 212 beschäftigt zu
halten, bis ein weiteres Super-PIT-Paket geliefert werden kann.
-
Man
ziehe die Situation in Betracht, in der ein Rechnerknoten 200 genug
Arbeit in einer Warteschlange in einem ION 212 eingereiht
hat, um seine PIT-Gutschrift zu erschöpfen, und damit begonnen hat,
Anforderungen lokal in einer Warteschlange einzureihen. Die Anzahl
von in der Super-PIT-Anforderung
in der Warteschlange eingereihten Anforderungen ist nur durch den
Umfang des Puffers begrenzt, zu dem das Super-PIT transportiert
wird. Super-PIT-Pakete arbeiten anders als normale PIT-Pakete. Im
Steuerungsmodell der vorliegenden Erfindung können Einrichtungen nur dann
eine Anforderung (eine Lastschrift) senden, wenn sie eine Lastschrift
für den
Zielort haben. Das bestimmte von der Einrichtung verwendete PIT-Paket
spielt keine besondere Rolle, da die Einrichtung nicht auf einen
spezifischen Anwendungsthread im ION 212 abzielt. PIT-Pakete zum
ION 212 regulieren lediglich die Pufferverwendung (und
als Nebeneffekt die Flusssteuerung). Im Gegensatz dazu ist das SASE-PIT
in einer PIT-Anforderung anders. Die SASE-PIT-ID stellt einen Adressraum
eines individuellen Threads im Rechnerknoten 200 dar. Jede
Anforderung im Super-PIT enthält
ein SASE-PIT, wenn jedoch die E/A, die sie darstellen, abgeschlossen
wird, enthält
die E/A-Abschlussnachricht kein Gutschrift-PIT. Nur wenn dem Super-PIT alle Anforderungen
entzogen wurden, wird für
seinen Adressraum ein Gutschrift-PIT ausgegeben.
-
Das
Erstellen eines Super-PIT auf einem Rechnerknoten 200 wird
im Folgenden beschrieben. Ein Super-PIT kann jedes Mal erstellt
werden, wenn mindestens zwei E/A-Anforderungen an einen einzigen
ION 212 im Rechnerknoten 200 in einer Warteschlange
eingereiht sind. Wenn der Grenzwert für Super-PIT-Pakete für diesen Rechnerknoten 200 bereits
auf diesem ION 212 erreicht worden ist, wird der Rechnerknoten 200 damit fortfahren,
Anforderungen in der Warteschlange einzureihen, bis eine Super-PIT-ID
an ihn zurückgesendet wird.
Der Rechnerknoten 200 gibt dann eine weitere Super-PIT-Nachricht aus. Nachdem
das Einreihen in eine Warteschlange begonnen hat, werden im Systemtreiber
Warteschlangen pro ION benötigt,
um Super-PIT-Pakete zu erstellen.
-
Wie
oben erörtert
können
Super-PIT-Nachrichten die Verarbeitungslast auf einen ION 212 unter
Arbeitslasten, die von einer großen Menge an kleinen E/A-Anforderungen
dominiert sind, vermindern. Super-PIT-Nachrichten verbessern aufgrund
einer Erhöhung
der durchschnittlichen Nachrichtengröße die Leistung des Zielortknotens
und die Auslastung der Verbindungsstruktur 106. Das Konzept
von Super-PIT-Nachrichten
kann jedoch ebenfalls am ION 212 angewendet werden, um
die Last auf den Rechnerknoten 200, die durch kleine E/A-Arbeitslasten
erzeugt wird, zu reduzieren. Das Erstellen von Super-PIT-Nachrichten
auf dem ION 212 ist im Gegensatz zum Erstellen dieser auf
dem Rechnerknoten 200 ein komplett anderes Problem. Auf
dem Rechnerknoten 200 werden E/A-Anforderungen erzeugende
Anwendungsthreads der Flusssteuerung unterworfen, um zu verhindern,
dass der ION 212 überflutet
wird. Die Dienstrate des Festplattenuntersystems ist sehr viel niedriger
als beim Rest des ION 212 und wird stets die letzte Einschränkung der
Leistung des ION 212 sein. Anforderungen werden beim Eintreten
ins System blockiert, bis der ION 212 genügend Ressourcen
hat, um die Anforderung in eine Warteschlange einzureihen und schließlich zu
bedienen. Die Sache ist die, dass Anforderungen auf dem Rechnerknoten
sich in eine Warteschlange einreihen würden (oder die Anwendung blockiert
werden würde),
bis auf dem ION 212 Ressourcen verfügbar sind. Das Ausgehen von
Ressourcen ist auf dem Rechnerknoten 200 kein Problem.
Wenn eine Anwendung des Rechnerknotens 200 eine Anforderung
nach E/A an das System vorbringt, sind die zum Abschließen der
E/A erforderlichen Speicherressourcen des Rechnerknotens 200 als
Teil der Anforderung eingebunden (der Anwendungsthreadpuffer). Für jede E/A-Abschlussnachricht,
die der ION 212 an den Rechnerknoten 200 senden
muss, weist er bereits eine zugeteilte PIT-ID (die SASE-PIT-ID) auf. Aus
Sichtweise des ION 212 ist E/A-Abschlussnachrichten bereits der Zielpuffer
zugeteilt und sie können
gefüllt
werden, sobald die Daten bereit sind. Die E/A-Abschlussnachricht gilt
nach der Lieferung als erfolgreich (der ION 212 braucht
nicht auf den Ablauf der Bedienzeit eines Festplattenspeichersystems
am Rechnerknoten zu warten). Somit kann der ION 212 aufgrund
des Flusssteuerungsdrucks von einem Rechnerknoten nicht blockieren.
Um Super-PIT-Nachrichten zu erstellen, hat der Rechnerknoten Vorteile
aus dem Einreihen in eine Warteschlange bei der Flusssteuerung genommen,
eine Option, die dem ION 212 nicht zur Verfügung steht.
Da der ION 212 nicht auf irgendwelche Ressourcen, außer auf
den Zugriff auf das BYNET warten muss, ist die Gelegenheit zum Erstellen
von Super-PIT-Nachrichten
sehr viel geringer.
-
Es
können
mehrere Ansätze
zum Erstellen von Super-PIT-Nachrichten
auf dem ION 212 eingesetzt werden. Ein Ansatz besteht darin,
die E/A-Abschlussanforderungen leicht zu verzögern, um die Gelegenheit zum
Erstellen eines Super-PIT-Pakets
zu erhöhen.
Wenn nach einer geringen Verzögerung
keine neuen Abschlussnachrichten für denselben Knoten bereit sind,
wird die Nachricht als normale PIT-Nachricht gesendet. Das Problem
bei dieser Technik ist, dass, wenn die Anforderung um eine beliebige
Zeitspanne verzögert
wird, weil eine Super-PIT erstellt werden soll (der Upcall-Overhead auf dem
Rechnerknoten vermindert werden soll), ein entsprechender Anstieg
der Gesamtbedienzeit für
die Anforderungen eintritt. Das Nettoergebnis ist eine reduzierte
Last auf dem Rechnerknoten 200, dies kann jedoch auch die
Anwendung verlangsamen. Eine anpassungsfähige Verzögerungszeit wäre vorteilhaft
(je nach der durchschnittlichen Bedienzeit zu einem Rechnerknoten 200 und
der Gesamtbedien zeit, die von einer spezifischen Anforderung akkumuliert
wird). Der zweite Ansatz ist eine geringe Variation des ersten.
Dieser würde
erfordern, dass jeder Rechnerknoten 200 jeden ION 212 mit
einer Verzögerungszeit
ausstattet, die ansteigen würde,
wenn die Rate kleiner E/A am Rechnerknoten ansteigt. Der Sinn liegt
darin, das Fenster zum Erstellen von Super-PIT-Nachrichten für einen
spezifischen ION 212 nach Bedarf zu vergrößern. Der
dritte Ansatz wäre,
bestimmte Verkehrstypen, wie beispielsweise kleine Lese- oder Schreibvorgänge, die
direkt vom Cache-Speicher bedient werden und kein Warten auf einen
Vorgang der Speicherplatte 224 umfassten, zu verzögern. Während der
Cache-Speicher die durchschnittliche E/A-Wartezeit durch Vermeiden
von Festplattenverkehr für
einen Prozentanteil der Anforderungen vermindert, wird die Verteilung
von Wartezeiten durch Cache-Speicher-Hits verändert. Eine geringe Warteschlangenverzögerungszeit
für eine
von einem Cache-Speicher-Hit betroffene Anforderung würde bei
der Bedienzeit im Vergleich zu der Bedienzeit, die einen Festplattenvorgang
beinhaltete, nicht zu einem hohen Anstieg führen. Bei denjenigen Anwendungen,
die in Bezug auf die Bedienzeitverteilung empfindlich sind (bei
denen eine einheitliche Antwortzeit für die Leistung wichtig ist),
weist eine geringe Verzögerung
zum Erstellen eines Super-PIT-Pakets auf dem ION 212 das
Potential zur Verbesserung der Gesamtsystemleistung auf.
-
Unterstützung von
großen
Blöcken
und fragmentierte PIT-Pakete
-
Leistungsvoraussetzungen
für Datenbankanwendungen
sind häufig
vom Umfang der Datenbank unabhängig.
Wenn der Umfang der Datenbank ansteigt, muss auch die Rate, mit
der der Festplattenspeicher überprüft wird,
proportional ansteigen, um eine Erosion der Anwendungsleistung zu
verhindern. Anders ausgedrückt
muss die Antwortzeit für
eine gegebene Anfrage konstant bleiben, damit Kundendatenbanken
an Umfang zunehmen können.
Die Problematik beim Erfüllen
dieser Voraussetzungen besteht darin, dass sie im direkten Widerspruch
zum aktuellen Trend bei der Festplattenlaufwerktechnologie stehen:
Festplattenlaufwerke nehmen an Kapazität zu, während gleichzeitig ihre Leistung
bei willkürlichen
E/A konstant bleibt. Ein Ansatz zum Mildern dieses Trends besteht
darin, den durchschnittlichen Umfang von Festplatten-E/A-Vorgängen zu erhöhen, wenn
sich die Kapazität
des Festplattenlaufwerks erhöht.
Auf der Grundlage der aktuellen Trends bei der Speicherkapazität und den
Leistungsvoraussetzungen wird die durchschnittliche E/A-Größe möglicherweise
in der unmittelbaren Zukunft von 24 KB auf 128 KB ansteigen. Ein
agressiveres Zwischenspeichern und Techniken zum verzögerten Schreiben
könnten
sich bei vielen Arbeitslasten ebenfalls als hilfreich erweisen. Ungleichmäßiges Technologiewachstum
bei Festplattenlaufwerken ist nicht die einzige hinter ansteigenden E/A-Anforderungsgrößen steckende
treibende Kraft. Da Datenbanken mit BLOBS (binary large objects,
binäre große Objekte)
gängiger
werden, werden Objekte mit einem Umfang von 1 MB oder mehr gebräuchlicher.
Ungeachtet der spezifischen Ursache wird erwartet, dass Systeme
große
E/A-Objekte unterstützen
werden müssen,
dessen Umfang weiter der Ökonomie
von Festplattenspeichern folgen wird.
-
Es
bestehen mehrere Probleme, die mit der Übermittlung von großen Datenobjekten
zwischen dem ION 212 und den Rechnerknoten 200 unter
Verwendung des PIT-Protokolls zusammenhängen. Wie hierin beschrieben
wurde, liegt der Vorteil des PIT-Protokolls in der Vorzuteilung
von Zielortpuffern, um die Probleme der Flusssteuerung und der Endpunktlage
anzugehen. Die Upcall-Semantik erfordert jedoch die Identifizierung (oder
Zuteilung) von ausreichendem Pufferplatz, in dem die Nachricht abgelegt
werden kann. Das PIT-Protokoll geht dieses Problem an, indem es
die Sendeseite die Ziel-PIT-ID 906 auswählen lässt, wobei
jede Nachricht am Empfänger
abzulegen ist. Große
E/A-Schreibvorgänge
erschweren eindeutig das Protokoll, da der Nachrichtenumfang ein
Kriterium bei der Auswahl einer spezifischen PIT-ID 906 aus
einer verfügbaren
Datenbasis werden könnte.
Bei Perioden hoher Last besteht das Potential für Situationen, bei denen der
Sender verfügbare
Gutschriften für
PIT-IDs 906 aufweist, aber keine davon die Pufferumfangvoraussetzung
für eine
große E/A-Anforderung
erfüllt.
Beim PIT-Protokoll muss die Sendeseite, wenn ein umfangreicher Bestand
von zu sendenden Datengrößen vorliegt,
mit der Empfangsseite zusammenarbeiten, um sowohl die Anzahl als
auch den Umfang der PIT-Puffer zu verwalten. Dies schafft ein Problem
in Bezug auf die PIT-Puffer-Zuteilungsgröße, d. h., wenn eine Datenbasis
von PIT-Puffern erstellt wird, wie sieht die korrekte Verteilung
von Puffergrößen für eine Datenbasis
von PIT-Puffern bei einer gegebenen Arbeitslast aus? Die BYNET-Software
führt einen
zusätzlichen
MTU-Grenzwert (MTU = maximum transfer unit, maximale Übertragungseinheit),
der große
E/A-Lesevorgänge
zusätzlich
zu den Schreibvorgängen
erschwert. E/A-Anforderungen (sowohl Lese- als auch Schreibanforderungen),
die die BYNET-MTU überschreiten,
müssen
vom Softwareprotokoll (in diesem Fall dem PIT-Protokoll) an der
Sendeseite fragmentiert und an der Zielortseite wieder zusammengefügt werden. Dies
schafft das Problem der Speicherfragmentierung. Kurz gesagt ist
interne Fragmen-tierung verschwendeter Platz innerhalb eines zugeteilten
Puffers. Externe Fragmentierung ist verschwendeter Platz außerhalb
der zugeteilten Puffer, die zu klein sind, um eine beliebige Anforderung
zu erfüllen.
Eine Lösung
wäre, nur
einen Teil eines größeren PIT-Puffers
zu verwenden; dies würde
jedoch unnötige
interne Fragmentierung verursachen, wenn größere PIT-Puffer verwendet werden.
Große
PIT-Puffer verschwenden Speicher, was die Kosten/Leistung beeinträchtigt.
-
In
der vorliegenden Erfindung wird das Problem in Bezug auf die BYNET-MTU
und die PIT-Puffergrößenzuteilung
durch das Hinzufügen
von zwei weiteren Typen von PIT-Nachrichten gelöst: dem RT-PIT (RT = round
trip, Rundreise) und dem FRAG-PIT (fragmentiertem PIT). Sowohl das
FRAG-PIT als auch das RT-PIT verwenden ein Datenzieh-Modell anstelle
des PIT-Datenschieb-Modell.
(Zum Schieben von Daten schob die Sendeseite die Daten zum Zielort.
Zum Ziehen von Daten zieht der Zielort die Daten aus der Quelle.) FRAG-PIT-Nachrichten sind
darauf konzipiert, große
Datenlesevorgänge
zu unterstützen,
während RT-PIT-Nachrichten
große
Datenschreibvorgänge
unterstützen.
Sowohl das FRAG-PIT als auch das RT-PIT sind dem Super-PIT insofern ähnlich,
dass sie ebenfalls den PIT-Arbeitslastinjektor des ION zum Verwalten des
Datenflusses verwenden.
-
RT-PIT-Nachrichten
-
Wenn
ein Rechnerknoten 200 einen großen Festplattenschreibvorgang
auf einem ION 212 ausführen will
und der E/A-Schreibvorgang
umfangreicher als entweder die BYNET-MTU oder ein beliebiger verfügbarer PIT-Puffer
des ION 212 ist, wird der Rechnerknoten 200 eine
RT-PIT erstellen-Nachricht erstellen. Eine RT-PIT-Nachricht arbeitet
in zwei Phasen: die Boost-Phase, gefolgt von der Rundreise-Phase.
In der Boost-Phase wird eine Liste von Quellenpuffern für die zu
schreibenden Daten einer Reihe von PIT-IDs auf dem Rechnerknoten 200 zugewiesen.
Die Fragmentationsgröße des Quellenpuffers
wird durch die BYNET-MTU und die Größeneinschränkungen, die während des
ION-Protokolls für
das erstmalige Öffnen
spezifiziert wurden, bestimmt. Diese Liste von PIT-IDs (mit dem entsprechenden
Pufferumfang) werden in die Nutzlast einer einzigen RT-PIT-Anforderungsnachricht
gesetzt. und werden PIT-Gutschriften für den Zielort-ION 212 darstellen.
Ein zusätzlicher
PIT-Puffer wird aus der Rechnerknotendatenbasis zugeteilt, um direkt
vom RT-PIT-Protokoll verwendet zu werden. Die PIT-ID dieses zusätzlichen
Puffers wird in das Gutschriftenfeld des PIT-Kopfteils gesetzt.
Der Rest der RT-PIT-Anforderung ist mit dem einer normalen PIT-Schreibnachricht
identisch. Der Rechnerknoten 200 sendet (boostet) dann
diese RT-PIT-Anforderungsnachricht an den ION 212.
-
Der
PIT-Arbeitslastinjektor am ION 212 verarbeitet die RT-PIT-Anforderungsnachricht
in zwei Schritten. Der Arbeitslastinjektor muss für jede quellenseitige
PIT-ID 906 einen PIT-Puffer aus dem ION-Cache-Speicher
anfordern, der dem Umfang angeglichen ist. (Man beachte dabei, dass
dies je nach im Cache-Speicher des ION-Puffers verfügbarem Speicherplatz
gleichzeitig oder nacheinander ausgeführt werden kann.) Durch Angleichen
der PIT-Puffer wird der ION 212 Ressourcen dynamisch zuteilen,
um die Schreibanforderung anzugleichen. Die E/A kann nun unter Verwendung
einer modifizierten Sequenz normaler PIT-Übertragungen voranschreiten.
Die Verarbeitung der RT-PIT-Nachricht tritt nun in die Rundreise-Phase
ein, in der der Arbeitslastinjektor eine RT-PIT-Startnachricht für ein (oder
mehrere) angeglichene/s Paar/e aus Quellen- und Zielort-PIT-IDs
erstellt. (Die Option des Sendens eines Teilsatzes angeglichener
PIT-IDs bleibt in
der Ermessensfreiheit des ION 212.) Die Anzahl von PIT-IDs 906 in
einer einzigen RT-PIT-Startnachricht
steuert die Körnung
der Datenübertragung
im ION 212 (wie im Folgenden erörtert).
-
Diese
RT-PIT-Startnachricht wird zurück
zum Rechnerknoten 200 gesendet, wodurch die Boost-Phase der
RT-PIT-Nachricht beendet wird. Wenn der Rechnerknoten 200 die
RT-PIT-Startnachricht empfängt,
beginnt er die Daten unter Verwendung einer normalen PIT-Schreibnachricht
an den ION 212 zu übertragen,
ein PIT-Paar nach dem anderen. Die Fragmente müssen vom Rechnerknoten 200 nicht
in ihrer Reihenfolge gesendet werden, da sowohl der Rechnerknoten 200 als
auch der ION 212 genügend
Daten aufweisen, um mit verlorengegangenen Fragmenten umzugehen
(das angeglichene PIT-Paar spezifiziert die Reihenfolge zum erneuten
Zusammenfügen).
Wenn der ION 212 die PIT-Schreibnachricht empfängt, wird
der Ar beitslastinjektor benachrichtigt, der erkennt, dass diese
Schreibanforderung Teil eines größeren RT-PIT-E/A-Vorgangs
ist. Dem Arbeitslastinjektor stehen zum Verarbeiten des PIT-Schreibvorgangs
zwei Optionen zur Verfügung:
entweder das Fragment an die Cache-Speicher-Routinen weiterzuleiten,
um den Schreibvorgang zu starten, oder auf die Übermittlung des letzten Fragments
zu warten und dann den Schreibvorgang zu starten. Das frühe Starten der
E/A kann den Cache-Speicher-Routinen
ermöglichen,
den Datenfluss zu den Festplattenlaufwerken zu leiten (je nach der
Schreibstrategie des Cache-Speichers), es wird dabei jedoch bei
der kleineren E/A-Größe ein Leistungsverlust
riskiert. Das Festhalten der E/A, bis alle Fragmente eingetroffen
sind, kann jedoch eine unangemessene Belastung für das Cache-Speichersystem
bedeuten. Da die Gesamtgröße und die
Anzahl der Fragmente vom Anfang an bekannt sind, werden alle Daten,
die zum Optimieren der großen
E/A-Anforderung unter den derzeitigen Betriebsbedingungen erforderlich
sind, vom Cache-Speichersystem erstellt. Die erfolgreiche Übermittlung
jedes PIT-Schreibvorgangs
bewirkt auf der Seite des Rechnerknotens 200 den Start
des nächsten
Fragments des zu startenden Schreibvorgangs, wenn mehrere Fragmente
in einer einzigen RT-PIT-Startnachricht enthalten sind. Wenn das
letzte Fragment in einem einzigen RT-PIT-Startbefehl empfangen worden
ist, leitet der Anforderungsinjektor die Daten an das Cache-Speichersystem
weiter, damit diese ähnlich
wie bei einer normalen Schreibanforderung verarbeitet werden. Wenn
die Daten gesichert sind, wird vom Cache-Speichersystem eine E/A-Abschlussnachricht
erstellt, die zurück
zum Rechnerknoten 200 gesendet wird, um den Abschluss dieser
Phase der Verarbeitung (des RT-PIT-Startvorgangs) zu signalisieren.
Wenn weitere Fragmente verbleiben, wird ein weiterer. RT-PIT-Startbefehl
erstellt und an den Rechnerknoten gesendet, womit der oben beschriebene
Kreislauf wiederholt wird, bis alle Fragmente verarbeitet worden
sind. Wenn der Arbeitslastinjektor und der Cache-Speicher die Verarbeitung
des letzten Fragments abgeschlossen haben, wird eine ab schließende E/A-Abschlussnachricht
zum Rechnerknoten zurückgeleitet,
um das Ende der gesamten Verarbeitung der RT-PIT-Anforderung zu
synchronisieren.
-
RT-PIT-Nachrichten
könnten
mit einigen Änderungen
des BYNET optimiert werden. Man ziehe die Situation in Betracht,
in der der ION 212 gerade eine RT-PIT-Anforderung empfangen
hat; der Arbeitslastinjektor auf dem ION 212 gleicht Puffer
auf dem Rechnerknoten an den ION 212 an, um die große E/A-Anforderung in eine
Reihe kleinerer normaler Schreibanforderungen zu übersetzen.
Die Synchronisierung wird mittels der Zwischen-RT-PIT-Startbefehle
durchgeführt.
Wenn das BYNET jedoch ermöglichen
würde,
dass ein empfangenes Kanalprogramm einen Datenziehvorgang durchführt, könnte der
Zwischenschritt des Sendens eines RT-PIT-Startbefehls an den Rechnerknoten
eliminiert werden. Aus Erörterungsgründen nennen
wir diesen Modus des BYNET-Betriebs eine Bandschleifennachricht.
Bei einer Bandschleifennachricht handelt es sich tatsächlich um
zwei bandgesteuerte Nachrichten, die ineinander verschachtelt sind.
Beispielhaft wird sie, wenn der Arbeitslastinjektor eine RT-PIT-Anforderung
empfängt,
jedes Fragment durch Erstellen einer RT-PIT-Startnachricht, die
die zum Erstellen einer zweiten PIT-Schreibnachricht auf dem Rechnerknoten
erforderlichen Daten enthält,
verarbeiten. Die RT-PIT-Startnachricht überträgt die Schablone für den PIT-Schreibvorgang
für ein Fragment
an den Rechnerknoten 200. Das auf dem Rechnerknoten 200 ausgeführte Kanalprogramm
(das zusammen mit der RT-PIT-Startnachricht gesendet wurde) legt
die Nutzlast auf der Sendewarteschlange auf dem BYNET-Treiber des
Rechnerknotens ab. Die Nutzlast sieht wie eine Anforderung aus,
die von dem Anwendungsthread, der die anfängliche RT-PIT-Anforderung
gestellt hatte, in die Warteschlange eingereiht wurde. Die Nutzlast
wird unter Verwendung des Paars aus PIT-IDs (Quellen- und Zielort-PIT-IDs)
für dieses
vom Arbeitslastinjektor gesendete Fragment eine PIT-Schreibanforderung
erstellen. Der PIT-Schreib-vorgang wird das Fragment auf dem ION 212 ablegen
und den Arbeitslastinjektor darüber
benachrichtigen, dass es eingetroffen ist. Der Arbeitslastinjektor
wird diesen Kreislauf für
jedes Fragment fortsetzen, bis alle verarbeitet worden sind. Die
Leistungsverbesserung durch die Bandschleifennachrichten leitet
sich vom Entfernen des Interrupts und der für jede RT-PIT-Startnachricht
erforderlichen Verarbeitung durch den Rechnerknoten ab.
-
FRAG-PIT-Nachrichten
sind darauf konzipiert, den Ablauf großer E/A-Leseanforderungen aus
einem Rechnerknoten zu unterstützen.
Wenn eine Anwendung eine große
E/A-Leseanforderung
stellt, heftet der Rechnerknoten den Zielpuffer an und erstellt
eine Liste aus PIT-IDs, die die Zielpuffer jedes Fragments darstellen.
Jede PIT-ID beschreibt eine Scatter-Liste, die sich aus dem/den
Zielpuffer/n für
dieses Fragment und einem zugehörigen
Statuspuffer zusammensetzt. Der Statuspuffer wird aktualisiert,
wenn die Daten gesendet werden, was dem Rechnerknoten zu bestimmen
ermöglicht,
wann jedes Fragment verarbeitet wurde. Die Größe jedes Fragments wird mit
demselben Algorithmus wie bei RT-PIT-Nachrichten bestimmt (siehe
den obigen Abschnitt zum RT-PIT). Diese Felder werden zusammengefügt, um ein
FRAG-PIT zu erstellen.
-
Der
Rechnerknoten 200 sendet die FRAG-PIT-Anforderung an den
ION 212, wo sie vom Arbeitslastinjektor verarbeitet wird.
In diese Anforderung eingebunden sind der Name der virtuellen Festplatte,
die Startblocknummer und die Datenlänge der Datenquelle auf dem
ION 212. Der Arbeitslastinjektor arbeitet auf wie bei einer
RT-PIT-Anforderung ähnliche
Weise an einer FRAG-PIT-Anforderung. Jedes Fragment in der FRAG-PIT-Anforderung
wird in Zusammenarbeit mit dem Cache-Speichersystem als separate
PIT-Leseanforderung verarbeitet. Das Cache-Speichersystem kann wählen, jedes
Fragment unabhängig
von den anderen oder als eine einzige Leseanforderung zu bearbeiten,
wobei es die Festplattendaten wieder dem Arbeitslastinjektor bereitstellt,
wenn dieser zur Verfügung
steht. Wenn ein Datenfragment vom Cache-Speicher bereitgestellt
wird (entweder einzeln oder als Teil eines einzigen E/A-Vorgangs),
werden die Daten für
die große
Leseanforderung zurück
zum Rechnerknoten zu fließen
beginnen. Der Arbeitslastinjektor sendet für jedes Fragment, für das der
Cache-Speicher Daten zur Verfügung
gestellt hat, dieses Datenfragment in einer FRAG-PIT-Teilabschlussnachricht
zurück
zum Rechnerknoten. Jede FRAG-PIT-Teil-abschlussnachricht übermittelt
Daten ähnlich
wie ein regulärer
PIT-Leseanforderungsabschluss mit dem Unterschied, dass die FRAG-PIT-Teilabschlussnachricht
keinen Interrupt am Rechnerknoten erzeugen wird, wenn sie geliefert
wird. Das zuletzt abgeschlossene Fragment wird mit einer FRAG-PIT-Komplettabschlussnachricht
an den Rechnerknoten zurückgeleitet.
Ein FRAG-PIT-Komplettabschluss unterscheidet sich insofern von einer
Teilabschlussnachricht, dass er den Abschluss der gesamten FRAG-PIT-Leseanforderung mittels
eines Interrupts (eines kompletten Upcalls) signalisiert.
-
Umsetzen eines PIT-Protokolls
auf anderen Netzwerkeinrichtungen
-
Ein
Großteil
der Leistung des vorhergehenden Ansatzes von an ein Netzwerk angehängtem Speicher beruht
auf der Fähigkeit
der Verbindungsstruktur 106 zur Unterstützung des PIT-Protokolls. Im Fall
des BYNET wurde eine Low-Level-Schnittstelle erstellt, die dem PIT-Protokoll
sehr nahekommt. Andere Netzwerkschnittstellen, wie beispielsweise
Fibre Channel, können
das PIT-Protokoll ebenfalls unterstützen.
-
BERMUDADREIECK-PROTOKOLL
-
Die
vorliegenden Erfindung stellt durch die Verwendung von ION-Cliquen 226 und
Write-Back-Zwischenspeicherung (Zwischenspeicherung mit Zurückschreiben)
Daten- und E/A-Redundanz bereit. ION-Cliquen umfassen mehrere IONs
(in der Regel in Paaren oder Dipolen eingesetzt, wie beispielsweise
den IONS 212 und 214, die einen primären ION 212 und
einen Buddy-ION 214 umfassen).
-
Der
Buddy-ION 214 stellt Daten- und E/A-Redundanz bereit, weil
er als ein zeitweiser Speicher für
Kopien der modifizierten Cache-Speicherseiten des primären ION 212 agiert.
Jeder ION 212 in einer ION-Clique 226 (als ein
Paar aus IONs oder ein Dipol dargestellt) fungiert für eine Gruppe
von Volumensätzen
als ein primärer
ION 212 und für
eine andere als der Buddy-ION 214.
-
Um
hohe Verfügbarkeit
und Write-Back-Zwischenspeicherung bereitzustellen, müssen Daten
an mindestens zwei Orten sicher gespeichert werden, bevor einer
Anwendung ein Schreibvorgang bestätigt werden kann. Wenn diese
redundante Kopie nicht bereitgestellt wird, kann es zu Datenverlust
kommen, wenn der Speicherkontroller versagt, nachdem ein Schreibvorgang
bestätigt
wurde, jedoch bevor die Daten auf einem permanenten Speicher aufgezeichnet
wurden.
-
Da
die IONs 212 und 214 jedoch physisch separate
Computer umfassen, ist eine Kommunikation über die Verbindungsstruktur 106 erforderlich,
um diese Sicherheitskopien zu unterhalten. Für eine optimale Systemleistung
ist es notwendig, die Anzahl von BYNET-Übertragungen und dem Schreibprotokoll
zugehörigen Interrupts
zu minimieren und trotzdem weiterhin die Write-Back-Zwischenspeicherung
zu verwenden.
-
Ein
mögliches
Protokoll für
das Schreiben von Daten auf eine Festplatte 224 in einem
Dipol 226 wäre, dass
der Rechnerknoten 200 separat auf den primären ION 212 und
den Buddy-ION 214 schreibt, wartet, bis von beiden IONs 212 und 214 eine
Antwort auf die Schreibanforderungen empfangen worden ist, und der
primäre
ION 212 dann eine Säuberungsanforderung
an den Buddy-ION 214 sendet, die anzeigt, dass er nicht länger eine
Kopie der Seite aufbewahren muss.
-
Angenommen,
dass „Senden
abgeschlossen"-Interrupts
auf der sendenden Seite unterdrückt
werden, erfordert dieses Protokoll mindestens fünf Interrupts, da jede gesendete
Nachricht auf dem Rechnerknoten 200 oder den IONs 212 und 214 einen
Interrupt erzeugt.
-
Ein
weiteres mögliches
Protokoll weist den primären
ION 212 an, Schreibanforderungen an den Buddy-ION 214 zu
senden, auf eine Antwort zu warten und die Bestätigung zurück an den Rechnerknoten 200 zu senden.
Dieses Protokoll erfordert ebenfalls mindestens fünf Interrupts.
Der erste Interrupt erfolgt, wenn der Rechnerknoten 200 die
Schreibanforderung an den primären
ION 212 übermittelt.
Der zweite Interrupt erfolgt, wenn der primäre ION 212 Daten an
den Buddy-ION 214 übermittelt.
Der dritte Interrupt erfolgt, wenn der Buddy-ION 214 den
Empfang der Daten bestätigt.
Der vierte Interrupt erfolgt, wenn der primäre ION 212 dem Rechnerknoten 200 antwortet,
und der endgültige
Interrupt erfolgt, nachdem die Daten sicher auf die Festplatte übertragen
worden sind und der primäre
ION 212 dem Buddy-ION 214 eine Säuberungsanforderung
sendet.
-
11 stellt ein in der vorliegenden Erfindung verwendetes
Protokoll dar, das die Anzahl von zum Verarbeiten einer Schreibanforderung
erforderlichen Interrupts minimiert. Dieses Protokoll wird als das
Bermudadreieck-Protokoll bezeichnet.
-
Erstens
gibt der Rechnerknoten 200 eine Schreibanforderung an den
primären
ION 212 aus. Zweitens sendet der primäre ION die Daten an den Buddy-ION 214.
Drittens sendet der Buddy-ION 214 die Bestätigung an
den Rechnerknoten 200. Schließlich, wenn die Daten sich
sicher auf der Festplatte befinden, sendet der primäre ION 212 dem
Buddy-ION 214 eine Säuberungsanforderung.
-
Die
vier oben geschilderten Schritte erfordern insgesamt vier Interrupts.
Um die Interrupts weiter zu reduzieren, können die Säuberungsanforderungen (Schritt 4 in
der 11) verzögert und mit der Datenübertragung
eines anschließenden
Schreibvorgangs in Schritt 2 kombiniert werden, um ein
Protokoll mit drei Interrupts zu erzielen. Ein zusätzlicher
Vorteil dieses Protokolls besteht darin, dass der primäre ION 212,
wenn der Buddy-ION 214 beim Empfangen der Schreibanforderung
außer
Betrieb ist, die Anforderung im Write-Through-Modus (Durchschreibmodus)
verarbeiten und den Schreibvorgang bestätigen kann, wenn sich die Daten
sicher auf der Festplatte befinden. Der Rechnerknoten 200 braucht
den Status des Buddy-ION 214 nicht zu kennen.
-
Das
Bermudadreieck-Protokoll ermöglicht
die Write-Back-Zwischenspeicherung
mit weniger Interrupts als bei herkömmlichen Protokollen, wobei
gleichzeitig die Datenverfügbarkeit
bewahrt wird. Dies ist möglich,
weil der Buddy-ION 214 die Bestätigung von an den primären ION 212 gesendeten
Schreibanforderungen durchführt.
In Anbetracht dessen, dass die Interrupt-Verarbeitung auf modernen
leitungsgebundenen Prozessoren teuer sein kann, resultiert dieses
Protokoll, das in einer großen
Vielfalt von Architekturen eines verteilten Speichersystems verwendet
werden kann, in einem geringeren Gesamtsystem-Overhead und einer
verbesserten Leistung.
-
RECHNERKNOTEN Überblick
-
Die
Rechnerknoten 200 führen
die Benutzeranwendungen 204 aus. In Systemen des Stands
der Technik wird eine Reihe von fest zugeordneten geteilten SCSI-Bussen
verwendet, um den Knoten innerhalb eines Clusters oder einer Clique
einen gleichberechtigten Speicherzugriff zu ermöglichen. In der vorliegenden
Erfindung wird der Speicher über
eine oder mehrere Kommunikationsstrukturen 106 an die Rechnerknoten 200 angehängt. Dieser
an das Netzwerk angehängte
Speicher teilen sich die Kommunikationsstrukturen 106 mit IPC-Verkehr
(IPC = inter-process communication, Interprozesskommunikation) unter
den Benutzeranwendungen 204, die über die Rechnerknoten 200 verteilt
sind. Speicheranforderungen von den Benutzeranwendungen 204 werden
von der Struktur/der Speicherschnittstelle in IPC-Nachrichten an
auf den IONs 212 angeordnete Speicherverwaltungsanwendungen
verkapselt. Diese fest zugeordneten Anwendungen auf den Speicherknoten
wandeln die IPC-Nachrichten in lokale Cache-Speicher- oder Festplatten-E/A-Vorgänge um und senden
die Ergebnisse gegebenenfalls zu den Rechnerknoten 200 zurück. Für eine Benutzeranwendung 204 sind
der an das Netzwerk angehängte
Speicher und der lokal angehängte
Speicher nicht zu unterscheiden.
-
Lese-
und Schreibanforderungen für
virtuelle Festplattenblöcke
treffen mittels der Verbindungsstruktur 106 am ION 212 ein.
Anforderungen können
durch quelleninitiierte Auswahl an den Rechnerknoten 200 zu
einem spezifischen ION 212 geleitet werden. Jeder Rechnerknoten 200 weiß, welcher
ION 212 Anforderungen für
jede virtuelle Festplatte der Struktur im System annehmen wird.
Eine virtuelle Festplatte der Struktur spiegelt ein Modell einer
virtuellen Festplatte wider, in dem ein eindeutiger Speicherumfang
dargestellt ist, der Speicherumfang jedoch die physischen Orte der
physischen Festplatte/n im Namen weder andeutet noch kodiert.
-
Jeder
Rechnerknoten 200 unterhält eine Liste, die die Namen
der virtuellen Festplatte der Struktur auf den ION-Dipolen 226 abbildet.
Die Liste wird durch Koordination zwischen den Rechnerknoten 200 und
den IONs 212 dynamisch erstellt. Während des Hochfahrens und Fehlerwiederherstellungsvorgängen teilen
die IONs 212 in einem Dipol 226 die virtuellen
(und die physischen) Festplatten untereinander auf und erstellen eine
Liste davon, welcher ION 212 welche virtu elle Festplatte
besitzt. Der andere ION 214 im Dipol 226 (der keine
virtuelle Festplatte oder Speicherressource besitzt) stellt im Fall
eines Versagens einen alternativen Pfad zur virtuellen Festplatte
bereit.
-
Diese
Liste wird in regelmäßigen Abständen über die
Verbindungsstruktur 106 hinweg an alle anderen Dipole 226 und
Rechnerknoten 200 exportiert oder diesen angepriesen. Die
Rechnerknoten 200 verwenden diese Daten, um eine Mastertabelle
von primären
und sekundären
Pfaden zu jeder virtuellen Festplatte im System zu erstellen. Ein
Verbindungsstrukturtreiber im Rechnerknoten 200 stimmt
sich dann mit dem Dipol 226 zum Routing der E/A-Anforderungen
ab. Die Dipole 226 verwenden diese „Selbstentdeckungs"-Technik zum Erkennen
und Korrigieren von Inkonsistenzen in der Benennung der virtuellen
Festplatten, die auftreten können,
wenn Dipole 226 zu einem aktiven System hinzugefügt oder
aus diesem entfernt werden.
-
Auf
den Rechnerknoten 200 laufende Anwendungen sehen ein Blockschnittstellenmodell,
wie eine lokale Festplatte für
jede virtuelle Festplatte der Struktur, die zum Rechnerknoten 200 exportiert
wird. Wie zuvor hierin beschrieben wurde, erstellen die Rechnerknoten
200 beim Neustarten einen Eingangspunkt zu jeder virtuellen Festplatte
der Struktur und aktualisieren diese Eingangspunkte dynamisch unter
Verwendung eines Benennungsprotokolls, das zwischen den Rechnerknoten 200 und
den IONs 212 eingerichtet wurde.
-
SERVERVERWALTUNG
-
Überblick
-
Ein
wichtiger Aspekt der vorliegenden Erfindung ist ihre Verwaltung,
bei der es sich um einen Teilsatz der Gesamtverwaltung handelt,
die als Systemverwaltung oder Systemadministration bezeichnet wird.
Dieser Teilsatz wird Ser ververwaltung für Speicher (server management
for storage, SMS) genannt. Die Verwaltung von den Speicher betreffenden
Hardware- und Softwarekomponenten sowie die Platzierung von Dateneinheiten
im verfügbaren
Speicherplatz werden durch diese Einrichtung umgesetzt. Verwaltungs-aktionen
können von
einem Administrator initiiert oder bei Eintreten eines beliebigen
Ereignisses im System dynamisch aufgerufen werden. Verwaltungsbefehle
können
eingegeben und fast sofort bestätigt
werden, die Ergebnisse eines einzigen, einfachen Befehls könnten jedoch
leicht eine große
Anzahl von Systemkomponenten eine erhebliche Zeitdauer lang beeinträchtigen.
Das Abschließen
des Verschiebens eines Volumensatzes von einem ION 212 zu
einem anderen ION beispielsweise kann viele Minuten oder sogar Stunden
in Anspruch nehmen und sich auf mehrere IONs 212 und den/die
Rechnerknoten 200 auswirken, die das Subjektdateisystem
verwenden möchten.
Die Serververwaltung zeichnet sich auch für das Versorgen des Administrators
mit informativen Nachrichten und Warnmeldungen zum Zustand der Systemhardware
und -software verantwortlich.
-
Der
Administrator nimmt das System vorwiegend über eine Reihe von „Ansichten" der Bildschirmanzeige
wahr. Es können
mehrere Ansichten des Gesamtsystems präsentiert werden. Die primäre Ansicht
ist eine hierarchische Ansicht, in dessen oberster Ebene alle Rechnerknoten 200,
IONs 212 und Strukturen 106 im System gezeigt
werden. Aufrisstechniken ermöglichen
detailliertere Anzeigen von Elementen von Interesse. Die meisten
Systeme sind so groß,
dass die Größe und Komplexität nicht
auf einer einzigen Anzeigeseite wiedergegeben werden kann. Graphische
Ansichten werden so wiedergegeben, dass sie entweder eine physische
(geografische) oder eine logische Ansicht zeigen. Einzelne Einheiten
oder Gruppen von Einheiten können
für eine
detailliertere Ansicht und für
die Administration ausgewählt
werden und die Ergebnisse von Anforderungen können in vom Benutzer ausgewählten Formaten
angezeigt werden.
-
Es
wird auch ein tabellarisches Darstellungsverfahren bereitgestellt
und einzelne Elemente oder Gruppen können in dieser Ansicht angesehen
und administriert werden. Ein wichtiger Aspekt dieser Verwaltung
ist die Darstellung des Pfads eines bestimmten Datenteils von einem
bestimmten Rechnerknoten 200 bis zu der/den physischen
Speicherplatte/n 224, die dieses enthält/enthalten. Dieser Pfad wird
in tabellarischer Form dargestellt und zeigt dabei seine Ausfallsicherheit
auf – d.
h. wieviele separate Komponentenfehler auftreten müssen, bevor
die Daten nicht mehr verfügbar
sind.
-
Erstellen
von Volumensätzen
-
Das
Erstellen eines Volumensatzes (VS) teilt freien Platz zu, der von
einer Anwendung 204 des Host-Rechnerknotens 200 verwendet
werden soll. Volumensätze
befinden sich in einem ION 212 und weisen Namen (die hierin
beschriebenen VSIs 602), Größen und RAID-Datenschutzniveaus
(RAID = redundant array of inexpensive disks, redundante Anordnung
preisgünstiger
Festplatten) auf. Der Systemadministrator erstellt den VS auf Grundlage
der Erfordernisse und kann den Ort und die Redundanzcharakteristika
spezifizieren. Mit Gruppenvorgängen
können
mehrere VSs erstellt werden.
-
Betriebsübersicht
-
12 ist ein Flussdiagramm, dass die beim Praktizieren
einer Ausführungsform
der vorliegenden Erfindung ausgeführten Operationen zeigt. Zuerst
wird eine global eindeutige ID wie eine VSI 602 in dem
ION 212 oder Dipol 226 für einen Datenumfang erzeugt
(1102), der physikalisch in der Vielzahl von Speichergeräten gespeichert
ist, die an dem ION 212 oder dem Dipol 226 befestigt
sind. Als nächstes
wird die global eindeutige ID an den Datenumfang gebunden (1104).
Schließlich
wird die global eindeutige ID von dem ION 212 oder dem Dipol 226 über die
Verbindungsstruktur 106 zu den Computerknoten 200 exportiert
(1106).
-
13 ist ein Flussdiagramm, das die Operationen
zeigt, die beim Erzeugen einer global eindeutigen ID in den ION 212 oder
den Dipol 226 für
einen Datenumfang ausgeführt
werden, der physikalisch in der Vielzahl von Speichergeräten gespeichert
ist. Zuerst wird ein global eindeutiger I/O-Knoten-Identifizierer gelesen (1202).
In einer Ausführungsform
wird dies durch ein elektronisches Lesen der Seriennummer des mother boards
von der Hardware erreicht, die den ION 212 implementiert.
Als nächstes
wird ein Datenumfangs-Identifizierer
erzeugt (1204), der lokal eindeutig für den ION 212 oder
den Dipol 226 ist. Dieser Datenumfangs-Identifizierer kann zum Beispiel eine
reell zugeordnete Nummer oder Zeichen sein. Dann werden der global
eindeutige Identifizierer des ION 212 und der Datenumfangs-Identifizierer kombiniert
(1206), um die global eindeutige Idee zu bilden.
-
14 ist ein Flussdiagramm, das Operationen zeigt,
die beim Exportieren der global eindeutigen ID zu den Computerknoten 200 über die
Verbindungsstruktur 106 durchgeführt werden. Als erstes wird
eine Mitteilung von einem Computerknoten 200 in den ION 212 empfangen
(1302). Diese Mitteilung umfasst optional eine Signatur,
die sicher den Computerknoten 200 identifiziert. Dann wird
die Signatur geprüft,
um zu authentifizieren (1304), das die Mitteilung tatsächlich von
dem Computerknoten 200 empfangen wurde. Falls die Authentifizierung
fehl schlägt,
wird die global eindeutige ID nicht gesendet. Falls die Authentifizierung
erfolgreich ist, wird die global eindeutige ID von dem ION 212 zu
dem Computerknoten 200 übertragen
(1306). Diese global eindeutige ID kann optional lokale
Zugriffsrechte für optional
lokale Zugriffsrechte für
die Daten umfassen, die mit der ID verbunden sind.
-
Zusammengefasst
werden ein Verfahren und eine Vorrichtung zum Kommunizieren von
Daten in einer parallel verarbeitenden Computerarchitektur beschrieben.
Das Verfahren umfasst die Schritte des Erzeugens einer global eindeutigen
ID in dem I/O-Knoten für
einen Datenumfang, der physikalisch in der Vielzahl von Speichereinrichtungen
gespeichert ist, des Bindens der global eindeutigen ID an den Datenumfang,
und des Exportierens der global eindeutigen ID zu den Computerknoten über die
Verbindungsstruktur. In einer Ausführungsform wird die global
eindeutige ID von einem global eindeutigen I/O-Knoten-Identifizierer
und einem lokal eindeutigen Datenumfangsidentifizierer erzeugt.
Ein lokaler Eingangspunkt wird in dem Computerknoten für die Daten
erzeugt, die mit der global eindeutigen ID verbunden sind, wodurch
die global eindeutige ID als ein Einrichtungspunkt in dem Computerknoten
präsentiert
wird. In einer Ausführungsform
umfasst der Schritt des Exportierens der global eindeutigen ID zu
den Computerknoten den Schritt des Empfangens einer Mitteilung von
dem Computerknoten, die eine Signatur umfasst, die die Mitteilung
sicher an den I/O-Knoten identifiziert, des Authentifizierens der
Quelle der Mitteilung unter Verwendung der Signatur, und des Übertragens
der global eindeutigen ID umfassend Daten, die lokale Zugriffsrechte
an den Daten spezifizieren, die durch die global eindeutige ID repräsentiert
werden, von dem I/O-Knoten zu dem Computer-Knoten.
-
Die
vorhergehende Beschreibung der bevorzugten Ausführungsform der Erfindung ist
aus Veranschaulichungs- und Beschreibungszwecken dargestellt worden.
Sie soll nicht als vollständig
sind oder die Erfindung auf die konkrete offenbarte Form beschränken. Im
Licht der obigen Lehre sind viele Modifikationen und Veränderungen
möglich.
Der Schutz umfang der Erfindung soll nicht durch diese ausführliche
Beschreibung, sondern vielmehr durch die hieran angehängten Ansprüche beschränkt sein.