High Availability (HA) Architecture

Availability is the percentage of time that a system is functioning and able to perform its mission. High availability is a characteristic of a system that aims to achieve an agreed level of availability for a higher than normal period.

Controller systems can achieve high availability when specific hardware and configuration requirements are met. For general guidelines for high availability systems, including redundant system components, networks, and other hardware and software considerations, see

High Availability Systems Reference Manual, publication HIGHAV-RM002

.

High availability (HA) architecture maintains

FactoryTalk® Optix™

application availability when a node fails. In an HA architecture model, redundant nodes allow

FactoryTalk® Optix™

runtime to continue to operate when a node fails, without manual intervention. HA with

FactoryTalk® Optix™

improves system resilience for visualization, but does not replace controller, network, or I/O redundancy elsewhere in the automation system.

With HA, real time control remains in the controller level and is unaffected by

FactoryTalk® Optix™

Runtime application availability.

High Availability Architecture Model

Item	Description	Behavior
	Web client	Connects to the active runtime application via virtual IP address.
	Virtual IP address	The HA cluster is assigned one virtual IP address, which is used for web client connectivity and FactoryTalk® Optix Studio™ application deployment.
	Three-node HA cluster	FactoryTalk® Optix™ Runtime is deployed to all nodes in the cluster. The cluster uses three nodes for uninterrupted maintenance and upgrades, and to prevent data synchronization conflicts that can occur with a two-node cluster.
	Active runtime node	During normal operation, the active node runs FactoryTalk® Optix™ Runtime application.
	Standby runtime node	The standby node remains synchronized and ready to assume operation if the active node becomes unavailable.

During failover, the active runtime server becomes unavailable and one of the redundant standby nodes in the HA cluster becomes the active server. See Failover Behavior. If a previously unavailable node becomes available, the node automatically synchronizes with the HA cluster and becomes a standby server.

HA Architecture Considerations

When designing

FactoryTalk® Optix™

HA architecture, consider the following.

HA architecture protects the

FactoryTalk® Optix™

Runtime application layer only, meaning failures from hardware, operating system faults, or runtime services.

HA does not protect against controller, I/O, or network path failures, power loss, or site‑level or data center disasters.

Server hardware, virtualization platforms, and network infrastructure must not introduce shared single points of failure.

You must validate HA behavior as part of system commissioning.

Failover Behavior

Failover triggers when the active runtime server becomes unavailable. This disruption can happen due to:

Server failure

Operating system failure

Host failure

Hardware failures

PC/VMware shuts down or fails

Network failures

Network cable is disconnected or not available

Network is not available or disrupted

Loss of the

FactoryTalk® Optix™

Runtime application

During failover:

The runtime application stops running temporarily. Operations such as data logging also stop.

The runtime transitions from the failed node to the standby node, which becomes the new active runtime node.

IMPORTANT: Embedded database synchronization is not supported in version 1.8. For data that must remain available across a failover, use a supported external database architecture. Files that are generated or modified locally by the runtime are not synchronized between nodes.

Connections to controllers, databases, and other external devices automatically reconnect to the new active node.

Visualization, alarming, data access, and data logging resume without manual reconfiguration.

The web client automatically reconnects.

Runtime data and navigation resume from the new active node.

The client returns to the Start Window and the Starting User, as defined in the Web Presentation Engine properties.

Web client sessions re‑establish and operator displays reload from the newly active node using the shared project definition. Session continuity maintains at the application level rather than as a persistent connection to a specific server instance.

Only the active runtime node processes logic at any given time to prevent duplication or conflict. After failover, processing resumes from the newly active node using the same configuration and definitions.

IMPORTANT: Failover behavior is limited to the

FactoryTalk® Optix™

Runtime application. Controller function, I/O scanning, and real time control are not affected during failover.

HA System Requirements

Requirement	Description
Cluster topology	Three server-class runtime target computers are configured as one HA Kubernetes cluster.
Hardware architecture	System: x86_64 (64-bit), either local hardware or virtual machines. RAM: 8 GB minimum; 16 GB recommended Storage: 64 GB minimum
Operating system	Ubuntu Linux OS version 22.04.5 LTS installed on all cluster nodes.
Network configuration	All runtime nodes in the HA cluster must reside on the same layer 2 network segment or broadcast domain to support reliable cluster communication and failover.
Licensing	Enabling high availability requires an extended token package. See Runtime Entitlement Sizing Guide for information on extended token packages.
Core runtime image / container	Keepalive for virtual IP management and seamless client failover K3s Lightweight Kubernetes for container orchestration FactoryTalk® Optix™ Runtime install RuntimeMonitor for health and status monitoring UpdateServer for coordinated runtime updates MariaDB Galera cluster for synchronized, fault‑tolerant data replication
FactoryTalk® Optix™ High Availability Manager	For deployment, configuration, and management of the HA cluster.

For more information on application requirements for HA, see

FactoryTalk Optix Help

.