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?
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).
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.