Linux Clustering With Csm and Gpfs
|
| < Day Day Up > |
|
7.5 Creating the GPFS cluster
The first thing you must do in the process of creating a GPFS cluster is to define the characteristics of the cluster through the mmcrcluster command. The following are a brief description of the mmcrcluster command line options:
| -n | A list of node descriptors. You must provide a descriptor for each node to be added to the GPFS cluster. Each descriptor must be specified in the form primaryNetworkNodeName::secondaryNetworkNodeName. Those descriptors should be defined in a text file one per line. |
| -t | The type of the cluster to be defined. At the time of writing this book, the only valid value is lc. |
| -p | This is the primary GPFS cluster data server node used to store the GPFS cluster data. |
| -s | Specifies the secondary GPFS cluster data server node used to store the GPFS cluster data. It is suggested that you specify a secondary GPFS cluster data server to prevent the loss of configuration data in the event your primary GPFS cluster data server goes down. |
| -r | Specify the remote shell to be used. The default value is rsh. As CSM has already been installed in our cluster and it uses ssh as the remote shell, we will need to specify /usr/bin/ssh in this option. |
| -R | Specify the remote file copy command to be used. The default value is rcp. Similarly to the remote shell option, we will need to specify /usr/bin/scp in this option. |
7.5.1 Creating the GPFS nodes descriptor file
When creating your GPFS cluster, you need to provide a file containing a list of node descriptors, one per line for each node to be included in the cluster, including the storage nodes. Each descriptor must be specified in the form:
primaryNetworkNodeName::secondaryNetworkNodeName
Where:
| primaryNetworkNodeName | The host name of the node on the primary network for GPFS daemon to daemon communication. |
| designation | Currently unused and specified by the double colon ::. |
| secondaryNetworkNodeName | The host name of the node on the secondary network, if one exists. |
You may configure a secondary network node name in order to prevent the node from appearing to have gone down when the network is merely saturated. During times of excessive network traffic, if a second network is not specified, there is the potential for the RSCT component to be unable to communicate with the node over the primary network. RSCT would perceive the node as having failed and inform GPFS to perform node recovery.
Example 7-19 shows the contents the GPFS descriptors file we have created using the primaryNetworkNodeName as the one defined in our Myrinet network and the secondaryNetworkNodeName as the one defined in our Cluster network.
Example 7-19: /tmp/gpfs.allnodes file
[root@storage001 root]# cat /tmp/gpfs.allnodes storage001-myri0::storage001 node001-myri0::node001 node002-myri0::node002 node003-myri0::node003 node004-myri0::node004 [root@storage001 root]#
7.5.2 Defining the GPFS cluster
It is time now to run the mmcrcluster command to define the GPFS cluster. In our lab environment, we defined storage001-myri0 as the primary network for GPFS communication, ssh as remote shell command, scp as remote file copy commands, and lc for the cluster type. Example 7-20 on page 209 shows the output of the mmcrcluster command.
Example 7-20: mmcrcluster command output
[root@storage001 root]# mmcrcluster -t lc -p storage001-myri0.cluster.com -n \ /tmp/gpfs.allnodes -r /usr/bin/ssh -R /usr/bin/scp Wed Oct 23 15:19:33 CDT 2002: mmcrcluster: Processing node storage001-myri0.cluster.com Wed Oct 23 15:19:35 CDT 2002: mmcrcluster: Processing node node001-myri0.cluster.com Wed Oct 23 15:19:36 CDT 2002: mmcrcluster: Processing node node002-myri0.cluster.com Wed Oct 23 15:19:38 CDT 2002: mmcrcluster: Processing node node003-myri0.cluster.com Wed Oct 23 15:19:40 CDT 2002: mmcrcluster: Processing node node004-myri0.cluster.com Wed Oct 23 15:19:43 CDT 2002: mmcrcluster: Initializing needed RSCT subsystems. mmcrcluster: Command successfully completed [root@storage001 root]#
This command, as with almost all GPFS commands, may take some time to execute, because it executes many tasks in all the nodes. Wait until the command finishes its execution, with success or not. If you stop its execution, the cluster definitions may not be fully created.
If one or more nodes are unavailable during the cluster definition, the mmcrcluster command will issue warnings regarding the nodes and they must be included in the cluster later using the mmaddcluster command.
After creating the cluster definitions, you can see the definitions using the mmlscluster command, as in Example 7-21.
Example 7-21: mmlscluster command output
[root@storage001 root]# mmlscluster GPFS cluster information ======================== Cluster id: gpfs1034298448 Remote shell command: /usr/bin/ssh Remote file copy command: /usr/bin/scp Primary network: myrinet Secondary network: ether GPFS cluster data repository servers: ------------------------------------- Primary server: storage001-myri0.cluster.com Secondary server: (none) Cluster nodes that are not assigned to a nodeset: ------------------------------------------------- 1 storage001-myri0 10.2.1.141 storage001-myri0.cluster.com 10.0.3.141 2 node001-myri0 10.2.1.1 node001-myri0.cluster.com 10.0.3.1 3 node002-myri0 10.2.1.2 node002-myri0.cluster.com 10.0.3.2 4 node003-myri0 10.2.1.3 node003-myri0.cluster.com 10.0.3.3 5 node004-myri0 10.2.1.4 node004-myri0.cluster.com 10.0.3.4 [root@storage001 root]#
|
| < Day Day Up > |
|