Logic behind replication factor

Help IPFS Cluster
1

When someone sets a replication factor, what is the method used to select the other cluster nodes the file will be pinned on?
Random? Load balancing? Low latency? Other?

1 Like
2

Hi,

cluster comes with an allocator component that, given a set of metrics for each peer, will sort those peers into a priority list. The pins will go to the peers with most priority.

This approach will allow to provide great flexibility in the future, but for now, the metric is free ipfs repository space (Max-Used from ipfs repo stat) and the sorting is descending. So your pins are allocated to the peers with most free space.

If you think of a different allocation strategy that would be useful to you, I’d love to hear about it.

Also, you can now check the values for the freespace metrics with ipfs-cluster-ctl health metrics freespace.

2 Likes
3

Hi @hector

Free repo space is a logical first option for general purposes.
Please consider a few alternatives:

  1. For usecases where speed matters most, cluster could keep stats on connection speeds and replicate to neighbors with the smallest latency.

  2. For usecases where geography matters, cluster nodes could store gealloc data, so we could have geofencing features.

  3. For usescase where lightweight subclustering is needed, each node could have its own list with the most preferable nodes for replicating files.

I think (3) would be the most usefull right now, since it reduces the need for composite clusters.

3 Likes
4

@plexus Could please explain a bit further how the third strategy would reduce the need for composite clusters? I am interested to understand how that would work.

5

Hi @lanzafame

I will use my own usecase as an example.

In my understanding, one of the features composite clusters can offer, is that we can have some kind of subclustering: Multiple clusters with strong replication inside them, can be loosely connected to other clusters, creating a large cluster that has some form of organizational structure regarding file replication.

The above can be easily achieved with a feature of a custom “replication node list”. Such a list could be manually created in each node and it would contain the IDs/multiaddresses of the other nodes that are preferable for replicating local pins.
At the top of the list are the most preferable and the order is descending.
In that way we can have custom “enclaves” inside a single cluster, without the need of composite clusters.

In my case this would be extremely useful, because i’ d like to control which nodes are selected each time a replication is needed. That is because i need subclustering but with evenly distributed groups.
With the current option, the largest nodes will monopolize the replication, so all the the allocations will be on the same few machines.

I haven’t dived into the code yet, so I wonder if there is a fairly easy wait to do this now.