Per-Entity Metadata Working Group

[Nick Roy <>]

On 9/14/16 1:56 PM, Nick Roy wrote:
> On 9/14/16 1:43 PM, Cantor, Scott wrote:
> > On 9/14/16, 3:16 PM, " on behalf of 
> > Nick Roy" < on behalf of 
> > > wrote:
> >
> > >     That is exactly why having at least one CDN, and preferably more 
> > > than
> > >     one, is relevant to a failover strategy.  Geographic and logical
> > >     redundancy.  Publishing to more than one CDN than one means you can
> > >     configure clients to fail over between more than one service.  
> > > Keeping
> > >     the naming separate and putting the failover between CDNs in the 
> > > client
> > >     lets clients specify parameters they are comfortable with for 
> > > things
> > >     like latency.
> > But server-side lets you mitigate the cost of timeouts so that every 
> > client doesn't have to wait an unpredictable amount of time before 
> > realizing something isn't working.
>
> That's true - does anyone have suggestions for a cloud GSLB which can 
> do arbitrary aliveness/quality-of-service checks on CDN-fronted data 
> and fail over between CDNs?  This GSLB service by definition needs to 
> have at least the number of nines that you as a group find acceptable 
> and will require of the service.

I'll also just leave this here for you to peruse/think about: 
https://loadbalancer.org/blog/gslb-why-do-global-server-load-balancers-suck

Nick

> > You really can't realistically have much more than maybe 2 sources 
> > before the timeouts start to get too long in sequence. Or you have to 
> > set really, really low timeouts and hope things keep up.
>
> Agreed
>
> > Using parallel retrieval to mitigate the overlap is, IMHO, a bit too 
> > much to expect.
>
> Yes
>
> Nick
>
> > -- Scott