On Tue, Nov 24, 2009 at 1:26 PM, ron minnich <[email protected]> wrote:
>
> On Tue, Nov 24, 2009 at 11:22 AM, Eric Van Hensbergen <[email protected]>
> wrote:
>>
>> but xcpu2 solves this problem - it can run any manner of scripts quite
>> handily.
>
> xcpu2 is the way forward. The remaining issues are getting it to be
> more familiar to sysadmins on setup, performance, and so on. But it's
> all doable.
>
I think it would be useful to have some well defined requirements
here. What about it do sysadmins find difficult to configure?
My experience is there are two things that one needs to know how to do:
a) setup authentication
b) manage the machine list
ssh gets around (a) by using LDAP or some other local auth. xcpu2
could do something similar, but there are some folks that use xcpu2
locally specifically because they don't have to get involved with an
outside userid/authentication mechanism
ssh doesn't get around (b) either, but it does seem like it would be
nice to have some easier mechanism for maintaining this sort of
information. Something like zeroconf could help on a local network,
but many of the networks we deploy xcpu2 on are segmented.
I guess (b) can be got around by using another workload management
system on top of xcpu/ssh which handles the management/monitoring of
physical resources.
Something like a distributed registry with distributed auth could help
solve some of these problems, but you'll likely need to configure at
least one node per network segment with the right information (auth
server and registry server) and then everyone else could pick it up
with zero conf. Alternatively, you could point all nodes to a
hierarchical parent which would eventually fully connect a
hierarchical tree of nodes in a manner which the
auth/registry/monitoring information could be distributed.
-eric
