Hey Jeremy, With a redundant origin in each location, there would be a total of 6 HTTP_LIVE DSes. Then you'd create a steering DS with each of those 6 HTTP_LIVE DSes as targets. The type of each target would either be GEO_ORDER or GEO_WEIGHT, depending on if we want a forced ordering or something like a 50/50 split, respectively.
Say I have the following targets in my Steering DS: Seattle1 (S1): GEO_ORDER: 1 Seattle2 (S2): GEO_ORDER: 2 Denver1 (D1): GEO_WEIGHT: 50 Denver2 (D2): GEO_WEIGHT: 50 Boston1 (B1): GEO_ORDER: 1 Boston2 (B2): GEO_ORDER: 2 For a client in Seattle requesting /foo, they would get the list [S1, S2, D2, D1, B1, B2], where D1 and D2 are consistent hashed based upon the requested URL and given weight. So if they request /bar maybe D1 and D2 are switched so they get [S1, S2, D1, D2, B1, B2]. - Rawlin On Mon, Feb 26, 2018 at 8:18 PM, Jeremy Mitchell <mitchell...@gmail.com> wrote: > So, back to the Seattle, Denver, Boston example... > > To accomplish the geo ordering and redundant origin use case, you'd create > 3 HTTP_LIVE delivery services? One with an origin in seattle. One with an > origin in denver. One with an origin in boston. (or would you create 6 ds's > so you have 2 in each location?) > > Then you'd create a steering delivery service with 3 targets (the HTTP_LIVE > ds's you just created.) Each target would have type = GEO_ORDER and value = > ? > > I'm getting confused with that above scenario. How many targets would you > have? What would the type of each target be and what would the value of > each target be? > > Jeremy > > > On Fri, Feb 23, 2018 at 3:40 PM, Rawlin Peters <rawlin.pet...@gmail.com> > wrote: > >> Hey folks, >> >> At Comcast we have a need to augment CLIENT_STEERING (also regular >> STEERING while we're at it) to allow targets to be ordered/sorted >> based upon the client's proximity to the origin of the target delivery >> services. I'd like to get your feedback on my proposed design and >> address any of your concerns. >> >> For HTTP_LIVE targets for instance, we'd like edge caches to ideally >> retrieve/serve data from an Origin that is close to the client and >> fall back to Origins that are farther and farther away. This allows >> for increased redundancy while ordering optimal Origins (Delivery >> Services) for a client to choose from. >> >> For example, I have 3 Origins in different locations: Seattle, Denver, >> and Boston. I would create an HTTP_LIVE delivery service for each >> origin and a CLIENT_STEERING delivery service with those delivery >> services as targets. I would then like to have those targets ordered >> based upon proximity to the client. So a client in Seattle would get >> the list [Seattle, Denver, Boston], while a client in Boston would get >> the list [Boston, Denver, Seattle]. >> >> To make things more complicated, I want to add a redundant origin in >> each location and split traffic between them (like STEERING_WEIGHT >> today) while taking into account the geo-ordering. I also want to be >> able to force an ordering (like STEERING_ORDER today) among co-located >> targets. >> >> In order to accomplish this I propose to: >> 1. add two new steering types: GEO_ORDER and GEO_WEIGHT (by adding a >> target of type GEO_*, a steering DS would then enable geo-ordering) >> 2. associate a Delivery Service Origin with a latitude/longitude, >> thereby associating a lat/long to a GEO_* target >> >> Item 1 is pretty straightforward and will also play nicely with the >> current steering types (STEERING_ORDER and STEERING_WEIGHT). I've >> completed a POC within Traffic Router that basically provides the >> following ordering when mixing all 4 types in a single steering >> delivery service: >> - Negative STEERING_ORDER targets >> - GEO_WEIGHT and GEO_ORDER targets, grouped by proximity to the >> client, ordered by geo-order and the consistent-hashing from the >> weightings >> - STEERING_WEIGHT targets (consistent-hashed) >> - Positive STEERING_ORDER targets >> >> Item 2 is not as straightforward because the simple thing would be to >> just add an Origin Lat/Long field to the Delivery Service and call it >> a day. However I don't think we should do that, and I'll dive more >> into that in a separate thread (coming soon). >> >> Does anyone have questions/concerns about adding these new GEO_ORDER >> and GEO_STEERING target types and geo-sorting them based upon >> proximity to the client? Are you okay with the proposed ordering when >> all the steering types are mixed together? >> >> - Rawlin >>
