(OO) Support Tip: OO 10.x and High Availability (HA)
Please provide the following information:
- Explain the concept of OO 10.x and High Availablity (HA).
- What is needed for an OO version 10.0 cluster?
- Is a load balancer required?
- How to achieve HA with RAS?
- Scheduled flows failover?
- Is it supported for two Centrals to point to the same database without installing the cluster service?
- Does the orphan concept apply to 10.x?
Regarding OO 10.x and High Availability (HA)…
OO 10.x has a simplified topology. This simple topology means that:
- Everything is stateless.
- Automatic load balancing in workers – no load balancing or reverse proxy software is required.
- No clustering software is required (such as Terracotta, Windows Cluster, and so on).
- Offline authoring – Studio does not require any external components to function
- No shared file system
- Simplified APIs – RESTful APIs only
- Zero downtime when deploying new content – you can use the new content immediately without having to restart.
You can cluster OO by adding more HP OO Central nodes with a load balancer in front of them. There is no need for external clustering software, a clustered operating system, or a shared file system.
What is needed for an OO version 10.0 cluster are the following:
1. More than one identical Central
2. Optionally, a load balancer (LB) to balance the requests sent to the multiple Centrals
3. More than one worker [i.e. Remote Access Servers (RASes)] to be added in the same worker groups on the Central servers.
In order to prevent the Central being the single point of failure, it is recommended to have a high availability deployment. The benefit of a cluster is to prevent the Central from being the single point of failure.
You can set a cluster of multiple Central nodes, the simplest of which contains two Central nodes connected to the same database schema.
A load balancer can be set before the Central cluster to expose a single URL to the end users. Exposing a single URL can also be done with DNS load balancing.
Regarding RAS HA...
When a RAS is deployed in a network segment to manage the machines in that segment, you do not have to make do with a single instance. To achieve high availability, you can deploy an additional RAS instance in the same segment. Make sure to associate it with the same worker group.
Regarding scheduled flows failover…
The Scheduler is a trigger system not a queuing system. Any OO jobs scheduled within that minute and that has free threads will run. If there are no threads and the minute passes without a thread becoming free then a scheduled job will not run.
There is not failover as there is no concept of what server scheduled flows are running on. Basically, the scheduled flows look at the same database and whichever server takes the scheduled flow first wins. Note: If the scheduled flow fails after it was took then it would be an orphan.
Five flows are scheduled to run at 10 am.
At 9:59:59 am, nothing happens.
At 10 am, both servers take the schedule and trigger a flow. Once a server has taken the to-do work, it tells the other server that it has it and if the other server was taking it that server will stop.
It is not supported for two Centrals to point to the same database without installing the cluster service. Each Central must point to its own database unless it is a cluster.
The orphan concept does not apply to 10.x because the flows are not executed by Central but by RAS. In case of a failure, the worker recovery ensures everything will continue and that is because all the information required for a flow to run is stored in the database (unlike 9.x where it was stored in Central’s memory). RAS does not talk to the database directly, only to Central. Central has a management worker/queue and it puts work in the queue. RAS pulls from the queue. RAS finishes the work and puts in a different queue on Central.