![]() |
![]() HP OpenVMS Systemsask the wizard |
![]() |
The Question is: I am trying to implement TCP/IP (UCX V4.1 ECO 9) cluster alias load balancing on a VAX cluster consisting of two VAX 4000/600's. I am running VMS 6.2 and UCX V4.1. The PC's on the LAN are running Reflections 8.0 under NT 4.0 SP6 and making connections t o the cluster alias via the Reflections X client. All IP connections to the cluster alias go to one node on the cluster. The DECNET connections seem to do the "round robin" style of load balancing OK. I have read several of the articles found in the "A sk the Wizard" repository, but none of the solutions seem to work here. I have used the UCX SET NOHOST to remove the cluster alias from the host database. The cluster alias is being resolved by the DNS's, but all X-window clients connecting IP go to the same one node on the cluster. This makes for a very "unbalanced" load of users on the cluster and supsequent performance/resource bottleneck. The DNS's I have specified are all NT 4.0 based. The PC users can specify the individual node name and log di rectly onto the node. But when the users specify the cluster alias name, the user is logged onto just one particular node, never the other one. Upgrading the software is not an option. One of the articles states "With the DNS-based alias, participating nodes use their own IP addresses; there is no special IP address associated with the cluster alias." I'm not sure what or how to implement this statement. When I configured UCX on both nodes, I specified a cluster IP address for interface ZE0. Are the re any other technical write-ups on implementing TCP/IP load balancing on a VAX/VMS cluster ... or do you have any suggestions as to how I can solve my load balancing problem? The Answer is : Please upgrade, to at least TCP/IP Services V4.2 with ECO, as TCP/IP Services V4.1 is no longer supported. If you are on OpenVMS VAX V6.2, you should have no application problems (in either user- or kernel-mode code) upgrading to OpenVMS VAX V7.2 and TCP/IP Services V5.1, and you should seriously consider this upgrade. The components of interest here will be the TCP/IP Services Load Broker and the Metric Server -- these components do exist in the version of TCP/IP Services you are using, but have subsequently seen various enhancements in more recent versions of TCP/IP Services.
|