Cluster communication with a firewall "vault"

[Russ Carraro]

Customer is building a site "vault". It's a virtual "vault", I believe this as firewall software running on there network servers. They have a cluster sonsisting of three Alpha 2100s running OpenVMS 7.1 and UCX 4.5. The vault allows DECNET traffic within the vault but not into or out of the vault. They moved similar clusters at other locations into a vault with no problems. However, for their latest site they are talking about moving only two of the three Alphas into the vault.

Can a they maintain a 3 node cluster if two of the nodes are in the vault and 1 is outside the vault? I'm wondering about cluster communication since DECNET traffic would be blocked between the node outside the vault and the two inside the vault.

[Oswald Knoppers_1]

Cluster communications (protocol type 60-07) is not the same as decnet. The firewall must allow this traffic.

Oswald

[Hoff]

Virtual Vault meaning exactly what?

Firewall-protected subnet? (Probably an expensive and arcane example of that, given the obfuscated terminology.)

If DECnet via DDCMP and DECnet via IP is blocked from the protected subnet at the firewall router, then chances are that SCS traffic is also blocked.

Which means yes, they have to punch a few protocols through the firewall, if they want the cluster to operate.

Check your product versions, too. You might see UCX V4.2 on a V7 release (since unsupported), but it's more common to see V5.0A or V5.1 or later on V7. (I don't recall there being V4.5 release, either.)

The AlphaServer 2100 and the associated storage is not cheap to maintain, either, and that's easy to port that to a small fraction of the power and space, and with vastly better disk reliability, too. More than a few of those had RAID-5 (also known as fictional RAID), and that's really nasty during recovery from failed disks, and disks of the same vintage as the AlphaServer 2100 series are falling over all over.

[Jan van den Ende]

Russ,

As Oswald noted, the firewall (AND all intervening network devices) should allow SCS protocol.
And it can NOT be routed!

The only alternative is to move to VMS 8.4 on ALL nodes, and go IPCI (IP ClusterInterconnect).
But that is REALLY brandnew, and I would not yet consider VMS 8.4 "production ready". YMMV.

Should you go IPCI anytime soon, be sure to get HP (and here that means VMS Engineering!) involved; and report your experiences here, please.

Proost.

Have one on me.

jpe

[Russ Carraro]

Sorry, mistyped - UCX is V4.2 ECO 5.

Yes the equipment is old. Their plan is to eliminate the hardware by running their applications on OpenVMS emulation software (still at OpenVMS V7.1).

I'll have to find out if it's being routed.

[Robert Gezelter]

Russ,

I concur with Hoff, et al. I would expect SCS traffic (which is neither DECnet nor IP) to be blocked. I also note a major security issue: SCS traffic is not encrypted, and the security of the cluster depends on that traffic being safe.

Use extreme caution. This could create a major security and integrity problem in the OpenVMS cluster.

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

[Hoff]

Pragmatic answer follows...

DECnet and SCS are unrelated.

SCS can be routed.

SCS can be routed via various transports, given the appropriate networking gear.

And that's been possible long before the arrival of V8.4, too, given a sufficiently fast site-to-site link or managed switch.

There's some old stuff on this topic in RFC 1638, and likely some other RFCs. That RFC is from 1994, and DEC and Cisco both had products in this space an eon ago. Certainly other vendors, too. I first used these SCS bridging schemes late in version 4 series, shortly after SCS was deployed via Ethernet. That was a LONG time ago.

There's a picture of this layout in the manuals, too:

http://www.openvms.compaq.com/doc/732final/6318/6318pro_026.html

Now with more details on what this "vault" really is and why it's particularly superior (or inferior) to a plain old firewall and subnet, or circa level-3 managed switch, well, that has yet to be determined.