CA2270500C - Method, system and article of manufacture for parallel, remote administration of mirrored and alternate volume groups in a distributed data processing system - Google Patents
Method, system and article of manufacture for parallel, remote administration of mirrored and alternate volume groups in a distributed data processing system Download PDFInfo
- Publication number
- CA2270500C CA2270500C CA 2270500 CA2270500A CA2270500C CA 2270500 C CA2270500 C CA 2270500C CA 2270500 CA2270500 CA 2270500 CA 2270500 A CA2270500 A CA 2270500A CA 2270500 C CA2270500 C CA 2270500C
- Authority
- CA
- Canada
- Prior art keywords
- volume
- group
- node
- target node
- sdr
- 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.)
- Expired - Fee Related
Links
Abstract
A method, system and article of manufacture for remotely administering one or more nodes of a distributed data processing system to provide mirroring of operating system images and/or designating of alternate volume groups for the one or more nodes. A new data class is defined in a system data repository (SDR) coupled to a control node of the distributed system. A set of commands are provided to initiate and discontinue mirroring from the control node on a nodal volume group, along with designating alternate volume groups for remote installation on one or more nodes of the system in parallel. An interface to add, delete, modify or display information about nodal volume groups is also provided.
Description
METHOD, SYSTEM AND ARTICLE OF MANUFACTURE FOR
PARALLEL, REMOTE ADMINISTRATION OF MIRRORED AND
ALTERNATE VOLUME GROUPS IN A DISTRIBUTED DATA
PROCESSING SYSTEM
Technical Field This invention relates to methods, systems and articles of manufacture for administering operating systems on a distributed data processing system, and more particularly, the invention relates to remote administration of one or more nodes of the data processing system to provide, for example, mirroring of operating system images and/or designating of alternate volume groups for the one or more nodes.
Background of the Invention Many computer system customers require systems to be available on a seven-day, twenty-four hour basis. One way to provide this high availability is through redundancy so that no component is a single point of failure. In the case of an AIX~ operating system, i.e., the International Business Machines Corporation's version of the UNIX~ operating system, redundancy of the operating system image itself is provided via "mirroring" the operating system to separate physical volumes. However, "mirroring" of the operating system on AIX does not lend itself to mirroring on a distributed computer system such as a RISC System/6000~
(RS/6000~) Scalable POWERparallel System~ (SP) distributed computer system available from International Business Machines Corporation of Armonk, New York.
One particular problem in mirroring operating system images on the SP is that the SP has no central point of control for mirroring. No "central point of control" means there is no way to collect and display customer directives regarding mirroring, there is no way to apply mirroring short of logging on to every SP node. Once mirroring is initiated, there is no data available on which nodes are using mirrored volume groups, nor if any nodes are in a failover condition.
Conventionally, if a customer wishes to mirror volume groups, the customer would have to use, for example, IBM~ Parallel System Support Program (PSSP version 2.1) to install the nodes without mirroring initiated. Post-installation, the customer would log into the node to enter the set of commands to initiate mirroring. The customer would then write an additional short script that would set the bootlist of the node each time the node is booted to reflect the mirrored volume group presence in the list of bootable devices. The customer would then have to repeat this procedure for each node that mirroring is to be initiated on. Once mirroring is initiated, the customer would have to log on to each node to determine which nodes are using mirrored volume groups, and if any node has failed over to a mirrored volume group.
As a related problem, alternate volume groups may need to be created on one or more nodes of the system. A customer may require an alternate volume group when the customer needs to run multiple different copies of the operating system at different times, without forcing a re-install of the node. Different copies of the operating system might be required for different levels of device driver support, or to have "secure" versus "unsecure" levels of data at highly secure installations. Alternate volume groups may provide many of the same problems on the SP as does mirroring. This is again because there is no central point of control for alternate physical volume administration on the SP.
Conventionally, if a customer wishes to use alternate volume groups, for example, to boot a node from different versions of the AIX operating system, the customer would need to enter information via a command or System Management Interface Tool (SMIT) interface to designate the new volume as the volume to install. The customer would then install the alternate volume using, for example, PS SP software. If the customer wishes to change the node to boot from the other alternate device, the customer would have to manually log into the node to modify the bootlist of the node and then reboot the node. As in mirroring, there is no method of determining which nodes are using alternate volume groups short of logging on to every node.
In view of the above, the present invention comprises a method/system of centrally administering alternate and mirrored volume groups of the nodes in a distributed processing system.
Disclosure of the Invention Briefly summarized, the present invention comprises in one aspect a method of administering a mirrored volume group or an alternate volume group on at least one target node of a distributed processing system having multiple processors, with one processor being designated a control node S and one or more other processors being designated target nodes. The method includes: storing in Mode object and a Volume Group object in a system data repository (SDR), coupled to the control node, information on each volume group and the at least one target node in the distributed processing system; and performing at least one of mirroring of a volume group or designating an alternate volume group of said at least one target node of the distributed processing system, wherein the performing is initiated at the control node remote from the at least one target node. As an enhancement, multiple volume groups on multiple target nodes may be mirrored in parallel or multiple alternate volume groups may be designated on multiple target nodes in parallel in accordance with this invention.
In another aspect, the invention comprises a method for administering a volume group on at least one target node of a distributed processing system having multiple processors, with one processor being designated a control node and one or more other processors each being designated a target node. The method includes: storing information in a Node object and a Volume Group object in a system data repository (SDR) coupled to the control node, with the Node object and the Volume Group object providing information on each volume group of the at least one target node in the distributed processing system; and performing at least one of adding, deleting, modifying, or displaying information about at least one volume group of said at least one target node of the distributed processing system using at least one of the Node object and the Volume Group object in the SDR.
The present invention also comprises in another aspect a distributed processing system which includes multiple processors. One processor of the system is designated a control node and one or more other processors are each designated a target node. The system also has a system data repository (SDR) coupled to the control node, and means for administering at least one of a mirrored volume group or an alternate volume group of the at least one target node from the control node.
The means for administering includes: means for storing information in a Node object and a Volume Group object in the SDR, the Node object and the Volume Group object providing information on each volume group of the at least one target node in the distributed processing system; and means for performing at least one of mirroring of a volume group or designating an alternate volume group of the at least one target node of the distributed processing system, the means for performing being initiated at the control node remote from the at least one target node.
In another aspect, a distributed processing system is provided which includes multiple processors. One processor is designated a control node and one or more other processors are each designated a target node. A system data repository (SDR) is coupled to the control node and means for administering a volume group on at least one target node is provided. The means for administering includes: means for storing information in a Node object and Volume Group object in the SDR, the Node object and the Volume Group object providing information on each volume group of the at least one target node in the distributed processing system;
and means for performing at least one of adding, deleting, modifying, or displaying information about at least one volume group of the at least one target node of the distributed processing system using at least one of the Node object and the Volume Group object in the SDR.
In still another aspect, a distributed processing system is provided which includes multiple processors. One processor is designated a control node and one or more other processors are each designated a target node. A system data repository (SDR) is coupled to the control node. The control node is adapted to administer at least one of a mirrored volume group or an alternate volume group of the at least one target node. The control node includes a storage controller adapted to store information in a Node object and a Volume Group object in the SDR. The Node object and the Volume Group object provide information on each volume group of the at least one target node in the distributed processing system. The storage controller is further adapted to perform at least one of mirroring of a volume group or designating an alternate volume group of the at least one target node of the distributed processing system.
The present invention also comprises in one aspect at least one computer readable medium for storing data usable by a storage controller coupled to a storage device of a distributed processing system. The medium includes a data structure stored within the at least one computer readable medium. The data structure comprises: Node object information usable by the storage controller in identifying at least one target node within the distributed processing system;
and a Volume Group object comprising information on at least one volume group of said at least one target node in the distributed processing system. The Volume Group object is usable by the storage controller to remotely administer volume groups of the at least one target node of the distributed processing system.
In a further aspect, this invention provides at least one program storage device readable by a machine, tangibly embodying at least one program of instructions executable by the machine to perform a method for administering at least one of a mirrored volume group or an alternate volume group of at least one target node of a computer system. The computer system includes a plurality of processors coupled to a storage controller, the storage controller being coupled to the storage unit.
The method includes: storing information in a Node object and a Volume Group object in the storage unit, the Node object and the Volume Group object providing information on each volume group of the at least one target node in the computer system; and performing at least one of mirroring of a volume group or designating an alternate volume group of the at least one target node of the computer system. The performing is initiated by the storage controller remote from the at least one target node.
In a still further aspect, an article of manufacture is provided which includes at least one computer usable medium having computer readable program code means embodied therein for administering at least one of a mirrored volume group or an alternate volume group on at least one target node in a distributed processing system having a control node coupled to a system data repository (SDR). The computer readable program code means in the article of manufacture includes: computer readable program code means for causing a computer to store information in a Node object and a Volume Group object in the SDR, the Node object and the Volume Group object providing information on each volume group of the at least one target node in the distributed processing system; and computer readable program code means for causing a computer to perform at least one of mirroring of a volume group or designating an alternate volume group of the at least one target node of the distributed processing system.
In a yet further aspect of the present invention, an article of manufacture is provided which includes at least one computer usable medium having computer readable program code means embodied therein for administering a volume group on at least one target node of a distributed processing system having multiple processors, one processor being designated a control node and one or more other processors being designated a target node. The control node is coupled to a system data repository (SDR). The computer readable program code means in the article of manufacture includes: computer readable program code means for causing a computer to store information in a Node object and a Volume Group object in the SDR, the Node object and the Volume Group object providing information on each volume group of the at least one target node I S in the distributed processing system; and computer readable program code means for causing a computer to perform at least one of adding, deleting, modifying, or displaying information about at least one volume group of the at least one target node of the distributed processing system using at least one of the Node object and the Volume Group object in the SDR.
To restate, this invention provides for central administration of one or more remote nodes of a distributed data processing system. The invention allows for mirroring of operating system images and/or designating of alternate volume groups for the one or more remote nodes. The invention described herein provides a new data class in the system data repository (SDR) to retain information about volume groups at the nodes of the system. This central repository is coupled to the control node for central administration of the physical volumes of the nodes. An ability to create, modify, and delete this new data class (or volume group information) is also provided, as is the ability to form new volume groups for each node based upon information in the repository. A set of commands is provided to initiate and/or discontinue mirroring on multiple nodal volume groups of the system in parallel from the control node. Further, the invention provides for administering the bootlist on a node or set of nodes remotely and in parallel from the control node, again allowing for mirroring and alternate volume groups. Also, the bootlist can be set from the control node to correctly provide for automatic failover to backup volume groups in the nodes of the distributed system.
Advantageously, a system administrator or user does not have to log on to the individual nodes or use, for example, a remote AIX shell to administer the volume groups of the nodes. From the central workstation, the user can invoke a series of SMIT panels to input information about the mirroring or alternate volume groups of the nodes. This information is stored in the existing Node objects and in a new object, referred to herein as the "Volume Group object", ofthe SDR. Once the information about mirroring and alternate volume groups is entered in the SDR, the user can initiate mirroring in one of three ways, i.e., by installing the node, by rebooting the node, or immediately by invoking a mirroring/unmirroring routine in accordance with the present invention. Alternate volume groups can also be designated and installed from the control node.
Based on SDR data, the control node can determine which volume group is the boot volume group.
Brief Description of the Drawings The above-described objects, advantages and features of the present invention, as well as others, will be more readily understood from the following detailed description of certain preferred embodiments of the invention, when considered in conjunction with the accompanying drawings in which:
Fig. 1 is a schematic diagram of a parallel, distributed data processing system usable with the present invention;
Fig. 2 is a diagram of a portion of the system of Fig. 1 illustrating a portion of the method of the present invention;
P09-98-058 '7 Fig. 3 is a flow diagram of the program "spmirrorvg", run on the control workstation in accordance with the present invention, showing checking of input parameters and calling of "spmirror" to initiate mirroring on a node of the system;
Fig. 4 is a flow diagram of the remote running of "spmirror" of Fig. 3, identifying steps to be taken by a node to perform mirroring in accordance with the present invention;
Fig. 5 is a flow diagram of the program "spunmirrorvg", run on the control workstation in accordance with the present invention, and showing checking of input parameters and calling of "spunmirror" to initiate unmirroring on a node of the system;
Fig. 6 is a flow diagram of the run "spunmirror" step of the flow diagram of Fig. 5, detailing the steps to be taken on a node to perform unmirroring in accordance with the present invention;
1 S Fig. 7 is a flow diagram of user-initiated adding, modifying and deleting of Volume Group objects in the SDR in accordance with the present invention;
Fig. 8 is a flow diagram of the program "spmkvgobj", run on the control workstation in accordance with the present invention, for creating a Volume Group obj ect for a node of the system;
Fig. 9 is a flow diagram of the program "spchvgobj", run on the control workstation in accordance with the present invention, for changing Volume Group obj ect information in the system data repository; and Fig. 10 is a flow diagram of the program "sprmvgobj", run on the control workstation in accordance with the present invention, for removing Volume Group object information of a user-specified name and node number.
P09-98-058 g Best Mode for Carrying Out the Invention The following definitions of terms are provided to facilitate discussion of a detailed embodiment of the present invention.
Physical Volume (PVC
An individual fixed disk drive attached to a node.
Volume Group (VG~
A group of PVs, or fixed disk drives. The advantage of a Volume Group is that a group can be managed as a single entity to higher layers of software.
Root Volume Group~RVG) A special kind of Volume Group, the RVG contains all information about the operating system.
Mirroring a Volume Group Mirroring a Volume Group is a method of simultaneously writing all information to two separate physical volumes so that one volume becomes a backup or "mirrored"
copy of the other. When mirroring a Root Volume Group to separate volumes, each mirror becomes an independently bootable version of the operating system.
Alternate Volume Groun When a workstation has multiple different copies of the operating system to boot from, such that the copies are actually different versions or levels of the operating system, it is said to have Alternate Volume Groups.
Failover/Takeover The condition when a volume group fails due to hardware or software errors, and the exact duplicate of the group (i.e., the mirror) becomes the active volume group.
SDR
Or System Data Repository, is a database of system administrative information on the SP.
It contains such information as IP addresses for network adapters of every node, the hostname for each node, the client/server relationship with other nodes, etc.
bootlist A list of RS/6000 bootable devices in the order that they will be tried when booting a node.
All devices in the bootlist will be tried in order until a device is found that has a bootable AIX image.
SMIT
System Management Interface Tool, a part of AIX that provides a textual or graphical full screen interface for the system administrator to perform administrative tasks, such as setting hostnames or IP addresses, modifying device information, etc.
Control Workstation An RS/6000 workstation that provides a central point for system administration for many SP
functions. The control workstation is not an SP node; it connects to the SP
nodes via an ethernet LAN.
node list A list of a group of nodes.
IS
Using the above definitions, and to briefly summarize, the present invention comprises a method and system for centrally administering (preferably in parallel) alternate and/or mirrored volume groups of one or more nodes of a distributed data processing system.
The approach is implemented in one example by building upon existing AIX and PSSP operations.
The invention provides:
- a new data class in the SDR to retain information about volume groups;
- a set of commands to initiate and discontinue mirroring on a nodal volume group;
- a method to designate an alternate volume group for remote installation on a node;
- an interface to add/delete/modify or display information about nodal volume groups; and - a method of setting the bootlist correctly to provide for automatic failover to a backup physical volume on a node.
With central administration from the SP control workstation in accordance with this invention, a customer can invoke a new series of SMIT panels to input information about the mirroring or alternate volume groups of a node. This information will be stored in the existing Node object and a new object, labeled herein the "Volume Group object", held in the SDR. There will also be a command to display information about the known volume groups of a node. Once the information about mirroring and alternate volume groups is entered in the SDR, a customer can initiate mirroring in one of several ways, e.g., by installing the node, by rebooting the node, or by invoking a new mirroring script described hereinbelow. The customer can also designate in accordance with this invention, an alternate volume to be installed. Based on SDR data, the node can then determine which volume group is the boot volume group.
Fig. l is a schematic diagram of a distributed computer system 100 useable with the present invention. The distributed computer system 100 may be an IBM RISC System/6000 Scalable POWERparallel Systems (SP) distributed computer system available from International Business Machines Corporation of Armonk, New York. The embodiment disclosed in Fig. 1 is an SP
computer having a total of 8 frames, with each frame having up to 16 nodes, for a total of 128 nodes.
All of the nodes 106 are joined by a local area network (LAN) 102. Each node 106 is a computer itself, and may be a RISC System/6000 workstation, as is well-known by those skilled in the art.
All of the nodes in a frame of the SP computer 100 are included in a LAN
segment which is joined by the other LAN segments through LAN gates 104. Also connected to the LAN 102, is a control workstation (CWS) 112 which controls operation of the SP computer 100. The control workstation has a direct access storage device (DASD) 114 referred to as the System Shared Disk on which is stored the system data repository (SDR) files. The SDR files include such information as a list of nodes that are in the system and their configuration, and includes resources and object definitions for each of the nodes 106. Each node 106 also includes a DASD
device 107 for storing data processed by the SP computer 100.
In one embodiment, the nodes in each frame are also connected to an IBM
Scalable POWERparallel switch (SPS) 105. Each of the SPS switches 105 of each frame is connected to neighboring SPS switches 105 of other frames by a bus 110.
As is well understood in the art, the CWS node 112 sends system data and control signals to the frames of the SP computer 100 by means of the LAN 102 while messages and data may be sent from one to another of the nodes 106 by means of the high performance switches 105.
Fig. 2 is a portion of the system 100 of Fig. 1. The control workstation 112 provides a single point of control wherein the control workstation provides the interfaces to create, delete or update Volume Group objects contained in the SDR 114. The control workstation centrally administers the mirroring, unmirroring and bootless commands to nodes 1, 2, 3...N, (i.e., 201, 202, 203...204, respectively). It will be understood that each type of new operation described herein (e.g., make, delete or change a Volume Group object) is issued on the control workstation, and that the necessary data is stored in the SDR 114. It should also be understood that the number of nodes, which may be referred to as the targets or target nodes by the control workstation, may be varied to one or more as desired by the system administrator (i.e., user).
In PSSP, there is a class in the SDR called the "node class" which contains information specific to individual SP nodes. This invention provides a new class called the "volume_group class", which contains information about the volume groups of each node.
Further, the node class is expanded to have a new attribute, the selected vg attribute, which points to a selected volume group of the volume-group class. Each Volume Group object is unique by node, and vg name.
Each Volume Group object has a set of attributes which describe a volume group. The volume_group attributes, their initial and legal values, as well as data types are described in Table 1.
Table 1: SDR Volume Group Class Description Attribute Type Name Description Values node number I node number for Volume Group an integer representing a node number vg name S customer supplied volume group customer supplied, a convenient name handle for reference, initially "rootvg"
pv_list S a list of physical volumes. Valid initially "hdisk0"
formats are: hdisk,hdisk,...hdisk connwhere,connwhere,...
connwhere location:location:...location rvg S is this volume group a root initially "true"
volume group? true/false NOTE: rvg is always true for a current release of PSSP
quorum S is quorum on for this volume initially "true"
group? true/false copies I number of copies for the volume initially 1 group. Valid are 1 or 2 or 3 mapping S Is mapping on? true/false initially "false".
NOTE:
mapping is always false for this release of PSSP
install_imageS mksysb image name to install "default"
next code versionS PSSP code version to use for derived from Syspar next install Ippsource S name of the lppsource name resource "default"
to use for next install boot server S node number of boot/install default depending on node server location last_installS a date string of time when the node initial was last installed last_install_imageS a string of the last image initial installed on the node last bootdiskS The logical device name of the initial last volume the i ~ node booted rrcrm Each Volume Group object describes a volume group of the node; and collectively the Volume Group objects of a node define all possible volume group states of the node. The Node object attribute, the selected vg, points to an object in the Volume Group class. The selected Volume Group object designates a volume group for subsequent commands.
Prior to this invention, certain of the attributes associated with the Volume Group object were associated with the Node object, since nodes had only one root volume group. With this invention, these attributes were moved to the Volume Group object, and this allows the data to represent multiple volume groups per node.
The following is a list of new commands pursuant to the present invention.
Note: the o notation indicates a value to be filled in by the user.
spmkvgobj -r <vg name>
-1 mode list>
-h <pv list>
-i <install image>
-v <lppsource_name>
-p <code_version>
-n <boot server>
-c < copies >
-q < quorum >
The "spmkvgobj" command is used to create a Volume Group object.
splstdata -v <vg name>
-1 mode list>
The "splstdata" command is used to list information about a Volume Group object.
sprmvgobj -r <vg name>
-1 mode list>
The "sprmvgobj" command is used to remove a Volume Group object.
spchvgobj -r <vg name>
-1 mode list>
-h <pv_list>
-i <install image>
-v <lppsource_name>
-p <code_version>
-n <boot server>
-c < copies >
-q < quorum >
The "spchvgobj" command is used to change information associated with the current Volume Group object.
spmirrorvg -1 mode list>
The "spmirrorvg" command is used to initiate mirroring of Volume Groups on a node or group of nodes. The command runs remotely, and places the process in the background, allowing for parallel execution.
spunmirrorvg -1 mode list>
The "spunmirrovg" command is used to halt mirroring on the current volume groups for a group of nodes. The command runs remotely and places the process in the background, allowing for parallel execution.
spbootins -c <selected Volume Group>
-1 mode list>
The "spbootins" command sets the current Volume Group object name for a node or group of nodes. The command does other things that are not relevant to this design, and not mentioned here.
spbootlist -1 mode list>
This command is used to set the bootlist on a node or group of nodes based on the combination of the mirroring and alternate volume group information for the node. If mirroring is off, the bootlist is set to a single physical volume. If mirroring is on, the bootlist is set to a list of physical volumes that provide redundant boot backups.
Fig. 3 is a flow diagram of one embodiment of mirroring 300 in accordance with the present invention. This mirroring routine ("spmirrorvg") runs on the control workstation to check the state of the SDR and the ability of the CWS to communicate with each node, for example, nodes 1, 2, 3 & N of Fig. 2. If the routine is unable to verify it is running on the control workstation or cannot read the SDR 301, then the mirroring process is exited with an error message 302. Otherwise, a sub-process is entered for each node specified in the system 303. Within this sub-routine, processing first determines whether the node number and Volume Group object are valid for the particular node 304. If "no", mirroring at that node is skipped 305. If the node number and Volume Group objects are valid, then processing determines whether the control workstation is in communication with the node 306. Again, if "no", the node is skipped 307. After establishing that the control workstation is in communication with the node, processing runs the command "spmirror"
(Fig. 4) remotely on the node 308. Ifthe control workstation is unable to run the command, then the node is skipped 309.
The outlined sub-process preferably proceeds in parallel for each node in the distributed system. Once the processing has completed mirroring for all designated nodes 310, the mirror operation is exited with an appropriate code and message 311. Note that the "spmirrorvg" routine 300 of Fig. 3 is a script which calls routine 400 (i.e., "spmirror") of Fig. 4 and reports any errors in mirroring back to the system administrator.
Fig. 4 illustrates the lower level mirroring program, "spmirror", employed by inquiry 308 of Fig. 3. "Spmirror" checks to see if mirroring is already in the desired state on the node and proceeds if the number of copies requested by the user in the SDR is unfulfilled, i.e., are the number of copies of the root volume group greater than or equal to the number of copies requested by the user? 401. If "yes", extend the volume group by any new physical volumes in the pv list 413, after which processing exits the routine since the number of mirrored copies of the volume group already exists 402. If there are additional physical volumes to be placed in the volume group, the volume group is extended to include them 403. If processing is unable to extend the root volume group by the physical volumes in the pv list, an error has occurred and processing is exited 404.
The AIX mirroring command "mirrorvg" is then called to initiate mirroring of the volume group at the node 405. The "mirrorvg" AIX command (as well as the other AIX
commands referenced herein) is described, for example, in an IBM publication entitled "AIX Version 4.3 Commands Reference", Volumes 1-6, First Edition October 1997. If mirroring is unable to be initiated, processing exits with an error 406. After mirroring, the AIX
commands "bosboot" 407 and "bootlist" 409 are called to make the new mirrored disk bootable, and to set the order of booting on the node to include the new mirrored disk. If either the "bosboot" or "bootlist" AIX commands are not properly performed, processing exits 408 & 410, respectively. If the state of quorum changed on the node, a message is sent to the user to reboot the node 411, thus successfully completing the mirroring process 412.
Fig. 5 illustrates one embodiment of unmirroring processing 500 in accordance with the present invention. This unmirroring process 500 is implemented on the control workstation, and begins by checking the state of the SDR and the ability of the control workstation to communicate with the SDR 501. If either inquiry fails, then the unmirroring process is exited with an error message 502. Assuming that the unmirroring routine is running on the control workstation and the control workstation can read the SDR, then a parallel implemented sub-routine is entered 503 which is performed for each designated node of the distributed system. Processing initially determines whether the node number and Volume Group objects are valid 504. If "no", then the node is skipped 505. Next, the unmirroring process determines whether the control workstation can communicate with the given node 506, and if "no", processing at that node is skipped 507.
Assuming that communication is established, the command "spunmirror" (Fig. 6) is run on the node remotely 508. If the command is unable to be processed, the node is skipped 509. After completing the designated processing for each selected node of the distributed system 510, preferably in parallel, the unmirroring process is exited with an appropriate code and message 511.
Note that the "spunmirrorvg" routine 500 is a script which calls the command "spunmirror"
600 depicted in Fig.
6 and reports any errors in unmirroring back to the user.
As noted, the lower level unmirroring process "spunmirror" is depicted in Fig.
6, which is an expansion of block 508 of Fig. 5. Spunmirror initially checks to see if mirroring is already in the desired state on the node, and proceeds if the reduced number of copies requested by the user in the SDR is unfulfilled 601. If the reduced number of copies of the volume groups already exists, "spunmirror" reduces the volume group if any physical volumes have been removed from the pv_list 613, and then processing is terminated 602. Otherwise, the AIX unmirroring command "unmirrorvg" is called 603. The command "unmirrorvg" is part of the AIX
operating system and is discussed in the above-mentioned IBM publication. If unmirroring cannot be initiated, processing is exited 604. After unmirroring, if there are any physical volumes in the volume group that need to be taken out, the AIX command "reducevg" is run to reduce the volume group and make the physical volumes available for another use 605. If the root volume group cannot be reduced, error is indicated 606. After unmirroring, the AIX commands "bosboot" 607 and "bootlist" 609 are called for updating of the node information to reflect the disks which have been removed from the volume group. If either the "bosboot" or "bootlist" AIX commands are not properly performed, processing exits 608 & 610, respectively. Finally, if the state of quorum has changed on the node, a message is sent to the user to reboot the node 611, thus successfully completing the unmirroring process 612.
Fig. 7 is a flow diagram of user initiated processings 700 for making, changing or removing a Volume Group object in accordance with the present invention. Three new commands are provided herein, i.e., "spmkvgobj" 701, "spchvgobj" 702, and "sprmvgobj" 703.
Each of these commands interacts with information in the SDR 114. The "spmkvgobj" command is used to create a new Volume Group object, the "spchvgobj" command is employed to modify an existing Volume Group object, and the "sprmvgobj" command is used to remove an existing Volume Group object from the repository 114. Again, these Volume Group objects represent the information used by other commands described herein, such as "spmirrorvg" and "spunmirrorvg"
when initiating or P09-98-058 1 g discontinuing mirroring on a target node. Processing pursuant to the "spmkvgobj", "spchvgobj", and "sprmvgobj" commands is presented in greater detail in Figs. 8, 9 & 10, respectively.
Fig. 8 is a flow diagram of the user-initiated process 800 for making a Volume Group obj ect in accordance with the present invention. This process is initiated by invoking the "spmkvgobj"
command to create a new Volume Group object. Processing begins by checking the input parameters to make sure that "spmkvgobj" is running on the control workstation and that the control workstation can read the system repository 801. If "no", processing is terminated with an error message 802. Assuming that the program is running on the control workstation and the control workstation is in communication with the SDR, processing determines whether the user-inputted parameters are valid 803. If "no", processing terminates 804. Next, processing determines whether the Volume Group object to be created already exists for the particular node 805. If the Volume Group object already exists, processing exits with an error message 806. Thereafter, the routine creates the new Volume Group object and updates the SDR 807. If an error occurs during updating of the SDR, processing exits with an appropriate error code and message 808. Otherwise, the Volume Group object has been successfully created and processing ends 809.
Processing 900 for changing a Volume Group object is depicted in Fig. 9.
Again, this comprises a user-invoked command, "spchvgobj" to change an existing Volume Group object.
Processing begins by confirming that the command is running on the control workstation and that the control workstation can read the shared system repository 901. If "no", an appropriate error message is sent 902. Otherwise, the input parameters received from the user are checked to make sure that the parameters are valid 903. If "no", then processing ends with an error message 904.
Assuming that the parameters are valid, processing determines whether the Volume Group object that is about to change already exists for this node 905. If not, an error message is sent 906.
Assuming that the desired Volume Group object exists for the node, then processing changes the Volume Group object according to the user-specified parameters 907. If the updating of the SDR
with the changed volume group information fails, processing exits with an appropriate error message 908. Otherwise, the update processing of the Volume Group object's information is successfully completed 909.
Fig. 10 presents a flow diagram of processing 1000 in accordance with a user-invoking the "sprmvgobj" command of the present invention to delete an existing Volume Group object. The input parameters are initially checked to make sure that the command is running on the control workstation and that the program can read the SDR 1001. If "no", processing terminates with an error message 1002. Next, processing checks to make sure that all user parameters are valid 1003, and if not, issues an error message 1004. Assuming that the user parameters are valid, processing determines whether the Volume Group object to be removed exists for this node 1005, and if "no", processing terminates with an error message 1006. Assuming that the Volume Group object exists, then processing removes the object by the specified name for this particular node number 1007. If the Volume Group object is unable to be removed, an error message occurs during the removal process 1008. Upon removal of the object, processing terminates 1009.
Several examples of volume_group processing in accordance with the present invention are described below.
Initialization When PSSP is installed on the control workstation, the Node class and Volume Group class are created. One Node object and one Volume Group object are created per node detected. The "selected vg" (i.e., current volume group) attribute of the Node obj ect is set to "rootvg", to designate the Root Volume Group. The Volume Group Object that is created for each node has by default a "vg name" (i.e., volume group name) of "rootvg". All the other Volume Group attributes are initialized to default values, which indicate that "hdisk0" is the installation disk, and that mirroring is initially turned off for the volume group, i.e., the number of copies for the Volume Group object is set to 1. See Table 1.
Example 1: Mirroring a volume group at install time.
Initialization is performed as above.
Prior to installing a node, the user executes the "spchvgobj" command to set the pv list to the list of the physical volumes the user wants in the root volume group, and sets the number of mirrored copies to 2 or 3 (in this example). The user could list the information prior to installing the node using the "splstdata" command.
The user installs the node using standard PSSP procedures. When the node first boots, the "spmirrorvg" command is executed on the node to initiate mirroring.
On subsequent reboots of the node, the node writes information to the last bootdisk attribute of the Volume Group object. If this last bootdisk attribute does not match the expected boot disk for the node, the user could detect that a disk has failed and that a mirrored image has become the boot image.
The "last bootdisk" is a new attribute that is part of the Volume Group object in accordance with the present invention. This new attribute tells the user which physical volume the node booted from. In a mirrored environment, if the value of the last bootdisk changes, there must be a problem with a mirror of the root volume group, and this should alert the customer to a problem. The last bootdisk is set whenever the node is booted, for example, by a program named_ "psspfb-script", which is an existing PSSP program not part of this disclosure.
Example 2: Mirroring a volume group post installation.
Initialization is performed as above.
To begin mirroring a volume group on a node, the user first designates the name of the mirror using the "spchvgobj" command, to set the pv_list to the names) of the physical volumes) in the root volume group and sets the "copies" attribute to 2 or 3 (again by way of example).
To initiate mirroring, the user executes the "spmirrorvg" command, which executes a remote script to initiate mirroring on the node. Any error conditions that occur during mirroring are preferably displayed at the user's display console.
If multiple nodes have mirrors designated in their Volume Group obj ects, and if "spmirrovg"
is run with the names of many nodes, "spmirrorvg" will run across the nodes in parallel by starting background processes on every node. Again, information will come back from each process to the user's display console. Information from each process can be distinguished by a prefix to each line of output (standard PSSP code does this).
Example 3: Installing and selectine an alternate volume rout Initialization of the data is performed as above.
By default, the volume group to be installed and booted from is the Volume Group object with the name "rootvg", which is set during initialization of the data objects. To install and boot from an alternate volume group, the user first creates the alternate volume group in the SDR. To do this, the user executes the "spmkvgobj" command, filling in all the attributes that define the volume group. Note that the user can set AIX levels and PSSP levels to other than the values set for "rootvg".
With the alternate Volume Group object defined, the user executes the "spbootins" command to designate the new volume group as the current volume group for the node.
Using standard PSSP
procedures to install the node, the node installs using the alternate volume group instead of the default volume group "rootvg". If in this example the user wishes to boot from the original "rootvg"
volume group, the "selected vg" attribute of the Node object is set to "rootvg" via the "spbootins"
command. The user then executes the "spbootlist" command to set the bootlist on the node to reflect booting from "rootvg". Using standard AIX and PSSP procedures the user then reboots the node, and it would boot from the "rootvg" volume group.
The present invention can be included, for example, in an article of manufacture (e.g., one or more computer program products) having, for instance, computer usable media. This media has embodied therein, for instance, computer readable program code means for providing and facilitating the capabilities of the present invention. The articles of manufacture can be included as part of the computer system or sold separately.
Additionally, at least one program storage device readable by machine, tangibly embodying at least one program of instructions executable by the machine, to perform the capabilities of the present invention, can be provided.
The flow diagrams depicted herein are provided by way of example. There may be variations to these diagrams or the steps (or operations) described herein without departing from the spirit of the invention. For instance, in certain cases, the steps may be performed in differing order, or steps may be added, deleted or modified. All of these variations are considered to comprise part of the present invention as recited in the appended claims.
While the invention has been described in detail herein in accordance with certain preferred embodiments thereof, many modifications and changes therein may be effected by those skilled in the art. Accordingly, it is intended by the appended claims to cover all such modifications and changes as fall within the true spirit and scope of the invention.
PARALLEL, REMOTE ADMINISTRATION OF MIRRORED AND
ALTERNATE VOLUME GROUPS IN A DISTRIBUTED DATA
PROCESSING SYSTEM
Technical Field This invention relates to methods, systems and articles of manufacture for administering operating systems on a distributed data processing system, and more particularly, the invention relates to remote administration of one or more nodes of the data processing system to provide, for example, mirroring of operating system images and/or designating of alternate volume groups for the one or more nodes.
Background of the Invention Many computer system customers require systems to be available on a seven-day, twenty-four hour basis. One way to provide this high availability is through redundancy so that no component is a single point of failure. In the case of an AIX~ operating system, i.e., the International Business Machines Corporation's version of the UNIX~ operating system, redundancy of the operating system image itself is provided via "mirroring" the operating system to separate physical volumes. However, "mirroring" of the operating system on AIX does not lend itself to mirroring on a distributed computer system such as a RISC System/6000~
(RS/6000~) Scalable POWERparallel System~ (SP) distributed computer system available from International Business Machines Corporation of Armonk, New York.
One particular problem in mirroring operating system images on the SP is that the SP has no central point of control for mirroring. No "central point of control" means there is no way to collect and display customer directives regarding mirroring, there is no way to apply mirroring short of logging on to every SP node. Once mirroring is initiated, there is no data available on which nodes are using mirrored volume groups, nor if any nodes are in a failover condition.
Conventionally, if a customer wishes to mirror volume groups, the customer would have to use, for example, IBM~ Parallel System Support Program (PSSP version 2.1) to install the nodes without mirroring initiated. Post-installation, the customer would log into the node to enter the set of commands to initiate mirroring. The customer would then write an additional short script that would set the bootlist of the node each time the node is booted to reflect the mirrored volume group presence in the list of bootable devices. The customer would then have to repeat this procedure for each node that mirroring is to be initiated on. Once mirroring is initiated, the customer would have to log on to each node to determine which nodes are using mirrored volume groups, and if any node has failed over to a mirrored volume group.
As a related problem, alternate volume groups may need to be created on one or more nodes of the system. A customer may require an alternate volume group when the customer needs to run multiple different copies of the operating system at different times, without forcing a re-install of the node. Different copies of the operating system might be required for different levels of device driver support, or to have "secure" versus "unsecure" levels of data at highly secure installations. Alternate volume groups may provide many of the same problems on the SP as does mirroring. This is again because there is no central point of control for alternate physical volume administration on the SP.
Conventionally, if a customer wishes to use alternate volume groups, for example, to boot a node from different versions of the AIX operating system, the customer would need to enter information via a command or System Management Interface Tool (SMIT) interface to designate the new volume as the volume to install. The customer would then install the alternate volume using, for example, PS SP software. If the customer wishes to change the node to boot from the other alternate device, the customer would have to manually log into the node to modify the bootlist of the node and then reboot the node. As in mirroring, there is no method of determining which nodes are using alternate volume groups short of logging on to every node.
In view of the above, the present invention comprises a method/system of centrally administering alternate and mirrored volume groups of the nodes in a distributed processing system.
Disclosure of the Invention Briefly summarized, the present invention comprises in one aspect a method of administering a mirrored volume group or an alternate volume group on at least one target node of a distributed processing system having multiple processors, with one processor being designated a control node S and one or more other processors being designated target nodes. The method includes: storing in Mode object and a Volume Group object in a system data repository (SDR), coupled to the control node, information on each volume group and the at least one target node in the distributed processing system; and performing at least one of mirroring of a volume group or designating an alternate volume group of said at least one target node of the distributed processing system, wherein the performing is initiated at the control node remote from the at least one target node. As an enhancement, multiple volume groups on multiple target nodes may be mirrored in parallel or multiple alternate volume groups may be designated on multiple target nodes in parallel in accordance with this invention.
In another aspect, the invention comprises a method for administering a volume group on at least one target node of a distributed processing system having multiple processors, with one processor being designated a control node and one or more other processors each being designated a target node. The method includes: storing information in a Node object and a Volume Group object in a system data repository (SDR) coupled to the control node, with the Node object and the Volume Group object providing information on each volume group of the at least one target node in the distributed processing system; and performing at least one of adding, deleting, modifying, or displaying information about at least one volume group of said at least one target node of the distributed processing system using at least one of the Node object and the Volume Group object in the SDR.
The present invention also comprises in another aspect a distributed processing system which includes multiple processors. One processor of the system is designated a control node and one or more other processors are each designated a target node. The system also has a system data repository (SDR) coupled to the control node, and means for administering at least one of a mirrored volume group or an alternate volume group of the at least one target node from the control node.
The means for administering includes: means for storing information in a Node object and a Volume Group object in the SDR, the Node object and the Volume Group object providing information on each volume group of the at least one target node in the distributed processing system; and means for performing at least one of mirroring of a volume group or designating an alternate volume group of the at least one target node of the distributed processing system, the means for performing being initiated at the control node remote from the at least one target node.
In another aspect, a distributed processing system is provided which includes multiple processors. One processor is designated a control node and one or more other processors are each designated a target node. A system data repository (SDR) is coupled to the control node and means for administering a volume group on at least one target node is provided. The means for administering includes: means for storing information in a Node object and Volume Group object in the SDR, the Node object and the Volume Group object providing information on each volume group of the at least one target node in the distributed processing system;
and means for performing at least one of adding, deleting, modifying, or displaying information about at least one volume group of the at least one target node of the distributed processing system using at least one of the Node object and the Volume Group object in the SDR.
In still another aspect, a distributed processing system is provided which includes multiple processors. One processor is designated a control node and one or more other processors are each designated a target node. A system data repository (SDR) is coupled to the control node. The control node is adapted to administer at least one of a mirrored volume group or an alternate volume group of the at least one target node. The control node includes a storage controller adapted to store information in a Node object and a Volume Group object in the SDR. The Node object and the Volume Group object provide information on each volume group of the at least one target node in the distributed processing system. The storage controller is further adapted to perform at least one of mirroring of a volume group or designating an alternate volume group of the at least one target node of the distributed processing system.
The present invention also comprises in one aspect at least one computer readable medium for storing data usable by a storage controller coupled to a storage device of a distributed processing system. The medium includes a data structure stored within the at least one computer readable medium. The data structure comprises: Node object information usable by the storage controller in identifying at least one target node within the distributed processing system;
and a Volume Group object comprising information on at least one volume group of said at least one target node in the distributed processing system. The Volume Group object is usable by the storage controller to remotely administer volume groups of the at least one target node of the distributed processing system.
In a further aspect, this invention provides at least one program storage device readable by a machine, tangibly embodying at least one program of instructions executable by the machine to perform a method for administering at least one of a mirrored volume group or an alternate volume group of at least one target node of a computer system. The computer system includes a plurality of processors coupled to a storage controller, the storage controller being coupled to the storage unit.
The method includes: storing information in a Node object and a Volume Group object in the storage unit, the Node object and the Volume Group object providing information on each volume group of the at least one target node in the computer system; and performing at least one of mirroring of a volume group or designating an alternate volume group of the at least one target node of the computer system. The performing is initiated by the storage controller remote from the at least one target node.
In a still further aspect, an article of manufacture is provided which includes at least one computer usable medium having computer readable program code means embodied therein for administering at least one of a mirrored volume group or an alternate volume group on at least one target node in a distributed processing system having a control node coupled to a system data repository (SDR). The computer readable program code means in the article of manufacture includes: computer readable program code means for causing a computer to store information in a Node object and a Volume Group object in the SDR, the Node object and the Volume Group object providing information on each volume group of the at least one target node in the distributed processing system; and computer readable program code means for causing a computer to perform at least one of mirroring of a volume group or designating an alternate volume group of the at least one target node of the distributed processing system.
In a yet further aspect of the present invention, an article of manufacture is provided which includes at least one computer usable medium having computer readable program code means embodied therein for administering a volume group on at least one target node of a distributed processing system having multiple processors, one processor being designated a control node and one or more other processors being designated a target node. The control node is coupled to a system data repository (SDR). The computer readable program code means in the article of manufacture includes: computer readable program code means for causing a computer to store information in a Node object and a Volume Group object in the SDR, the Node object and the Volume Group object providing information on each volume group of the at least one target node I S in the distributed processing system; and computer readable program code means for causing a computer to perform at least one of adding, deleting, modifying, or displaying information about at least one volume group of the at least one target node of the distributed processing system using at least one of the Node object and the Volume Group object in the SDR.
To restate, this invention provides for central administration of one or more remote nodes of a distributed data processing system. The invention allows for mirroring of operating system images and/or designating of alternate volume groups for the one or more remote nodes. The invention described herein provides a new data class in the system data repository (SDR) to retain information about volume groups at the nodes of the system. This central repository is coupled to the control node for central administration of the physical volumes of the nodes. An ability to create, modify, and delete this new data class (or volume group information) is also provided, as is the ability to form new volume groups for each node based upon information in the repository. A set of commands is provided to initiate and/or discontinue mirroring on multiple nodal volume groups of the system in parallel from the control node. Further, the invention provides for administering the bootlist on a node or set of nodes remotely and in parallel from the control node, again allowing for mirroring and alternate volume groups. Also, the bootlist can be set from the control node to correctly provide for automatic failover to backup volume groups in the nodes of the distributed system.
Advantageously, a system administrator or user does not have to log on to the individual nodes or use, for example, a remote AIX shell to administer the volume groups of the nodes. From the central workstation, the user can invoke a series of SMIT panels to input information about the mirroring or alternate volume groups of the nodes. This information is stored in the existing Node objects and in a new object, referred to herein as the "Volume Group object", ofthe SDR. Once the information about mirroring and alternate volume groups is entered in the SDR, the user can initiate mirroring in one of three ways, i.e., by installing the node, by rebooting the node, or immediately by invoking a mirroring/unmirroring routine in accordance with the present invention. Alternate volume groups can also be designated and installed from the control node.
Based on SDR data, the control node can determine which volume group is the boot volume group.
Brief Description of the Drawings The above-described objects, advantages and features of the present invention, as well as others, will be more readily understood from the following detailed description of certain preferred embodiments of the invention, when considered in conjunction with the accompanying drawings in which:
Fig. 1 is a schematic diagram of a parallel, distributed data processing system usable with the present invention;
Fig. 2 is a diagram of a portion of the system of Fig. 1 illustrating a portion of the method of the present invention;
P09-98-058 '7 Fig. 3 is a flow diagram of the program "spmirrorvg", run on the control workstation in accordance with the present invention, showing checking of input parameters and calling of "spmirror" to initiate mirroring on a node of the system;
Fig. 4 is a flow diagram of the remote running of "spmirror" of Fig. 3, identifying steps to be taken by a node to perform mirroring in accordance with the present invention;
Fig. 5 is a flow diagram of the program "spunmirrorvg", run on the control workstation in accordance with the present invention, and showing checking of input parameters and calling of "spunmirror" to initiate unmirroring on a node of the system;
Fig. 6 is a flow diagram of the run "spunmirror" step of the flow diagram of Fig. 5, detailing the steps to be taken on a node to perform unmirroring in accordance with the present invention;
1 S Fig. 7 is a flow diagram of user-initiated adding, modifying and deleting of Volume Group objects in the SDR in accordance with the present invention;
Fig. 8 is a flow diagram of the program "spmkvgobj", run on the control workstation in accordance with the present invention, for creating a Volume Group obj ect for a node of the system;
Fig. 9 is a flow diagram of the program "spchvgobj", run on the control workstation in accordance with the present invention, for changing Volume Group obj ect information in the system data repository; and Fig. 10 is a flow diagram of the program "sprmvgobj", run on the control workstation in accordance with the present invention, for removing Volume Group object information of a user-specified name and node number.
P09-98-058 g Best Mode for Carrying Out the Invention The following definitions of terms are provided to facilitate discussion of a detailed embodiment of the present invention.
Physical Volume (PVC
An individual fixed disk drive attached to a node.
Volume Group (VG~
A group of PVs, or fixed disk drives. The advantage of a Volume Group is that a group can be managed as a single entity to higher layers of software.
Root Volume Group~RVG) A special kind of Volume Group, the RVG contains all information about the operating system.
Mirroring a Volume Group Mirroring a Volume Group is a method of simultaneously writing all information to two separate physical volumes so that one volume becomes a backup or "mirrored"
copy of the other. When mirroring a Root Volume Group to separate volumes, each mirror becomes an independently bootable version of the operating system.
Alternate Volume Groun When a workstation has multiple different copies of the operating system to boot from, such that the copies are actually different versions or levels of the operating system, it is said to have Alternate Volume Groups.
Failover/Takeover The condition when a volume group fails due to hardware or software errors, and the exact duplicate of the group (i.e., the mirror) becomes the active volume group.
SDR
Or System Data Repository, is a database of system administrative information on the SP.
It contains such information as IP addresses for network adapters of every node, the hostname for each node, the client/server relationship with other nodes, etc.
bootlist A list of RS/6000 bootable devices in the order that they will be tried when booting a node.
All devices in the bootlist will be tried in order until a device is found that has a bootable AIX image.
SMIT
System Management Interface Tool, a part of AIX that provides a textual or graphical full screen interface for the system administrator to perform administrative tasks, such as setting hostnames or IP addresses, modifying device information, etc.
Control Workstation An RS/6000 workstation that provides a central point for system administration for many SP
functions. The control workstation is not an SP node; it connects to the SP
nodes via an ethernet LAN.
node list A list of a group of nodes.
IS
Using the above definitions, and to briefly summarize, the present invention comprises a method and system for centrally administering (preferably in parallel) alternate and/or mirrored volume groups of one or more nodes of a distributed data processing system.
The approach is implemented in one example by building upon existing AIX and PSSP operations.
The invention provides:
- a new data class in the SDR to retain information about volume groups;
- a set of commands to initiate and discontinue mirroring on a nodal volume group;
- a method to designate an alternate volume group for remote installation on a node;
- an interface to add/delete/modify or display information about nodal volume groups; and - a method of setting the bootlist correctly to provide for automatic failover to a backup physical volume on a node.
With central administration from the SP control workstation in accordance with this invention, a customer can invoke a new series of SMIT panels to input information about the mirroring or alternate volume groups of a node. This information will be stored in the existing Node object and a new object, labeled herein the "Volume Group object", held in the SDR. There will also be a command to display information about the known volume groups of a node. Once the information about mirroring and alternate volume groups is entered in the SDR, a customer can initiate mirroring in one of several ways, e.g., by installing the node, by rebooting the node, or by invoking a new mirroring script described hereinbelow. The customer can also designate in accordance with this invention, an alternate volume to be installed. Based on SDR data, the node can then determine which volume group is the boot volume group.
Fig. l is a schematic diagram of a distributed computer system 100 useable with the present invention. The distributed computer system 100 may be an IBM RISC System/6000 Scalable POWERparallel Systems (SP) distributed computer system available from International Business Machines Corporation of Armonk, New York. The embodiment disclosed in Fig. 1 is an SP
computer having a total of 8 frames, with each frame having up to 16 nodes, for a total of 128 nodes.
All of the nodes 106 are joined by a local area network (LAN) 102. Each node 106 is a computer itself, and may be a RISC System/6000 workstation, as is well-known by those skilled in the art.
All of the nodes in a frame of the SP computer 100 are included in a LAN
segment which is joined by the other LAN segments through LAN gates 104. Also connected to the LAN 102, is a control workstation (CWS) 112 which controls operation of the SP computer 100. The control workstation has a direct access storage device (DASD) 114 referred to as the System Shared Disk on which is stored the system data repository (SDR) files. The SDR files include such information as a list of nodes that are in the system and their configuration, and includes resources and object definitions for each of the nodes 106. Each node 106 also includes a DASD
device 107 for storing data processed by the SP computer 100.
In one embodiment, the nodes in each frame are also connected to an IBM
Scalable POWERparallel switch (SPS) 105. Each of the SPS switches 105 of each frame is connected to neighboring SPS switches 105 of other frames by a bus 110.
As is well understood in the art, the CWS node 112 sends system data and control signals to the frames of the SP computer 100 by means of the LAN 102 while messages and data may be sent from one to another of the nodes 106 by means of the high performance switches 105.
Fig. 2 is a portion of the system 100 of Fig. 1. The control workstation 112 provides a single point of control wherein the control workstation provides the interfaces to create, delete or update Volume Group objects contained in the SDR 114. The control workstation centrally administers the mirroring, unmirroring and bootless commands to nodes 1, 2, 3...N, (i.e., 201, 202, 203...204, respectively). It will be understood that each type of new operation described herein (e.g., make, delete or change a Volume Group object) is issued on the control workstation, and that the necessary data is stored in the SDR 114. It should also be understood that the number of nodes, which may be referred to as the targets or target nodes by the control workstation, may be varied to one or more as desired by the system administrator (i.e., user).
In PSSP, there is a class in the SDR called the "node class" which contains information specific to individual SP nodes. This invention provides a new class called the "volume_group class", which contains information about the volume groups of each node.
Further, the node class is expanded to have a new attribute, the selected vg attribute, which points to a selected volume group of the volume-group class. Each Volume Group object is unique by node, and vg name.
Each Volume Group object has a set of attributes which describe a volume group. The volume_group attributes, their initial and legal values, as well as data types are described in Table 1.
Table 1: SDR Volume Group Class Description Attribute Type Name Description Values node number I node number for Volume Group an integer representing a node number vg name S customer supplied volume group customer supplied, a convenient name handle for reference, initially "rootvg"
pv_list S a list of physical volumes. Valid initially "hdisk0"
formats are: hdisk,hdisk,...hdisk connwhere,connwhere,...
connwhere location:location:...location rvg S is this volume group a root initially "true"
volume group? true/false NOTE: rvg is always true for a current release of PSSP
quorum S is quorum on for this volume initially "true"
group? true/false copies I number of copies for the volume initially 1 group. Valid are 1 or 2 or 3 mapping S Is mapping on? true/false initially "false".
NOTE:
mapping is always false for this release of PSSP
install_imageS mksysb image name to install "default"
next code versionS PSSP code version to use for derived from Syspar next install Ippsource S name of the lppsource name resource "default"
to use for next install boot server S node number of boot/install default depending on node server location last_installS a date string of time when the node initial was last installed last_install_imageS a string of the last image initial installed on the node last bootdiskS The logical device name of the initial last volume the i ~ node booted rrcrm Each Volume Group object describes a volume group of the node; and collectively the Volume Group objects of a node define all possible volume group states of the node. The Node object attribute, the selected vg, points to an object in the Volume Group class. The selected Volume Group object designates a volume group for subsequent commands.
Prior to this invention, certain of the attributes associated with the Volume Group object were associated with the Node object, since nodes had only one root volume group. With this invention, these attributes were moved to the Volume Group object, and this allows the data to represent multiple volume groups per node.
The following is a list of new commands pursuant to the present invention.
Note: the o notation indicates a value to be filled in by the user.
spmkvgobj -r <vg name>
-1 mode list>
-h <pv list>
-i <install image>
-v <lppsource_name>
-p <code_version>
-n <boot server>
-c < copies >
-q < quorum >
The "spmkvgobj" command is used to create a Volume Group object.
splstdata -v <vg name>
-1 mode list>
The "splstdata" command is used to list information about a Volume Group object.
sprmvgobj -r <vg name>
-1 mode list>
The "sprmvgobj" command is used to remove a Volume Group object.
spchvgobj -r <vg name>
-1 mode list>
-h <pv_list>
-i <install image>
-v <lppsource_name>
-p <code_version>
-n <boot server>
-c < copies >
-q < quorum >
The "spchvgobj" command is used to change information associated with the current Volume Group object.
spmirrorvg -1 mode list>
The "spmirrorvg" command is used to initiate mirroring of Volume Groups on a node or group of nodes. The command runs remotely, and places the process in the background, allowing for parallel execution.
spunmirrorvg -1 mode list>
The "spunmirrovg" command is used to halt mirroring on the current volume groups for a group of nodes. The command runs remotely and places the process in the background, allowing for parallel execution.
spbootins -c <selected Volume Group>
-1 mode list>
The "spbootins" command sets the current Volume Group object name for a node or group of nodes. The command does other things that are not relevant to this design, and not mentioned here.
spbootlist -1 mode list>
This command is used to set the bootlist on a node or group of nodes based on the combination of the mirroring and alternate volume group information for the node. If mirroring is off, the bootlist is set to a single physical volume. If mirroring is on, the bootlist is set to a list of physical volumes that provide redundant boot backups.
Fig. 3 is a flow diagram of one embodiment of mirroring 300 in accordance with the present invention. This mirroring routine ("spmirrorvg") runs on the control workstation to check the state of the SDR and the ability of the CWS to communicate with each node, for example, nodes 1, 2, 3 & N of Fig. 2. If the routine is unable to verify it is running on the control workstation or cannot read the SDR 301, then the mirroring process is exited with an error message 302. Otherwise, a sub-process is entered for each node specified in the system 303. Within this sub-routine, processing first determines whether the node number and Volume Group object are valid for the particular node 304. If "no", mirroring at that node is skipped 305. If the node number and Volume Group objects are valid, then processing determines whether the control workstation is in communication with the node 306. Again, if "no", the node is skipped 307. After establishing that the control workstation is in communication with the node, processing runs the command "spmirror"
(Fig. 4) remotely on the node 308. Ifthe control workstation is unable to run the command, then the node is skipped 309.
The outlined sub-process preferably proceeds in parallel for each node in the distributed system. Once the processing has completed mirroring for all designated nodes 310, the mirror operation is exited with an appropriate code and message 311. Note that the "spmirrorvg" routine 300 of Fig. 3 is a script which calls routine 400 (i.e., "spmirror") of Fig. 4 and reports any errors in mirroring back to the system administrator.
Fig. 4 illustrates the lower level mirroring program, "spmirror", employed by inquiry 308 of Fig. 3. "Spmirror" checks to see if mirroring is already in the desired state on the node and proceeds if the number of copies requested by the user in the SDR is unfulfilled, i.e., are the number of copies of the root volume group greater than or equal to the number of copies requested by the user? 401. If "yes", extend the volume group by any new physical volumes in the pv list 413, after which processing exits the routine since the number of mirrored copies of the volume group already exists 402. If there are additional physical volumes to be placed in the volume group, the volume group is extended to include them 403. If processing is unable to extend the root volume group by the physical volumes in the pv list, an error has occurred and processing is exited 404.
The AIX mirroring command "mirrorvg" is then called to initiate mirroring of the volume group at the node 405. The "mirrorvg" AIX command (as well as the other AIX
commands referenced herein) is described, for example, in an IBM publication entitled "AIX Version 4.3 Commands Reference", Volumes 1-6, First Edition October 1997. If mirroring is unable to be initiated, processing exits with an error 406. After mirroring, the AIX
commands "bosboot" 407 and "bootlist" 409 are called to make the new mirrored disk bootable, and to set the order of booting on the node to include the new mirrored disk. If either the "bosboot" or "bootlist" AIX commands are not properly performed, processing exits 408 & 410, respectively. If the state of quorum changed on the node, a message is sent to the user to reboot the node 411, thus successfully completing the mirroring process 412.
Fig. 5 illustrates one embodiment of unmirroring processing 500 in accordance with the present invention. This unmirroring process 500 is implemented on the control workstation, and begins by checking the state of the SDR and the ability of the control workstation to communicate with the SDR 501. If either inquiry fails, then the unmirroring process is exited with an error message 502. Assuming that the unmirroring routine is running on the control workstation and the control workstation can read the SDR, then a parallel implemented sub-routine is entered 503 which is performed for each designated node of the distributed system. Processing initially determines whether the node number and Volume Group objects are valid 504. If "no", then the node is skipped 505. Next, the unmirroring process determines whether the control workstation can communicate with the given node 506, and if "no", processing at that node is skipped 507.
Assuming that communication is established, the command "spunmirror" (Fig. 6) is run on the node remotely 508. If the command is unable to be processed, the node is skipped 509. After completing the designated processing for each selected node of the distributed system 510, preferably in parallel, the unmirroring process is exited with an appropriate code and message 511.
Note that the "spunmirrorvg" routine 500 is a script which calls the command "spunmirror"
600 depicted in Fig.
6 and reports any errors in unmirroring back to the user.
As noted, the lower level unmirroring process "spunmirror" is depicted in Fig.
6, which is an expansion of block 508 of Fig. 5. Spunmirror initially checks to see if mirroring is already in the desired state on the node, and proceeds if the reduced number of copies requested by the user in the SDR is unfulfilled 601. If the reduced number of copies of the volume groups already exists, "spunmirror" reduces the volume group if any physical volumes have been removed from the pv_list 613, and then processing is terminated 602. Otherwise, the AIX unmirroring command "unmirrorvg" is called 603. The command "unmirrorvg" is part of the AIX
operating system and is discussed in the above-mentioned IBM publication. If unmirroring cannot be initiated, processing is exited 604. After unmirroring, if there are any physical volumes in the volume group that need to be taken out, the AIX command "reducevg" is run to reduce the volume group and make the physical volumes available for another use 605. If the root volume group cannot be reduced, error is indicated 606. After unmirroring, the AIX commands "bosboot" 607 and "bootlist" 609 are called for updating of the node information to reflect the disks which have been removed from the volume group. If either the "bosboot" or "bootlist" AIX commands are not properly performed, processing exits 608 & 610, respectively. Finally, if the state of quorum has changed on the node, a message is sent to the user to reboot the node 611, thus successfully completing the unmirroring process 612.
Fig. 7 is a flow diagram of user initiated processings 700 for making, changing or removing a Volume Group object in accordance with the present invention. Three new commands are provided herein, i.e., "spmkvgobj" 701, "spchvgobj" 702, and "sprmvgobj" 703.
Each of these commands interacts with information in the SDR 114. The "spmkvgobj" command is used to create a new Volume Group object, the "spchvgobj" command is employed to modify an existing Volume Group object, and the "sprmvgobj" command is used to remove an existing Volume Group object from the repository 114. Again, these Volume Group objects represent the information used by other commands described herein, such as "spmirrorvg" and "spunmirrorvg"
when initiating or P09-98-058 1 g discontinuing mirroring on a target node. Processing pursuant to the "spmkvgobj", "spchvgobj", and "sprmvgobj" commands is presented in greater detail in Figs. 8, 9 & 10, respectively.
Fig. 8 is a flow diagram of the user-initiated process 800 for making a Volume Group obj ect in accordance with the present invention. This process is initiated by invoking the "spmkvgobj"
command to create a new Volume Group object. Processing begins by checking the input parameters to make sure that "spmkvgobj" is running on the control workstation and that the control workstation can read the system repository 801. If "no", processing is terminated with an error message 802. Assuming that the program is running on the control workstation and the control workstation is in communication with the SDR, processing determines whether the user-inputted parameters are valid 803. If "no", processing terminates 804. Next, processing determines whether the Volume Group object to be created already exists for the particular node 805. If the Volume Group object already exists, processing exits with an error message 806. Thereafter, the routine creates the new Volume Group object and updates the SDR 807. If an error occurs during updating of the SDR, processing exits with an appropriate error code and message 808. Otherwise, the Volume Group object has been successfully created and processing ends 809.
Processing 900 for changing a Volume Group object is depicted in Fig. 9.
Again, this comprises a user-invoked command, "spchvgobj" to change an existing Volume Group object.
Processing begins by confirming that the command is running on the control workstation and that the control workstation can read the shared system repository 901. If "no", an appropriate error message is sent 902. Otherwise, the input parameters received from the user are checked to make sure that the parameters are valid 903. If "no", then processing ends with an error message 904.
Assuming that the parameters are valid, processing determines whether the Volume Group object that is about to change already exists for this node 905. If not, an error message is sent 906.
Assuming that the desired Volume Group object exists for the node, then processing changes the Volume Group object according to the user-specified parameters 907. If the updating of the SDR
with the changed volume group information fails, processing exits with an appropriate error message 908. Otherwise, the update processing of the Volume Group object's information is successfully completed 909.
Fig. 10 presents a flow diagram of processing 1000 in accordance with a user-invoking the "sprmvgobj" command of the present invention to delete an existing Volume Group object. The input parameters are initially checked to make sure that the command is running on the control workstation and that the program can read the SDR 1001. If "no", processing terminates with an error message 1002. Next, processing checks to make sure that all user parameters are valid 1003, and if not, issues an error message 1004. Assuming that the user parameters are valid, processing determines whether the Volume Group object to be removed exists for this node 1005, and if "no", processing terminates with an error message 1006. Assuming that the Volume Group object exists, then processing removes the object by the specified name for this particular node number 1007. If the Volume Group object is unable to be removed, an error message occurs during the removal process 1008. Upon removal of the object, processing terminates 1009.
Several examples of volume_group processing in accordance with the present invention are described below.
Initialization When PSSP is installed on the control workstation, the Node class and Volume Group class are created. One Node object and one Volume Group object are created per node detected. The "selected vg" (i.e., current volume group) attribute of the Node obj ect is set to "rootvg", to designate the Root Volume Group. The Volume Group Object that is created for each node has by default a "vg name" (i.e., volume group name) of "rootvg". All the other Volume Group attributes are initialized to default values, which indicate that "hdisk0" is the installation disk, and that mirroring is initially turned off for the volume group, i.e., the number of copies for the Volume Group object is set to 1. See Table 1.
Example 1: Mirroring a volume group at install time.
Initialization is performed as above.
Prior to installing a node, the user executes the "spchvgobj" command to set the pv list to the list of the physical volumes the user wants in the root volume group, and sets the number of mirrored copies to 2 or 3 (in this example). The user could list the information prior to installing the node using the "splstdata" command.
The user installs the node using standard PSSP procedures. When the node first boots, the "spmirrorvg" command is executed on the node to initiate mirroring.
On subsequent reboots of the node, the node writes information to the last bootdisk attribute of the Volume Group object. If this last bootdisk attribute does not match the expected boot disk for the node, the user could detect that a disk has failed and that a mirrored image has become the boot image.
The "last bootdisk" is a new attribute that is part of the Volume Group object in accordance with the present invention. This new attribute tells the user which physical volume the node booted from. In a mirrored environment, if the value of the last bootdisk changes, there must be a problem with a mirror of the root volume group, and this should alert the customer to a problem. The last bootdisk is set whenever the node is booted, for example, by a program named_ "psspfb-script", which is an existing PSSP program not part of this disclosure.
Example 2: Mirroring a volume group post installation.
Initialization is performed as above.
To begin mirroring a volume group on a node, the user first designates the name of the mirror using the "spchvgobj" command, to set the pv_list to the names) of the physical volumes) in the root volume group and sets the "copies" attribute to 2 or 3 (again by way of example).
To initiate mirroring, the user executes the "spmirrorvg" command, which executes a remote script to initiate mirroring on the node. Any error conditions that occur during mirroring are preferably displayed at the user's display console.
If multiple nodes have mirrors designated in their Volume Group obj ects, and if "spmirrovg"
is run with the names of many nodes, "spmirrorvg" will run across the nodes in parallel by starting background processes on every node. Again, information will come back from each process to the user's display console. Information from each process can be distinguished by a prefix to each line of output (standard PSSP code does this).
Example 3: Installing and selectine an alternate volume rout Initialization of the data is performed as above.
By default, the volume group to be installed and booted from is the Volume Group object with the name "rootvg", which is set during initialization of the data objects. To install and boot from an alternate volume group, the user first creates the alternate volume group in the SDR. To do this, the user executes the "spmkvgobj" command, filling in all the attributes that define the volume group. Note that the user can set AIX levels and PSSP levels to other than the values set for "rootvg".
With the alternate Volume Group object defined, the user executes the "spbootins" command to designate the new volume group as the current volume group for the node.
Using standard PSSP
procedures to install the node, the node installs using the alternate volume group instead of the default volume group "rootvg". If in this example the user wishes to boot from the original "rootvg"
volume group, the "selected vg" attribute of the Node object is set to "rootvg" via the "spbootins"
command. The user then executes the "spbootlist" command to set the bootlist on the node to reflect booting from "rootvg". Using standard AIX and PSSP procedures the user then reboots the node, and it would boot from the "rootvg" volume group.
The present invention can be included, for example, in an article of manufacture (e.g., one or more computer program products) having, for instance, computer usable media. This media has embodied therein, for instance, computer readable program code means for providing and facilitating the capabilities of the present invention. The articles of manufacture can be included as part of the computer system or sold separately.
Additionally, at least one program storage device readable by machine, tangibly embodying at least one program of instructions executable by the machine, to perform the capabilities of the present invention, can be provided.
The flow diagrams depicted herein are provided by way of example. There may be variations to these diagrams or the steps (or operations) described herein without departing from the spirit of the invention. For instance, in certain cases, the steps may be performed in differing order, or steps may be added, deleted or modified. All of these variations are considered to comprise part of the present invention as recited in the appended claims.
While the invention has been described in detail herein in accordance with certain preferred embodiments thereof, many modifications and changes therein may be effected by those skilled in the art. Accordingly, it is intended by the appended claims to cover all such modifications and changes as fall within the true spirit and scope of the invention.
Claims (58)
1. In a distributed processing system having multiple processors, one processor being designated a control node and one or more other processors each being designated a target node, a method of administering at least one of a mirrored volume group or an alternate volume group on at least one target node, said method comprising:
storing information in a Node object and Volume_Group object in a system data repository (SDR) coupled to the control node, said Node object and said Volume_Group object providing information on each volume group of the at least one target node in the distributed processing system; and performing at the at least one target node at least one of mirroring of a volume group or designating an alternate volume group, said performing being initiated at said control node remote from said at least one target node.
storing information in a Node object and Volume_Group object in a system data repository (SDR) coupled to the control node, said Node object and said Volume_Group object providing information on each volume group of the at least one target node in the distributed processing system; and performing at the at least one target node at least one of mirroring of a volume group or designating an alternate volume group, said performing being initiated at said control node remote from said at least one target node.
2. The method of claim 1, wherein multiple other processors are designated target nodes and said at least one target node comprises a plurality of target nodes, said performing comprising performing mirroring of a volume group or designating an alternate volume group for each node of said plurality of target nodes of the distributed processing system, and wherein said method comprises initiating said performing in parallel for said plurality of target nodes.
3. The method of claim 1 or claim 2, further comprising performing at least one of adding, deleting, modifying, or displaying information in said SDR about at least one volume group of at least one target node of the distributed processing system.
4. The method of claim 3, wherein said performing at least one of adding, deleting, modifying, or displaying information in said SDR comprises performing at least one of adding, deleting, modifying, or displaying said Volume_Group object information for said at least one volume group of said at least one target node of the distributed processing system.
5. The method of claim 3 or claim 4, wherein said performing comprises making a new Volume_Group object, wherein said making comprises receiving user-defined parameters for the new Volume_Group object, determining that said user-defined parameters comprise a new, unique Volume_Group object, and updating said SDR with the new Volume_Group object.
6. The method of any one of claims 3 to 5, wherein said performing comprises changing said Volume_Group object information of said at least one volume group of said at least one target node, said changing including receiving user-defined parameters for said Volume_Group object, determining that said Volume_Group object exists by a user-defined name for said at least one target node, and updating said SDR with changed volume group information for said at least one target node.
7. The method of any one of claims 3 to 6, wherein said performing comprises removing Volume_Group object information of said at least one target node, said removing comprising receiving valid user-defined parameters for said removing, determining that said Volume_Group object exists for said at least one target node, and thereafter, removing the Volume_Group object information specified in the user-defined parameters from the SDR.
8. The method of any one of claims 3 to 7, further comprising providing an interface to allow a system administrator to control said performing at least one of adding, deleting, modifying, or displaying information in said SDR about said at least one volume group of said at least one target node of the distributed processing system.
9. The method of claim 1, wherein multiple other processors are designated target nodes and said at least one target node comprises a plurality of target nodes, and said method comprises administering multiple mirrored volume groups on said plurality of target nodes of said distributed processing system, wherein said performing comprises performing at least one of mirroring of a volume group or unmirroring of a volume group for each of multiple volume groups of said plurality of target nodes of the distributed processing system, said performing being initiated in parallel at said control node remote from said plurality of target nodes.
10. The method of claim 1, wherein said performing comprises performing mirroring of said volume group of said at least one target node of the distributed processing system, said performing being initiated at said control node remote from said at least one target node, wherein said mirroring comprises for each target node:
determining that said Node object and said Volume_Group object are valid for mirroring;
confirming that the control node is in communication with said at least one target node; and initiating mirroring of said volume group from said control node remotely from said at least one target node.
determining that said Node object and said Volume_Group object are valid for mirroring;
confirming that the control node is in communication with said at least one target node; and initiating mirroring of said volume group from said control node remotely from said at least one target node.
11. The method of claim 10, wherein said initiating mirroring from said control node remotely on said at least one target node comprises for each target node:
determining that less than a desired number of root volume groups reside on the target node;
extending the root volume group by a physical volume of the target node;
initiating mirroring of the root volume group at the target node to produce a mirrored root volume group;
creating a new bootable physical volume for the target node from the mirrored root volume group;
including all bootable disks in the mirrored root volume group; and if state of quorum has changed due to mirroring, issuing a message to reboot the target node to reflect the quorum change.
determining that less than a desired number of root volume groups reside on the target node;
extending the root volume group by a physical volume of the target node;
initiating mirroring of the root volume group at the target node to produce a mirrored root volume group;
creating a new bootable physical volume for the target node from the mirrored root volume group;
including all bootable disks in the mirrored root volume group; and if state of quorum has changed due to mirroring, issuing a message to reboot the target node to reflect the quorum change.
12. The method of claim 1, wherein said performing comprises performing unmirroring of said volume group of said at least one target node of the distributed processing system, said unmirroring comprising for each target node:
determining that the Node object and Volume_Group object are valid for unmirroring;
confirming that the control node is in communication with said at least one target node; and initiating unmirroring of said volume group from said control node remotely from said at least one target node.
determining that the Node object and Volume_Group object are valid for unmirroring;
confirming that the control node is in communication with said at least one target node; and initiating unmirroring of said volume group from said control node remotely from said at least one target node.
13. The method of claim 12, wherein said initiating unmirroring of said volume group on said at least one target node remotely from said control node comprises:
confirming that an actual number of root volume group copies is greater than a number of copies requested;
initiating unmirroring on the at least one target node;
reducing the root volume group if any physical volumes have been removed from the at least one target node;
creating a new bootable physical volume on the at least one target node if the root volume group has been reduced;
revising the bootlist on the at least one target node to include all bootable disks of the unmirrored root volume group; and if state of quorum has changed due to unmirroring, issuing a message to reboot the at least one target node to reflect said quorum change.
confirming that an actual number of root volume group copies is greater than a number of copies requested;
initiating unmirroring on the at least one target node;
reducing the root volume group if any physical volumes have been removed from the at least one target node;
creating a new bootable physical volume on the at least one target node if the root volume group has been reduced;
revising the bootlist on the at least one target node to include all bootable disks of the unmirrored root volume group; and if state of quorum has changed due to unmirroring, issuing a message to reboot the at least one target node to reflect said quorum change.
14. The method of claim 1, wherein said performing comprises designating said alternate volume group of said at least one target node of the distributed processing system, said designating comprising:
designating said alternate volume group within said SDR for installation on said at least one target node; and invoking commands to install said alternate volume group on said at least one target node based on SDR data for said at least one target node.
designating said alternate volume group within said SDR for installation on said at least one target node; and invoking commands to install said alternate volume group on said at least one target node based on SDR data for said at least one target node.
15. The method of claim 1, further comprising setting a bootlist on said at least one target node based on said performing at least one of mirroring of said volume group or designating an alternate volume group for said at least one target node, wherein if mirroring for said at least one target node is off, said bootlist is set to a single physical volume, and if mirroring for said at least one target node is on, said bootlist is set to a list of physical volumes that provide redundant boot backups.
16. The method of claim 1, wherein said storing information comprises creating said Node object and said Volume_Group object in said SDR, said creating comprising initially providing one Node object and one Volume_Group object per target node of said distributed processing system.
17. The method of claim 16, wherein said creating further comprises setting a selected_vg attribute of the Node object to "rootvg" to designate a root volume group and providing said Volume_Group object with a default name of "rootvg".
18. The method of claim 17, wherein said performing comprises initiating mirroring of said root volume group of said at least one target node.
19. In a distributed processing system having multiple processors, one processor being designated a control node and one or more other processors being designated a target node, a method of administering a volume group on at least one target node, said method comprising:
storing information in a Node object and Volume_Group object in a system data repository (SDR) coupled to the control node, said Node object and said Volume_Group object providing information on each volume group of the at least one target node in the distributed processing system; and performing at least one of adding, deleting, modifying, or displaying information about at least one volume group of said at least one target node of the distributed processing system using at least one of said Node object and said Volume_Group object in said SDR.
storing information in a Node object and Volume_Group object in a system data repository (SDR) coupled to the control node, said Node object and said Volume_Group object providing information on each volume group of the at least one target node in the distributed processing system; and performing at least one of adding, deleting, modifying, or displaying information about at least one volume group of said at least one target node of the distributed processing system using at least one of said Node object and said Volume_Group object in said SDR.
20. The method of claim 19, wherein said performing at least one of adding, deleting, modifying, or displaying information comprises performing at least one of adding, deleting, modifying, or displaying said volume_group information for said at least one volume group of said at least one target node of the distributed processing system.
21. The method of claim 19 or claim 20, further comprising providing an interface to allow a user to control said performing at least one of adding, deleting, modifying, or displaying information about said at least one volume group of said at least one target node of the distributed processing system.
22. The method of any one of claims 19 to 21, wherein said performing comprises making a new Volume_Group object, wherein said making comprises receiving user-defined parameters for the new Volume_Group object, determining that said user-defined parameters comprise a new, unique Volume_Group object, and updating the SDR with the new Volume_Group object.
23. The method of any one of claims 19 to 22, wherein said performing comprises changing said Volume_Group object information of said at least one volume group of said at least one target node, said changing including receiving user-defined parameters for said Volume_Group object, determining that said Volume_Group object exists for said at least one target node, and updating the SDR with changed volume group information for said at least one target node.
24. The method of any one of claims 19 to 23, wherein said performing comprises removing Volume_Group object information for said at least one volume group of said at least one target node, said removing comprising receiving valid user-defined parameters for said removing, determining that said Volume_Group object exists for said at least one target node, and thereafter, removing the Volume_Group object information specified in the user-defined parameters from the SDR.
25. A program storage device readable by a machine, tangibly embodying at least one program of instructions executable by the machine, to perform the method steps of any one of claims 1 to 24.
26. A distributed processing system comprising:
multiple processors, one processor being designated a control node and one or more other processors each being designated a target node;
a system data repository (SDR) coupled to said control node;
means for administering at least one of a mirrored volume group or an alternate volume group of at least one target node from said control node, said means for administering comprising:
(i) means for storing information in a Node object and a Volume_Group object in said SDR, said Node object and said Volume_Group object providing information on each volume group of the at least one target node in the distributed processing system; and (ii) means for performing at the at least one target node at least one of mirroring of a volume group or designating an alternate volume group, said means for performing being initiated at said control node remote from said at least one target node.
multiple processors, one processor being designated a control node and one or more other processors each being designated a target node;
a system data repository (SDR) coupled to said control node;
means for administering at least one of a mirrored volume group or an alternate volume group of at least one target node from said control node, said means for administering comprising:
(i) means for storing information in a Node object and a Volume_Group object in said SDR, said Node object and said Volume_Group object providing information on each volume group of the at least one target node in the distributed processing system; and (ii) means for performing at the at least one target node at least one of mirroring of a volume group or designating an alternate volume group, said means for performing being initiated at said control node remote from said at least one target node.
27. The system of claim 26, wherein multiple other processors of said multiple processors are designated target nodes and said at least one target node comprises a plurality of target nodes, and said means for performing comprises means for initiating mirroring of a volume group or designating an alternate volume group of each node in parallel for said plurality of target nodes of the distributed processing system.
28. The system of claim 26 or claim 27, further comprising means for performing at least one of adding, deleting, modifying, or displaying information in the SDR about at least one volume group of the at least one target node of the distributed processing system.
29. The system of claim 28, wherein said means for performing comprises means for making a new Volume_Group object, and wherein said means for making comprises means for receiving user-defined parameters for the new Volume_Group object, means for determining that said user-defined parameters comprise a new, unique Volume_Group object, and means for updating 26. A distributed processing system comprising:
multiple processors, one processor being designated a control node and one or more other processors each being designated a target node;
a system data repository (SDR) coupled to said control node;
means for administering at least one of a mirrored volume group or an alternate volume group of at least one target node from said control node, said means for administering comprising:
(i) means for storing information in a Node object and a Volume_Group object in said SDR, said Node object and said Volume_Group object providing information on each volume group of the at least one target node in the distributed processing system; and (ii) means for performing at the at least one target node at least one of mirroring of a volume group or designating an alternate volume group, said means for performing being initiated at said control node remote from said at least one target node.
27. The system of claim 26, wherein multiple other processors of said multiple processors are designated target nodes and said at least one target node comprises a plurality of target nodes, and said means for performing comprises means for initiating mirroring of a volume group or designating an alternate volume group of each node in parallel for said plurality of target nodes of the distributed processing system.
28. The system of claim 26 or claim 27, further comprising means for performing at least one of adding, deleting, modifying, or displaying information in the SDR about at least one volume group of the at least one target node of the distributed processing system.
29. The system of claim 28, wherein said means for performing comprises means for making a new Volume_Group object, and wherein said means for making comprises means for receiving user-defined parameters for the new Volume_Group object, means for determining that said user-defined parameters comprise a new, unique Volume_Group object, and means for updating the SDR with the new Volume_Group object.
the SDR with the new Volume_Group object.
multiple processors, one processor being designated a control node and one or more other processors each being designated a target node;
a system data repository (SDR) coupled to said control node;
means for administering at least one of a mirrored volume group or an alternate volume group of at least one target node from said control node, said means for administering comprising:
(i) means for storing information in a Node object and a Volume_Group object in said SDR, said Node object and said Volume_Group object providing information on each volume group of the at least one target node in the distributed processing system; and (ii) means for performing at the at least one target node at least one of mirroring of a volume group or designating an alternate volume group, said means for performing being initiated at said control node remote from said at least one target node.
27. The system of claim 26, wherein multiple other processors of said multiple processors are designated target nodes and said at least one target node comprises a plurality of target nodes, and said means for performing comprises means for initiating mirroring of a volume group or designating an alternate volume group of each node in parallel for said plurality of target nodes of the distributed processing system.
28. The system of claim 26 or claim 27, further comprising means for performing at least one of adding, deleting, modifying, or displaying information in the SDR about at least one volume group of the at least one target node of the distributed processing system.
29. The system of claim 28, wherein said means for performing comprises means for making a new Volume_Group object, and wherein said means for making comprises means for receiving user-defined parameters for the new Volume_Group object, means for determining that said user-defined parameters comprise a new, unique Volume_Group object, and means for updating the SDR with the new Volume_Group object.
the SDR with the new Volume_Group object.
30. The system of claim 28 or claim 29, wherein said means for performing comprises means for changing said Volume_Group object information of said at least one volume group of said at least one target node, said means for changing including means for receiving user-defined parameters for said Volume_Group object, means for determining that said Volume_Group object exists for said at least one target node, and means for updating the SDR with changed volume group information for said at least one target node.
31. The system of any one of claims 28 to 30, wherein said means for performing comprises means for removing Volume_Group object information for said at least one volume group of said at least one target node, said means for removing comprising means for receiving valid user-defined parameters for said removing, means for determining that said Volume_Group object exists within said at least one target node and means for removing the Volume_Group object information specified in the user-defined parameters from the SDR.
32. The system of claim 26, wherein said means for performing comprises means for mirroring said volume group of said at least one target node of the distributed processing system, said means for mirroring being initiated at said control node remote from said at least one target node, wherein said means for mirroring comprises for each target node:
means for determining that said Node object and said Volume_Group object are valid for mirroring;
means for confirming that the control node is in communication with said at least one target node; and means for initiating mirroring of said volume group on said at least one target node from said control node.
means for determining that said Node object and said Volume_Group object are valid for mirroring;
means for confirming that the control node is in communication with said at least one target node; and means for initiating mirroring of said volume group on said at least one target node from said control node.
33. The system of claim 26, wherein said means for performing comprises means for unmirroring said volume group of said at least one target node of the distributed processing system, said means for unmirroring comprising for each target node:
means for determining that the Node object and the Volume_Group object are valid for unmirroring;
means for confirming that the control node is in communication with said at least one target node; and means for initiating unmirroring of said volume group on said at least one target node remotely from said control node.
means for determining that the Node object and the Volume_Group object are valid for unmirroring;
means for confirming that the control node is in communication with said at least one target node; and means for initiating unmirroring of said volume group on said at least one target node remotely from said control node.
34. The system of claim 26, wherein said means for performing comprises means for performing designating of said alternate volume group of said at least one target node of the distributed processing system, said means for performing comprising:
means for designating said alternate volume group within said SDR for installation on said at least one target node; and means for invoking commands to install said alternate volume group on said at least one target node based on SDR data for said at least one target node.
means for designating said alternate volume group within said SDR for installation on said at least one target node; and means for invoking commands to install said alternate volume group on said at least one target node based on SDR data for said at least one target node.
35. The system of claim 26, further comprising means for setting a bootlist on said at least one target node based on said means for performing at least one of mirroring of said volume group or designating an alternate volume group for said at least one target node, wherein if mirroring for said at least one target node is off, said bootlist is set to a single physical volume, and if mirroring for at least one said target node is on, said bootlist is set to a list of physical volumes that provide redundant boot backups.
36. The system of claim 26, wherein said means for storing information comprises means for creating said Node object and said Volume_Group object in said SDR, said means for creating comprising means for initially providing one Node object and one Volume_Group object per target node of said distributed processing system.
37. A distributed processing system comprising:
multiple processors, one processor being designated a control node and one or more other processors being designated a target node;
a system data repository (SDR) coupled to the control node;
means for administering a volume group on at least one target node, said means for administering comprising:
means for storing information in a Node object and Volume_Group object in said SDR, said Node object and said Volume_Group object providing information on each volume group of the at least one target node in the distributed processing system; and means for performing at least one of adding, deleting, modifying, or displaying information about at least one volume group of said at least one target node of the distributed processing system using at least one of said Node object and said Volume_Group object in said SDR.
multiple processors, one processor being designated a control node and one or more other processors being designated a target node;
a system data repository (SDR) coupled to the control node;
means for administering a volume group on at least one target node, said means for administering comprising:
means for storing information in a Node object and Volume_Group object in said SDR, said Node object and said Volume_Group object providing information on each volume group of the at least one target node in the distributed processing system; and means for performing at least one of adding, deleting, modifying, or displaying information about at least one volume group of said at least one target node of the distributed processing system using at least one of said Node object and said Volume_Group object in said SDR.
38. The system of claim 37, wherein said means for performing at least one of adding, deleting, modifying, or displaying information in said SDR comprises means for performing at least one of adding, deleting, modifying, or displaying said Volume_Group object information for said at least one volume group of said at least one target node of the distributed processing system.
39. The system of claim of 37 or claim 38, wherein said means for performing comprises an interface to allow a user to control said means for performing at least one of adding, deleting, modifying, or displaying information about said at least one volume group of said at least one target node of the distributed processing system.
40. A distributed processing system comprising:
multiple processors, one processor being designated a control node and one or more other processors each being designated a target node;
a system data repository (SDR) coupled to said control node;
wherein said control node is adapted to administer at least one of a mirrored volume group or an alternate volume group of at least one target node, said control node comprising:
(i) a storage controller adapted to store information in a Node object and a Volume_Group object in said SDR, said Node object and said Volume_Group object providing information on each volume group of the at least one target node in the distributed processing system; and (ii) said storage controller being further adapted to perform at least one of mirroring of a volume group or designating an alternate volume group of the at least one target node of the distributed processing system, said performing being initiated at said control node remote from said at least one target node.
multiple processors, one processor being designated a control node and one or more other processors each being designated a target node;
a system data repository (SDR) coupled to said control node;
wherein said control node is adapted to administer at least one of a mirrored volume group or an alternate volume group of at least one target node, said control node comprising:
(i) a storage controller adapted to store information in a Node object and a Volume_Group object in said SDR, said Node object and said Volume_Group object providing information on each volume group of the at least one target node in the distributed processing system; and (ii) said storage controller being further adapted to perform at least one of mirroring of a volume group or designating an alternate volume group of the at least one target node of the distributed processing system, said performing being initiated at said control node remote from said at least one target node.
41. At least one computer readable medium for storing data usable by a storage controller coupled to a storage device of a distributed processing system, said at least one computer readable medium comprising:
a data structure stored within said at least one computer readable medium, said data structure comprising:
(i) Node object information usable by said storage controller in identifying at least one target node within the distributed processing system; and (ii) a Volume_Group object comprising information on at least one volume group of at least one target node in the distributed processing system, said Volume_Group object being usable by said storage controller in remotely administering volume groups of said at least one target node.
a data structure stored within said at least one computer readable medium, said data structure comprising:
(i) Node object information usable by said storage controller in identifying at least one target node within the distributed processing system; and (ii) a Volume_Group object comprising information on at least one volume group of at least one target node in the distributed processing system, said Volume_Group object being usable by said storage controller in remotely administering volume groups of said at least one target node.
42. At least one program storage device readable by a machine, tangibly embodying at least one program of instructions executable by the machine to perform a method for administering at least one of a mirrored volume group or an alternate volume group of at least one target node of a computer system, said computer system comprising a plurality of processors coupled to a storage controller, said storage controller coupled to said storage unit, said method comprising:
storing information in a Node object and Volume_Group object in said storage unit, said Node object and said Volume_Group object providing information on each volume group of the at least one target node in the computer system; and performing at least one of mirroring of a volume group or designating an alternate volume group of said at least one target node of the computer system, said performing being initiated by said storage controller remote from said at least one target node.
storing information in a Node object and Volume_Group object in said storage unit, said Node object and said Volume_Group object providing information on each volume group of the at least one target node in the computer system; and performing at least one of mirroring of a volume group or designating an alternate volume group of said at least one target node of the computer system, said performing being initiated by said storage controller remote from said at least one target node.
43. An article of manufacture, comprising:
at least one computer useable medium having computer readable program code means embodied therein for administering at least one of a mirrored volume group or an alternate volume group on at least one target node in a distributed processing system having a control node coupled to a system data repository (SDR), the computer readable program code means in the article of manufacture comprising:
(i) computer readable program code means for causing a computer to store information in a Node object and Volume_Group object in said SDR, said Node object in said Volume_Group object providing information on each volume group of the at least one target node in the distributed processing system; and (ii) computer readable program code means for causing a computer to perform at least one of mirroring of a volume group or designating an alternate volume group of said at least one target node of the distributed processing system, said performing being initiated at said control node remote from said at least one target node.
at least one computer useable medium having computer readable program code means embodied therein for administering at least one of a mirrored volume group or an alternate volume group on at least one target node in a distributed processing system having a control node coupled to a system data repository (SDR), the computer readable program code means in the article of manufacture comprising:
(i) computer readable program code means for causing a computer to store information in a Node object and Volume_Group object in said SDR, said Node object in said Volume_Group object providing information on each volume group of the at least one target node in the distributed processing system; and (ii) computer readable program code means for causing a computer to perform at least one of mirroring of a volume group or designating an alternate volume group of said at least one target node of the distributed processing system, said performing being initiated at said control node remote from said at least one target node.
44. The article of manufacture of claim 43, wherein multiple other processors are designated target nodes and said at least one target node comprises a plurality of target nodes, said computer readable program code means for causing a computer to perform comprising computer readable program code means for causing a computer to perform mirroring of a volume group or designating an alternate volume group for each node of said plurality of target nodes of the distributed processing system, and wherein said article of manufacture comprises computer readable program code means for causing a computer to initiate said performing in parallel for said plurality of target nodes.
45. The article of manufacture of claim 43, further comprising computer readable program code means for causing a computer to perform at least one of adding, deleting, modifying, or displaying information in said SDR about at least one volume group of at least one target node of the distributed processing system.
46. The article of manufacture of claim 45, wherein said computer readable program code means for causing a computer to perform at least one of adding, deleting, modifying, or displaying information in said SDR comprises computer readable program code means for causing a computer to perform at least one of adding, deleting, modifying, or displaying said Volume_Group object information for said at least one volume group of said at least one target node of the distributed processing system.
47. The article of manufacture of claim 46, wherein said computer readable program code means for causing a computer to perform comprises computer readable program code means for causing a computer to make a new Volume_Group object, wherein said making comprises receiving user-defined parameters for the new Volume_Group object, determining that said user-defined parameters comprise a new, unique Volume_Group object, and updating said SDR
with the new Volume_Group object.
with the new Volume_Group object.
48. The article of manufacture of claim 46, wherein said computer readable program code means for causing a computer to perform comprises computer readable program code means for causing a computer to change said Volume_Group object information of said at least one volume group of said at least one target node, said changing including receiving user-defined parameters for said Volume_Group object, determining that said Volume_Group object exists by a user-defined name for said at least one target node, and updating said SDR with changed volume group information for said at least one target node.
49. The article of manufacture of claim 46, wherein said computer readable program code means for causing a computer to perform comprises computer readable program code means for causing a computer to remove Volume_Group object information of said at least one target node, said removing comprising receiving valid user-defined parameters for said removing, determining that said Volume_Group object exists for said at least one target node, and thereafter, removing the Volume_Group object information specified in the user-defined parameters from the SDR.
50. The article of manufacture of claim 43, wherein said computer readable program code means for causing a computer to perform comprises computer readable program code means for causing a computer to perform mirroring of said volume group of said at least one target node of the distributed processing system, said performing being initiated at said control node remote from said at least one target node, wherein said mirroring comprises for each target node:
determining that said Node object and said Volume_Group object are valid for mirroring;
confirming that the control node is in communication with said at least one target node; and initiating mirroring of said volume group from said control node remotely from said at least one target node.
determining that said Node object and said Volume_Group object are valid for mirroring;
confirming that the control node is in communication with said at least one target node; and initiating mirroring of said volume group from said control node remotely from said at least one target node.
51. The article of manufacture of claim 43, wherein said computer readable program code means for causing a computer to perform comprises computer readable program code means for causing a computer to perform unmirroring of said volume group of said at least one target node of the distributed processing system, said unmirroring comprising for each target node:
determining that the Node object and Volume_Group object are valid for unmirroring;
confirming that the control node is in communication with said at least one target node; and initiating unmirroring of said volume group from said control node remotely from said at least one target node.
determining that the Node object and Volume_Group object are valid for unmirroring;
confirming that the control node is in communication with said at least one target node; and initiating unmirroring of said volume group from said control node remotely from said at least one target node.
52. The article of manufacture of claim 43, wherein said computer readable program code means for causing a computer to perform comprises computer readable program code means for causing a computer to designate said alternate volume group of said at least one target node of the distributed processing system, said designating comprising:
designating said alternate volume group within said SDR for installation on said at least one target node; and invoking commands to install said alternate volume group on said at least one target node based on SDR data for said at least one target node.
designating said alternate volume group within said SDR for installation on said at least one target node; and invoking commands to install said alternate volume group on said at least one target node based on SDR data for said at least one target node.
53. An article of manufacture, comprising:
at least one computer usable medium having computer readable program code means embodied therein for administering a volume group on at least one target node of a distributed processing system having multiple processors, one processor being designated a control node and one or more other processors being designated a target node, said control node being coupled to a system data repository (SDR), the computer readable program code means in the article of manufacture comprising:
(i) computer readable program code means for causing a computer to store information in a Node object and a Volume_Group object in said SDR, said Node object and said Volume_Group object providing information on each volume group of the at least one target node in the distributed processing system; and (ii) computer readable program code means for causing a computer to perform at least one of adding, deleting, modifying, or displaying information about at least one volume group of said at least one target node of the distributed processing system using at least one of said Node object and said Volume_Group object in said SDR.
at least one computer usable medium having computer readable program code means embodied therein for administering a volume group on at least one target node of a distributed processing system having multiple processors, one processor being designated a control node and one or more other processors being designated a target node, said control node being coupled to a system data repository (SDR), the computer readable program code means in the article of manufacture comprising:
(i) computer readable program code means for causing a computer to store information in a Node object and a Volume_Group object in said SDR, said Node object and said Volume_Group object providing information on each volume group of the at least one target node in the distributed processing system; and (ii) computer readable program code means for causing a computer to perform at least one of adding, deleting, modifying, or displaying information about at least one volume group of said at least one target node of the distributed processing system using at least one of said Node object and said Volume_Group object in said SDR.
54. The article of manufacture of claim 53, wherein said computer readable program code means for causing a computer to perform at least one of adding, deleting, modifying, or displaying information comprises computer readable program code means for causing a computer to perform at least one of adding, deleting, modifying, or displaying said volume_group information for said at least one volume group of said at least one target node of the distributed processing system.
55. The article of manufacture of claim 53, further comprising computer readable program code means for causing a computer to provide an interface to allow a user to control said computer readable program code means for causing a computer to perform at least one of adding, deleting, modifying, or displaying information about said at least one volume group of said at least one target node of the distributed processing system.
56. The article of manufacture of claim 53, wherein said computer readable program code means for causing a computer to perform comprises computer readable program code means for causing a computer to make a new Volume_Group object, wherein said making comprises receiving user-defined parameters for the new Volume_Group object, determining that said user-defined parameters comprise a new, unique Volume_Group object, and updating the SDR
with the new Volume_Group object.
with the new Volume_Group object.
57. The article of manufacture of claim 53, wherein said computer readable program code means for causing a computer to perform comprises computer readable program code means for causing a computer to change said Volume_Group object information of said at least one volume group of said at least one target node, said changing including receiving user-defined parameters for said Volume_Group object, determining that said Volume_Group object exists for said at least one target node, and updating the SDR with changed volume group information for said at least one target node.
58. The article of manufacture of claim 53, wherein said computer readable program code means for causing a computer to perform comprises computer readable program code means for causing a computer to remove Volume_Group object information for said at least one volume group of said at least one target node, said removing comprising receiving valid user-defined parameters for said removing, determining that said Volume_Group object exists for said at least one target node, and thereafter, removing the Volume_Group object information specified in the user-defined parameters from the SDR.
Applications Claiming Priority (6)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US09/111,615 | 1998-07-07 | ||
| US09/111,628 | 1998-07-07 | ||
| US09/111,626 | 1998-07-07 | ||
| US09/111,628 US6253209B1 (en) | 1998-07-07 | 1998-07-07 | Method for parallel, remote administration of mirrored and alternate volume groups in a distributed data processing system |
| US09/111,626 US6247140B1 (en) | 1998-07-07 | 1998-07-07 | Parallel remote administration of mirrored and alternate volume groups in a distributed data processing system |
| US09/111,615 US6243828B1 (en) | 1998-07-07 | 1998-07-07 | System for parallel, remote administration of mirrored and alternate volume groups in a distributed data processing system |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CA2270500A1 CA2270500A1 (en) | 2000-01-07 |
| CA2270500C true CA2270500C (en) | 2003-07-08 |
Family
ID=27381022
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CA 2270500 Expired - Fee Related CA2270500C (en) | 1998-07-07 | 1999-04-30 | Method, system and article of manufacture for parallel, remote administration of mirrored and alternate volume groups in a distributed data processing system |
Country Status (1)
| Country | Link |
|---|---|
| CA (1) | CA2270500C (en) |
-
1999
- 1999-04-30 CA CA 2270500 patent/CA2270500C/en not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| CA2270500A1 (en) | 2000-01-07 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US6253209B1 (en) | Method for parallel, remote administration of mirrored and alternate volume groups in a distributed data processing system | |
| US20220261419A1 (en) | Provisioning and managing replicated data instances | |
| JP4744804B2 (en) | Information replication system with enhanced error detection and recovery | |
| US7281159B2 (en) | Managing disk drive replacements on multidisk headless appliances | |
| US8010504B2 (en) | Increasing application availability during automated enterprise deployments | |
| US20040117414A1 (en) | Method and system for automatically updating operating systems | |
| JPH1091564A (en) | Method and system for renaming/exchanging metadevice driver for computer system containing plural independent device drivers | |
| US9043781B2 (en) | Algorithm for automated enterprise deployments | |
| JP5048498B2 (en) | Boot disk management utilities | |
| US6247140B1 (en) | Parallel remote administration of mirrored and alternate volume groups in a distributed data processing system | |
| US6243828B1 (en) | System for parallel, remote administration of mirrored and alternate volume groups in a distributed data processing system | |
| CA2270500C (en) | Method, system and article of manufacture for parallel, remote administration of mirrored and alternate volume groups in a distributed data processing system | |
| Cisco | CiscoWorks 2.1(2) Release Note on NetView for AIX | |
| Cisco | CiscoWorks 2.1(2) Release Note on NetView for AIX | |
| Cisco | CiscoWorks 2.1(2) Release Note on NetView for AIX | |
| Cisco | CiscoWorks 2.1(2) Release Note on NetView for AIX | |
| Cisco | CiscoWorks 2.1(2) Release Note on NetView for AIX | |
| Cisco | CiscoWorks 2.1(2) Release Note on NetView for AIX | |
| Cisco | CiscoWorks 2.1(2) Release Note on NetView for AIX | |
| Cisco | CiscoWorks 2.1(2) Release Note | |
| Cisco | CiscoWorks 2.1(2) Release Note | |
| US6804747B2 (en) | Apparatus and method of reducing physical storage systems needed for a volume group to remain active | |
| US20030115436A1 (en) | Apparatus and method of creating a mirroring map for use with different pieces of data | |
| Allison et al. | Oracle Database Oracle Clusterware and Oracle Real Application Clusters Installation Guide, 10g Release 2 (10.2) for Linux B14203-01 | |
| Salinas et al. | Oracle Real Application Clusters Administrator's Guide 10g Release 1 (10.1) Part No. B10765-02 Copyright© 1998, 2004, Oracle. All rights reserved. Primary Authors: David Austin, Mark Bauer Contributing Authors: Jonathan Creighton, Rajiv Jayaraman, Raj Kumar, Dayong Liu, Venkat Maddali |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| EEER | Examination request | ||
| MKLA | Lapsed |