When will Server Side Buffering be available, and what best practices are planned.
The current engineering plan lists SSB as a 1H-2010 deliverable:
Like all plans, this is subject to change as plans for future releases are reviewed.
Might you elaborate on your use case for this, and why PI to PI doesn't meet your need?
I find PI to PI unstable, and hope that SSB will be the next replacement in a HA Architecture. I am currently looking at integrating 2 large HA architectures where we would require SSB, otherwise it's PI to PI and 80 instances of.
I also have 4 assets in the field which are PI servers that need to synchronise to a HA environment. SSB on each client would be more practical, as using PI to PI we have to install extra boxes in redundant mode.
Just to add to Terry's comment...
PItoPI by its own admission is "not a true data replication tool. It does not synchronize PI server data or perform data validation.".If you consider this from an application's point of view (rather than an interface) then if you write data to a collective member you don't want to worry if that data gets updated to all collective members, you hope it does by the nature of writing to a "collective". Problem is that with PItoPI you need to consider all possible directions within a collective where you may need to replicate data too, especially in a failover situation where you hope the secondary member you have connected to (with SDK writes enabled) can then replicate the data back to all other members (including the member you failed over from).
Assuming you get over the PItoPI hookups, Manual data entry is an issue when you start using Annotations as PItoPI is API based. If you chose PI-ML as your tool for manual entries, you have option to store comments/user information in to Annotations - mix this up with a collective and there is the possibility for missing data.
Good thing I asked, because as I suspected there are multiple variables in play here.
If the aim is to have SDK based applications write data to all collective memebers, then SDK n-way buffering is really a better solution than server side buffering anyway - in most circumstances. This functionality is comming to the SDK, and based on the current engineering plan it will arrive much sooner than SSB to boot. Tough to say for sure without looking at the details, but it seems like this would cover all of the specific issues you raise about PItoPI in this circumstance. It should cover annotations, and it should fully cover all possibile combinations of primary/secondaries failure without extra servers/moving parts.
As for the short-commings of PItoPI, I agree that it isn't a fully automated server synchronization tool (not designed to be), but then no-one has said that this is the purpose for SSB either. A lot of time and energy goes into designing systems such that they stay in synch without an external "data cop". I'd love to hear more about circumstances where you think this functionality is needed.
Data validation is an analytic function, not a replication function. Actually, as we research the possibilities for edge processing at the interface level it could turn up that PItoPI would someday include this capability, where as server side buffering would almost certainly be purely a replication tool. Again, any more specifics you can provide as to the circumstances where these types of functions are needed helps us when it comes time to talk feature design and schedule. None of this is etched in stone.
This question has lead off path to the point that my original question has been lost; Problems to address are;
1. How we do replicate data to all members in a collective without using PI to PI. assuming that the application does not support N-way Buffering
2. How we synchronise data on a PI Server to all members of a collective without using PI to PI
3. How we get real-time data to collective members, assuming that the collective is disconnected from the real-time data source (similar to Q2)
This is the reason I asked about SSB, and believed this was meant to address these specific problems. Currently HA assumes that the architecture is using n-way buffering via the PIBufSS or PI Buffering. PI to PI to does not offer real-time data replication, which is similar to the problems faced with OPC HDA.
My understanding of SSB is that the Server, including members of a collective can pull real-time data from the source. Can you please explain the architecture of how n-way for Buffering for SDK would replace this functional requirement, as it only covers clients that need to write to PI using the SDK channel.
So my problem remains the same. The support issues around around PI to PI vastly outweigh its use in a newly designed HA architecture in particular.
Let me address your questions in the most honest and straightforward way possible.
Terry Price1. How we do replicate data to all members in a collective without using PI to PI. assuming that the application does not support N-way Buffering
The answer is as simple as it is uncomfortable: what you are asking is not supported in the current design. If PI-to-PI isn’t a workable solution, we don’t have anything out-of-the-box for applications that don’t write data through the PI API, or implement their own data fanning/validation (which is possible but far from trivial, and therefore not a recommended route).As Matt was saying, PI SDK fanning will offer soon a much needed relief for the vCampus community, but it won’t be a solution in all possible scenarios (see further comments).I can only offer you the most sincere apology for the delay in delivering Server Side Buffering (SSB) and SDK fanning/buffering. Back in 2007, we intended to follow up relatively quickly (i.e. 12-18 months) with these HA enhancements. Things have gone quite differently because of conflicting priorities. That being said, we are still committed to these critical features and they never disappeared from OSIsoft’s Engineering Plan.
Terry Price2. How we synchronise data on a PI Server to all members of a collective without using PI to PI
Today, the only way to guarantee synchronization of time-series data is through N-way Buffering, preferably using the Buffer Subsystem (pibufss) because of the stateful nature of our compression algorithm. PI-to-PI can be configured to replicate historical data in an identical fashion but it comes at the price of latency, as defined by the time between compressed events.I would like to take this opportunity to stress that SSB will not modify the above statement about N-way Buffering, which is ideal for single and/or high throughput data sources (e.g. PI Interfaces, data analytics). SSB is primarily intended for non-buffered data, and will complement N-way Buffering but it will not replace it.As previously mentioned, we intend to deliver “Client Side Buffering” through the PI SDK as well. This should work well in many contexts, including the obvious one where the client machine is totally disconnected, but SDK buffering will also rely on SSB for high-speed and/or largely distributed PI Server Collectives.
Terry Price3. How we get real-time data to collective members, assuming that the collective is disconnected from the real-time data source (similar to Q2)
This is something we intend to solve with SSB and nothing else (although probably in a static form in the initial implementation). Our current prototype do allow for PI Server nodes to replicate all of time-series data between them so there isn’t a technical problem. However, allowing for this behavior to be made dynamic is quite complex. In other words, we will ask that system integrators/administrators configure the replication “routes” between collective members and buffering will take place when network links or server nodes aren’t available. We will make sure that adjusting these routes on the fly could be done programmatically (e.g. shell scripting) so that you have control over the handling of degraded HA states.
If you have more specific information you would like to submit, please continue to use this forum or you may contact me privately.
With regards,Denis Vacher
Thank you very much or your open and honest answer to my questions.
It is assumed then an HA architecture that the integrator will design an architecture in such a manner that all such Interfaces write to each member of the collective independently. This would use SDK or API fanned data. This would most definitely eliminate the need for multiple sessions of PI to PI and ensure that all members recieve live data. It doesn't answer though how another PI server could replicate data to each member of the collective, whithout using a very complicated installation of PI to PI. How this scenario going to be addressed in the future?
When is the SDK with N-way buffering going to be released?
Has the white detailing how to implement HA in a WAN been released yet?
Terry PriceIt doesn't answer though how another PI server could replicate data to each member of the collective, whithout using a very complicated installation of PI to PI. How this scenario going to be addressed in the future?
This actually is the need that Server-Side Buffering (SSB) will address.
Terry PriceWhen is the SDK with N-way buffering going to be released?
According to our Engineering Plan, PI SDK 1.4.0 (which will integrate n-way buffering for SDK writes) should be released before the end of the year (4Q2009).
Terry PriceHas the white detailing how to implement HA in a WAN been released yet?
I assume you meant "white paper" And I assume you are referring to the White Paper that Sam Pride talked about in this blog post.If that`s the case, then the answer is that the full Whiter Paper hasn't been released yet, but "Part 1" was - and luckily, Part 1 covers manual entries to Collectives using PI SDK.
Looking forward to reading your feedback and questions (probably in the PI SDK Forum, if you try that method Sam suggested)
Sorry to hijack your thread again Terry...
What are the actual mechanics of SSB going to be?In non-technical terms:
- SSB hooks into Snapshot / Archive subsystems - rather than event pipes for each tag?- Member A receives a new snapshot value for Tag 1.- Internal event triggered for SSB.- SSB contacts all available members and queries if the member has the same new value for Tag 1. (If not the value is presented to the member.)Process repeated for updates/deletes on Read/Write archives.
What will the replication times for SSB to collective members? Would we need to be concerned with which member a client is connected to if say an application only writes to 1 member and leaves SSB to replicate the data?
Rhys @ RJK SolutionsWhat are the actual mechanics of SSB going to be?
In the shortest description possible, Server Side Buffering leverages the mechanisms used by the Buffer Subsystem, but this time directly inside the Snapshot Subsystem. The Snapshot Subsystems on all Collective members will create and maintain N-1 buffers in order to forward data to their peers. As you may know, all time-series data (in order, out-of-order, adds, edits, removes, etc.) come first to the Snapshot Subsystem. By leveraging this key concept, SSB can trap everything that a PI Server node receives and make sure it is forwarded to all other members. The trick obviously is detecting data that was already replicated by pibufss (that's easy), bufserv (a little harder, but not much), or custom code that performs data fanning. The latter case will require a little configuration on the part of the system admin and/or you, the integrator.
Rhys @ RJK SolutionsWhat will the replication times for SSB to collective members?
If the PI Servers in the Collective can communicate to each others (in all directions), it will be very close to the available latency/bandwidth of the network. We envision some parameters to potentially throttle SSB traffic, but the default will be real-time replication. Note that this is a push replication unlike the configuration changes that are pulled by each secondary server today.
Rhys @ RJK SolutionsWould we need to be concerned with which member a client is connected to if say an application only writes to 1 member and leaves SSB to replicate the data?
If you find yourself concerned about this we would have failed our job, and we will attempt to address your issues. The intend is for SSB to be as transparent to you as it should be to end-users.
Hi Denis, thanks as always for taking the time to reply.What I still have a niggle in the back of mind is how SSB will affect the network if we talk about high frequency collectives with large point counts (>500,000) and if SSB will "keep up". Will there be a way to monitor percentage of data received from SSB for collective members? So you could then monitor your collective to see which member clients connect to the most to post data.I guess I am just sitting patiently waiting for SSB to play with.
Retrieving data ...