3 Replies Latest reply on Dec 14, 2008 6:26 PM by bryan@osisoft.com

    Collectives (and HA-SDK)

      Would like to get some clarification on Collectives.


      BN = Business Network, CN = Control Network, FW=Firewall


      In a collective consisting of 2 PI Systems on BN and 2 PI systems on CN with a FW between BN & CN, where the Primary server is on one box of the CN.  The 2 BN PI systems have a route through the FW but all other clients on the BN do not have a route through the FW thus cannot see the Primary server on CN.

      So taking the currently available solutions from OSI, clients on the BN cannot write data to the Primary server on CN so any connections from HA-SDK mean they will connect to a Secondary server on BN.  Now there are limitations when using HA-SDK on a Secondary server in a Collective, most notable is SDK cannot write values by default.  I see this can be overriden Replication_EnableSDKWriteValues, so SDK can now write to the secondary server.  Appreciate this set up is probably not advised but it is still likely to happen.  If this occurs, the secondary server starts to get data that the primary server does not know about.  As OSI does not have server side buffering yet, how should this be handled?  Data will already be coming from the Primary server to the Secondary server via PItoPI.


      Any other comments on this and collectives?



        • Re: Collectives (and HA-SDK)

          The FW does not leave much options with the current PI functionality - so I can not see a different way than using the PI2PI i/f here as well.


          Please let me verify - the two BN PIs have a route throug the firewall to the CN network or only to the CN PIs?



            • Re: Collectives (and HA-SDK)

              Hi Andreas...there are interfaces on the CN fanning the data to collectives on BN.  Yeah the BN PIs have a route to the CN PIs.


              What I am trying to get clear (in my own mind more than anything) is how we would handle any updates to a secondary PI server on BN, lets say there is a value added application writing to it that does not warrant to be put on the CN, how do we ensure the other BN PI server & CN PI servers are kept in sync.


              So we would PItoPI those points across to BN & CN...just wondered if there is anything clever that can be done.  I guess my next question is, will SSB cover this kind of scenario? 


              Limitations on secondary servers are understandable but in the event the primary server goes down and an application failsover to a secondary and continues writing data to the secondary server (if allowed!), can you automatically configure PItoPI to start fanning data from there to all other collective members - this just seems to start to get messy...not necessarily Collectives but this particular kind of set up.  I guess for some applications using "RequirePrimary" should be used to prevent these problems i.e. it will only write to the Primary and data is fanned from there (PItoPI).

                • Re: Collectives (and HA-SDK)

                  The security policy perspective (isolating the CN primary from most BN connections) is important to consider.  In other words, a common solution where the BN data source application directly posts data to all collective members is not compatible with the security policy. 


                  It might be useful to consider designating a BN member as primary (CN as secondary).  A site specific risk analysis should be performed, but this may result in even fewer connections into the CN.  Role access protection for configuration tasks in the BN is often considered acceptable.


                  Alternately it is often acceptable risk to relax connection policy for a trusted BN application server.  In this case, the application is instrumented to write and queue for all collective members. Depending on the data and methods required the API may be used to leverage n-way buffering. A middleware solution can be a good choice (implement in PI-ACE/OLEDB etc).


                  PItoPI is a good solution for replicating time series over a security boundary.  In the case of two source servers on the BN, PItoPI should open an outbound connection from the CN (or DMZ) and pull from the BN. Automatic failover between the two BN servers is supported (provided a reliable heartbeat status point is available to monitor the replication). There can be subtle impact on point configuration settings and data limitations such as event annotation.  


                  The dev roadmap SSB is expected to increase flexibility for replication.  Let us know more about the application so we can ensure the SSB design specification covers your use case.