High Availability

High Availability in
FactoryTalk® Optix™
runs the runtime application on three nodes and fails over automatically if the active node fails.
Instead of a single
FactoryTalk Optix
deployment, High Availability uses a three-node cluster on separate physical machines. One node is active and serves client traffic. Two nodes are idle and ready to take over. Clients connect to one Virtual IP address, and a Runtime Monitor service continuously checks node health. It automatically promotes an idle node to active if the current active node fails.

Cluster overview

A High Availability cluster runs one FactoryTalk Optix runtime application across three networked nodes, with no single point of failure.

Key concepts

Node
One machine in the cluster that runs one runtime instance. A cluster always has exactly three nodes.
Active node
The node that serves all client traffic and maintains all external connections, including controllers, databases, and OPC UA or MQTT clients. Only one node is active at a time.
Idle node
A fully initialized node that runs but does not serve client traffic or maintain external connections to controllers, databases, or other devices. Two nodes are idle during normal operation. If the active node fails, one idle node becomes active automatically.
Failover
The automatic process that detects an active node failure and promotes an idle node to active.
Virtual IP (VIP)
A single IP address used by the clients and FactoryTalk Optix Studio for client traffic and for deploying projects to the cluster, regardless of which machine hosts the active runtime. The cluster manages the address automatically.
Runtime Monitor
A service that continuously checks node health and starts failover when needed.
Shared database
A synchronized database cluster that all nodes use for retentivity data. A newly active node has current retained data.
High Availability Manager
A Windows desktop application that deploys the cluster and manages its ongoing configuration: ports, credentials, entitlements, and node health.

Failover overview

  1. Clients connect to the Virtual IP address instead of individual node addresses.
  2. The active node handles all client traffic and external connections, including controllers, databases, and OPC UA or MQTT clients.
  3. All three nodes share the same database for retentivity data, replicated synchronously, so an idle node can become active with current retained data.
  4. The Runtime Monitor continuously checks node health. If the active node fails, the service starts failover.
  5. During automatic failover, an idle node is promoted to active, and traffic is redirected to it through the Virtual IP.
  6. When the failed node reconnects, it automatically rejoins the cluster as a new idle node.
TIP: Failover protects against runtime software crashes, node hardware failures, database node failures, and network issues that affect a single node. If two or more nodes fail at the same time, repair the failed nodes and rejoin the nodes to the cluster to recover.

Application considerations

  • Exactly three nodes are required. Each runtime instance runs on a dedicated node.
  • The cluster tolerates one node failure.
  • During failover, the runtime application stops running temporarily. Operations such as data logging also stop. During the node transition, temporary connection loss between the web client and the runtime application occurs. The failover time varies by failure type and application size.
  • After failover, the client returns to the Start window and signs in as the Starting user, as configured in the WebPresentationEngine properties
  • Application data configured in the retentivity module synchronizes across nodes.
  • Data written to the application files folder at runtime, including runtime-generated files, is not synchronized across nodes or retained after failover, except retentivity data.
    TIP: Automatically export files to an external server and retrieve them at startup
  • The system does not support embedded database synchronization. Rockwell Automation recommends logging to an external database.
  • Store administrator credentials securely.
  • High Availability applies only to the
    FactoryTalk Optix
    runtime application.
Provide Feedback
Have questions or feedback about this documentation? Please submit your feedback here.
Normal