Hi fredprinsloo,
[QUOTE=fredprinsloo;25650]Hi all,
I have an IBM Blade Server (HS21) which consists of 13 blades. Now, I am wondering how (is it even possible?) can one amalgamate all the processing power of those blades into one interface?
For instance, is it possible to interface on blade one and use that as the primary blade on which operations are executed, and then the rest of the blades’ resources are utilized for processing tasks inside blade 1?
Is there a certain config or software that can allow for this? Is there some sort of SUSE config, does it support this capability?[/QUOTE]
what you’re looking for is some cross-machine clustering at a task level. IOW, the OS usually won’t support this directly.
There are a number of different approaches you might look into, and all cater special needs and only apply under certain conditions. Even so, your “payload” (the job(s) you want to run) bacially need to support both this execution model and the used framework.
One example, commonly used, not too complicated: You need to load-balance web servers. So you put a “load-balancer” up front, i.e. on “blade one” (and maybe on blade two, for redundancy) and run web servers on all blades. The balancer takes care of distributing the requests across the servers / blades.
Spreading process instances across the blades (if this mode is supported by the processes in the first place, like with the web server cluster in the previous example) can be done via Pacemaker from the SLE HAE extension.
A completely different example: If you need to do stream processing and would like to spread the load across your nodes, you might want to look into “Apache Storm” where you can program your “topology” (with all the individual filters (AKA bolts) and have the framework spread those (single- and multi-instance) bolts across all participating nodes.
All this can be done with SLES11 (which I assume is what you meant - “SUSE 11” would traditionally point to “openSUSE” but would be missing the minor number, making it an ambigious term).
Regards,
Jens