Joshua,
So Q3 2016? :)
In furtherance of your point but kind of ignoring the 'shadow' pid
problem, it seems to me if a process were constrained to resources that
aren't exclusive to the local domain, either via NFS (and the ilk)
and/or by avoiding UNIX domain and loopback sockets shows some issues as
resolvable and that some processes wouldn't be realistically
migrate-able,/i.e. [//African swallows] are//non/-/migratory/.
That said I am not really sure I have pondered the difference between
process migration and 'migration and a checkpoint/restart style facility'.
I wasn't the one who broached the HA question, instead my thoughts have
been around a Manta-like service where the process follows the resources
it needs as though Manta were some kind of giant 'exo-computer' deciding
whether it is faster to move the process to the data or the data to the
process; akin to cache-affinity for processes whom seek to run where
they are most likely to have warm cache. *
All, this being done, of course, while piping together processes across
machine boundaries.
(Why not buffer an a system that is idle?)
I am sure you have heard all these ponderings in one form or another, it
certainly has that /El Derado/ (or _Holy Grail_) feel to it.
So Q4 2016?
Merry Yule,
Will
P.S.
* Yes, this is all likely better solved as task and with messages passed
on some interface. (MPI anyone?)
On 12/28/15 5:22 PM, Joshua M. Clulow wrote:
On 28 December 2015 at 14:47, Will Beazley <[email protected]> wrote:
I imagine if you want to do it SmartOS would be an OS to do it. I guess it
may require a mapping scheme so heterogeneous processes could be migrated.
It's much more likely that you would be able to migrate an entire
_zone_ than just one process.
One of the many issues with migrating a UNIX process from one machine
to another is the set of essentially opaque, integer-typed identifiers
that refer to resources outside the memory space of the process. The
classical example is the process ID (pid), though this applies to
other things as well.
In order to be able to migrate a zone from one machine to another, you
would need to preserve the pid of each mutually visible process within
that zone. Processes become aware of each other through their pids,
and these relationships must be preserved. Currently the pid
namespace is global to the entire machine; you would need to create a
per-zone unique namespace to prevent a newly migrated zone from
stepping on the pids of another zone already on the migration target.
The system would still require a globally unique pid underneath, so
you'd probably end up having a "shadow" pid within the zone; this will
complicate the implementation of ps(1), DTrace, every ptool, etc. It
will also complicate the operator's view of the system (from the
global zone).
There are many other extra-process resources that you would need to
serialise and deserialise as well: a file descriptor really connects
you with a particular vnode within a filesystem, so you'd need to be
able to reconstitute that (even if unlinked) after presumably also
sending the ZFS dataset to the remote peer. You would also need to
move the VNIC (MAC & IP) as well as all open connection state, with
the contents of the send and receive buffers, etc. You would need to
unhook any inter-zone socket connections that have been fused together
for performance reasons.
Even though the zone (instead of the process) could potentially make
for a crisper boundary along which to detach a set of processes (and
associated resources) and move them to another machine, it is almost
certainly not worth the trouble. Such an architectural shift would
forever complicate the implementation of every other operating system
feature implemented afterwards. Each new feature would need to be
built with a view to being paused, serialised, deserialised and
resumed; there is little practical difference between this kind of
migration and a checkpoint/restart style facility.
It is cleaner, simpler, and more robust to do HA (whatever that means
for you) in your application. There, you can make different and
nuanced decisions about consistency and availability for individual
abstract pieces of your application, even down to the level of
particular tables in a database, rather than trying to create a UNIX
host that magically spans the data centre.
-------------------------------------------
smartos-discuss
Archives: https://www.listbox.com/member/archive/184463/=now
RSS Feed: https://www.listbox.com/member/archive/rss/184463/25769125-55cfbc00
Modify Your Subscription:
https://www.listbox.com/member/?member_id=25769125&id_secret=25769125-7688e9fb
Powered by Listbox: http://www.listbox.com
