AnsweredAssumed Answered

System architecture for redendancy

Question asked by flost Champion on Apr 3, 2017
Latest reply on Mar 7, 2019 by manishmakwana

Hi all,


during the last days I´m digging all avlaible PI System documentation about the topic redundancy. Some parts are clear for me and other parts left me with questions. I will share my concutions with you and also my questions so that - hopefully - a overview for the whole PI System will be the result and other can profit from it.


There are three main parts which have their own challenges:


1) Data Collection (aka Interfaces)

2) Server components

3) Clients


On the data collection and the client side I have experiance but for the server components I need some help (so my experiance is limited to a single PI Data Archive with a single PI AF with SQL onboard):


1) Data Collection (aka Interfaces):

Here we have the internal rule that every Interface must be redundand if the data source itself is not able to store data. So OPC-HDA, Databases or file-based sources have no redundand interfaces. This reduce complexitiy and maintainence efford. But if there is a bussines need to have the data avalible without delay we have some of these interfaces redundand.

With this basic rule we make sure that data loss isn´t a topic of the PI System (if configured and maintained propperly).


In general we have a separate network for each building and within every network we have two Interface Nodes. So we are indipendent from data sources which is especially good for maintainence of my PI System. So I can have updates without having dependencies with vendor software or the lifecycle of the components we collect data from.

In the field of hardware we had a journey from Industrial PCs for mounting in electric cabinets over Industrial PCs in 19" format for mounting in standard IT Server Racks towards normal 19" Server Hardware. I don´t like to go into detail but I want to explain a bit why we did the steps: In the first hardware generation we hat problems with soldered components. So that a exchange of defekt parts could only be done by the vendor. So we had to have similar IPCs on stock to be able to run an PIN in the time the defect one is repaired by the vendor. The second generation lacked of quality and despite the parts were able to be changed by ourself, the vendor did not provide a sufficent support model. So we changed to standard server hardware from our standard server supplier so we can participate on the support contract. Yes, I´m aware that some of the problems are special problems with the choosen vendor. Another reason is, that we created an proffesional IT-Structure in all our buildings. Since that we have IT-Rooms with 19" Racks and a propirate Envirinment in every building. And therefor is a 19" format is best for mounting IT-Systems.


Most interfaces from OSI can be configured with a redundand partner. We have good experiance with this feature. Today we use "HOT" failover so that all two interfaces are actively collecting data from the data source but only the primary interface sends data to PI Data Archive.

For the OPC-DA Interface (and maybe for other iterfaces) there is also a "server side failover" avalible. Here you can configure two data sources and the interface switches between this data sources. I have no good experiance with this feature (well my experiance is about 4-5 years old, in current versions it may work well). I prefere redundant interfaces with one data source for each.


3) Clients


We mainly use ProcessBook als client. We installed it in a Citrix environment (which provides several load balanced servers). Other Clients acces our PI Data via OLEDB. They do not need redundancy or use two SQL-Linked Servers.


So now I will come to the part were I need Information and experiance reports from you:


2) Server components:


Here we have three Components to take a look on:


2.1) PI Data Archve Server

2.2) PI AF Server

2.3) PI Vison


I asume that PI notifications will be installed on the PI AF Server. PI ACE is kept out of my thoughts because I will switch to AF analytics. If someone will use ACE I can say, that we have ACE installed on our AF Server (non redundand) and it works well.

The system I want to have redandency at PI Server side is about 30.000 TAGs in size and I will have about 5.000 Assets and about 30 notifications. After all compression an exception handling there will be about 2GB of data per month (there are about 400GB of data that already exists). In future I asume a growth to 50.000 TAGs and about 10.000 Assets. There will be no big growth in Notifications.


So here my thoughts on the three server components (physical Servers):


2.1) PI Data Archive:

I think for my needs is a standard Server enough (I think a Intel Xenon CPU with 10 Cores, 64GB of RAM and HDD storage - 100GB for Operating System; 80GB for PI root directory; 20 GB for Event queues; 800GB for Archives; at least 1GB network speed). Two of them should run as a PI Collective. PI Backup will be stored on another Server (e.g. PI AF Server).


2.2) PI AF Server and 2.3) PI Vision

I Plan to install them together. I think the same configuration as mentioned for PI Data Archive should be enough: Intel Xeon CPU with 10 Cores; 64 GB RAM and at least 1GB network speed. For redundancy reasons I will have two of them.


Here I have three questions:


Will it be sufficent to install the SQL-Server on the same servers (well maybo I will need more RAM in this case)? Or is it better to have two seperate SQL Servers?


How much Disk Space is nessesary for the two scenarios (first: AF, Vision and SQL-Server on same machine and two: AF and Vision on same machine and SQL separate)?


Is this design enough for my system? Or is another design better (e.g. seperate Servers for AF, Vison and SQL? or AF and SQL together and Vision separate? )?


And at least one final question:


Do you have experiance on system sizing for virtual production systems? How to design the environment here?


Thanks for taking the time reading this and Thank you in Advance fopr your answers an shared experiance!