In this video we're going to talk about
the options you have with interface architectures and redundancy.
While we're discussing this keep in mind the golden rule of PI System administration:
"don't lose data!" When we're thinking about implementing a system or upgrading an old system
moving hardware your number one priority is to get as close to zero data loss as you possibly can.
We've done a few things that have caused data loss in the class so far
we've restarted our interface a few times and the buffer system a few times.
Anytime you've got an interface not running or restarting you're losing data; well it's
true with interfaces with no history recovery like the interface for OPCDA which is what we're using;
other interfaces can automatically recover missed history while they've been shut down,
you'll need to check the manual for the specific interface you're using for more information.
Now other causes of data loss are ungraceful shutdown of the Data Archive.
By default the Data Archive has up to 20 minutes of archived data stored in memory before it's
flushed out to the disk. If you pull the plug on a Data Archive you'll risk losing up to about 20
minutes of data by default. This is why we really recommend having an uninterrupted power supply ups
attached to the Data Archive. But apart from that we already have a buffer in
front of our interface so we should be good with network connectivity problems
if the Data Archive is gracefully shut down or the network simply goes out between the interface and
the Data Archive the device will happily buffer data until it's back and then flush through.
We're not protected for interruptions between the connection between the OPC server and the
interface. This is partly why we install the interface on the same machine as the OPC server;
best practice is to install the interface as close to the data source as possible because you want
that connection to be rock solid. We can reduce data loss in scenarios like this though by using
interface redundancy. So let's take a look at PIIINTO2 the OPC server on PI02 contains exactly
the same data as on PIINT01, it's a redundant OPC server connected to the same control system.
We're going to install and set up an identical interface on PIINT02
to read from it and then configure interface redundancy. After it's all set up only one of
our interfaces will be active at any one time, sending data through to the Data
Archive. If one fails the other one will take over. So let's see how that works,
both interfaces will look at a shared file keeping their health status updated inside it along with a
heartbeat. A heartbeat's a counter that counts up every second to 15 and then resets. So the other
interface pair can see that its partner is still alive. So these counters are also exposed in the
Data Archive as PI points and we'll take a look at those when we configure these later in the course.
When one interface sees something is wrong with the other one
or it's not updating its heartbeat it will attempt to take the primary role sending data to the Data
Archive. While we're configuring this, you'll see a lot of items on the user interface like hot,
warm, cold, these all know how active the backup interface is. While it's not actively writing
to the Data Archive what we're configuring in hot failover both interfaces are always
reading from their OPC servers, only one will be writing out to the PI Data Archive though.
The other simply doesn't send the data its collecting through. If the backup interface
detects a problem with the primary it'll instantly start writing data to the archive. It's already
connected to the OPC server. There's no delay in connection and then authentication and then etc
etc it'll just start sending the data. So you'll effectively get zero data loss in most situations.
So for more information on the inner workings and
any caveats check the documentation we're referencing to the side.