Does setting unique clustername (setClusterName("myCluster")) and instancename prevent joins?

[o haya]

Hi,

I was just doing some searching about the question I asked previously about setMembers() and TCP clustering, and I ran across this SO thread:

https://stackoverflow.com/questions/62713563/restrict-members-in-hazelcast-cluster

From that thread, it sounds like, if an application has the same cluster name, and regardless on which physical machine (for example on machine "SVC03") it is on, the Hazelcast on that machine might still join the cluster with that clustername, regardless of whether the IP/hostname of that machine is in the setMembers() (for example if the setMembers() only has "SVC01" and "SVC02")?

Is that correct?

In our case we do:

.setClusterName("dev")

where the cluster name corresponds to one of our specific environments ("dev" means our development environment, vs., say "int" for integration, etc.)

Per code I included in my earlier thread, we also do:

.setInstanceName("app")

where the instance name specifies the application, e.g., "app1", "app2", etc.

Now, as I understand it, one of the reasons I was asked to look into TCP discovery/clustering is that we have several servers whose purpose is specifically for hosting all of our (for example) Spring Boot services, and several of those services/apps also utilize Hazelcast, and also we want to use Hazelcast clustering with those other apps, AND we want the caches among the different apps to be separate.

The question that I have is:  Suppose that we have 2 of the SVC machines, and the clustername corresponds to the environment (so, for example,  ALL apps on the service machines in the environment would have clustername "dev" since they are all in the same development environment), and each service/app has a different instance name, will:

a) the cache instances (e.g., "app1", "app2", etc.) on each SVC machine be separate from each other?   and

b) if there is another machine, say "foreignSVC", that is not included in the setMembers() list on an app on either the SVC01 or SVC02 machine, and there is an instance of an app that is using Hazelcast TCP discovery/clustering on the "foreignSVC" machine, and the app on the "foreignSVC" machine has setMembers() that includes, say, SVC01 in the list, will the Hazelcast on the the "foreignSVC" machine be able to join the "dev" cluster?

Sorry, I know the question is kind of convoluted and I hope I got the terminology and wording ok :(...

Thanks in advance (again),

Jim

[Neil Stevenson]

 When a cluster wants to scale up, particularly on cloud infrastructure, the new machines will have IP addresses you cannot predict.

 So the IP address isn't normally used as a reason to reject membership. 

 A process trying to join the cluster is rejected for one of three reasons

 o- the cluster name differs

 o- it is an incompatible software version (for open source the minor version must match, 5.0.1 is compatible with 5.0.2, for commercial the major version must match, 5.0.* is compatible 5.1.*)  

 o- the security module rejects (this is in commercial).

With TCP config, the members listed is some of the places in the cluster where you are likely to get a response, and if the above conditions pass, be accepted for joining and be told where all the others are.

You can have two clusters with the same name, so long as the TCP config is two distinct sets, they won't find each other. I would add that such an approach will cause confusion at best,

and if some future accident means they do find each, they will join together into one. 

"dev-cluster1" and "dev-cluster2" would be a simpler solution.

Neil

[o haya]

Hi Neil,

Thanks for that info.  FYI, what we are doing (for now) is the construct the clustername using a combination of:

Jim