Hi, all
As everyone known, the host id is the essential of sanlock. It identifies all the servers with different offset in the shared disk.
Could the host id be self-organization by the servers themselves ? In this condition, the manager node that generated the unique host id would be useless.
My thought lists here:
1. Get the system uuid with dmidecode.
2. System uuid maps into a uint32 integer.
3. Calculate the host id with the hash function with the uint32 integer. Hash function f(x) = value % MAX_HOST_ID
a) Once the conflict occurs, choose its neighbor id.
b) The detection of conflict can use the bitmap in the delta lease.
Is this idea feasibility?
Thank you.
Qi
On Sat, Jun 29, 2013 at 03:46:08AM +0000, Qixiaozhen wrote:
Hi, all
As everyone known, the host id is the essential of sanlock. It identifies all the servers with different offset in the shared disk.
Could the host id be self-organization by the servers themselves ? In this condition, the manager node that generated the unique host id would be useless.
My thought lists here:
Get the system uuid with dmidecode.
System uuid maps into a uint32 integer.
Calculate the host id with the hash function with the uint32 integer. Hash function f(x) = value % MAX_HOST_ID
a) Once the conflict occurs, choose its neighbor id.
b) The detection of conflict can use the bitmap in the delta lease.
Is this idea feasibility?
If two hosts try to acquire a delta lease on the same host id, then the delta lease algorithm is meant to detect the conflict, and give the host id delta lease to only one of the hosts. So, the conflict detection already exists. You should still try to avoid host id conflicts as much as possible, though, and your method of hashing the system uuid sounds like it might be a reasonable way of doing that. (Once a host gets a host id that works, it should remember it and reuse the same id next time.)
Dave
sanlock-devel@lists.fedorahosted.org