VOResource 1.1: Mirrors?

[Markus Demleitner]

Hi,

On Wed, Jun 01, 2016 at 06:07:17PM +0200, Thomas Boch wrote:
> The use cases I had in mind are the following:
> - in case the main VizieR service is down, how can a sophisticated client
> find an alternative access URL to query the service?
> VizieR services are mirrored in 7 places around the world, but this
> knowledge is not inside the registry. Hence, if the main site breaks, VizieR
> is totally unreachable from a VO point of view, which is too bad as working
> mirrors are there.
> - find the nearest (in term of network latency) mirror for a given service.
>  [...]
> >(a) I guess most commercial services use some sort of GeoIP, i.e., the
> >DNS responses depend on the geographic location.  So, for instance
> >here in Baden-Württemberg www.google.de (at the moment) resolves to
> >2a00:1450:4013:c01::5e, wheres in Saxonia it is
> >2a00:1450:4001:817::2003.  I've never set something like that up
> >before, but I'd be surprised if it was hard.
> 
> GeoDNS would be I think the ideal solution to this problem. It is a general
> solution to a problem that goes well beyond the IVOA registry.
> But that requires some technical know-how and to have the full mastery of
> your DNS records, which might not be trivial.

If you feel it is the ideal solution (and I believe, too, that it's
probably what works best in an average over all the users, even
though failover requires some sort of intervention), perhaps one
could explore it a bit further before committing to change
VOResource?

Does anyone here have experience with it?

> >(b) have a separate element, perhaps like this:
> >
> >   <capability standardID="ivo://example/whatever">
> >     <interface std="True">
> >       <accessURL use="base">http://example.eu/svc/stars?</accessURL>
> >       <mirrorURL>http://example.za/svc/stars?</mirrorURL>
> >       <mirrorURL>http://example.cn/svc/stars?</mirrorURL>
> >     </interface>
> >     <param ...
> >   </capability>
> >
> >I guess something like that would be my winner if we decided to go
> >ahead with VOResource mirrors.
> 
> 
> This option has my preference too, as it introduces a new element and
> minimizes the risk of a basic client using by mistake the mirror accessURL
> (though you might argue it also introduces a schema change).

Yeah, but we're touching the schema anyway, and since it's by
necessity an optional element it doesn't hurt as such.  It'll be
another table in RegTAP, so I'd be happier overall if we didn't need
it, but it's certainly manageable.

> >Is there any metadata that should go ahead with mirrorURL if we went
> >this way?  Perhaps something to help make a choice between the
> >mirrors without having to ping them all?
> 
> Well, pinging all the mirror alternatives with a basic query (SR=0 for cone
> search) might not be that bad.

You can do this because you basically have one machine to deal with.
When a registry query yields 20 different services, the picture
changes.

In GLU, is the only mirror metadata you have the base URL?

Cheers,

        Markus