Evidian SafeKit provides Windows file replication and Windows clustering between 3 servers. This feature is an extension of a mirror application module with the replication of data on a third server supposed to be in a Disaster Recovery site (DR Site).
2 SafeKit modules are required for implementing Windows file replication and Windows clustering between 3 servers: the application module and the spare module.
The application module works between server 1 and server 2 as a standard mirror module with
With the semi-synchronous real-time replication between server1 and server2, the application does not wait the acknowledgement of server3 before restarting its execution.
The other module (named the spare module) makes the real-time replication to the DR site.
Each directory defined replicated inside the application module has a spare directory. On the SECOND server of the application module (3nodesrepli/server2 in the picture), the spare directory is maintained as a copy of the corresponding directory by SafeKit. And the spare directory is replicated in real-time on the DR site by the spare module.
Note that this architecture can also be implemented by a mixed of a Hyper-V module and an application module. See the Hyper-V synchronous replication and automatic failover between 3 servers article. The advantage of the Hyper-V architecture is that the failover and the failback on the 3rd server are automatic while a manual procedure in the SafeKit web console is required for this architecture (see in the next sections).
An application module named 3nodesrepli.safe has been developed as an extension of the mirror module to simplify the installation. And the SafeKit web console helps in the deployment of this module on 3 servers.
In the configuration wizard of 3nodesrepli.safe, the identity of the 3 servers are entered.
When configuring a new replicated directory, a spare directory must be defined which will be a copy of the original directory.
Among the 3 servers, the server in the disaster recovery site must be identified.
The first time, the server with the up-to-date data must be identified in order to synchronize data in the right way.
Finally, the system is high available
When server 1 and server 2 fail, the application failover to the DR site is possible with a manual procedure integrated in the administration console.
When server 1 and server 2 come back, the application failback from the DR site to server 1 and server 2 is possible with a manual procedure in the administration console.