Step 7: Ensure scalability

The site must be able to withstand any predetermined load. This means that for the planned maximum load of target requests coming to the site, it should be possible to create such an infrastructure and configuration on it that the site will be able to serve all these requests without visible problems. So far we have considered few variants of requests, but already on this essentially the only considered example with CRUD-operations, you can imagine how the load can increase by orders of magnitude.

We start with the simplest, one site - one server:

Powering up the system. The WS heats up, the SDC puffs. At the moment when it turns out that the load average (total CPU, memory, and disk utilization) on the server is approaching half the limit, it is worth adding another server to the infrastructure and configuration. What does this mean with a single server on the site? For example, spread the roles of WS and DC across different servers in the configuration. The load on IC in the case study is small, so assuming that the load on SDC is less, let’s leave it on the server with the role of SDC:

Load further. Now the dedicated WS server is approaching the limit of its performance. We add another server and place a duplicate WS on it. Earlier we found out that WS is reserved in the Active-Active mode, so the reservation is the essence of scaling. We give half of the administrators the address of the first server, the other half the address of the second server, or set up hashing on DNS.

Load more. It’s getting "hard to breathe" for the server with SDC. And what to do with it? After all, it can only be reserved in Active-Passive mode, which means it doesn’t multiply within the site like WS. Transferring the load to another site will not be a solution - the master site has the same MDC with the same Active-Passive reservation, and the load will be concentrated on it and stall the overall scaling. This is where the multi-domain structure comes to the rescue. Form a domain tree, limit the number of entities in each domain, including the administrators working in them. We add a server to the infrastructure and create several _role groups SDC in the configuration for the site. These are mapped to domain zones and on that basis there can be multiple active at the same time. They do not reserve each other, but complement each other in terms of combining into a complete domain tree. And each may have a reserve instance. The sign of reserve is the same group index and as a consequence the same set of parameters, including the relationship to domain zones. Our 100,000 administrators are distributed over a certain number of domains, the load on servers is distributed, and the potential for further load growth is gained.

In this scheme, there are two servers with no active services (Server2 and Server4), and it would be possible to move two WS roles to them, saving a couple of servers (remove Server6 and Server7 from the configuration). The feasibility of such a compaction of roles on a server depends on additional external requirements and conditions. Arguments against compaction include the following:

You can further increase servers, add WS roles, add domains, add SDC roles on the work site and similarly MDC roles on the master site. We will only be limited by network bandwidth - between the servers of a single site, and between the work site and the master site. It is quite possible to roughly calculate the limit of this load for each value of network bandwidth within a site and between sites.

And MIC doesn’t work with domains and doesn’t have a similar ability to split into groups. So what happens if you load the system with configuration changes? No, it won’t work, because MIC handles requests one by one, and will deny an action until the previous one is completed.

By the way, the configuration validator on MIC will not allow misconfiguration of role groups. That is, it will not allow it: