frostfs-node/docs/epoch.md
Anton Nikiforov 05249e6c6b
All checks were successful
DCO action / DCO (pull_request) Successful in 4m50s
Vulncheck / Vulncheck (pull_request) Successful in 5m28s
Build / Build Components (1.21) (pull_request) Successful in 7m6s
Build / Build Components (1.20) (pull_request) Successful in 7m15s
Tests and linters / Staticcheck (pull_request) Successful in 4m19s
Tests and linters / Lint (pull_request) Successful in 5m32s
Tests and linters / Tests (1.20) (pull_request) Successful in 10m14s
Tests and linters / Tests with -race (pull_request) Successful in 10m22s
Tests and linters / Tests (1.21) (pull_request) Successful in 10m27s
[#841] doc: Describe epoch
Signed-off-by: Anton Nikiforov <an.nikiforov@yadro.com>
2023-12-07 17:08:31 +03:00

2.5 KiB

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)
...
>

Once epoch timer ticks, 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

Command goes directly to the 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.