Orleans: What does the ClusterOption.ServiceId actually do?

[sheng-jie]

I have one cluster with two silo services (A and B). I build a client with options.ServiceId= "A". With this client, I find I can get the grain in the Service B to invoke the services B's method.
So is that the right behavior? If that, what does serviceid option actually do?
I read the doc and source code but I still cannot get through.
Anyone can help to give an clear explanation? Thanks very much.

Orleans clustering information
[...]
// Clustering information
.Configure(options =>
{
options.ClusterId = "my-first-cluster";
options.ServiceId = "AspNetSampleApp";
})
[...]
Here we do two things:
Set the ClusterId to "my-first-cluster": this is a unique ID for the Orleans cluster. All clients and silos that use this ID will be able to talk directly to each other. You can choose to use a different ClusterId for different deployments, though.
Set the ServiceId to "AspNetSampleApp": this is a unique ID for your application that will be used by some providers, such as persistence providers. This ID should remain stable and not change across deployments.

PS: English is not my native language; please excuse typing errors.

[ReubenBond]

Orleans supports both a blue/green deployment model as well as a rolling deployment model.

The blue/green deployment model is sometimes called "VIP swaps". It is how upgrades work on Azure Cloud Services and many other platforms.

The rolling deployment model is becoming more common. That model is common when running on Kubernetes or Service Fabric.

Orleans has both ClusterId & ServiceId to support the blue/green deployment model.

In this model, each deployment slot will have a distinct ClusterId (eg, the values could be "blue-slot" & "green-slot") but they will always have the same ServiceId (eg, "my-service"). The "blue-slot" silos will only talk to other "blue-slot" silos.

However Grain A in the blue cluster and Grain A in the green cluster will still share the same storage - if they are both active then one will see a conflict when writing to the state if the other activation has already written it.

This allows for the state in the database to remain consistent when multiple clusters are active (which is usually a short period of time - during the upgrade).

If you do not use blue/green deployments then you can set ClusterId & ServiceId to the same value.

To say this in a different way:

• ClusterId + ServiceId are used for cluster membership
• ServiceId is used for storage

I hope that is clear, but please ask if there is something which is still not clear.

PS: English is not my native language; please excuse typing errors.

Your English is good :)

[sheng-jie]

Thanks for reply so soon. Now I got it.
The officials doc doesn't have a clear description about the parameters of ClusterOption. So it will be good to have an update.

Thanks again.

[ReubenBond]

Keeping open: clarify documentation using above comment.

Thank you, @sheng-jie.

[veikkoeeva]

@ReubenBond Where would you suggest adding this piece of information? Would https://dotnet.github.io/orleans/Documentation/clusters_and_clients/configuration_guide/client_configuration.html be an appropriate place?

[ReubenBond]

@veikkoeeva it seems like either we should either combine the pages into one or add a new page and link it from client/silo config pages.

We could have a "Clustering configuration" page, perhaps

[veikkoeeva]

@ReubenBond Ah, do you mean that combine the aforementioned client configuration page with https://dotnet.github.io/orleans/Documentation/clusters_and_clients/configuration_guide/server_configuration.html ? Now that I think of this, it would make sense to have these combined since now there isn't one place that explains "there are siloes and there are clients connecting to siloes" and then telling how do the actually connect. Mostly people probably think this, but it would reduce cognitive load to have it spelled out explicitly.

Moreover, it would one to naturally expand discussion on how clients keep connected to siloes and learn failures, new siloes and all that. I mean now to do that one probably needs to go to the source to read, but maybe having this combined would incline someone to expand the documentation later.

[misha-fm]

Hi, guys. @ReubenBond thanks for the explanation, but I still don't fully get the idea.

The main question is as follows. You write "ServiceId is used for storage". What I currently observe in my configuration: silo's ServiceId is set to "ServiceA", silo-client's ServiceId is set to "ServiceB". But I still can retrieve the data (which is stored in AdoNet database and has ServiceId field equal to "ServiceA") from silo.

Some time ago (in older versions, can't say exactly which one) that scenario was not possible: I couldn't retrieve data from DB storage, when client's and silo's ServiceId values were different. Did anything change in the behavior?

update:

After I've tried to recall the older behavior, I realized that the setup was the following: DB already had data with ServiceId = ServiceA, but silo instance had ServiceId = ServiceB. Therefore silo couldn't retrieve data from the database. That makes sense.

But the first question still remains: does client's ServiceId play any role in interacting with silo? In my opinion, it does not. Correct me, if I'm wrong.