Real Time Replication Between Two Linux Servers for Data Failover

Client: NDA Signed & Protected

Location: United States (US)

Platform

Bare-Metal

Industry

Health

Replication Type

Real-time

Provider

OVHCloud

Customer Requirement​​

The client provided us with a requirement of having a real-time file replication between two or more servers. This means any change made in one server should be reflected in the rest of the servers. The client also requested that the system be robust and self-healing, which means it should be capable of automatically detecting and recovering from issues without any manual help. Also, the setup should maintain a high level of stability and performance so that the application relying on these files continues to run smoothly without any disruption.

Challenges​

According to the client’s request, the file replication solution must be self-healing, reliable, and quick, ensuring synchronization of data across multiple servers. The setup includes heavy input-output operations by services like FTP transfers, Samba file sharing, and web server activity, which demand real-time accuracy and consistency. Such usage may add a high I/O workload, which might affect the performance and stability of the replication system. In addition to this, the client maintains strict security protocols, due to which the entire process had to be executed remotely through secure terminals.

Skynat's Proposal and Implementations
  • Analysis: Skynats had created a proposal as per the client’s requirements. After deeply analyzing the client’s constraints and requirements, we did an in-depth evaluation of all the open-source file replication systems in the field. Our research and development team built and tested multiple replication setups in controlled environments to evaluate their performance and stability under load. Based on the findings from our team, we concluded that GlusterFS is best for the replication.

  • Designing the Architecture: We set up two servers and installed GlusterFS on them. On each server, the other server was added as a trusted peer. Then we verified the peer status for successful communication between both servers. On both servers, we created a directory that acts as a brick (the actual storage location for GlusterFS), as well as a mounting point where the replicated volume can be accessed. A new GlusterFS volume was created on one server with replication enabled for the brick directories, which ensures that all data written there will be reflected on both servers. Then the volume is mounted to both servers, and the setup is tested to verify that the files were immediately available on both servers after creation, confirming real-time replication of files.

  • Implementation: We implemented the entire architecture in a staging environment and tested the system’s efficiency by applying a load to it. We subjected the setup to sustained high I/O operations by using traffic patterns from FTP, Samba, and web server. The system was under testing for a week, during which our team analyzed the performance, resource usage, fault recovery, and replication integrity, and based on the results, we made several performance optimizations and fine-tuned configuration parameters to ensure optimal behavior in the production environment.
  • Troubleshooting: We did continuous monitoring and troubleshooting to ensure that there are no volume creation failures, stable connection between servers, files are replicated properly, the status of GlusterFS is running and latency in replication due to heavy load.

Implementation Timeline​

The project was completed in 2 weeks with deployments, testing, auditing, and final delivery.

Results and Conclusion​

With proper planning, designing, testing, and monitoring, we successfully fulfilled the client’s requirement and implemented the system in production, and it has been running effectively for more than a year.

Have Similar Requirements ?

Let us know your requirement.

Thank You

We have received your query and will get back to you soon.