Need an MFT Expert?
We can put you in touch with our network of expert MFT systems integrators.
Find a Partner
High Availability & DR
High Availability & Disaster Recovery for B2B Integration
Keep EDI and managed file transfer running through node failures, maintenance windows, and infrastructure events—with clustered Arc instances, centralized logs, and consistent processing behavior across the farm.
Load-balanced clustering · Shared app data + shared audit logs · Built for EDI reliability
Resilience
Operational resilience that EDI teams can trust
High availability and disaster recovery are only meaningful if they preserve the things integration teams care about most: predictable processing, complete audit trails, and clean handoffs during failover.
Uptime through failures
Run Arc on multiple systems in the same server farm and place a load balancer in front to distribute inbound traffic. If a node becomes unavailable, traffic routes to healthy nodes.
One audit trail, even across many nodes
Configure each node to use the same Application Database so transaction history, errors, and access logs are consolidated. Audit and troubleshooting stay centralized—even when the workload scales out.
Consistent processing behavior
Use a shared Application Data Directory so each node processes the same files and uses the same configuration—preventing “it worked on one server” drift as your environment grows.
Architecture
How Arc delivers HA in practice
Arc supports load-balanced and high-availability deployments by focusing on two concrete requirements: distribute inbound traffic and keep all nodes synchronized on data + logs.
1
2
3
4
Put a load balancer in front of multiple Arc installations
Incoming partner connections are routed across the server farm. Health checks can validate that Arc’s receiving endpoint is responsive so traffic only goes to healthy nodes.
For high-volume EDI: When transaction volume and resource ceilings (CPU/RAM/disk/network) are reached, scaling horizontally can be more efficient than pushing a single endpoint harder.
Share the same Application Database across the cluster
Arc logs transaction history and errors to a database. In a cluster, all nodes point to the same Application Database, so operational visibility and auditability remain complete and consistent.
Share the same Application Data Directory
Arc stores configuration and application data in a data directory. In clustering, each node should use the same directory to ensure consistent configuration and shared processing locations.
Rely on locking to prevent double-processing
Arc uses locks so multiple instances don’t interfere with each other or process the same file twice—critical for maintaining throughput and correctness in clustered environments.
Arc strongly recommends avoiding clustering across multiple server farms where file-system latency can impact locking efficiency.
Capabilities
Key capabilities for HA & DR-ready EDI operations
These are the building blocks teams use to design “stay up” B2B integration—without reinventing the operational model.
Clustered Arc nodes that behave like one system
In a properly configured cluster, Arc nodes share configuration, process data to/from the same disk locations, and write to the same database tables—so the cluster behaves like a single Arc instance.
Load balancing for scale and failover
Use a load balancer to distribute inbound traffic across Arc nodes. This supports both horizontal scaling and high availability when individual nodes fail or are taken offline for maintenance.
Centralized logs for auditability
A shared Application Database consolidates transaction status, error history, and access logging—simplifying troubleshooting, compliance evidence, and operational reporting.
Shared configuration and partner artifacts
By using a shared Application Directory, partner configuration and operational artifacts remain consistent across nodes. This reduces configuration drift and supports predictable incident response.
Disaster Recovery
Designing for disaster recovery, not just uptime
Clustering removes single points of failure at the application tier. A complete DR posture also ensures the shared dependencies (file storage and database) are themselves highly available.
Eliminate single points of failure
Use multiple Arc nodes behind a load balancer so a server outage doesn’t become an EDI outage.
Make shared services HA
Point Arc to a shared file location and a shared database—then ensure those services are HA-capable (e.g., clustered file services and database HA) so they don’t become the weak link.
Operational clarity during incidents
Centralized logging plus consistent configuration across nodes reduces uncertainty under pressure—so teams can diagnose, contain, and recover faster.
FAQ
High Availability & Disaster Recovery
-
Is this for load balancing or high availability?
Both. Load balancing distributes traffic for throughput; high availability ensures traffic routes to healthy nodes during failures. The architectural foundation is the same: multiple Arc installations, a load balancer, and shared state (data + logs).
-
How does Arc avoid double-processing files in a cluster?
Arc uses locks to prevent multiple instances from interfering with each other or processing the same file twice. Shared application directory access ensures those locks are respected across nodes.
-
What should we share across nodes?
In clustering, each node is configured to use the same Application Database (for transaction/error/access logging) and the same Application Data Directory (for configuration and application data).
-
Where do we start?
Use the HA tutorial to implement a practical server farm + load balancer approach and then configure shared application directory and database across nodes.