The information in this appendix will help you migrate from a cluster with IRIX server-capable administration nodes to a cluster with Linux server-capable administration nodes. It discusses the following:
You must ensure that you have the correct network configuration for the new Linux server-capable administration nodes; see Chapter 6, “Preinstallation Steps”. For assistance, contact SGI Installation Services.
If you are migrating from a cluster with IRIX metadata servers to a cluster with Linux metadata servers, you should understand the differences between IRIX and Linux system administration. The details of these differences are beyond the scope of this guide, but a brief overview includes:
Installation tools
Mount options
Paths
Location of kernel system tunable parameters
For more information, see the operating system documentation.
See also:
This section discusses the following:
CXFS does not support SGIRDAC mode. To convert from SGIRDAC to SGIAVT, do the following:
Install the latest supported firmware on the RAID.
Determine the IP address for one of the controllers on each RAID box.
Make a script settype.scr that contains the following line:
set storageArray defaultHostType="modename";
Note: The capitalization and punctuation in the above line are required. To switch to SGIAVT mode, use the following line:
set storageArray defaultHostType="SGIAVT";
For the InfiniteStorage 220, use the CLI client to set the host type to SGIAVT:
smicli -w SA_WWID -c 'set storageArray defaultHostType="SGIAVT";'
To determine the value for SA_WWID, invoke the following:
smicli -d -w
For example:
# smicli -d -w unit1 600a0b80002459d40000000045003fbc localhost |---> SA_WWID
Run the following for one of the controllers per RAID box:
/opt/tpssm/client/tpssmcli RAID_IPaddress -f settype.scr
For example:
# /opt/tpssm/client/tpssmcli 192.168.0.1 -f settype.scr Performing syntax check... Syntax check complete. Executing script... Script execution complete. tpssmcli completed successfully.
Linux does not support version-1 naming on filesystems. You must examine the parameters for each filesystem by using the following command on the active metadata server for each filesystem:
xfs_growfs -n mountpoint |
For example, the following shows that the /stripe1 filesystem has version-2 naming:
irixMDS# xfs_growfs -n /stripe1
meta-data=/stripe1 isize=256 agcount=16, agsize=1663360 blks
= sectsz=512 attr=0, parent=0
data = bsize=4096 blocks=26611968, imaxpct=25
= sunit=128 swidth=768 blks, unwritten=1
= mmr=0
naming =version 2 bsize=4096 mixed-case=Y
log =internal bsize=4096 blocks=13056 version=1
= sectsz=512 sunit=0 blks lazy-count=0
realtime =none extsz=4096 blocks=0, rtextents=0 |
If you have a filesystem that displays version-1 naming, you must recreate it on a Linux server-capable administration node so that it will have version-2 naming. Do the following:
Dump the filesystem data to backup media by using the xfsdump(1M) command.
Warning: If this step is not performed, all data currently on the filesystems will become inaccessible and will be permanently lost. Unmount the CXFS filesystems clusterwide by using the cxfs_admin command.
Recreate the filesystem by using the mkfs.xfs(8) command on a Linux server-capable administration node. Preserve any nondefault filesystem parameters by specifying the applicable options to the mkfs.xfs command.
Restore the filesystem data from backup media by using the xfsrestore(8) command.
For more information, see the man pages for the above commands and the following:
IRIX Admin: Disks and Filesystems
XFS Administrator Guide
On SGI x86_64 server-capable administration nodes, the maximum block size is 4K. If you have filesystems with larger block sizes, you must recreate them by performing a dump and a restore, changing the block size so that it does not exceed the maximum for the architecture of your systems.
| Note: SGI recommends a block size of 4K for CXFS filesystems in a multiOS cluster because this is the only block size that is supported on all CXFS hardware platforms. |
Under Linux, project quotas are applied to the files below a given directory. You can view the project quotas only from the active CXFS metadata server, not from CXFS client-only nodes. See “Quotas Differences” in Chapter 1.
| Note: The following procedure assumes that the filesystems in the cluster you want to migrate do not have block sizes greater than the system page size and that they are not real-time filesystems. These types of filesystems are supported on IRIX but not on Linux. |
Following is a procedure for using cxfs_admin to migrate from a cluster with IRIX server-capable administration nodes to a cluster with Linux server-capable administration nodes. For details about using cxfs_admin, see Chapter 11, “cxfs_admin Command”.
| Note: The cluster cannot be used for production work during this process. |
For information about using the GUI to perform similar tasks, see Chapter 10, “CXFS GUI”.
As a precaution, save the current cluster database contents by using the build_cmgr_script command.
Ensure you have CXFS 7.0 licenses installed on the Linux server-capable administration nodes. See:
From an IRIX server-capable administration node:
Unmount the CXFS filesystems clusterwide by using the cxfs_admin command. For example, to unmount the CXFS V9500 filesystem clusterwide:
cxfs_admin:mycluster> unmount V9500
Use the IRIX mount and umount commands to mount and unmount the filesystems locally, which will ensure that the XFS log plays back cleanly. For example, mount and unmount the V9500 filesystem locally:
irixadmin# mount /dev/cxvm/V9500 /mnt irixadmin# umount /mnt
Disable each IRIX server-capable administration node by using the cxfs_admin command. For example, to disable the node named irixnode1:
cxfs_admin:mycluster> disable irixnode1
Repeat the disable command for each IRIX server-capable administration node.
Create a Linux server-capable administration node in the cluster. This will allow the cluster database information to be transferred to the Linux nodes.
Note: This migration situation is the only time that mixed OS server-capable administration nodes are allowed in the same cluster. For example (line breaks here for readability):
cxfs_admin:mycluster> create node name=linuxnode1 type=server_admin os=linux private_net=10.0.10.1 enabled=true hostname=linuxnode1.domain.com
From the Linux server-capable administration node created in step d above, do the following:
Delete each IRIX server-capable administration node by using the cxfs_admin command. For example, to delete the node named irixnode1:
cxfs_admin:mycluster> delete irixnode1
Repeat the delete command for each IRIX server-capable administration node.
Create any additional Linux server-capable administration nodes in the cluster. For example, to create a node named linuxnode2:
cxfs_admin:mycluster> create node name=linuxnode2 type=server_admin os=linux private_net=10.0.10.2
Repeat the create command for each Linux server-capable administration node.
Modify the CXFS filesystems to assign the new Linux server-capable administration nodes as potential metadata servers. For example:
cxfs_admin:mycluster> modify filesystem name=V9500 servers=linuxnode1,linuxnode2
Mount the CXFS filesystems by using the cxfs_admin command. For example, to mount the V9500 filesystem:
cxfs_admin:mycluster> mount V9500
Check cluster configuration:
cxfs_admin:mycluster> status
You could also use the cxfs-config command to verify the status.
Dispose of the former IRIX server-capable administration nodes properly:
Stop CXFS processes on each IRIX server-capable administration node:
irixadmin# /etc/init.d/grio2 stop (if running GRIOv2) irixadmin# /etc/init.d/cxfs stop irixadmin# /etc/init.d/cluster stop
Repeat these commands on each IRIX server-capable administration node.
Do one of the following:
Transform the nodes into IRIX client-only nodes and add them to the cluster. Execute the stop commands above and follow the procedure in “Transforming a Server-Capable Administration Node into a Client-Only Node” in Chapter 12.
Remove the IRIX server-capable administration nodes physically from the network.
For more information about using the GUI, see the following:
The following sections discuss possible problems you may encounter after migrating from an IRIX cluster to a Linux cluster:
Messages such as the following indicate that the filesystem was not cleanly unmounted from the IRIX metadata server:
Jan 29 22:06:07 4A:cxfs2 kernel: XFS: nil uuid in log - IRIX style log Jan 29 22:06:07 5A:cxfs2 kernel: Starting XFS recovery on filesystem: xvm-0 (dev: xvm-0) Jan 29 22:06:07 4A:cxfs2 kernel: XFS: dirty log written in incompatible format - can't recover |
To resolve this problem, you must return to the IRIX node and then mount and umount the filesystem locally on the IRIX node in order to replay the dirty log messages (as in step 3b in “Migration Procedure”).
 | Caution: Do not steal the XVM volumes to the local host. Mounting /dev/cxvm/volname locally on /mnt is sufficient. |
If you have DMF filesystems and have dmi as a mount option,you must edit the/etc/sysconfig/sysctlfile to turn on DMAPI probing in order to mount CXFS filesystems. Change the bottom line from:
DMAPI_PROBE="no" |
to:
DMAPI_PROBE="yes" |