My two cents... Others can correct, add, adjust as appropriate.
There is no in-built notion of HA in the context of automated or hot fail-over if a component goes 'out of band'.
Since each service is running in its own JVM and memory space, fail-over of an in-flight process is not achievable (e.g., if a Service such as the Coordinator goes down, the memory and execution state of all in-flight activity is lost).
There are concepts with regard to providing a simulated HA within VSE. This concept includes placing multiple VSEs behind a load balancer. The consumer applications' endpoint is the LB. The LB routes to one or more VSEs according to the balancer's routing strategy. The approach would work in situations where the transactions are stateless. When transactions are stateful, the LB has to maintain stickiness to a specific VSE and service for the duration of the business process flow because there is no notion of sharing state across VSEs -- unless the service implements state management via the Persistent Model Map (PMM) or external DBMS. Use of the PMM, implies that all VSEs are connected to a single Registry since the PMM database is accessible per Registry not across Registries.
It may be possible to add a cold stand-by environment. If one environment goes down, the user performs what amounts to a cold fail-over. This means shutting down all Services on the running instance and starting the back-up Services. It might require the back-up servers to register themselves with the same IP or DNS as the primary. Perhaps, NATing could be applied.
Caveats:
- When running behind a load balancer, service developers and testers connect to the actual IP of the Registry not the IP exposed by the LB.
- Deployment of services into a VSE does NOT deploy the service into all VSEs running under a Registry. A separate deployment to each is required. This could be automated if using the REST Invoke API.
- There are probably other issues as well.