>>>>> "Joe" == Joe Landman <land...@scalableinformatics.com> writes:
Joe> On 11/29/2013 06:16 AM, Olli-Pekka Lehto wrote: [...]
Olli-Pekka> Thus it might not be a question of choosing to adopt it
Olli-Pekka> and sell it to the users but rather having to respond to
Olli-Pekka> user demand for it. This means understanding and dealing
Olli-Pekka> with the constraints involved with especially
Olli-Pekka> InfiniBand-based HPC clusters which you outlined pretty
Olli-Pekka> well in your mail.
Joe> My thoughts are, that while its not necessarily the first to
Joe> market with the concept, the Docker.io folks have benefited
Joe> from a technological convergence of sorts, where they were able
Joe> to assemble, from pre-existing parts (that work relatively well
Joe> on their own), the solution. Moreover, there are real problems
Joe> that this can be applied to, with the specifics of repeatable
Joe> environments for computational studies ...
I agree with this. It's a nice wrap-up of existing concepts/modules.
I think the advantages are obvious. There are at least two points I'm a
little bit worried/skeptical about though at this time:
a) Security issues:
Probably most of these containers will never get properly updated
with security fixes and hence will present a nest of security holes.
As long as they are just used as short-lived, transient environments,
the danger is probably strongly reduced, but I'm sure many of them
will also be alive for an extended period of time. In any case one
has to make damn sure to properly secure the host serving the
containers (see
http://blog.docker.io/2013/08/containers-docker-how-secure-are-they/
). Since I'm pretty much sure that quite a few guys out there will
mess this up though, there is a big potential for attack. I would
call this the "androidization of servers": The containers playing the
role of Android Apps (and everyone knows there is no way to make sure
that the whole bunch of them out there can be made or be considered
secure).
b) MPI communication (via Infiniband or other non-standard interfaces)
between different containers:
The communication will only work if the libraries in the container will
function well (or at all) with the kernel drivers on the host. It's
pretty clear that an OpenMPI built against an 1.1 OFED in a container
will not work together with a OFED 3.12 stack e.g. So in many cases
you'd probably be limited to use shared memory (or ethernet) as a
communication path for old code and hence large scale calculations will
probably be ruled out.
Nevertheless, we will include Docker as an optional image module in
our next major Qlustar [1] release. Then people can start playing with
the stuff and we'll see how well it'll get adopted in the HPC world.
--
Roland Fehrenbacher, PhD
Founder/CEO Q-Leap Networks
www.q-leap.com
+49 7034 652270
[1] http://qlustar.com
_______________________________________________
Beowulf mailing list, Beowulf@beowulf.org sponsored by Penguin Computing
To change your subscription (digest mode or unsubscribe) visit
http://www.beowulf.org/mailman/listinfo/beowulf
