Jeff Templon said last week that Brunel were the only site he could find
who advertised that they didn't support outbound IP.
> -----Original Message-----
> From: Testbed Support for GridPP member institutes
> [mailto:[log in to unmask]] On Behalf Of Burke, S (Stephen)
> Sent: 10 April 2006 13:32
> To: [log in to unmask]
> Subject: Re: FW: Using external (non-SL cluster) with LCG
> grid SE/CE/MON?
>
> Testbed Support for GridPP member institutes
> > [mailto:[log in to unmask]] On Behalf Of John Walsh said:
> > I believe that each batch queue could be declared a
> > a subcluster, so
> > that the correct information is also published
> > (including OS etc).
> > [Stephen (Burke), is my assumption correct?]. This
> > may require a change
> > to the GIP configuration. I have not implemented a
> > subcluster solution
> > as the nodes are a similar SPEC to those published by
> > the site.
>
> The mapping is supposed to be (1 or more subclusters) -> (1
> cluster) ->
> (1 or more CEs). Unfortunately the broker can't cope with more than 1
> subcluster per cluster, so if you want to publish like that
> you have to
> duplicate the cluster as well and have a separate set of
> queues. You can
> however keep everything attached to a single CE head node.
> This has been
> done by Steve Traylen:
>
> http://goc.grid.sinica.edu.tw/gocwiki/How_to_publish_different
> _memory_li
> mits_for_different_queues_on_the_same_CE
>
> The main downside is that if you wanted to represent lots of different
> subcluster configurations you would end up with a huge explosion of
> queues (atlas_short_bigmem_fast-cpu_debian ...) There is
> supposed to be
> a working group looking at doing this more efficiently, but don't hold
> your breath :)
>
> > It might be possible to publish that this subcluster has no
> > outbound IP access (again Stephen, can you verify this?).
>
> You can publish it, but there's no guarantee that people will check it
> in their JDL as it's generally assumed to be there. Also
> various bits of
> the middleware assume outbound connectivity.
>
> Stephen
>
|