Hey Sanjay. Thank you for your answer. Answers inline below.
On Sun, Apr 2, 2023 at 9:10 AM '[email protected]' via grpc.io < [email protected]> wrote: > - you said "map shards to running containers (network endpoints)" : is > there a single container (endpoint) for a shard or can you have more than > one endpoint and a load balancer picks any one of those endpoints (based on > some LB policy)? > There are 3 typical setups: 1. primary only: each shard has a single replicas 2. secondary only: each shard has multiple replicas 3. primary/secondary: one replica is responsible for writes, and there are multiple replicas available for reads. While 1. is a popular option and a good first iteration, the design should definitely account for the possibility of having multiple replicas and using another load balancing policies to route to them. - if there is a single endpoint for a shard then the shard identifier > basically is immaterial to the gRPC routing component: we combine the 2 > mapping steps and you in effect map the keys in the incoming request to an > endpoint: unless I am missing something > Yes, that would be true iff there was a 1<->1 mapping between shards and endpoints. That being said, we plan to have the service discovery component be aware of the shard <-> endpoint mapping rather than the application, to simplify integration with Envoy, and reuse gRPC built-in load balancing when multiple replicas are present, if possible. Ideally the mapping from shard -> host is not known from the client application, and only from gRPC (an alternative would be to pick the host directly in the filter/interceptor, but that would require it to implement load balancing, which is not ideal). > - the "information contained in the incoming request" i.e. the list of > keys are part of the request metadata and not the request payload, is that > correct? > Yes, we can make this assumption. > There is something called stateful session affinity that is described in A55: > xDS-Based Stateful Session Affinity for Proxyless gRPC > <https://github.com/grpc/proposal/blob/master/A55-xds-stateful-session-affinity.md> > and there is a follow-on proposal called "A60: new gRFC for weighted > clusters support for Stateful Session Affinity" in a PR > <https://github.com/grpc/proposal/pull/348>. And the solution I thought > for your problem is structurally similar to what is proposed in A60. > As you mentioned for your Envoy solution, basically you will have a > "custom" filter that will map a request to a shard and/or an endpoint > (since the shard to cluster mapping is not clear let's say the filter will > specify both a cluster and an endpoint within the cluster). Using the > technique described in A60 the cluster selection made by the config > selector will be overridden by the ClusterSelectionFilter and the endpoint > selection will be done by the xds_override_host policy based on the pick > attribute set by your custom filter. > Thanks for pointing out A55 and A60. This is very interesting in that it shows how filters can interact with the load balancer to pick a particular host. I think if we were to implement metadata subsets, we would need to do something very similar. > So the questions left to be answered are how the custom filter will be > injected for the gRPC client and whether you agree that there is a > structural similarity between the 2 use-cases. The custom filter in your > case uses keys in the incoming request (instead of a cookie) to figure out > the cluster and the endpoint - and also possibly interacts with an external > component to get the keys->shard and shard->endpoint mappings. Based on > answers to these questions we can discuss further. > In the first iteration of this work, we'll ask clients to add a custom interceptor that adds the necessary shard identifier to the request context. It would be ideal if that could be done directly via built-in interceptors and configured via an xDS extension, but I'd rather concentrate on the shard -> endpoint mapping for now. Antoine. -- You received this message because you are subscribed to the Google Groups "grpc.io" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/CADrS3j%2BVqncPik54Mk%2BKjZN40MZUEDeyjOj2pv4dYST-%2BjNFGA%40mail.gmail.com.
