[GE users] Using cycles from a 2nd SGE cluster
Marcin.Goldyn at Sun.com
Fri Jan 8 14:42:17 GMT 2010
This is a really good feedback for us. Thank you.
Have you got a chance to try out SDM 1.0u5 already? If not, please do so
and give us your thoughts.
You are saying that users who tried "multiclustering" feature in their
organization were unhappy with the complexity and reduced productivity.
Did they try SDM with conjunction with SGE or some other software?
I also cannot agree with the statement that "Multiclustering" is only a
figment of upper management or HPC designers. As we can see even from
this discussion there are real live examples where multiclustering
can/should be used. If some obstacles exists, please give us a
feedback(like the one below), that will help us to address issues in the
You, as a consultant, cannot also always reply to your customers, asking
for the multiclustering feature, that the only solution is to merge the
W dniu 2010-01-08 14:39, craffi pisze:
> rhierlmeier wrote:
>> However for problems like different funding or fundamental different
>> configuration of the clusters I do not see any reason why multi clustering
>> should not work.
> Just being contrarian here so take my words with a grain of salt !
> Multi-clustering works from the perspective of sysadmins, HPC designers
> and senior management.
> Few of these people bother to ask users what they think either before or
> after considering multi-clustering.
> Few of these people will also measure their cluster from the perspective
> of "how easy is it for me to get my work done?" or "how how many hours
> does my expensive scientist have to spend making her jobs abstracted,
> wrapped and generic so they can be portable?
> HPC system operators and management are more concerned with uptime and
> utilization measurements rather than how effectively these systems can
> be used to achieve the organizational goals that created them.
> If you ask users what they think about multi-clustering you'd hear:
> - dealing with user account UID/GID mapping sucks
> - monitoring state and status sucks
> - dealing with different filesystem paths sucks
> - dealing with data movement issues among clusters sucks
> - spending days or hours making simple jobscripts portable sucks when
> that time could be better spent getting actual work done
> Unless an organization has static workflows that can be wrapped and
> abstracted by a dedicated app team or unless an organization has
> dedicated sysadmins with domain expertise available to help users with
> optimizing their workflows for cluster portability you will often find
> either unhappy users or users who have given up productivity in order to
> make their own workscripts abstracted and generic enough to be portable.
> For people who have not thought this out carefully you can have a net
> loss in productivity and efficiency.
> Again my views are tainted by the industry I work in and the
> organizations I visit. I'm speaking only for myself, not trying to
> describe the entire community or anything.
> To unsubscribe from this discussion, e-mail: [users-unsubscribe at gridengine.sunsource.net].
To unsubscribe from this discussion, e-mail: [users-unsubscribe at gridengine.sunsource.net].
More information about the gridengine-users