How Did the Quake Demo from DockerCon Work?(blog.kubernetes.io)
blog.kubernetes.io
How Did the Quake Demo from DockerCon Work?
http://blog.kubernetes.io/2015/07/how-did-quake-demo-from-dockercon-work.html
7 comments
Doesn't this go against the 'cattle not pets' philosophy? Even though they're just moving RAM, it gives you the impression of permanence of a given state.
I don't think so. The sever instances are definitely cattle. The current state, which is mutable and volatile, is persisted because it needs to be and that's the service provided. The server instances are identical and destructible... This cattle. The illusion of permanence may exist but if the migration fails, the persisted state dies and the user gets reset.
https://youtu.be/mL9AFkJJAq0?t=27m30s if you want to see the actual demo...
That is impressive.
They are running docket instances in all the data centers at the same time. each time he migrates the running instance, he pauses the instance, saves the contents of the instances ram and file descriptors (checkpoint), moves or copies that checkpoint to another data center, changes iptables to redirect any clients to the new instance through the load balancer and starts the instance in the new location. all scripted of course. Pure devops. This is basically how a love migration works on all hypervisors but it is really cool to see it in docker.
When he changes the server from Singapore to Amerstand, how does the connection change to send packets to the new location? Can the server keep the same IP, and the internet protocol automatically finds a new shortest path to the server?
He mentions towards the end that there's a load-balancer that pauses the connection while the migration occurs. When the container comes back up, the traffic is redirected to the new instance and the connection resumes.
I wonder if this demo is only possible because the game uses UDP.
TCP should work too, on sufficiently recent kernels. The CRIU developers added kernel support for saving and restoring the internal state of an open connection, including things like sequence numbers and window sizes. It looks like you have to be careful to drop all incoming packets during the migration so that the network stack doesn't get confused, but that should just appear as a temporary network interruption.
http://criu.org/TCP_connection
http://criu.org/TCP_connection
they mention using iptables so they might be utilizing conntrack and vrrp groups. Bunch of different ways to redirect in just a couple of packets.
It should not matter. They mention in the qa after that they are modifying the load balancer to point to each new instance during migration. TCP might drop the connection and reconnect but the results are the same.
Slick! In the next generation of phones (I.e. ones with more ram) I could easily see coming home and flicking my wrist to "throw" a VM off my phone to a local VM server. What application does that fit? No idea. It just sounds like fun.