9 Replies Latest reply on May 18, 2011 9:12 AM by RJKSolutions

    Question on PItoPI deployment and architecture


      I'm involved in the early planning stages of what should eventually become over the years a 1.5M point PI System. The various development and testing teams will require real world data for their purposes, and we'll be using PItoPI to synchronize whatever points they need from the production environment. Currently, 5 PItoPI receiving nodes are planned.


      I'm (quickly) skimming through the PItoPI documentation. Not being a PI admin, I don't understand much... but I do notice a lot of performance-related caveats and I'm a little concerned about suggesting starting 5 PItoPI source servers on the production system. Maybe that is a common setup and I'd like to know if some people here are doing this.


      If that is too much, what strategy would be the best to ensure that the production PI system won't be impacted by all these PItoPI's? Using a dedicated interface node? Or simply replicating everything using a lone PItoPI to an alternate system which has no performance requirements, and running the other PItoPI's downstream from there?



        • Re: Question on PItoPI deployment and architecture

          It is common to use PItoPI to copy data between systems/collectives, especially systems seperated by network levels or geographical locations.  I wouldn't run the PItoPI interfaces on the production server that is running your PI system, definitely use interface nodes.


          Can you fan the data from the source systems to both your production PI system and your development system to reduce the need for PItoPI?


          There are various other factors to consider too (data rates, latency, fanning etc).

            • Re: Question on PItoPI deployment and architecture

              I'm not yet really familiar with PI. If by fanning you mean configuring the buffer on the PI interface nodes to send data to multiple destinations, I'm not sure this will be possible as the other systems only need a subset of the data for development and testing purposes, not the whole dataset. Furthermore, these interface nodes are behind firewalls and I want to limit the downstream traffic flow from them. Any replication must start from somewhere near the production system.

                • Re: Question on PItoPI deployment and architecture
                  Ahmad Fattahi

                  I would definitely go for a separate PItoPI interface node to minimize the load on the PI Server. As Rhys pointed out too, the eventual load will depend on many other factors the biggest of which would be data rate. Having a separate duplicated PI Server for distributing data down stream would be another option too as you mentioned.


                  Another thing to consider is the scan classes on the PItoPI interface. You don't want to hit the source PI Server every 30 seconds with one huge 1.5M-tag request; instead you would want to spread them out over time as equally as you can using smaller scan classes with different offsets.

                    • Re: Question on PItoPI deployment and architecture

                      @Olivier: it seems like you found people interested in the topic (no surprise!), but I would like to kindly bring to your attention that PI System Administration questions (like PI Interfaces) are generally better handled by our regular Technical Support team. Unlike on vCampus (which generally focuses on PI programming and systems integration), they have the processes/mechanisms to escalate these kinds of questions on Interfaces, to the right people.


                      In other words, you can find good discussion over here, but you have better chances to get to the right answer in a more timely fashion over there... at least if it's a PI System administration or "end-user" kind of question, not for PI programming or integration questions ;)


                      Good luck!

                      • Re: Question on PItoPI deployment and architecture



                        This is an interesting point regarding the scan rate for PI-PI.  My understanding was that PI-PI usually signs up for exceptions.  If this is the case, are scan rates still relevant?





                          • Re: Question on PItoPI deployment and architecture
                            Daniel Takara

                            Zev Arnold

                            My understanding was that PI-PI usually signs up for exceptions. If this is the case, are scan rates still relevant?



                            PItoPI interface scan rates are relevant if its tags are configured to get archive data (instead of exception data) from the source PI server. Both archive data and exception data retrieval are supported. Per the interface documentation:

                            The PItoPI interface copies tag data from one PI server to another. Data is moved in one direction, meaning data is copied from the source to the receiving PI server (also referred to as target PI server). (...)
                            Interface tags are created on the receiving PI server. Each interface tag is configured to receive data for a unique source tag. Tags receive either archive or exception data updates from the source tag. Exception data is data that has not yet been subjected to compression. The type of data collection, exception or archive, is configured through scan class assignment. By default, all tags belonging to the first scan class receive exception data. Tags assigned to any other defined scan class receive archive data.

                    • Re: Question on PItoPI deployment and architecture

                      @Olivier:  I've deployed this at a couple different client sites.  An important caveat to remember is that OSIsoft recommends that each instance of PI-PI only be used with 5000 tags (or 10,000 or 2,500 depending on the version.)  This can result in numerous PI-PI instances depending on the number of tags you want to copy.  This limit should be respected as I have seen PI-PI quietly fail on occasions that I have used more than 5000 tags.


                      The support of this system is also something you should take into account.  You should make every effort to match the tag configuration on the test PI server to the tag configuration on the production PI server.  Having to change attributes on the test PI server for every tag you mirror from production can be time consuming and error prone.


                      Another thing to consider is how you manage the requests for new tags from your development and testing teams.  Frequently I find that they underestimate the amount of data that they need.  This results in repeated requests for new tags or, much much worse, a loss of confidence in the testing system.  Careful attention to the business process to manage this change is important.


                      As for hosting the PI-PI interfaces, I have found that performance is always best if the PI-PI interfaces are hosted on the source PI server.  That being said, performance of your PI-PI interfaces is probably less important to you than performance on your production PI server.  I usually host the PI-PI interfaces on the test PI server in this instance.  There are two reasons for this.  First, performance is usually not critical.  Second, the benefit of having an interface node, namely being able to buffer data when the receiving PI server goes down, is not relevant for the PI-PI interface.  If the receiving PI server goes down, the test PI server in this case, PI-PI will perform History Recovery to retrieve any missed data.


                      I have discussed using an HA node as a test PI server internally with my Team.  I'm not sure I would recommend this quite yet.


                      Hope this was helpful.