Almost every service we've mentioned in this class can be moved off to another machine
and many can be made into redundant services. With this in mind let's go through each component and
under what conditions would expand our system and add more machines. We're not going to do
all of this in class but it's good to go through what our decision process would be if we wanted
to make our system larger. The architecture we ended up with in this class is fairly close to
what you'd see in a smaller production system, minus the fact that we're using a single SQL
express server, we've mentioned that already, and we're only using a single interface instance.
If this was a real production system, my eyes would widen, and I wouldn't close them until
I had a redundant interface instance running. In a real system we'd have lots of different
types of interfaces and each one would be set up as a redundant pair in union failover.
We might have some connectors thrown in there as well, if you're interested in connectors,
I'll throw some documentation over to the side. So, we covered union failover in the basics class,
but this is how it interacts with PI data archive collectives. If we were to add another interface
machine to our infrastructure here let's call it PIINT02 the setup here would be
exactly the same as in the basics class except one very small difference. In the ICU under the
PI host information, we'd set the SDK member to PISRV02. This makes the interface pair slightly
more robust if there's an outage. Okay so we have both interfaces set up and buffering to
both servers. We'll assume that we're using hot fail over here. In hot failover both interfaces
are reading from the source at all times but only one of them is sending data to both data archives.
If the interface can't connect to one of the data archives it'll buffer data for that archive but
continue to send data to the other one. Once it comes back the buffer will flow through.
If the primary interface goes offline the backup will start sending data to both collective members
straight away. With this whole setup you'll be able to have up to two failures,
one interface and one data archive and still have zero data loss and 100 uptime for users.
Okay. Let's talk about making other improvements to our system. The first improvement would make
would be for performance reasons and we'd move the analysis service away from the data
archive service. The reason why we do this is to alleviate resource contention. We see this
if analysis calculations are running behind and it's struggling to keep up and you'd know this
was happening if users were complaining to you that they're not seeing their calculation results
when they're meant to be, or the analysis service is taking a noticeable amount of memory and CPU
resources away from the data archive. To move the service off we'd stop the analysis service
on our data archive then install the analysis service on the new machine by running the
PI server install kit, set it up then do a little configuration and set up buffering.
See the documentation reference on this lesson for more information. This will make our
architecture more into a recommended topology and it's fairly close to most PI Systems I see
out there in the wild. If you determine that the analysis service is business critical and
uptime is a high priority, you need to use windows failover clustering if you want redundancy here.
See the references for details on that. The next move that makes sense would probably be
moving asset framework away from the data archive servers. We'd do this if users were using the RTQP
engine to query data. The RTQP engine needs to be installed on the same machine as the AF server.
The RTQP engine is pretty heavy on resource consumption, and it'll compete for the data
archive for memory use if it's installed on the same machine. To move our AF servers off we'd
install AF servers on new hardware and then point the network load balancer to the new AF service.
Then we'd remove the services from PISRV01 and PISRV02 and remove their records from the
network load balancer. Easy! The other benefit we get here apart from performance is security.
We can now remove our AF servers from the DMZ network between our corporate network and
our process control network. AF really doesn't need to be in a DMZ because it doesn't connect
downstream. The less services we have installed close to the process control network the lower
our attack surface and the better we're doing. Now let's talk about adding more data archives. First
off, we'll talk about accessibility. The golden rules with server placement are keep interfaces
as close to the data source as possible and keep PI servers as close to the users as possible.
When I say close here, I mean both geographically and from a network standpoint. So, if we have a
remote site with a shaky network, for example an offshore oil platform, and site users need PI data
in their control rooms for critical operations and our network is unreliable between our site
and our corporate headquarters, we might consider having a data archive on site
and another one in our corporate headquarters. Now you'd think we could use the data archive
collective here, but collectives are intended to be in a similar geographic location.
High latency or lots of packet loss between them tends to make them fall out of sync and you need
to re-initialize them with a collective manager. Most of the time you wouldn't want a collective
that spans between corporate and site. Not to mention they'll probably be on different domains
or require different security configuration and collective synchronize their security settings,
so it probably won't work for you. In this scenario we usually set up a PI-to-PI interface or
a PI System connector. These services are similar in function to the OPC interface we know and love
but don't use an OPC server as a data source, they use a PI data archive as a data source. They read
data coming in to tags on one data archive and push it all to tags on another data archive.
So, we've just added another PI data archive for accessibility reasons, what about performance? If
your system is tall, well tall meaning approaching hundreds of thousands of events per second coming
in, you'd get that if you're using synchro phases, or the system is wide approaching tens of millions
of tags. Examples of this would be if you're using a PI data archive to store data from lots of well
heads or large solar farms, you should consider spreading your tags across multiple data archives.
There's not much to say here regarding configuration, you'd have to maintain the
servers independently and have different interface instances running to different data archives.
Next, PI Vision. We didn't install PI Vision in this class. You can see directions on how to do
that on the side if you want to. But PI Vision is a web application running on windows IIS. You
install it on a server, point it to a SQL backend that stores all the displays that users make
and then tell it which data archives and which AF servers should make available to users.
If you want it to be highly available you just install more than one, point from both
the same SQL backend and the same data archive and asset framework servers and stick a network
load balancer between the Vision servers and the users. Now the next question we usually get is:
can I put PI Vision on the internet? It's a web app so I can just put on the internet, right? Well
yeah, you can but it reaches down into the PI data archive, into critical business resources so any
normal security and rules your organization should have for something like this should be respected.
Most likely, you put your Vision server in its own DMZ between the corporate network and the nasty
dangerous internet over there, it's a wild west out there. Talk to your IΤ department for more
recommendations. I'm sure they'll have them. The good thing here is that PI Vision itself
isn't too different from many other corporate web applications and you should be able to
work out a solution with IT. And lastly one day, if it hasn't happened already,
a data scientist is going to come and ask you how to get data out of the PI System.
You're going to ask them: “What data you want? and in what format?” and they're going to say,
“Oh I want all the data in a txt file”. It's something like that. You'll have noticed by now
that the whole PI data archive is designed around efficient storage and delivery of production data
and sticking the whole thing into a text file isn't a really simple or even achievable task
for even a small system. Let's talk about how your friends in data science should be getting
data out of the system. They have a few choices here. They can get data out through our developer
technologies, most commonly by executing SQL queries against the RTQP engine service on
the asset framework server or by running PI AF SDK inside of python or something like that.
For exactly how to use these technologies check out our developer learning path linked in the
references. These options can work but it'll most likely result in huge performance drops
for other users while data is being extracted. A safer option is probably the PI Integrator
for business analytics. This is a service you install on a machine that makes scheduled queries
for data from asset framework and data archive and saves that data in tables or text files
or just streams it to the cloud. This solution is preferable because you've got control over
the load on the system, you can determine how often the data is updated and it's made to
efficiently extract a large amount of data and save it for access in exactly
the format that your data science friends want. And that's about all I wanted to talk about here.
There are many more components in the PI System. I recommend taking a look at the documentation
or making a post in the community if you have any questions on additional features or capabilities.