Dual-redundant networking

  • Thread starter Thread starter Tim Baldwin
  • Start date Start date
T

Tim Baldwin

I'm trying to configure a local network for an industrial application using
2 duplicated W2K servers and a suite of W2K workstations as HMIs. The
application is mission-critical, so the LAN and associated hardware must
also be duplicated (i.e. two identical nectworks, both of which are
connected to all platforms through their own ports). Ideally, I either need
a dual-port PCI LAN card that can perform the split to the two networks
transparently to the application stack, or failing that, stacks (TCP/IP and
preferably NetBEUI as well) that split as low down as possible. Either way,
the application must see a single stack interface, and the system must have
a means of detecting and reporting failures on either LAN. The critical
applications generate continuous background traffic, so there is no specific
need for heartbeats.

Does anyone have any suggestions for suitable off-the-shelf hardware and/or
software drivers. I've tried the usual suspects, and trawled the web and
newsgroups, but with no success.

Thanks in advance
 
This question illustrates why software engineers should not play with
hardware...

As I understand it, you want a highly available LAN. Is this correct ? What
is your budget?
Netbeui ??? Whatever for? You really dont want to run all your traffic over
2 protocols...

This is the kind of thing that consultants get paid a lot of money to design
and impliment.
You are talking about a serious endeavor, not just "what nic do I use, and
software do I install to make it work".

Before anyone can start telling you that you need X NIC's, and Y drivers...
its essential to know what your app does, and how it works. Is it a web
based app, or a client server application. Does it use a database backend,
and if so, which one. Is it an N-Tier appliacation ? What technologies are
in use ?

There are no easy answers without a complete understanding of what you are
working with.

NuTs
 
Sounds like you are looking for the words "teaming" and "load balancing" or
"clustering." Teaming is when you have two identical server nics (not
desktop nics), which can be teamed via software. Most major server vendors
have this available. That gives you the redundancy on each server that you
need: should one nic fail, the other takes over, etc.
As for server redundancy, you have the load balancing option, or if the the
app is cluster-aware, you could use clustering (servers must be identical
and usually require a shared storage device). Each server would also need
fault tolerant parts, dual-cpu, dual power supplies - each one going to
separate PDU>>UPS, dual memory daughter-boards if possible, etc, etc...
As for "network" redundancy/availability, you will need multiple switches,
cable runs, battery or generator backup, etc. Each nic and/or
clustered/load-balanced node runs to a different switch, etc.
I don't see why you would need Netbeui - it's obsolete and not routable.
Don't know what "HMIs" are either.

Good luck.
 
For your information, Crack Nutter, I started life as a hardware engineer.
No matter.

I'm just trying to meet a spec put up by a prospective client. Given the
choice, I wouldn't be doing it this way at all, but it's kind of hard for a
(very) small OEM to tell a major national oil company not to be so dumb.

Also, given the choice, I would far rather have nothing to do with NetBEUI,
and just stick with TCP/IP, but again I may not have that luxury (our client
hasn't made up his mind yet what other applications he wants beside the
server and HMI apps, so I have to keep the protocol options open).

The LAN(s) are to be local, isolated (no, not even a fire-wall) and
definitely not web-based.

The server app and associated HMIs are off-the-shelf SCADA applications
(which handle their own data synchronisation and updates). The servers
operate in a duty/hot standby configuration, and the HMIs are clients of the
duty server (changing over automatically as required). Since the apps are
proprietary, I don't know the details of how they connect, but from the
user-configuration options they offer, I'd say the HMIs run two TCP/IP
stacks, with an open socket on each, to each server, but request updates
from the duty server only.

I'm looking for a ready-made solution. The scale of the application doesn't
justify engineering our own. Because the application caters for only one IP
address per server, and I can't change that, I need the stack to split
somewhere below the IP layer, so it looks like just one stack to the app.

Dual-redundancy is a common requirement in the process control industry, but
since it's very much at the cinderella end of DP, it wouldn't surprise me if
still no-one's bothered to come up with a solution.

Tim
 
Tim Baldwin said:
For your information, Crack Nutter, I started life as a hardware engineer.
No matter.

I'm just trying to meet a spec put up by a prospective client. Given the
choice, I wouldn't be doing it this way at all, but it's kind of hard for a
(very) small OEM to tell a major national oil company not to be so dumb.
Click to expand...

You need to manage the customers expectations. This is always a balancing
act. Product Knowledge is the key, here as it will give you the ability to
field rebuttles and make your sale.
Also, given the choice, I would far rather have nothing to do with NetBEUI,
and just stick with TCP/IP, but again I may not have that luxury (our client
hasn't made up his mind yet what other applications he wants beside the
server and HMI apps, so I have to keep the protocol options open).
Click to expand...

If the network is islolated (yet routable), netbeui will not suffice. It
cannot be routed. Its chatty, and when on a network that is also configured
with TCP/IP, every packet is sent using both protocols. This cuts your
network efficiency in 1/2, and increases retransmissions due to broadcasts
that result in collisions.
The LAN(s) are to be local, isolated (no, not even a fire-wall) and
definitely not web-based.
Click to expand...

Are there to be any segments, or different address spaces on this LAN ? are
there remote locations that need to connect to this application ?
The server app and associated HMIs are off-the-shelf SCADA applications
(which handle their own data synchronisation and updates). The servers
operate in a duty/hot standby configuration, and the HMIs are clients of the
duty server (changing over automatically as required). Since the apps are
proprietary, I don't know the details of how they connect, but from the
user-configuration options they offer, I'd say the HMIs run two TCP/IP
stacks, with an open socket on each, to each server, but request updates
from the duty server only.
Click to expand...

A windows box can only run 1 IP protocol "stack".

HMI... is that some kind of kiosk based interface system, or just another
fancy industry term for a terminal, or workstation ?

SCADA.. Supervisory Control And Data Aquisition ... something for
manufacturing and process control. This information isnt very relevant. If
both systems rely on a design that requires IP, then stick to the IP portion
of the discussion. This is superfluous information to most of us, and not
germain to the LAN question.
I'm looking for a ready-made solution. The scale of the application doesn't
justify engineering our own. Because the application caters for only one IP
address per server, and I can't change that, I need the stack to split
somewhere below the IP layer, so it looks like just one stack to the app.

Dual-redundancy is a common requirement in the process control industry, but
since it's very much at the cinderella end of DP, it wouldn't surprise me if
still no-one's bothered to come up with a solution.

Tim
Click to expand...

First: you cannot have 2 seperate, duplicate windows IP based networks with
the same IP scheme, and have 1 computer on both at the same time. For one, a
machine cannot have the same IP address on two seperate interfaces. Nor
could a machine try to talk to another machine on such a network, as there
is no way to tell the machine "which" network interface to use. This is
based on the statement you made where it needs to be able to actively switch
from one network to the other automatically (or some such thing).

What you can do:

You can create 2 physical networks, and use 2 NIC's in each machine, and use
the same address space. However, only one of the networks would be in use at
any time (from a machine perspective). This would require a seperate switch
environment for each network, and you would need to use the Spanning Tree
protocol between the switches. The NIC's would need drivers that allowed
them to be grouped into a virtual interface, and be configured to fail over
in the even of a switch or NIC failure. Servers would have 2 nic's as well.
This is called multi-homing,

For NIC, depends on the machine MFG. If they are a big Petrolium company..
they wont balk at using HP or Dell or IBM, in that order. They all have
teaming capabilities on thier adpaters.

For the application, no reason not to have it clustered. In order to have a
cluster, you need shared storage (fibre channel is preferrable, but shared
SCSI will do if absolutely necessary).

I have given you all the raw pieces that you need to build a highly
available LAN. Now its up to you to determine how you are going to become
familiar with these technologies, and come up with a clean, pristine
presentation to your client.


NuTs
 
Thanks for the response, Server Guy, but it demonstrates how the gap between
the DP and Process Control communities can sometimes trip you up - we may
use the same terms, but they don't always mean the same things. Let me
explain what I mean by the terms I used, including some that seem very
familiar:

HMI is "Human Machine Interface". In this case, it's just a graphical and
list-based application providing displays of dynamic data coming from the
servers, which allow the user to select how the information is presented,
and also send back control commands.

By "Server", I'm not talking about a static data server, but one that
autonomously gathers data in real time from external processes (i.e.
industrial plant process parameters, GPS data from sea-going vessels,
weather and sea conditions, etc.) under the control of a proprietary server
application, which processes, logs and records the incoming data, then makes
both current and logged data available to the HMIs. The HMI apps are clients
to the server apps. The servers and HMIs together constitute a SCADA
(Supervisory, Control And Data Acquisition) system.

In fact, the servers act in a "duty/hot standby" configuration, i.e. only
the duty server is scanning the field for new/updated data, and provides
data to the HMIs (i.e. the servers don't load share). The duty server is
also responsible for maintaining data coherency with the standby server,
updating it as it receives data, and also synchronising it with logged and
historical event data if it has missed any ("catch up"). The SCADA
application publishers describe the servers as "cluster-aware", although it
doesn't sound like they mean the same thing you do by the term.

Physically, the servers will employ the redundancy measures you suggest,
such as hot-swap dual PSUs, supplied by independant external UPSs (the UPSs
supply all the critical plant instrumentation, so have battery banks that
fill rooms), mirrored (RAID1) HDDs, and ECC RAM.

As for the NIC configuration, "teaming" sounds closest to what I'm looking
for, although it would have to apply to the network clients as well as the
servers, because there would be two indentical but entirely separate LANs
(i.e. no bridges or switches linking them), and all platforms in the system
(servers and HMIs) will connect to both LANs via separate ports (i.e. two
per platform). It would be preferable if the two ports were actually on
different cards (to minimise the scope for common-mode single point
failure), but however it's organised physically, the two connections must
appear to be a single stack to the SCADA applications, because they're set
up to use only a single IP address. This is why I talked about a split
stack.

I don't care particularly how sophisticated the split is. It would be nice
if the traffic was shared evenly between the two LANs, but it will be low
enough to produce a very low collision rate on a single 100baseTx LAN, so
all of it could be directed down one side, as long as the other is
periodically checked for availability.

As for NetBEUI, I agree. Given the choice, I would prefer to stick
exclusively with TCP/IP, but my customer may want to run auxiliary
applications that require NetBEUI, so I may not have the choice.

Tim
 
Back
Top