Building a highly available MFS Distributed file storage architecture

Now there are a large number of enterprises using the shared Storage server NFS to the Application data network storage, but there are performance bottlenecks and single point of failure problem, so the Distributed file Storage Management system began to become popular. Its advantages are self-evident, this article for everyone to recommend the open source of Distributed File system MFS, compared with NFS it is a many-to-many relationship, this way, the performance of a significant increase, while the reliability is much higher! I believe it is helpful to everyone.

As we all know, the current MFS metadata server has a single point of problem, so we can provide disk through DRBD synchronization, through the heartbeat to provide failover, to achieve high availability.

I believe DRBD has learned that DRBD (distributed replicated block Device) is a piece of equipment that can be used in high availability (HA). It is similar to a network RAID-1 function. When you write data to the local filesystem, The data will also be sent to another host on the network. Recorded in a file system in the same form. Data from the local (primary) and remote host (standby node) can be synchronized in real time. When a local system fails, the same data is kept on the remote host and can continue to be used. In high availability (HA) Use the DRBD feature in place of a shared disk array. Because the data exists simultaneously on both the local host and the remote host, the remote host can continue the service as long as it uses the backup data on it.

The working principle of DRBD is as follows:

+----------+

| File System |

+----------+

|

V

+-------------+

| Block Device Layer |

| (/DEV/DRBD1) |

+-------------+

| |

| |

V V

+------------+  +-------------+

|  Local Hard Drive | | Remote Host Hard Drive |

|  (/DEV/SDB) | | (/DEV/SDB) |

+------------+  +-------------+

As for MFS more knowledge can look at relevant information! No more talking here! Here is just a description of the next MFS file system composition!

The composition of the MFS file system:

1. Meta data server. In charge of managing the file system throughout the system, MFS currently supports only one metadata server master, which is a single point of failure that requires a stable server to act on. It is hoped that in the future MFS can support multiple master servers to further improve the reliability of the system.

2, data Storage server Chunkserver. The server that really stores the user's data, storing the files, first blocks the files, and then the blocks are replicated between the data server Chunkserver (the number of copies can be manually specified and the recommended number of replicas is set to 3). The data server can be multiple, and the larger the number, the smaller the amount of disk space that can be used, and the higher the reliability.

3, metadata log server Metalogger. Responsible for backing up the master server's change log file with a file type of Changelog_ml.*.mfs so that it can be replaced when master server is in trouble, with new features added in version 1.6.

4, the client. A host that uses the MFS file system to store and access is called a MFS client, and after a successful mount of the MFS file system, it is possible to share this virtual storage with NFS as before.

The entire system architecture diagram is as follows: