LizardFS
 | |
| Developer(s) | Distributed FS Sp. z o.o.[1] |
|---|---|
| Stable release | 3.12.0
/ 21 December 2017[2] |
| Repository | |
| Operating system | Linux, FreeBSD, Mac OS X, Solaris |
| Type | Distributed file system |
| License | GPLv3 |
| Website | LizardFS.com |
LizardFS is an open source distributed file system that is POSIX-compliant and licensed under GPLv3.[3][4] It was released in 2013 as fork of MooseFS.[5] LizardFS is also offering a paid Technical Support (Standard, Enterprise and Enterprise Plus) with possibility of configurating and setting up the cluster and active cluster monitoring.
LizardFS is a distributed, scalable and fault-tolerant file system. The file system is designed so that it is possible to add more disks and servers “on the fly”, without the need for any server reboots or shut-downs.[6]
Description[edit]
LizardFS makes files secure by keeping all the data in multiple replicas spread over the available servers. This storage is presented to the end-user as a single logical namespace. It can also be used to build space-efficient storage because it is designed to run on commodity hardware. It has applications in multiple fields and is used by institutions in finance, telecommunications, medicine, education, post-production, game development, cloud hosting services, and others.
Hardware[edit]
LizardFS is fully hardware agnostic. Commodity hardware can be utilized for cost efficiency. The minimum requirements are two dedicated nodes with a number of disks, but to obtain a high available installation at least 3 nodes are needed. This will also enable the use of erasure coding.
Architecture[edit]
LizardFS keeps metadata (e.g. file names, modification timestamps, directory trees) and the data separately. Metadata are kept on metadata servers, while data is kept on chunkservers.
A typical installation consists of:
- At least two metadata servers, which work in the master-slave mode for failure recovery. Their role is to manage the whole installation, so the active metadata server is often called the master server. The role of other metadata servers is to keep in sync with the active master server, so they are often called shadow master servers. Any shadow master server is ready to take the role of the master server at any time. A suggested configuration of a metadata server is a machine with fast CPU, at least 32 GB of RAM and at least one drive (preferably SSD) to store several GB of metadata.
- A set of chunkservers which store the data. Each file is divided into blocks called chunks (each up to 64 MB) which are stored on the chunkservers. A suggested configuration of a chunkserver is a machine with large disk space available either in a JBOD or RAID configuration. CPU and RAM are not very important. You can have as little as 2 chunkservers or as many as hundreds of them.
- Clients who use the data stored on LizardFS. These machines use LizardFS mount to access files in the installation and process them just like those on their local hard drives. Files stored on LizardFS can be seen and accessed by as many clients as needed.
Features[edit]
- Snapshots - When creating a snapshot, only the metadata of a target file is copied, speeding up the operation. Chunks of the original and the duplicated file are shared until one of them is modified.
- QoS - LizardFS offers mechanisms that allow administrators to set read/write bandwidth limits for all the traffic generated by a given mount point, as well as for a specific group of processes spread over multiple client machines and mountpoints.
- Data replication - Files stored in LizardFS are divided into blocks called chunks, each up to 64 MB in size. Each chunk is kept on chunkservers and administrators can choose how many copies of each file are maintained. For example, choosing to keep 3 copies (configuration goal=3), all of the data will survive a failure of any two disks or chunkservers, because LizardFS will never keep 2 copies of the same chunk on the same node.
- Geo-replication - With Geo-replication you can decide where the chunks are stored. The topology feature allows for suggesting which copy should be read by a client in the case when more than one copy is available. For example, when LizardFS is deployed across two data centers, e.g. one located in London and one in Paris, it is possible to assign the label “london” to each server in the London location and “paris” to each server in the Paris location.
- Metadata replication - Metadata is stored on metadata servers. At any time, one of the metadata servers also manages the whole installation and is called the master server. Other metadata servers remain in sync with it and are shadow master servers
- High availability - Shadow master servers provide LizardFS with High Availability. If there is at least one shadow master server running and the active master server is lost, one of the shadow master servers takes over
- Quotas - LizardFS support disk quota mechanism known from other POSIX le systems. It offers an option to set soft and hard limits for a number of files and their total size for a specific user or a group of users. A user whose hard limit is exceeded cannot write new data to LizardFS.
- Trash - Another feature of LizardFS is a transparent and fully automatic trash bin. After removing any file, it is moved to a trash bin, which is visible only to the administrator. Any file in the trash bin can be restored or deleted permanently.
- Native Windows™ client - LizardFS Windows Client can be installed on both workstations and servers. It provides access to files stored on LizardFS via a virtual drive. The Windows client is a licensed feature to be obtained by contacting the creators of LizardFS - Distributed FS Sp. z o.o.
- Monitoring LizardFS offers two monitoring interfaces. First of all, there is a command-line tool useful for systems like Nagios, Zabbix, Icinga, which are typically used for proactive monitoring. Moreover, there is a graphical web-based monitoring interface available for administrators, which allows tracking almost all aspects of a system.
- Hadoop - This is a java based solution allowing Hadoop to use LizardFS storage, implementing an HDFS interface to LizardFS. It functions as a kind of a File System Abstraction Layer. It enables you to use Hadoop jobs to directly access the data on a LizardFS cluster. The plugin translates LizardFS protocol and makes the metadata readable for Yarn and Map Reduce
- NFS and pNFS - LizardFS uses NFS-ganesha server to create NFS shares, so technically NFS client connects not with the master server, but with a Ganesha file server that talks directly with LizardFS components. From the user point of view, it works just like an ordinary NFS server.
See also[edit]
- Hyper-converged infrastructure
- Distributed file system
- List of file systems#Distributed parallel fault-tolerant file systems
- MooseFS
- BeeGFS
References[edit]
- ^ "LizardFS".
- ^ "Releases · lizardfs/lizardfs". GitHub.
- ^ "LizardFS: Software-defined storage, as it should be (original article in German)". www.golem.de. April 27, 2016. Retrieved 2016-05-06.
- ^ "Mr. Blue Coat: (updated) Distributed File System benchmark". Retrieved 2016-05-06.
- ^ "ZFS + glusterfs on two or three nodes". permalink.gmane.org. Retrieved 2016-05-06.
- ^ Korenkov, V. V.; Kutovskiy, N. A.; Balashov, N. A.; Baranov, A. V.; Semenov, R. N. (2015-01-01). "JINR Cloud Infrastructure". Procedia Computer Science. 4th International Young Scientist Conference on Computational Science. 66: 574–583. doi:10.1016/j.procs.2015.11.065.