US20010014954A1 - System and method for fail-over data transport - Google Patents
System and method for fail-over data transport Download PDFInfo
- Publication number
- US20010014954A1 US20010014954A1 US09/840,671 US84067101A US2001014954A1 US 20010014954 A1 US20010014954 A1 US 20010014954A1 US 84067101 A US84067101 A US 84067101A US 2001014954 A1 US2001014954 A1 US 2001014954A1
- Authority
- US
- United States
- Prior art keywords
- processing unit
- computer system
- communications link
- transport
- memory allocation
- 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.)
- Granted
Links
- 238000000034 method Methods 0.000 title claims abstract description 26
- 238000004891 communication Methods 0.000 claims abstract description 56
- 238000001514 detection method Methods 0.000 claims abstract description 16
- 230000032258 transport Effects 0.000 claims description 89
- 230000015654 memory Effects 0.000 claims description 48
- 238000012545 processing Methods 0.000 claims description 45
- 239000003795 chemical substances by application Substances 0.000 claims description 11
- 239000000835 fiber Substances 0.000 claims description 4
- 230000007246 mechanism Effects 0.000 abstract description 5
- 230000007723 transport mechanism Effects 0.000 abstract description 4
- CHBOSHOWERDCMH-UHFFFAOYSA-N 1-chloro-2,2-bis(4-chlorophenyl)ethane Chemical compound C=1C=C(Cl)C=CC=1C(CCl)C1=CC=C(Cl)C=C1 CHBOSHOWERDCMH-UHFFFAOYSA-N 0.000 description 41
- UCTWMZQNUQWSLP-VIFPVBQESA-N (R)-adrenaline Chemical compound CNC[C@H](O)C1=CC=C(O)C(O)=C1 UCTWMZQNUQWSLP-VIFPVBQESA-N 0.000 description 39
- 239000000872 buffer Substances 0.000 description 23
- 230000002093 peripheral effect Effects 0.000 description 22
- 238000002399 angioplasty Methods 0.000 description 7
- 230000008859 change Effects 0.000 description 4
- 238000012546 transfer Methods 0.000 description 3
- 238000012384 transportation and delivery Methods 0.000 description 3
- 238000005516 engineering process Methods 0.000 description 2
- 230000000977 initiatory effect Effects 0.000 description 2
- 230000037361 pathway Effects 0.000 description 2
- 230000008569 process Effects 0.000 description 2
- 238000003491 array Methods 0.000 description 1
- 238000000429 assembly Methods 0.000 description 1
- 230000000712 assembly Effects 0.000 description 1
- 230000005540 biological transmission Effects 0.000 description 1
- 230000015572 biosynthetic process Effects 0.000 description 1
- 238000010276 construction Methods 0.000 description 1
- 238000013523 data management Methods 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 230000006870 function Effects 0.000 description 1
- 238000002955 isolation Methods 0.000 description 1
- 238000007726 management method Methods 0.000 description 1
- 230000008520 organization Effects 0.000 description 1
- 230000009046 primary transport Effects 0.000 description 1
- 238000010926 purge Methods 0.000 description 1
- 238000011084 recovery Methods 0.000 description 1
- 238000002407 reforming Methods 0.000 description 1
- 238000013468 resource allocation Methods 0.000 description 1
- 230000026676 system process Effects 0.000 description 1
- 230000001131 transforming effect Effects 0.000 description 1
Images
Classifications
-
- 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/2002—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 interconnections or communication control functionality are redundant
- G06F11/2007—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 interconnections or communication control functionality are redundant using redundant communication media
Definitions
- the present invention relates generally to the handling of data transport failures and fail-over capability for data transfers within a computer system such as a server. More particularly, the present invention is directed to a system and method that establishes a secondary link for fail-over data transfer in the event of primary link failure. More particularly, also the system and method of the present invention are applicable for Input/Output Processors (IOPs) in an I 2 O (intelligent input/output) environment.
- IOPs Input/Output Processors
- Computer systems have achieved wide usage in modern society. During operation, a computer system processes and stores data at a speed and at a level of accuracy many times that which can be performed manually. Successive generations of computer systems have permitted ever-increasing amounts of data to be processed at ever-increasing rates.
- Computer systems are sometimes operated as standalone devices or connected together by way of network connections, typically together with a network server, to form a computer network.
- network connections typically together with a network server, to form a computer network.
- files and other data stored or generated at one computer system can be readily transferred to another computer system.
- a conventional computer system typically includes one or more CPUs (central processing units) capable of executing algorithms forming applications, and a computer main memory.
- Peripheral devices both those embedded on a backplane of the computer system, or constructed to be separate therefrom, also typically form portions of a conventional computer system.
- Computer peripheral devices include, for instance, video graphics adapters, LAN (local area network) interfaces, SCSI (small computer system interface) adapters, and mass storage devices, such as disk drive assemblies.
- a computer system further typically includes data buses which permit the communication of data between portions of the computer system.
- a host bus for instance, a memory bus, at least one high-speed bus, a local peripheral expansion bus, and one or more additional peripheral buses form portions of a typical computer system.
- a peripheral bus is formed, for instance, of a SCSI bus, an EISA (extension to industry standard architecture) bus, an ISA (industry standard architecture) bus, or a PCI (peripheral component interface) bus.
- the peripheral bus forms a communication path to and from a peripheral device connected thereto.
- the computer system CPU or a plurality of CPUs in a multi-processor system, communicates with a computer peripheral device by way of a computer bus, such as one or more of the computer buses noted above.
- a computer peripheral depending upon its data transfer speed requirements, is connected to an appropriate computer bus, typically by way of a bus bridge that detects required actions, arbitrates, and translates both data and addresses between the various buses.
- a computer peripheral device forming a portion of a single computer system might well be supplied by a manufacturer other than the manufacturer of the computer CPU. If the computer system contains more than one peripheral device, the peripheral devices might also be supplied by different manufacturers. Furthermore, the computer system may be operable pursuant to any of several different operating systems. The various combinations of computer peripheral devices and computer operating systems of which a computer system might be formed quickly becomes quite large.
- Software drivers are typically required for each computer peripheral device to effectuate its operation.
- a software driver must be tailored to be operable together with the operating system pursuant to which the computer system is operable.
- a computer peripheral device must, therefore, have associated therewith a software driver to be operable together with any of the several operating systems pursuant to which the computer system might be operable.
- a multiplicity of software drivers might have to be created for a single computer peripheral to ensure that a computer peripheral device is operable together with any of the different operating systems.
- I 2 O intelligent input/output
- the I 2 O standard specification sets forth, inter alia, standards for an I/O device driver architecture that is independent of both a specific peripheral device being controlled and the operating system of the computer system at which the device driver is to be installed.
- the portion of the driver that is responsible for managing the peripheral device is logically separated from the specific implementation details for the operating system which is to be installed. Because of this, the part of the driver that manages the peripheral device becomes portable across different computer and operating systems.
- the I 2 O standard specification also generalizes the nature of communication between the host computer system and peripheral hardware, thus providing processor and bus technology independence.
- Construction of computer systems compliant with the I 2 O standard specification facilitates formation of a computer system having component portions supplied by different suppliers while also assuring that the different component portions of the computer system shall be operable when connected together. Upgrading an existing computer system to be I 2 O aware assures that subsequent upgrading of the computer system shall be able to be effectuated simply.
- fault tolerance One difficulty inherent in all computer systems is the handling of a variety of system faults and their recovery, also referred to as fault tolerance.
- the identification, control and isolation of such faults is especially important in current devices which employ Error Checking Correcting (ECC) memory, Redundant Arrays of Inexpensive Drives (RAID) and hot-swappable disk drives, and even hot-swappable power supplies.
- ECC Error Checking Correcting
- RAID Redundant Arrays of Inexpensive Drives
- hot-swappable disk drives and even hot-swappable power supplies.
- fault tolerance techniques begin with an initial focus on memory and physical storage subsystems, and now includes various fail-over solutions. Current servers implement such fail-over solutions for storage subsystems and LAN-LAN routing.
- I 2 O may be used to incorporate new levels of fail-over for I/O subsystems.
- One particular area of interest is the peer-to-peer and clustering capabilities of I 2 O.
- Peer-to-peer technology allows two I/O Processors (IOPs) to communicate with each other independently of the host CPUs and the media connecting the two IOPs.
- Clustering extends the peer-to-peer concept outside of the physical system (or unit) defined by the I 2 O specification.
- the respective DDMs then automatically close the connection with the remote IOP and lose all of the resources previously allocated by that DDM on that remote IOP. Furthermore, the DDMs, upon transport failure, must tear down their respective operating environments and completely rebuild them. Even if a redundant link is found, the entire buffer allocation and DDM-to-DDM setup must begin anew.
- the present invention is directed to a system and method for maintaining communications within a computer system after a data transport failure across a first link. Fail-over capability is attained by re-establishing communications across a secondary link using different transport mechanisms. For example, between two Input/Output Processors (IOPs) within a computer system, such as a server, a series of data transactions therebetween are queued until transaction completion. Upon detection of a failure condition between the IOPs across the first link, the IOPs engage fail-over mechanisms therein to preserve uncompleted data transactions until communications are re-established across the secondary link.
- IOPs Input/Output Processors
- FIG. 1 depicts a portion of the system architecture for a conventional computer system, illustrating inter-processor communications across a primary media link;
- FIG. 2 illustrates the improved system architecture of the present invention, which incorporates a secondary media link in addition to the primary media link shown in FIG. 1;
- FIG. 3 illustrates a data send fail-over queue that may be used in the present invention;
- FIG. 4 illustrates a data move fail-over queue that may be used in the present invention.
- FIG. 5 illustrates a data redirect fail-over queue that may be used in the present invention.
- FIG. 1 Shown in FIG. 1 is a general illustration of some of the features of the aforementioned I 2 O architecture, which abstracts the underlying transport mechanisms through the creation of a class of Application Program Interfaces (APIs), defining a set of common services for all transports.
- APIs Application Program Interfaces
- IOP 10 A includes therein a first DDM (or I 2 O Real Time Operating System) 14 A, a first Peer Transport Agent (PTA) 16 A in communication with the DDM 14 A, and a first multiplicity of transports, generally designated in FIG. 1 by the reference numeral 18 .
- DDM or I 2 O Real Time Operating System
- PTA Peer Transport Agent
- IOP 10 B contains therein a second DDM 14 B, a second PTA 16 B and a second multiplicity of transports 18 .
- IOP 10 A communicates, via a first of said transports 18 A, with IOP 10 B via another of said transports 18 B therein across media link 12 .
- each transport 18 is hardware devices and/or software applications operating at the transport layer, according to the International Standards Organization Operating Systems Interconnection model (ISO OSI).
- ISO OSI International Standards Organization Operating Systems Interconnection model
- each transport 18 represents a specific protocol for transforming data across a given media.
- multiple transports may exist for a single media, for example, in currently available network adaptors such as Transmission Control Protocol/Internet Protocol (TCP/IP), NetBIOS Extended User Interface (NetBEUI), ServerNet, Fibre Channel or a number of other communication networks.
- TCP/IP Transmission Control Protocol/Internet Protocol
- NetBEUI NetBIOS Extended User Interface
- ServerNet Fibre Channel or a number of other communication networks.
- IOPs 10 A and 10 B all communication paths between IOPs, such as IOPs 10 A and 10 B, must be quiesced before adaptor replacement. After all paths have been torn down, the failed adaptor is placed in reset and powered down.
- the respective hot-plug drivers in the host Operating System (OS) and on a given IOP work in conjunction to preserve the IOP's state information, e.g., the IOP's Target Identification (TID), an identifier for each device in an I 2 O system. After replacement, the adaptor is powered up and taken out of reset.
- OS Operating System
- TID Target Identification
- the DDMs 14 After the host OS′ hot-plug driver and Peer OS Specific Module (OSM) reestablish DDM-to-DDM connectivity, e.g., between DDMs 14 A and 14 B in FIG. 1, the DDMs 14 must individually create new connections to each remote IOP, attach and claim the requisite remote DDMs and allocate any local and remote memory necessary. It should be understood, however, that although the state (TID) information may persist across boot cycles and hot-plug events, the memory allocations do not. Without automatic fail-over protection to maintain resource allocations on remote IOPs, conventional computer apparatus and methods, whether non-I 2 O or I 2 O in nature, are inadequate to preserve the connection after a connection failure.
- OSM Peer OS Specific Module
- the Peer Transport Agents 16 described in connection with FIG. 1, of the present invention preferably incorporate Fail-Over Management mechanisms, generally designated by the reference numeral 20 , therein. Also shown in FIG. 2 are two media links 12 A and 12 B. In particular, the IOPs 10 A and 10 B in FIG.
- transports 18 A 1 and 18 B 1 across media link 12 A are actively connected to each other via transports 18 A 1 and 18 B 1 across media link 12 A, for example, by a cable (network, serial, Fibre Channel, etc.) If that cable were somehow disabled or disconnected, however, the primary media link 12 A would fail and IOPs 10 A and 10 B would, upon such disconnection and processor reset, reallocate any local and remote resources, such as storage space on respective memories 22 A and 22 B shown in FIG. 2.
- inter-DDM communication and resources are maintained after primary media link 12 A failure by the use of the redundant, backup media link 12 B, secondarily connecting the IOPs 10 A and 10 B via transports 18 A 2 and 18 B 2 , respectively.
- the redundant pathway connecting the DDMs 14 A and 14 B the respective PTAs 16 A and 16 B would automatically switch over from the nonfunctional primary media link 12 A to the redundant media link 12 B without interrupting the operation of each IOP's 10 peer DDMs 14 , thereby minimizing the impact of the link failure on the respective DDMs 14 . In other words, no disconnection and subsequent reset and reallocation occurs.
- the PTAs 16 keep track of all peer requests/transactions and the associated memory allocation(s). Further details on the data management functionality of the aforementioned preferred embodiment for implementing the aforedescribed transport fail-over system and method are described hereinbelow.
- a DDM e.g., DDM 14 A in IOP 10 A
- the request goes through the associated PTA 16 A, which is responsible for tracking each DDM's 14 message, data delivery requests and associated status information.
- the PTA 16 A preferably uses a portion of the IOP's 10 A memory, e.g., memory 22 A described hereinbefore in connection with DDM 14 A, to store data regarding outstanding DDM requests and remote memory allocations.
- the PTA 16 forwards the aforementioned data service request through the pertinent transports 18 , via media 12 , to the indicated remote IOP.
- the reply message contains a conventional scatter gather list (SGL) describing the remote buffers involved, e.g., for PTA 16 A accessing the remote data in memory 22 B.
- SGL scatter gather list
- the PTA 16 stores a copy of the returned remote buffer identifier, e.g., remBufAllocID, and correlates the identifier with an access status indicator, along with the state (TID) information of the DDM 12 requesting the allocation.
- Boolean or other flag values may be employed for each DDM 14 to indicate normal access to memory 22 , prohibited memory access due to transport failure, etc.
- the data send requests from the DDMs 14 are preferably tracked by a data send service and the respective PTA 16 holds a list of all outstanding data send transactions, each identified by a DataSendID identifier.
- a data send completion handler Upon successful completion of a given transaction, a data send completion handler removes that transaction from the outstanding list and passes completion status to the originating Data Delivery Service User (DDSU), i.e., the aforedescribed DDM 14 .
- DDSU Data Delivery Service User
- the transaction is then posted to the data send service's fail-over queue, e.g., DataSendFOQ.
- DataSendFOQ data send service's fail-over queue
- the pertinent transport 18 signals a loss of connectivity
- all pending and new transactions to the particular remote IOP are posted to the aforementioned DataSendFOQ, which is used by the PTA 16 during link re-establishment.
- FIG. 3 A preferred data structure for the DataSendFOQ is illustrated in FIG. 3 in which a head pointer, HeadDataSendFOQ 30 , points to a first field of a DataSend record 32 , DataSendID 32 A, which is the particular identifier or object handler for the data object/transaction.
- DataSend record 32 also includes an OwnerID field 32 B which indicates the identifier (TID) of the initiating DDM 14 , a PeerTransportTID field 32 C which indicates the particular transport 18 used for data send service, a TimeOfFailure field 32 D which includes a timestamp for the failure, a ReestablishmentCount field 32 E which indicates the number of retries attempted, and a NextPtr field 32 F which points to the start of another, next DataSend record 32 or contains a NULL to indicate the end of the linked list.
- TID identifier
- PeerTransportTID field 32 C which indicates the particular transport 18 used for data send service
- TimeOfFailure field 32 D which includes a timestamp for the failure
- ReestablishmentCount field 32 E which indicates the number of retries attempted
- a NextPtr field 32 F which points to the start of another, next DataSend record 32 or contains a NULL to indicate the end of the linked list.
- Data movement in the preferred embodiment of the present invention is a virtualized, Direct Memory Access (DMA) service where the data is moved between explicitly defined source and destination buffers.
- DMA Direct Memory Access
- a data move service within the PTA 16 tracks all DDM 14 requests by maintaining a data structure for all outstanding transactions.
- data send service when data move transactions successfully complete, they too are removed from the outstanding list and completion status is returned to the initiating DDSU, e.g., a DDM 14 or an I 2 O Real Time Operating System (IRTOS).
- I 2 O Real Time Operating System I 2 O Real Time Operating System
- the transaction is then posted to the data move service's fail-over queue, e.g., DataMoveFOQ. If the pertinent peer transport 18 signals a loss of connectivity, all pending and new transactions to the pertinent remote IOP are posted to the DataSendFOQ, which is used by the PTA 16 during the link re-establishment process.
- the structure for the DataMoveFOQ is shown in FIG. 4, which is similar to the DataSendFOQ structure shown in FIG. 3.
- a HeadDataMoveFOQ pointer 40 points to a DataMoveID field 42 A of the DataMove record 42 .
- Fields 42 B-F correspond to the fields 32 B-F described in connection with FIG. 3.
- a similar record data structure may be utilized to implement other functions, e.g., a data redirect fail-over queue, DataRedirFOQ, which employs a HeadDataRedirFOQ 50 and fields 52 A-F of a DataRedirect record 52 , as illustrated in FIG. 5.
- DataRedirFOQ a data redirect fail-over queue
- HeadDataRedirFOQ 50 and fields 52 A-F of a DataRedirect record 52 as illustrated in FIG. 5.
- a local PTA e.g., PTA 16 B
- PTA 16 A marks a portion of the memory 22 B allocated therein for usage by a remote PTA, e.g., PTA 16 A, as “suspended due to transport failure” by setting the access indicator for the corresponding remBufAllocID to “no access”.
- the PTA 16 B also marks the portion of the memory 22 A it allocated on the remote IOP 16 A as “suspended due to transport failure”.
- All queued transactions from the PTA 16 and new transactions to the remote IOP are, upon connectivity loss, placed in the appropriate data service's fail-over queue (FOQ), as described above.
- Each PTA 16 sends a ptaCancelxxx message to the failed transport(s) involved, e.g., PTA 16 A to transport 18 A, and PTA 16 B to transport 18 B, in order to clear all outstanding transactions.
- the respective PTAs 16 use the information contained within each of the aforedescribed FOQs to synchronize the remote memory allocation and resubmit each of the failed transactions, queued within the respective FOQ data structures.
- Each object placed in an FOQ is assigned a timestamp, which is placed within the aforementioned TimeOfFailure field 32 D/ 42 D/ 52 D of FIGS. 3, 4 and 5 , respectively.
- the PTA 16 uses the timestamp information to monitor and limit the time that a particular object waits for the IOP-IOP connection to be reestablished.
- a ptaMaxWaitReconnect or other such timeout parameter may be utilized by the PTA 16 to specify the maximum amount of time, e.g., in microseconds, that objects may wait in the FOQ.
- the PTA 16 e.g., of IOP 10 B, removes all of the objects destined for the remote IOP 10 A from the FOQ.
- the PTA 16 also returns all of the outstanding DDM 14 transactions with a status flag indicating the loss of peer service.
- the PTA 16 notifies the local DDM 14 that the connection with the remote IOP 10 has failed and is currently unrecoverable.
- the DDM 14 is then responsible for shutting down and freeing any allocated resources.
- the PTA 16 After receiving a connectivity status change event from a respective transport 18 , the PTA 16 determines the actual status change. For example, if the transport 18 status changed to “active”, the PTA 16 has the option of transferring all transactions from the fail-over transport which handled communications during the fail-over period to the original transport. This determination may be defined by a PTA restore parameter, e.g., ptaRestoreOriginalTransport. If, however, the transport 18 status changed to “failed”, the PTA 16 then attempts to find a new transport 18 that provides data link connectivity to the remote IOP 10 . In the preferred embodiment of the present invention, it is the responsibility of the IOP 10 that first established connectivity to reestablish the IOP-IOP connection following a transport failure.
- a PTA restore parameter e.g., ptaRestoreOriginalTransport
- the PTA 16 scans, in a prioritized order, its list of available media links 12 and associated transports 18 to determine which transport 18 provides connectivity to the specified remote IOP 10 . For example and with reference to FIG. 2, upon failure of media link 12 A, PTA 16 A scans the media available, media link 12 B, and the transports associated therewith, transports 18 A 2 and 18 B 2 in IOPs 10 A and 10 B, respectively. If, however, no transport 18 provides data link connectivity to the specified IOP 10 , the PTA 16 waits for the connection reestablishment period to timeout, ptaMaxWaitReconnect. Following timeout, the PTA 16 removes or purges all objects that cannot be delivered to the remote IOP 10 from the FOQ, and returns an unrecoverable transport error back to each failed object's originating DDM 14 , or more generally the DDSU.
- the PTA 16 substitutes the new transport for the failed transport, e.g., PTA 16 A switches from transport 18 A 1 to new transport 18 A 2 for the secondary media link 12 B.
- PTA 16 must issue a setup message to create a logical connection between the two transports by creating TID or other such identification aliases for each transport, as is understood in the art.
- the local PTA e.g., PTA 16 A
- the remote IOP 10 B issues a release message (across the newly formed connection 12 B) to the remote IOP 10 B in order to completely sever the prior connection between the failed transports, i.e., between transports 18 A 1 and 18 B 1 across media link 12 A.
- the PTA 16 specifies the source TID as the alias TID to the local failed transport and specify the second TID as the alias TID to the remote failed transport.
- the PTA 16 then resynchronizes any remote memory allocations with the remote IOP.
- the two PTAs 16 upon fail-over connection, must reclaim and synchronize their respective remote buffer allocation before the associated DDMs 14 use the transport data services. Reclaiming the prior remote buffer allocation, e.g., in the respective memories 22 A and 22 B or other storage within the IOPs 10 , ensures that the DDMs 14 will not access memory that has been freed or reassigned due to the loss of connectivity.
- the local PTA 16 A places all of the buffers it has allocated for the remote IOP 10 B into a suspended state and sets a flag, remBufSynchronized, to FALSE.
- the remBufSynchronized flag indicates that the remote buffers, e.g., in memory 22 B, are in an unknown state, and it is dangerous for the local PTA 16 A to access the remote memory.
- PTA 16 A has a similar flag defined for its own local buffers, localBufSynchronized, that is set to FALSE, also indicating a danger for the particular remote IOP 10 B to access the local buffers, e.g., in memory 22 A.
- the “danger” in accessing a remote buffer, prior to transaction reconstruction, is that the local DDM 14 does not know the current state or owner of the buffer. Accordingly, PTAs 16 preferably access the remote buffers only when both remBufSynchronized and localBufSynchronized are TRUE.
- the local PTA 16 A sends a message, ptaRemAllocSynch, to the remote PTA 16 B to update the state of the remote IOP's 10 B memory allocation (in memory 22 A of the local IOP 10 A).
- the local PTA 16 A includes the remote handle remBufAllocID for each buffer as well as the alias TID that previously owned the buffer.
- the remote IOP's 10 B reply message preferably contains a list of buffer handles and associated status information. If the buffer status information indicates that the TID maintains ownership of the buffer, the PTA 16 changes the status of the buffer from “suspended due to transport failure” to “active”.
- the PTA 16 must notify the DDM 14 that the particular remBufAllocID is invalid. The DDM 14 then frees the indicated object.
- the PTA 16 processes the transactions which were placed in the various Fail-Over Queues.
- the PTA 16 inspects each transaction's destination and fail-over timestamp. If the transaction has exceeded its allowable submission time, ptaMaxWaitReconnect, the transaction return status is set to “failed”. The transaction is then returned to the originating DDSU. If the transaction has not exceeded its allowable submission time, however, then the PTA 16 identifies if there is still connectivity to the target IOP 10 . If connectivity exists, the PTA 16 removes the transaction from the FOQ and sends it to the transport providing data delivery services to the target IOP 10 .
- the media may include the aforementioned ServerNet and Fibre Channel, as well as Ethernet, Personal Computer Interconnect (PCI) and related protocols providing a communication path between users.
- PCI Personal Computer Interconnect
- a reliable and better performing media should be selected as the primary media link 12 A and a less-optimal media chosen as the secondary link 12 B.
Abstract
Description
- 1. Field of the Invention
- The present invention relates generally to the handling of data transport failures and fail-over capability for data transfers within a computer system such as a server. More particularly, the present invention is directed to a system and method that establishes a secondary link for fail-over data transfer in the event of primary link failure. More particularly, also the system and method of the present invention are applicable for Input/Output Processors (IOPs) in an I2O (intelligent input/output) environment.
- 2. Description of Related Art
- Computer systems have achieved wide usage in modern society. During operation, a computer system processes and stores data at a speed and at a level of accuracy many times that which can be performed manually. Successive generations of computer systems have permitted ever-increasing amounts of data to be processed at ever-increasing rates.
- Computer systems are sometimes operated as standalone devices or connected together by way of network connections, typically together with a network server, to form a computer network. When networked together, files and other data stored or generated at one computer system can be readily transferred to another computer system.
- A conventional computer system typically includes one or more CPUs (central processing units) capable of executing algorithms forming applications, and a computer main memory. Peripheral devices, both those embedded on a backplane of the computer system, or constructed to be separate therefrom, also typically form portions of a conventional computer system. Computer peripheral devices include, for instance, video graphics adapters, LAN (local area network) interfaces, SCSI (small computer system interface) adapters, and mass storage devices, such as disk drive assemblies.
- A computer system further typically includes data buses which permit the communication of data between portions of the computer system. For instance, a host bus, a memory bus, at least one high-speed bus, a local peripheral expansion bus, and one or more additional peripheral buses form portions of a typical computer system.
- A peripheral bus is formed, for instance, of a SCSI bus, an EISA (extension to industry standard architecture) bus, an ISA (industry standard architecture) bus, or a PCI (peripheral component interface) bus. The peripheral bus forms a communication path to and from a peripheral device connected thereto. The computer system CPU, or a plurality of CPUs in a multi-processor system, communicates with a computer peripheral device by way of a computer bus, such as one or more of the computer buses noted above. A computer peripheral, depending upon its data transfer speed requirements, is connected to an appropriate computer bus, typically by way of a bus bridge that detects required actions, arbitrates, and translates both data and addresses between the various buses.
- A computer peripheral device forming a portion of a single computer system might well be supplied by a manufacturer other than the manufacturer of the computer CPU. If the computer system contains more than one peripheral device, the peripheral devices might also be supplied by different manufacturers. Furthermore, the computer system may be operable pursuant to any of several different operating systems. The various combinations of computer peripheral devices and computer operating systems of which a computer system might be formed quickly becomes quite large.
- Software drivers are typically required for each computer peripheral device to effectuate its operation. A software driver must be tailored to be operable together with the operating system pursuant to which the computer system is operable. A computer peripheral device must, therefore, have associated therewith a software driver to be operable together with any of the several operating systems pursuant to which the computer system might be operable. A multiplicity of software drivers might have to be created for a single computer peripheral to ensure that a computer peripheral device is operable together with any of the different operating systems.
- The complexity resulting from such a requirement has led to the development of an I2O (intelligent input/output) standard specification. The I2O standard specification sets forth, inter alia, standards for an I/O device driver architecture that is independent of both a specific peripheral device being controlled and the operating system of the computer system at which the device driver is to be installed.
- In the I2O standard specification, the portion of the driver that is responsible for managing the peripheral device is logically separated from the specific implementation details for the operating system which is to be installed. Because of this, the part of the driver that manages the peripheral device becomes portable across different computer and operating systems. The I2O standard specification also generalizes the nature of communication between the host computer system and peripheral hardware, thus providing processor and bus technology independence.
- Construction of computer systems compliant with the I2O standard specification facilitates formation of a computer system having component portions supplied by different suppliers while also assuring that the different component portions of the computer system shall be operable when connected together. Upgrading an existing computer system to be I2O aware assures that subsequent upgrading of the computer system shall be able to be effectuated simply.
- One difficulty inherent in all computer systems is the handling of a variety of system faults and their recovery, also referred to as fault tolerance. The identification, control and isolation of such faults is especially important in current devices which employ Error Checking Correcting (ECC) memory, Redundant Arrays of Inexpensive Drives (RAID) and hot-swappable disk drives, and even hot-swappable power supplies. Within servers, fault tolerance techniques begin with an initial focus on memory and physical storage subsystems, and now includes various fail-over solutions. Current servers implement such fail-over solutions for storage subsystems and LAN-LAN routing.
- It has been proposed that the I2O specification may be used to incorporate new levels of fail-over for I/O subsystems. One particular area of interest is the peer-to-peer and clustering capabilities of I2O. Peer-to-peer technology allows two I/O Processors (IOPs) to communicate with each other independently of the host CPUs and the media connecting the two IOPs. Clustering extends the peer-to-peer concept outside of the physical system (or unit) defined by the I2O specification.
- Problems arise, however, when a failure occurs across the media connecting two such IOPs, such as disconnection of a communications cable (minor) or a bus lock-up (severe). In non-I2O systems, for example, each driver must have direct knowledge of every underlying transport and media, which since there are a myriad of transport and media types available, implies a lot of complex coding for each driver to handle various contingencies. In the current I2O specification, for example, a fault, upon detection by a transport device, is reported to each device driver or application software, collectively referred to hereinafter as downloadable driver modules or DDMs, using a particular data service pathway. The respective DDMs then automatically close the connection with the remote IOP and lose all of the resources previously allocated by that DDM on that remote IOP. Furthermore, the DDMs, upon transport failure, must tear down their respective operating environments and completely rebuild them. Even if a redundant link is found, the entire buffer allocation and DDM-to-DDM setup must begin anew.
- There is, therefore, a need for a computer system and method which minimizes the error handling needs of a device driver or application software, particularly in the event of a primary transport failure.
- The present invention is directed to a system and method for maintaining communications within a computer system after a data transport failure across a first link. Fail-over capability is attained by re-establishing communications across a secondary link using different transport mechanisms. For example, between two Input/Output Processors (IOPs) within a computer system, such as a server, a series of data transactions therebetween are queued until transaction completion. Upon detection of a failure condition between the IOPs across the first link, the IOPs engage fail-over mechanisms therein to preserve uncompleted data transactions until communications are re-established across the secondary link.
- A more complete appreciation of the present invention and the scope thereof can be obtained from the accompanying drawings which are briefly summarized below, the following detailed description of the presently-preferred embodiments of the invention, and the appended claims.
- FIG. 1 depicts a portion of the system architecture for a conventional computer system, illustrating inter-processor communications across a primary media link;
- FIG. 2 illustrates the improved system architecture of the present invention, which incorporates a secondary media link in addition to the primary media link shown in FIG. 1; FIG. 3 illustrates a data send fail-over queue that may be used in the present invention;
- FIG. 4 illustrates a data move fail-over queue that may be used in the present invention; and
- FIG. 5 illustrates a data redirect fail-over queue that may be used in the present invention.
- The present invention will now be described more fully hereinafter with reference to the accompanying drawings, in which preferred embodiments of the invention are shown. This invention may, however, be embodied in many different forms and should not be construed as limited to the embodiments set forth herein; rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the invention to those skilled in the art.
- Although the principles set forth in the present invention are applicable to a variety of computer architectures, for simplicity only one such architecture, I2O, will be described in detail herein. It should therefore be understood to those skilled in the art that although the preferred embodiment of the present invention is an extension on the standardized I2O architecture, the present invention is also applicable in non-I2O architectures.
- Shown in FIG. 1 is a general illustration of some of the features of the aforementioned I2O architecture, which abstracts the underlying transport mechanisms through the creation of a class of Application Program Interfaces (APIs), defining a set of common services for all transports. In particular, inter-processor communications are depicted in which a
first IOP 10A is in communication with asecond IOP 10B across amedia link 12 therebetween. As further shown in FIG. 1,IOP 10A includes therein a first DDM (or I2O Real Time Operating System) 14A, a first Peer Transport Agent (PTA) 16A in communication with theDDM 14A, and a first multiplicity of transports, generally designated in FIG. 1 by thereference numeral 18. Similarly,IOP 10B contains therein asecond DDM 14B, asecond PTA 16B and a second multiplicity oftransports 18. As illustrated,IOP 10A communicates, via a first of said transports 18A, withIOP 10B via another of said transports 18B therein across media link 12. - It should be understood in the art that the
aforementioned transports 18 are hardware devices and/or software applications operating at the transport layer, according to the International Standards Organization Operating Systems Interconnection model (ISO OSI). In particular, eachtransport 18 represents a specific protocol for transforming data across a given media. It should further be understood that multiple transports may exist for a single media, for example, in currently available network adaptors such as Transmission Control Protocol/Internet Protocol (TCP/IP), NetBIOS Extended User Interface (NetBEUI), ServerNet, Fibre Channel or a number of other communication networks. - It should be understood that in hot-pluggable environments, all communication paths between IOPs, such as
IOPs DDMs - As an extension to the aforementioned standard I2O architecture depicted in FIG. 1, fail-over mechanisms can be implemented to isolate the respective DDM 14 from any underlying media/transport faults by implementing the transport fail-over principles of the present invention. With reference now to FIG. 2 of the Drawings, the Peer Transport Agents 16, described in connection with FIG. 1, of the present invention preferably incorporate Fail-Over Management mechanisms, generally designated by the reference numeral 20, therein. Also shown in FIG. 2 are two
media links IOPs transports IOPs respective memories - In accordance with the strategy of the present invention, however, inter-DDM communication and resources are maintained after primary media link12A failure by the use of the redundant, backup media link 12B, secondarily connecting the
IOPs transports DDMs respective PTAs - When a DDM, e.g.,
DDM 14A inIOP 10A, issues a data service request, the request goes through the associatedPTA 16A, which is responsible for tracking each DDM's 14 message, data delivery requests and associated status information. ThePTA 16A preferably uses a portion of the IOP's 10A memory, e.g.,memory 22A described hereinbefore in connection withDDM 14A, to store data regarding outstanding DDM requests and remote memory allocations. - When allocating remote memory, the PTA16 forwards the aforementioned data service request through the
pertinent transports 18, viamedia 12, to the indicated remote IOP. Preferably, the reply message contains a conventional scatter gather list (SGL) describing the remote buffers involved, e.g., forPTA 16A accessing the remote data inmemory 22B. For each such remote memory allocation request, the PTA 16 stores a copy of the returned remote buffer identifier, e.g., remBufAllocID, and correlates the identifier with an access status indicator, along with the state (TID) information of theDDM 12 requesting the allocation. Boolean or other flag values may be employed for each DDM 14 to indicate normal access to memory 22, prohibited memory access due to transport failure, etc. - The data send requests from the DDMs14 are preferably tracked by a data send service and the respective PTA 16 holds a list of all outstanding data send transactions, each identified by a DataSendID identifier. Upon successful completion of a given transaction, a data send completion handler removes that transaction from the outstanding list and passes completion status to the originating Data Delivery Service User (DDSU), i.e., the aforedescribed DDM 14.
- If the data send operation fails, e.g., due to disconnection or other primary link failure, the transaction is then posted to the data send service's fail-over queue, e.g., DataSendFOQ. In particular, if the
pertinent transport 18 signals a loss of connectivity, all pending and new transactions to the particular remote IOP are posted to the aforementioned DataSendFOQ, which is used by the PTA 16 during link re-establishment. A preferred data structure for the DataSendFOQ is illustrated in FIG. 3 in which a head pointer,HeadDataSendFOQ 30, points to a first field of aDataSend record 32,DataSendID 32A, which is the particular identifier or object handler for the data object/transaction.DataSend record 32 also includes anOwnerID field 32B which indicates the identifier (TID) of the initiating DDM 14, aPeerTransportTID field 32C which indicates theparticular transport 18 used for data send service, a TimeOfFailure field 32D which includes a timestamp for the failure, aReestablishmentCount field 32E which indicates the number of retries attempted, and aNextPtr field 32F which points to the start of another,next DataSend record 32 or contains a NULL to indicate the end of the linked list. - Data movement in the preferred embodiment of the present invention is a virtualized, Direct Memory Access (DMA) service where the data is moved between explicitly defined source and destination buffers. A data move service within the PTA16 tracks all DDM 14 requests by maintaining a data structure for all outstanding transactions. As with the aforementioned data send service, when data move transactions successfully complete, they too are removed from the outstanding list and completion status is returned to the initiating DDSU, e.g., a DDM 14 or an I2O Real Time Operating System (IRTOS).
- If the data move operation fails, the transaction is then posted to the data move service's fail-over queue, e.g., DataMoveFOQ. If the
pertinent peer transport 18 signals a loss of connectivity, all pending and new transactions to the pertinent remote IOP are posted to the DataSendFOQ, which is used by the PTA 16 during the link re-establishment process. The structure for the DataMoveFOQ is shown in FIG. 4, which is similar to the DataSendFOQ structure shown in FIG. 3. AHeadDataMoveFOQ pointer 40 points to aDataMoveID field 42A of theDataMove record 42.Fields 42B-F correspond to thefields 32B-F described in connection with FIG. 3. - A similar record data structure may be utilized to implement other functions, e.g., a data redirect fail-over queue, DataRedirFOQ, which employs a
HeadDataRedirFOQ 50 andfields 52A-F of aDataRedirect record 52, as illustrated in FIG. 5. - With reference again to FIG. 2, if data link connectivity is lost across the primary (active) transport mechanism, e.g., between
transports - Upon loss of connectivity, a local PTA, e.g.,
PTA 16B, marks a portion of thememory 22B allocated therein for usage by a remote PTA, e.g.,PTA 16A, as “suspended due to transport failure” by setting the access indicator for the corresponding remBufAllocID to “no access”. Similarly, thePTA 16B also marks the portion of thememory 22A it allocated on theremote IOP 16A as “suspended due to transport failure”. - All queued transactions from the PTA16 and new transactions to the remote IOP are, upon connectivity loss, placed in the appropriate data service's fail-over queue (FOQ), as described above. Each PTA 16 sends a ptaCancelxxx message to the failed transport(s) involved, e.g.,
PTA 16A to transport 18A, andPTA 16B to transport 18B, in order to clear all outstanding transactions. Once the connection with the remote IOP is reestablished, e.g., using the redundant, secondary media link 12B, the respective PTAs 16 use the information contained within each of the aforedescribed FOQs to synchronize the remote memory allocation and resubmit each of the failed transactions, queued within the respective FOQ data structures. - Each object placed in an FOQ is assigned a timestamp, which is placed within the aforementioned TimeOfFailure field32D/42D/52D of FIGS. 3, 4 and 5, respectively. The PTA 16 uses the timestamp information to monitor and limit the time that a particular object waits for the IOP-IOP connection to be reestablished. A ptaMaxWaitReconnect or other such timeout parameter may be utilized by the PTA 16 to specify the maximum amount of time, e.g., in microseconds, that objects may wait in the FOQ.
- If the connection is not reestablished within ptaMaxwaitReconnect microseconds, the PTA16, e.g., of
IOP 10B, removes all of the objects destined for theremote IOP 10A from the FOQ. The PTA 16 also returns all of the outstanding DDM 14 transactions with a status flag indicating the loss of peer service. The PTA 16 notifies the local DDM 14 that the connection with the remote IOP 10 has failed and is currently unrecoverable. The DDM 14 is then responsible for shutting down and freeing any allocated resources. - After receiving a connectivity status change event from a
respective transport 18, the PTA 16 determines the actual status change. For example, if thetransport 18 status changed to “active”, the PTA 16 has the option of transferring all transactions from the fail-over transport which handled communications during the fail-over period to the original transport. This determination may be defined by a PTA restore parameter, e.g., ptaRestoreOriginalTransport. If, however, thetransport 18 status changed to “failed”, the PTA 16 then attempts to find anew transport 18 that provides data link connectivity to the remote IOP 10. In the preferred embodiment of the present invention, it is the responsibility of the IOP 10 that first established connectivity to reestablish the IOP-IOP connection following a transport failure. - After connectivity failure, the PTA16 scans, in a prioritized order, its list of
available media links 12 and associatedtransports 18 to determine whichtransport 18 provides connectivity to the specified remote IOP 10. For example and with reference to FIG. 2, upon failure of media link 12A,PTA 16A scans the media available, media link 12B, and the transports associated therewith, transports 18A2 and 18B2 inIOPs transport 18 provides data link connectivity to the specified IOP 10, the PTA 16 waits for the connection reestablishment period to timeout, ptaMaxWaitReconnect. Following timeout, the PTA 16 removes or purges all objects that cannot be delivered to the remote IOP 10 from the FOQ, and returns an unrecoverable transport error back to each failed object's originating DDM 14, or more generally the DDSU. - If there is a
transport 18 that provides the requisite secondary data link connectivity to the specified IOP 10, the PTA 16 substitutes the new transport for the failed transport, e.g.,PTA 16A switches fromtransport 18A1 tonew transport 18A2 for the secondary media link 12B. However, before messaging can pass between two transports, e.g., 18A2 and 18B2, PTA 16 must issue a setup message to create a logical connection between the two transports by creating TID or other such identification aliases for each transport, as is understood in the art. - After establishment of the fail-over connection, the local PTA, e.g.,
PTA 16A, issues a release message (across the newly formedconnection 12B) to theremote IOP 10B in order to completely sever the prior connection between the failed transports, i.e., betweentransports media link 12A. The PTA 16 then specifies the source TID as the alias TID to the local failed transport and specify the second TID as the alias TID to the remote failed transport. The PTA 16 then resynchronizes any remote memory allocations with the remote IOP. - It should be understood that the two PTAs16, upon fail-over connection, must reclaim and synchronize their respective remote buffer allocation before the associated DDMs 14 use the transport data services. Reclaiming the prior remote buffer allocation, e.g., in the
respective memories - With regard to synchronization after the primary connection has been lost, the
local PTA 16A, for example, places all of the buffers it has allocated for theremote IOP 10B into a suspended state and sets a flag, remBufSynchronized, to FALSE. The remBufSynchronized flag indicates that the remote buffers, e.g., inmemory 22B, are in an unknown state, and it is dangerous for thelocal PTA 16A to access the remote memory.PTA 16A has a similar flag defined for its own local buffers, localBufSynchronized, that is set to FALSE, also indicating a danger for the particularremote IOP 10B to access the local buffers, e.g., inmemory 22A. The “danger” in accessing a remote buffer, prior to transaction reconstruction, is that the local DDM 14 does not know the current state or owner of the buffer. Accordingly, PTAs 16 preferably access the remote buffers only when both remBufSynchronized and localBufSynchronized are TRUE. - The
local PTA 16A sends a message, ptaRemAllocSynch, to theremote PTA 16B to update the state of the remote IOP's 10B memory allocation (inmemory 22A of thelocal IOP 10A). Within the message, thelocal PTA 16A includes the remote handle remBufAllocID for each buffer as well as the alias TID that previously owned the buffer. The remote IOP's 10B reply message preferably contains a list of buffer handles and associated status information. If the buffer status information indicates that the TID maintains ownership of the buffer, the PTA 16 changes the status of the buffer from “suspended due to transport failure” to “active”. If, however, the buffer status information indicates that the local TID does not have access to the previously allocated buffer, e.g., the buffer having been freed due to a timeout or unexpected latency in reforming the IOP-IOP connection, the PTA 16 must notify the DDM 14 that the particular remBufAllocID is invalid. The DDM 14 then frees the indicated object. - After the local and remote buffer allocations have been resynchronized, the PTA16 processes the transactions which were placed in the various Fail-Over Queues. The PTA 16 inspects each transaction's destination and fail-over timestamp. If the transaction has exceeded its allowable submission time, ptaMaxWaitReconnect, the transaction return status is set to “failed”. The transaction is then returned to the originating DDSU. If the transaction has not exceeded its allowable submission time, however, then the PTA 16 identifies if there is still connectivity to the target IOP 10. If connectivity exists, the PTA 16 removes the transaction from the FOQ and sends it to the transport providing data delivery services to the target IOP 10.
- If a connection does not exist with the target IOP10, the transaction is placed back in the FOQ because the PTA 16 may still be trying to establish connectivity to the IOP 10. Eventually, connectivity will be gained and the transaction will be forwarded to the appropriate remote IOP, or the transaction will timeout and return with a failure status.
- It should be understood that a variety of media may be used as the primary and
secondary media links secondary link 12B. - As set forth hereinabove, in preferred embodiments of the present invention transport fail-over mechanisms are applied in inter-IOP communications within Input/Output-intensive environments such as servers, particularly in an I2O system. It should nonetheless be understood that the principles of the present invention may find applicability in non-server, non-I2O systems as well. Accordingly, the scope of the present invention should not necessarily be limited by this description, but should instead be defined by the following claims.
Claims (28)
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US09/840,671 US6389555B2 (en) | 1998-05-11 | 2001-04-23 | System and method for fail-over data transport |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US09/075,623 US6260158B1 (en) | 1998-05-11 | 1998-05-11 | System and method for fail-over data transport |
US09/840,671 US6389555B2 (en) | 1998-05-11 | 2001-04-23 | System and method for fail-over data transport |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US09/075,623 Continuation US6260158B1 (en) | 1998-05-11 | 1998-05-11 | System and method for fail-over data transport |
Publications (2)
Publication Number | Publication Date |
---|---|
US20010014954A1 true US20010014954A1 (en) | 2001-08-16 |
US6389555B2 US6389555B2 (en) | 2002-05-14 |
Family
ID=22126975
Family Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US09/075,623 Expired - Lifetime US6260158B1 (en) | 1998-05-11 | 1998-05-11 | System and method for fail-over data transport |
US09/840,671 Expired - Lifetime US6389555B2 (en) | 1998-05-11 | 2001-04-23 | System and method for fail-over data transport |
Family Applications Before (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US09/075,623 Expired - Lifetime US6260158B1 (en) | 1998-05-11 | 1998-05-11 | System and method for fail-over data transport |
Country Status (1)
Country | Link |
---|---|
US (2) | US6260158B1 (en) |
Cited By (31)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20020091844A1 (en) * | 1997-10-14 | 2002-07-11 | Alacritech, Inc. | Network interface device that fast-path processes solicited session layer read commands |
US20020095519A1 (en) * | 1997-10-14 | 2002-07-18 | Alacritech, Inc. | TCP/IP offload device with fast-path TCP ACK generating and transmitting mechanism |
US20020156927A1 (en) * | 2000-12-26 | 2002-10-24 | Alacritech, Inc. | TCP/IP offload network interface device |
US20020161919A1 (en) * | 1997-10-14 | 2002-10-31 | Boucher Laurence B. | Fast-path processing for receiving data on TCP connection offload devices |
US20030121835A1 (en) * | 2001-12-31 | 2003-07-03 | Peter Quartararo | Apparatus for and method of sieving biocompatible adsorbent beaded polymers |
US20030129405A1 (en) * | 2000-10-26 | 2003-07-10 | Yide Zhang | Insulator coated magnetic nanoparticulate composites with reduced core loss and method of manufacture thereof |
US20040003126A1 (en) * | 1998-08-27 | 2004-01-01 | Alacritech, Inc. | TCP/IP offload network interface device |
US20040073703A1 (en) * | 1997-10-14 | 2004-04-15 | Alacritech, Inc. | Fast-path apparatus for receiving data corresponding a TCP connection |
US20040117509A1 (en) * | 1997-10-14 | 2004-06-17 | Alacritech, Inc. | Protocol processing stack for use with intelligent network interface device |
US20090217284A1 (en) * | 2008-02-25 | 2009-08-27 | International Business Machines Corporation | Passing initiative in a multitasking multiprocessor environment |
US20090217007A1 (en) * | 2008-02-25 | 2009-08-27 | International Business Machines Corporation | Discovery of a virtual topology in a multi-tasking multi-processor environment |
US20090216853A1 (en) * | 2008-02-25 | 2009-08-27 | International Business Machines Corporation | Subnet management discovery of point-to-point network topologies |
US20090217291A1 (en) * | 2008-02-25 | 2009-08-27 | International Business Machines Corporation | Performance neutral heartbeat for a multi-tasking multi-processor environment |
US20090213753A1 (en) * | 2008-02-25 | 2009-08-27 | International Business Machines Corporation | Subnet management in virtual host channel adapter topologies |
US20090216518A1 (en) * | 2008-02-25 | 2009-08-27 | International Business Machines Corporation | Emulated multi-tasking multi-processor channels implementing standard network protocols |
US7664883B2 (en) | 1998-08-28 | 2010-02-16 | Alacritech, Inc. | Network interface device that fast-path processes solicited session layer read commands |
US7738500B1 (en) | 2005-12-14 | 2010-06-15 | Alacritech, Inc. | TCP timestamp synchronization for network connections that are offloaded to network interface devices |
US7945699B2 (en) | 1997-10-14 | 2011-05-17 | Alacritech, Inc. | Obtaining a destination address so that a network interface device can write network data without headers directly into host memory |
US8019901B2 (en) | 2000-09-29 | 2011-09-13 | Alacritech, Inc. | Intelligent network storage interface system |
US8248939B1 (en) | 2004-10-08 | 2012-08-21 | Alacritech, Inc. | Transferring control of TCP connections between hierarchy of processing mechanisms |
US8341286B1 (en) | 2008-07-31 | 2012-12-25 | Alacritech, Inc. | TCP offload send optimization |
US8365008B2 (en) | 2010-10-13 | 2013-01-29 | International Business Machines Corporation | Providing unsolicited global disconnect requests to users of storage |
US8539513B1 (en) | 2008-04-01 | 2013-09-17 | Alacritech, Inc. | Accelerating data transfer in a virtual computer system with tightly coupled TCP connections |
US8539112B2 (en) | 1997-10-14 | 2013-09-17 | Alacritech, Inc. | TCP/IP offload device |
US8621101B1 (en) | 2000-09-29 | 2013-12-31 | Alacritech, Inc. | Intelligent network storage interface device |
US8782199B2 (en) | 1997-10-14 | 2014-07-15 | A-Tech Llc | Parsing a packet header |
US9055104B2 (en) | 2002-04-22 | 2015-06-09 | Alacritech, Inc. | Freeing transmit memory on a network interface device prior to receiving an acknowledgment that transmit data has been received by a remote device |
WO2016001772A1 (en) * | 2014-07-02 | 2016-01-07 | International Business Machines Corporation | Synchronizing operations between regions when a network connection fails |
US9306793B1 (en) | 2008-10-22 | 2016-04-05 | Alacritech, Inc. | TCP offload device that batches session layer headers to reduce interrupts as well as CPU copies |
US20220067819A1 (en) * | 2020-09-03 | 2022-03-03 | Mastercard International Incorporated | Methods and systems for recovering a failed payment processing request |
US20220138059A1 (en) * | 2020-11-05 | 2022-05-05 | Samsung Electronics Co., Ltd. | Storage system and operating method thereof |
Families Citing this family (40)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7342581B2 (en) | 1996-07-18 | 2008-03-11 | Computer Associates Think, Inc. | Method and apparatus for displaying 3-D state indicators |
US7003587B1 (en) * | 1996-07-18 | 2006-02-21 | Computer Associates Think, Inc. | Method and apparatus for maintaining data integrity across distributed computer systems |
US5958012A (en) * | 1996-07-18 | 1999-09-28 | Computer Associates International, Inc. | Network management system using virtual reality techniques to display and simulate navigation to network components |
US7680879B2 (en) * | 1996-07-18 | 2010-03-16 | Computer Associates Think, Inc. | Method and apparatus for maintaining data integrity across distributed computer systems |
US20030023721A1 (en) * | 1997-07-15 | 2003-01-30 | Computer Associates Think, Inc. | Method and apparatus for generating context-descriptive messages |
US20030018771A1 (en) * | 1997-07-15 | 2003-01-23 | Computer Associates Think, Inc. | Method and apparatus for generating and recognizing speech as a user interface element in systems and network management |
US7315893B2 (en) * | 1997-07-15 | 2008-01-01 | Computer Associates Think, Inc. | Method and apparatus for filtering messages based on context |
US6260158B1 (en) * | 1998-05-11 | 2001-07-10 | Compaq Computer Corporation | System and method for fail-over data transport |
US6580693B1 (en) * | 1999-05-24 | 2003-06-17 | 3Com Corporation | Methods and apparatus for detecting leaks in ATM networks |
US7023800B1 (en) * | 1999-06-01 | 2006-04-04 | Microsoft Corporation | Congestion avoidance within aggregate channels |
US6490664B1 (en) * | 1999-06-14 | 2002-12-03 | International Business Machines Corporation | Method and system for handling destage requests during shut-down in a log-structured array |
US6738826B1 (en) | 2000-02-24 | 2004-05-18 | Cisco Technology, Inc. | Router software upgrade employing redundant processors |
US6775230B1 (en) * | 2000-07-18 | 2004-08-10 | Hitachi, Ltd. | Apparatus and method for transmitting frames via a switch in a storage area network |
US20020147809A1 (en) * | 2000-10-17 | 2002-10-10 | Anders Vinberg | Method and apparatus for selectively displaying layered network diagrams |
US7370078B1 (en) | 2001-05-22 | 2008-05-06 | Cisco Technology, Inc. | Determining a remote device name |
JP3695375B2 (en) * | 2001-09-26 | 2005-09-14 | 日本電気株式会社 | Alarm transfer method and method |
US6880041B2 (en) * | 2002-02-20 | 2005-04-12 | International Business Machines Corporation | Method and apparatus to transfer information between different categories of servers and one or more data storage media |
US7165258B1 (en) * | 2002-04-22 | 2007-01-16 | Cisco Technology, Inc. | SCSI-based storage area network having a SCSI router that routes traffic between SCSI and IP networks |
US7743143B2 (en) * | 2002-05-03 | 2010-06-22 | Oracle America, Inc. | Diagnosability enhancements for multi-level secure operating environments |
US7219149B2 (en) * | 2003-06-12 | 2007-05-15 | Dw Holdings, Inc. | Versatile terminal adapter and network for transaction processing |
US6922754B2 (en) * | 2002-12-09 | 2005-07-26 | Infabric Technologies, Inc. | Data-aware data flow manager |
US20040162928A1 (en) * | 2003-02-18 | 2004-08-19 | Hewlett-Packard Development Company, L.P. | High speed multiple ported bus interface reset control system |
US7287083B1 (en) * | 2003-03-20 | 2007-10-23 | Novell, Inc. | Computing environment failover in a branch office environment |
US7526527B1 (en) * | 2003-03-31 | 2009-04-28 | Cisco Technology, Inc. | Storage area network interconnect server |
US7194655B2 (en) * | 2003-06-12 | 2007-03-20 | International Business Machines Corporation | Method and system for autonomously rebuilding a failed server and a computer system utilizing the same |
JP4080970B2 (en) * | 2003-07-30 | 2008-04-23 | 株式会社日立製作所 | Switch that provides path switching |
US7210058B2 (en) * | 2003-09-29 | 2007-04-24 | International Business Machines Corporation | Method for peer-to-peer system recovery |
US7769021B1 (en) * | 2004-07-03 | 2010-08-03 | At&T Corp. | Multiple media fail-over to alternate media |
FR2873464B1 (en) * | 2004-07-23 | 2006-09-29 | Thales Sa | ARCHITECTURE OF HIGH AVAILABILITY, HIGH PERFORMANCE COMPONENT SOFTWARE COMPONENTS |
WO2006091247A2 (en) * | 2004-11-12 | 2006-08-31 | Taser International, Inc. | Systems and methods for electronic weaponry having audio and/or video recording capability |
JP2006195821A (en) * | 2005-01-14 | 2006-07-27 | Fujitsu Ltd | Method for controlling information processing system, information processing system, direct memory access controller, and program |
ITMI20050243A1 (en) * | 2005-02-18 | 2006-08-19 | Alcatel Italia | PROPAGATION AND DETECTION OF FAILURES IN A NETWORK FOR TELECOMMUNICATIONS |
US8122174B2 (en) * | 2006-03-31 | 2012-02-21 | Research In Motion Limited | System and method for provisioning a remote resource for an electronic device |
JP4998316B2 (en) * | 2008-02-20 | 2012-08-15 | 富士通株式会社 | Communication system, communication processing method, and node |
KR101175689B1 (en) * | 2008-02-27 | 2012-08-23 | 노키아 코포레이션 | Buffer control for multi-transport architectures |
US8179785B1 (en) * | 2010-02-17 | 2012-05-15 | Tellabs Operations, Inc. | Deterministic switching protection over aggregated links |
US8510552B2 (en) | 2010-04-07 | 2013-08-13 | Apple Inc. | System and method for file-level data protection |
US8788842B2 (en) | 2010-04-07 | 2014-07-22 | Apple Inc. | System and method for content protection based on a combination of a user PIN and a device specific identifier |
US8433901B2 (en) * | 2010-04-07 | 2013-04-30 | Apple Inc. | System and method for wiping encrypted data on a device having file-level content protection |
JP2018116477A (en) * | 2017-01-18 | 2018-07-26 | 富士通株式会社 | Information processing apparatus and information processing system |
Family Cites Families (18)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5072368A (en) * | 1985-10-31 | 1991-12-10 | International Business Machines Corporation | Immediate duplication of I/O requests on a record by record basis by a computer operating system |
US4914653A (en) * | 1986-12-22 | 1990-04-03 | American Telephone And Telegraph Company | Inter-processor communication protocol |
US5065311A (en) * | 1987-04-20 | 1991-11-12 | Hitachi, Ltd. | Distributed data base system of composite subsystem type, and method fault recovery for the system |
US5359594A (en) * | 1992-05-15 | 1994-10-25 | International Business Machines Corporation | Power-saving full duplex nodal communications systems |
DE69433109D1 (en) * | 1994-04-28 | 2003-10-09 | Hewlett Packard Co | Multicast device |
US5475813A (en) * | 1994-07-18 | 1995-12-12 | International Business Machines Corporation | Routing transactions in the presence of failing servers |
DE19509558A1 (en) * | 1995-03-16 | 1996-09-19 | Abb Patent Gmbh | Process for fault-tolerant communication under high real-time conditions |
IT1285179B1 (en) * | 1995-04-24 | 1998-06-03 | Motorola Inc | PROCEDURE AND APPARATUS FOR THE CONTROL OF SENSITIVE ADDRESSING FOR COMMUNICATIONS SYSTEMS. |
US5838915A (en) * | 1995-06-21 | 1998-11-17 | Cisco Technology, Inc. | System for buffering data in the network having a linked list for each of said plurality of queues |
US5996019A (en) * | 1995-07-19 | 1999-11-30 | Fujitsu Network Communications, Inc. | Network link access scheduling using a plurality of prioritized lists containing queue identifiers |
US5699511A (en) * | 1995-10-10 | 1997-12-16 | International Business Machines Corporation | System and method for dynamically varying low level file system operation timeout parameters in network systems of variable bandwidth |
US5835493A (en) * | 1996-01-02 | 1998-11-10 | Divicom, Inc. | MPEG transport stream remultiplexer |
US5838994A (en) * | 1996-01-11 | 1998-11-17 | Cisco Technology, Inc. | Method and apparatus for the dynamic allocation of buffers in a digital communications network |
US5796718A (en) * | 1996-09-30 | 1998-08-18 | Mci Communications Corporation | Method of and system for intelligent access line protect switching |
US6011780A (en) * | 1997-05-23 | 2000-01-04 | Stevens Institute Of Technology | Transparant non-disruptable ATM network |
US6192483B1 (en) * | 1997-10-21 | 2001-02-20 | Sun Microsystems, Inc. | Data integrity and availability in a distributed computer system |
US6260158B1 (en) * | 1998-05-11 | 2001-07-10 | Compaq Computer Corporation | System and method for fail-over data transport |
US6247142B1 (en) * | 1998-08-21 | 2001-06-12 | Aspect Communications | Apparatus and method for providing redundancy in a transaction processing system |
-
1998
- 1998-05-11 US US09/075,623 patent/US6260158B1/en not_active Expired - Lifetime
-
2001
- 2001-04-23 US US09/840,671 patent/US6389555B2/en not_active Expired - Lifetime
Cited By (64)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20050071490A1 (en) * | 1987-01-12 | 2005-03-31 | Craft Peter K. | Method to synchronize and upload an offloaded network stack connection with a network stack |
US20020091844A1 (en) * | 1997-10-14 | 2002-07-11 | Alacritech, Inc. | Network interface device that fast-path processes solicited session layer read commands |
US7945699B2 (en) | 1997-10-14 | 2011-05-17 | Alacritech, Inc. | Obtaining a destination address so that a network interface device can write network data without headers directly into host memory |
US8782199B2 (en) | 1997-10-14 | 2014-07-15 | A-Tech Llc | Parsing a packet header |
US8131880B2 (en) | 1997-10-14 | 2012-03-06 | Alacritech, Inc. | Intelligent network interface device and system for accelerated communication |
US7853723B2 (en) | 1997-10-14 | 2010-12-14 | Alacritech, Inc. | TCP/IP offload network interface device |
US7844743B2 (en) | 1997-10-14 | 2010-11-30 | Alacritech, Inc. | Protocol stack that offloads a TCP connection from a host computer to a network interface device |
US20040073703A1 (en) * | 1997-10-14 | 2004-04-15 | Alacritech, Inc. | Fast-path apparatus for receiving data corresponding a TCP connection |
US20040117509A1 (en) * | 1997-10-14 | 2004-06-17 | Alacritech, Inc. | Protocol processing stack for use with intelligent network interface device |
US20020095519A1 (en) * | 1997-10-14 | 2002-07-18 | Alacritech, Inc. | TCP/IP offload device with fast-path TCP ACK generating and transmitting mechanism |
US20060075130A1 (en) * | 1997-10-14 | 2006-04-06 | Craft Peter K | Protocol stack that offloads a TCP connection from a host computer to a network interface device |
US7809847B2 (en) | 1997-10-14 | 2010-10-05 | Alacritech, Inc. | Network interface device that can transfer control of a TCP connection to a host CPU |
US9009223B2 (en) | 1997-10-14 | 2015-04-14 | Alacritech, Inc. | Method and apparatus for processing received network packets on a network interface for a computer |
US8856379B2 (en) | 1997-10-14 | 2014-10-07 | A-Tech Llc | Intelligent network interface system and method for protocol processing |
US8805948B2 (en) | 1997-10-14 | 2014-08-12 | A-Tech Llc | Intelligent network interface system and method for protocol processing |
US20020161919A1 (en) * | 1997-10-14 | 2002-10-31 | Boucher Laurence B. | Fast-path processing for receiving data on TCP connection offload devices |
US8631140B2 (en) | 1997-10-14 | 2014-01-14 | Alacritech, Inc. | Intelligent network interface system and method for accelerated protocol processing |
US7694024B2 (en) | 1997-10-14 | 2010-04-06 | Alacritech, Inc. | TCP/IP offload device with fast-path TCP ACK generating and transmitting mechanism |
US7673072B2 (en) | 1997-10-14 | 2010-03-02 | Alacritech, Inc. | Fast-path apparatus for transmitting data corresponding to a TCP connection |
US8539112B2 (en) | 1997-10-14 | 2013-09-17 | Alacritech, Inc. | TCP/IP offload device |
US8447803B2 (en) | 1997-10-14 | 2013-05-21 | Alacritech, Inc. | Method and apparatus for distributing network traffic processing on a multiprocessor computer |
US7664868B2 (en) | 1998-04-27 | 2010-02-16 | Alacritech, Inc. | TCP/IP offload network interface device |
US20040003126A1 (en) * | 1998-08-27 | 2004-01-01 | Alacritech, Inc. | TCP/IP offload network interface device |
US7664883B2 (en) | 1998-08-28 | 2010-02-16 | Alacritech, Inc. | Network interface device that fast-path processes solicited session layer read commands |
US8621101B1 (en) | 2000-09-29 | 2013-12-31 | Alacritech, Inc. | Intelligent network storage interface device |
US8019901B2 (en) | 2000-09-29 | 2011-09-13 | Alacritech, Inc. | Intelligent network storage interface system |
US20030129405A1 (en) * | 2000-10-26 | 2003-07-10 | Yide Zhang | Insulator coated magnetic nanoparticulate composites with reduced core loss and method of manufacture thereof |
US20020156927A1 (en) * | 2000-12-26 | 2002-10-24 | Alacritech, Inc. | TCP/IP offload network interface device |
US20030121835A1 (en) * | 2001-12-31 | 2003-07-03 | Peter Quartararo | Apparatus for and method of sieving biocompatible adsorbent beaded polymers |
US9055104B2 (en) | 2002-04-22 | 2015-06-09 | Alacritech, Inc. | Freeing transmit memory on a network interface device prior to receiving an acknowledgment that transmit data has been received by a remote device |
US8248939B1 (en) | 2004-10-08 | 2012-08-21 | Alacritech, Inc. | Transferring control of TCP connections between hierarchy of processing mechanisms |
US7738500B1 (en) | 2005-12-14 | 2010-06-15 | Alacritech, Inc. | TCP timestamp synchronization for network connections that are offloaded to network interface devices |
US20090217238A1 (en) * | 2008-02-25 | 2009-08-27 | International Business Machines Corporation | Incorporating state machine controls into existing non-state machine environments |
US8432793B2 (en) * | 2008-02-25 | 2013-04-30 | International Business Machines Corporation | Managing recovery of a link via loss of link |
US8009589B2 (en) | 2008-02-25 | 2011-08-30 | International Business Machines Corporation | Subnet management in virtual host channel adapter topologies |
US7949721B2 (en) | 2008-02-25 | 2011-05-24 | International Business Machines Corporation | Subnet management discovery of point-to-point network topologies |
US8065279B2 (en) | 2008-02-25 | 2011-11-22 | International Business Machines Corporation | Performance neutral heartbeat for a multi-tasking multi-processor environment |
US7895462B2 (en) | 2008-02-25 | 2011-02-22 | International Business Machines Corporation | Managing recovery and control of a communications link via out-of-band signaling |
US8225280B2 (en) | 2008-02-25 | 2012-07-17 | International Business Machines Corporation | Incorporating state machine controls into existing non-state machine environments |
US20090216518A1 (en) * | 2008-02-25 | 2009-08-27 | International Business Machines Corporation | Emulated multi-tasking multi-processor channels implementing standard network protocols |
US20090217284A1 (en) * | 2008-02-25 | 2009-08-27 | International Business Machines Corporation | Passing initiative in a multitasking multiprocessor environment |
US20090217007A1 (en) * | 2008-02-25 | 2009-08-27 | International Business Machines Corporation | Discovery of a virtual topology in a multi-tasking multi-processor environment |
US8429662B2 (en) | 2008-02-25 | 2013-04-23 | International Business Machines Corporation | Passing initiative in a multitasking multiprocessor environment |
US20090216893A1 (en) * | 2008-02-25 | 2009-08-27 | International Business Machines Corporation | Buffer discovery in a parrallel multi-tasking multi-processor environment |
US20090213753A1 (en) * | 2008-02-25 | 2009-08-27 | International Business Machines Corporation | Subnet management in virtual host channel adapter topologies |
US7962564B2 (en) | 2008-02-25 | 2011-06-14 | International Business Machines Corporation | Discovery of a virtual topology in a multi-tasking multi-processor environment |
US20090217291A1 (en) * | 2008-02-25 | 2009-08-27 | International Business Machines Corporation | Performance neutral heartbeat for a multi-tasking multi-processor environment |
US20090216853A1 (en) * | 2008-02-25 | 2009-08-27 | International Business Machines Corporation | Subnet management discovery of point-to-point network topologies |
US20090216923A1 (en) * | 2008-02-25 | 2009-08-27 | International Business Machines Corporation | Managing recovery of a link via loss of link |
US8762125B2 (en) | 2008-02-25 | 2014-06-24 | International Business Machines Corporation | Emulated multi-tasking multi-processor channels implementing standard network protocols |
US20090217270A1 (en) * | 2008-02-25 | 2009-08-27 | International Business Machines Corporation | Negating initiative for select entries from a shared, strictly fifo initiative queue |
US8793699B2 (en) | 2008-02-25 | 2014-07-29 | International Business Machines Corporation | Negating initiative for select entries from a shared, strictly FIFO initiative queue |
US20090216927A1 (en) * | 2008-02-25 | 2009-08-27 | International Business Machines Corporation | Managing recovery and control of a communications link via out-of-band signaling |
US8893159B1 (en) | 2008-04-01 | 2014-11-18 | Alacritech, Inc. | Accelerating data transfer in a virtual computer system with tightly coupled TCP connections |
US8539513B1 (en) | 2008-04-01 | 2013-09-17 | Alacritech, Inc. | Accelerating data transfer in a virtual computer system with tightly coupled TCP connections |
US8341286B1 (en) | 2008-07-31 | 2012-12-25 | Alacritech, Inc. | TCP offload send optimization |
US9413788B1 (en) | 2008-07-31 | 2016-08-09 | Alacritech, Inc. | TCP offload send optimization |
US9667729B1 (en) | 2008-07-31 | 2017-05-30 | Alacritech, Inc. | TCP offload send optimization |
US9306793B1 (en) | 2008-10-22 | 2016-04-05 | Alacritech, Inc. | TCP offload device that batches session layer headers to reduce interrupts as well as CPU copies |
US8365008B2 (en) | 2010-10-13 | 2013-01-29 | International Business Machines Corporation | Providing unsolicited global disconnect requests to users of storage |
WO2016001772A1 (en) * | 2014-07-02 | 2016-01-07 | International Business Machines Corporation | Synchronizing operations between regions when a network connection fails |
US20220067819A1 (en) * | 2020-09-03 | 2022-03-03 | Mastercard International Incorporated | Methods and systems for recovering a failed payment processing request |
US20220138059A1 (en) * | 2020-11-05 | 2022-05-05 | Samsung Electronics Co., Ltd. | Storage system and operating method thereof |
US11809290B2 (en) * | 2020-11-05 | 2023-11-07 | Samsung Electronics Co., Ltd. | Storage system and storage queue processing following port error |
Also Published As
Publication number | Publication date |
---|---|
US6260158B1 (en) | 2001-07-10 |
US6389555B2 (en) | 2002-05-14 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US6260158B1 (en) | System and method for fail-over data transport | |
US7290086B2 (en) | Method, apparatus and program storage device for providing asynchronous status messaging in a data storage system | |
US5784617A (en) | Resource-capability-based method and system for handling service processor requests | |
US6868442B1 (en) | Methods and apparatus for processing administrative requests of a distributed network application executing in a clustered computing environment | |
US6772304B2 (en) | Control method for a data storage system | |
JP3657665B2 (en) | Multiple computer systems coupled to shared memory and control method of multiple computer systems coupled to shared memory | |
US7490264B2 (en) | Method for error handling in a dual adaptor system where one adaptor is a master | |
US6983324B1 (en) | Dynamic modification of cluster communication parameters in clustered computer system | |
RU2108621C1 (en) | Trouble-free computing system and its organization process | |
US8984222B2 (en) | Methods and structure for task management in storage controllers of a clustered storage system | |
US6345368B1 (en) | Fault-tolerant access to storage arrays using active and quiescent storage controllers | |
US20050125557A1 (en) | Transaction transfer during a failover of a cluster controller | |
US7567514B2 (en) | RAID apparatus, and communication-connection monitoring method and program | |
JPH06214969A (en) | Method and equipment for information communication | |
EP1200896A2 (en) | Intelligent splitter, system, and methods of use | |
JP2006048578A (en) | Computer system, computer and its program | |
JP2004516575A (en) | How to prevent "split brain" in computer clustering systems | |
US7406617B1 (en) | Universal multi-path driver for storage systems including an external boot device with failover and failback capabilities | |
US6345331B1 (en) | Device adapter being reintegrated with plurality of device adapters of network, or reestablishing permissions and resubmitting I/O requests depending on determined device state after failure | |
GB2395809A (en) | Metadata lock management used to maintain data image | |
US20050050376A1 (en) | Two node virtual shared disk cluster recovery | |
JP2007334668A (en) | Memory dumping method, cluster system, node constituting the system, and program | |
JPH08328990A (en) | Computer system and processing method therefor | |
JPS62296264A (en) | Control system for structure of data processing system |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
STCF | Information on status: patent grant |
Free format text: PATENTED CASE |
|
FPAY | Fee payment |
Year of fee payment: 4 |
|
FPAY | Fee payment |
Year of fee payment: 8 |
|
AS | Assignment |
Owner name: HEWLETT-PACKARD DEVELOPMENT COMPANY, L.P., TEXAS Free format text: CHANGE OF NAME;ASSIGNOR:COMPAQ INFORMATION TECHNOLOGIES GROUP, L.P.;REEL/FRAME:026908/0651 Effective date: 20021001 |
|
FPAY | Fee payment |
Year of fee payment: 12 |
|
AS | Assignment |
Owner name: HEWLETT PACKARD ENTERPRISE DEVELOPMENT LP, TEXAS Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:HEWLETT-PACKARD DEVELOPMENT COMPANY, L.P.;REEL/FRAME:037079/0001 Effective date: 20151027 |