We're going to talk about server high availability or in other words PI server redundancy.
The concept here is to configure multiple endpoints that users can connect to
for data ensuring that one is always available. This improves uptime in case we need to perform
maintenance or updates on any one server. We covered interface redundancy in the basic course,
mainly because I consider it to be an essential part of even the smallest PI System. The primary
directive of you, of a PI System administrator, is to have as close to zero data loss as possible,
which is why we need interface redundancy for. Here though we're talking about PI server
redundancy. Having two PI servers gives us a lot of flexibility in managing the system without
downtime for users. When we have a highly available system with a lot more freedom
and users have a much better experience. It also builds trust in the system. Interface redundancy
reduces data loss, PI server redundancy reduces downtime for users retrieving data.
We'll talk about PI data archive and asset framework redundancy in this video, but they
work very differently from each other. First PI data archive higher availability or HA for short.
To set this up you install two PI data archives of the same version
then you run PI collective manager and configure your two PI data archives to be in a collective.
You choose which one is the primary and which one is the secondary.
The collective manager will automatically move all the data from the primaries to the secondary and
set them up to be a replication of each other. No special hardware is needed. You don't even
need the same hardware specs on both machines and really it just works.
If you're doing this to an existing server and you choose it to be the primary server,
collective manager will replicate all data over and all interfaces and other applications that
are configured to use the PI buffer subsystem that are already sending data to the primary,
automatically start fanning data to the secondary as well. All your tags and security settings
are synchronized to the secondary. After the collective is up and running users by default
automatically connect to the primary and then if that fails, they fail over to the secondary.
Essentially, it's a client-side failover. The servers don't communicate with each other, on
which one is up, and which one is down, a client will just try to connect to whichever one is
available. In this class we'll be doing this with PI data archives installed on PISRV01 and PISRV02.
Now for asset framework works a little differently but much more similarly to other
server applications you would have come across like web servers. To set it up you'll need to
install the same version of asset framework on two different machines and point them both to the same
SQL backend database. Optimally you'll have a highly available SQL backend as well
using a supported configuration and see the references on this lesson for details on that,
and while this would work with the two different machines and users connecting
independently to them, users need to know which AF to connect to and they need to switch servers
by themselves. And we don't want to rely on them for that. So, we configure a network load
balancer between the users and the AF servers. A network load balancer essentially exposes
both of the servers as a single name on the network and any user requests that come in,
it will send them to either of the servers. It'll balance the traffic. And with that
we know how it works. In the next few videos, we'll go about configuring this.