rx2620 - network connections for Cluster/SCS and Decnet

[Thomas Griesan]

Hello people!

We have a 2 node cluster (two Itanium rx2620 each with a dual port fiber NIC). These boxes also have 2 copper net connections each. Quorum disk is on the MSA1000.

What I’d like to do is hook these boxes together directly with a crossover cable (i.e. not to a switch) for cluster/SCS and/or Decnet traffic and also connect to the ethernet to redundant switches for IP. I only need Decnet BETWEEN the two nodes (yes, I know that is a bit odd ;-).

1. Is it cool to hook these severs together directly and what ramifications may I have?
2. Which ports should I use for the best reliability and performance?
3. How do I config decent to use the direct connection between the nodes?
4. Do I need something like FailSAFE to make Decent failover if one connection is down?

For example, I could use fiber to hook the boxes together with one or both ports, or I could use copper or any combination thereof. I have 4 net connections on each box so there are a number of possibilities.

Could I, or should I, even hook both fiber ports on each machine together and run SCS over one and Decnet over the other? I realize SCS will decide on its own what connection it will use.

I don't have to use all the ports, obviously, just looking for reliability and performance.

Thanks a ton!!!
Tom

[Andy Bustamante · Accepted solution]

A cross over is one of the simpliest most reliable cluster interconnects. Plug it and, make sure the speed/duplex is correct and be happy.

There's a lot of "it depends" here on the remaining questions. With two dual ported NICs I'd look at band width required. DECnet Phase IV or V? It sounds like you have redundant switching available, I'd want to use both NICs. Does your switching support fiber?

LAN failover is configured with the LANCP utility, see System Manager's Manual v 2, chapter 10. http://h71000.www7.hp.com/doc/82FINAL/aa-pv5nj-tk/aa-pv5nj-tk.HTMl

Configure DECnet IV with sys$manager:netconfig.com, DECnet IV with sys$manager:net$configure.com.
http://h71000.www7.hp.com/doc/

You could configure 2 LAN failover devices, one node to node, the second to your switching. For reliablity, I'd want to allocate one port from each NIC to each failover device.

SCS, cluster traffic will just work.


Welcome to the VMS forum.

Andy

[Thomas Ritter]

Thomas, since 7.3-2 SCS traffic is no longer dedicated to a single network path. The PE driver will us all available network paths, but will perfer the path with the best throughput.
Have lots of inter connects and and you will have plenty of interconnect redundancy. IMO with the perfomance of network switches you could have one logical gigabit ethernet for all you cluster and network communcations. Physically it would be configured to avoid single points of failure due to hard problems.
The days of coaxial able providing cluster interconnects are not missed.
My AUS 2 cents.

[Volker Halle]

Thomas,

re: LAN Failover

LAN Failover is not supported for point-to-point connections. Refer to 'LAN Failover restrictions' in the manual cited above.

Maybe use LAN failover (one port from each NIC) to connect to your switches.

Use the point-to-point connections for SCS and DECnet. Multicircuit end nodes should work and may even do load sharing.

Volker.

[Ian Miller.]

I don't think you need lan failover. Connect the copper lan connections using a crossover. Cluster traffic will use all or you can use SCACP to set a management priority so it prefers to use certain connections but will use the others if necessary. Configure DECnet to know about the two copper connections. It will either use both or failover (I forget which I think the behavior is different with DECnet/Plus and DECnet Phase IV).

[Thomas Griesan]

Thanks everyone!!!

Answers: Decent Phase IV. No serious bandwidth/traffic requirements. Yes, redundant switching is available. BTW, this is 8.2 of VMS.

The comments pretty much confirm my hopes/plans.

I'm thinking to hook the fiber NICs directly together with one port and also hook the copper NICs directly together with a copper crossover.

Then put both node's remaining copper port to one switch and both node's remaining fiber port to another switch.

SCS will take care of itself as folks say, so that leaves me with configuring Decnet IV and TCPIP. As you can tell, I'm not a big network guy. ;-)

I need to go figure out how to check the speed/duplex settings. This is all stock stuff so I presume everything is set the same. Does it need to be full duplex? DUH. ;-) I read that with gigabit, that auto-negotiate on the speed is now recommended.

I would want decnet to pick one or both of the direct connections first, then the ethernet/switch route.

I would want IP to pick fiber first, then copper to/from the switch.

This is really ULTRA redundant and probably overkill but we might as well use what we have.

Thanks for the welcome Andy. I was a long time Deccie. 17 years managing the CSCTLS (Champ/CSC) VMS cluster in the Customer Support Center in Colorado Springs. Then I got layed off - BIG SURPRISE, hahahahaha... I'm on a little one-month contract doing some VMS sys admin, then its back to layoff limbo. ;-)

Ahhh, the beauty of being a nearly extinct dinosaur. ;-) Gimme a holler if you need a big ole useless lizard. ;-)

VMS, RDB, ACMS, SQL, 3GL languages - you know the drill. griesantomjean@msn.com (719)632-6565

[Colin Butcher]

The RX series will do auto-negotiate. I don't know of a way to lock the speed / duplex at EFI console level. Use LANCP DEFINE DEVICE instead.

Gigabit Ethernet devices are best left at auto-negotiate. Fibre GigE direct to Fibre GigE works fine in auto (or at least it does for the GigE NICs in a pair of DS25s that are directly connected to each other).

LANCP should let you lock the speed & duplex on non-GigE devices. A cross-over cable should be fine, but YMMV.

DECnet-Plus will do a much better job of multiple paths than Phase IV. You'll get load balancing and path failover for the price of the end-node licence. Set Phase V up to use the two paths you want and make sure that they are truly separate, then use Phase IV style addressing on both.

See http://h71000.www7.hp.com/openvms/journal/v5/index.html#decnet for some of the DECnet background.

failsafe IP will let an IP address migrate from one NIC to the other. Set the two IP NICs up with their own specific addresses, then use failsafe IP to manage the "service IP addresses" that people will connect to. Don't think in terms of a single IP address any more - think in terms of one (or more) IP addresses per service that your systems are offering.

See http://h71000.www7.hp.com/openvms/journal/v2/articles/tcpip.pdf for more info on IP.

Remember to disable SCS on adapters where it's not needed, such as the main network. Use SCACP to control SCS.

Given the choice I'd use GigE for the dual SCS connection between the machines, plus DECnet and use the others for IP connectivity to the outside world. Worth configuring silly IP addresses on the cross-linked pair too, if only for someone to be able to use PING as a test.

Any other protocols in use such (eg: LAT)? If so then control which adapters they start up on too.


Cheers, Colin.

[Ian Miller.]

OT - Thomas, you may wish to post your CV to
http://www.openvms.org/phorum/list.php?3

[Kris Clippeleyr]

Re: Colin

The RX series will do auto-negotiate. I don't know of a way to lock the speed / duplex at EFI console level. Use LANCP DEFINE DEVICE instead.


Please see the discussion on settings of the network devices in thread
http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=675002

Last year, at the Bootcamp, I was told (I think it was Andy, but I'm not sure) that the only way to set the speed and mode of the network devices on an RX-series is using the LANCP utility (at least with VMS).

FWIW,
Kris (aka Qkcl)

[Robert Gezelter]

Tom,

To embroider slightly on Colin's comment. "Silly" should mean an RFC 1918 (intranet) address block that the site is NOT using. Thus, you will not end up with a addressing or routing problems vis a vis the intranet or the internet in the future.

I also agree with Andy, there is little that can go wrong with a null modem (reversal) cable. The only failures in a steady state are broken connectors. Vermin nibbling on the cable can also be a problem (up to and including fork lifts and backhoes).

- Bob Gezelter, http://www.rlgsc.com