DE69923243T2

DE69923243T2 - Dynamische und konsistente Namensverwaltung von Speicher der zu einer Kommunikationsstelle verbunden ist

Info

Publication number: DE69923243T2
Application number: DE69923243T
Authority: DE
Inventors: Kit M. Carlsbad Chow; Michael W. Encinitas Meyer; Keith P. San Diego Muller; Alan P. San Diego Adamson
Original assignee: NCR International Inc
Current assignee: Teradata US Inc
Priority date: 1998-02-06
Filing date: 1999-02-01
Publication date: 2006-03-23
Anticipated expiration: 2019-02-02
Also published as: EP0935374A1; JP2000090061A; EP0935374B1; JP4618654B2; US6148349A; DE69923243D1

Description

Die vorliegende Erfindung bezieht sich allgemein auf Rechnersysteme und insbesondere auf ein Verfahren und eine Vorrichtung zur dynamischen und konsistenten Namensgebung von strukturgebundenem Speicher.
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 CPU-Leistungsvermögen, (2) der Entwicklung interner CPU-Architekturen und (3) von Verbindungsstrukturen.
Dokument US-A-5 671 441 bezieht sich auf Verfahren zur automatischen Identifizierung von I/O-Komponenten. Dokument EP-A-0 365 115 offenbart einen Identifizierungsgenerator, der eine eindeutige Identifizierung für Objekte in einem verteilten Computersystem erzeugt. Dokument US-A-5 303 383 offenbart, wie Schaltknoten verbunden werden, um ein Netzwerk zu implementieren.
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 Festplattenlauf werke 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.
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 großen Datenverarbeitungssysteme, die oben beschrieben wurden, stellen für eine Fehlertoleranz und Datensicherheit eine vergrößerte Redundanz bereit. Derartige Systeme erfordern jedoch einen ortsunabhängigen Namensdienst für strukturgebundenen Speicher und einen, der mit bestehenden Datenbank API's kompatibel ist, die begrenzte Bitlängennamen sind.
Es ist eine Aufgabe der vorliegenden Erfindung, den obigen Nachteilen zu begegnen.
Die vorliegende Erfindung stellt ein Verfahren gemäß dem beigefügten Anspruch 1, eine Vorrichtung gemäß dem Anspruch 3, eine Programmspeichereinrichtung und ein Parallel verarbeitungssystem gemäß den Anspruchen 5 und 7 bereit.
Die vorliegende Erfindung stellt ein Parallelverarbeitungssystem bereit. Das System umfasst eine Vielzahl von Computerknoten zum Ausführen von Anwendungen über eine Speicheranwendungs-Programmierungs-Schnittstelle, die System-Eingang/Ausgang-Aufrufe aufweisen, eine Vielzahl von I/O-Knoten und ein Dateisystem, das auf dem Computerknoten implementiert ist, zur Speicherung von Informationen, die API-System-Eingang/Ausgang-Aufrufe für das Datenobjekt mit der global eindeutigen Identifizierung für das Datenobjekt zuordnen. Jeder I/O-Knoten managt eine kommunizierend verbundene Vielzahl von Speicherressourcen und jeder weist ein Mittel zur Erzeugung einer global eindeutigen Identifizierung für ein Datenobjekt auf, das auf der Speicherressource gespeichert ist, und überträgt die global eindeutige Identifizierung und das Datenobjekt über mindestens eine verbindende Struktur, die eine Kommunikation zwischen jedem der Computerknoten und jedem der I/O-Knoten bereitstellt, zu dem Computerknoten.
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 hostseitigen BYNET-Schnittstelle;
9 ein Schaubild des PIT-Kopfteils;
10 ein Blockschema der Funktionsmodule des ION 212;
11 ein Schaubild, das das ION-Dipolprotokoll zeigt;
12 einen Ablaufplan von Betriebsschritten, die verwendet werden, um einen Datenumfang von einem ION zu einem Computerknoten zu kommunizieren; und
13 einen Ablaufplan von Betriebsschritten, die verwendet werden, um eine global eindeutige Identifizierung für den Datenumfang in der Ausführungsform der vorliegenden Erfindung zu erzeugen.
Ü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.
Tabelle I
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 adapterspezifischen 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) im Hardwareschnittstellenmodul (hardware interface module, HIM) 508 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 (tape)) 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 Wiederho lungsmaximum 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 beschriebenen 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 E/A-Vektors (I/O vector, 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 bei spielsweise 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.
Tabelle III
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, Fehlerhandhabungstechniken 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.
AUSFALLSICHERUNGSHANDHABUNG
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 zugewiesen 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, struktureindeutigen 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. Eine weitere Technik, die die Zuordnung einer global eindeutigen VSI garantiert, ist es, die Knoten-ID des ION 212 zu verwenden, die beim Aufbooten für den global eindeutigen ION-Identifizierer 604 erhalten wird. In ähnlicher Weise kann, wenn multiple Systeme verbunden werden, eine System-ID, die eindeutig den anderen bezogenen Systemen durch die AWS zugeordnet ist, verwendet werden, um einen global eindeutigen ION-Identifizierer 604 zu erzeugen.
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 Namenskonsis tenz 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 Ein richtungseingangspunkten. 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 enthalte nen 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 Zeitpunkt, 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 Rech nerknoten 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.
Drei SCSI-Befehle werden zum Umsetzen der SES-Schnittstelle verwendet: ABFRAGEN, DIAGNOSE SENDEN und DIAGNOSEERGEBNISSE EMPFANGEN. Der ABFRAGEN-Befehl spezifiziert, ob die spezifische 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.
Tabelle VII
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 Verwaltungsdienstschicht 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überwachung 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 ein 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 Statusinformationen 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 Komponenteneinrichtungen 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 KOMPO-NENTENEINRICHTUNGSKENNUNG 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 Vorteile 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, es wird doch anfangs vernünftig verwendet, wie wir die Vorteile und Nachteile des spezifischen Gestaltungsalgorithmus herausfinden. Antworten von Experimenten und Erfahrungen werden angewendet, um diese Algorithmen zu verstärken, die sogar für vorhersagbare Verkehrsmuster vom Benutzer auswählbar sein können.
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 Kanalpro gramm 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(log_bN) Schaltungsknotenstufen 812 angeordnet, wobei b die Gesamtanzahl der Eingangs-/Ausgangsanschlü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 Gruppenruf-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 sen derbasierten 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 Zielortknoten 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, wo die Festplattendaten an einen SCSI-High-Level-System-Treiber (Verbindungsprotokolltreiber des virtuellen Speichers) übertragen werden sollen. Der CN-Systemtreiber weist eine Schnittstelle mit der Anwendung 204 und dem Strukturtreiber auf dem Computerknoten 200 auf, wickelt die Namensgebung ab und stellt eine binär kompatible Plattenschnittstelle bereit. 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) im 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) Lastschriften-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 Fest plattenlaufwerklesevorgang. 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 abgeschlossen 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.
Das PIT-Protokoll muss zwischen den zwei Knoten auf dem BYNET freigegeben werden. Das Freigeben des PIT-Protokolls wird typischerweise während der Start-of-Day(SOD)-Verarbeitung zwischen einem Knoten ION 212 und einem Buddy-ION 214 durchgeführt oder dann durchgeführt, wenn ein Computerknoten 200 auf irgendeinem VSI 602 auf einem speziellen ION 212 zum ersten Mal zugreift, seit dieser gebootet hat. Die Schritte zur Freigabe des PIT-Protokolls zwischen zwei Knoten (z.B. Knoten A und Knoten B) enthält die Schritte (1) des Initiierens, dass der Knoten (Knoten A) eine PIT-Anbindungsanforderung an den Knoten B ausgibt, (2) des Austauschens von PIT-ID's zwischen dem Knoten A und dem Knoten B, (3) der Freigabe von BYNET-gerichteten Bandmitteilungsübertragungen durch den VSIP-Treiber des initiierenden Knotens (hier: Knoten A), und (4) der Freigabe von BYNET-gerichteten Bandmitteilungsübertragungen und der Freigabe von BYNET-gerichteten Bandmitteilungsübertragungen vom Knoten A durch den VSIP-Treiber auf den Knoten B.
Der empfangende Knoten (Knoten B) hat die absolute Kontrolle, über welche Knoten das BYNET PIT-Pakete an diesen senden kann. Die PIT-Übertragungen zu dem empfangenden Knoten (Knoten B) werden fehlschlagen, es sei denn, gerichtete Bandübertragungen von dem sendenden Knoten sind durch den empfangenden Knoten freigegeben, da dieser gebootet hat. Somit werden, wenn ein Knoten ausfällt und neu startet, die vor dem Ausfall ausgetauschten und durch die entfernten Knoten gehaltenen PIT-ID's des ausgefallenen Knotens automatisch unwirksam gemacht, da direkte Bandübertragungen nicht möglich sind. Dies schützt gegen die Lieferung von jeglichen abgelaufenen PIT-Paketen, bis das PIT-Protokoll freigegeben worden ist.
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 eingereihten 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 Gesamtbedienzeit, 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 Rechner knoten 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 weder 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 beliebi ge 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) angeglichenes 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-Start nachricht 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 Arbeitslastinjektor 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-Speicher system 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 abschließ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 Daten lä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 virtuelle 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.
Schnittstelle mit bestehenden Speicher-API's
Die Namen von strukturgebundenen Speichern, die durch die VSI 602 repräsentiert werden, sollten mit bestehenden Speicheranwendungs-Programmierungs-Schnittstellen (API's) 232 kompatibel sein, die mit Anwendungen 204 implementiert werden, die auf dem Computerknoten 200 laufen. Dies erlaubt den Anwendungen, die Namen der strukturgebundenen Speicher ohne Modifizierung zu verwenden.
Ein typischer Speicher-API enthält open()-, read()-, und write()-Systemaufrufe. In Computerknoten 200, die das UNIX-Betriebssystem 202 verwenden, wird z.B. ein open()-Systemaufruf auf einem Speichernamen-UNIX-Einrichtungsknoten ausgeführt, der eine spezielle Datei ist, der bis zu 22 Bitinformation codiert. Währenddessen sind 22 Bits für Zwecke einer ortsgebundenen Speicherung adequat, da sie ausreichend sind, um den physikalischen Ort der Speichereinrichtung relativ zu dem lokalen Host zu codieren. Für die hier beschriebenen Namens-Schemata strukturgebundener Speicher werden 22 Bit jedoch häufig ungenügend sein, um alle Informationen zu enthalten, die für den Namen erforderlich sind, beispielsweise ist bei dem Codieren der Knoten-ID (10 Bit) und der System-ID (8 Bit) in den Speichernamen für eine automatisierte Speichernamenzuordnung ein 22-Bit-Wort ungenügend. Folglich muss in den Knoten der UNIX-Einrichtung mehr Information codiert werden, als es gewöhnlich möglich ist, und um die Rückwärtskompatibilität zu erhalten, muss dies erreicht werden, ohne die bestehende API 232 zu modifizieren.
Die vorliegende Erfindung bringt dieses Kunststück mit einem Dateisystem zustande, das auf dem Computerknoten implementiert ist, der Informationen speichert, die API-System-Eingang/Ausgang-Aufrufe für Datenobjekte mit der global eindeutigen ID auflistet. In einer Ausführungsform wird dies erreicht, indem der Systemaufruf codiert wird, um eindeutig den Ort von einem indirekten Zeiger zu identifizieren, der auf Informationen weist, die in dem Dateisystem über dem Namen des Speicherinhalts von Interesse gespeichert ist. Dies enthält die VSI und die TON-Idenfikation, die die Daten managt, die durch diesen VSI definiert sind. Dies ermöglicht, dass eine unbegrenzte Menge von Information gelistet wird. Des Weiteren ist diese gelistete Information aktualisiert, wie es passend ist, um sicherzustellen, dass der strukturbezogene Speicher aktuell ist.
12 ist ein Ablaufplan, der die Betriebsschritte beschreibt, die verwendet werden, um einen Volumensatz oder einen Datenumfang von den ION's 212 zu den Computerknoten 200 zu kommunizieren. Zuerst wird eine global eindeutige Identifizierung (so wie eine VSI) für den Datenumfang in dem ION 212 erzeugt (1102). Dann wird die global eindeutige ID an den Datenumfang gebunden (1104) und über die Verbindungsstruktur 106 zu den Computerknoten 200 exportiert (1106).
13 ist ein Ablaufplan, der die Betriebsschritte beschreibt, die verwendet werden, um die global eindeutige ID in dem I/O-Knoten in einer Ausführungsform der vorliegenden Erfindung zu erzeugen. Zuerst wird ein global eindeutiger I/O-Knoten-Identifizierer von einem Administrationsknoten 230 gelesen (1202). Dieser global eindeutige I/O-Knoten-Identifizierer kann die AWS-Knoten-ID oder System-ID oder einer Kombination von beiden (ID's) umfassen. Dann wird ein Datenumfangsidentifizierer, der für den ION 212 eindeutig ist, erzeugt (1209). Dann werden der global eindeutige I/O-Knoten-Identifizierer und der lokal eindeutige Datenumfangsidentifizierer kombiniert (1206). Das Resultat ist ein global eindeutiger Identifizierer für den Datenumfang.
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 Serververwaltung 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üns tiger 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.
Zusammenfassend wird ein Parallelverarbeitungssystem beschrieben. Das System umfasst eine Vielzahl von Computerknoten zum Ausführen von Anwendungen über eine Speicheranwendungs-Schnittstelle, die System-Eingang/Ausgang-Aufrufe aufweisen, eine Vielzahl von I/O-Knoten, und ein Dateisystem, das auf dem Computerknoten implementiert ist, zur Speicherung von Informationen, die API-System-Eingang/Ausgang-Aufrufe für das Datenobjekt mit der global eindeutigen Identifizierung für das Datenobjekt zu ordnen. Jeder I/O-Knoten managt eine kommunizierend verbundene Vielzahl von Speicherressourcen und jeder weist ein Mittel zum Erzeugen einer global eindeutigen Identifizierung für ein Datenobjekt auf, das auf der Speicherressource gespeichert ist, und überträgt die global eindeutige Identifizierung und das Datenobjekt zu dem Computerknoten über mindestens eine verbindende Struktur, die eine Kommunikation zwischen jedem der Computerknoten und jedem der I/O-Knoten bereitstellt.
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 Schutzumfang der Erfindung soll nicht durch diese ausführliche Beschreibung, sondern vielmehr durch die hieran angehängten Ansprüche beschränkt sein.

Claims

Verfahren zum Kommunizieren von Daten für ein Vielknoten-Computersystem, das eine Vielzahl von Computerknoten (200) und eine Vielzahl von Eingang/Ausgang-I/O-Knoten (212, 214) umfasst, die über mindestens eine verbindende Struktur (106) kommunizierend mit den Computerknoten verbunden sind, wobei jeder I/O-Knoten kommunizierend mit einer Vielzahl von Speichereinrichtungen (102, 104) verbunden ist, umfassend die Schritte: – Erzeugen einer global eindeutigen Identifizierung, ID, für einen Datenumfang, der physikalisch in der Vielzahl von Speichereinrichtungen gespeichert ist, in dem I/O-Knoten durch Lesen eines global eindeutigen I/O-Knoten-Identifizierers von einem Administrationsknoten, Erzeugen eines Datenumfangs-Identifizierers, der für den I/O-Knoten lokal eindeutig ist, und Kombinieren des global eindeutigen I/O-Knoten-Identifizierers mit dem lokal eindeutigen Datenumfangs-Identifizierer; – Binden der global eindeutigen ID an den Datenumfang; und – Exportieren der global eindeutigen ID über die verbindende Struktur zu den Computerknoten.
Verfahren nach Anspruch 1, bei dem der I/O-Knoten-Identifizierer beim I/O-Knoten-Start von dem Administrationsknoten gelesen wird.
Vorrichtung zum Kommunizieren von Daten in einem Vielknoten-Computersystem, umfassend eine Vielzahl von Computerknoten (200) und eine Vielzahl von Eingang/Ausgang-I/O-Knoten (212, 214), die über mindestens eine verbindende Struktur (106) kommunizierend mit den Computerknoten verbun den sind, wobei jeder I/O-Knoten kommunizierend mit einer Vielzahl von Speichereinrichtungen (102, 104) verbunden ist, umfassend: – Mittel zum Erzeugen einer global eindeutigen Identifizierung, ID, für einen Datenumfang, der physikalisch in der Vielzahl von Speichereinrichtungen gespeichert ist, in dem I/O-Knoten durch Lesen eines global eindeutigen I/O-Knoten-Identifizierers von einem Administrationsknoten, Erzeugen eines Datenumfangs-Identifizierers, der für den I/O-Knoten lokal eindeutig ist, und Kombinieren des global eindeutigen I/O-Knoten-Identifizierers mit dem lokal eindeutigen Datenumfangs-Identifizierer; – Mittel zum Binden der global eindeutigen ID an den Datenumfang; und – Mittel zum Exportieren der global eindeutigen ID über die verbindende Struktur zu den Computerknoten.
Vorrichtung nach Anspruch 3, bei der der I/O-Knoten-Identifizierer beim I/O-Knoten-Start von dem Administrationsknoten gelesen wird.
Programmspeichereinrichtung, die durch einen Computer lesbar ist und ein oder mehrere Programme von Instruktionen verkörpert, die durch den Computer ausführbar sind, um Verfahrensschritte eines Kommunizieren von Daten für ein Vielknoten-Computersystem auszuführen, das eine Vielzahl von Computerknoten (200) und eine Vielzahl von Eingang/Ausgang-I/O-Knoten (212, 214) umfasst, die über mindestens eine verbindende Struktur (106) kommunizierend mit den Computerknoten verbunden sind, wobei jeder I/O-Knoten kommunizierend mit einer Vielzahl von Speichereinrichtungen (102, 104) verbunden ist, wobei die Verfahrensschritte umfassen: – Erzeugen einer global eindeutigen Identifizierung, ID, für einen Datenumfang, der physikalisch in der Vielzahl von Speichereinrichtungen gespeichert ist, in dem I/O-Knoten durch Lesen eines global eindeutigen I/O-Knoten-Identifizierers von einem Administrationsknoten, Erzeugen eines Datenumfangs-Identifizierers, der für den I/O-Knoten lokal eindeutig ist, und Kombinieren des global eindeutigen I/O-Knoten-Identifizierers mit dem lokal eindeutigen Datenumfangs-Identifizierer; – Binden der global eindeutigen ID an den Datenumfang; und – Exportieren der global eindeutigen ID über die verbindende Struktur zu den Computerknoten.
Programmspeichereinrichtung nach Anspruch 5, bei der der I/O-Knoten-Identifizierer beim I/O-Knoten-Start von dem Administrationsknoten gelesen wird.
Parallelverarbeitungssystem, das umfasst: eine Vielzahl von Computerknoten (200) zum Ausführen von Anwendungen über eine Speicheranwendungs-Programmierungs-Schnittstelle, API, die System-Eingang/Ausgang-Aufrufe aufweisen; eine Vielzahl von Eingang/Ausgang-I/O-Knoten (212, 214), wobei jeder eine kommunizierend verbundene Vielzahl von Speicherressourcen (102, 104) steuert und jeder ein Mittel zum Erzeugen einer global eindeutigen Identifizierung für ein auf der Speicherressource gespeichertes Datenobjekt und zur Übertragung der global eindeutigen Identifizierung und des Datenobjekts über mindestens eine verbindende Struktur (106) zu dem Computerknoten aufweist, wobei eine Kommunikation zwischen jedem der Computerknoten und jedem der I/O-Knoten bereitgestellt wird; und ein Dateisystem, das auf dem Computerknoten implementiert ist, zur Speicherung von Informationen, die API-System-Eingang/Ausgang-Aufrufe für das Datenobjekt mit der globaleindeutigen Identifizierung für das Datenobjekt zuordnen.
Parallelverarbeitungssystem nach Anspruch 7, bei dem das Dateisystem Informationen speichert, die das Datenobjekt dem I/O-Knoten zuordnet, der die Speicherressource steuert, die das Datenobjekt speichert.
Parallelverarbeitungssystem nach Anspruch 7, bei dem die System-Eingang/Ausgang-Aufrufe einen indirekten Zeiger zu dem Dateisystem umfassen, der die global eindeutige Identifizierung bezeichnet.