Table of Contents
Table of Contents
Note: this is an xCAT design document, not an xCAT user document. If you are an xCAT user, you are welcome to glean information from this design, but be aware that it may not have complete or up to date procedures.
makeroutes command
The original makeroutes format was designed to create routes on the management node based on the data from CAT's routes table. The format was:
makeroutes [-r|--routename r1[,r2...]]
makeroutes -d|--delete [-r|--routenames r1[,r2...]]
makeroutes [-n|--net net] [-g|--gateway gw] [-m|--mask netmask]
makeroutes -d|--delete [-n|--net net] [-g|--gateway gw] [-m|--mask netmask]
makeroutes [-h --help|-v|--version]
In this release, we want to be able set up the routes not only for the mn, but also for any nodes in the cluster. Thus a new column called routenames will be added in the noderes table to indicate what routes to setup for the node. It will be a comma separated list of rout names. The route name is defined in the routes table. For example:
# tabdump routes
#routename,net,mask,gateway,ifname,comments,disable
"**r2**","10.2.2.0","255.255.255.0","10.2.0.102","eth0",,
"**r1**","10.2.1.0","255.255.255.0","10.2.0.101","eth1",,
# tabdump noderes
#node,servicenode,netboot,tftpserver,nfsserver,monserver,nfsdir,installnic,primarynic,discoverynics,cmdinterface,xcatmaster,current_osimage,next_osimage,nimserver,routenames,comments,disable
"cn1","xcatsn21","yaboot",,"10.2.1.100",,,"eth0","eth0",,,"10.2.1.100",,,,**"r1,r2"**,,
The routes table can be setup manually by the admin or use xcatsetup command. The node range will be added to the command, and -n,-g and -m will be removed to reduced confusion. All the routes handled by this command will be entered in the routes table and the routes will be referenced by the route name only. Here is the new format for this command:
makeroutes [noderange] [-r|--routename r1[,r2...]]
makeroutes [noderange] -d|--delete [-r|--routenames r1[,r2...]]
makeroutes [-h --help|-v|--version]
when noderange is omitted, it will cretae/delete routes on the management nodes.
For the mn, a site table key called mnroutenames will be used for the name of the routes that are to be setup on the mn.
snmove command
snmove command moves a group of nodes from one service node to another. It was released with xCAT 2.5. Service_node_take_over In this release, the we have done some work on AIX. Service_node_manual_takeover_on_AIX. In addition to that, the following two enhancements will be made:
1. Change the default gateway to be the destination SN if the networks.gateway is 'xcatmaster' for the node.
When the gateway is 'xcatmaster' for the network the node is in, it means that the default gateway is the service node. The original default gateway was set to be the source sn. When there is a need to move the nodes to a new service node, the old sn may very well not be working, thus the default gateway will not be functioning. We must set the default gateway to be the destination sn.
2. Allow scripts to run
xCAT runs some of postscripts like syslog, setupntp and mkresolvconf after a group of nodes are moved from one sn to another. Sometimes the user's application and software also need to be reconfigured after the nodes are moved to a new sn. A new flag -P will be added to the snmove command. It takes a list of postscripts and run them on the nodes. All the scripts will have to be saved under /install/postscripts. If no scripts are provided following -P, all postscripts for the nodes will be run. For example:
snmove node1-node15 -s sn1 -d sn2 -D sn2n -P myscript,myscript2
How to setup routes in a hierarchical cluster
1. Assuming we have a hierarchical cluster with 2 service nodes and 20 compute nodes.
node1-node10 are in a group called grp1, and they are managed by sn1, the backup service node for it is sn2.
node11-node20 are in a group called grp2, and they are managed by sn2, the backup service node for it is sn1.
2. For grp1, set
noderes.servicenode="sn1,sn2"
noderes.xcatmaster="sn1-eth1"
For grp2, set:
noderes.servicenode="sn2,sn1"
noderes.xcatmaster="sn2-eth1"
where sn1-eth1 and sn2-eth1 are the nics facing the nodes.
3. Networks:
Assume mn, sn1 and sn2 are in one network called mn_net.
netname"mn_net"
net=10.0.0.0
netmask=255.255.255.0
gateway=10.0.0.100
mn's ip=10.0.0.100
sn1's ip=10.0.0.101
sn2's ip=10.0.0.102.
Assume sn1,sn2,grp1 and grp2 are in another network called sn_net.
netname="sn_net"
net=10.1.0.0
netmask=255.255.0.0
gateway=<xcatmaster>
sn1's ip=10.1.1.100
grp1's ip=10.1.1.*
sn2's ip=10.1.2.100
grp2's ip=10.1.2.*
gateway=<xcatmaster> means that the node will use its service node as the default gateway. In this case, nodes in grp1 will have sn1 as the default gateway. nodes in grp2 will have sn2 as default gateway.
4. Define routes in the routes table
#routename,net,mask,gateway,ifname,comments,disable
"mn_r1","10.1.0.0","255.255.0.0","10.0.0.101",,"This is for mn reaching grp1 through sn1",
"mn_r2","10.1.0.0","255.255.0.0","10.0.0.102",,"This is for mn reaching grp2 through sn2",
"node_r1","10.0.0.0","255.255.255.0","10.1.1.100",,"This is for grp1,grp2 reaching mn through sn1-eth1",
"node_r2","10.0.0.0","255.255.255.0","10.1.2.100",,"This is for grp1,grp2 reaching mn through sn2-eth1",
5. Define routes for the mn and nodes.
site.mnroutenames="mn_r1,mn_r2"
For all nodes in grp1 and grp2
noderes.routenames="node_r1,node_r2"
6. Setup the routes on the mn.
makeroutes
7. Setup the routes on the node if they are up and running.
makeroutes grp1,grp1
8. Add "setroute" to the postscripts.postbootscripts so that the defined routes will be automatically setup next then the node boots up.
News
- Apr 22, 2016: xCAT 2.11.1 released.
- Mar 11, 2016: xCAT 2.9.3 (AIX only) released.
- Dec 11, 2015: xCAT 2.11 released.
- Nov 11, 2015: xCAT 2.9.2 (AIX only) released.
- Jul 30, 2015: xCAT 2.10 released.
- Jul 30, 2015: xCAT migrates from sourceforge to github
- Jun 26, 2015: xCAT 2.7.9 released.
- Mar 20, 2015: xCAT 2.9.1 released.
- Dec 12, 2014: xCAT 2.9 released.
- Sep 5, 2014: xCAT 2.8.5 released.
- May 23, 2014: xCAT 2.8.4 released.
- Jan 24, 2014: xCAT 2.7.8 released.
- Nov 15, 2013: xCAT 2.8.3 released.
- Jun 26, 2013: xCAT 2.8.2 released.
- May 17, 2013: xCAT 2.7.7 released.
- May 10, 2013: xCAT 2.8.1 released.
- Feb 28, 2013: xCAT 2.8 released.
- Nov 30, 2012: xCAT 2.7.6 released.
- Oct 29, 2012: xCAT 2.7.5 released.
- Aug 27, 2012: xCAT 2.7.4 released.
- Jun 22, 2012: xCAT 2.7.3 released.
- May 25, 2012: xCAT 2.7.2 released.
- Apr 20, 2012: xCAT 2.7.1 released.
- Mar 19, 2012: xCAT 2.7 released.
- Mar 15, 2012: xCAT 2.6.11 released.
- Jan 23, 2012: xCAT 2.6.10 released.
- Nov 15, 2011: xCAT 2.6.9 released.
- Sep 30, 2011: xCAT 2.6.8 released.
- Aug 26, 2011: xCAT 2.6.6 released.
- May 20, 2011: xCAT 2.6 released.
- Feb 14, 2011: Watson plays on Jeopardy and is managed by xCAT!
- xCAT Release Notes Summary
- xCAT OS And Hw Support Matrix
- xCAT Test Environment Summary
History
- Oct 22, 2010: xCAT 2.5 released.
- Apr 30, 2010: xCAT 2.4 is released.
- Oct 31, 2009: xCAT 2.3 released.
xCAT's 10 year anniversary! - Apr 16, 2009: xCAT 2.2 released.
- Oct 31, 2008: xCAT 2.1 released.
- Sep 12, 2008: Support for xCAT 2
can now be purchased! - June 9, 2008: xCAT breaths life into
(at the time) the fastest
supercomputer on the planet - May 30, 2008: xCAT 2.0 for Linux
officially released! - Oct 31, 2007: IBM open sources
xCAT 2.0 to allow collaboration
among all of the xCAT users. - Oct 31, 1999: xCAT 1.0 is born!
xCAT started out as a project in
IBM developed by Egan Ford. It
was quickly adopted by customers
and IBM manufacturing sites to
rapidly deploy clusters.