Epoch¶
The main purpose of the epoch
in frostfs
environment is to manipulate netmap
.
Each new epoch, ir
service trigger revision content of the netmap
by adding or removing nodes to or from it.
node
service trigger few internal processes each new epoch - for example, running GC.
Epoch also used in an object lifecycle.
At the startup, ir
service initializes an epoch timer which handles new epoch tick.
Epoch timer is a block timer - which means that this timer ticks each block or set of blocks.
The epoch duration stores in the configurable parameter EpochDuration
in the blockchain.
It is possible to get it via frostfs-adm
:
> frostfs-adm morph dump-config -c config.yml -r http://morph-chain.frostfs.devenv:30333
...
EpochDuration: 240 (int)
...
>
ir
service call method NewEpoch
of the netmap
contract. Each ir
instance can do this at the same time, but it is not an issue,
because multiple call of this method with the same set of parameters will give us the same result.
Utility frostfs-adm
have a command to trigger new epoch:
> frostfs-adm morph force-new-epoch -c config.yml -r http://morph-chain.frostfs.devenv:30333
netmap
contract and call method NewEpoch
.
Method checks alphabet witness and stores candidates nodes which are not in the OFFLINE
state as a current netmap.
Then executes method NewEpoch
in balance
and container
contracts.
At the end it produces notification NewEpoch
which is handled by node
and ir
services.
ir
handler for NewEpoch
updates internal state of the netmap, if it is necessary, updates state of the nodes or
marks for exclusion from netmap in the blockchain.
node
handler for NewEpoch
executes method addPeer
of the netmap
contract.
This method do nothing, but produces notification which handled by ir
service.
ir
in handler for AddPeer
may update node state in the netmap if it is necessary.
At the startup, node bootstraps with state ONLINE
. From the online state, it is possible to move to MAINTENANCE
or OFFLINE
.
Node moved to OFFLINE
state automatically, when there is no bootstrap request from it for a number of epochs.
This number stored in the ir
config netmap_cleaner.threshold
.
From OFFLINE
state node, once it bootstrapped, moves to ONLINE
.
MAINTENANCE
state persists even if node rebooted or unavailable for a few epochs.
Local netmap view¶
Application of a storage policy to the netmap produces a subset of nodes
used to select candidates for object placement and retrieval. To dynamically
adapt to node info changes, frostfs-node
merges info in the netmap with
candidates list. This affects object, control, container and tree services and
functionality of replicator and policer.
To adjust frequency of merging candidates with netmap in local cache, set duration
in netmap.candidates.poll_interval
of node
config section.
During the merge, the following node parameters are overriden: - Node status; - Node endpoints (external and internal values).
The node does not perform the following actions, as they affect object placement: - Adding new items to the network map; - Overriding node attributes.