High Availability

Plant Connectivity supports two types of scenarios:

  • Query scenario

    A client, for example SAP MII, sends a query via Plant Connectivity to the data source in order to browse, read or write tags.

  • Notification scenario

    Plant Connectivity subscribes to tag value changes in the data source. A change event from the data source is processed by Plant Connectivity and is forwarded to the configured destination system.

A special case is the EWM scenario where Plant Connectivity acts as a pure middleware. In the EWM scenario telegrams are exchanged between SAP EWM and the connected PLCs in a bidirectional way. In principle the EWM scenario consists of both scenario types. But the reliability in the EWM scenario is not covered by Plant Connectivity. It is handled by SAP EWM and the PLC themselves that are sending acknowledgement telegrams for the original telegram to guarantee message delivery.

If the server on which an agent instance is running fails, data transfer between source and destination systems is no longer possible. To mitigate the risk of server failures, you can run several instances of PCo in a failover cluster of Windows Servers. Therefore, Plant Connectivity could support high availability for the query scenario and for the EWM scenario. But Plant Connectivity has only limited support for high availability for the notification scenario.

One restriction is related to the MSMQ that is used in PCo for the notification scenario. There is the option of Windows Servers supporting MSMQ in a failover cluster, but only for public queues. Plant Connectivity is currently using only private queues. Internal tests showed that a switch to public queues in Plant Connectivity would hamper the performance of the notification process significantly. For this reason, Plant Connectivity currently only supports private queues and does not support full high availability for the notification scenario. It is possible to use PCo with private queues for the MSMQ that then have to be created on each node of the failover cluster. This may, however, result in data loss when data is in the queue on the active node and that node fails (the data that is then in the queue is lost).

In addition, as of version 15.0, PCo is using the Windows event log to log messages and errors. The log instances will be created on each node on which an agent instance is created. This implies that the log for the resulting services is distributed over the nodes of the failover cluster and the most recent log messages are persisted only on the active node. The event log for the same agent may also get different names on each node, since the name is generated automatically. This may cause difficulties when trying to access the log from the Failover Cluster Manager.

There is no support at all for remote notifications and versioned notifications on failover clusters, since in this case the configuration data is created from a remote host on the currently active node and there is, as of the current release, no support for the transfer of this kind of configuration to other nodes.

If you want to enable high availability for PCo using a failover cluster, you have to carry out the following steps:

  • Data sources have to be installed on each node of the failover cluster as a prerequisite, for example, OPC Core Redistributables,PI SDK,Proficy SDK, or other components have to be installed or deployed in advance.

  • Plant Connectivity has to be installed on each node of the cluster.

  • Agent instances have to be created as services on one node of the cluster. It is important to use only the host name of the group (Windows Server 2008) or the role (Windows Server 2012) in case the host name has to be specified in the configuration of the agent, for example, in the endpoint of the management services.

  • The complete configuration of the agent instances has to be exported from the definition node and deployed (imported) to the other nodes of the failover cluster. Resources that are not created automatically, like the folders for simulation destinations, have to be created manually. For agent instances, that are using assemblies (DLL) for enhanced notification processing or enhanced method processing, the pertaining assembly has to be distributed manually, too.

  • In the last step, the agent instance service and the PCo main service have to be assigned to a generic service in the Failover Cluster Manager.

Enhancing the agent instance at a later point in time, for example, with new subscription items or other new configurations, has to be done with particular care to ensure that the agent instances are kept identical on all nodes. It is recommended that you define a workflow for this task. It might be advisable to reconfigure the agent instance again only on one node, export it, and transfer it to another node, remove (delete) the agent instance on that node and import it again for this purpose.