Skip to content

Commit

Permalink
reworded explaination
Browse files Browse the repository at this point in the history
  • Loading branch information
rkargMsft authored Jan 22, 2025
1 parent 5a3dd03 commit 0be5521
Showing 1 changed file with 5 additions and 3 deletions.
8 changes: 5 additions & 3 deletions docs/orleans/grains/grain-placement-filtering.md
Original file line number Diff line number Diff line change
Expand Up @@ -39,11 +39,13 @@ Silo Metadata is used to filter candidate silos to only ones that matches all of

#### `PreferredMatchSiloMetadata`

This filtering will attempt to select only silos that match all of the configured metadata keys with the values of the calling silo. However, instead of returning an empty set if there are not matches as the above Required filtering this will then fall back to partial matches. The first configured metadata key is dropped and a match is made against the remaining keys. This will continue, dropping the initial keys, until a sufficient number of matches are made. If there are not any compatible silos that match *any* of the metadata keys, then all of the candidate silos are returned.

This filtering will attempt to be filtered to only silos that match all of the configured metadata keys with the calling silo. However, instead of returning an empty set if there are not matches as the above Required filtering this will then fall back to partial matches. The first configured metadata key is dropped and a match is made against the remaining keys. This will continue, dropping the initial keys, until a sufficient number of matches are made. If there are not any compatible silos that match *any* of the metadata keys, then all of the candidate silos are returned.
The `minCandidates` value configures how many candidates must be found to stop the filtering process. This value is used to prevent a single silo or small number of silos from getting quickly overloaded if the match were that small.

The `minCandidates` value configures how many candidates must be found to stop the filtering process. This value is used to prevent a single silo from getting quickly overloaded if it would be the only match.
For example, if filtering on `[PreferredMatchSiloMetadata(["cloud.availability-zone", "cloud.region"], minCandidates:2)]` and there is only one matching silo on both `cloud.availability-zone` and `cloud.region`, then all activations would get placed on that one silo. It is often desirable to not focus activation (or do scheduling in general) on one target. With the above `minCandidates` value of 2, this scenario would fail to match on both keys because only one silo matches both metadata keys. Then it would then fall back to matching only on `cloud.region`. If there were 2 or more silos that match only that key then those would get returned. Otherwise, it would fall back to returning all of the candidates. Note that this config is a minimum value; more candidates could be returned. If you would prefer a most specific matching only then setting this to 1 would only return the best match (the one silo in the above scenario). This could be preferable in specific use cases where there is low activation throughput and where there is a great penalty when moving to a less specific match from a more specific one. In general use, the default value of 2 should be used (and not need to be specified in the attribute).
If `minCandidates` were not considered, then there could be a scenario where there are a large number of silos but only one silo that best matches the configured metadata keys. All placements would be concentrated on that one silo despite having many more available that could host activations. The purpose of `minCandidates` is to allow for a balance between preferring only best matches and avoiding hot silos. It is often desirable to not focus activation (or do scheduling in general) on one target. Set it to a value larger than 1 to ensure a minimum candidate set size so that future placement decisions are able to avoid concentrating activations on one or a few hot silos. Note that this config is a minimum value; more candidates could be returned. If you would prefer most specific matching only then set `minCandidates: 1` to always prefer best match. This might be preferable in specific use cases where there is low activation throughput and where there is a great penalty when moving to a less specific match from a more specific one. In general use, the default value of 2 should be used (and not need to be specified in the attribute).

For example, if filtering on `[PreferredMatchSiloMetadata(["cloud.availability-zone", "cloud.region"], minCandidates:2)]` and there is only one matching silo on both `cloud.availability-zone` and `cloud.region`, then this scenario with `minCandidates: 2` would fail to match on both keys because only one silo matches both metadata keys and that's below the minimum configured size of 2. It would then then fall back to matching only on `cloud.region`. If there were 2 or more silos that match only `cloud.region` then those would get returned. Otherwise, it would fall back to returning all of the candidates.

## Implement placement filters

Expand Down

0 comments on commit 0be5521

Please sign in to comment.