|
      
 Redundancy
Master
RedundancyMaster increases the reliability and availability of
OPC data by allowing multiple OPC Servers to be configured into
redundant pairs. These redundant OPC Server pairs seamlessly appear
as a single OPC Server to any OPC Client application.
RedundancyMaster can be a drop in
application that does not require you to
make any changes to your OPC client or
server applications. Its intuitive
configuration takes only minutes and
will allow you to have a redundant OPC
system running with no headaches.
|
|
| |
Broadcasting Proprietary
Ethernet IP Data
This diagram shows how the
proprietary Ethernet IP data
is manipulated within the
plug-in device driver of
KEPServerEX to become OPC
Data, which is then served
out to the OPC Client in a
basic redundant system.
|
|
Local Machine Redundancy
This scenario has the OPC
Client, RedundancyMaster, and
the Secondary OPC Server
residing on the Local Machine
with the Primary OPC Server on a
Remote Machine. In this scenario
be sure to make the most
reliable Server your Secondary
OPC Server. This scenario also
reduces the need for another
machine to run the Secondary OPC
Server. |
|
Single OPC Server Pair
Redundancy
This is a standard use diagram
for one Server Pair where
RedundancyMaster resides on the
same machine as the OPC Client,
and the two OPC Servers are on
remote machines.
|
|
Multiple OPC Server Pair
Redundancy
RedundancyMaster can be
configured to have multiple OPC
Server Pairs. In this diagram
there are two pairs of OPC
Servers which are gathering data
from two separate device
networks. If the multiple OPC
Server Pairs are all of the same
ProgID (KEPware.KEPServerEx.V4),
then you will need to use the
Aliasing feature; if the two
pairs have different OPC Servers
with different ProgIDs then you
will not need the Aliasing
feature. |
|
|
|
Pricing
| Software |
Price |
| Support for a pair of OPC
Servers |
US $1,295.00 |
|
  |
|
  |
 To
purchase a Kepware product and receive an authorization code visit
our
on-line
store or fax your company purchase order or credit card
information to 1-(303)-679-8698.
Redundancy Configurations
Primary/Secondary Machine Names
Browse for the primary machine
which specifies the preferred
connection that should be made
to an OPC server and the
secondary machine which
specifies the fallback
connection that should be made
to an OPC server when
communications to the primary
machine are unavailable. Every
time a new client connection is
made to the underlying server,
the application will first
attempt to make a connection to
the server running on the
primary machine. In the event
that the connection to the
primary fails or communications
to the primary is lost, a
connection to the secondary
server will be attempted and, if
available, established.
Depending on the connection
mode, you can configure the
application to automatically
establish communications with
the primary machine when it
becomes available.
Connection Mode
The connection mode defines how
and when the redundancy
application should connect to
the underlying primary and
secondary servers. The mode in
which you operate affects the
amount of time it takes to fail
over from one OPC server to the
other. Some modes allow you to
automatically promote
communications to the primary
when it is available. The
following summarizes connection
modes:
| |
Cold (Active machine
only): |
| |
In
this mode, the
application will only
connect to one
underlying server at a
time. On startup, a
connection to the
primary server will be
made and all client
related requests will be
forwarded onto the
primary. In the event
that the connection to
the primary fails, or
communications to the
primary is lost, a
connection to the
secondary will be made.
If the redundancy
application is unable to
obtain a connection to
the secondary, it will
continue to ping-pong
between the two servers
until it makes a
successful connection.
The 'cold' connection
mode minimizes the
amount of system
resources that are
allocated since there
will only be one
connection to one server
at any given time. It
also reduces network
traffic since there is
no need to poll the
inactive machine in
addition to the active
machine, as in other
modes. The drawback to
this setting is the
amount of time it takes
to fail-over to the
inactive server. When
communications loss is
detected with the active
server, the application
needs to establish the
connection to the
inactive server,
subscribe to all items
on behalf of the client
and initiate the
appropriate callback
mechanisms.
|
| |
Warm (Both machines,
subscribe to items on
active machine): |
| |
In
this mode, the
application will attempt
to maintain a connection
to both the primary and
secondary servers at all
times. On startup, the
application will
initialize data
callbacks for the
primary server only. In
the event that the
connection to the
primary fails, or
communications to the
primary is lost, a data
callback will be
initialized for the
secondary server.
Periodically, both
servers will be pinged
to determine if the
connection is still
valid.
The 'warm' connection
increases the amount of
system resources that
are allocated, since
there will be two server
connections made on
behalf of the client.
There is also a minimal
increase in network
traffic due to
periodically pinging two
servers instead of one,
as in 'Cold' mode
operation. The benefits
are that fail-over time
is minimized over 'Cold'
mode operation, since
the redundancy
application will only
have to initialize data
callbacks to the
inactive server to begin
receiving data. If you
need to minimize the
loss of data in your
application, and at the
same time want to
minimize network
traffic, you should use
this connection mode.
|
| |
Hot (Both machines,
subscribe to items on
both machines): |
| |
In
this mode, the
application will attempt
to maintain a connection
to both the primary and
secondary servers at all
times. On startup, the
application will
initialize data
callbacks for both
primary and secondary
servers so that both
servers will send data
change notifications.
The data received from
the primary server will
be forwarded onto the
client. In the event
that the connection to
the primary fails, or
communications to the
primary is lost, data
received for the
secondary will
immediately be forwarded
onto the client. In
either case, writes will
only be forwarded to the
active server.
Periodically, both
servers will be pinged
to determine if the
connections are still
valid. If at anytime the
redundancy application
loses communications to
either server, it will
periodically attempt to
reconnect to the failed
server.
This setting increases
the amount of system
resources that are
allocated, since there
will be two server
connections made on
behalf of the client.
There is also an
increase in network
traffic due to receiving
data change
notifications from both
underlying servers, as
well as periodically
pinging both servers to
determine if they are
still available. The
benefit of this setting
is that fail-over time
occurs immediately after
detecting the loss of
the active server. If
loss of data is very
crucial to your
application, you should
use this connection
mode.
|
OPC
Server Aliasing:
This feature will allow you to
configure multiple pairs of OPC
Servers with the same ProgID
(KEPware.KEPServerEx.V4). This
feature permits you to use one
OPC Server vendor if you have
multiple OPC Server nodes on
your network. This will allow
OPC clients to connect to a
specific redundant pair by
referring to the aliased ProgID
of that redundant pair.
Always connect to primary
machine upon availability
This setting enables
RedundancyMaster to
automatically promote
communications back to the
primary machine when the OPC
server becomes available.
Query
Server Status Interval
This interval (specified in
milliseconds) determines how
often RedundancyMaster will ping
the underlying servers to
determine if there has been a
loss of communications. By
querying at a faster rate, you
can minimize fail-over time
since failure detection occurs
more frequently.
Query
Server Status Timeout
This interval (specified in
milliseconds) determines how
long the redundancy application
will wait for a ping response
from the underlying servers
before considering there to be a
loss of communications.
| |
This
feature allows you to
configure certain
conditions which will
initiate a fail-over to
the inactive server.
These conditions allow
you to monitor server
items for specific
states to determine the
health of the underlying
servers/devices, above
and beyond the automatic
fail-over that will
occur due to the loss of
communications.
|
| |
Preserve events to disk
on shutdown: Events will
be preserved to disk
when the application is
shutdown. The next time
the application is
started, the events will
be displayed and any new
events will be
concatenated to the end
of the view.
Maximum number of events
to capture: Since
diagnostics utilizes
memory and storage
resources, you may want
to limit the number of
diagnostics that are
preserved at any given
time. Once the maximum
number of events has
been reached, the oldest
events will be discarded
as necessary.
|
| |
This
feature allows you to
configure one or more
recipients to receive
email notifications for
one or more diagnostics
events. The events that
are available to send as
email notifications are
the same events visible
to the local Diagnostics
Settings event view.
|
|
|
|
|
|
|
|
|
 
|
|
|
|
