The software architecture showed in the diagram below, represents a High Availability (HA) system used to provide a continuous service even in case of network or system failure.
This type of architecture is not intended to implement a load balancing service but instead to assure business continuity. In case of failure of the Primary Host, it will assure the regular thin clients operation by accessing the Secondary Server. The secondary server will continue to supply the thin clients and users with ThinMan services as user login, user and device policies and profile deployment.
All administrative features as add new devices, profile and policies management are possible only operating on the ThinMan Primary Server. In other words the ThinMan Primary and Secondary server configuration allows, in case of a failure on the ThinMan Primary Server the clients/users business continuity, but doesn't permit administrative operations.
Whichever redundant solution require mandatory to use an external Database that have to be reachable for both Primary and Secondary ThinMan Server.
Until now we focalised only on ThinMan server redundancy.
In the same way, even on the database side we can reach different degree of redundancy. ThinMan, indeed, offer a Primary and Secondary server configuration that can use both a single and a dual Database Server implementation.
We can define these two distinct configuration as "ThinMan HALF redundant configuration" and "ThinMan FULL redundant configuration".
Both these will be depicted in tetail hereinafter.
¶ ThinMan HALF redundant configuration
The simplest architecture involves two ThinMan Server and only one Database instance as depicted in the picture below.
This solution assure a redundant solution only for the ThinMan Application Server, whereas the Database Server remains a single point of failure, unless it be already implemented on a high availability infrastructure.
ATTENTION! In any case this solution requires a forced service unavailability during a ThinMan servers software update.
¶ ThinMan FULL redundant configuration
The most resilient solution presents a redundant installation both on ThinMan Application Server and Database Server side.
As you can see in the picture below, a dual Database Instance assure business continuity even at Database service level. Both Primary and Secondary ThinMan Servers are connected each one to a distinct database.
In case of failure of Primary ThinMan Server or of its database (Master Database), the secondary ThinMan Server will continue to offer to the clients all standard ThinMan services by way of the Slave database, assuring user business continuity.
FULL AVAILABILITY ThinMan FULL redundant configuration assure users business continuity even during a ThinMan software update.
The Database consistency and alignment is carried out by MySQL Replication between dual external DB instance that permits the correct updating of all data from the Master Database towards the Slave one.
This architecture is recommended when ThinMan authenticates users on thin clients and especially when User Profile configuration is used.
This architecture is configured as follow:
- The Primary ThinMan server on the first host, connected to the Master MySQL Server.
- The Secondary ThinMan server on the second host, connected to the Slave MySQL Server.