Re: [v6ops] State of play as of today

["Fred Baker (fred)" <[e-mail]>]

> On Oct 2, 2015, at 5:58 AM, Hemant Singh (shemant) <[e-mail]> wrote:
> 
> Does IPv4 in the data center support container/task migration and if so, how is it done today?

This isn't really an IPv4/IPv6 question as much as it is a process question. To my knowledge, there are two fundamental approaches.

One is suitable for transaction systems, like Jynga's games, web clusters, and client/server applications built on top of the web. In that model, consider that the server is a cluster of VM/Containers that one reaches by DNS name or something equivalent. In that model, one spins up a new server instance, adds its address to the DNS name in a DNS Resource Record (so it is now servicing transactions), deletes the old address's DNS Resource Record (so the only folks opening new transactions with it already had its address from a previous read of DNS), waits a while (the RR has to expire, and you then need to continue waiting until all active sessions acquiesce), and then kills the old system.

The other is more for applications that have to maintain memory across such a change. VMWare describes it at http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1000936. In that case, you're literally moving the VM/Container and its IP address; if you're not willing to stop its processing while you do so, it is changing its swap image while you're copying the image somewhere else. Net result - you copy the image, copy the parts that changed while you were doing that, and do so again, until you get something consistent at the new and the old locations. Then you kill the old and continue with the new.

The advantage of Tom's approach is that moving the "inside" address requires nothing in routing, only informing the systems that care where the instance is that the instance has changed. Depending on the nature of the application moved, you'll use something akin to one of those approaches.