5 Replies Latest reply on Mar 7, 2019 12:45 AM by manishmakwana

    System architecture for redendancy

    flost

      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!

       

      fLOSt

        • Re: System architecture for redendancy
          Ikorablev

          Hello,

           

          I can use this tool to estimate the hardware needs for different products:

          https://techsupport.osisoft.com/Downloads/File/8d7f6f38-2ed3-43f3-a7f5-a15789e6bca7

          It should answer most of your sizing questions.

           

          Concerning architecture questions:

          1. Setting up SQL Server on same machine with PI AF and PI Vision is possible, but, as you said, the more RAM you have on such machine - the better. The amount of RAM needed depends on the size of AF Database(s), number of displays in PI Vision, number of users connected, expensive queries, e.t.c.

          For PI Vision we recommend to use the same MS SQL Server that PI AF uses.

           

          2. Concerning virtual environment.
          The main OSIsoft recommendation to size your VMs is:Treat your VM's as an actual hardware. It directly applies to sizing as well.

          • Re: System architecture for redendancy
            John Messinger

            I generally avoid running SQL Server and the PI AF application on the same server in a production environment, as resource contention is an issue to be concerned with. Until I knew details on the other aspects of your system such as how many AF databases and objects you are using, how many users and applications/external systems will be accessing your PI AF system, I would be uncomfortable with considering running both SQL Server and the PI AF services on the same box. You indicated expected growth to about 10K assets, but what about analytics on those assets?

             

            Whilst OSIsoft's recommendations in the Live Library seem to indicate running PI AF and SQL Server on the same box is OK, my own past experience with some larger customers has shown performance issues doing so. The other part of this is where do you plan to install the Analysis service? Depending on your anticipated analysis load, you may want to consider where this goes. Again, I have a couple of customers that run this service on a separate server from the main PI AF service to reduce resource contention.

             

            Likewise with your PI Vision server. What is your projected usage of PI Vision (number of users, etc)? Will having a higher number of users accessing the web server contend for resources if SQL Server is running on the same machine? Again, I would likely be looking to run PI Vision on it's own server separate from both the AF application server and the SQL Server.

             

            John

            1 of 1 people found this helpful
            • Re: System architecture for redendancy
              manishmakwana

              Hi fLOSt,

               

              What did you end up doing with your system design? I'm currently exploring something similar: fully redundant PI archive servers, AF servers, ACE, SQL. However I've realised that this can add tremendously to the complexity and cost of the system. I'm keen to hear what's practical and established.

               

              Regards

              Manish