Github-Mirror/seaweedfs
1
0 Fork 0
mirror of https://github.com/seaweedfs/seaweedfs.git synced 2026-11-02 10:17:10 +01:00
Code Issues Packages Projects Releases Wiki Activity

Simplification and grammar

Scott Edlund committed 2024-04-09 02:55:14 +08:00
1 parent 00b68d3574
commit 3ef0082c26
1 file changed
+4 -10
Download Patch File Download Diff File Expand all files Collapse all files
Components.md
+4 -10
@@ -1,12 +1,10 @@
# SeaweedFS Components
SeaweedFS comprises 3 main conceptual components. The master service and the volume service together provide a distributed object store, with user-configurable replication and redundancy. The optional filer and S3 service are additional layers on top of the object store. Each of these services may run as one or separate instances, on various actual servers.
SeaweedFS comprises 3 main components. The master service and the volume service together provide a distributed object store, with user-configurable replication and redundancy. The optional filer and S3 service are additional layers on top of the object store. Each of these services may run as one or separate processes, on one or more operating systems.
## Master service
The essential master service works smart, not hard.
It represents a cluster of 1 (or 3 or more servers) that own a consistent view of the entire SeaweedFS cluster and communicate it to all participating nodes, through a Leader elected via Raft protocol.
It represents a cluster of 1 (or 3 or n/2+1) that own a consistent view of the entire SeaweedFS cluster and communicate it to all participating nodes, through a leader elected via [Raft](https://raft.github.io/) protocol.
The number of servers in the master service must always be odd, to ensure that a majority consensus can be formed. You're best off keeping this number down, a small number of stable servers is better than a large pool of flakey boxes. 1 or 3 is typical.
@@ -18,17 +16,13 @@ If the leader is unavailable, the raft consensus protocol ensures that a new lea
## Volume service
The volume service is where the hard work is done.
It packs many objects (files and chunks of files) efficiently into larger individual volumes, which can be arbitrarily large blocks on disk. Redundancy and replication of data is managed at the volume level, not on a per-object level.
Each volume server sends periodic heartbeats with status and volume information back to the leader, via a master.
## Filer service
The optional filer service does heavy lifting so you don't have to.
It organizes SeaweedFS volumes and objects, into user-visible paths (like URLs or file systems) over HTTP or UNIX FUSE mounts.
It organizes SeaweedFS volumes and objects into user-visible paths (like URLs or file systems) over HTTP or UNIX FUSE mounts.
Filer provides a convenient and common abstraction that can be used to provide normal looking filesystems, or web APIs for down/uploads, to existing applications without modification.
@@ -38,7 +32,7 @@ This optional service provides AWS style S3 buckets, similar to the filer servic
## Volume Concept
The volume in SeaweedFS means a single actual file consists of many small files. When master starts, it configures the volume file size, default to 30GB. At the beginning, there are 8 volumes created.
In SeaweedFS, a volume is a single file consisting of many small files. When a master server starts, it sets the volume file maximum size to 30GB (see: `-volumeSizeLimitMB`). At volume server initialization, it will create 8 of these volumes (see: `-max`).
Each volume has its own TTL and replication.