16.6 Alias Attributes


16.6 Alias Attributes

Notice how gracefully we slipped by the other alias attributes. Only professional authors and technical bullet dodgers can get away with that kind of move. Since we know you are curious, let's discuss some routing and alias issues that have been avoided so far.

16.6.1 The rpri Alias Attribute

If multiple cluster members are willing to route for an alias, how does the cluster determine which member actually pulls the packet off the wire and makes the subsequent routing decisions? Each member can apply a routing priority (rpri) to an alias. The higher the rpri number (the range is 0-100), the more likely the member will be the one selected to do the routing activities.

Note

An rpri value of zero indicates that the member does not want to volunteer for routing duties unless every other member is also trying to dodge the bullet too. This would effectively eliminate the member as an alias router under normal circumstances. An rpri value of 100 is a special case while the normal rpri values (1-99) cause an entry to be placed in the routing table with a cost metric of 14. If you set rpri to 100, the same routing table information appears but with a cost metric of 10. The RIP clients will prefer the lower cost route.

If multiple members set up the same routing priority for an alias (as seen in the example output below), the alias router will be the first member to boot (if the clients were already up at the time of the cluster booting). If the cluster boots before the clients, the alias router will be the member that has the highest rpri and sent out the most recent routing information to the client's dynamic routing daemon.

 Member Attributes: memberid: 1, selw=1, selp=1, rpri=1 flags=11<JOINED,ENABLED> memberid: 2, selw=1, selp=1, rpri=1 flags=11<JOINED,ENABLED> 

16.6.2 The selw and selp Alias Attributes

To determine to which member the request for service is routed within the cluster, two attributes are used: selection weight (selw) and selection priority (selp). The selp number determines which node(s) are asked to perform the service (telnet, ftp, ping, etc.). Only a member with the highest selection priority will provide the service. If more than one member has the highest selection priority, they all will share the service load. Remember that if a member has a selp that is not the highest in the cluster, the member will not provide the service at all, until the other cluster members (with higher selp) are removed or fail (or change their selp).

In the case of a tie selp value, the members will provide the service in a round robin fashion based on the value of the selection weight (selw) attribute. The selection weight dictates how many services requested through the alias will be handled by the first member with the highest selp value before switching over to the next member with the exact same selp value. The selw value provides a mechanism whereby some members may handle more instances of the service than others, despite having the same selp value.

If member1 (molari) has an alias with selp=6 and selw=3, while member2 (sheridan) has the same alias with selp=6 and selw=1, the first member will handle the first three requests for service through the alias. The other member will then handle one request before we go back to the first member for the next three requests and so on.

 # rsh babylon5 hostname molari.dec.com # rsh babylon5 hostname molari.dec.com member1 receives the first three requests. # rsh babylon5 hostname molari.dec.com # rsh babylon5 hostname sheridan.dec.com member2 gets one request. # rsh babylon5 hostname molari.dec.com The cycle starts again. This is the "weighted" round robin member selection process. 




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