The reason for this separation of names is that, in the previous introduction to Server Load balancer, we assume that each actual server has the same file and program. In fact, how does one implement the same resources for each actual server? In this article, we will share network sharing, Content Distribution synchronization, and distributed file systems.
Network Sharing
This approach is to place resources on a network server. Multiple actual request processing servers can access these resources in the same way, such as our common database servers, all our programs can access the database through the network. After obtaining the data, they generate HTML and return it to the user. In addition, we also mentioned the cache server in the cache, here we will introduce the file sharing system.
The file sharing system removes the need to consider network access and transmission details. You can access files on other server file systems on the network just like accessing a local file system. A file sharing system is not a general Disk File System. It cannot be used to store and manage disk data, but only defines the organization format and transmission protocol of files during network transmission, when a file is accessed in the way specified by the file system shared by the actual server application, the file format must be converted twice internally, it occurs when the actual file server enters the network and the network leaves the actual processing server.
Common file sharing systems include NFS and samba. NFS is mainly used on UNIX/lniux platforms. Samba is designed to map Unix/Linux Files to Windows Network neighbors, file Sharing between UNIX, Linux, and Windows is also supported. Of course there are other systems. We can decide which one to use based on actual needs and the characteristics of each system.
Although it solves the problem of file access, we must understand that, unlike disk Io, through the file sharing system, the maximum Disk Throughput, concurrent processing capability, and network bandwidth of the file server have become a major factor restricting our system. In addition, it is still a single-point-of-dependence solution. If a large number of shared files exist, we must consider other solutions, such as copying files to more servers and establishing multi-level redundancy.
Content Delivery and Synchronization
For the reason mentioned in the previous section, we need to copy the file to each server to allow the server to access the files on the local disk to process HTTP requests. We generally implement replication in two ways, active distribution and passive synchronization.
The so-called active distribution means that when a file is changed during the update period, if the user uploads a new image, the application will synchronize the image to other servers with the same function. If there are too many identical servers or deployed in different regions, we can solve these problems through multi-level distribution, separate the tasks from different machines, and initiate the server after synchronizing several nodes, several node servers are responsible for synchronizing the files of other servers in the cluster. In PHP, We have SSH, SFTP, and WebDAV. If file operations are too frequent, real-time file synchronization requests may be a disaster, and the server will process file distribution every moment.
Passive synchronization means that one end of the file actively initiates a request to the file server. If there are differences between the two, you can choose to update them to ensure file consistency on each server. In Linux, the rsync tool can do this well. We can set the update time gap, and synchronize every time, it seems to reduce the server pressure to a certain extent, however, if too many files are updated, the overhead of disk scan files compared with local disk files will be very large. However, the book mentions a method to reduce the scanning overhead, enable the inotify module of the Linux kernel, and monitor file movements through it. If any file changes after the modification time, an event notification will be sent, in this way, we can write a program to update the modification time of the file's parent directory until the root directory. In this way, you can find out whether there are any file changes at the earliest time, and exit the scan in time if there are no changes.
Distributed File System
Through the above methods, we seem to be able to solve the file synchronization problem, but the single point bottleneck of sharing, while distribution and synchronization, we need to implement too many scripts and logic and lack overall management and monitoring. Fortunately, we have another consideration: distributed file systems. Distributed File systems are not traditional operating systems. They work in user space and are implemented by applications, such as mogilefs or hadoop. They are more like the abstraction of underlying operating systems, this avoids restrictions on the file system and has its own content organization structure. For example, mogilefs supports domains and classes to facilitate reasonable planning of large-scale storage and replication.
When we use a specific interface to operate a distributed operating system, we can see a whole. However, behind a simple interface, a distributed file system can span multiple servers, automatically copy files according to your own rules. Of course, there are already a lot of distributed file systems available for you to choose from, as to how to use or internal implementation logic, advantages and disadvantages need to be thoroughly understood.
The file system is simple, but it is not so easy to use. Here we only provide an idea to solve the actual problem, "There must be a way to get to the mountains. Next, I will share the optimization and expansion of the database.