DE10392181T5 - Dynamische RDF-Gruppen - Google Patents

Dynamische RDF-Gruppen Download PDF

Info

Publication number
DE10392181T5
DE10392181T5 DE10392181T DE10392181T DE10392181T5 DE 10392181 T5 DE10392181 T5 DE 10392181T5 DE 10392181 T DE10392181 T DE 10392181T DE 10392181 T DE10392181 T DE 10392181T DE 10392181 T5 DE10392181 T5 DE 10392181T5
Authority
DE
Germany
Prior art keywords
data storage
storage system
group
data
devices
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
DE10392181T
Other languages
English (en)
Inventor
Marik Newton Marshak
Mark J. Watertown Halstead
David Cambridge Meiri
Alexandr Brookline Veprinsky
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
EMC Corp
Original Assignee
EMC Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by EMC Corp filed Critical EMC Corp
Publication of DE10392181T5 publication Critical patent/DE10392181T5/de
Ceased legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/133—Protocols for remote procedure calls [RPC]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/54—Store-and-forward switching systems 
    • H04L12/56—Packet switching systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/1666—Error detection or correction of the data by redundancy in hardware where the redundant component is memory or memory area
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
    • G06F11/2053—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where persistent mass storage functionality or persistent mass storage control functionality is redundant
    • G06F11/2056—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where persistent mass storage functionality or persistent mass storage control functionality is redundant by mirroring
    • G06F11/2069—Management of state, configuration or failover
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • G06F13/10—Program control for peripheral devices
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0602—Interfaces specially adapted for storage systems specifically adapted to achieve a particular effect
    • G06F3/0604—Improving or facilitating administration, e.g. storage management
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0628—Interfaces specially adapted for storage systems making use of a particular technique
    • G06F3/0629—Configuration or reconfiguration of storage systems
    • G06F3/0635—Configuration or reconfiguration of storage systems by changing the path, e.g. traffic rerouting, path reconfiguration
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0668—Interfaces specially adapted for storage systems adopting a particular infrastructure
    • G06F3/0671—In-line storage system
    • G06F3/0683—Plurality of storage devices
    • G06F3/0689—Disk arrays, e.g. RAID, JBOD
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F2003/0697—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers device management, e.g. handlers, drivers, I/O schedulers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1097—Protocols in which an application is distributed across nodes in the network for distributed storage of data in networks, e.g. transport arrangements for network file system [NFS], storage area networks [SAN] or network attached storage [NAS]
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
    • Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10S707/00—Data processing: database and file management or data structures
    • Y10S707/99951—File or database maintenance
    • Y10S707/99952—Coherency, e.g. same view to multiple users
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
    • Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10S707/00—Data processing: database and file management or data structures
    • Y10S707/99951—File or database maintenance
    • Y10S707/99952—Coherency, e.g. same view to multiple users
    • Y10S707/99953—Recoverability

Abstract

Verfahren zum dynamischen Modifizieren eines Kommunikationspfades zwischen einer ersten Gruppe von Vorrichtungen in einem ersten Datenspeichersystem und einer zweiten Gruppe von Vorrichtungen in einem zweiten Datenspeichersystem, mit den folgenden Schritten:
Ausgeben einer Befehlsanfrage an das erste Datenspeichersystem, um den Kommunikationspfad dynamisch zu modifizieren;
Durchschleusen von Aufbaudaten von dem ersten Datenspeichersystem zu einem zweiten Datenspeichersystem unter Verwendung eines Kommunikationsverbindungsgliedes, welches nicht dafür bereit ist, Anwenderdaten zu übertragen;
Vorbereiten eines ersten Teiles einer Verbindung zu der ersten Gruppe der Vorrichtungen;
nach einer erfolgreichen Vorbereitung des ersten Teiles, Vorbereiten eines zweiten Teiles der Verbindung zu der zweiten Gruppe der Vorrichtungen; und
nach der erfolgreichen Vorbereitung des ersten und des zweiten Teiles der Verbindung, Anzeigen, daß der Kommunikationspfad dafür bereit ist, um Anwenderdaten zu übertragen.

Description

  • BEZUGSANMELDUNGEN
  • Die vorliegende Anmeldung ist eine Continuation-in-Part der schwebenden U.S.-Patentanmeldung Nr. 09/997,810, eingereicht am 30. November 2001, mit dem Titel "DYNAMIC RDF", welche die Priorität der U.S. Provisional Patent Application Nr. 60/332,991, eingereicht am 14. November 2001, beansprucht, die alle unter Bezugnahme hier mit einbezogen sind.
  • HINTERGRUND
  • Technisches Gebiet
  • Die Anmeldung betrifft allgemein ein Computersystem und spezieller Techniken, die bei der Computersystemkonfiguration verwendet werden.
  • Beschreibung des Standes der Technik
  • Computersysteme können unterschiedliche Ressourcen enthalten, die durch einen oder durch mehrere Hostprozessoren verwendet werden. Die Ressourcen und die Hostprozessoren in einem Computersystem können durch eine oder mehrere Kommunikationsverbindungen miteinander verbunden sein. Diese Ressourcen können beispielsweise Datenspeichervorrichtungen enthalten, wie die Symmetrix®-Familie der Datenspeichersysteme, die von der EMC Corporation hergestellt werden. Diese Datenspeichersysteme können mit einem oder mit mehreren Hostprozessoren gekoppelt werden und schaffen Speicherservices für jeden Hostprozessor. Als Beispiel kann ein Datenspeichersystem einen oder mehrere Datenspeichervorrichtungen enthalten, wie beispielsweise diejenigen der Symmetrix®-Familie, die zusammengeschaltet sind und dazu verwendet werden können, um einen gemeinsamen Datenspeicher für einen oder mehrere Hostprozessoren in einem Computersystem zu schaffen.
  • Ein Hostprozessor kann eine Vielfalt an Datenverarbeitungsaufgaben durchführen und auch Operationen unter Verwendung des Datenspeichersystems. Beispielsweise kann ein Hostprozessor Basissystem-I/O-Operationen in Verbindung mit Datenanfragen durchführen, wie beispielsweise Datenlese- und -schreiboperationen, und auch administrative Aufgaben, wie beispielsweise Datensicherung und Spiegelungsoperationen.
  • Hostprozessorsysteme können Daten speichern und wieder auffinden, und zwar unter Verwendung einer Speichervorrichtung, die eine Vielzahl von Host-Interfaceeinheiten, Plattenlaufwerken und Platten-Interfaceeinheiten enthält. Solche Speichervorrichtungen werden beispielsweise durch die EMC Corporation von Hopkinton, Mass., geliefert und sind in dem U.S. Patent Nr. 5,206,939 von Yanai et al. offenbart, ebenso in 5,778,394 von Galtzur et al., in dem U.S. Patent Nr. 5,845,147 von Vishlitzky et al. und in dem U.S. Patent Nr. 5,857,208 von Ofek. Die Hostsysteme führen einen Zugriff auf die Speichervorrichtung durch, und zwar über eine Vielzahl an Kanälen, die dafür vorgesehen sind. Hostsysteme liefern Daten und auch Zugriffssteuerinformationen über die Kanäle zu der Speichervorrichtung und die Speichervorrichtung liefert Daten zu den Hostsystemen über die Kanäle. Die Hostsysteme adressieren die Plattenlaufwerke der Speichervorrichtung nicht direkt, sondern führen vielmehr einen Zugriff aus, der für die Hostsysteme als eine Vielzahl von logischen Platteneinheiten erscheint. Die logischen Platteneinheiten können oder können auch nicht den aktuellen Plattenlaufwerken entsprechen. Indem man einer Vielzahl von Hostsystemen einen Zugriff erlaubt, ermöglicht die einzelne Speichervorrichtungseinheit den Hostsystemen, die Daten mit zu verwenden, die darin gespeichert sind.
  • In einigen Fällen kann es wünschenswert sein, Daten von einer Speichervorrichtung in eine andere zu kopieren. Wenn beispielsweise ein Host Daten zu einer ersten Speichervorrichtung schreibt, kann es wünschenswert sein, diese Daten zu kopieren, und zwar zu einer zweiten Speichervorrichtung, die an einer verschiedenen Stelle gelegen ist, so daß dann, wenn ein Absturz auftritt, welcher die erste Speichervorrichtung außer Betrieb setzt, der Host (oder ein anderer Host) den Betrieb aufnehmen kann unter Verwendung der Daten der zweiten Speichervorrichtung. Solch eine Möglichkeit wird beispielsweise durch das Remote Data Facility (RDF) Produkt geliefert, die von der EMC Corporation von Hopkinton, Massachusetts, hergestellt wird. Die Datenspeichervorrichtungskommunikation zwischen den Symmetrix®-Datenspeichersystemen, welche die oben genannte RDF verwenden, wie beispielsweise in den U.S. Patent Nrn. 5,742,792 und 5,544,347 beschrieben ist, werden beide hier unter Bezugnahme mit einbezogen. Mit dem RDF kann ein Anwender eine erste Speichervorrichtung als Master-Speichervorrichtung bezeichnen und kann eine zweite Speichervorrichtung als eine Slave-Speichervorrichtung bezeichnen. Andere Inkarnationen von RDF können eine Peer-zu-Peer-Beziehung vorsehen, und zwar zwischen der örtlichen und der entfernten Speichervorrichtung. Der Host interagiert direkt mit der logischen Speichervorrichtung, jedoch werden irgendwelche Datenänderungen, die an der örtlichen Speichervorrichtung vorgenommen werden, automatisch zu der entfernt gelegenen Speichervorrichtung unter Verwendung von RDF vorgesehen. Die örtliche und die entfernt gelegenen Speichervorrichtungen können über ein Datenverbindungsglied verbunden sein, wie beispielsweise ein ESCON-Glied oder ein Faserkanalverbindungsglied. Die RDF-Funktionalität kann mit einem RDF-Adapter (RA) vereinfacht werden, der an jeder der Speichervorrichtungen vorgesehen ist.
  • In einigen Fällen kann es wünschenswert sein, die RDF-Konfiguration bzw. das betreffende System zu modifizieren. Jedoch erfordern manche Fälle für solche Modifikationen erfahrene Techniker unter Verwendung einer speziellen Software und Anwendung von Nicht-Standard-Verbindungen zu den örtlichen Speichervorrichtungen. Es kann wünschenswert sein, den RDF-Konfigurationsmodifikationsprozeß zu automatisieren, um es einem Host zu ermöglichen, die RDF-Konfiguration abzuwandeln. Zusätzlich kann es wünschenswert sein, zuzulassen, daß dynamische Abwandlungen der RDF-Konfiguration nicht den Betrieb der Speichervorrichtung beeinflußt, wenn individuelle Vorrichtungen darin auf dynamische Konfigurationsinformationen zugreifen müssen.
    •
  • ZUSAMMENFASSUNG DER ERFINDUNG
  • Gemäß einem Aspekt der Erfindung wird ein Verfahren zur dynamischen Modifizierung eines Kommunikationspfades zwischen einer ersten Gruppe an Vorrichtungen in einem ersten Datenspeichersystem und einer zweiten Gruppe von Vorrichtungen in einem zweiten Datenspeichersystem geschaffen. Eine Befehlsanfrage wird zu dem ersten Datenspeichersystem ausgegeben, um dynamisch den Kommunikationspfad abzuwandeln. Aufbaudaten werden von dem ersten Datenspeichersystem zu dem zweiten Datenspeichersystem hindurch geleitet, und zwar unter Verwendung eines Kommunikationsverbindungsgliedes, welches nicht bereit ist, Anwenderdaten zu übertragen. Ein erster Teil einer Verbindung zu der ersten Gruppe der Vorrichtungen wird vorbereitet. Nach einer erfolgreichen Vorbereitung des ersten Teiles wird ein zweiter Teil der Verbindung zu der zweiten Gruppe der Vorrichtungen vorbereitet. Nach der erfolgreichen Vorbereitung der ersten und der zweiten Teile der Verbindung wird damit angezeigt, daß der Kommunikationspfad für die Übertragung von Anwenderdaten bereit ist. In Einklang mit einem anderen Aspekt der Erfindung wird ein Computerprogramm erzeugt, um dynamisch einen Kommunikationspfad zwischen einer ersten Gruppe der Vorrichtungen in einem ersten Datenspeichersystem und einer zweiten Gruppe von Vorrichtungen in einem zweiten Datenspeichersystem zu modifizieren, mit den folgenden Schritten: es werden maschinenausführbare Befehle verwendet, um eine Befehlsanfrage an das erste Datenspeichersystem auszugeben, um dynamisch den Kommunikationspfad zu modifizieren; es werden maschinenausführbare Befehle verwendet, um die Aufbaudaten von dem ersten Datenspeichersystem zu einem zweiten Datenspeichersystem hindurch zu schleusen, und zwar unter Verwendung eines Kommunikationsverbindungsgliedes, welches nicht bereit ist, um Anwenderdaten zu übertragen; es werden maschinenausführbare Befehle verwendet, um einen ersten Teil einer Verbindung vorzubereiten, und zwar mit der ersten Gruppe der Vorrichtungen; es werden maschinenausführbare Befehle verwendet, um nach der erfolgreichen Vorbereitung des ersten Teiles, einen zweiten Teil einer Verbindung zu der zweiten Gruppe der Vorrichtungen vorzubereiten; und es werden maschinenausführbare Befehle verwendet, um nach der erfolgreichen Vorbereitung des ersten und des zweiten Teiles der Verbindung eine Anzeige zu erhalten, daß der Kommunikationspfad zum Übertragen der Anwenderdaten fertig gestellt ist oder bereit ist.
    •
  • KURZE BESCHREIBUNG DER ZEICHNUNGEN
  • Weitere Merkmale und Vorteile der vorliegenden Erfindung ergeben sich klarer aus der folgenden detaillierten Beschreibung von beispielhaften Ausführungsformen unter Hinweis auf die beigefügten Zeichnungen, in denen zeigen:
  • 1 ein Beispiel einer Ausführungsform eines Computersystems gemäß der vorliegenden Erfindung;
  • 2 ein Beispiel einer Ausführungsform eines Datenspeichersystems;
  • 3 eine vereinfachte Darstellung eines Beispiels einer Ausführungsform des Computersystems von 1 und 2;
  • 4 ein Beispiel einer Ausführungsform einer dynamischen RDF-Gruppentabelle (DRGT);
  • 5 ein Beispiel eines Eintrags der DRGT;
  • 6 ein Beispiel der Konfigurationsinformationen, die in dem Eintrag von 5 enthalten sind;
  • 7 ein Beispiel einer Darstellung der RDF-Gruppen;
  • 8 und 9 Beispiele von Datenstrukturen, die bei der Verbindungsverarbeitung einer dynamischen RDF-Gruppenanfrageoperation für eine GigE-Ausführungsform verwendet werden;
  • 10 ein Beispiel einer Darstellung eines Multihop-Systemrufes, der in einem Computersystem für eine dynamische RDF-Gruppenanfrageoperation ausgegeben wird;
  • 11 und 13 bis 17 Flußdiagramme von Schritten einer Ausführungsform zur Verarbeitung der dynamischen RDF-Gruppenanfrageoperation; und
  • 12 eine detailliertere Darstellung von zwei Datenspeichersystemen, die in dem Computersystem von 10 enthalten sind, welches die dynamische RDF-Gruppenanfrageoperation verarbeitet.
  • DETAILLIERTE BESCHREIBUNG DER AUSFÜHRUNGSFORM(EN)
  • Um nun auf 1 einzugehen, so ist in dieser Figur ein Beispiel einer Ausführungsform eines Computersystems gemäß der vorliegenden Erfindung dargestellt. Das Computersystem 10 enthält ein Datenspeichersystem 12, welches mit Hostsystemen 14a–14n verbunden ist, und enthält ein Datenmanagementsystem 16 vermittels eines Kommunikationsmediums 18. Bei dieser Ausführungsform des Computersystems 10 können N Hosts 14a–14n und das Datenmanagementsystem 16 auf das Datenspeichersystem 12 zugreifen, beispielsweise bei der Ausführung von Eingabe/Ausgabe-(I/O)-Operationen oder bei Datenanfragen. Das Kommunikationsmedium 18 kann aus irgendeinem Medium bestehen aus einer Vielfalt an Netzwerken oder anderen Typen von Kommunikationsverbindungen, die für Fachleute gut bekannt sind. Das Kommunikationsmedium 18 kann aus einer Netzwerkverbindung, einem Bus und/oder anderen Typen von Datenverbindungsglieder bestehen, wie beispielsweise einer Hartverdrahtung oder anderen Verbindungen, die auf dem Gebiet bekannt sind. Beispielsweise kann das Kommunikationsmedium 18 das Internet sein, ein Intranet sein, ein Netzwerk oder aus anderen Verbindungen oder Verbindung bestehen, über die die Hostsysteme 14a–14n und das Datenmanagementsystem einen Zugriff ausführen können und mit dem Datenspeichersystem 12 kommunizieren können und auch mit anderen Systemen kommunizieren können, die in dem Computersystem 10 enthalten sind.
  • Jedes der Hostsysteme 14a–14n, das Datenmanagementsystem 16 und das Datenspeichersystem 12, die in dem Computersystem 10 enthalten sind, können mit dem Kommunikationsmedium 18 durch irgendeine einer Vielzahl von Verbindungen verbunden sein, und zwar mit solchen, die in Einklang mit dem Typ des Kommunikationsmediums 18 unterstützt werden. Die Prozessoren, die in den Hostcomputersystemen 14a–14n enthalten sind, und das Datenmanagementsystem 16 können aus irgendeinem einer Vielfalt an im Handel erhältlichen und verfügbaren einzelnen oder Vielfach-Prozessorsystemen gebildet sein, wie beispielsweise einem Intel-gestützten Prozessor, einem IBM Mainframe oder anderen Typ eines im Handel verfügbaren Prozessors, der den anfallenden Datenverkehr in Einklang mit jeder speziellen Ausführungsform und Anwendung unterstützen kann.
  • Es sei darauf hingewiesen, daß Besonderheiten der Hardware und der Software, die in jedem der Hostsysteme 14a–14n enthalten sind und auch in dem Datenmanagementsystem 16 enthalten sind, als auch solche Komponenten, die in dem Datenspeichersystem 12 enthalten sein können, im folgenden noch mehr in Einzelheiten beschrieben werden und auch mit jeder speziellen Ausführungsform variieren können. Jeder der Hostcomputer 14a–14n als auch das Datenmanagementsystem 16 können alle an derselben physikalischen Stelle gelegen sein oder können alternativ auch an unterschiedlichen physikalischen Örtlichkeiten gelegen sein. Beispiele für das Kommunikationsmedium, welches dazu verwendet werden kann, um die unterschiedlichen Typen von Verbindungen zwischen den Hostcomputersystemen vorzusehen, ebenso mit dem Datenmanagementsystem und mit dem Datenspeichersystem des Computersystems 10, können eine Vielfalt an unterschiedlichen Kommunikationsprotokollen verwenden, wie beispielsweise SCSI, ESCON, Fiber Channel oder GIGE (Gigabit-Ethernet) und ähnlichem. Einige oder alle der Verbindungen, über die die Hosts, das Datenmanagementsystem 16 und das Datenspeichersystem 12 mit dem Kommunikationsmedium 18 verbunden werden, können durch andere Kommunikationsvorrichtungen verlaufen, wie beispielsweise einer Connectrix- oder anderen Schaltausrüstung, die vorhanden sein können, wie beispielsweise einer Telefonleitung, einem Repeater, einem Multiplexer oder selbst einem Satelliten.
  • Jedes der Hostcomputersysteme als auch das Datenmanagementsystem kann unterschiedliche Typen von Datenoperationen durchführen, und zwar in Einklang mit unterschiedlichen Typen der administrativen Aufgaben. Bei der Ausführungsform nach 1 kann irgendeiner der Hostcomputer 14a–14n eine Datenanfrage ausgeben, und zwar an das Datenspeichersystem 12, um eine Datenoperation auszuführen. Beispielsweise kann eine Anwendung, die bei einem der Hostcomputer 14a–14n ausgeführt wird, eine Backup-Operation umfassen, eine Spiegeloperation oder auch eine andere administrative Operation umfassen, und diese kann ausgeführt werden, während Datenanfragen an das Datenspeichersystem 12 ausgeführt werden.
  • Um nun auf 2 einzugehen, so ist in dieser Figur ein Beispiel einer Ausführungsform des Datenspeichersystems 12 gezeigt, welches in dem Computersystem 10 von 1 enthalten sein kann. In dem Datenspeichersystem 12 nach 2 sind Symmetrix®-Speichersysteme 20a–20n enthalten, die von der EMC Corporation of Hopkinton, Massachusetts, hergestellt werden. Bei diesem speziellen Beispiel kann jedes der Symmetrix®-Speichersysteme 20a–20n untereinander verbunden sein (nicht dargestellt) als auch mit dem Host und mit den Datenmanagementsystemen verbunden sein, und zwar über irgendeine oder mehrere Kommunikationsverbindungen 30, die mit jedem speziellen Fall bzw. Ausführungsform und Vorrichtung variieren können, und zwar in Einklang mit den unterschiedlichen Protokollen, die bei einer speziellen Ausführungsform verwendet werden. Zusätzlich kann der Typ der Kommunikationsverbindung, der verwendet wird, variieren, und zwar hinsichtlich bestimmter Systemparameter und -anforderungen, wie beispielsweise solchen, welche die Bandbreite betreffen und auch den Datendurchsatz betreffen, der in Einklang mit einer Rate der I/O-Anfragen gefordert wird, wie dies durch die Hostcomputersysteme ausgegeben werden kann, beispielsweise zu dem Datenspeichersystem 12 hin. Bei diesem Beispiel, welches mehr in Einzelheiten in den folgenden Absätzen beschrieben wird, wird Bezug genommen auf eine detailliertere Ansicht des Elements 20a. Es sei darauf hingewiesen, daß eine ähnliche detailliertere Beschreibung auch auf irgendein anderes oder auf mehrere der anderen Elemente angewendet werden kann, wie beispielsweise auf das Element 20n, diese Beschreibung jedoch der Einfachheit halber. bzw. zur Vereinfachung der Erläuterung weggelassen wurde. Es sei auch darauf hingewiesen, daß eine Ausführungsform andere Ty pen von Datenspeichersystemen enthalten kann, und zwar in Kombination mit einem oder mit mehreren Symmetrix®-Systemen. Jedes der Elemente 20a–20n kann aus Ressourcen bestehen, die in einer Ausführungsform des Computersystems 10 enthalten sind, um Speicherservices zu liefern, und zwar beispielsweise für die Hostcomputersysteme und/oder für das Datenmanagementsystem.
  • Jedes der Symmetrix®-Systeme, wie beispielsweise das System 20a, kann eine Vielzahl von Plattenlaufwerken oder Datenträgern enthalten, wie beispielsweise die Anordnung 24, die aus n Reihen von Platten oder Datenträgern 24a–24n besteht. Bei dieser Anordnung kann jede Reihe der Platten oder Datenträger mit einem Plattenadapter ("DA") oder Director verbunden sein, der für das Rückende-Management der Operationen verantwortlich ist, und zwar zu und von einem Abschnitt der Platten oder Datenträger 24. Bei dem Symmetrix®-System 20a kann ein einzelner DA, wie beispielsweise der DA 23a, für das Management einer Reihe von Platten oder Datenträgern verantwortlich sein, wie beispielsweise für die Reihe 24a. Jeder der DAs 23a–23n ist beispielsweise über einen Bus 30 mit einem Cache-Speicher verbunden, der einen speziellen Abschnitt enthält, welcher als globaler Speicher 25b bezeichnet wird. Die DAs 23a–23n können Datenoperationen durchführen, und zwar zu und von dem Cache-Speicher, der in dem globalen Speicher 25b enthalten sein kann, beispielsweise unter einer Kommunikation mit anderen Plattenprozessoren oder Directoren und anderen Komponenten des Systems 20a. Im allgemeinen kann der globale Speicher 25b bei der Vereinfachung der Kommunikationen zwischen den Komponenten in dem System 20a verwendet werden. Der andere Abschnitt 25a ist derjenige Abschnitt des Speichers, der in Verbindung mit anderen Bestimmungsorten verwendet werden kann, die in Einklang mit jeder Ausführungsform variieren können.
  • Eine Ausführungsform des Symmetrix®-Systems 20a kann einen Serviceprozessor 22a enthalten, der zum Managen und zum Überwachen des Systems 20a verwendet wird. Bei einer Ausführungsform kann der Serviceprozessor 22a zum Sammeln von Performancedaten verwendet werden, und zwar beispielsweise hinsichtlich der I/O-Performance in Verbindung mit dem System 20a. Diese Performancedaten können bei spielsweise Performancemessungen in Verbindung mit einer Datenanfrage betreffen, wie diese von unterschiedlichen Hostcomputersystemen 14a–14n vorgenommen werden können. Diese Performancedaten können zusammengefaßt und gespeichert werden, beispielsweise in dem globalen Speicher und/oder in einem anderen Speicherbereich.
  • Das System 20a kann auch einen oder mehrere Hostadapter ("HAs") oder Directoren 21a–21n enthalten. Jeder dieser HAs kann zur Managementkommunikation und für Datenoperationen zwischen einem oder mehreren Hostsystemen und dem globalen Speicher verwendet werden.
  • Das spezielle Datenspeichersystem, welches bei der Ausführungsform beschrieben wurde, wie das Symmetrix®-System der EMC Corporation, oder eine Platte soll hier nicht als eine Einschränkung aufgefaßt werden. Es sind andere Typen an Datenspeichersystemen im Handel verfügbar als auch Prozessoren und eine Hardware, die einen Zugriff auf diese speziellen Vorrichtungen steuern, welche ebenso in einer Ausführungsform mit enthalten sein können.
  • Wie in dem Speichersystem 20a gezeigt ist, ist ein RA oder Fernadapter 40 vorgesehen. Der RA kann aus einer Hardware bestehen, die einen Prozessor enthält, der zur Vereinfachung der Kommunikation zwischen den Datenspeichersystemen verwendet wird, wie beispielsweise zwischen zwei Symmetrix®-Datenspeichersystemen. Der RA kann mit dem Remote Data Facility (RDF) Produkt verwendet werden, welches von der EMC Corporation von Hopkinton, Massachusetts, hergestellt wird.
  • Hostsysteme liefern Daten und Zugriffssteuerinformationen über Kanäle zu den Speichersystemen, und die Speichersysteme können Daten zu den Hostsystemen liefern, und zwar ebenfalls über die Kanäle. Die Hostsysteme adressieren die Plattenlaufwerke der Speichersysteme nicht direkt, sondern führen vielmehr einen Zugriff auf Daten durch, der durch ein oder mehrere Hostsysteme vorgenommen wird, die von den Hostsystemen als eine Vielzahl von logischen Vorrichtungen oder logische Datenträger (LVs) angesehen werden. Die LVs können den aktuellen Plattenlaufwerken entsprechen oder auch nicht. Beispielsweise kann eine oder können mehrere LVs in einem einzelnen physikalischen Plattenlaufwerk vorhanden sein. Daten in einem einzelnen Speichersystem können durch eine Vielzahl an Hosts zugegriffen werden, so daß die Hosts die Möglichkeit erhalten, die darin vorhandenen Daten gemeinsam zu verwenden. Die HAs können in Verbindung mit den Kommunikationen zwischen einem Symmetrix-Datenspeichersystem und einem Hostsystem verwendet werden. Die RAs können bei der Vereinfachung der Kommunikationen zwischen zwei Symmetrix-Datenspeichersystemen verwendet werden. Die DAs können in Verbindung mit einer Vereinfachung der Kommunikation verwendet werden, und zwar Kommunikation mit den zugeordneten Plattenlaufwerken oder Plattenlaufwerk und dem LV oder LVs, die darin vorhanden sind.
  • Das DA kann I/O-Operationen bewirken, die an einem Datenträger oder Vorrichtung durchgeführt werden. Bei der folgenden Beschreibung können Daten durch LV zugegriffen werden, in welcher ein einzelnes DA Datenanfragen managt, und zwar in Verbindung mit I/O-Operationen von Vielfach-LVs, die auf einer Platte vorhanden sein können. Das DA kann dies dadurch erreichen, indem es Job-Aufzeichnungen für unterschiedliche LVs erzeugt, die dem speziellen DA zugeordnet sind. Diese unterschiedlichen Job-Aufzeichnungen können den unterschiedlichen LVs in einer Datenstruktur zugeordnet werden, die durch jedes DA gespeichert oder gemanagt wird.
  • Um nun auf 3 einzugehen, so ist in dieser Figur ein Beispiel einer Ausführungsform eines Computersystems 46 gezeigt, welches die Beziehung zwischen einem Host 48, einem ersten Datenspeichersystem 50a und einem zweiten Datenspeichersystem 50b veranschaulicht. Es sei darauf hingewiesen, daß die in 3 gezeigte Ausführungsform eine vereinfachte Ansicht von Komponenten eines Computersystems ist, beispielsweise mit nur einigen Details in Verbindung mit den Datenspeichersystemen 50a und 50b, um die Darstellung vereinfacht zu halten. Der Host 48 kann einen Befehl an das Datenspeichersystem 50a ausgeben, und zwar über die Verbindung 49a unter Verwendung von HA 52a. Kommunikationen zwischen Datenspeichersystemen 50a und 50b können über die Verbindung 49b vereinfacht werden, und zwar unter Verwendung von RA 52b und RA 52c, die jeweils in den Datenspeichersystemen 50a und 50b enthalten sind. Das Verbindungsglied 49b kann aus einem RDF-Verbindungsglied bestehen, welches bewirkt, daß Daten von dem Datenspeichersystem 50a auf das entfernt gelegene Datenspeichersystem 50b kopiert werden. Daten von einer Vorrichtung, wie beispielsweise der Vorrichtung 54a, können zu der Speichervorrichtung 54b in einem entfernt gelegenen Datenspeichersystem 50b kopiert werden, und zwar unter Verwendung des RDF-Verbindungsgliedes 49b, um zu veranlassen, daß die Daten an der entfernten Speichervorrichtung 54b identisch mit den Daten an der örtlichen Speichervorrichtung 54a sind.
  • Das Vorsehen einer RDF-Auflistung zwischen Abschnitten der Vorrichtungen; die in dem Datenspeichersystem 50a enthalten sind, und Vorrichtungen, die in dem Datenspeichersystem 50b enthalten sind, können durch Aufbauen der LVs an dem entfernt gelegenen Datenspeichersystem 50b vorgenommen werden, in welchem diejenigen gespiegelt sind, die in dem Datenspeichersystem 50a enthalten sind. Der Host 48 kann Daten lesen und schreiben, und zwar unter Verwendung der logischen Vorrichtung an dem Datenspeichersystem 50a. Eine RDF-Auflistung kann bewirken, daß modifizierte Daten von dem Datenspeichersystem 50a zu einer entsprechenden Vorrichtung übertragen werden, die über die RDF-Auflistung bzw. -Liste an dem Datenspeichersystem 50b identifiziert wird. In einem Dauerzustand des Betriebes enthalten die logischen Vorrichtungen bei dem entfernt gelegenen Datenspeichersystem 50b identische Daten mit denjenigen, die in der entsprechenden Vorrichtung enthalten sind, was über die RDF-Auflistung und das Datenspeichersystem 50a erfolgt. Die logische Vorrichtung an dem Datenspeichersystem 50a kann von einem Host aus zugegriffen werden und kann als "R1"-Datenträger (volume) bezeichnet werden, während die entsprechende logische Vorrichtung an dem entfernt gelegenen Datenspeichersystem, wie beispielsweise dem System 50b, als "R2"-Datenträger (volume) bezeichnet werden kann. Im Betrieb kann der Host 48 Daten unter Verwendung eines R1-Datenträger in 50a Daten lesen und schreiben, und RDF kann das automatische Kopieren und Erneuern der Daten aus dem R1-Datenträger zu dem R2-Datenträger in dem System 50b handhaben.
  • Es können R1/R2-Paare in einer Vielzahl an unterschiedlichen Wegen definiert werden. R1/R2-Paare können in Einklang mit statischen Konfigurationsdaten definiert werden, in denen eine Konfigurationsdatendatei existieren kann, beispielsweise in dem globalen Speicher. Dies kann als statische Information bezeichnet werden, und zwar dahingehend, daß die Datendatei bei der Initialisierung des Datenspeichersystems gelesen wird, und zwar so wie das System 50a, und existent verbleibt, wie ein R1/R2-Paar, welches nicht modifiziert werden kann. Unter Verwendung einer statischen Konfigurationsdatei besteht die einzige Möglichkeit zu einer Modifikation, inklusive Erzeugen und Löschen von R1/R2-Paaren, darin, die statische Konfigurationsdatei zu modifizieren und das Datenspeichersystem erneut zu initialisieren. Zusätzlich kann es erforderlich werden, die Konfigurationsdatendatei zu modifizieren, und zwar unter Verwendung einer speziellen Software, und es kann auch erforderlich werden, daß die Unterstützung eines Technikers benötigt wird, der mit der speziellen Konfigurationsdatendatei vertraut ist.
  • Zusätzlich zu den statischen Konfigurationsdaten kann das Datenspeichersystem dynamische Konfigurationsdaten enthalten, die in einem Abschnitt des globalen Speichers gespeichert sein können. Bei einigen Ausführungsformen können die dynamischen Konfigurationsdaten irgendwelche Informationen überschreiben, die in den statischen Konfigurationsdaten enthalten sind. Bei anderen Ausführungsformen können die dynamischen Konfigurationsdaten lediglich additiver Natur sein, derart, daß diese beispielsweise lediglich in Fällen verwendet werden, in welchen kein Eintrag in der Statikkonfigurationsdatendatei mit einem entsprechenden Eintrag vorhanden ist. Zusätzlich zum Vorsehen einer dynamischen und statischen Konfigurationstechnik kann eine Ausführungsform auch das Konzept einer RDF-Gruppe enthalten, in welcher null oder mehr RDF-Vorrichtungen an einem Datenspeichersystem einer speziellen Gruppe zugeordnet wird, und zwar unter der Steuerung eines einzelnen RA, welches die Vorrichtungen, die darin enthalten sind, bedient. Eine Ausführungsform kann auch die Existenz einer Leergruppe zulassen, in welcher keine Vorrichtungen enthalten sind. Eine RDF-Gruppe kann statisch definiert sein, wie beispielsweise durch Verwenden einer statischen Konfigurationsdatei, und kann auch dynamisch definiert sein.
  • In einigen Situationen kann es vorteilhaft sein, dem Host 48 zu ermöglichen, RDF-Aufzeichnungsträger zu erzeugen und zu vernichten, und zwar in dynamischer Form während des Betriebes des Systems. Solche Techniken sind beispielsweise in der U.S. Patentanmeldung Nr. 09/997,180, eingereicht am 30. November 2001, mit dem Titel "DYNAMIC RDF", beschrieben, welche hier unter Bezugnahme voll mit einbezogen wird. Es sei erwähnt, daß die RDF-Datenträger in Paaren erzeugt und zerstört werden können, so daß ein R1/R2-Paar zerstört oder gelöscht werden kann oder ein R1/R2-Paar erzeugt werden kann. Das Erzeugen oder Löschen von R1/R2-Paaren kann durch den Host 48 initialisiert werden. Der Host kann einen Multihop-Systembefehl senden. Der Multihop-Systembefehl besteht aus einem einzelnen Systembefehl, der für eine Vielzahl an Speichervorrichtungen vorgesehen wird und Operationen anzeigt, die durch die Vielfach-Speichervorrichtung ausgeführt werden sollen. Beispielsweise kann der Host 48 einen Multihop-Systembefehl aussenden mit der Anfrage, daß ein bestimmtes R1/R2-Paar zerstört oder gelöscht wird, wobei sich der R1-Datenträger in dem Datenspeichersystem 50a befindet und der R2-Datenträger sich bei dem entfernt gelegenen Datenspeichersystem 50b befindet, indem nämlich bei jedem Speichersystem 50 und 50b örtlich eine Tabelle eine Tabelle modifiziert wird, die intern von jeder der Speichervorrichtungen verwendet wird, um das Erstellen oder den Aufbau zu lenken und um die RDF-Datenträger zu managen. Das Erzeugen eines R1/R2-Paares involviert das Erzeugen des R1-Datenträgers an einer Speichervorrichtung und das Erzeugen des R2-Datenträgers an der anderen Speichervorrichtung.
  • Eine Ausführungsform kann auch eine umschaltbare RDF-Umgebung enthalten, in welcher ein einzelnes RA Vielfach-RDF-Gruppen bedienen kann. In einer geschalteten RDF-Umgebung werden die RAs unter Verwendung eines Schalters verbunden und kommunizieren über diesen. Die Kommunikationspunkte an dem Schalter können dynamisch modifiziert werden als auch Verbindungsglieder dazwischen. Dies steht im Gegensatz beispielsweise zu dem Punkt-zu-Punkt-Typ einer Verbindung, die als statische Verbindung charakterisiert werden kann, bei der Endpunkte definiert sind und auch ein Verbindungsglied, die nicht modifizierbar sind. Eine geschaltete RDF-Umgebung kann beispielsweise einen Faserschalter und GigE-Verbindungen verwenden.
  • In den folgenden Absätzen werden Techniken beschrieben, um dynamisch RDF-Gruppen zu erzeugen, zu zerstören bzw. zu löschen und anderweitig zu modifizieren, und zwar in einer geschalteten RDF-Umgebung, in welcher RDF-Verbindungsglieder dynamisch hinzu addiert werden können oder auch entfernt werden können, und zwar unter Verwendung von Fernsystemanrufen. Die folgende Beschreibung gibt auch Aufschluß über die Erzeugung einer leeren RDF-Gruppe, in welcher eine Gruppe, die einen Namen hat, welcher dieser zugeordnet ist, jedoch keine zugeordneten Datenspeichervorrichtungen aufweist. In Verbindung mit der nachfolgenden Beschreibung hinsichtlich der Erzeugung, Aufhebung und anderweitigen Modifizierung der RDF-Gruppen wird ein Paar von RDF-Gruppen definiert, in welchen eine erste RDF-Gruppe an einem örtlichen Datenspeichersystem eine entsprechende RDF-Gruppe bei einer entfernten Datenspeichersystem aufweist. Dies ist analog zu dem R1/R2-Paar mit der Ausnahme, daß jedes R1 und R2 auf eine RDF-Gruppe verweist.
  • Ferner erfordern die hier beschriebenen Techniken nicht, daß ein Verbindungsglied initialisiert wird und zwischen irgendwelchen zwei RDF-Gruppen gelegen ist. Vielmehr erfordern die hier beschriebenen Techniken lediglich, daß ein physikalisches Verbindungsglied zwischen den RDF-Gruppen existiert.
  • Die in dem folgenden Absatz beschriebene Ausführungsform enthält bestimmte Anforderungen und Einschränkungen. Die speziellen Anforderungen und/oder Einschränkungen, die bei der Ausführungsform enthalten sind, können in Einklang mit den Details von jeder speziellen Ausführungsform variieren. Wenn der Systemruf verwendet wird, werden RDF-Gruppen hinzu addiert oder entfernt, und zwar in Paaren von sowohl einem örtlichen als auch einem entfernt gelegenen Datenspeichersystem. Jeder Systemruf darf lediglich eine Gruppe erzeugen oder entfernen, und zwar in jedem Datenspeichersystem. Lediglich ein Moment des Systemrufs zum Modifizieren einer dynamischen RDF-Gruppe darf zu irgendeinem Zeitpunkt ausgeführt werden. Wie oben beschrieben ist, wird bei der Erzeugung und der Entfernung eines RDF-Gruppenpaares nicht angenommen, daß bereits ein Verbindungsglied zwischen den Datenspeichersystemen, die hier von Interesse sind, aufgebaut wurde. Die dynamische Gruppeninformationen werden in einem nichtflüchtigen Speicher für ein Event gespeichert, beispielsweise für einen Stromausfall. Der Systemruf für eine dynamische RDF-Gruppe darf lediglich eine dynamische RDF-Gruppe hinzu addieren oder entfernen. Demzufolge darf dieser Befehl beispielsweise nicht dafür zugelassen werden, irgendeine geeignete Verwendung der Gruppen zu ändern, die in der statischen Konfigurationsdatei enthalten sind. Der dyna mische RDF-Gruppensystembefehl beeinflußt die Inhalte der dynamischen Konfigurationsdatei, wie dies noch an späterer Stelle beschrieben wird. Dieser Befehl wird nicht dazu verwendet, um Werte zu erneuern, die in der statischen Konfigurationsdatendatei enthalten sind. Eine RDF-Gruppe, die nicht leer ist, wird nicht unter Verwendung des dynamischen RDF-Gruppensystembefehls entfernt.
  • Eine dynamische Gruppenblockierung kann als ein Mechanismus verwendet werden, um sicherzustellen, daß lediglich ein einzelner Posten dieses dynamischen RDF-Gruppenbefehls zu einer Zeit bzw. einmalig ausgeführt wird. Bei dieser Ausführungsform kann die dynamische Gruppenblockierung als ein Bitflag charakterisiert werden, welches als ein Signal dazu dient, welches angibt, wann ein Bestandteil des dynamischen RDF-Gruppenbefehls ausgeführt wird. Dieses Bitflag kann in dem globalen Speicher an jedem Datenspeichersystem gespeichert sein. Diese Technik führt nicht zur Plazierung einer Software- oder Hardwareblockierung, die Exklusivität garantiert. Vielmehr dienet dieses Flag als Signalisiertechnik, die von allen Prozessen beobachtet wird. Andere Ausführungsformen können auch andere Techniken verwenden.
  • Wie hier noch beschrieben wird, kann eine nicht existente Gruppe eine globale Systemwarteschlange oder GST innerhalb des Datenspeichersystems für eine Kommunikation mit einer oder mit mehreren anderen RDF-Gruppen verwenden. Existierende dynamische Gruppen können statische Warteschlangen (queues) enthalten, die bereits in Verbindung mit der Initialisierung des Systems definiert wurden. Demzufolge kann in Verbindung mit der Kommunikation mit RAs während RDF-Gruppen für den dynamischen RDF-Gruppensystembefehl gemanagt werden, was noch später beschrieben werden soll, die GST-Warteschlange als eine Einrichtung zur Realisierung von Kommunikationen zwischen den RAs innerhalb des gleichen Datenspeichersystems verwendet werden.
  • Eine Ausführungsform kann zum Erzeugen des dynamischen RDF-Gruppenbefehls lediglich einen einzelnen Ruf vorsehen, um eine dynamische Gruppe hinzu zu addieren oder zu entfernen, im Gegensatz zum Definieren von Vielfachrufen. Eine Modifikation in Verbindung mit einer dynamischen Systemgruppe enthält das Hinzuaddieren oder Entfernen einer Unterstützung für eine Gruppe durch einige oder durch alle der relevanten Directoren oder RAs. In Verbindung mit dem Entfernen einer dynamischen RDF-Gruppe verursacht diese spezielle Ausführungsform einen Fehler, wenn der letzte Director entfernt wird und wenn die Gruppe nicht leer ist. Wenn eine Gruppe entfernt wird, wird auch das zugeordnete Verbindungsglied entfernt. Für den Fall, daß dies das letzte Verbindungsglied für die Gruppe ist, kann auch die Gruppeninformation ebenfalls entfernt werden.
  • Ein spezielles Task kann dazu verwendet werden, um Gruppeninformationen zu transferieren, um eine Gruppe zu erzeugen und zu entfernen, und zwar an einem entfernten Datenspeichersystem, ohne daß dabei ein Verbindungsglied zwischen einem örtlichen und einem entfernt gelegenen Datenspeichersystem vorhanden ist. Die zwei Datenspeichersysteme besitzen ein physikalisches Verbindungsglied zwischen sich, beispielsweise in solcher Weise, daß sie über einen Schalter verbunden werden. Die allgemeine Technik, die für diese spezielle Aufgabe verwendet wird, besteht darin, einen Verbindungsglied-Wiederherstellprozeß für ein nicht verwendetes Verbindungsglied zu starten und den Verbindungsglied-Wiederherstellprozeß zu beenden, und zwar vor der Vervollständigung der Initialisierung unmittelbar, nachdem das entfernt gelegene Datenspeichersystem die dynamische Gruppeninformation erhalten hat, und welches entsprechend einen Status zu dem örtlichen Datenspeichersystem zurückleitet. Dieses Verbindungsglied wird erneut nicht-initialisiert gemacht. Ein nicht verwendetes Verbindungsglied kann auf eine existierende physikalische Verbindung verweisen, welches momentan nicht als eine Kommunikation zugeordnet oder in Verwendung ist, und zwar zwischen zwei RAs oder anderen Typen von Anwenderanwendungen. Der Prozeß der Verbindungsgliedinitialisierung wird an einem örtlichen Datenspeichersystem gestartet und es werden Informationen hinsichtlich der dynamischen Gruppendaten, die durch einen Ruf des entfernten Systems übertragen werden sollen, zu einem entfernt gelegenen Datenspeichersystem durchgeschoben. Nachdem die Informationen einmal zu dem entfernt gelegenen Datenspeichersystem durchgeschoben wurden und das örtliche Datenspeichersystem einen Status hinsichtlich dieser Information empfangen hat, der durch das entfernt gelegene Datenspeichersystem empfangen wurde, zeigt das örtliche Datenspeichersystem das Verbindungsglied als nicht initialisiert an. Dieser spezielle Task und dessen Verarbeitung werden weiter unten mehr in Einzelheiten beschrieben.
  • Jeder Director RAs, DAs und HAs enthält Informationen, die örtlich auf eine RDF-Gruppe bezogen gespeichert sein können. Einige der Variablen, welche eine RDF-Gruppe betreffen, können lediglich in der Statikkonfigurationsdatei initialisiert werden. Es kann erforderlich sein, die Gruppeninformationen zu erneuern, wie sie durch HAs, DAs gehalten werden und ähnliche Einrichtungen gehalten werden, und zwar zusätzlich zu solchen RAs, die direkt in der Erzeugung der RDF-Gruppe involviert sind. Wenn eine Änderung dynamisch in Verbindung mit den RDF-Gruppeninformationen stattfindet, können alle Directoren, inklusive der Directoren, die nicht direkt in der Hinzufügung oder Entfernung einer Gruppe involviert sind, entsprechend unterrichtet werden.
  • In Verbindung mit der Sicherstellung, daß Nicht-RDF-Directoren, wie beispielsweise HAs und DAs, die Erneuerungsinformationen in Verbindung mit einer dynamischen RDF-Gruppenänderung empfangen, können mehrere verschiedene Mechanismen bei einer Ausführungsform verwendet werden. Zuerst erfolgt in den folgenden Abschnitten eine Beschreibung hinsichtlich der dynamischen RDF-Gruppe RA, die für die Änderung verantwortlich ist, die eine RST-Warteschlangenanfrage aussendet, um andere Directoren über die Änderung in Verbindung mit den RDF-Gruppen zu informieren. Jedoch verifiziert, wie weiter unten beschrieben wird, die verantwortliche RA nicht, daß jeder der Directoren aktuell diese Erneuerung beim Lesen der neuen Informationen aus dem globalen Speicher durchführt. Der Ausführung an jedem Director kann eine Niedrigprioritätstask hinzugeführt werden, die jeden der Directoren instruiert, aus dem globalen Speicher die letzte Kopie der dynamischen RDF-Gruppe-Gruppentabelle oder DRGT herabzuladen und die erforderlichen Gruppenmasken in irgendwelchen Daten auszubilden, die örtlich an jedem Director aufrecht erhalten werden. Es sei darauf hingewiesen, daß dann, wenn eine Niedrigprioritätsaufgabe herausfindet, daß ein dynamischer RDF-Gruppensystemrufbefehl momentan innerhalb eines Datenspeichersystems ausgeführt wird, wie beispielsweise bei einer Prüfung der globalen Speicherblockierung, der Niedrigprioritätstask solange zum Warten gezwungen wird, bis die Verriegelung freigegeben wird, und zwar vor der Fortsetzung der Ausführung.
  • Was nun im folgenden beschrieben ist, sind einige Datenstrukturen, die bei den Verarbeitungsschritten verwendet werden, welche mehr in Einzelheiten in den folgenden Abschnitten beschrieben werden, um den dynamischen RDF-Gruppenmodifizierbefehl durchzuführen.
  • Um auf 4 einzugehen, so ist in dieser Figur ein Beispiel einer Ausführungsform einer dynamischen RDF-Gruppentabelle (DRGT) gezeigt. Jeder Director besitzt eine DRGT, die Informationen identifiziert, die für das Datenspeichersystem speziell sind, in welchem der Director vorherrscht. Die DRGT enthält einen Eintrag für jede mögliche RDF-Gruppe. Bei einer Ausführungsform liegt die maximale Zahl der möglichen RDF-Gruppen, die durch einen einzelnen Director gemanagt werden können, bei vierundsechzig (64). Demzufolge enthält die Tabelle bei dieser Ausführungsform 64 Einträge. Die maximale Zahl der RDF-Gruppen, die bei irgendeiner speziellen Ausführungsform gemanagt werden kann, kann variieren und ist nicht auf eine spezielle Zahl von 64, wie hier beschrieben ist, beschränkt. Auch sind andere spezifische Zahlen und Werte beschrieben, die bei den Beispielen verwendet werden, welche hier beschrieben sind. Diese spezifischen Werte sind nicht als Einschränkungen aufzufassen, und zwar hinsichtlich der Konzepte, Techniken und Prinzipien, die hier beschrieben werden, sondern vielmehr als Faktoren, die in Einklang mit jeder Ausführungsform variieren können.
  • Jede örtliche Kopie eines Directors der DRGT ist in einem Abschnitt eines nichtflüchtigen Speichers gespeichert. Wie hier beschrieben wird, kann ein Director beispielsweise ein RA, ein DA oder HA sein. Eine Kopie der DRGT-Tabelle wird auch in dem globalen Speicher gespeichert, wie dies auch in Verbindung mit 2 beschrieben ist. Es sei darauf hingewiesen, daß die Kopie der DRGT, welche in dem globalen Speicher gespeichert ist, die als auf dem neuesten Stand stehende betrachtet wird und auch als eine korrekte Kopie der DRGT-Tabelle betrachtet wird. Bei dieser Ausführungsform besteht die Kopie der DRGT-Tabelle, die in dem nichtflüchtigen Speicherabschnitt von jedem Director gespeichert ist, in einer kompletten Kopie der Tabelle aus dem globalen Speicher.
  • Gemäß 5 ist ein detaillierteres Beispiel einer Ausführungsform eines Eintrags der DRGT-Tabelle 100 gezeigt. Bei dieser speziellen Ausführungsform enthält jeder Eintrag in der DRGT eines Datenspeichersystems Informationen von der Statikkonfigurationsdatei, einen Bitplan der Directoren in dem Datenspeichersystem, welche die Gruppe entsprechend dem Eintrag unterstützen, enthält implementierungsspezifische Informationen und Gültigkeitsflags. Um mehr in Einzelheiten zu gehen, so enthält ein Eintrag 101 bei diesem Beispiel Gruppenkonfigurationsinformationen 102, eine Liste der Directoren in diesem Datenspeichersystem, welche die momentane Gruppe 104 unterstützen, andere unterstützte Directoren 106, einen Anker-Director an einer entfernten Site 108, ein gültiges Flag 110 und irgendwelche zusätzlichen Felder in diesem speziellen Eintrag 112. Die speziellen Gruppenkonfigurationsinformationen, die in dem Feld 102 von jedem Aufzeichnungseintrag 101 enthalten sind, werden mehr in Einzelheiten in den folgenden Abschnitten beschrieben. Es sei darauf hingewiesen, daß die Kopie der Informationen, die in dem Gruppenkonfigurationsinformationseintrag 102 enthalten sind, die gleichen sind wie die Gruppenkonfigurationsinformationen, die in einer Statikkonfigurationsdatei ebenfalls enthalten sein können oder die gleichen sind wie andere Typen von Konfigurationsinformationen, welche die Gruppe beschreiben, die irgendwo in dem System gespeichert ist. Bei einer Ausführungsform kann eine Kopie der Statikkonfigurationsdateidaten in dem globalen Speicher in jedem Datenspeichersystem gespeichert sein. Jeder Director innerhalb eines Datenspeichersystems kann örtlich eine Kopie von allen oder von Abschnitten dieser Statikkonfigurationsdateien speichern. Das Feld 104 listet solche Directoren in diesem Datenspeichersystem auf, welche die Gruppe unterstützen, die momentan durch diesen Aufzeichnungseintrag 101 beschrieben wird. Das Datenspeichersystem kann beispielsweise aus einem symmetrischen Datenspeichersystem bestehen, welches eine Vielzahl der Directoren, wie beispielsweise RAs, HAs und ähnliches enthalten kann. Das Feld 104 listet solche Directoren in diesem speziellen Datenspeichersystem auf, welche die momentane Gruppe unterstützen. Das Feld 104 kann aus einem kodierten Bitplan oder einem anderen Typ einer Repräsentation bestehen, um die Directoren zu identifizieren.
  • Es werden Felder 106 und 108 in Verbindung mit der speziellen Ausführungsform verwendet, welche eine GigE-Verbindung verwendet. Die spezielle Verwendung dieser Felder wird irgendwo hier in der Beschreibung wiedergegeben, und zwar noch mehr in Einzelheiten. Das andere Feld 106 von unterstützten Directoren enthält eine Liste, wie beispielsweise eine Bitplan (bitmap), ähnlich dem Feld 104, welches die Directoren an einer entfernten Site identifiziert. Das Feld 108 ist ein spezieller Director, der als ein Anker-Director an der entfernten Site bezeichnet werden kann, mit welchem Kommunikationen vorgenommen werden können, und zwar in Verbindung mit der Erstellung einer dynamischen RDF-Gruppe. Bei dieser speziellen Ausführungsform wird das Feld 108 lediglich für die GigE-Implementierung verwendet. In ähnlicher Weise können andere Ausführungsformen die Verwendung anderer implementierungsspezifischer Felder erfordern, was im folgenden noch beschrieben wird.
  • Das Feld 110 enthält ein Gültigkeitsflag, welches als ein Bitflag implementiert werden kann, welches eine 1 enthält, die anzeigt, daß die Information, die in der Aufzeichnung oder dem Eintrag 101 enthalten ist, gültig ist, und im anderen Fall 0 enthält. Andere Felder 112 können ebenfalls in jedem Eintrag der DRGT enthalten sein. Diese anderen Felder können beispielsweise zusätzliche Informationen enthalten, die in Einklang mit jeder speziellen Ausführungsform variieren können, als auch Füllzeichen enthalten, die in Verbindung mit der Ausführung von irgendwelchen Ausrichtanforderungen für eine spezielle Ausführungsform verwendet werden können.
  • Es sei darauf hingewiesen, daß Einträge in örtlichen Kopien der DRGT durch Directoren erneuert werden können, und zwar in Verbindung mit den Verarbeitungsschritten, die später beschrieben werden.
  • Um nun auf 6 einzugehen, so ist in dieser Figur ein Beispiel einer detaillierteren Information der Gruppenkonfigurationsinformationen dargestellt, die an früherer Stelle in Verbindung mit 5 beschrieben wurden. Bei dieser speziellen Ausführungsform enthält die Gruppenkonfigurationsinformation Konfigurationsflags 120, Gruppenkennungsdaten 122, Gruppennummerinformationen 124, Vorrichtungsverbindungsglied-spezifische Informationen 126 und irgendwelche anderen Informationen 128. Die Konfigurationsflags 120 als auch die Gruppenkennung 122 und die Gruppennummer 124 können als gemeinsame Felder fungieren, die in Verbindung mit unterschiedlichen Typen von Kommunikationsverbindungen bzw. Verbindungsgliedern verwendet werden. Wie an irgendeiner Stelle in der vorliegenden Beschreibung dargelegt ist, bilden Kommunikationsverbindungsglieder Verbindungen, die beispielsweise einen Faserschalter oder GigE-Verbindungen enthalten können. Die Konfigurationsflags 120 können Informationen hinsichtlich der Konfigurierung der speziellen Gruppe enthalten. Die Gruppenkennung und die Gruppenzahl in den jeweiligen Feldern 122 und 124 enthalten Identifizierungsinformationen hinsichtlich der RDF-Gruppe. Bei dieser speziellen Ausführungsform kann eine RDF-Gruppe, die durch die Gruppenzahl in dem Feld 124 bezeichnet ist, eine 0 enthalten, was beispielsweise einer Gruppe A entspricht, eine 1 enthalten, was einer Gruppe B entspricht, und ähnlichem, wobei jede spezielle RDF-Gruppe auf eine Gruppe von Vorrichtungen verweist, die durch diesen speziellen RA-Director bedient werden. Die Gruppenkennung bei diesem speziellen Beispiel kann auf eine Kennungskette oder -folge von bis hinauf zu zehn Zeichen verweisen. Die Gruppenkennung ist in beiden Datenspeichersystemen, welche in der Verbindung involviert sind, die gleiche. Die Gruppenkennung kann auch als ein Spitzname für die Seriennummern und die Gruppennummern der Datenspeichersysteme bei der Verbindung charakterisiert werden.
  • Gemäß 7 ist ein Beispiel einer Ausführungsform 130 mit zwei Datenspeichersystemen 132a und 132b gezeigt. Zwei RDF-Gruppen sind in diesem Beispiel definiert. Die erste Gruppe ist als ein LABEL1 zwischen den RDF-Gruppen A und C mit der Verbindung 134 definiert. Die zweite RDF-Gruppe ist als LABEL2 definiert und ist der Verbindung 136 zwischen den RDF-Gruppen B und D zugeordnet. Die Gruppe A und die Gruppe B sind in dem Datenspeichersystem 132a vorhanden und die Gruppe C und die Gruppe D sind in dem Datenspeichersystem 132b vorhanden. Eine RDF-Gruppe kann als ein Bündel aus null oder mehreren RDF-Vorrichtungen charakterisiert werden, welches einem speziellen RA-Director zugeordnet oder zugewiesen ist, welcher die Gruppe bedient.
  • Eine Ausführungsform kann unterschiedliche Einschränkungen in Verbindung mit der Definierung und dem Implementieren von Gruppen enthalten. Eine Ausführungsform kann auch unterschiedliche Einschränkungen und Namensgebungskonventionen für Vorrichtungskennungen enthalten. Beispielsweise kann ein Default-Kennungsname verwendet werden, wenn kein spezifischer Name spezifiziert wurde. Eine Ausführungsform kann eine Einschränkung beispielsweise dahingehend enthalten, daß eine Gruppe, die den Default-Kennungsnamen verwendet, keine leere Gruppe ist. Andere Ausführungsformen können unterschiedliche Einschränkungen in Verbindung mit der Namensgebung haben und auch in Verbindung mit anderen Typen von Spezifikationen, die mit jeder speziellen Ausführungsform variieren können. Bei diesem speziellen Beispiel kann der Default-RDF-Gruppenkennungsname nicht in Verbindung mit leeren Gruppen verwendet werden, wie dieser beim Initialisieren einer neuen dynamischen RDF-Gruppe zugewiesen werden kann. Eine leere Gruppe kann als eine solche gekennzeichnet werden, die keinerlei Vorrichtungen enthält.
  • Um nun erneut auf 6 zurückzukommen, so kann die Gruppenkennung 122, wie beispielsweise "LABEL1" oder "LABEL2", einem Paar von RDF-Gruppen gemäß 7 zugeordnet sein, in welcher jede RDF-Gruppe in einem unterschiedlichen Datenspeichersystem enthalten ist. In ähnlicher Weise kann die Gruppenzahl 124 eine Kodierung darstellen, um jede spezielle Gruppe, wie beispielsweise A, B, C und D, zu repräsentieren, die in Verbindung mit 7 beschrieben werden. Das Feld 126, kann unterschiedliche Typen von Verbindungsglied-spezifischen Informationen enthalten, die mit der Kommunikationsverbindung, die verwendet wird, variieren. Beispielsweise kann in Verbindung mit 7 das Verbindungsglied oder die Kommunikationsverbindung 134 zwischen den RDF-Gruppen A und C in unterschiedlichen Datenspeichersystemen ein Faserschalterverbindungsglied sein. Bei Verwendung eines Faserschalterverbindungsgliedes (fiber switch link) kann eine Seriennummer verwendet werden, um eine Adresse eines Directors zu erhalten. Wie auch noch mehr in Einzelheiten in der vorliegenden Beschreibung wiedergegeben ist, können auch andere Typen von Informationen für unterschiedliche Typen von Verbindungen und von Verbindungsgliedern verwendet werden, um Adressen der RAs zu erhalten, die unterschiedliche RDF-Gruppen bedienen.
  • Die Typen der Verbindungen und Techniken, die verwendet werden, um RA-Adresseninformationen zu erhalten, können mit jeder speziellen Ausführungsform variieren.
  • Irgendeine Ausführungsform kann irgendeine oder mehrere Typen von Kommunikationsverbindungen zwischen entfernt gelegenen Directoren von unterschiedlichen Datenspeichersystemen unterstützen, wie beispielsweise einen Faserschalter und GigE-Verbindungen. Die unterschiedlichen Typen der Kommunikationsverbindungen können unterschiedliche Techniken verwenden, um eine entfernte Adresse eines RA oder eines anderen Directors zu erhalten. Informationen, die in den Verbindungsglied-spezifischen Informationen 126 enthalten sind, können beispielsweise bei dem Prozeß der Bestimmung solcher Adressen verwendet werden. Für Faserschalterverbindungen kann ein weltweiter Namensgebungsservice (WWN) verwendet werden, um eine Adresse eines Directors zu erhalten, der eine Seriennummer liefert. Für andere Verbindungstypen, wie beispielsweise GigE, können andere Techniken verwendet werden, da beispielsweise Namensgebungsdienste wie WWN nicht verfügbar sein können.
  • Was nun im folgenden beschrieben wird, ist eine Technik, die in Verbindung damit verwendet werden kann, um Directoradressen bei einer Ausführungsform zu erhalten, welche GigE-Verbindungen unterstützt.
  • Um nun auf 8 einzugehen, so ist in dieser Figur ein Beispiel einer Ausführungsform 140 von Tabellen gezeigt, die mit einer GigE-Verbindung verwendet werden können, um die Kommunikation zwischen den Directoren in entfernten Datenspeichersystemen, wie beispielsweise Symmetrix-Datenspeichersystemen, zu vereinfachen. In Verbindung mit einer Faserschalterverbindung kann ein Namensgebungsdienst verwendet werden, um die Adresse für einen Zieldirector zu erhalten, wenn dessen Seriennummer gegeben ist. In Verbindung mit einer GigE-Verbindung können alternative Techniken verwendet werden, um die spezielle Adresse der Directoren zu bestimmen. Die Tabellen 142 und 144, die in 8 enthalten sind, können in Verbindung mit einer Bestimmung der IP-Adresse eines Directors verwendet werden. Posten der Tabelle 142 und 144 können in jedem Datenspeichersystem definiert und gespeichert sein, beispielsweise in dem globalen Speicher oder einem anderen Abschnitt des Speichers, wo Konfigurationsinformationen gespeichert sein können. Diese Tabellen können in einem nichtflüchtigen Speicher abgespeichert sein.
  • Die Tabelle 142 kann auf eine Remote-Box-Tabelle (Fern-Box-Tabelle) verweisen, die einen Eintrag enthält, und zwar mit der Seriennummer von allen anderen Datenspeichersystemen, die in einer Umgebung eines Anwenders enthalten sind. Die Tabelle 142 kann einen Eintrag mit einer Seriennummer für jedes andere Datenspeichersystem enthalten, mit welchem beispielsweise das vorliegende oder momentane Datenspeichersystem eine Fernverbindung herstellen kann.
  • Jedes Datenspeichersystem kann auch in seinem globalen Speicher beispielsweise einen Posten der Tabelle 144 speichern. Die Tabelle 144 kann auch Informationen hinsichtlich aller GigE-Directornummern und hinsichtlich der zugeordneten IP-Adressen enthalten. Die Tabelle 144 kann in solcher Weise organisiert sein, daß alle die GigE-Directornummern und zugeordneten IP-Adressen für jedes Datenspeichersystem miteinander gruppiert sind. Die Seriennummer, die aus der Tabelle 142 erhalten wird, kann als ein Index in der Tabelle 144 verwendet werden, um die Adresse von einem oder von mehreren GigE-Directoren zu erhalten, die innerhalb eines speziellen Datenspeichersystems gelegen sind. Unter Verwendung der speziellen Seriennummer des Datenspeichersystems, welches mit einer speziellen GigE-Directorzahl gepaart ist, kann die entsprechende IP-Adresse erhalten werden und kann in Verbindung mit dem Erstellen einer Verbindung verwendet werden. Bei dieser Ausführungsform kann der spezielle Director in einer GigE-Ausführungsform, mit welcher Kommunikationen hergestellt werden sollen, als ein Eingabe- oder Eingangsparameter spezifiziert werden, und zwar in dem dynamischen RDF-Gruppensystemruf.
  • Es sei darauf hingewiesen, daß eine Ausführungsform Systemrufe enthalten kann oder ein Anwendungsprogrammierinterface (API) festlegen kann, um Informationen hinsichtlich der speziellen IP-Adresse eines GigE oder eines anderen Directors zu liefern. Mit anderen Worten, anstatt direkt auf die Werte in der Tabelle 140 zuzugreifen, wie dies hier beschrieben ist, kann eine Softwareeinrichtung, die innerhalb eines Datenspeichersystems enthalten ist, ein API liefern, beispielsweise mit den Eingangsparame tern einer Seriennummer und einer Directornummer, und kann als Ausgangsparameter eine spezielle Adresse, wie beispielsweise eine Netzwerkadresse, zurückleiten. Dies kann als eine Alternative zu dem WWN-Dienst verwendet werden, beispielsweise in Verbindung mit der Faserkanal-Ausführungsform, die hier ebenfalls beschrieben ist.
  • Um auf 9 einzugehen, so zeigt diese ein Beispiel einer Ausführungsform 200 eines Eintrags der DRGT, wie diese in dem globalen Speicher eines speziellen Datenspeichers enthalten sein kann. Diese Struktur wird erzeugt und verwendet, wenn eine zeitweilige Struktur bei der Verarbeitung erzeugt wird, wie beispielsweise für die Schritte 390 und 562, die hier ebenfalls beschrieben werden. Es sei darauf hingewiesen, daß ein Eintrag in der DRGT, die in dem globalen Speicher gespeichert ist, einen Supersatz von Informationen darstellt, und zwar eines Eintrages der DRGT, wie dieser örtlich durch jeden Director gespeichert sein kann. Der Globalspeicher (Global Memory (GM)) bzw. die zeitweilige Struktur 200 desselben, die einem speziellen Eintrag in der Globalspeicherversion der DRGT entspricht, enthält den DRGT-Eintrag 204, welcher hier ebenfalls beschrieben ist, und zwar in Verbindung mit dem Element 101 von 5. Zusätzlich enthält jeder Eintrag in der Globalspeicherversion der DRGT zusätzliche Metadaten 206.
  • Die zusätzlichen Metadaten 206 können die RDF-Gruppennummer enthalten. Diese Gruppennummer kann durch einen Director verwendet werden, um sicherzustellen, daß der korrekte Eintrag in der Statikkonfigurationsdatei für eine bestimmte Gruppe erhalten worden ist. Zu dem Director, der die zeitweilige GM-Struktur 200 erzeugt, wird eine bestimmte Gruppennummer in dem Systemruf zugeführt und dieser wird in der zusätzlichen Metadatendatei 206 plaziert. Der Director kopiert dann andere Daten aus der Globalspeichertabelle DRGT bzw. dem Eintrag und führt eine Verifizierung durch, daß die Gruppennummer der DRGT mit der Gruppennummer übereinstimmt, die in dem Parameter spezifiziert ist. Die Gruppennummer in dem Bereich 206, wie diese hier beschrieben wird, kann zum Schutz und für die Datenverifizierung bei den Verarbeitungsschritten verwendet werden, beispielsweise um zu verifizieren, daß die Gruppennummer eines Rufparameters in der zeitweiligen Struktur, wie durch einen ersten Director erzeugt, mit der Gruppennummer übereinstimmt, die empfangen wurde und durch einen anderen Director bei der nachfolgenden Verarbeitung verwendet wird. Es sei darauf hingewiesen, daß andere Ausführungsformen zusätzliche Informationen in der zeitweiligen Globalspeicherstruktur zusätzlich zu denjenigen enthalten können, die hier beschrieben sind. Dies kann in Einklang mit jeder speziellen Ausführungsform variieren.
  • Um nun auf 10 einzugehen, so ist in dieser Figur ein Beispiel einer Ausführungsform von Komponenten eines Computersystems 300 gezeigt, welche in Verbindung mit der Erzeugung und Modifizierung einer dynamischen RDF-Gruppe verwendet werden können. Wie hier unter anderem beschrieben wird, kann eine RDF-Gruppe als Nullvorrichtungen oder mehrere RDF-Vorrichtungen enthaltend charakterisiert werden. Im allgemeinen bedient eine spezielle RA, wie dies in Verbindung mit 2 beschrieben wurde, einen speziellen Satz von einer oder mehreren Gruppen. Obwohl auch andere Ausführungsformen und Konfigurationen möglich sind, die in Verbindung mit dem Definieren und Modifizieren einer dynamischen RDF-Gruppe verwendet werden können, so wird in den folgenden Abschnitten und Figuren ein Beispiel beschrieben, bei welchem Fernsystemrufe verwendet werden. Beispielsweise ist gemäß der Ausführungsform mit der Konfiguration 300 der Host 302 mit der Datenspeichervorrichtung X0 304 verbunden. Der Host 302 kann Fernprozedurrufe in Verbindung mit der Erzeugung eines dynamischen RDF-Gruppenpaares zwischen einem Datenspeichersystem Xn-1 306 und einem Datenspeichersystem Xn 308 verwenden. Es kann eine Anzahl von null oder es können mehrere andere Datenspeichersysteme zwischen dem Datenspeichersystem 304 und 306 vorgesehen sein. Obwohl die hier beschriebenen Techniken in Verbindung mit Fernsystemrufen verwendet werden, wo ein Host nicht direkt mit der Vorrichtung 306 verbunden ist, können die hier verwendeten Techniken auch in Verbindung mit Prozedurrufen verwendet werden, die dazu dienen, eine dynamische RDF-Gruppe zu erstellen, und zwar dort, wo auch eine direkte Verbindung zwischen dem Host 302 und dem Datenspeichersystem wie 306 vorhanden ist.
  • In Verbindung mit dem Host 302, der ein RDF-Gruppenpaar zwischen dem Datenspeichersystem 306 und 308 erzeugt, kann der Multihop-Prozedurruf wie in der U.S. Patentanmeldung Nr. 09/591,827, eingereicht am 12. Juni 2000, mit dem Titel "MULTIHOP SYSTEM CALLS" (Multihop-Systemrufe), beschrieben ist, verwendet werden, wobei diese Patentanmeldung hier unter Bezugnahme voll mit einbezogen wird. Unter Verwendung eines Multihop-Systemrufs kann der Host 302 Fernprozedurrufe verwenden, um eine RDF-Dynamikgruppe zwischen dem Datenspeichersystem 306 und 308 über eine indirekte Verbindung zu dem Datenspeichersystem 306 zu erstellen. In diesem Fall sind unter Verwendung des Multihop-Systemrufs Nachrichtenverbindungen bzw. Verbindungsglieder an einer Stelle zwischen dem Datenspeichersystem 304 und dem Datenspeichersystem 306 vorhanden. Der Bitplan, welcher in dem Multihop-Systemruf enthalten ist, zeigt an, daß lediglich das Datenspeichersystem Xn-1 306 den Fernsystemruf ausführt. Zusätzlich ist in dem Multihop-Systemruf als Parameter ein Identifizierer oder der Ferndirector an dem Datenspeichersystem 306 Xn-1 enthalten, der dafür ausgebildet ist, den Multihop-Systemruf auszuführen. Es sei darauf hingewiesen, daß, obwohl ein Multihop-Systemruf in der beschriebenen Weise verwendet werden kann, Fernsystemrufe auch in Verbindung mit dynamischen RDF-Gruppenbefehlen verwendet werden können. Eine Ausführungsform, die Fernsystemrufe verwendet, kann beispielsweise den Host 302 enthalten, der einen Fernprozedurruf zu dem Datenspeichersystem 306 ausgibt, anstatt den Systemruf über Zwischen-Datenspeichersysteme, die direkt an den Host 302 bis 306 angeschlossen sind, auszugeben.
  • Innerhalb des Speichersystems 306 als auch bei anderen Datenspeichersystemen, die bei der Ausführungsform 300 enthalten sind, können mehr als ein RA enthalten sein. Der Multihop-Systemruf wird von dem Host 302 über ein oder mehrere zwischengefügte Datenspeichersysteme weitergeschickt, bis das Datenspeichersystem 306 erreicht ist. Ein Director RA, welcher durch Parameter des Multihop-Systemrufs an dem Datenspeichersystem 306 spezifiziert ist, empfängt den Fernsystemruf und führt diesen aus. Das Datenspeichersystem 306 wartet auf den Fernsystemruf um die Ausführung zu vervollständigen. Nachfolgend wird, nachdem der Fernsystemruf die Beendigung der Erzeugung und/oder Modifizierung der dynamischen RDF-Gruppen beendet hat, der Status der Ausführung dieses Fernsystemrufs zwischen den Systemen 306 und 308 zurück über die Kette des Multihop-Systemrufs zu dem Host 302 geleitet.
  • Gemäß 11 ist ein Flußdiagramm 320 gezeigt, welches die Verarbeitungsschritte zusammenfasst, die an früherer Stelle in Verbindung mit 10 beschrieben wurden. Bei dem Schritt 322 gibt der Host einen Multihop-Systemruf über das Datenspeichersystem X0 aus. Wie in Verbindung mit der Ausführungsform 300 beschrieben wurde, ist der Host direkt mit dem Datenspeichersystem X0 verbunden und wünscht einen dynamischen RDF-Gruppenmodifizierbefehl von der Ferne aus durchzuführen, und zwar an einem anderen Datenspeichersystem, welches nicht direkt an den Host angeschlossen ist. Bei dem Schritt 324 wird der Multihop-Systemruf zu dem Datenspeichersystem Xn-1 übertragen. Es sei darauf hingewiesen, daß in Verbindung mit der Verarbeitung bei dem Schritt 324 der Multihop-Systemruf durch ein oder mehrere zwischengefügte Datenspeichersysteme ebenfalls übertragen werden kann. Bei dem Schritt 326 führt das Datenspeichersystem Xn-1 einen Fernsystemruf durch, und zwar direkt an einen RA, welcher an dem Datenspeichersystem Xn-1 gelegen ist. Bei dem Schritt 328 wird eine Bestimmung vorgenommen, ob der Fernsystemruf für die dynamische RDF-Gruppe vervollständigt worden ist. Wenn dies nicht der Fall ist, verläuft die Steuerung zurück, um in einer Schleife zu warten, die bei dem Schritt 328 gebildet wird. Wenn der Fernsystemruf für die dynamische RDF-Gruppe vervollständigt worden ist, verläuft die Steuerung zu dem Schritt 330, bei dem ein Status des Fernsystemrufs in Verbindung mit der dynamischen RDF-Gruppenoperation durch die Reihen von einer oder mehreren zwischengefügten Knotenpunkten zurück zu dem Hostcomputersystem geleitet wird, welches den Fernsystemrufbefehl ausgegeben hatte.
  • Um nun auf 12 einzugehen, so ist in dieser Figur ein Beispiel einer Ausführungsform gezeigt, welches mehr in Einzelheiten die Verarbeitungsschritte des Datenspeichersystems Xn-1 und Xn veranschaulicht. Das Datenspeichersystem Xn-1 empfängt den Fernsystemruf und führt diesen aus, um eine dynamische RDF-Gruppe zu modifizieren oder zu erzeugen, und zwar zwischen dem Datenspeichersystem Xn-1 306 und dem Datenspeichersystem Xn 308. In dem Datenspeichersystem 306 sind zwei Directoren enthalten, die als Director X und als Director Y bezeichnet werden. Der Director X empfängt zu Beginn den Fernsystemruf für die dynamische RDF-Gruppenoperation. Der Director X bestimmt, daß es sich tatsächlich um einen Fernsystemruf handelt, der durch einen anderen Director ausgeführt werden muß. Nachfolgend erzeugt der Director X eine Aufzeichnung in einer Warteschlange (queue), die als Globalsystem-(GST)-Warteschlange bezeichnet wird, um Informationen zu einem anderen Director zu übertragen, welcher in diesem Fall der Director Y ist. Die Warteschlangenaufzeichnung besteht aus einer Anfrage für einen Fernsystemruf der in Verbindung mit der Erzeugung der dynamischen RDF-Gruppe auszuführen ist. Die Ausführungsmaske zeigt den Zieldirector als Director Y an, der in den Parametern des Fernsystemrufs spezifiziert ist. Der Director X gelangt dann in einen Wartezustand. Der Director X kann zeitlich beendet werden oder leitet einen Fehlerstatus zurück oder einen anderen Typen eines Vervollständigungsstatus, und zwar nach dem Empfangen der Rückkehrstatusinformationen von dem Director Y, welche die Operation betreffen. Die Ausführungsmaske zeigt an, daß der Director Y der bezeichnete Empfänger der GST-Aufzeichnung ist, die erzeugt wird und in die GST-Warteschlange plaziert wird. Der Director Y kontaktiert dann einen anderen Director in dem Datenspeichersystem Xn 308, um Daten von dem Systemruf zu übertragen. Wie noch mehr in Einzelheiten in den folgenden Abschnitten beschrieben wird, können beide Directoren A und Y ihre jeweiligen GSTs dazu verwenden, um mit anderen Directoren zu kommunizieren, und zwar je nach Bedarf bei der Ausführung der Verarbeitungsschritte für den dynamischen RDF-Gruppenbefehl und die zugeordneten Statusinformationen.
  • Der Director Y empfängt die GST-Warteschlangenaufzeichnung und führt eine Verifizierung durch oder eine Überprüfung durch, und zwar vor dem Versuch, den Fernsystemruf auszuführen, und zwar zum Zwecke der Erzeugung der dynamischen RDF-Gruppe. Bei dieser Ausführungsform kann beispielsweise der Director Y folgendes verifizieren: daß diese spezielle RDF-Gruppe noch nicht als eine statische RDF-Gruppe für irgendeinen Director definiert wurde, daß die Gruppe noch nicht für einen Director definiert wurde, für den eine angefragte Gruppe hinzugefügt werden soll, daß die Directoren, welche diese Gruppe erzeugen sollen, lediglich von einem spezifischen Typ sind, die bei dieser speziellen Ausführungsform zugelassen sind, nämlich beispielsweise ein Faserschalter (fiber switch) oder eine GigE-Verbindung. Zusätzlich kann der Y-Director auch irgendwelche Prüfungen in Verbindung mit der Gruppenkennung durchführen und Einschränkungen in Verbindung mit dieser Ausführungsform durchführen, daß beispielsweise die Gruppenkennung keine Default-Gruppenkennung ist, da diese Operation Leergruppen involviert und die Default-Gruppenkennung bei dieser Ausführungsform für die Leergruppen nicht spezifiziert ist. Der Director Y kann auch die Seriennummer des Xn-1-Datenspeichersystems 306 prüfen, um festzustellen, ob dessen Seriennummer mit der Seriennummer übereinstimmt, die in den physikalischen Parametern des Systemrufs spezifiziert sind. Der Director Y kann auch andere Prüfungen in Verbindung mit der Einschränkung bei einer speziellen Ausführungsform vornehmen, derart, daß keine andere Zuständigkeitsstelle den dynamischen RDF-Gruppenmodifizierbefehl ausführen kann, und zwar bei diesem speziellen Datenspeichersystem. Bei der Ausführungsform fällt jedoch der Director Y darin aus, den Systemruf auszuführen, wenn der dynamische RDF-Gruppenbefehl aus einem Befehl besteht, den letzten Director zu entfernen, der eine Gruppe unterstützt, und wenn die Gruppe nicht leer ist. Es sei darauf hingewiesen, daß die speziellen Punkte, die zu Beginn durch den Director Y verifiziert werden, in Einklang mit jeder speziellen Ausführungsform variieren können. Andere Ausführungsformen können dafür Sorge tragen, andere Verifizierungen in Einklang mit spezifischen Merkmalen von jeder Ausführungsform durchzuführen.
  • Nachfolgend der aufeinander folgenden Verifizierung des Satzes von Anfangsüberprüfungen, markiert der Director Y die dynamische Gruppenblockierung in dem globalen Speicher, wobei spezielle DRGT-Einträge für diese Operation verriegelt oder gesperrt werden. Der Director Y erneuert dann seine eigene örtliche Kopie von DRGT, welches in dem nichtflüchtigen Speicher gespeichert ist, und zwar unter Verwendung der Kopie, die in dem Globalspeicher enthalten ist, und addiert dann zu seiner örtlichen Kopie die angefragte RDF-dynamische Gruppenmodifizieroperation. Wie hier auch beschrieben wird, wird davon ausgegangen, daß die Kopie in dem Globalspeicher die allerneueste Kopie in dem System ist. Der Director Y modifiziert auch geeignete Gruppenbits, um den Verbindungsgliedauffindprozeß daran zu hindern, zu starten, bevor das Datenspeichersystem Xn mit der geeigneten Gruppeninformation initialisiert wurde.
  • Der Director Y erzeugt eine zeitweilige Globalspeicherstruktur, um Informationen hinsichtlich der dynamischen RDF-Gruppenoperation zu speichern. Es sei darauf hingewiesen, daß der Globalspeicher DRGT noch nicht auf den neuesten Stand gebracht wurde. Die Information für die dynamische Gruppenmodifizierung wird in die zeitweilige Globalspeicherkopie durch den Director Y plaziert, und zwar unter Verwendung der Informationen, die in den Systemrufparametern enthalten sind, und auch anhand von anderen Örtlichkeiten.
  • Die folgenden Daten können als Eingabeparameter in dem Multihop-Systemruf enthalten sein: die Seriennummern der Datenspeichersysteme Xn und Xn-1, die Gruppenkennung, eine Gruppenzahl an Xn und eine andere Gruppenzahl an Xn-1, welche diese RDF-Gruppe definiert, eine Bitmaske der Directoren an Xn-1, welche die Gruppe unterstützt, die modifiziert wird (our_supported_dir) und eine Bitmaske der Directoren an Xn, welche die Gruppe unterstützen, die modifiziert wird (other_supported_dir). Zusätzlich können bei einer GigE-Ausführungsform die Daten eine spezielle Directornummer an Xn enthalten, mit welcher ein Director an Xn-1 kommuniziert (gige_other_side_dir_anchor). Andere Ausführungsformen können eine Kommunikation unterschiedlicher Abschnitte der Daten unter Verwendung anderer Techniken realisiert. Andere Ausführungsformen können zusätzliche Daten zu den hier beschriebenen enthalten.
  • Der Multihop-Systemruf zeigt den Director Y als Empfängerdirector an, um diesen Fernsystemruf auszuführen. Der Director Y kann den Eintrag in der DRGT entsprechend dieser Anfrage nach dem dynamischen RDF-Gruppenbefehl unter Verwendung von Daten erzeugen, die in den Systemrufparametern in der oben beschriebenen Weise mit übertragen werden und auch durch Kopieren der Informationen aus dem Globalspeicher, wie beispielsweise der statischen Konfigurationsdateidaten.
  • Der Director Y führt dann in Verbindung mit der Unterrichtung anderer RAs Schritte hinsichtlich der dynamischen RDF-Gruppenmodifizierung durch. Der Director Y kann diese Operation durch Erzeugen einer anderen Aufzeichnung durchführen und durch Einfügen derselben in die GST-Warteschlange. Die Aufzeichnung wird zu allen RAs geleitet, welche diese neue dynamische Gruppe erzeugen müssen. Die anderen RAs, welche diese Gruppe erzeugen sollen, empfangen die GST-Aufzeichnung und verifizieren, daß die Aufzeichnung durch den gleichen Director, nämlich den Director Y, ausgegeben wurde, der aktuell die dynamische Gruppenblockierung an der DRGT verriegelt hat, die in dem Globalspeicher gespeichert ist. Wenn jeder der anderen RAs erfolgreich diesen Zustand oder Zustände verifiziert hat, erneuert jedes der RAs demzufolge eine örtliche Kopie der DRGT, die in dem nichtflüchtigen Speicher gespeichert ist, und zwar unter Verwendung der Systemrufparameterinformationen, die in der zeitweiligen Globalspeicherstruktur vorhanden sind.
  • Wenn jedoch der RA-Verifizierungstest fehlschlägt, führt das RA, welches den Verifizierungsfehlschlag detektiert hat, nichts weiter durch und leitet die Fehlschlagnachricht zu dem Director Y zurück. Der Director Y wartet solange, bis alle RAs unterrichtet worden sind und eine Bestätigung zu dem Director Y zurückgeleitet haben, und zwar hinsichtlich der erfolgreichen Vervollständigung des Verifizierungstests. In einem Fall, bei dem irgendeiner der Directoren oder RAs einen Fehler zu dem Director Y zurückleitet, kann die Erzeugung der dynamischen RDF-Gruppenoperation als "nicht ausgeführt" behandelt werden. Diese Operation kann dadurch als "nicht ausgeführt" dargestellt werden, beispielsweise indem die DRGT in dem Globalspeicher nicht auf den neusten Stand gebracht wird, und zwar mit den Informationen, die in der zeitweiligen Globalspeicherstruktur gespeichert sind. Zusätzlich kann der Director Y an jedes der RAs eine Nachricht ausgeben, in solcher Weise, daß die GST-Warteschlange verwendet wird, um die örtlichen DRGT-Kopien unter Verwendung von Daten auf den neuesten Stand zu bringen, die aus der DRGT-Tabelle in dem Globalspeicher stammen.
  • Mit der Annahme, daß alle RAs erfolgreich ihre eigenen Kopien der RDF-Informationen in Verbindung mit der dynamischen Gruppenanfrage erneuert haben, bewegt sich der Director Y aus dem Wartezustand heraus und erzeugt eine Spezialaufgabe, um die dynamische RDF-Gruppenmodifizieranfrage in Einklang mit dem Fernsystemruf durchzuführen.
  • Bevor die Verarbeitung in Verbindung mit dem Erzeugen oder Entfernen einer dynamischen Gruppe an einer Fernbox beschrieben wird, werden zunächst zwei Flußdiagramme gemäß den 13 und 14 in Verbindung mit der Zusammenfassung der Verarbeitung beschrieben, wie sie durch das Datenspeichersystem Xn-1 durchgeführt werden kann.
  • Gemäß 13 ist ein Flußdiagramm 350 mit Schritten von einer Ausführungsform gezeigt, wie sie durch den Director X in Verbindung mit der Verarbeitung eines dynamischen RDF-Gruppenmodifizierbefehls ausgeführt werden. Bei dem Schritt 352 empfängt der Director X einen Befehl zur Erneuerung der dynamischen RDF-Gruppentabelle. Diese Erneuerung kann beispielsweise in Verbindung mit einem Hinzufügen oder Weglassen einer neuen RDF-Gruppe erfolgen als auch beim Modifizieren einer existierenden Gruppe. Die Steuerung verläuft dann zu dem Schritt 354, bei welchem der Director X eine Bestimmung durchführt, ob es sich bei dem richtigen empfangenen Befehl um einen Fernsystemruf handelt. Wenn es sich nicht um einen Fernsystemruf handelt, verläuft die Steuerung zu dem Schritt 356, bei dem der Director X andere Verarbeitungsschritte durchführt. Ansonsten verläuft die Steuerung zu dem Schritt 358, bei dem der Director X eine GST-Aufzeichnung unter Verwendung einer Warteschlange erzeugt, um anderen Directoren innerhalb des Datenspeichersystems Xn-1 306 mit Informationen zu versehen. Die GST-Aufzeichnung, die erzeugt wurde, identifiziert oder verweist auf den Director, der in der Systemrufausführungsmaske identifiziert ist. Bei dieser speziellen Ausführungsform wird die GST-Aufzeichnung und -Warteschlange der Kommunikationstechnik dafür verwendet, um Befehle zwischen den Directoren auszugeben als auch Informationen und Daten zwischen diesen zu übertragen. Andere Ausführungsformen können andere Techniken in Verbindung mit den Kommunikationen zwischen und innerhalb der Datenspeichersysteme verwenden.
  • Die Steuerung schreitet dann zu dem Schritt 366 voran, bei dem eine Entscheidung durch den Director X getroffen wird, ob der Fernsystemruf vervollständigt wurde oder eine Zeitüberschreitung stattgefunden hat. Der Director X verweilt in einem Wartezustand bis eines der Ereignisse auftritt. Demzufolge verläuft die Steuerung zu dem Schritt 362, nachdem entweder ein Vervollständigungsstatus zurückgeleitet wurde, der einen Erfolg anzeigt, oder ein Fehler oder eine Zeitüberschreitung aufgetreten ist. Bei dem Schritt 362 können Statusinformationen zu den anderen Directoren zurückgeleitet werden, die in der Rufkette enthalten sind, als auch zu dem Hostcomputersystem, welches anfänglich den Ruf abgesetzt hat. In Verbindung mit der Ausführung der Warteoperation bei dem Schritt 366 als auch weiteren hier beschriebenen Verarbeitungsschritten sei darauf hingewiesen, daß ein Director nicht in einem Leerlaufzustand ver bleiben muß, während dieser wartet. Eine Ausführungsform kann andere Techniken verwenden, beispielsweise kann einen Wartetask erzeugen, der signalisiert wird, wenn ein Vervollständigungsstatus zurückgeleitet wird, und zwar für einen vorbestimmten Job unter Verwendung eines Unterbrechungsmechanismus. Andere Ausführungsformen können andere Techniken verwenden, und zwar in Verbindung mit der Durchführung von Warteoperationen und Verarbeitungsschritten in Verbindung mit dem Schritt 366 oder den anderen hier beschriebenen Schritten.
  • Um nun auf 14 einzugehen, so ist in dieser Figur ein Flußdiagramm 380 gezeigt, entsprechend Schritten einer Ausführungsform, die durch einen zweiten Director, dem Director Y ausgeführt werden können, welcher in dem Datenspeichersystem 306 Xn-1 enthalten ist, und zwar in Verbindung mit einer dynamischen RDF-Gruppenoperation. Bei dem Schritt 382 empfängt der Director Y die GST-Warteschlangenaufzeichnung, die durch den Director X gesendet wurde. Der Director Y verifiziert dann die Testbedingungen, um festzustellen, ob die dynamische RDF-Gruppenoperation durchgeführt werden kann. Bei dem Schritt 384 wird eine Entscheidung getroffen, ob die Testbedingungen erfolgreich waren. Wenn nicht, verläuft die Steuerung zu dem Schritt 386, bei welchem ein Fehlerstatus zurückgeleitet werden kann. Ansonsten verläuft die Steuerung zu dem Schritt 388, bei dem der Director Y die dynamische Gruppenaufzeichnung oder Gruppenaufzeichnungen innerhalb des Globalspeichers der DRGT verriegelt, entsprechend der speziellen dynamischen Gruppenanfrageänderung, erneuert dessen örtliche DRGT, um die modifizierte Gruppenoperation zu reflektieren bzw. darzustellen, und modifiziert Gruppenbits, um zu verhindern, daß der Verbindungsgliedaufsuchprozeß startet, bevor das Datenspeichersystem Xn mit den korrekten Gruppeninformationen ausgestattet worden ist. Die Steuerung verläuft zu dem Schritt 390, bei welchem der Director Y eine zeitweilige Globalspeicherstruktur erzeugt, um die dynamische Gruppeninformationsanfrage zu halten, wie sie von den Systemrufparametern erhalten wird. Die zeitweilige Struktur wird mit diesen Informationen entsprechend initialisiert.
  • Die Steuerung verläuft zu dem Schritt 392, bei dem eine GST-Warteschlangenaufzeichnung erzeugt wird, um alle anderen RAs zu unterrichten, die eine dynamische RDF-Gruppe erzeugen müssen, und zwar in Verbindung mit dieser Operation. Mit anderen Worten, bedeutet die Verarbeitung bei dem Schritt 392 eine Nachricht zu allen den anderen RAs, um deren Kopien der DRGT entsprechend zu erneuern, um die angefragte Änderung wiederzugeben. Zusätzlich kann, wie hier auch beschrieben wird, jedes der RAs, welches in Verbindung mit dem Schritt 392 unterrichtet wurde, auch andere Testverifizierungsschritte durchführen, wie beispielsweise bis der Director, der die GST-Warteschlangenanfrage bei dem Schritt 392 ausgegeben hat, der gleiche Director, der die DRGT in dem Globalspeicher verriegelt hat. Zusätzlich erneuert jedes der RAs, welches die GST-Warteschlangenaufzeichnung empfängt, die bei dem Schritt 392 erzeugt wurde, ihre Kopie der DRGT, welche in deren örtlichem Speicher gespeichert ist. Als Teil dieses Erneuerungsprozesses wird die DRGT aus dem Globalspeicher zu Beginn kopiert und wird demzufolge mit den dynamischen Gruppeninformationen für die momentane dynamische RDF-Gruppenanfrage erneuert, und zwar unter Verwendung der zeitweiligen Globalspeicherstruktur. Jede der RAs sendet eine Nachricht zurück zu dem Director Y, welche die Vervollständigung anzeigt. Bis der Director Y einen Rückkehrstatus von alle den anderen RAs empfangen hat oder alternativ eine Zeitüberschreitung aufgetreten ist, während dieser auf den Rückführstatus wartet, gelangt der Director Y in einen Wartezustand, und zwar bei dem Schritt 394. Wenn ein Vervollständigungsstatus oder eine Zeitüberschreitung in Verbindung mit allen RAs empfangen worden ist, verläuft die Steuerung zu dem Schritt 396, bei dem eine Entscheidung getroffen wird, ob eine erfolgreiche Vervollständigung dieser GST-Warteschlangenaufzeichnungsanfrage durch all die anderen RAs vervollständigt worden ist. Wenn dies der Fall ist, verläuft die Steuerung zu dem Schritt 398, bei dem ein spezielles Task erzeugt wird, und in Verbindung mit der Übertragung der neuen RDF-Gruppenanfrageinformationen zu dem anderen Director in dem Datenspeichersystem Xn erzeugt und ausgeführt wird. Im anderen Fall, wenn keine erfolgreiche Vervollständigung stattgefunden hat oder eine Erneuerung der DRGT erfolgt ist, die örtlich in jedem der RAs enthalten ist, verläuft die Steuerung zu dem Schritt 400, bei welchem Verarbeitungsschritte in Verbindung mit "nicht getan" ("undoing") der Operation in bezug auf die örtliche Kopie der DRGT ausgeführt werden, die an jedem der RAs gespeichert ist. Bei dem Schritt 400 wird die Globalspeicherkopie der DRGT nicht erneuert. Bei dem Schritt 402 wird eine GST-Warteschlangenaufzeichnung erzeugt und zu all den anderen RAs ausgegeben, um deren örtliche Kopien der DRGT zu erneuern, und zwar unter Verwendung der nicht modifizierten Globalspeicherkopie der DRGT. Bei dem Schritt 404 leitet der Director Y einen Fehlerstatus zurück.
  • Was nun im folgenden beschrieben wird, sind Verarbeitungsschritte, die durch den Director Y durchgeführt werden können, und zwar in Verbindung mit Erneuerungs-RDF-Gruppeninformationen, die in dem Datenspeichersystem Xn enthalten sind, ohne daß dabei eine Verbindung zwischen den Datenspeichersystemen Xn-1 306 und Xn 308 erstellt wird. Es existiert eine physikalische Verbindung zwischen dem Datenspeichersystem Xn und Xn-1. Jedoch wurden keine Verarbeitungsschritte in Verbindung mit der Initialisierung dieser physikalischen Verbindung unternommen, um aktiv für Kommunikationen zwischen den zwei Directoren verwendet zu werden.
  • Wie an früherer Stelle in Verbindung mit dem Schritt 398 beschrieben wurde, wird die Verarbeitung eines Task bei dem Director Y initialisiert, um mit der Übertragung der Gruppeninformationen in Verbindung mit dem RDF-Gruppenmodifizierbefehl zu dem entfernt gelegenen Datenspeichersystem Xn zu beginnen. Die Verarbeitungsschritte berücksichtigen die Tatsache, daß eine Gruppe aus einer Leergruppe bestehen kann. Gruppeninformationen können zwischen den Datenspeichersystemen Xn und Xn-1 unter Verwendung von Parametern übertragen werden, um die erforderlichen Gruppeninformationen zu enthalten, wie diese in dem Multihop-Systemruf übertragen werden. Die in den folgenden Abschnitten beschriebene allgemeine Technik zielt darauf, zu Beginn den Verbindungsgliedauffindprozeß einzuleiten, um nach einem nicht verwendeten Verbindungsglied zwischen dem Datenspeichersystem Xn und Xn-1 zu suchen und um dann diese Initialisierung zu beenden oder den Prozeß zu starten, und zwar vor der Vervollständigung der Initialisierungsschritte, nachdem festgestellt worden ist, daß das Datenspeichersystem Xn die erneuerten Gruppeninformationen empfangen hat und einen Status zurückgeleitet hat. Nachfolgend zeigt der Director Y dieses spezielle Verbindungsglied erneut als nicht initialisiert an. Bei der folgenden Beschreibung wird angenommen, daß wenigstens ein Verbindungsglied vorhanden ist, welches nicht initialisiert worden ist und für die Verwendung zur Verfügung steht.
  • Die Zahl der verwendbaren Verbindungsglieder kann aufbewahrt und für die Verwendung in Verbindung mit der dynamischen Modifizierung und/oder Erzeugung der RDF-Gruppen verfügbar gemacht werden. Beispielsweise können bei der einen Ausführungsform 64 verwendbare Verbindungsglieder existieren und die letzten zwei Verbindungsglieder können für die Verwendung durch die hier beschriebene Technik reserviert sein. Die Zahl der verwendbaren Verbindungsglieder, die für andere Zwecke verfügbar sind, wie beispielsweise durch einen Anwender, liegt bei 62. Andere Ausführungsformen können unterschiedliche Zahlen von verfügbaren und reservierten Verbindungsgliedern umfassen und können andere Techniken anwenden, und zwar in Verbindung mit dieser Verarbeitung.
  • Bevor der Director Y den speziellen Task ausführt, wird in dem Datenspeichersystem Xn-1 unter Verwendung eines bezeichneten Verbindungsgliedindex, der einem der reservierten verfügbaren Verbindungsglieder zugeordnet ist, und zwar zwischen den Datenspeichersystemen X und Xn-1 ein neues Ziel erzeugt. Als Teil der Verarbeitung zum Erzeugen eines neuen Zieles kann der Director Y die Systemdatenstrukturen initialisieren, die zum Definieren des Verbindungsgliedes zwischen dem Director Y und einem Zieldirector in dem Datenspeichersystem Xn erforderlich sind. Der Director Y kann beispielsweise die Tabellen 142 und 144 bei einer GigE-Ausführungsform verwenden oder einen Namengebungsservice bei einer Faserschalter-Ausführungsform beim Ableiten der Zieldirectoradresse, die in den erforderlichen Datenstrukturen enthalten sein muß. Ein Verbindungsgliedindex bei diesem speziellen Beispiel ist mit jeder der speziellen Kommunikationsverbindungen zugeordnet, die für die Verwendung zwischen den Datenspeichersystemen verfügbar sind. Es kann jedoch eine physikalische Verbindung existieren und diese kann bereits in Verwendung sein, und zwar in Verbindung mit anderen Kommunikationen. Ein Verbindungsgliedindex kann einem Verbindungsglied zugeordnet sein, der als "verfügbar" betrachtet wird, wenn das Verbindungsglied momentan nicht in Verwendung ist oder zugeordnet ist, jedoch steht und läuft. Der Director Y versucht, eine Verbindung mit einem Director in dem Datenspeichersystem Xn herzustellen. Ein Vorrichtungsidentifizierer, der dem Director in dem Datenspeichersystem Xn zugeordnet ist, kann beispielsweise unter Verwendung von Routinerufen in einer API erhalten werden. Der Director Y versucht, eine Verbindung mit dem entfernt gele genen Datenspeichersystem herzustellen und kann für eine Zeitperiode warten, bis Erfolg auftritt. Der Director Y kann im anderen Fall aufgeben, und zwar nach einem Fehler oder nach einer Zeitüberschreitungsperiode.
  • Es sei darauf hingewiesen, daß in einer Faserschalter-Ausführungsform der Director Y die erforderlichen Parameterinformationen übertragen kann, um die RDF-Gruppe zu irgendeinem der Directoren von Xn aufzubauen, die durch die Bitmaske spezifiziert sind (other_supported_dir). Bei der GigE-Ausführungsform können Kommunikationen von dem Director Y direkt zu der Xn-Directornummer übertragen werden die oben angezeigt sind gemäß gige_other_side_anchor. In Verbindung mit einer Faserschalter-Ausführungsform sei darauf hingewiesen, daß die Bitmaske in den empfangenen Systemrufdaten 0 betragen kann. In diesem Fall kann der Director eine Nicht-Null-Maske aus einem früheren entsprechenden Eintrag verwenden. Für einen Fall, daß diese frühere Maske ebenfalls Null ist, kann der Director Y bestimmen, und zwar beispielsweise unter Verwendung von WWN, welche Directoren sich an dem entfernt gelegenen Datenspeichersystem Xn befinden, und kann einen für die Verwendung als "Anchor" ("Anker") bei den Kommunikationen verwenden. Wenn keine Directoren bestimmt werden, schlägt der Systemruf fehl, da der Director Y unfähig ist, mit dem entfernt gelegenen Datenspeichersystem in Kommunikation zu treten.
  • Wenn einmal eine Verbindung aufgebaut ist, bereitet der Director Y die erweiterten Parameterinformationen der neuen Gruppe vor und auch eine Anzeige, wenn es sich dabei um eine Erzeugungs- oder Weglaßoperation handelt. Der Director Y sendet diese Informationen zu einem Antwortgeber, der in dem Datenspeichersystem Xn enthalten ist. Das Datenspeichersystem Xn empfängt diesen Befehl, erkennt ihn als den ersten Befehl auf diesem Verbindungsglied und erkennt diesen Befehl als einen Versuch, eine neue Gruppe zu erzeugen. Das Datenspeichersystem Xn empfängt den Neugruppenbefehl und weiß, daß der Director Y des Datenspeichersystems Xn-1 einen speziellen Task für die dynamische Gruppenmodifizierung ausführt und stoppt demzufolge den Verbindungsgliedsuchprozeßabschnitt der Initialisierung an dem Datenspeichersystem Xn. Der Antwortgeber kann dann geeignete Hardware- und/oder Softwareeinstellungen einstellen, um das Verbindungsglied als nicht initialisiert anzuzeigen. Der Antwortgeber kann auch eine GST-Warteschlangenaufzeichnungsanfrage erzeugen, um die empfangene dynamische Gruppenänderung auszuführen, die durch einen Director an einer späteren Stelle ausgeführt wird. Der Director macht dann das Verbindungsglied in dem Datenspeichersystem Xn nicht initialisiert. Der Director leitet dann eine Statusantwort zu dem Director Y in dem Datenspeichersystem Xn-1 zurück.
  • Der Director Y empfängt die Antwort, zeigt das Verbindungsglied als nicht initialisiert in dem Datenspeichersystem Xn-1 an und macht das Ziel ungültig. Das Ziel kann beispielsweise dadurch ungültig gemacht werden, indem die geeigneten Datenstrukturen, die an früherer Stelle initialisiert wurden, ungültig gemacht werden. Dies kann beispielsweise auch ein geeignetes Einstellen von Bits umfassen, welche "unbenutzte" Systemdatenstrukturen anzeigen und/oder es können die Datenstrukturen zu einem Pool von verfügbaren Datenstrukturen zurückgeleitet werden. Das Datenspeichersystem Xn-1 nimmt dann die weitere Verarbeitung auf, und zwar mit den Verarbeitungsschritten, die nach dem speziellen Task ausgeführt werden.
  • Es wird nun ein Flußdiagramm von 15 beschrieben, welches die Verarbeitungsschritte zusammenfaßt, die eben in Verbindung mit der speziellen Taskausführung des Directors Y beschrieben wurden, und die Schritte zeigt, die ausgeführt werden, wenn der Director A die dynamischen Gruppenbefehlserzeugungsdaten empfängt.
  • Um nun auf 15 einzugehen, so ist in dieser Figur ein Flußdiagramm der Verarbeitungsschritte gezeigt, welche von beiden Datenspeichersystemen Xn und Xn-1 ausgeführt werden, ohne ein Verbindungsglied zwischen dem Datenspeichersystem, welches initialisiert wird, wenn die dynamischen Gruppenbefehlsinformationen nach Xn übertragen werden. Bei dem Schritt 420 erzeugt vor der Ausführung des speziellen Tasks an dem Datenspeichersystem Xn-1 der Director Y ein neues Ziel. Bei dem Schritt 424 wird eine Bestimmung durchgeführt, ob ein Verbindungsglied verfügbar ist. Wenn keines verfügbar ist, verläuft die Steuerung zu dem Schritt 426, bei dem ein Fehler in Verbindung mit dieser Operation zurückgeleitet wird. Im anderen Fall verläuft die Steuerung zu dem Schritt 428, bei dem neue Verbindungsparameter für dieses spezielle Verbindungsglied aufgebaut werden und ein Versuch unternommen wird, eine Verbindung mit dem Datenspeichersystem Xn herzustellen.
  • Bei dem Schritt 430 wartet der Director Y, bis ein Verbindungsstatus für das spezielle im Interesse stehende Verbindungsglied zurückgeleitet wurde. Wenn ein Erfolg nicht angezeigt wird, verläuft die Steuerung zu dem Schritt 434, bei welchem ein Fehlerstatus zurückgeleitet wird. Im anderen Fall verläuft die Steuerung von dem Schritt 432 zu dem Schritt 436, bei welchem erweiterte Parameterinformationen vorbereitet werden und zu dem Datenspeichersystem Xn gesendet werden.
  • Es sei darauf hingewiesen, daß die Schritte 420 bis 436, inklusive in dem Flußdiagramm 422 enthalten, bei diesem Beispiel durch den Director Y des Datenspeichersystems Xn-1 durchgeführt werden. Die Steuerung verläuft dann zu dem Schritt 438, bei welchem die Ausführung der Schritte ausgeführt werden kann, und zwar durch das Datenspeichersystem Xn nach dem Empfang der Informationen von dem Director Y. Ein Director von Xn, wie beispielsweise der Director A, erkennt auch, daß dies ein neuer Verbindungsversuch ist, da dies ein erster Befehl ist, der auf diesem speziellen Verbindungsglied gesendet wird. Die Steuerung gelangt dann zu dem Schritt 440, bei dem der Antwortgeberdirector an Xn bestimmt, daß ein Verbindungsglied für einen dynamischen Gruppenänderungsbefehl erzeugt worden ist. Der Antwortgeber, der Director A von Xn, bestimmt, daß dieses Verbindungsglied für eine dynamische Gruppenänderungsoperation erstellt werden soll, und das Verbindungsglied wird verwendet, um Informationen in Verbindung mit dieser Operation zu übertragen. Der Director A macht dieses Verbindungsglied nicht initialisiert. Der Director A kann eine GST-Warteschlangenaufzeichnung für den dynamischen Gruppenänderungsbefehl erzeugen, der dann an einer späteren Stelle bei dem Schritt 442 verarbeitet wird, was dazu führt, daß die neue Gruppe in Xn mit den neuen Gruppeninformationen erzeugt wird. Es sei auch darauf hingewiesen, daß im anderen Fall ein Fehler durch diesen Operationsausfall angezeigt werden kann.
  • Bei dem Schritt 444 leitet der Director A des Datenspeichersystems Xn eine Statusantwort zu dem Director Y des Datenspeichersystems Xn-1 zurück, und zwar betreffend das Ergebnis des dynamischen Gruppenerneuerungsbefehls. Der Director Y zeigt dieses Verbindungsglied auch als nicht initialisiert an dem Datenspeichersystem Xn an. Bei dem Schritt 446 empfängt der Director Y die Antwort hinsichtlich des Status und zeigt auch an, daß das Verbindungsglied nicht initialisiert ist und macht dann das Ziel ungültig.
  • Das, was nun beschrieben wird, besteht aus detaillierteren Verarbeitungsschritten von demjenigen, was innerhalb des Datenspeichersystems Xn stattfindet, wenn der Antwortgeber die Befehlsanfrage und die Parameter von dem Director Y während der Ausführung des speziellen Task empfängt. In Verbindung mit der Verarbeitung an dem Datenspeichersystem Xn empfängt der Antwortgeber die neuen Gruppeninformationen und die erweiterten Parameter, die von dem Director Y gesendet wurden. In den folgenden Abschnitten kann der Antwortgeber innerhalb des Datenspeichersystems Xn auch als Director A bezeichnet werden.
  • Der Director A an dem Datenspeichersystem Xn verifiziert, daß die Gruppe erzeugt werden kann, indem Bedingungen ähnlich denjenigen getestet werden, die beispielsweise an früherer Stelle in Verbindung mit der Verarbeitung durch den Director Y des Datenspeichersystems Xn-1 beschrieben wurden. Wenn all die Bedingungen erfolgreich verifiziert worden sind, verriegelt der Director A die dynamische Gruppenverriegelung in dem Globalspeicher. In ähnlicher Weise führt, wie an irgendeiner Stelle auch beschrieben ist, in Verbindung mit dem Datenspeichersystem Xn-1 der Director A eine Erneuerung seiner örtlichen Kopie der DRGT in dem nichtflüchtigen Speicher durch, und zwar unter Verwendung der Kopie der DRGT aus dem Globalspeicher. Der Director A kann Schritte unternehmen, um die Verarbeitungsschritte zu synchronisieren, die zwischen dem Datenspeichersystem Xn und Xn-1 stattfinden. Beispielsweise kann bei einer Ausführungsform der Director A ein Gruppenbit setzen, um zu verhindern, daß der Verbindungsgliedsuchprozeß innerhalb des Datenspeichersystems Xn startet, bevor das Datenspeichersystem Xn-1 die geeigneten Gruppeninformationen aufgebaut hat. Bei dieser Ausführungsform kann auch eine Bitmaske entsprechend jeder Gruppe in dem Globalspeicher abgespeichert sein. Die Bitmaske kann Einstellungen für jede spezielle Gruppe anzeigen. In diesem Fall kann das Gruppenbit, welches eine Verbindungsgliedsuche ermöglicht, außer Bereitschaft gesetzt werden, bis zu dem Zeitpunkt, wenn alle Verarbeitungsschritte vervollständigt worden sind, um eine neue Gruppe zu definieren, beispielsweise alle Directoren, die zum Definieren der neuen Gruppe benötigt werden, wie in dem Systembefehl spezifiziert ist, die ihre örtlichen DRGT-Einträge erneut haben und ähnliches stattgefunden hat, wie noch beschrieben wird.
  • Der Director A wird dann von dem speziellen Task, welcher beim Director Y ausgeführt wird, abgetrennt. Diese Abtrennung wird bei dieser Ausführungsform durchgeführt, im Gegensatz zur Rückführung eines Statuswertes zu dem Director Y. Der Director A kopiert dann die erweiterten Parameter, die durch den speziellen Task, der beim Director Y ausgeführt wird, zu einer zeitweiligen Globalspeicherstruktur gesendet wurden. Der Director A erzeugt eine GST-Warteschlangenaufzeichnungsanfrage für andere RAs, die zum Erzeugen dieser neuen Gruppe benötigt werden, und zwar hinsichtlich der dynamischen Gruppenänderungsinformationen, die in den erweiterten Parametern übertragen werden, und geht dann in einen Wartezustand über. Die GST-Warteschlangenaufzeichnungsanfragen, die alle RAs bezeichnen, die zum Erzeugen dieser neuen Gruppeninformationen benötigt werden, führen einen Verifizierungsschritt durch und dann, nach der erfolgreichen Verifizierung, erneuern sie ihre lokale Kopie der DRGT, um die neuen Gruppeninformationen zu enthalten. Der Verifizierungsschritt bei dieser Ausführungsform kann eine Bestimmung enthalten, wenn der Director, welcher die GST-Aufzeichnungsanfrage ausgegeben hat, der gleiche Director ist, welcher die dynamische Gruppenverriegelung in dem Globalspeicher verriegelt hat.
  • Jeder der RAs leitet eine Statusantwort zu dem Director A zurück. Wenn der Director A eine erfolgreiche Statusantwort von den anderen RAs empfängt, die die Gruppe erzeugen sollen, führt der Director A folgendes durch: Erneuerung der DRGT in dem Globalspeicher, um die neue Gruppeninformation zu enthalten, Ausschalten des Gruppenbits, um den Verbindungsgliedauffindprozeß zu ermöglichen, Ausgabe einer GST-Warteschlangenaufzeichnungsanfrage zu allen anderen Directoren, die RAs, HAs und DAs enthalten, um deren örtliche DRGT-Kopien auf den neuesten Stand zu bringen und um jegliche erforderlichen Gruppenmasken in Einklang mit dieser dynamischen Gruppenänderung zu erzeugen und auf den neuesten Stand zu bringen.
  • Alternativ, wenn irgendeiner der RAs einzeln ausfällt, wird ein Statusfehler zu dem Director A zurückgeleitet. Der Director A fährt dann mit den Verarbeitungsschritten fort, um die Erzeugung der Gruppe als "nicht getan" zu kennzeichnen, indem er beispielsweise nicht die DRGT-Kopie in dem Globalspeicher auf den neuesten Stand bringt und indem er eine Anfrage für alle RAs ausgibt, die involviert sind, um deren örtliche DRGT-Kopie mit der nicht modifizierten DRGT aus dem Globalspeicher zu überschreiben.
  • Wenn irgendeiner der Directoren ausgefallen ist, bedeutet dies, daß die Erzeugung der dynamischen Gruppeninformationen nicht ausgeführt wird, ähnlich wie dies hier beschrieben ist, in welchem Fall die GSTQ-Aufzeichnungen von all den anderen RAs ausgegeben werden, welche die Informationen nicht ausführen, die in deren örtlicher DRGT gespeichert sind. Mit anderen Worten, wird die örtliche DRGT der RAs mit der Kopie in dem Globalspeicher wieder hergestellt, die unbeeinflußt oder unberührt geblieben ist und die nicht die momentane RDF-Gruppenänderung wiedergibt. Der Director A, welcher in dem Datenspeichersystem Xn enthalten ist, antwortet dem Director Y des Datenspeichersystems Xn-1 mit einer Erfolg- oder Ausfallanzeige, verbunden mit einigen zusätzlichen Informationen für den Fall eines Fehlers oder Ausfalls. Dies kann in Einklang mit jedem Typ einer Ausführungsform variieren, und zwar exakt abhängig davon, welche Informationen übertragen werden und welche Aktionen unternommen werden.
  • Um nun auf 16 einzugehen, so ist in dieser Figur ein Flußdiagramm 550 mit Schritten von einer Ausführungsform gezeigt, welches mehr detaillierte Verarbeitungsschritte enthält, die durch den Director A ausgeführt werden können, welche an früherer Stelle in Verbindung mit den Schritten 438, 440, 442 und 444 beschrieben wurden, und zwar nach dem Empfang der neuen Gruppeninformationen. Bei dem Schritt 552 empfängt der Antwortgeberdirector A in dem Datenspeichersystem Xn die neuen Gruppeninformationen. Bei dem Schritt 554 verifiziert der Director A, daß die Gruppe erzeugt werden kann. Bei dem Schritt 556 wird eine Bestimmung durchgeführt, ob der Verifizierungsprozeß erfolgreich war. Wenn dies nicht der Fall war, verläuft die Steuerung zu dem Schritt 558, bei dem der Fehler oder Ausfall zurückgeleitet wird. Im anderen Fall verläuft die Steuerung von dem Schritt 556 zu dem Schritt 560, bei dem die DRGT in dem Globalspeicher verriegelt wird und wobei die örtliche DRGT-Kopie des Directors A auf den neuesten Stand gebracht wird, und zwar unter Verwendung der Informationen aus der Globalspeicherkopie. Zusätzlich wird die örtliche DRGT-Kopie des Directors A auf den neusten Stand gebracht, um die neuen Gruppeninformationen zu enthalten. Bei dem Schritt 561 wird das geeignete Gruppenbit gesetzt, um zu verhindern, daß der Verbindungsgliedsuchprozeß startet, und es wird der Director A von dem speziellen Task, der am Director Y ausgeführt wird, abgetrennt. Bei dem Schritt 562 wird eine zeitweilige Globalspeicherstruktur erzeugt und wird mit den Systemrufinformationen initialisiert. Bei dem Schritt 564 wird eine GST-Warteschlangenaufzeichnung erzeugt und wird zu den anderen RAs gesendet, die benötigt werden, um die neue Gruppe zu erzeugen, und zwar in Verbindung mit den neuen dynamischen Gruppeninformationen, die zu dem Director A übertragen werden. Die RAs führen eine anfängliche Verifizierungsprüfung durch und, wenn diese erfolgreich ist, erfolgt eine Erneuerung von deren örtlicher DRGT-Kopie und es wird ein Status zu dem Director A zurückgeleitet. Der Director A wartet auf den Empfang eines vollständigen Status oder einer Zeitüberschreitung von all den anderen RAs, was bei dem Schritt 570 erfolgt. Nach dem Empfang des vollständigen Status oder Zeitüberlaufs von all den anderen RAs, verläuft die Steuerung zu dem Schritt 572, bei dem eine Bestimmung vorgenommen wird, dahingehend, ob ein erfolgreicher Status für alle RAs empfangen worden ist. Wenn dies der Fall ist, verläuft die Steuerung von dem Schritt 572 zu dem Schritt 566, bei dem die DRGT in dem Globalspeicher auf den neuesten Stand gebracht wird, und zwar mit den neuen Gruppeninformationen, es werden geeignete Gruppenbits abgewandelt, um den Verbindungsgliedsuchprozeß zu ermöglichen, und es werden irgendwelche anderen Directoren, wie beispielsweise HAs oder RAs oder DAs, ebenfalls gefragt, die örtlichen DRGT-Kopien zu erneuern, und zwar hinsichtlich dieser neuen oder modifizierten RDF-Gruppe. Wie hier ebenfalls beschrieben wird, können diese Directoren die örtliche DRGT unter Verwendung der Globalspeicherkopie der DRGT und der zeitweiligen Globalspeicherstruktur auf den neuesten Stand bringen. Die Steuerung verläuft dann zu dem Schritt 568, bei dem ein Status des Erfolges von dem Director A zu dem Director Y zurückgeleitet wird.
  • Wie hier ebenfalls noch beschrieben wird, kann die Freigabe des Verbindungsgliedsuchprozesses einen automatischen Prozeß veranlassen, und zwar innerhalb des Datenspeichersystems, der zu irgendeinem späteren Zeitpunkt ausgeführt wird, um die Verarbeitung in Verbindung mit den speziellen RDF-Verbindungsgliedern zu vervollständigen, die der dynamischen Gruppe zugeordnet sind, wobei die RDF-Verbindungsglieder und die RDF-Gruppen für die Verwendung verfügbar werden.
  • Wenn bei dem Schritt 572 irgendeiner der RAs keinen Erfolg zurückmeldet, verläuft die Steuerung zu dem Schritt 574, bei dem die Globalspeicher-DRGT nicht erneuert wird, und bei dem Schritt 576 werden Befehle ausgegeben, um die früheren DRGT-Updates hinsichtlich der örtlichen Kopien von solchen RAs, die bei dem Schritt 564 unterrichtet wurden, als nicht getan zu kennzeichnen. Dies kann beispielsweise bei der vorliegenden Ausführungsform dadurch erfolgen, indem jeder der örtlichen RAs instruiert wird, die DRGT des Globalspeichers zu kopieren. Bei dem Schritt 578 wird ein Status eines Fehlers oder Ausfalls zu dem Director Y des Datenspeichersystems Xn-1 zurückgeleitet.
  • Nachfolgend, wenn das Datenspeichersystem Xn-1 einen Rückmeldestatus von dem Datenspeichersystem Xn empfangen hat, wird die Verarbeitung durch den Director Y des Datenspeichersystems Xn-1 wieder aufgenommen. Der Director Y führt eine Bestimmung durch, ob der Status der dynamischen Gruppenerzeugung erfolgreich war. Für den Fall, daß der Status anzeigt, daß alle Directoren erfolgreich waren, derart, daß alle die Directoren in beiden Datenspeichersystemen Xn und Xn-1 auf den neuesten Stand gebracht worden sind, wird die DRGT in dem Globalspeicher des Datenspeichersystems Xn-1 auf den neuesten Stand gebracht. Zusätzlich werden die erforderliche Hardware- und/oder Softwarebits und Flags in geeigneter Weise modifiziert, um den Verbindungsgliedsuchprozeß zu ermöglichen, und zwar für das neu erstellte oder neu definierte RDF-Verbindungsglied, welches dann verfügbar wird. Zusätzlich, wenn alle Directoren, bei denen angefragt wurde, um deren Tabellen in Verbindung mit dieser Operation auf den neuesten Stand zu bringen, erfolgreich waren, werden die verbleibenden Directoren, welche beispielsweise HAs, DAs und irgendwelche verbleibenden RAs enthalten, gefragt, eine GST-Warteschlangenaufzeichnung zu verwenden, um die örtlichen DRGT- Kopien auf den neuesten Stand zu bringen und um die erforderlichen Masken zu erzeugen, die auch örtlich aufrecht erhalten werden, und zwar in Einklang mit den neuen Gruppeninformationen.
  • Wenn irgendeiner der Directoren ausgefallen ist oder fehlerhaft ist, wird die Erzeugung der Gruppe als "nicht getan" bezeichnet, und zwar beispielsweise dadurch, indem die DRGT in dem Globalspeicher bei Xn-1 nicht auf den neuesten Stand gebracht wird und indem zu allen RAs, die bereits ihre örtlichen DRGTs auf den neuesten Stand gebracht haben, eine Überschreiboperation ausgegeben wird, um die örtlichen DRGTs auf den neuesten Stand zu bringen, und zwar mit einer Kopie der DRGT aus dem Globalspeicher. Der Director Y des Datenspeichersystems Xn-1 leitet Statusinformationen zu dem Director C zurück. Der Director X leitet in ähnlicher Weise Statusinformationen in Verbindung mit einem Multihop-Systemruf zurück, bis die Ergebnisse zurück zu dem Hostcomputersystem laufen, welches den Befehl ausgegeben hat.
  • In 17 ist ein Flußdiagramm von Verarbeitungsschritten gezeigt, welches die Schritte aufsummiert, die durch den Director Y ausgeführt werden, wenn der Director A des Datenspeichersystems Xn Rückmelde-Statusinformationen zu dem Director sendet. Bei dem Schritt 600 empfängt das Datenspeichersystem Xn-1 eine Antwort von dem Datenspeichersystem Xn. Es wird eine Bestimmung bei dem Datenspeichersystem Xn vorgenommen, ob die dynamische Gruppenoperation erfolgreich war. Wenn dies nicht der Fall war, verläuft die Steuerung zu dem Schritt 606, bei dem die Erzeugung der Gruppe als nicht erledigt bezeichnet wird, und zwar an dem Datenspeichersystem Xn-1, indem die Globalspeicherkopie der DRGT nicht auf den neuesten Stand gebracht wird. Bei dem Schritt 608 wird eine GST-Warteschlangenaufzeichnung erzeugt mit der Anfrage, daß alle die RAs, die an früherer Stelle die örtlichen DRGT-Kopien modifiziert erhielten, die örtlichen DRGT-Kopien mit der nicht modifizierten DRGT aus dem Globalspeicher ersetzt bekommen.
  • Wenn der Prozeß bei dem Schritt 604 angelangt ist, wird bestimmt, daß die Dynamikgruppenerzeugung erfolgreich war, und die Steuerung verläuft dann zu dem Schritt 610, bei dem die DRGT in dem Globalspeicher erneuert wird, und zwar unter Verwendung der Kopie, die an früherer Stelle in der zeitweiligen Struktur, die erzeugt wurde, gespeichert ist. Zusätzlich verläuft die Steuerung zu dem Schritt 612, bei dem irgendwelche erforderliche Hardware- und/oder Softwareeinstellungen modifiziert werden, um das neue Verbindungsglied anzuzeigen, und zwar als verfügbar, indem der Verbindungsgliedsuchprozeß ermöglicht wird oder freigegeben wird. Zusätzlich werden bei dem Schritt 613 irgendwelche verbleibenden Directoren, die beispielsweise HAs, DAs und verbliebene RAs enthalten, über eine GST-Warteschlangenaufzeichnung angefragt, ihre örtlichen Kopien der DRGT auf den neuesten Stand zu bringen, um die neue dynamische RDF-Gruppe wiederzugeben.
  • Es sei darauf hingewiesen, daß die vorangegangene Beschreibung eine dynamische Gruppenverriegelung enthält, wie sie beispielsweise in Verbindung mit dem Schritt 388 und 560 bzw. deren Verarbeitung verwendet wird, und zwar in jedem Datenspeichersystem in dem Globalspeicher. Obwohl dies nicht explizit bei irgendeinem der nachfolgenden Verarbeitungsschritte festgestellt worden ist, wird die dynamische Gruppenverriegelung innerhalb jedes Datenspeichersystems freigegeben, wenn die Verarbeitung, die dem dynamischen RDF-Gruppensystemruf zugeordnet ist, vervollständigt worden ist, und zwar innerhalb von jedem betreffenden Datenspeichersystem. Beispielsweise kann die Verriegelung vor der Rückleitung eines Erfolgs- oder Fehlerstatus zu einem anderen Director in einem anderen Datenspeichersystem freigegeben werden, wie dies bei den vielfältigen Verarbeitungsschritten angezeigt wird, die oben beschrieben wurden.
  • Es können auch Zeitmarken jeder Kopie der DRGT zugeordnet werden, die in dem örtlichen nichtflüchtigen Speicher von jedem Director gespeichert sind, und auch in der Globalspeicherkopie ebenfalls gespeichert sind. Für den Fall, daß ein Stromversorgungsausfall auftritt, kann beispielsweise die DRGT mit der letzten Zeitmarke dazu verwendet werden, um andere Versionen der DRGT in dem Globalspeicher zu synchronisieren, und auch zwischen anderen örtlichen Directoren.
  • Eine dynamische Gruppe kann zu Beginn erzeugt werden und es können Vorrichtungen und Verbindungsglieder dynamisch zu dieser Gruppe hinzu addiert werden, unter Verwendung einer dynamischen Konfigurationsdatei, beispielsweise unter Verwendung von dynamischen RDF-Techniken, wie sie in der U.S. Patentanmeldung Nr. 09/997,810, eingereicht am 30. November 2001, beschrieben sind. In Verbindung mit dem zuvor erläuterten Dynamikgruppenbefehl können verschiedene Dynamikgruppenoperationen durchgeführt werden. Beispielsweise kann ein Director, der eine Gruppe von einem oder von beiden Datenspeichersystemen Xn und Xn-1 bedient, entfernt werden und es kann ein Director, der eine Gruppe von einem oder von beiden Datenspeichersystemen Xn und Xn-1 bedient, hinzu addiert werden.
  • Es sei darauf hingewiesen, daß bei der vorangegangenen Beschreibung eine einzelne Gruppe von mehr als einem Director in dem gleichen Datenspeichersystem bedient werden kann.
  • Die vorangegangen beschriebenen Ausführungsformen liefern eine flexible und effektive Technik, um einen dynamischen RDF-Gruppenbefehl durchzuführen, ohne daß dabei ein Verbindungsglied zwischen zwei Datenspeichersystemen benötigt wird, welches initialisiert wird und zum Übertragen von Anwenderdaten bereitgestellt wird. Das physikalische Verbindungsglied existiert zwischen zwei Systemen, ist jedoch nicht für Kommunikationen zwischen den zwei Systemen zugeordnet oder dafür aufgebaut. Es werden Teilinitialisierungsverarbeitungsschritte durchgeführt, um Informationen zu Beginn durchzuschleusen, wie beispielsweise Aufbau- und Befehlsdaten von dem ersten zu dem zweiten System, und um eine Bestätigung zu dem ersten System zurückzuleiten. Das Verbindungsglied wird dann initialisiert, und zwar als nicht-initialisiert, bis sowohl das erste als auch das zweite Datenspeichersystem den verbleibenden Aufbau durchführen und die Initialisierungsverarbeitung vor der Ermöglichung des Verbindungsgliedes zwischen den zwei Systemen realisierbar wird und erkannt wird und bei den Kommunikationen zwischen den zwei Systemen zum Übertragen von Anwenderdaten verwendet wird.
  • In Verbindung mit der vorangegangenen Beschreibung sei darauf hingewiesen, daß ein erstes Verbindungsglied, welches zum Übertragen von dynamischen Gruppenkonfigurationsinformationen verwendet wird, verschieden von einem zweiten Verbin dungsglied sein kann, welches beim Übertragen der Anwenderdaten verwendet wird. Beispielsweise können in der beschriebenen Art Verbindungsglieder 62 und 63 dafür verwendet werden, um die Gruppeninformationen durchzuleiten, wobei die verbleibenden Verbindungsglieder 0 bis 61, inklusive, für die Übertragung von Anwenderdaten verfügbar sind. Andere Ausführungsformen können andere Verbindungsgliedbestimmungen beim Übertragen von Anwender- und/oder Gruppenkonfigurationsdaten verwenden.
  • Obwohl die Erfindung in Verbindung mit bevorzugten Ausführungsformen offenbart wurde, die in Einzelheiten dargestellt und beschrieben wurden, sind für Fachleute deren Abwandlungen und Verbesserungen unmittelbar zu erkennen. Daher wird der Rahmen der vorliegenden Erfindung lediglich durch die nachfolgenden Ansprüche definiert und beschränkt.
  • Zusammenfassung
  • Es sind Techniken beschrieben, die bei der dynamischen Modifizierung von RDF-Gruppen (A, B, C, D) verwendet werden. Ein Systemruf wird durch ein Hostcomputersystem (14a–14n) ausgegeben, um einen Fernsystemruf an einem ersten Datenspeichersystem (50a) auszuführen, um eine RDF-Gruppe zu erzeugen, zu entfernen oder zu modifizieren, und zwar zwischen dem ersten Datenspeichersystem (50a) und einem anderen Datenspeichersystem (50b), welches entfernt an das erste Datenspeichersystem in einer RDF-geschalteten Umgebung angeschlossen ist. Als Teil der Ausführungsform des Fernsystemrufs werden Daten von dem ersten zu dem zweiten Datenspeichersystem durchgeschleust, ohne dabei ein aufgebautes Verbindungsglied zwischen den Datenspeichersystemen zur Verfügung zu haben. Jedes Datenspeichersystem führt eine Verarbeitung durch, um die erforderlichen Modifikationen in allen Directoren in Einklang mit der dynamischen RDF-Gruppe durchzuführen. Ein Status, der einen Erfolg oder einen Fehler oder Ausfall des Fernsystemrufs anzeigt, wird zu dem Hostcomputersystem (14a–14n) zurückgeleitet.
    (1)

Claims (42)

  1. Verfahren zum dynamischen Modifizieren eines Kommunikationspfades zwischen einer ersten Gruppe von Vorrichtungen in einem ersten Datenspeichersystem und einer zweiten Gruppe von Vorrichtungen in einem zweiten Datenspeichersystem, mit den folgenden Schritten: Ausgeben einer Befehlsanfrage an das erste Datenspeichersystem, um den Kommunikationspfad dynamisch zu modifizieren; Durchschleusen von Aufbaudaten von dem ersten Datenspeichersystem zu einem zweiten Datenspeichersystem unter Verwendung eines Kommunikationsverbindungsgliedes, welches nicht dafür bereit ist, Anwenderdaten zu übertragen; Vorbereiten eines ersten Teiles einer Verbindung zu der ersten Gruppe der Vorrichtungen; nach einer erfolgreichen Vorbereitung des ersten Teiles, Vorbereiten eines zweiten Teiles der Verbindung zu der zweiten Gruppe der Vorrichtungen; und nach der erfolgreichen Vorbereitung des ersten und des zweiten Teiles der Verbindung, Anzeigen, daß der Kommunikationspfad dafür bereit ist, um Anwenderdaten zu übertragen.
  2. Verfahren nach Anspruch 1, ferner mit den folgenden Schritten: vor der Vorbereitung des ersten Teiles der Verbindung verifiziert ein erster Prozessor in dem ersten Datenspeichersystem mit Hilfe eines ersten Serviceprozes sors, der die erste Gruppe von Vorrichtungen bedient, ob der Kommunikationspfad in Einklang mit der Befehlsanfrage modifiziert werden kann; und vor der Vorbereitung des zweiten Abschnitts der Verbindung verifiziert ein zweiter Prozessor in dem zweiten Datenspeichersystem mit Hilfe eines zweiten Serviceprozessors, der die zweite Gruppe von Vorrichtungen bedient, ob der Kommunikationspfad in Einklang mit der Befehlsanfrage modifiziert werden kann.
  3. Verfahren nach Anspruch 1, bei dem das Vorbereiten des ersten Teiles der Kommunikationsverbindung ein Modifizieren einer Tabelle enthält, welche dynamische Konfigurationsinformationen für die erste Gruppe der Vorrichtungen enthält.
  4. Verfahren nach Anspruch 3, bei dem das Vorbereiten des zweiten Teiles der Kommunikationsverbindung das Modifizieren einer Tabelle enthält, welche dynamische Konfigurationsinformationen für die zweite Gruppe von Vorrichtungen enthält.
  5. Verfahren nach Anspruch 1, ferner mit den folgenden Schritten: ein erster Prozessor in dem ersten Datenspeichersystem sendet eine Befehlsanfrage zu wenigstens einem Serviceprozessor des ersten Datenspeichersystem, welches in der Befehlsanfrage identifiziert ist; und ein zweiter Prozessor in dem zweiten Datenspeichersystem sendet eine Befehlsanfrage zu wenigstens einem Serviceprozessor des zweiten Datenspeichersystems, welches in der Befehlsanfrage identifiziert ist.
  6. Verfahren nach Anspruch 1, mit dem folgenden Schritt: ein Hostcomputersystem gibt die Befehlsanfrage aus.
  7. Verfahren nach Anspruch 6, bei dem das Hostcomputersystem einen Fernprozedurruf zu dem ersten Datenspeichersystem ausgibt.
  8. Verfahren nach Anspruch 7, bei dem das Hostcomputersystem den Fernprozedurruf zu dem ersten Datenspeichersystem direkt über wenigstens ein anderes Zwischen-Datenspeichersystem ausgibt, welches mit dem ersten Datenspeichersystem verbunden ist.
  9. Verfahren nach Anspruch 8, bei dem das erste Datenspeichersystem einen Rückleitstatus zu dem Hostcomputersystem sendet.
  10. Verfahren nach Anspruch 1, bei dem das Kommunikationsverbindungsglied teilweise initialisiert wird.
  11. Verfahren nach Anspruch 1, bei dem die Aufbaudaten über ein Kommunikationsverbindungsglied unter Verwendung eines Schalters durchgeschleust werden.
  12. Verfahren nach Anspruch 11, bei dem der Schalter wenigstens eine der folgenden Einrichtungen enthält: eine GigE-Verbindung und eine Faserschalterverbindung.
  13. Verfahren nach Anspruch 12, bei dem die Verbindung eine Faserschalterverbindung ist, und wobei das Verfahren die folgenden Schritte umfaßt: Ableiten einer Adresse des zweiten Datenspeichersystems mit Hilfe des ersten Datenspeichersystems unter Verwendung eines Namensgebungsservice mit Daten, die in der Befehlsanfrage enthalten sind.
  14. Verfahren nach Anspruch 12, bei dem die Verbindung eine GigE-Verbindung ist und das Verfahren folgende Schritte umfaßt: Ableiten einer Adresse des zweiten Datenspeichersystems durch das erste Datenspeichersystem unter Verwendung von wenigstens einer Konfigurationstabelle, die in dem ersten Datenspeichersystem gespeichert ist.
  15. Verfahren nach Anspruch 1, bei dem die Befehlsanfrage für eine der folgenden Aufgaben bestimmt ist: dynamisches Erzeugen einer neuen Gruppe, dynamisches Entfernen einer Gruppe, dynamisches Addieren eines Directors, um eine der ersten und zweiten Gruppen der Vorrichtungen zu bedienen, und dynamisches Entfernen eines Directors, der eine der ersten und zweiten Gruppen der Vorrichtungen bedient.
  16. Verfahren nach Anspruch 1, bei dem wenigstens eine der ersten und zweiten Gruppen der Vorrichtungen leer ist.
  17. Verfahren nach Anspruch 1, welches die folgenden Schritte umfaßt: Ausfallen lassen der Ausführung der Befehlsanfrage, wenn die Befehlsanfrage sich darauf richtet, einen Serviceprozessor aus dem Service von einer der ersten und zweiten Gruppen der Vorrichtungen zu entfernen und der Serviceprozessor der einzige Serviceprozessor ist, der die eine der ersten und zweiten Gruppen bedient, und wenn die eine der ersten und zweiten Gruppe nicht leer ist.
  18. Verfahren nach Anspruch 1, ferner mit den folgenden Schritten: Anzeigen, daß ein Abschnitt eines Bestimmungsdatenträgers in der zweiten Gruppe der Vorrichtungen ungültige Daten enthält; und Kopieren der Daten aus einem Quellendatenträger in der ersten Gruppe der Vorrichtungen zu dem Bestimmungsdatenträger nach der Anzeige, daß der Kommunikationspfad für die Übertragung von Daten bereit ist.
  19. Verfahren nach Anspruch 1, ferner mit den folgenden Schritten: Anzeigen, daß ein Abschnitt eines Bestimmungsdatenträgers in der ersten Gruppe der Vorrichtungen ungültige Daten enthält; und Kopieren der Daten aus einem Quellendatenträger in der zweiten Gruppe der Vorrichtungen zu dem Bestimmungsdatenträger nach der Anzeige, daß der Kommunikationspfad für eine Übertragung von Daten bereit ist.
  20. Verfahren nach Anspruch 2, ferner mit den folgenden Schritten: der zweite Prozessor wartet auf alle Serviceprozessoren in dem zweiten Datenspeichersystem, die in der Befehlsanfrage spezifiziert sind, zum Modifizieren des Kommunikationspfades, um einen Status zurückzuleiten; nach dem Empfang eines erfolgreichen Status von allen Serviceprozessoren in dem zweiten Datenspeichersystem, Erneuern einer Globalkopie der dynamischen Konfigurationsdaten in dem zweiten Datenspeichersystem mit einer Modifikation, die in der Befehlsanfrage angezeigt wird; und Erneuern der Kopien der dynamischen Konfigurationsdaten, die örtlich durch andere Prozessoren in dem zweiten Datenspeichersystem gehalten werden.
  21. Verfahren nach Anspruch 20, ferner mit den folgenden Schritten: Empfangen eines Rückleitstatus von dem zweiten Prozessor durch den ersten Prozessor mit der Aussage, ob das zweite Datenspeichersystem in erfolgreicher Weise die Vorbereitung des zweiten Teiles der Verbindung vervollständigt hat; wobei im Ansprechen auf den Empfang eines Erfolgsrückleitstatus von dem zweiten Prozessor, die von dem ersten Prozessor durchgeführte Verarbeitung folgendes umfaßt: Erneuern einer Globalkopie der dynamischen Konfigurationsdaten in dem ersten Datenspeichersystem mit einer Modifikation, die in der Befehlsanfrage angezeigt wird; und Erneuern der Kopien der dynamischen Konfigurationsdaten, die örtlich durch andere Prozessoren in dem ersten Datenspeichersystem gehalten werden.
  22. Computerprogrammprodukt zum dynamischen Modifizieren eines Kommunikationspfades zwischen einer ersten Gruppe an Vorrichtungen in einem ersten Datenspeichersystem und einer zweiten Gruppe von Vorrichtungen in einem zweiten Datenspeichersystem, mit: maschinenausführbaren Anweisungen zur Ausgabe einer Befehlsanfrage zu dem ersten Datenspeichersystem, um den Kommunikationspfad dynamisch zu modifizieren; maschinenausführbaren Anweisungen zum Durchschleusen von Aufbaudaten von dem ersten Datenspeichersystem zu einem zweiten Datenspeichersystem unter Verwendung eines Kommunikationsverbindungsgliedes, welches nicht für die Übertragung von Anwenderdaten bereit ist; maschinenausführbaren Anweisungen zum Vorbereiten eines ersten Teiles einer Verbindung zu der ersten Gruppe der Vorrichtungen; maschinenausführbaren Anweisungen, um nach der erfolgreichen Vorbereitung des ersten Teiles einen zweiten Teil der Verbindung zu der zweiten Gruppe der Vorrichtungen vorzubereiten; und maschinenausführbaren Anweisungen, um nach der erfolgreichen Vorbereitung des ersten und des zweiten Teiles der Verbindung anzuzeigen, daß der Kommunikationspfad für die Übertragung von Anwenderdaten bereit ist.
  23. Computerprogrammprodukt nach Anspruch 22, ferner mit: maschinenausführbaren Anweisungen, um mit Hilfe eines ersten Prozessors in dem ersten Datenspeichersystem vor der Vorbereitung des ersten Teiles der Verbindung, mit Hilfe eines ersten Serviceprozessors, der die erste Gruppe der Vorrichtungen bedient, zu verifizieren, ob der Kommunikationspfad in Einklang mit der Befehlsanfrage modifiziert werden kann; und maschinenausführbaren Instruktionen, um mit Hilfe eines zweiten Prozessors in dem zweiten Datenspeichersystem vor der Vorbereitung des zweiten Abschnitts der Verbindung mit Hilfe eines zweiten Serviceprozessors, der die zweite Gruppe der Vorrichtungen bedient, zu verifizieren, ob der Kommunikationspfad in Einklang mit der Befehlsanfrage modifiziert werden kann.
  24. Computerprogrammprodukt nach Anspruch 22, bei dem der maschinenausführbare Kode zum Vorbereiten des ersten Teiles der Kommunikationsverbindung einen maschinenausführbaren Kode zum Modifizieren einer Tabelle enthält, welche dynamische Konfigurationsinformationen für die erste Gruppe der Vorrichtungen enthält.
  25. Computerprogrammprodukt nach Anspruch 24, bei dem die maschinenausführbaren Anweisungen zum Vorbereiten des zweiten Teiles der Kommunikationsverbindung maschinenausführbare Anweisungen zum Modifizieren einer Tabelle enthalten, welche dynamische Konfigurationsinformationen für die zweite Gruppe der Vorrichtungen enthält.
  26. Computerprogrammprodukt nach Anspruch 22, ferner mit: einem maschinenausführbaren Kode, um mit Hilfe eines ersten Prozessors in dem ersten Datenspeichersystem eine Befehlsanfrage zu wenigstens einem Serviceprozessor des ersten Datenspeichersystems, der in der Befehlsanfrage identifiziert ist, zu senden; und maschinenausführbaren Anweisungen, um über einen zweiten Prozessor in dem zweiten Datenspeichersystem eine Befehlsanfrage zu wenigstens einem Serviceprozessor des zweiten Datenspeichersystems zu senden, welches in der Befehlsanfrage identifiziert ist.
  27. Computerprogrammprodukt nach Anspruch 22, mit: einem maschinenausführbaren Kode zur Ausgabe einer Befehlsanfrage durch einen Hostcomputer.
  28. Computerprogrammprodukt nach Anspruch 27, ferner mit einem maschinenausführbaren Kode, um durch das Hostcomputersystem einen Fernprozedurruf zu dem ersten Datenspeichersystem auszugeben.
  29. Computerprogrammprodukt nach Anspruch 28, ferner mit einem maschinenausführbaren Kode, um durch das Hostcomputersystem den Fernprozedurruf zu dem ersten Datenspeichersystem indirekt über wenigstens ein anderes Zwischen-Datenspeichersystem auszugeben, welches mit dem ersten Datenspeichersystem verbunden ist.
  30. Computerprogrammprodukt nach Anspruch 29, ferner mit einem maschinenausführbaren Kode, um durch das erste Datenspeichersystem einen Rückmeldestatus zu dem Hostcomputersystem zurückzuleiten.
  31. Computerprogrammprodukt nach Anspruch 22, bei dem das Kommunikationsverbindungsglied teilweise initialisiert ist.
  32. Computerprogrammprodukt nach Anspruch 22, bei dem die Aufbaudaten über ein Kommunikationsverbindungsglied unter Verwendung eines Schalters durchgeschleust werden.
  33. Computerprogrammprodukt nach Anspruch 32, bei dem der Schalter wenigstens eine der Einrichtungen gemäß einer GigE-Verbindung und einer Faserschalter-Verbindung enthält.
  34. Computerprogrammprodukt nach Anspruch 33, bei dem die Verbindung aus einer Faserschalter-Verbindung besteht und das Computerprogrammprodukt ferner folgendes aufweist: einen maschinenausführbaren Kode, um durch das erste Datenspeichersystem eine Adresse des zweiten Datenspeichersystems unter Verwendung eines Namensgebungsservices mit Daten, die in der Befehlsanfrage enthalten sind, abzuleiten.
  35. Computerprogrammprodukt nach Anspruch 33, bei dem die Verbindung eine GigE-Verbindung ist und das Computerprogrammprodukt ferner folgendes aufweist: einen maschinenausführbaren Kode, um durch das erste Datenspeichersystem eine Adresse des zweiten Datenspeichersystems unter Verwendung von wenigstens einer Konfigurationstabelle, die in dem ersten Datenspeichersystem gespeichert ist, abzuleiten.
  36. Computerprogrammprodukt nach Anspruch 22, bei dem die Befehlsanfrage eine der folgenden Möglichkeiten betrifft: dynamisches Erzeugen einer neuen Gruppe, dynamisches Entfernen einer Gruppe, dynamisches Hinzufügen eines Directors, um eine der ersten und zweiten Gruppen der Vorrichtungen zu bedienen, und dynamisches Entfernen eines Directors, der eine der ersten und zweiten Gruppen der Vorrichtungen bedient.
  37. Computerprogrammprodukt nach Anspruch 22, bei dem wenigstens eine der ersten und zweiten Gruppen an Vorrichtungen leer ist.
  38. Computerprogrammprodukt nach Anspruch 22, ferner mit: einem maschinenausführbaren Kode, um die Befehlsanfrage als Ausfall zu behandeln bzw. auszuführen, wenn die Befehlsanfrage darin besteht, einen Serviceprozessor zu entfernen, der eine der ersten und zweiten Gruppen der Vorrichtungen bedient und wenn der Serviceprozessor der einzige Serviceprozessor ist, der eine der ersten und zweiten Gruppen bedient und eine der ersten und zweiten Gruppen nicht leer ist.
  39. Computerprogrammprodukt nach Anspruch 22, ferner mit: einem maschinenausführbaren Kode, um anzuzeigen, daß ein Abschnitt eines Bestimmungsort-Datenträgers in der zweiten Gruppe der Vorrichtungen ungültige Daten enthält; und einem maschinenausführbaren Kode, um Daten von einem Quellendatenträger in der ersten Gruppe der Vorrichtungen nach einem Bestimmungsort-Datenträger zu kopieren, und zwar nach der Anzeige, daß der Kommunikationspfad für die Übertragung von Daten bereit ist.
  40. Computerprogrammprodukt nach Anspruch 22, ferner mit: einem maschinenausführbaren Kode, um anzuzeigen, daß ein Abschnitt eines Bestimmungsort-Datenträgers in der ersten Gruppe der Vorrichtungen ungültige Daten enthält; und einem maschinenausführbaren Kode, um Daten von einem Quellendatenträger in der zweiten Gruppe der Vorrichtungen nach einem Bestimmungsort-Datenträger zu kopieren, und zwar nach der Anzeige, daß der Kommunikationspfad für die Übertragung von Daten bereit ist.
  41. Computerprogrammprodukt nach Anspruch 23, ferner mit: einem maschinenausführbaren Kode, um über den zweiten Prozessor auf alle Serviceprozessoren in dem zweiten Datenspeichersystem zu warten, die in der Befehlsanfrage spezifiziert sind, den Kommunikationspfad zur Rückleitung eines Status zu modifizieren; einem maschinenausführbaren Kode, um nach dem Empfang eines erfolgreichen Status von allen Serviceprozessoren in dem zweiten Datenspeichersystem, eine Globalkopie der dynamischen Konfigurationsdaten in dem zweiten Datenspeichersystem mit einer Modifikation, die in der Befehlsanfrage angezeigt ist, auf den neuesten Stand zu bringen; und einem maschinenausführbaren Kode, um Kopien der dynamischen Konfigurationsdaten, die örtlich durch andere Prozessoren in dem zweiten Datenspeichersystem gehalten werden, auf den neuesten Stand zu bringen.
  42. Computerprogrammprodukt nach Anspruch 41, ferner mit: einem maschinenausführbaren Kode, um durch den ersten Prozessor einen Rückleitstatus von dem zweiten Prozessor zu empfangen, mit der Information, ob das zweite Datenspeichersystem erfolgreich die Vorbereitung des zweiten Teiles der Verbindung vervollständigt hat; einem maschinenausführbaren Kode, der im Ansprechen auf den Empfang eines erfolgreichen Rückleitstatus von dem zweiten Prozessor den ersten Prozessor veranlaßt, eine Verarbeitung durchzuführen, wobei: eine Globalkopie der dynamischen Konfigurationsdaten in dem ersten Datenspeichersystem mit einer Modifikation auf den neuesten Stand gebracht wird, die in der Befehlsanfrage angezeigt ist; und wobei Kopien der dynamischen Konfigurationsdaten, die örtlich durch andere Prozessoren in dem ersten Datenspeichersystem gehalten werden, auf den neuesten Stand gebracht werden.
DE10392181T 2002-10-02 2003-09-04 Dynamische RDF-Gruppen Ceased DE10392181T5 (de)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US10/262,684 US6910075B2 (en) 2001-11-14 2002-10-02 Dynamic RDF groups
US10/262,684 2002-10-02
PCT/US2003/027442 WO2004031971A1 (en) 2002-10-02 2003-09-04 Dynamic rdf groups

Publications (1)

Publication Number Publication Date
DE10392181T5 true DE10392181T5 (de) 2005-08-25

Family

ID=32068262

Family Applications (1)

Application Number Title Priority Date Filing Date
DE10392181T Ceased DE10392181T5 (de) 2002-10-02 2003-09-04 Dynamische RDF-Gruppen

Country Status (7)

Country Link
US (2) US6910075B2 (de)
JP (1) JP2006500693A (de)
CN (1) CN100416538C (de)
AU (1) AU2003270060A1 (de)
DE (1) DE10392181T5 (de)
GB (1) GB2398203B (de)
WO (1) WO2004031971A1 (de)

Families Citing this family (80)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7150000B1 (en) * 1999-08-17 2006-12-12 Nash Controlware, Inc. Component development with autonomous and compiled components to implement and consume services with components operate in edit and run mode
US20040054698A1 (en) * 2002-09-18 2004-03-18 Hitachi, Ltd. Layered computer system with thin clients
JP4598387B2 (ja) * 2003-09-17 2010-12-15 株式会社日立製作所 記憶システム
US7219201B2 (en) 2003-09-17 2007-05-15 Hitachi, Ltd. Remote storage disk control device and method for controlling the same
US7185223B2 (en) * 2003-09-29 2007-02-27 International Business Machines Corporation Logical partitioning in redundant systems
JP2005157521A (ja) * 2003-11-21 2005-06-16 Hitachi Ltd 遠隔記憶装置の状態情報監視方法および記憶サブシステム
US7426578B2 (en) 2003-12-12 2008-09-16 Intercall, Inc. Systems and methods for synchronizing data between communication devices in a networked environment
US8589513B1 (en) * 2003-12-23 2013-11-19 Emc Corporation Remote mirroring of group name services
JP4421385B2 (ja) 2004-06-09 2010-02-24 株式会社日立製作所 計算機システム
US7716180B2 (en) * 2005-12-29 2010-05-11 Amazon Technologies, Inc. Distributed storage system with web services client interface
US20070185882A1 (en) * 2006-02-06 2007-08-09 International Business Machines Corporation Method and system for selective tracking of semantic web data using distributed update events
US7751398B1 (en) 2007-03-28 2010-07-06 Emc Corporation Techniques for prioritization of messaging traffic
US9396283B2 (en) 2010-10-22 2016-07-19 Daniel Paul Miranker System for accessing a relational database using semantic queries
US9304960B2 (en) * 2013-06-04 2016-04-05 Avago Technologies General Ip (Singapore) Pte. Ltd. Delayed physical link activation in serial attached small computer system interface devices that utilize smart cabling
US9606870B1 (en) 2014-03-31 2017-03-28 EMC IP Holding Company LLC Data reduction techniques in a flash-based key/value cluster storage
US10324635B1 (en) 2016-03-22 2019-06-18 EMC IP Holding Company LLC Adaptive compression for data replication in a storage system
US10565058B1 (en) 2016-03-30 2020-02-18 EMC IP Holding Company LLC Adaptive hash-based data replication in a storage system
US10324925B2 (en) 2016-06-19 2019-06-18 Data.World, Inc. Query generation for collaborative datasets
US11016931B2 (en) 2016-06-19 2021-05-25 Data.World, Inc. Data ingestion to generate layered dataset interrelations to form a system of networked collaborative datasets
US10824637B2 (en) 2017-03-09 2020-11-03 Data.World, Inc. Matching subsets of tabular data arrangements to subsets of graphical data arrangements at ingestion into data driven collaborative datasets
US11755602B2 (en) 2016-06-19 2023-09-12 Data.World, Inc. Correlating parallelized data from disparate data sources to aggregate graph data portions to predictively identify entity data
US11675808B2 (en) 2016-06-19 2023-06-13 Data.World, Inc. Dataset analysis and dataset attribute inferencing to form collaborative datasets
US11042560B2 (en) 2016-06-19 2021-06-22 data. world, Inc. Extended computerized query language syntax for analyzing multiple tabular data arrangements in data-driven collaborative projects
US10452975B2 (en) 2016-06-19 2019-10-22 Data.World, Inc. Platform management of integrated access of public and privately-accessible datasets utilizing federated query generation and query schema rewriting optimization
US10645548B2 (en) 2016-06-19 2020-05-05 Data.World, Inc. Computerized tool implementation of layered data files to discover, form, or analyze dataset interrelations of networked collaborative datasets
US11086896B2 (en) 2016-06-19 2021-08-10 Data.World, Inc. Dynamic composite data dictionary to facilitate data operations via computerized tools configured to access collaborative datasets in a networked computing platform
US11023104B2 (en) 2016-06-19 2021-06-01 data.world,Inc. Interactive interfaces as computerized tools to present summarization data of dataset attributes for collaborative datasets
US11334625B2 (en) 2016-06-19 2022-05-17 Data.World, Inc. Loading collaborative datasets into data stores for queries via distributed computer networks
US10747774B2 (en) 2016-06-19 2020-08-18 Data.World, Inc. Interactive interfaces to present data arrangement overviews and summarized dataset attributes for collaborative datasets
US11042548B2 (en) 2016-06-19 2021-06-22 Data World, Inc. Aggregation of ancillary data associated with source data in a system of networked collaborative datasets
US11941140B2 (en) 2016-06-19 2024-03-26 Data.World, Inc. Platform management of integrated access of public and privately-accessible datasets utilizing federated query generation and query schema rewriting optimization
US11042537B2 (en) 2016-06-19 2021-06-22 Data.World, Inc. Link-formative auxiliary queries applied at data ingestion to facilitate data operations in a system of networked collaborative datasets
US11068847B2 (en) 2016-06-19 2021-07-20 Data.World, Inc. Computerized tools to facilitate data project development via data access layering logic in a networked computing platform including collaborative datasets
US11036716B2 (en) 2016-06-19 2021-06-15 Data World, Inc. Layered data generation and data remediation to facilitate formation of interrelated data in a system of networked collaborative datasets
US10984008B2 (en) 2016-06-19 2021-04-20 Data.World, Inc. Collaborative dataset consolidation via distributed computer networks
US10438013B2 (en) 2016-06-19 2019-10-08 Data.World, Inc. Platform management of integrated access of public and privately-accessible datasets utilizing federated query generation and query schema rewriting optimization
US10699027B2 (en) 2016-06-19 2020-06-30 Data.World, Inc. Loading collaborative datasets into data stores for queries via distributed computer networks
US11042556B2 (en) 2016-06-19 2021-06-22 Data.World, Inc. Localized link formation to perform implicitly federated queries using extended computerized query language syntax
US10853376B2 (en) 2016-06-19 2020-12-01 Data.World, Inc. Collaborative dataset consolidation via distributed computer networks
US10353911B2 (en) 2016-06-19 2019-07-16 Data.World, Inc. Computerized tools to discover, form, and analyze dataset interrelations among a system of networked collaborative datasets
US10452677B2 (en) 2016-06-19 2019-10-22 Data.World, Inc. Dataset analysis and dataset attribute inferencing to form collaborative datasets
US10346429B2 (en) 2016-06-19 2019-07-09 Data.World, Inc. Management of collaborative datasets via distributed computer networks
US10691710B2 (en) * 2016-06-19 2020-06-23 Data.World, Inc. Interactive interfaces as computerized tools to present summarization data of dataset attributes for collaborative datasets
US11468049B2 (en) 2016-06-19 2022-10-11 Data.World, Inc. Data ingestion to generate layered dataset interrelations to form a system of networked collaborative datasets
US11036697B2 (en) 2016-06-19 2021-06-15 Data.World, Inc. Transmuting data associations among data arrangements to facilitate data operations in a system of networked collaborative datasets
US11947554B2 (en) 2016-06-19 2024-04-02 Data.World, Inc. Loading collaborative datasets into data stores for queries via distributed computer networks
US11068475B2 (en) 2016-06-19 2021-07-20 Data.World, Inc. Computerized tools to develop and manage data-driven projects collaboratively via a networked computing platform and collaborative datasets
US11068453B2 (en) 2017-03-09 2021-07-20 data.world, Inc Determining a degree of similarity of a subset of tabular data arrangements to subsets of graph data arrangements at ingestion into a data-driven collaborative dataset platform
US11238109B2 (en) 2017-03-09 2022-02-01 Data.World, Inc. Computerized tools configured to determine subsets of graph data arrangements for linking relevant data to enrich datasets associated with a data-driven collaborative dataset platform
US11169727B1 (en) * 2017-03-10 2021-11-09 Pure Storage, Inc. Synchronous replication between storage systems with virtualized storage
US10409520B1 (en) 2017-04-27 2019-09-10 EMC IP Holding Company LLC Replication of content-based storage using address space slices
US10503609B1 (en) 2017-04-27 2019-12-10 EMC IP Holding Company LLC Replication link smoothing using historical data
US10922308B2 (en) 2018-03-20 2021-02-16 Data.World, Inc. Predictive determination of constraint data for application with linked data in graph-based datasets associated with a data-driven collaborative dataset platform
US11243960B2 (en) 2018-03-20 2022-02-08 Data.World, Inc. Content addressable caching and federation in linked data projects in a data-driven collaborative dataset platform using disparate database architectures
US10853221B2 (en) 2018-05-04 2020-12-01 EMC IP Holding Company LLC Performance evaluation and comparison of storage systems
US10860239B2 (en) 2018-05-04 2020-12-08 EMC IP Holding Company LLC Fan-out asynchronous replication caching
US11360688B2 (en) 2018-05-04 2022-06-14 EMC IP Holding Company LLC Cascading snapshot creation in a native replication 3-site configuration
US10705753B2 (en) 2018-05-04 2020-07-07 EMC IP Holding Company LLC Fan-out asynchronous replication logical level caching
USD920353S1 (en) 2018-05-22 2021-05-25 Data.World, Inc. Display screen or portion thereof with graphical user interface
USD940732S1 (en) 2018-05-22 2022-01-11 Data.World, Inc. Display screen or portion thereof with a graphical user interface
US11537990B2 (en) 2018-05-22 2022-12-27 Data.World, Inc. Computerized tools to collaboratively generate queries to access in-situ predictive data models in a networked computing platform
US11327991B2 (en) 2018-05-22 2022-05-10 Data.World, Inc. Auxiliary query commands to deploy predictive data models for queries in a networked computing platform
USD940169S1 (en) 2018-05-22 2022-01-04 Data.World, Inc. Display screen or portion thereof with a graphical user interface
US11947529B2 (en) 2018-05-22 2024-04-02 Data.World, Inc. Generating and analyzing a data model to identify relevant data catalog data derived from graph-based data arrangements to perform an action
US11442988B2 (en) 2018-06-07 2022-09-13 Data.World, Inc. Method and system for editing and maintaining a graph schema
US11048722B2 (en) 2018-07-31 2021-06-29 EMC IP Holding Company LLC Performance optimization for data persistency in asynchronous replication setups
US10613793B1 (en) 2018-11-01 2020-04-07 EMC IP Holding Company LLC Method to support hash based xcopy synchronous replication
US10719249B1 (en) 2019-01-31 2020-07-21 EMC IP Holding Company LLC Extent lock resolution in active/active replication
US10853200B2 (en) 2019-02-01 2020-12-01 EMC IP Holding Company LLC Consistent input/output (IO) recovery for active/active cluster replication
US11194666B2 (en) 2019-04-26 2021-12-07 EMC IP Holding Company LLC Time addressable storage in a content addressable storage system
US10719257B1 (en) 2019-04-29 2020-07-21 EMC IP Holding Company LLC Time-to-live (TTL) license management in an active/active replication session
US11216388B2 (en) 2019-04-30 2022-01-04 EMC IP Holding Company LLC Tiering between storage media in a content aware storage system
FR3097994B1 (fr) * 2019-06-28 2022-03-11 St Microelectronics Rousset Modification d'une mémoire d'un microprocesseur sécurisé
US11301138B2 (en) 2019-07-19 2022-04-12 EMC IP Holding Company LLC Dynamic balancing of input/output (IO) operations for a storage system
US10908828B1 (en) 2019-07-25 2021-02-02 EMC IP Holding Company LLC Enhanced quality of service (QoS) for multiple simultaneous replication sessions in a replication setup
US11238063B2 (en) 2019-07-25 2022-02-01 EMC IP Holding Company LLC Provenance-based replication in a storage system
US11429493B2 (en) 2020-01-20 2022-08-30 EMC IP Holding Company LLC Remote rollback of snapshots for asynchronous replication
US11281407B1 (en) 2020-09-23 2022-03-22 EMC IP Holding Company LLC Verified write command in active-active replication
US11593396B2 (en) 2020-09-23 2023-02-28 EMC IP Holding Company LLC Smart data offload sync replication
US11947600B2 (en) 2021-11-30 2024-04-02 Data.World, Inc. Content addressable caching and federation in linked data projects in a data-driven collaborative dataset platform using disparate database architectures

Family Cites Families (29)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5206939A (en) 1990-09-24 1993-04-27 Emc Corporation System and method for disk mapping and data retrieval
US5544347A (en) 1990-09-24 1996-08-06 Emc Corporation Data storage system controlled remote data mirroring with respectively maintained data indices
US5253344A (en) * 1991-09-05 1993-10-12 International Business Machines Corp. Method and apparatus for dynamically changing the configuration of a logically partitioned data processing system
EP0537903A2 (de) * 1991-10-02 1993-04-21 International Business Machines Corporation Verteiltes Kontrollsystem
US5555371A (en) * 1992-12-17 1996-09-10 International Business Machines Corporation Data backup copying with delayed directory updating and reduced numbers of DASD accesses at a back up site using a log structured array data storage
US5574950A (en) * 1994-03-01 1996-11-12 International Business Machines Corporation Remote data shadowing using a multimode interface to dynamically reconfigure control link-level and communication link-level
GB9501378D0 (en) * 1995-01-24 1995-03-15 Ibm A system and method for establishing a communication channel over a heterogeneous network between a source node and a destination node
US6047323A (en) * 1995-10-19 2000-04-04 Hewlett-Packard Company Creation and migration of distributed streams in clusters of networked computers
US5806074A (en) * 1996-03-19 1998-09-08 Oracle Corporation Configurable conflict resolution in a computer implemented distributed database
US5845147A (en) 1996-03-19 1998-12-01 Emc Corporation Single lock command for an I/O storage system that performs both locking and I/O data operation
US5857208A (en) 1996-05-31 1999-01-05 Emc Corporation Method and apparatus for performing point in time backup operation in a computer system
US5778394A (en) 1996-12-23 1998-07-07 Emc Corporation Space reclamation system and method for use in connection with tape logging system
US6504817B2 (en) * 1997-03-31 2003-01-07 Hewlett-Packard Company Fiber channel arbitrated loop dynamic loop sizing
JPH1115761A (ja) * 1997-06-02 1999-01-22 Internatl Business Mach Corp <Ibm> 赤外線通信機能を持つ情報処理装置及びその制御方法
US6144999A (en) * 1998-05-29 2000-11-07 Sun Microsystems, Incorporated Method and apparatus for file system disaster recovery
US6295448B1 (en) * 1998-09-21 2001-09-25 Telefonaktiebolaget Lm Ericsson (Publ) Short distance communication and remote control capability for mobile telephones
US6574239B1 (en) * 1998-10-07 2003-06-03 Eric Morgan Dowling Virtual connection of a remote unit to a server
US6529963B1 (en) * 1998-12-29 2003-03-04 Lsi Logic Corporation Methods and apparatus for interconnecting independent fibre channel fabrics
US6324563B1 (en) * 1998-12-30 2001-11-27 Compaq Computer Corporation Customer information control system application programming interface, with global and local system and file control functions, in a loosely coupled data processing environment
US6389432B1 (en) * 1999-04-05 2002-05-14 Auspex Systems, Inc. Intelligent virtual volume access
US6519660B1 (en) * 1999-09-28 2003-02-11 International Business Machines Corporation Method, system and program products for determining I/O configuration entropy
US6982939B2 (en) * 2000-02-02 2006-01-03 Lsi Logic Corporation Write compensation for data storage and communication systems
US20010027491A1 (en) * 2000-03-27 2001-10-04 Terretta Michael S. Network communication system including metaswitch functionality
US7088720B1 (en) * 2000-08-07 2006-08-08 Sbc Technology Resources, Inc. Multiservice use of network connection capability under user-to-network interface signaling
US6742028B1 (en) * 2000-09-15 2004-05-25 Frank Wang Content management and sharing
WO2002061525A2 (en) * 2000-11-02 2002-08-08 Pirus Networks Tcp/udp acceleration
US6985956B2 (en) * 2000-11-02 2006-01-10 Sun Microsystems, Inc. Switching system
US20020188754A1 (en) * 2001-04-27 2002-12-12 Foster Michael S. Method and system for domain addressing in a communications network
US6862632B1 (en) * 2001-11-14 2005-03-01 Emc Corporation Dynamic RDF system for transferring initial data between source and destination volume wherein data maybe restored to either volume at same time other data is written

Also Published As

Publication number Publication date
CN1602479A (zh) 2005-03-30
GB2398203A (en) 2004-08-11
US20030093597A1 (en) 2003-05-15
JP2006500693A (ja) 2006-01-05
WO2004031971A1 (en) 2004-04-15
CN100416538C (zh) 2008-09-03
US7240116B2 (en) 2007-07-03
GB0410972D0 (en) 2004-06-16
AU2003270060A1 (en) 2004-04-23
US20060031526A1 (en) 2006-02-09
GB2398203B (en) 2006-03-01
US6910075B2 (en) 2005-06-21

Similar Documents

Publication Publication Date Title
DE10392181T5 (de) Dynamische RDF-Gruppen
DE60113586T2 (de) Übertragen von miteinander verbundenen Datenobjekten in einer verteilten Datenspeicherumgebung
DE602004005344T2 (de) Verfahren, system und programm zur handhabung eines failover zu einem fernspeicherort
DE60212922T2 (de) Umkehr eines Kommunikationspfades zwischen Speichergeräten
DE69929095T2 (de) Verwaltung eines durch eine Mehrzahl von Knoten benutzten Betriebsmittels
DE60312746T2 (de) Wiederherstellung nach fehlern in datenverarbeitungsanlagen
DE69724846T2 (de) Mehrweg-Ein/Ausgabespeichersysteme mit Mehrweg-Ein/Ausgabeanforderungsmechanismus
DE60034327T2 (de) Verfahren und systeme zur implementierung von verwaltungsfunktionen für gemeinsam genutzte plattenanordnungen
DE19982999B4 (de) Computersystem und Verfahren zum Transferieren von Daten
DE69923621T2 (de) Verfahren und Vorrichtung zu korrekten und vollständigen Übertragungen in einem fehlertoleranten verteilten Datenbanksystem
DE60030397T2 (de) Belastungsverteilung in einem Netzwerk
DE69918467T2 (de) Servervorrichtung und Verfahren deren Verwendung
DE60214234T2 (de) Verfahren und apparate zum implementieren einer glasfaservermittlungseinheit mit hoher verfügbarkeit
DE60018872T2 (de) System und Methode für das Löschen von Datenbank-Aktualisierungsbilddateien nach Abschluss der dazugehörigen Transaktionen
DE69724834T2 (de) System für hochverfügbare datenspeicherung mit allgemein-adressiertem speicher
DE4497149B4 (de) Computerbezogenes Verfahren zur Datenreplikation in Peer-to-Peer-Umgebung
DE10393771T5 (de) Schnelle Datensicherungsspeicherung und schnelle Datenwiederherstellung (FBSRD)
DE10197179T5 (de) Fern-Spiegelung in einer geschalteten Umgebung
DE112014006156B4 (de) Speichersystem und Datenmigrationsverfahren
EP0807883B1 (de) Kommunikationssystem mit Mitteln zum Austausch von Softwareprozessen
DE102006059378A1 (de) Nachrichtenübermittlung mit mehrfacher Priorität
DE10112941A1 (de) System und Verfahren für das parallele Lesen von primären und sekundären Sicherungen zur Wiederherstellung mehrerer gemeinsam benutzter Datenbankdateien
DE112014006605T5 (de) Speichersystem
DE10236179A1 (de) Speichersystem und Verfahren zur Verwendung desselben
DE602004005666T2 (de) Speichervorrichtung für asynchrone entfernte Datenspiegelung

Legal Events

Date Code Title Description
8110 Request for examination paragraph 44
R016 Response to examination communication
R002 Refusal decision in examination/registration proceedings
R006 Appeal filed
R008 Case pending at federal patent court
R003 Refusal decision now final
R011 All appeals rejected, refused or otherwise settled