Skip to main content
Skip to main content

Shared Storage Technical Details

Zerops Shared Storage is built on SeaweedFS ↗, a distributed filesystem optimized for high-volume storage with efficient retrieval.

Architecture

Shared Storage consists of three main components:

  • Master Server: manages metadata and coordinates volume servers
  • Volume Servers: store the actual file data
  • Filer: provides a POSIX-compatible interface for file operations

Storage Engine Behavior

SeaweedFS stores file data in append-only volumes. Files are split into chunks, and when a file is modified, new chunks are written while the old ones remain on disk until they are reclaimed. Frequent small modifications of existing files therefore cause significant write amplification, which is one of the reasons Shared Storage is not suitable for databases.

An automatic vacuum process reclaims the space occupied by deleted and superseded chunks. This process is triggered when the size of deleted content exceeds 15% (reduced from the SeaweedFS default of 30%).

Deployment Modes

Zerops provides Shared Storage in two deployment modes:

Highly Available

Recommended for production environments where data reliability is critical.

  • Architecture: Two containers, each running its own filer and volume server; the master server runs on the first container
  • Data Durability: Data and filer metadata are replicated 1:1 across both containers
  • Fault Tolerance:
    • If a node fails, an automatic repair process begins
    • A new container replaces the failed one
    • Data is automatically replicated to the new container (duration depends on data size)
    • During master node failure, mounted directories become temporarily unavailable until the new master initializes (~30s)

Single Container

Suitable for development environments or non-critical data storage.

  • Architecture: Master, volume, and filer server all located on a single container
  • Data Durability: All data is lost if the container fails
Warning

The deployment mode is fixed after the service is created and cannot be changed later.

Filesystem Capabilities

Shared Storage supports standard POSIX filesystem operations:

  • Create, read, update, and delete files and directories
  • Set permissions (with some limitations)
  • File locking (per mount only, see the warning below)
  • Hard and symbolic links
  • Directory listing and traversal

For a complete list of supported features, see the SeaweedFS FUSE documentation ↗.

File locks are per-mount only

File locks (flock, POSIX locks) are enforced only within a single container's mount. A process in another container can freely write to a file you hold locked. Do not rely on file locking for coordination between containers, and do not run lock-dependent workloads such as databases on Shared Storage.

Storage Capacity

The 60GB data limit is independent of disk scaling

A Shared Storage service holds at most 60GB of data, no matter how much disk the service scales to. The disk resource (up to 250GB) provides headroom for the vacuum process and filesystem metadata; raising the disk limits in autoscaling does not increase the amount of data you can store.

If you need more than 60GB, contact support.

  • Maximum storage space: 60GB (can be increased via support request)
  • Maximum file size: no fixed limit through the mount (files are stored in chunks), up to the available storage space
  • Maximum upload size via Filer UI: 64MB per file

Performance Considerations

  • Latency: higher latency compared to local storage due to the network-based distributed architecture
  • Write performance: for write-heavy workloads, batch operations where possible
  • Small files: minimize operations with many small files for better performance
  • Mount process memory: the mount process runs inside each connected runtime container and consumes its memory, roughly 60MB when idle and around 150MB under higher filesystem loads; it is optimized for low RAM usage, which may trade off some performance

Auto Scaling Configuration

Zerops scales Shared Storage services automatically by raising or lowering the hardware resources of each container.

Vertical auto scaling has the following default configuration:

 MinimumMaximum
CPU cores18
RAM0.5 GB48 GB
Disk5 GB250 GB
Note

Disk size only gives the storage engine working space; the usable data capacity stays capped at 60GB. See Storage Capacity.

For most cases, the default parameters will work without issues. If you need to limit the cost of the Shared Storage service, lower the maximal resources. Zerops will never scale above the selected maximums.

When you are experiencing problems with insufficient Shared Storage performance, increase the minimal resources. Zerops will never scale below the selected minimums.

You can change the auto scaling parameters at any time.