Support Failover for PI Adapters

Thank you for all the input and feedback regarding this idea. We recently released AVEVA Adapter for OPC UA and AVEVA Adapter for MQTT that include both client- and server-level failover. We will mark this idea as Completed. For other adapters, please create a new idea specific to the adapter you wish to see this feature implemented. The following were created for the protocols that were explicitly mentioned in previous comments:

Modbus TCP: https://pisystem.feedback.aveva.com/ideas/PIADAPTERS-I-65
DNP3: https://pisystem.feedback.aveva.com/ideas/PIADAPTERS-I-66

WHello,
With the recent release of failover support for OPC UA and MQTT Adapters, does the MQTT Adapter support server failover or only client failover? Or is server failover (data source) only for the OPC UA Adapter? I'm not able to find information on configuration steps for server failover with MQTT Adapters.

As per the attached pic, with two Adapters and a PI Server, is the Client failover service typically installed on the PI Server?

Definitely encouraging that failover support is out for OPC UA and MQTT.

Would like to see DNP3 and Modbus adapters added to the list. It's hard to justify learning the adapter programming when only half my companies current protocols support failover/HA.

I'd love to get rid of some of the expensive/power hungry Windows servers running PI interfaces at my companies sites (by converting to smaller Linux machines running adapters), but I won't be able to until failover is more widely available among protocols.

Hi,


Could we please have an update on the progress of this development?


Thanks.

Adapters that support failover will support both client-level (or adapter-level) failover and server-level failover, depending on if the data source supports redundancy. So, for OPC UA and MQTT Adapters, both failover features will be available. I hope that answers your question.

@Jiyeon Hwang:

Just for being sure talking of the same Failover feature, which is heavily needed by your custiomers:

We all need an Adapter Failover and not a Server Failover Feature (which is nice to have, but not THAT important). So we need to have a pair of Adapters running on two Servers being a Failover pair exactly like the UFO solution on for PI Interfaces to be able to do maintenance on the Adapter Servers and/or the Adapters itself without loosing Data, so if one Adapter is down, the other immediately takes over without any Data Flow Interruption.

Thank you for your feedback and questions. Apologies for not responding in a timely fashion. I'd like to address a couple of the questions I noticed in the last couple of posts.

Regarding MQTT broker redundancy support - with the next version of Adapter for MQTT with Failover functionality, you will be able to specify a list of MQTT brokers for server-level failover. The adapter will be able to failover to the next available broker if the initially connected one goes into a bad state. This is the case for SparkplugB. If you're using a generic MQTT broker, the behavior will be different.

Regarding failover functionality for all other adapters - while we have started rolling out the failover feature to the Adapters for OPC UA and MQTT, our plan is to roll it out across the other available adapters as well. We do not have a timeframe yet on when all of them will be released with the new feature but please keep an eye out for future releases of these adapters.

Adding my thoughts around the failover for PI Adapters from a GxP setting, adapter failover is required to ensure no data loss. This would apply not just to the MQTT and OPC UA adapters, but to all available adapters from Aveva PI i.e. Modbus, RDBMS etc. Adding this feature would remove a major barrier and bring us one step closer for adopting PI adapters in our production environment.

Hi There,

Currently the PI MQTT Adapter and MQTT Sparkplug Connector do not support MQTT architectures with multiple MQTT Brokers. Our team recently completed testing and found that if an Edge Node switches connectivity to another Broker then the Connector creates a duplicate sub set of tags. The majority of the MQTT architectures we work with have multiple brokers and in some cases have up to four MQTT Brokers connecting to a single Edge Node. So this is a critical functionality which needs to be supported. Is there any tentative timeline on when this feature will be available? Is there also any high level explanation on how the failover functionality will work?

If PI Adapters are to eventually replace PI Interfaces and PI Connectors, this will be necessary. To many customers, having redundancy is more important than using the latest, fastest, most secure/user-friendly/lightweight/scalable technology.

Hi Jiyeon, I have a customer that is looking at Adapters, EDS and OCS as an option in a GMP/pharmaceutical setting. They realize there will have to be some concessions for cloud based software in GMP, but they would like to ensure data integrity is present from the data source all the way to the cloud service, and so have asked for adapter failover that will ensure no data loss. This is one qualification of a data integrity assessment that they would do for the solution should they decide to test it.

Nice suggestion

We use the PI Interface For OPC DA to send data to a PI Collective in the DMZ network, which uses the PI To PI Interface to send data to a PI Collective on the business network. Having redundancy is very important to us, so if the PI Adapter For OPC UA supported failover, then I could propose that we use it instead, and we could simplify our setup to have 1 less PI Collective and no PI Interfaces.

Uniint failover is a very good feature to keep up data availability, in case of pi-node downtimes due to failure, maintenance, migration or other reasons. There should be a similar mechanism for adapters.

I'm not sure that I completely understand the "specific ask", but I'll try to answer. If my answer is not what Allison was getting at, please let me know. We currently have redundant instances of DeltaV that send their data to redundant OPC DA servers, which use redundant instances of the PI Interface For OPC DA to send data to a PI Collective in the DMZ network, which uses redundant instances of the PI To PI Interface to send data to a PI Collective on the business network. Everything that can be redundant is redundant, and we don't want to sacrifice any of this redundancy. Our PI Asset Framework and PI Analysis Service would probably also be redundant if we used them more. As for reasons why we might expect a PI Adapter to go down, that would include everything that Ingo@Uniper said plus: • The PI Adapter license expires (a perpetual option would be nice) • The PI Adapter or the computer on which it is installed fails to start up for whatever reason. This includes failing to start up due to a bug in the PI Adapter. • More wiggle room and peace of mind when making changes to the PI Adapter computer. If we have only the 1 computer, then we won't make changes to it, even if they're good changes (e.g. software/OS/security updates), for fear of disrupting the data flow and being in a rush to restore it.

Redundant is very important to guarantee to full High availability for the solution (DA, SQL, AF Vision). It is important for the patching strategy. (trigger to switch the primary) Actually we use OPC DA interface and we want to migrate to Adapter with the same features. Like Kenneth Barber said it is also important when the service scrash to launch the secondary in order to continue to collect data. That why the monitoring of some counters it is also very important. The warm failover is more interesting in our case to not double the connection everytime.

Redundancy plays at two levels: 1) source level redundancy: an adapter instance can loose connection or loose data flow (watchdog item) to trigger failover to either a secondary data source, or a secondary adapter 2) adapter level redundancy: if an adapter shuts down it should trigger failover to a secondary adapter (like UNIINT failover). Not sure if we need more than that (e.g. arbiter) as this has proven to be sufficient for most scenarios

This feature is necessary for the stability and should be standard