add documentation on heterogeneous clusters (WIP) #448
Conversation
|
@migueldiascosta It's probably better to set up a specific page for sites to explain how they configure/use EasyBuild (see also #264, but someone will need to update & chase down people on that) |
docs/Heterogeneous_clusters.rst
Outdated
| each host only sees the software compiled for its own architecture (plus any software eventually compiled for ``GENERIC``) | ||
| or if it sees everything. | ||
|
|
||
| By mounting architecture dependent targets on the same mountpoint in every host, the configuration is then very similar to |
There was a problem hiding this comment.
Would it only be changing the mointpoint? We thought about directories like /common-path/easybuild// where architecture is the instruction set name of gcc (nehalem, broadwell, skylake,...) to start with. On the nodes one would change the profile.d to prepend $MODULEPATH with the according modules path, hence module load would pick up the more optimized modules first and fall back to the other architectures, i.e. instruction sets for other modules. For example, MODULEPATH=/<....>/skylake/modules/all:/<....>/nehalem/modules/all.
There was a problem hiding this comment.
@henkela this clearly needs to be rewritten, my goal was precisely to describe those two approaches (a node only seeing it's own arch, via mountpoints, or seeing everything but using only it's own arch, via variables).
Using variables is of course much more flexible, but in many simple cases using mountpoints may be more robust and foolproof (from the point of view of the nodes, and except for the custom mountpoint, it's the same as an homogeneous cluster)
|
Documentation for heterogeneous clusters is also a matter of site policy. I think this page can only offer a certain way or maybe some ways to tackle this point. Building multiple software trees according to the different architectures in the cluster is common to several approaches. Another question that arises is how to build for those different architectures? Manually sending build jobs? Using ansible? Including even ReFrame maybe? Should there be a eb --multiple-arch where one could overwritte optflags,installdir,modulesdir,easyconfig-repo on the fly and trigger multiple build-jobs at once? Probably GC3Pie would get involved here, too? |
besides reviewing this text, can people submit PRs to my branch with site-specific examples?
Or maybe we should set up a separate page for those?