MooseFS 5 Pro Launch: Geo-Aware Storage with Multilocations
MooseFS 5 Pro is here — and it brings a major new capability that changes how distributed storage works across physical infrastructure: Multilocations. Whether you’re running a two-datacenter setup, managing research clusters across facilities, or serving content globally, Multilocations fundamentally change how you think about distributed storage. This feature is available exclusively in MooseFS 5 Pro.
What Are Multilocations?
Multilocations let you divide your MooseFS cluster into logical segments that correspond to physical locations — different racks, server rooms, buildings, or even cities and data centers separated by hundreds of kilometers. Each location houses its own set of MooseFS modules (at least one chunkserver is required per location; master and metalogger modules are optional).
The key insight is that storage classes now have per-location definitions. Every data lifecycle state — CREATE, KEEP, ARCHIVE, TRASH — can be configured independently for each location, with different redundancy levels and even different formats (copies or Erasure Coding). This gives you fine-grained, policy-driven control over exactly where your data lives and how it’s protected.
Crucially, Multilocations are entirely optional. Upgrading to MooseFS 5 Pro doesn’t force you into anything new. Your existing cluster will behave exactly as before, operating in a transparent single-location mode until you decide to take advantage of the new capabilities. The current hard limit is 8 locations per MooseFS instance.
Why It Matters: Key Benefits
1. Per-Location Storage Policies
Each location can follow a different storage definition within the same storage class. For example, you can keep your data in copy format in the main location for fast, straightforward access, while simultaneously storing it in Erasure Coding format in a backup location to save space — all automatically, without separate storage classes or manual intervention.
2. Location-Level Maintenance Without Cluster Downtime
One of the most operationally valuable features: you can disable an entire location (for maintenance, hardware failure, or network issues) without putting the whole cluster into an emergency state. There’s even an intermediate IO state, which keeps a location available for reads and writes while pausing replication and rebalancing — ideal for temporary network degradation.
3. Smarter Leader Election
The leader election algorithm has been redesigned from the ground up to work correctly with uneven location sizes. Rather than requiring a raw majority of chunkservers, the new algorithm gives each location a single vote. A Leader is elected when either a majority of locations agree, or when exactly half do — provided the default location is among them. This means a healthy location can always maintain cluster operations even when another location fails entirely.
Real-World Use Cases
Primary and secondary datacenter — Users work from the primary DC; all data is automatically mirrored to a secondary DC. If the primary fails, operations switch over with no data loss.
Wide-area cluster with a single namespace — Teams in different offices or cities share one filesystem and access data locally, reaching across locations only when needed.
Work DC + disaster recovery backup — Permanent data is written to the main datacenter and replicated to one or more backup sites for disaster recovery. Temporary data stays local.
Content delivery — Media is recorded once, replicated across locations, and clients connect to the nearest location for read-only access.
New Tools and Updated Interfaces
mfslocadmin – The New Location Manager
A dedicated tool for creating, configuring, and managing locations. Key operations include:
create/rename/delete— manage location lifecyclemap/unmap— assign module IP addresses to locations; any unmapped module automatically falls into the default locationstate— toggle a location between ON, IO, and OFF statessetdefault— designate which location holds the tie-breaking vote and accepts all unassigned modules; the default location cannot be switched OFF
Updated mfsscadmin
The storage class tool gains a new role for the -l flag: it now specifies which location a storage definition applies to. Definitions can be asymmetric — you might keep 1 copy in location A and 3 copies in location B within the same storage class. A zero expression (-C 0, etc.) explicitly means “store nothing here,” which is different from an empty definition that inherits from KEEP state.
GUI and CLI Monitoring
When locations are active, monitoring tools reflect the topology automatically:
- The Status tab shows the cluster map divided by location
- The Info tab gains a location table and per-module location columns
- Chunkservers, Mounts, and Redundancy views all gain location-aware columns
mfsfileinfoshows which location each chunk copy or EC part resides in
A Note on Zero Expressions
One subtlety worth highlighting: with Multilocations, the distinction between an empty definition and a zero definition becomes important. An empty state (like no CREATE definition) inherits from KEEP. A zero expression (0) explicitly instructs the system to store nothing for that state in that location. This is the mechanism that enables patterns like “create chunks only in the primary location, then let them replicate to backup locations in KEEP state.”
Enhanced Server Authentication and I/O Security
MooseFS 5 Pro also significantly strengthens cluster security with a new, cluster-wide authentication model. Previously, authentication in MooseFS was limited to two areas: chunkservers could be required to present an auth code before the master would accept them, and exports could be password-protected to control client mount access. Inter-module communication — between chunkservers, or between clients and chunkservers — was not covered.
In version 5, this has been addressed. A new global setting enables authentication across all internal cluster communication. When turned on, all modules (master, chunkservers, metaloggers) authenticate with each other using a shared auth code. On the client side, password-protected exports become mandatory — and clients must obtain a session token from the master before they can read data from a chunkserver. Without a valid token, direct data access is not possible. This means that access to data is now fully gated through the master, closing off any possibility of bypassing export-level permissions at the storage layer.
Upgrading from MooseFS 4.x
The upgrade procedure is unchanged. After upgrading to version 5 Pro, your instance will look and work identically to MooseFS 4 — the location tools are installed but dormant. Multilocations only activate when you explicitly create your first named location.
When migrating an existing cluster that already uses chunkserver labels to represent physical separation, the recommended approach is to temporarily block replications during the reconfiguration (by placing one chunkserver in maintenance mode) to avoid needless data movement while storage class definitions and IP mappings are being updated.
Summary
Multilocations are a mature, flexible feature designed for production infrastructure where data placement, redundancy, and availability need to be managed across physical boundaries. It’s available today in MooseFS 5 Pro.
Want to try it out before committing? MooseFS 5 Pro is available for free for personal, non-commercial use — so you can explore Multilocations and all other Pro features in your own environment at no cost. Check the version comparison to see what’s included in each edition. A Community Edition release is also planned for the future — it will share the same codebase as v5 Pro, though no timeline has been announced yet.
If you’re running multi-site infrastructure or planning to, now is the time to take a closer look at what MooseFS 5 Pro can do for you.