Step 6: Ensuring accessibility

The input requirement is for the system to have high availability and provide full functionality if any of the servers go down and there is a loss of communication between any of the sites. This is accomplished by _reserving all required roles on each site.

Consider the case of deploying the system on the following infrastructure.

The distribution of roles known at this step could, for example, look like this:

In the above role allocation scheme, it is worth noting that even if one of the _sites loses both communication with other sites and one of its servers at the same time, the case from step 1 will still be executed on it. The system will actually switch to the single-server mode discussed in step 1 at that site. All functional services will be centered on a single server, and each at its own level will expect to communicate with other servers and the sites from configuration known to the server.

Two servers at a single site is the smallest infrastructure on which it is possible to provide availability through reservation of all roles. Therefore, the alternative ways of allocating roles in the above example are reduced to changing redundancy sequences or partially doing away with redundancy. That is, there are no alternatives.

When servers and communications are fully available, any instance of WS is a fully functional API access point - this is a Active-Active reservation; role instances are shown in the same color in the diagram. DC and MIC are reserved differently - only one instance of the role on the site is active, and the second one is activated when the first one suddenly becomes unavailable - this is reservation of Active-Passive type (alternative concept - role-flow, related terms FailOver and TakeOver), in the diagram active and passive (reserve) instances are shown in different colors.

All roles of the system are reserved according to one of the principles described above (Active-Active or Active-Passive). In both cases of redundancy there can be 2,3,10 and as many servers with the same role, but if for Active-Active it makes sense in terms of load balancing, then for Active-Passive roles it is hardly reasonable to have more than 3 redundant servers for the same role, unless the problem is to ensure availability in case of simultaneous loss of 3 servers for the same role. the task of ensuring availability in case of simultaneous loss of 3 arbitrary servers is solved.