Multilocation Management Tools
Operating a cluster with Multilocations involves three primary interfaces: mfslocadmin for location management, mfsscadmin for storage class definitions, and the standard GUI/CLI tools for monitoring. These tools seamlessly transition to "multilocation mode" as soon as the feature is activated.
mfslocadmin
The primary tool for managing Multilocations is mfslocadmin. It handles the creation, configuration, and lifecycle of locations. All locations are referenced by name, similar to how storage classes work.
You can always access contextual help for any command by appending the -? parameter.
Creating Locations
mfslocadmin create or mfslocationcreate
Creates a new location with the specified name.
When the first named location is created, two locations become visible. This is because MooseFS 5 always operates on locations internally. However, as long as only a single location exists and no additional definitions (such as mappings or storage classes) are configured, this location remains hidden for convenience.
Creating the first user-defined location effectively reveals the initially hidden one. This original hidden location is named default and can be renamed using mfslocadmin rename described below.
Renaming Locations
mfslocadmin rename or mfslocationrename
Renames an existing location based on the provided old name and new name.
Listing Locations
mfslocadmin list or mfslocationlist
Displays a comprehensive list of existing locations, including:
- location names
- the designated default location
- IP addresses mapped to each location
Mapping IPs to Locations
mfslocadmin map or mfslocationmap
Assigns IP addresses to a location. Each MooseFS module (chunkserver, master, metalogger) belongs to exactly one location: the one to which its IP is mapped. If a module's IP is not mapped to any location, it will belong to the default location. Overlapping IP mappings are not permitted.
Unmapping IPs from Locations
mfslocadmin unmap or mfslocationunmap
Removes an existing IP-to-location mapping.
Both mapping and unmapping IPs can change the location of existing, working MooseFS modules. Double-check the IPs before issuing these commands, especially when using the force option. Chunkservers that move from one location to another are immediately used to host chunks for their new location, which may trigger unexpected replications and deletions.
Setting Location State
mfslocadmin state or mfslocationstate
Sets a location to one of three possible states:
| State | Description |
|---|---|
ON | Fully operational. |
IO | Available for I/O, but chunk replication and rebalance are limited or disabled. Use this to mitigate temporary network issues without compromising data integrity. |
OFF | Disabled. |
The default location cannot be switched to OFF state. To disable it, first promote another location to be the default using mfslocadmin setdefault.
Setting the Default Location
mfslocadmin setdefault or mfslocationsetdefault
Sets the given location as the default. There is always exactly one default location in a MooseFS cluster. The default location:
- accepts all modules that are not explicitly mapped to another location (implicit mapping)
- holds the deciding vote in the event of a tie during leader master election
- cannot be switched to
OFFstate
Deleting Locations
mfslocadmin delete or mfslocationdelete
Deletes an existing location. A location can only be deleted if it is completely empty:
- it has no IP mappings
- all storage class definitions for this location are cleared
- it is set to
OFFstate
If you delete all locations but one, the last remaining location will still be visible system-wide (in the GUI, CLI, and other tools). To hide it again (reverting to non-location mode), remove all IP mappings and rename it back to default.
mfsscadmin
The storage class tool mfsscadmin has been updated for Multilocations. The main features remain the same; the key change is how the -l switch works. In previous versions, -l was used only by mfsscadmin list to show additional details. Starting from MooseFS 5 Pro, -l is used by all commands to specify the location to which the subsequent -C, -K, -A, and -T switches apply.
Defining Storage Classes with Locations
In MooseFS 4 (and MooseFS 5 without active locations), creating a storage class that keeps chunks in 2 copies on chunkservers labeled A looks like this:
mfsscadmin create -K 2A mynewclass
In MooseFS 5 Pro with locations active, this same command still works but uses the default location implicitly. For example, with two locations named foo and bar, where bar is the default, the resulting class would only record chunks in location bar.
To record 2 copies in chunkservers labeled A in both locations, explicitly specify each location:
mfsscadmin create -l foo -K 2A -l bar -K 2A mynewclass
This creates a storage class that keeps 2 copies in location foo and 2 copies in location bar – 4 copies total across the cluster.
Definitions do not have to be symmetrical. To keep 1 copy in foo and 2 copies in bar:
mfsscadmin create -l foo -K A -l bar -K 2A mynewclass
Modifying Storage Classes
The modify command follows the same pattern: use -l to specify which location's state definition (CREATE, KEEP, ARCHIVE, or TRASH) you are modifying.
Deleting Storage Classes
The delete command has two modes:
- Without
-l: deletes the entire storage class. - With
-l: deletes only the definition for the specified location, leaving other locations' definitions intact.
Empty vs. Zero Definitions
With Multilocations it is critical to understand the difference between an empty definition and a zero definition.
- Empty definition (state not defined for a location): the state inherits the
KEEPdefinition, just as in MooseFS 4. - Zero definition (
-C 0,-K 0, etc.): chunks are explicitly not stored in that location for that state.
A common use case is creating new chunks (CREATE state) only in one location and letting them replicate to other locations via KEEP. To achieve this, explicitly set CREATE to zero in the locations that should not hold new chunks:
mfsscadmin create -l main -K 2 -l backup1 -C 0 -K 1 -l backup2 -C 0 -K 1 myclass
CLI and GUI
When locations are active, the monitoring tools reflect this automatically:
- Status tab (GUI): the cluster map is divided into locations.
- Info tab (GUI): an additional table shows location names, states, mapped IPs, and the number of connected modules of each type per location. The same data is available in the CLI via
mfscli -SIN; the location table alone can be viewed withmfscli -SLO. - Info tab – Masters/Metaloggers table: a new column shows the location of each module.
- Chunkservers tab: a new column shows the location of each chunkserver.
- Mounts → Parameters and Mounts → Operations tabs: a new column shows the location of each client.
- Redundancy tab: each storage class entry has an expanded view showing details for every location.
mfsfileinfo
mfsfileinfo has no new options when Multilocations are active, but it provides additional information: for each chunk copy or EC part displayed, it now also shows the location in which that copy or part is stored.