[0] https://docs.openstack.org/ironic/latest/_modules/ironic/com...
From what I can see in the UI, nodes are placed semi randomly on the ring (probably a hash itself determines the node placement) so don’t you still have the same problem that the hashing of virtual nodes onto the ring can still cause imbalances?
To me it seems like you should be trying to put new nodes on the ring within the largest gaps on the ring.
There are probably other issues where simultaneously added nodes may try to insert themself into the same position in the ring, you could add some jitter in the placement to compensate for this, but then I guess you are now introducing randomness which is one step closer to just having vnodes again.
In Cassandra's consistent hashing & many others, you can also juggle vnodes around between nodes as you please, which, if you have hotspot vnodes, gives you some chance to add some anti- affinity for the hot vnodes.
https://docs.datastax.com/en/cassandra-oss/3.0/cassandra/arc...
In the real world some platform team does this (or AWS) and then probably one person in that team for one week implements it. Although good for everyone to understand.
You can use it to ensure a request for a user ends up generally at the same node. If that users workload creates state (even if that is cache) then you get a performance win. By using the same server on each request.
Personally I still find that a lot easier to reason about. Especially when it’s time to resize the cluster.
jcartw•9mo ago