 | Caution: This appendix is included for convenience, but has not been updated to support CXFS 5.0. With the exception of a few administrative cmgrcommands, the preferred CXFS configuration tools are cxfs_admin and the CXFS graphical user interface (GUI). For more information about these commands, see CXFS Administration Guide for SGI InfiniteStorage. |
This appendix contains the following information about the cmgr command:
The following example shows the entries used to define a Solaris node named solaris1 using the cmgr command in prompting mode:
# /usr/cluster/bin/cmgr -p Welcome to SGI Cluster Manager Command-Line Interface cmgr> define node solaris1 Enter commands, you may enter "done" or "cancel" at any time to exit Hostname[optional] ? Is this a FailSafe node <true|false> ? false Is this a CXFS node <true|false> ? true Operating System <IRIX|Linux32|Linux64|AIX|MacOSX|Solaris|Windows> ? solaris Node ID ? 7 Do you wish to define failure hierarchy[y/n]:y Hierarchy option 0 <System|Fence|Shutdown>[optional] ? fence Hierarchy option 1 <System|Fence|Shutdown>[optional] ? shutdown Hierarchy option 2 <System|Fence|Shutdown>[optional] ? Number of Network Interfaces ? (1) NIC 1 - IP Address ? 163.154.18.172 NIC 1 - Heartbeat HB (use network for heartbeats) <true|false> ? true NIC 1 - (use network for control messages) <true|false> ? true NIC 1 - Priority <1,2,...> ? 1 |
If you are using cmgr, you must add the defined nodes to the cluster. This happens by default if you are using cxfs_admin.
After you define all of the client-only nodes, you must add them to the cluster.
For example, if you have already defined a cluster named cxfscluster using cmgr and want to add the Solaris nodes solaris1 and solaris2, you could use the following cmgr command:
cmgr> modify cluster cxfscluster cxfscluster ? add node solaris1 cxfscluster ? add node solaris2 cxfscluster ? done |
Depending upon your filesystem configuration, you may also need to add the node to the list of clients that have access to the volume. See “Mounting Filesystems on the Client-Only Nodes” in Chapter 10.
You are required to use I/O fencing on client-only nodes in order to protect data integrity. I/O fencing requires a switch; see the release notes for supported switches.
For example, for a QLogic switch named myswitch:
cxfs_admin:mycluster> create switch name=myswitch vendor=qlogic |
After you have defined the switch, you must ensure that all of the switch ports that are connected to the cluster nodes are enabled. To determine port status, enter the following on a CXFS server-capable administration node:
irix# hafence -v |
If there are disabled ports that are connected to cluster nodes, you must enable them. Log into the switch as user admin and use the following command:
switch# portEnable portnumber |
You must then update the switch port information
For example, suppose that you have a cluster with port 0 connected to the node blue, port 1 connected to the node green, and port 5 connected to the node yellow, all of which are defined in cluster colors. The following output shows that the status of port 0 and port 1 is disabled and that the host is UNKNOWN (as opposed to port 5, which has a status of enabled and a host of yellow). Ports 2, 3, 4, 6, and 7 are not connected to nodes in the cluster and therefore their status does not matter.
irix# hafence -v
Switch[0] "ptg-brocade" has 8 ports
Port 0 type=FABRIC status=disabled hba=0000000000000000 on host UNKNOWN
Port 1 type=FABRIC status=disabled hba=0000000000000000 on host UNKNOWN
Port 2 type=FABRIC status=enabled hba=210000e08b05fecf on host UNKNOWN
Port 3 type=FABRIC status=enabled hba=210000e08b01fec5 on host UNKNOWN
Port 4 type=FABRIC status=enabled hba=210000e08b01fec3 on host UNKNOWN
Port 5 type=FABRIC status=enabled hba=210000e08b019ef0 on host yellow
Port 6 type=FABRIC status=enabled hba=210000e08b0113ce on host UNKNOWN
Port 7 type=FABRIC status=enabled hba=210000e08b027795 on host UNKNOWN |
In this case, you would need to enable ports 0 and 1:
Logged in to the switch:
switch# portEnable 0
switch# portEnable 1
Logged in to a CXFS server-capable administration node:
irix# hafence -v
Switch[0] "ptg-brocade" has 8 ports
Port 0 type=FABRIC status=disabled hba=210000e08b0103b8 on host UNKNOWN
Port 1 type=FABRIC status=disabled hba=210000e08b0102c6 on host UNKNOWN
Port 2 type=FABRIC status=enabled hba=210000e08b05fecf on host UNKNOWN
Port 3 type=FABRIC status=enabled hba=210000e08b01fec5 on host UNKNOWN
Port 4 type=FABRIC status=enabled hba=210000e08b01fec3 on host UNKNOWN
Port 5 type=FABRIC status=enabled hba=210000e08b019ef0 on host yellow
Port 6 type=FABRIC status=enabled hba=210000e08b0113ce on host UNKNOWN
Port 7 type=FABRIC status=enabled hba=210000e08b027795 on host UNKNOWN
irix# cmgr -c admin fence update (No command necessary for cxfs_admin)
irix# hafence -v
Switch[0] "ptg-brocade" has 8 ports
Port 0 type=FABRIC status=disabled hba=210000e08b0103b8 on host blue
Port 1 type=FABRIC status=disabled hba=210000e08b0102c6 on host green
Port 2 type=FABRIC status=enabled hba=210000e08b05fecf on host UNKNOWN
Port 3 type=FABRIC status=enabled hba=210000e08b01fec5 on host UNKNOWN
Port 4 type=FABRIC status=enabled hba=210000e08b01fec3 on host UNKNOWN
Port 5 type=FABRIC status=enabled hba=210000e08b019ef0 on host yellow
Port 6 type=FABRIC status=enabled hba=210000e08b0113ce on host UNKNOWN
Port 7 type=FABRIC status=enabled hba=210000e08b027795 on host UNKNOWN |
After adding the client-only nodes to the cluster with cmgr, you must start CXFS services for them, which enables the node by setting a flag for the node in the cluster database. This happens by default with cxfs_admin.
For example:
cmgr> start cx_services on node solaris1 for cluster cxfscluster cmgr> start cx_services on node solaris2 for cluster cxfscluster |
With cmgr command, you can mount the filesystems on the new client-only nodes by unmounting the currently active filesystems, enabling the mount on the required nodes, and then performing the actual mount. For example, to mount the fs1 filesystem on all nodes in the cluster except solaris2, you could use the following commands:
cmgr> admin cxfs_unmount cxfs_filesystem fs1 in cluster cxfscluster cmgr> modify cxfs_filesystem fs1 in cluster cxfscluster cxfs_filesystem fs1 ? set dflt_local_status to enabled cxfs_filesystem fs1 ? add disabled_node solaris2 cxfs_filesystem fs1 ? done |
 | Note: SGI recommends that you enable the forced unmount feature for CXFS filesystems, which is turned off by default; see “Enable Forced Unmount” in Chapter 2 and “Forced Unmount of CXFS Filesystems” in Chapter 10. |
Normally, an unmount operation will fail if any process has an open file on the filesystem. However, a forced unmount allows the unmount to proceed regardless of whether the filesystem is still in use.
For example:
cxfs_admin:mycluster> create filesystem name=myfs forced_unmount=true |
Using cmgr, define or modify the filesystem to unmount with force and then unmount the filesystem. For example:
define cxfs_filesystem logical_filesystem_name [in cluster clustername] set force to true |
modify cxfs_filesystem logical_filesystem_name [in cluster clustername] set force to true |
admin cxfs_unmount cxfs_filesystem filesystemname [on node nodename] [in cluster clustername] |
For example, the following set of commands modifies the fs1 filesystem to allow forced unmount, then unmounts the filesystem on all nodes in the cxfscluster cluster:
cmgr> modify cxfs_filesystem fs1 in cluster cxfscluster Enter commands, when finished enter either "done" or "cancel"cmgr> cxfs_filesystem fs1 ? set force to true cxfs_filesystem fs1 ? done Successfully defined cxfs_filesystem fs1 cmgr> admin cxfs_unmount cxfs_filesystem fs1 in cluster cxfscluster |
For details, see cmgr reference appendix in the CXFS Administration Guide for SGI InfiniteStorage.