Here are my observations, coming from the perspective of an OpenStack deployment networking architect.
The weather cooperated, providing opportunities for sitting on the beach with a Cerveza in hand, talking with engineers from several different companies working on the same Open Source projects. It was a good trip, I think I ate more excellent food in one week than ever before. In-memory database migration across hostsĪ counter on the same host with checkpoint -> restoreĪ tweet producer/consumer application centered around an in-memory database, redis.I just returned home from Barcelona, where I attended the OpenStack Design Summit for Ocata, the next release of OpenStack. IP conflict with getting same IP assignment across hosts Requires load balancer solution fronting migrating servicesĮxternal volume data migration would require a solution that supported volume drivers/data export (use clustered FS)ĭemonstrate basic checkpoint restore on a single host1 (docker import on target to re-create target image) Read container metadata from source container Create container from new image at target Replicate container metadata into new container Extract checkpoint metadata into new container path Start container with docker start -checkpointĭocker export -> docker import only addresses filesystem migration does not save container runtime metadata (e.g. a read-only root filesystem)Ĭheckpoint the container Migrate checkpoint metadata to target Pull (or pre-pull) exact image on target Create container from same image at target Extract checkpoint metadata into new container path Start container with docker start -checkpointĬheckpoint the container Migrate checkpoint metadata to target docker export stopped container, migrate to target
Only in-memory changes to process stateĢ.
Two potential paths for live migration of container data:ġ. # docker start -checkpoint checkpoint_id container # docker checkpoint container checkpoint_idOPTIONS: Simplest model implemented allows for checkpoint associated with a specific container restore re-starts same container at the named checkpoint Migrating Quake game backend between hostsĭocker 1.13 use will require the experimental build to allow for testing/validation of capabilities and use cases Support already existed in libcontainer (and the runc) codebase Popular demo from DockerCon SF 2015 Support to the Docker API/client UI Support has been merged into theĮngine as of September 2016 Will be part of the Docker 1.13 release Hard work (and perseverance) by Ross Pipes/fifos, UNIX sockets, network sockets, IPC, timers, signals,ĬRIU & Docker The Docker engine is bringing CRIU Process/thread info+caps+uid/gid info, application memory, open files, Was that the C/R work was performed from userspaceĪll major kernel changes required were completed by the 3.11 LinuxĬRIU handles freezing all the process state: Key difference from other checkpoint/restore attempts in Linux Until CRIU Checkpoint Restore In Userspace Work began in 2011/2012 in the Linux kernel 3.11 kernel + CRIU in late 2013 had working release 2016: CRIU 2.0 releasedĬRIU: A Brief Overview Proposed and led by Pavel Emelyanov from OpenVZ team System suspend/resume is a solved problem Hypervisor-based live migration can take advantage of thisĬontainers are processes Can the Linux kernel migrate a process? Well, not as easily Why? A hypervisor is controlling an emulated (complete) machine Why cant I do live migration of containers? Live Container MigrationPhil Estes, STSM Open Containers, IBM Cloud, Murakami, Senior Engineer, IBM Cloud, Live migration supported by most hypervisors in OpenStackĬontainer use across OpenStack ecosystem growing
0 kommentar(er)
