16.8 Virtual vs. Common Subnets


16.8 Virtual vs. Common Subnets

If an IP address in a real subnet containing interfaces in one or more cluster members is used, the subnet is referred to as a "common" subnet. Client nodes will view a cluster alias from a common subnet as if it were an actual node on the network. The primary means for clients to locate the cluster alias when using a common subnet is through proxy ARP. Any routing within the cluster will be transparent to the clients. Routing beyond the local network will involve host routes only (no network routes).

click to expand
Figure 16-5: Common Subnet: Physical vs. Logical View

Suppose you have no spare IP addresses at your site. Does this mean that you cannot use cluster aliases? That sad situation would eliminate one of the more important capabilities within the cluster. The solution is to use an IP address from within a "virtual subnet." A "virtual subnet" is made up of IP addresses that are not associated with any real interfaces. Clients will access the IP addresses in the virtual subnet (used by the cluster aliases, naturally) through the cluster member serving as the router for that alias. When dealing with high traffic, a common subnet is likely to provide better performance than a virtual subnet, although a virtual subnet provides much more flexibility.

One notable difference when dealing with virtual subnets is that the route advertised by gated will be both a network route and a host route (a common subnet would advertise the host route only).

click to expand
Figure 16-6: Virtual Subnet: Physical vs. Logical View

The network route should be advertised once per member, even if there is more than one alias assigned to the subnet.

Caution

You may not use an address from within the subnet used by the cluster interconnect. This is true for the common subnet aliases as well. Moreover, an address in the virtual subnet cannot be in use on the network. If you choose a virtual subnet that is a real subnet somewhere in the world, the general-purpose router should not route this subnet externally.

Use the cluamgr command to set the virtual option on a subnet.

 # cluamgr -a alias=clua_den,virtual 

The following output shows a cluster member creating a cluster alias using a virtual subnet. Note that the IP address must not be associated with a real interface.

 # grep clua_den_virt /etc/hosts 192.206.126.99 clua_den_virt 

 # cluamgr -a alias=clua_den_virt,mask=255.255.255.0,join,virtual=t 

 # cluamgr -s clua_den_virt Status of Cluster Alias: clua_den_virt netmask: ffffff ... Member Attributes: memberid: 20, selw=1, selp=1, rpri=1 flags=31<JOINED,ENABLED, VIRTUAL> 

The cluster alias routing has not been restarted yet. Note that there are 15 entries in the routing table and nothing pertaining to the alias in the ARP cache.

 # netstat -r | wc -l           15 
 # arp clua_den_virt clua_den_virt (192.206.126.99) -- no entry 

After restarting routing on the current cluster member, the routing table has added two entries. The ARP table shows no additional data because virtual subnetting does not rely directly on proxy ARP as common subnet routing does.

 # cluamgr -r start 
 # arp clua_den_virt clua_den_virt (192.206.126.99) -- no entry 
 # netstat -r | wc -l          17 

 # netstat -r ... 192.206.126        localhost         UG       0         0     lo0 clua_den_virt      localhost         UH       0         0     lo0 ... 

The following output is from a client node. We ran the routed daemon and specified that it run silently (-q no outgoing route advertising) and display a trace of its activities (-t). The routed daemon understands the RIP protocol just as the gated daemon. Therefore, it is legitimate to mix routed and gated daemons in a network as long as both do not run in the same network node. The first part of the output is standard routed startup sequence where it sends a broadcast (192.168.0.255) to announce its presence and hears back from itself on port 520 (192.168.0.104.520). So far, no excitement.

 # routed -q -t Tracing packets started Wed Sep 18 20:04:53 2002 Wed Sep 18 20:04:53: ADD dst 127.0.0.0, router 127.0.0.1, metric 1,         flags UP state PASSIVE|INTERFACE|CHANGED|EXTERNAL timer 0 ADD dst 192.168.0.0, router 192.168.0.104, metric 1,         flags UP state INTERFACE|CHANGED timer 0 SIOCADDRT: File exists REQUEST to 192.168.0.255.0 Wed Sep 18 20:04:53: REQUEST from 192.168.0.104.520 Wed Sep 18 20:04:53: 

The routed trace after this point happened just after the "cluamgr –r start" command was issued on the cluster member. The gated daemon on the cluster (at address 192.168.0.69) advertised two items to the client, one network route that identifies a router with which to communicate when attempting to access a node on network 192.206.126, and one host route that identifies a router with which to communicate when attempting to access the interface at address 192.206.126.99. These items were added to the current information in the client's routing table.

 REQUEST from 192.168.0.69.520 Wed Sep 18 20:19:04: RESPONSE from 192.168.0.69.520 Wed Sep 18 20:19:09: Wed Sep 18 20:19:09: ADD dst 192.206.126.99, router 192.168.0.69, metric 15,         flags UP|GATEWAY|HOST state CHANGED timer 0 ADD dst 192.206.126.0, router 192.168.0.69, metric 2,         flags UP|GATEWAY state CHANGED timer 0 

We stopped routed and restarted it in the background using the "routed –q" command to eliminate repetitive trace output. The client node's routing table contained the following entries sent to it by the gated running on the cluster member that had defined the clua_den_virt alias. Both entries indicate that sheridan (a cluster member) is the way to get where they want to go. The first entry is the network entry; the second entry is the host entry.

 # netstat -r ... 192.206.126         sheridan.dec.com       UG        0       0      tu0 clua_den_virt       sheridan.dec.com       UGH       0       0      tu0 ... 

In the following sequence, the host-specific entry in the routing table on the client shows traffic, but the network counter has not budged. Host routes take precedence over network routes.

 # rsh clua_den_virt hostname sheridan.dec.com # rsh clua_den_virt hostname sheridan.dec.com 

 # netstat -r ... 192.206.126           sheridan.dec.com       UG           0        0  tu0 clua_den_virt         sheridan.dec.com       UGH          2        13 tu0 ... 

The network route would get used in situations where the client attempts to access another node on the virtual subnet that is not currently reflected with a host route in the client routing table. This may be useful to summarize a series of cluster aliases on a virtual subnet in the cluster with one network advertisement.

 # ping 192.206.126.98 PING 192.206.126.98 (192.206.126.98): 56 data bytes ----192.206.126.98 PING Statistics---- 6 packets transmitted, 0 packets received, 100% packet loss 

 # netstat -r ... 192.206.126           sheridan.dec.com        UG           0           6    tu0 clua_den_virt         sheridan.dec.com        UGH          0           13   tu0 ... 

Back on the cluster, we can see the appropriate counters increasing. If another cluster member were the ultimate destination of the client request, the "forward" counts would increase, indicating that cluster routing (forwarding) is happening.

 # cluamgr -s clua_den_virt Status of Cluster Alias: clua_den_virt netmask: ffffff aliasid: 3 flags:5<ENABLED,IP_V4> connections rcvd from net: 4 connections forwarded: 0 connections rcvd within cluster: 4 data packets received from network: 22 data packets forwarded within cluster: 0 datagrams received from network: 0 datagrams forwarded within cluster: 0 datagrams received within cluster: 0 fragments received from network: 0 fragments forwarded within cluster: 0 fragments received within cluster: 0 Member Attributes: memberid: 2, selw=1, selp=1, rpri=1 flags=31<JOINED,ENABLED,VIRTUAL> 

16.8.1 Not Common, Kinda' Virtual

If you look up the word "virtual" in a Merriam-Webster dictionary, you'll find the following definition, "being in essence or in effect though not formally recognized or admitted". Or you could condense the definition and simply say that "virtual" means "fake". So when we talk about a virtual subnet, we are really talking about a "fake" subnet. Fake in that it does not really have any interfaces defined on the subnet. Suppose we only wanted to use a few addresses from a virtual subnet for aliases?

According to the previous section, we can create an alias using an address in a virtual subnet by attaching the syntax "virtual" or "virtual=t" in our cluamgr command, such as:

 # cluamgr -a alias=clua_den_virt,mask=255.255.255.0,join,virtual=t 

The alias clua_den_virt equates to an IP address (192.206.126.99) on a subnet that has no real interfaces on it. Consider what it would mean if we used the exact same syntax but left off the "virtual=t". Wouldn't the alias still be in a "fake" subnet? Indeed it would, but there would be no advertisement for the network route to the subnet. There would only be an advertisement for the host route.

The following syntax creates an alias in a virtual subnet but does not advertise the network route to the virtual subnet (it still advertises the host route). Note that the only thing in this syntax that identifies the alias as being in a virtual subnet (as opposed to a common subnet) is the fact that the IP address for the alias is in a subnet with no real interfaces.

 # cluamgr -a alias=clua_den_virt,mask=255.255.255.0,join 

This technique may be useful if you have multiple clusters and would like to create aliases on multiple clusters using IP addresses from the same virtual subnet. If the "virtual=t" option were used in creating the aliases, the external routers would be informed of a network route to the subnet that may direct traffic to the wrong cluster. This would only be an issue when you have multiple clusters and need to use only one virtual subnet between the multiple clusters.

We recommend (for sanity reasons) that you use a separate virtual subnet for each of your clusters if possible.




TruCluster Server Handbook
TruCluster Server Handbook (HP Technologies)
ISBN: 1555582591
EAN: 2147483647
Year: 2005
Pages: 273

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net