« Return to Thread: clearinghouses (or not)
Re: clearinghouses (or not)
by Larry Peterson
::
Rate this Message:
I accept your distinction between controls and allocates, but
I disagree with how you apply them. Ultimately, the aggregates
make allocation decisions, not the the SM. It makes no difference
whether the client talks directly to an aggregate (initially to request
resources and later to control the resources it was allocated) or
funnels those allocation-requests/control-requests through an
intermediate SM (which is really serving an aggregation function...
to overload that term).
Larry
On Thu, Apr 16, 2009 at 1:46 PM, David Irwin <irwin@...> wrote:
>> Anyone care to comment on the general issue of these competing
>> strategies:
>>
>> User manages multiple Aggregates (SM functionality runs on client
>> and user requests go directly to the aggregates)
>>
>> versus
>>
>> Clearinghouse manages multiple Aggregates (SM functionality runs
>> on server with all user requested funneled through the SM)
>
> Orca doesn't really view these strategies as necessarily competing,
> since it effectively separates "management" into two functions:
> allocation and control. So using your words:
>
> User **controls** (resources from) multiple Aggregates (SM
> functionality runs on the client and user **control** requests go
> directly to the aggregates)
>
> Clearinghouse **allocates** (resources from) multiple Aggregates (SM
> functionality runs on the server with all user **allocation** requests
> funneled through the SM)
>
> So the SM functionality that does control resides with the user, while
> the SM functionality that does allocation resides with the
> Clearinghouse.
>
> That said, we often compose users, clearinghouses, and AMs together to
> produce similar divisions of function as you propose for your SM. To
> do the first approach, we have each aggregate manager run its own
> personal clearinghouse, so it incorporates all the Clearinghouse
> authorization functions (this is how we often run Orca in practice).
> To do the second approach, a single Clearinghouse allocates resources
> from multiple AMs (this is our approach in Cluster D) that the user
> then controls. In both cases, we assume some persistent server runs
> under the auspices of the user (whether on the desktop or a remote
> server), so it can receive asynchronous callbacks/notifications from
> the Clearinghouse and/or AM about its resources.
>
> So from an architectural standpoint, I view this as maybe a false
> choice between two extremes in a spectrum of possibilities. However,
> from an implementation standpoint, I agree with Rob, in that your
> first choice is probably best. Despite our focus on Clearinghouses
> managing multiple AMs, this was a first step in our development and
> remains in practice a useful way to organize our system (especially
> when coordinated allocation of resources across aggregates is not
> necessary).
>
> -David
>
_______________________________________________
control-wg mailing list
control-wg@...
http://lists.geni.net/mailman/listinfo/control-wg
I disagree with how you apply them. Ultimately, the aggregates
make allocation decisions, not the the SM. It makes no difference
whether the client talks directly to an aggregate (initially to request
resources and later to control the resources it was allocated) or
funnels those allocation-requests/control-requests through an
intermediate SM (which is really serving an aggregation function...
to overload that term).
Larry
On Thu, Apr 16, 2009 at 1:46 PM, David Irwin <irwin@...> wrote:
>> Anyone care to comment on the general issue of these competing
>> strategies:
>>
>> User manages multiple Aggregates (SM functionality runs on client
>> and user requests go directly to the aggregates)
>>
>> versus
>>
>> Clearinghouse manages multiple Aggregates (SM functionality runs
>> on server with all user requested funneled through the SM)
>
> Orca doesn't really view these strategies as necessarily competing,
> since it effectively separates "management" into two functions:
> allocation and control. So using your words:
>
> User **controls** (resources from) multiple Aggregates (SM
> functionality runs on the client and user **control** requests go
> directly to the aggregates)
>
> Clearinghouse **allocates** (resources from) multiple Aggregates (SM
> functionality runs on the server with all user **allocation** requests
> funneled through the SM)
>
> So the SM functionality that does control resides with the user, while
> the SM functionality that does allocation resides with the
> Clearinghouse.
>
> That said, we often compose users, clearinghouses, and AMs together to
> produce similar divisions of function as you propose for your SM. To
> do the first approach, we have each aggregate manager run its own
> personal clearinghouse, so it incorporates all the Clearinghouse
> authorization functions (this is how we often run Orca in practice).
> To do the second approach, a single Clearinghouse allocates resources
> from multiple AMs (this is our approach in Cluster D) that the user
> then controls. In both cases, we assume some persistent server runs
> under the auspices of the user (whether on the desktop or a remote
> server), so it can receive asynchronous callbacks/notifications from
> the Clearinghouse and/or AM about its resources.
>
> So from an architectural standpoint, I view this as maybe a false
> choice between two extremes in a spectrum of possibilities. However,
> from an implementation standpoint, I agree with Rob, in that your
> first choice is probably best. Despite our focus on Clearinghouses
> managing multiple AMs, this was a first step in our development and
> remains in practice a useful way to organize our system (especially
> when coordinated allocation of resources across aggregates is not
> necessary).
>
> -David
>
_______________________________________________
control-wg mailing list
control-wg@...
http://lists.geni.net/mailman/listinfo/control-wg
« Return to Thread: clearinghouses (or not)
| Free embeddable forum powered by Nabble | Forum Help |
