Per-Entity Metadata Working Group

[Nicholas Roy <>]

On 9/6/16 5:37 PM, Patrick Radtke wrote:
> On Tue, Sep 6, 2016 at 4:24 PM, Tom Scavo 
> <>
>  wrote:
> > On Tue, Sep 6, 2016 at 7:19 PM, Cantor, Scott 
> > <>
> >  wrote:
> > > On 9/6/16 7:16 PM, Paul Caskey wrote:
> > > > To the extent that's true, then I would question the need for a CDN,
> > > > as opposed to a normal highly-available infrastructure (which would be
> > > > less expensive to operate).
> > > I think the point of the CDN was not performance but in fact
> > > availability. I thought the issue was that InCommon wasn't comfortable
> > > providing that HA infrastructure, at least enough that it was thought to
> > > be worth investigating what a CDN would offer and cost.
> > Well, our initial thought was to enable AWS Elastic Load Balancer for
> > automatic failover. It has not been tried, however, so I don't know if
> > it works as advertised.
> I believe a CDN will be cheaper than running a pair of EC2 instances
> and the ELB.
> Cloud front is a penny per 10K HTTPS connections and ~9 cents for 10TB
> of data transfer. There would probably be a dollar or two in S3
> charges for storing the signed metadata. Going with servers, an ELB
> and figuring out cross region HA will cost more than that.
>
> To me the real advantage to the CDN is resilience to targeted attacks
> against the MDQ servers. To me the largest downside is that failure
> modes are now location specific, which can make it hard to provide an
> accurate federation wide status of the service. If the cloudfront edge
> in Toronto is having issues, who would it affect? how would they be
> affected? would Ops be able to determine there was partial outage?,
> etc, etc.


Exactly.

Nick

> -Patrick