2 Replies Latest reply on Apr 20, 2013 1:24 AM by jlakumb

    Dropping the PI Collective from our solution?


      We need your help to make a decision.




      First, we are application developers and maybe we are missing some important information to understand, so that's why we ask for your help.




      We have deployed a "PI solution" all around the world and here is our current setup:
      For each site:


      2 VMware hosts with a SAN:
      - PI Server 01 on the first, PI Server 02 on the second = PI Collective
      - SQL Server 01 on the first, SQL Server 02 on the second = SQL cluster / mirror
      - AF Server 01 on the first, AF Server 02 on the second = AF Collective
      and other servers like services and terminal servers on both.




      We do a lot of custom development currently with PI SDK.
      Many of our custom applications need to write values in PI tags.
      Everywhere we need to run our applications, we need to:


      - Add a trust (admin) in PI for that client machine (needed by the buffering service);


      - Setup the PI buffer sub service.


      Doing this means that we lose the security set on pi tags?




      All of this is a pain for us (developers) and we really want to revert to a non-collective PI. But first, we need good arguments to be able to convince higher instances.


      Maybe we are wrong and we are going about it improperly?




      We believe (developers) that all this "redundancy" is exaggerated since it is well taken care of by our VMware setup.


      The fact that servers are virtual servers on 2 VMware hosts gives us enough fallback (VMware handling everything in case of maintenance/failure).




      Also on another slightly related subject, with AF SDK 2.5’s PI namespace, there is no need any more for COM objects, which is GREAT!


      But there is no support for the collective yet (forget about the SwitchMember hack since once a tag is buffered this does not work).




      Our suggestion would be to remove all secondary servers from our solution and disable buffering, and then recover the ability to use the new AF SDK or the PI SDK to write/update/remove PI tags values from anywhere and with normal behavior.




      Would you say this makes sense? Do you believe our understanding is right? Any advice that could help us make that decision would be appreciated?

        • Re: Dropping the PI Collective from our solution?



          In your post you had questions about security as well as high availability. Let's treat them independently.


          A few things about security:


          - "Add a trust (admin) in PI for that client machine (needed by the buffering service)"


          --> if by that you mean piadmin then you're giving it too much privs (equivalent of doing everything as root). There is a security manual ("PI Server 2012 Configuring PI Server Security") you may want to review:




          - "Doing this means that we lose the security set on pi tags?"


          --> I didn't completely follow this question. The tag's ACLs are sort of orthogonal to how connections get authorized. I say sort of because they are related and have an effect on what is feasible. However, if you're alluding to the piadmin thing mentioned above, then I kind of understand what you meant and in that case: yes, see my previous comment.


          So far we have discussed security. Let me know if you have questions about it.


          Maybe some more context would be useful here. What is handling data collection? For instance, is your code editing the data after the fact or are you also inputting it via it? Are these edits/inserts always to the snapshot?


          I assume that by "once a tag is buffered this does not work" you that the tag is locked by pi buffer subsystem in which case the "data collection" question sort of tends to the former case (i.e., an interface writes the data). But, depending on the context, it could mean other stuff like Replication_EnableSDKWriteValues. So I think we would need more context in order to help you better.


          In any case, here are the limitations with pisdk buffering. There is a table towards the end of that page that goes over some cases (which would basically depend on that "data collection" question):




          That link assumes you are in a machine with pisdk installed and is something you run from Windows+R. If you are not in such a machine, I think you may find it from the download center link i provided for the security manual.


          That page and the HA user manual ("High Availability Administrator Guide", in the first link) should, generally, help you reach a more informed decision.


          There is a PI and virtualization white paper in* that you may leverage for your decision. Particularly, look at page 11 (section titled: "Virtualization High Availability Strategies vs. PI High Availability"). However, I think there are more recent sources (even a video or two) in vCampus -I'll try to find them and put them as a reply to this.


          * techsupport.osisoft.com/.../DownloadCenter.aspx

            • Re: Dropping the PI Collective from our solution?

              Hi Sebastien,


              Sorry to hear you're experiencing some pain due to these issues.


              Regarding buffering security, I suspect you are referring to the issue where buffering uses a single identity to send data to the PI Server.  This means that all data is sent as one specific user no matter which user/application writes data into the buffer.  Is that the problem?  If so, it is documented in PLI #22387OSI8 to support impersonation and delegation in PI Buffer Subsystem.  If you can confirm that is an issue for you then we can discuss potential workarounds.  Note, that PLI is not targeted for the next release of PIBufss, but is a high priority for follow on release.


              Regarding PI AF SDK, I suspect you are referring to the issue that it does not yet support buffering, therefore you cannot easily fan data to multiple members of PI Collective?  Is that right?  If so, this feature is targeted for PI AF SDK 2014.  In addition to the questions which Luis raised, I would also like to reference this KB article which may provide some possible workarounds depending on your use case -




              Before you forgo the benefits of PI HA, let's keep the discussion going to see if we can come to a solution that works for now.