Step 3: Multi-server system

Scaling is provided by the fact that the system operates on multiple servers. Predominantly, each server has its own composition of roles. In this step, we will investigate how the system is ensured to be unified into a single entity. For clarity, let’s present the following scheme of roles distribution to servers on a site (see Fig.)

If we were talking about a simple application running on 4 servers, let’s take a calculator for example, it would be just 4 independent calculators. And we have a system where each instance of the program on each server (more precisely, on each node) performs a certain set of roles. At the same time, from the application’s point of view, everything is the same on all servers, but it functions differently. Only the whole system has those useful qualities that satisfy the whole set of requirements.

How does each of the servers know which roles it should fulfill? How does each role on a server know where the other system services it needs are located? In particular, the WS role needs a DC, and not just as an application, but specifically as a service, that is, a running application with active processes and data. You can’t just address locally, because locally the DC role is not executed (see site schema - one role on each server), but only has a set of program files due to the identity of program directories on all servers.

This is the responsibility of the configuration_ - the structure that connects the infrastructure, logic, and data layers together. Which server belongs to which site, what addresses the servers have, what roles are performed on which servers, what domain zones are served on which sites, and other data. The configuration is defined by a configuration_ file, and is uniform across all servers in the system. Each node on each server draws information from the configuration about which servers are part of the infrastructure, discovers itself, determines which roles to activate, and which servers host the other roles_.

Running the platform application on the server schematically looks like this:

Another chart..

`The application starts the root node, where the _ServerShell service role is activated. Its main task is to start and monitor child ServerShell nodes based on the configuration file. Each working node starts the BasedRole process, which starts the target functional roles based on the configuration file. If something happens to a working node, ServerShell restarts it instantly. If something happens to an instance of the target role in the working node, it is restarted by the service Boot.