On past days KIE Foundation Team achieved an important milestone: Building a production-ready HA infrastructure for Business Central.
This journey began many months ago and our main goal was to provide HA in a simplified cluster setup, leveraging on the provided infrastructure, especially in a containerized environment like OpenShift.
This effort required a new architecture for the core components of Business Central, including file-system, indexing, messaging and locking mechanisms.
Before diving on tech details, let’s take a quick look on what is HA for Business Central perspective and how can I setup it on my own environments.
What is High Availability on BC perspective?
High Availability could potentially mean different things depending on the context. That is why is important to make it clear what is currently supported on Business Central.
Our current HA implementation has two major goals:
- All the data committed in one node is reflected on others and it is always preserved[1];
- Provide an infrastructure that let the user work in a fail-safe environment. If one server goes down, users will be able to continue working in any other server/pod available[2].
[1] In some corner case extreme circumstances, we can still fail during a new project/asset creation. This work is tracked on AF-2142.
[2] UI state not committed will be lost, but the user will be able to keep working on a different node, for instance, if you are working/modifying an asset and node fails you will be redirected to the home screen (but in a different node).
Overview of the architecture
Before diving in some details, let’s have a quick overview of the new clustered setup of Business Central and do a quick setup of our infrastructure. There are four main components of this architecture:
