Another way to do this would be with features.
Then mpi jobs must specify the feature=OSstring to run, and others can
run without the feature.
I'd use partitions to differentiate HW, not OS, but that's just my
personal bias.
The only issue you'd have is building the slurm rpms 3 times each time
you wish to update a version, as a consistent slurm version across the
cluster is "better form". I believe the only constraint is slurmctld
must be higher or equal version to slurmd and slurmdbd must be equal or
higher to slurmctld (slurmdbd≥slurmctld≥slurmd) but best not to test
once in production and upgrade all at once.
On 01/04/2016 11:31 PM, Michael Robbert wrote:
Shadd,
This should be doable with some work. If I were doing this the first thing I’d
do do is reconcile all the differences in the slurm.conf of each cluster. Once
all the clusters are running with the same settings, or you’ve decided on which
cluster’s settings you want to use for the new combined cluster then just
append the nodes and partitions from the other clusters into the one slurm.conf
to rule them all. Push that file out to all the nodes and restart.
As far as multi-OS within a single cluster goes I don’t think that Slurm really
cares what OS is running. How you set it up is probably more a matter of what
kind of applications you’re running. In a typical HPC cluster running MPI jobs
you’re probably going to want to create a separate Slurm partition for each OS.
Each job will then be confined to one partition. If you want jobs to be able to
run on and communicate between nodes with different OS’s that could be
possible, but I’d think that it’ll be a bigger headache than it is worth.
Mike Robbert
Colorado School of Mines
On Dec 30, 2015, at 6:26 AM, Shadd Gallegos <[email protected]> wrote:
I have Multiple clusters
one Sles 11 SP3
one CentOS 6.7
one CentOS 7.0
Each running their own SLURM instance
Is there a way I can consolidate the three to a single scheduler system?
is there any doc on multi OS systems anywhere?
Shadd
