Adding High (Private) or Low (Public) priority heartbeat link.

Other day, I had a very urgent requirement to implement VCS with guns pointing @ me :). When I checked for the hardware I found I can start the cluster only with one Private & one Public heartbeat link, which left the cluster in Jeopardy state the moment it started.

This was quiet obvious as VCS would atleast require two Private links with very less/minimal access to Low-priority links (Not recommended by Symantec) to have greater security and smooth functioning.

Mean while I got the hardware and wondered whether I can add them to cluster without any disruption to the running applications??? Thanks for the intuitive solution from Symantec team. !!!!.

Having faced the heat would like to share these with you all…..Lets begin the sneak-peek :)

Configuring heartbeat links is done as follows

Make sure your hardware is connected to the servers and OS can see it using dladm or kstat (Solaris 9 and less) or whichever is suitable.

# dladm show-dev

e1000g0         link: up        speed: 1000  Mbps       duplex: full

e1000g1         link: up        speed: 1000  Mbps       duplex: full

e1000g2         link: unknown   speed: 0     Mbps       duplex: half

#

To add a new high priority link (private heartbeat) while Low Latency transport is active, use the following command on each node:

# lltconfig -t <if alias name> -d <device> -b ether

Ex: # lltconfig -t e1000g2 -d /dev/e1000g2 -b ether

To add a new low priority link (utilizing a public interface),

# lltconfig -t <alias> -l -d <device> -b ether

Ex: lltconfig -t e1000g0 -l -d /dev/e1000g2 -b ether

NOTE: -l represents the low-priority link.

Here we are, now we can see the new NIC gets added under online private interconnect configuration on both the nodes,

# lltstat -l |grep link
 link 0 e100g0 on etherfp lowpri
 link 1 e1000g1 on etherfp hipri
 link 2 e1000g2 on etherfp hipri  -à Newly added.

But, there is a catch here. The word, I mentioned “ONLINE” means the configuration will only remain active till the server reboots or until the cluster is offline because, whenever LLT is started its reads the “/etc/llttab” file and loads the devices appropriately.

                No were till now, we have added the new heartbeat link (e100g2) to “/etc/llttab”. Let’s pull the trigger.

Open the file using any UNIX editor (mostly vi) and before that, take a copy of LLT configuration file (/etc/llttab) it always saves you from troubles, otherwise. Then append the following entries on both the nodes.

               

After editing, the file looks as below.

# cat /etc/llttab
set-node testclus
set-cluster 100
link-lowpri e1000g0 /dev/e1000g0 - ether - -
link e1000g1 /dev/e1000g1 - ether - -

link e1000g2 /dev/e1000g2 - ether - -   ]--à Newly appended.

Upon reboot of the system, the VCS configuration will read the additional link that was added to "/etc/llttab" in the above steps.

There you go we reached end of a hectic problem by a simple solution. The change to the link configuration is now permanent.

1-2-3 DHCP

            Today I just wanted to document here the quickest and easiest way of setting your Solaris box as a DHCP client. Setting up a Sun Solaris Server to receive its IP address from a DHCP Server is fairly straight forward and is infact just a matter of setting up files on your Solaris Server.

dhcpagent is the dhcp client thats running on your Solaris operating system. With this in place create the following file:

1. Create the /etc/hostname. <interface>

This will be an empty file

sun1# touch /etc/hostname.e1000g0

                                                                  

Repeat the above for all the avaliable interface cards on which you would like to have the IP from DHCP.

2. Create the /etc/dhcp.<interface>

This is also an empty file

sun1# touch /etc/dhcp.e1000g0  

                                                           

but you can also use it to specify how long ifconfig should be waiting for a DHCP-server reply before giving up and continuing with Solaris boot.

sun1# cat /etc/dhcp.e1000g0    

wait 60 ( default 30 sec)            ------> (Can be any value or forever)

primary                                                ------> (To notfy ifconfig about primary interface incase you have more tha one interface)

3. Specify your system name

It has to be specified in /etc/nodename. This name is going to be used as your hostname in case your DHCP-server does not return your hostname in reply to your DHCP-request.

                       

sun1# cat > /etc/nodename 

sun2                         

Reboot your system, and it all should work !!!

As simple as that, 1-2-3 DHCP

Appendix A:

Problem: Unknown hostname

            Actually, there's one snag: most (if not all) cable modem DHCP servers don't provide you with a hostname (even if they did, odds are it won't be one you want anyway!). This wouldn't be a problem, except that the boot scripts (/etc/init.d/rootusr in particular) try to be clever, and set your hostname to "unknown" in this case, which is not at all useful!

Solution: Add the hostname to /etc/nodename as mentioned earlier.

Appendix B: Tunable dhcpagent parameters.

Below is the file which needs to be modifed to have changes according to requirments.

                                                           

            /etc/default/dhcpagent

                                                             

Most important parameter value attribute is below.

PARAM_REQUEST_LIST=1,3,6,12,15,28,43

This variable tells dhcpagent what to request for from DHCP server.

Each value in the above list has specific meaning.

    1 = subnet mask

    3 = Default Router

    6 = DNS Server

    12 = hostname

    15 = DNS Domain Name

    28 = broadcast address

    43 = Encapsulated Vendor options

If you doesn't want the client to request for hostname delete number 12 followed by its comma (,) symbol