Error detection/correction and fault detection/recovery – Data processing system error or fault handling – Reliability and availability
Reexamination Certificate
1999-07-28
2003-07-01
Le, Dieu-Minh (Department: 2184)
Error detection/correction and fault detection/recovery
Data processing system error or fault handling
Reliability and availability
Reexamination Certificate
active
06587959
ABSTRACT:
FIELD OF INVENTION
This invention relates to computer programs, and more particularly to addressing schemes for sending messages to peripherals connected to clustered computers.
BACKGROUND ART
In a client/server architecture, server computers may be grouped together into a cluster. A cluster could have one default server and at least one backup server. If the default server fails, all incoming messages are routed to the backup server so that it becomes the default server. In this configuration increased fault tolerance is provided. Switching between servers may be achieved through a shared common access address for all servers in the cluster, such as, a common Internet Protocol (IP) address. One software product for providing such a common address for a cluster and the capability of switching between servers has been designed by the Microsoft Corporation, of Redmond, Wash., called the Microsoft Cluster Server.
Often times each server in a cluster is connected to the same peripheral device. This peripheral may contain data storage for client applications. All clustered servers are capable of accessing this data and providing it to client applications, but only one server (the aforementioned default server) will access the data at any one time. The clustered servers all use the same “name” or “handle” to refer to a peripheral device, such as, a data storage area (this name is typically provided by the user when creating the data storage). Clustering technology allows the client application to be unaware of which server is handling the request for accessing the data storage area, because all servers are capable of responding to the common IP address of the cluster, and all servers use the same “name” or “handle” to refer to the data storage area. Therefore, when the default server fails, the backup server transparently provides access to the data storage area, because the “name” or “handle” will be the same.
However, when the client application is actually managing the peripheral device (as opposed to accessing the data on it), the “name” or “local path” of the device may not be the same between servers in the cluster. For example, if the peripheral is a storage processor, the device name on one server may be a concatenation of the host bus adapter slot number, the disk array storage processor slot id, and a logical unit number (lun) on the disk array. If another server in the cluster uses a different host bus adapter slot number, the concatenated device name or local path will be different. This will result in a loss of the ability to transparently manage the peripheral in a cluster, which is unacceptable and contrary to the services provided by clustering software. In the text that follows, the term local path and concatenated device name shall be synonymous.
Client applications that manage peripherals commonly communicate with the peripheral via “agent” software running on the server connected to the peripheral. This agent uses commonly known network transport mechanism (i.e. sockets over TCP/IP) to send and receive data to and from client applications. Should the client application wish to send a message to a peripheral device of a server, the client application will pass the message, along with the concatenated device name, to the agent. The agent will then simply pass the message to the peripheral using an established method provided by the server's operating system (i.e. a SCSI pass-through IOCTL interface).
FIG. 1
shows a block diagram of a client sending a message to a server cluster. The designation “ABC” represents the complete local path. In this example the final destination is a storage processor that is attached to the server. Here the letter “A” represents the host bus adapter, the letter “B” represents the SCSI address of the storage processor, and the letter “C” represents the LUN unit on the storage processor that is to be communicated with.
Providing the full local path is an adequate addressing solution, as long as, the default server does not fail. When the default server fails and the message is rerouted to the backup server, the local path may no longer be valid.
FIG. 2
shows a block diagram of this situation. Server “X” fails and the message is routed to server “Y”. The message/request is attempting to reach a logical group of disks “C”, however the local path is not “ABC” but is now “DEC”. Thus, in this prior art addressing scheme, the message fails to reach the destination.
SUMMARY OF THE INVENTION
In accordance with one aspect of the invention, a method of forwarding a message received by a server to a coupled hardware device is provided. The method may also be accomplished in a server cluster where the server cluster is comprised of a default server and a coupled backup server.
A look-up table is created in the server for fall hardware devices coupled to the server by a server agent. The look-up table relates a unique identifier of a hardware device to a local path (i.e. “ABC”). The lookup table is stored in memory accessible by the server agent.
The server agent sends all of the hardware identifiers to the client. Typically, this occurs as the result of a client application requesting this information. The client can then send a message for a hardware device connected to the server. The message is attached to a unique identifier which contains the hardware identifier. The server agent then extracts the identifier from the message, because the server and the client are using an agreed-upon structure to send messages back and forth to each other. The server then retrieves the look-up table and locates the path in the look-up table for the coupled hardware device based on the hardware identifier parsed from the unique identifier. The message is then forwarded through the path to the hardware device.
If the method is implemented in a server cluster environment, each server may initially identify if any hardware devices are attached to the server and access a hardware identifier for each hardware device that is found attached to the server. The hardware identifier can be accessed using standard protocols such as SCSI mode sense, or the protocols suggested by the attached peripheral. From the hardware identifiers, each server creates a look-up table. The lookup table is an association between the hardware identifier and a path where the path comprises a local access channel from the input of the server to the hardware device. Port numbers of the hardware device may be included within the unique identifier.
Preferred embodiments of the invention are implemented as a computer program product having a computer usable medium with computer readable program code thereon. The computer readable code may be read and utilized by the computer system in accordance with conventional processes.
REFERENCES:
patent: 5253342 (1993-10-01), Blount et al.
patent: 5276871 (1994-01-01), Howarth
patent: 5448698 (1995-09-01), Wilkes
patent: 5537642 (1996-07-01), Glowny et al.
patent: 5561769 (1996-10-01), Kumar et al.
patent: 5802298 (1998-09-01), Imai et al.
patent: 5974474 (1999-10-01), Furner et al.
patent: 6006331 (1999-12-01), Chu et al.
patent: 6292905 (2001-09-01), Wallach et al.
patent: 6377987 (2002-04-01), Kracht
Sjolander Todd Michael
Todd Stephen James
Bromberg & Sunstein LLP
EMC Corporation
Le Dieu-Minh
LandOfFree
System and method for addressing scheme for use on clusters does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with System and method for addressing scheme for use on clusters, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and System and method for addressing scheme for use on clusters will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3091524