Hey;
Let me try to summarize to see if I got what you're asking for:
1. You have a couple of packages that are currently using virtual IPs on lan0. You want to change those virtual IPs to a different subnet and still use lan0.
2. You want to reconfigure lan2 to your backbone network.
From what I've read, you seem to be on the right track; however, it's important to step back occasionally and review:
To satisfy #1, you want to verify the infrastructure is setup *BEFORE* making any cluster changes. Try plumbing the new virtual IP address manually before making any cluster/DNS changes and see if you can get out:
ifconfig lan0:${num} inet ${new_ip} netmask ${netmask}
ping ${any_other_host_on_that_network}
ping ${router_on_that_network}
The reason you want to do that is there's some router magic that has to happen behind the scenes in order to support multiple networks on the same wire. I honestly don't know what that magic is - however, talking to router people, it's not difficult, but it's also not default.
Once you have that working it's time to start making some choices.
1. You don't actually have to bring the package down in order to make this change. It is by far preferable; however, you can leave the IP manually plumbed and update DNS. After the DNS cache timeout, all clients should be using the new IP address. Make sure you update the /etc/hosts as well.
If you decide to go this route, update a copy of the package control script with the new IP addresses. During your maintenance/testing window, the old package control scripts will take down the old IP address. Once it's down, copy the new package control script over the old one (RCS is a wonderful thing) then bring up the pacakge. Troubleshoot as necessary. Once everything's working on the primary node, copy the control script over to the adoptive node and bring the package up over there. Troubleshoot as necessary.
If you decide to shut everything down first, manually deconfigure the IP address you plumbed earlier, shutdown the package, and update the control script. From there test on primary/alternate nodes and troubleshoot as necessary.
2. Decide whether or not you want a standby lan. They're not mandatory. They're pretty cool in that they don't fail over the whole package if a cable or switch port goes out; however, they're not mandatory. The advantage to not having the standby lan is cost - you won't have to buy new cards. I would suggest keeping them; however, that's more of a business decision.
If you decide against the standby lan, you can either update the cluster ascii file manually or regenerate one. Regenerating one is probably safer. Stop all packages, drop the cluster, then update /etc/rc.config.d/netconf as appropriate then either reboot or manually configure lan2.
cmquerycl -C ${config} -v -n ${node1} -n ${node2}
update, check and apply:
cmcheckconf -C ${config}
cmapplyconf -C ${config}
If you want to edit the config, generate the current running config and edit that file:
cmgetconf -c ${cluster} > ${config}
update, check, and apply.
If you decide to add new lan cards, shut everything down, have them installed, then generate a new cluster config file as described above.
Regardless which option you choose, either reconfiguring lan2 or adding new NICs, you'll have to update your cluster config file as MCSG is very sensitive to network configuration.
Last suggestion: Do your updates in two discrete steps - better yet on two separate maintenance windows. You can upate the package IPs first; verify over the course of the week that everything's working, then update the network/cluster configuration.
HTH.
Doug O'Leary
------
Senior UNIX Admin
O'Leary Computers Inc
linkedin: http://www.linkedin.com/dkoleary
Resume: http://www.olearycomputers.com/resume.html
