Lukas Straub <[email protected]> writes: > Signed-off-by: Lukas Straub <[email protected]> > --- > MAINTAINERS | 2 +- > docs/COLO-FT.txt | 334 ------------------------------------------ > docs/system/index.rst | 1 + > docs/system/qemu-colo.rst | 360 > ++++++++++++++++++++++++++++++++++++++++++++++ > 4 files changed, 362 insertions(+), 335 deletions(-) > > diff --git a/MAINTAINERS b/MAINTAINERS > index > ceb3ecb1d955a267018c70429de61e45abb7a7ba..b04a5fef47d26ef14842e8a2e2a674651e9215e3 > 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -3854,7 +3854,7 @@ F: migration/multifd-colo.* > F: include/migration/colo.h > F: include/migration/failover.h > F: tests/qtest/migration/colo-tests.c > -F: docs/COLO-FT.txt > +F: docs/system/qemu-colo.rst > > COLO Proxy > M: Zhang Chen <[email protected]> > diff --git a/docs/COLO-FT.txt b/docs/COLO-FT.txt > deleted file mode 100644 > index > 2283a09c080b8996f9767eeb415e8d4fbdc940af..0000000000000000000000000000000000000000 > --- a/docs/COLO-FT.txt > +++ /dev/null > @@ -1,334 +0,0 @@ > -COarse-grained LOck-stepping Virtual Machines for Non-stop Service > ----------------------------------------- > -Copyright (c) 2016 Intel Corporation > -Copyright (c) 2016 HUAWEI TECHNOLOGIES CO., LTD. > -Copyright (c) 2016 Fujitsu, Corp. > - > -This work is licensed under the terms of the GNU GPL, version 2 or later. > -See the COPYING file in the top-level directory. > - > -This document gives an overview of COLO's design and how to use it. > - > -== Background == > -Virtual machine (VM) replication is a well known technique for providing > -application-agnostic software-implemented hardware fault tolerance, > -also known as "non-stop service". > - > -COLO (COarse-grained LOck-stepping) is a high availability solution. > -Both primary VM (PVM) and secondary VM (SVM) run in parallel. They receive > the > -same request from client, and generate response in parallel too. > -If the response packets from PVM and SVM are identical, they are released > -immediately. Otherwise, a VM checkpoint (on demand) is conducted. > - > -== Architecture == > - > -The architecture of COLO is shown in the diagram below. > -It consists of a pair of networked physical nodes: > -The primary node running the PVM, and the secondary node running the SVM > -to maintain a valid replica of the PVM. > -PVM and SVM execute in parallel and generate output of response packets for > -client requests according to the application semantics. > - > -The incoming packets from the client or external network are received by the > -primary node, and then forwarded to the secondary node, so that both the PVM > -and the SVM are stimulated with the same requests. > - > -COLO receives the outbound packets from both the PVM and SVM and compares > them > -before allowing the output to be sent to clients. > - > -The SVM is qualified as a valid replica of the PVM, as long as it generates > -identical responses to all client requests. Once the differences in the > outputs > -are detected between the PVM and SVM, COLO withholds transmission of the > -outbound packets until it has successfully synchronized the PVM state to the > SVM. > - > - Primary Node > Secondary Node > -+------------+ +-----------------------+ +------------------------+ > +------------+ > -| | | HeartBeat +<----->+ HeartBeat | > | | > -| Primary VM | +-----------+-----------+ +-----------+------------+ > |Secondary VM| > -| | | | > | | > -| | +-----------|-----------+ +-----------|------------+ > | | > -| | |QEMU +---v----+ | |QEMU +----v---+ | > | | > -| | | |Failover| | | |Failover| | > | | > -| | | +--------+ | | +--------+ | > | | > -| | | +---------------+ | | +---------------+ | > | | > -| | | | VM Checkpoint +-------------->+ VM Checkpoint | | > | | > -| | | +---------------+ | | +---------------+ | > | | > -|Requests<--------------------------\ /-----------------\ > /--------------------->Requests| > -| | | ^ ^ | | | | | > | | > -|Responses+---------------------\ /-|-|------------\ > /-------------------------+Responses| > -| | | | | | | | | | | | | | > | | > -| | | +-----------+ | | | | | | | | | | +----------+ | > | | > -| | | | COLO disk | | | | | | | | | | | | COLO disk| | > | | > -| | | | Manager +---------------------------->| Manager | | > | | > -| | | ++----------+ v v | | | | | v v | +---------++ | > | | > -| | | |+-----------+-+-+-++| | ++-+--+-+---------+ | | > | | > -| | | || COLO Proxy || | | COLO Proxy | | | > | | > -| | | || (compare packet || | |(adjust sequence | | | > | | > -| | | ||and mirror packet)|| | | and ACK) | | | > | | > -| | | |+------------+---+-+| | +-----------------+ | | > | | > -+------------+ +-----------------------+ +------------------------+ > +------------+ > -+------------+ | | | | > +------------+ > -| VM Monitor | | | | | > | VM Monitor | > -+------------+ | | | | > +------------+ > -+---------------------------------------+ > +----------------------------------------+ > -| Kernel | | | | | Kernel | > | > -+---------------------------------------+ > +----------------------------------------+ > - | | | | > - +--------------v+ +---------v---+--+ +------------------+ > +v-------------+ > - | Storage | |External Network| | External Network | | > Storage | > - +---------------+ +----------------+ +------------------+ > +--------------+ > - > - > -== Components introduction == > - > -You can see there are several components in COLO's diagram of architecture. > -Their functions are described below. > - > -HeartBeat: > -Runs on both the primary and secondary nodes, to periodically check platform > -availability. When the primary node suffers a hardware fail-stop failure, > -the heartbeat stops responding, the secondary node will trigger a failover > -as soon as it determines the absence. > - > -COLO disk Manager: > -When primary VM writes data into image, the colo disk manager captures this > data > -and sends it to secondary VM's which makes sure the context of secondary VM's > -image is consistent with the context of primary VM 's image. > -For more details, please refer to docs/block-replication.txt. > - > -Checkpoint/Failover Controller: > -Modifications of save/restore flow to realize continuous migration, > -to make sure the state of VM in Secondary side is always consistent with VM > in > -Primary side. > - > -COLO Proxy: > -Delivers packets to Primary and Secondary, and then compare the responses > from > -both side. Then decide whether to start a checkpoint according to some rules. > -Please refer to docs/colo-proxy.txt for more information. > - > -Note: > -HeartBeat has not been implemented yet, so you need to trigger failover > process > -by using 'x-colo-lost-heartbeat' command. > - > -== COLO operation status == > - > -+-----------------+ > -| | > -| Start COLO | > -| | > -+--------+--------+ > - | > - | Main qmp command: > - | migrate-set-capabilities with x-colo > - | migrate > - | > - v > -+--------+--------+ > -| | > -| COLO running | > -| | > -+--------+--------+ > - | > - | Main qmp command: > - | x-colo-lost-heartbeat > - | or > - | some error happened > - v > -+--------+--------+ > -| | send qmp event: > -| COLO failover | COLO_EXIT > -| | > -+-----------------+ > - > -COLO use the qmp command to switch and report operation status. > -The diagram just shows the main qmp command, you can get the detail > -in test procedure. > - > -== Test procedure == > -Note: Here we are running both instances on the same host for testing, > -change the IP Addresses if you want to run it on two hosts. Initially > -127.0.0.1 is the Primary Host and 127.0.0.2 is the Secondary Host. > - > -== Startup qemu == > -1. Primary: > -Note: Initially, $imagefolder/primary.qcow2 needs to be copied to all hosts. > -You don't need to change any IP's here, because 0.0.0.0 listens on any > -interface. The chardev's with 127.0.0.1 IP's loopback to the local qemu > -instance. > - > -# imagefolder="/mnt/vms/colo-test-primary" > - > -# qemu-system-x86_64 -enable-kvm -cpu qemu64,kvmclock=on -m 512 -smp 1 -qmp > stdio \ > - -device piix3-usb-uhci -device usb-tablet -name primary \ > - -netdev tap,id=hn0,vhost=off,helper=/usr/lib/qemu/qemu-bridge-helper \ > - -device rtl8139,id=e0,netdev=hn0 \ > - -chardev socket,id=mirror0,host=0.0.0.0,port=9003,server=on,wait=off \ > - -chardev socket,id=compare1,host=0.0.0.0,port=9004,server=on,wait=on \ > - -chardev socket,id=compare0,host=127.0.0.1,port=9001,server=on,wait=off \ > - -chardev socket,id=compare0-0,host=127.0.0.1,port=9001 \ > - -chardev > socket,id=compare_out,host=127.0.0.1,port=9005,server=on,wait=off \ > - -chardev socket,id=compare_out0,host=127.0.0.1,port=9005 \ > - -object filter-mirror,id=m0,netdev=hn0,queue=tx,outdev=mirror0 \ > - -object > filter-redirector,netdev=hn0,id=redire0,queue=rx,indev=compare_out \ > - -object filter-redirector,netdev=hn0,id=redire1,queue=rx,outdev=compare0 \ > - -object iothread,id=iothread1 \ > - -object > colo-compare,id=comp0,primary_in=compare0-0,secondary_in=compare1,\ > -outdev=compare_out0,iothread=iothread1 \ > - -drive > if=ide,id=colo-disk0,driver=quorum,read-pattern=fifo,vote-threshold=1,\ > -children.0.file.filename=$imagefolder/primary.qcow2,children.0.driver=qcow2 > -S > - > -2. Secondary: > -Note: Active and hidden images need to be created only once and the > -size should be the same as primary.qcow2. Again, you don't need to change > -any IP's here, except for the $primary_ip variable. > - > -# imagefolder="/mnt/vms/colo-test-secondary" > -# primary_ip=127.0.0.1 > - > -# qemu-img create -f qcow2 $imagefolder/secondary-active.qcow2 10G > - > -# qemu-img create -f qcow2 $imagefolder/secondary-hidden.qcow2 10G > - > -# qemu-system-x86_64 -enable-kvm -cpu qemu64,kvmclock=on -m 512 -smp 1 -qmp > stdio \ > - -device piix3-usb-uhci -device usb-tablet -name secondary \ > - -netdev tap,id=hn0,vhost=off,helper=/usr/lib/qemu/qemu-bridge-helper \ > - -device rtl8139,id=e0,netdev=hn0 \ > - -chardev socket,id=red0,host=$primary_ip,port=9003,reconnect-ms=1000 \ > - -chardev socket,id=red1,host=$primary_ip,port=9004,reconnect-ms=1000 \ > - -object filter-redirector,id=f1,netdev=hn0,queue=tx,indev=red0 \ > - -object filter-redirector,id=f2,netdev=hn0,queue=rx,outdev=red1 \ > - -object filter-rewriter,id=rew0,netdev=hn0,queue=all \ > - -drive > if=none,id=parent0,file.filename=$imagefolder/primary.qcow2,driver=qcow2 \ > - -drive > if=none,id=childs0,driver=replication,mode=secondary,file.driver=qcow2,\ > -top-id=colo-disk0,file.file.filename=$imagefolder/secondary-active.qcow2,\ > -file.backing.driver=qcow2,file.backing.file.filename=$imagefolder/secondary-hidden.qcow2,\ > -file.backing.backing=parent0 \ > - -drive > if=ide,id=colo-disk0,driver=quorum,read-pattern=fifo,vote-threshold=1,\ > -children.0=childs0 \ > - -incoming tcp:0.0.0.0:9998 > - > - > -3. On Secondary VM's QEMU monitor, issue command > -{"execute":"qmp_capabilities"} > -{"execute": "migrate-set-capabilities", "arguments": {"capabilities": [ > {"capability": "x-colo", "state": true } ] } } > -{"execute": "nbd-server-start", "arguments": {"addr": {"type": "inet", > "data": {"host": "0.0.0.0", "port": "9999"} } } } > -{"execute": "nbd-server-add", "arguments": {"device": "parent0", "writable": > true } } > - > -Note: > - a. The qmp command nbd-server-start and nbd-server-add must be run > - before running the qmp command migrate on primary QEMU > - b. Active disk, hidden disk and nbd target's length should be the > - same. > - c. It is better to put active disk and hidden disk in ramdisk. They > - will be merged into the parent disk on failover. > - > -4. On Primary VM's QEMU monitor, issue command: > -{"execute":"qmp_capabilities"} > -{"execute": "human-monitor-command", "arguments": {"command-line": > "drive_add -n buddy > driver=replication,mode=primary,file.driver=nbd,file.host=127.0.0.2,file.port=9999,file.export=parent0,node-name=replication0"}} > -{"execute": "x-blockdev-change", "arguments":{"parent": "colo-disk0", > "node": "replication0" } } > -{"execute": "migrate-set-capabilities", "arguments": {"capabilities": [ > {"capability": "x-colo", "state": true } ] } } > -{"execute": "migrate", "arguments": {"uri": "tcp:127.0.0.2:9998" } } > - > - Note: > - a. There should be only one NBD Client for each primary disk. > - b. The qmp command line must be run after running qmp command line in > - secondary qemu. > - > -5. After the above steps, you will see, whenever you make changes to PVM, > SVM will be synced. > -You can issue command '{ "execute": "migrate-set-parameters" , "arguments":{ > "x-checkpoint-delay": 2000 } }' > -to change the idle checkpoint period time > - > -6. Failover test > -You can kill one of the VMs and Failover on the surviving VM: > - > -If you killed the Secondary, then follow "Primary Failover". After that, > -if you want to resume the replication, follow "Primary resume replication" > - > -If you killed the Primary, then follow "Secondary Failover". After that, > -if you want to resume the replication, follow "Secondary resume replication" > - > -== Primary Failover == > -The Secondary died, resume on the Primary > - > -{"execute": "x-blockdev-change", "arguments":{ "parent": "colo-disk0", > "child": "children.1"} } > -{"execute": "human-monitor-command", "arguments":{ "command-line": > "drive_del replication0" } } > -{"execute": "object-del", "arguments":{ "id": "comp0" } } > -{"execute": "object-del", "arguments":{ "id": "iothread1" } } > -{"execute": "object-del", "arguments":{ "id": "m0" } } > -{"execute": "object-del", "arguments":{ "id": "redire0" } } > -{"execute": "object-del", "arguments":{ "id": "redire1" } } > -{"execute": "x-colo-lost-heartbeat" } > - > -== Secondary Failover == > -The Primary died, resume on the Secondary and prepare to become the new > Primary > - > -{"execute": "nbd-server-stop"} > -{"execute": "x-colo-lost-heartbeat"} > - > -{"execute": "object-del", "arguments":{ "id": "f2" } } > -{"execute": "object-del", "arguments":{ "id": "f1" } } > -{"execute": "chardev-remove", "arguments":{ "id": "red1" } } > -{"execute": "chardev-remove", "arguments":{ "id": "red0" } } > - > -{"execute": "chardev-add", "arguments":{ "id": "mirror0", "backend": > {"type": "socket", "data": {"addr": { "type": "inet", "data": { "host": > "0.0.0.0", "port": "9003" } }, "server": true } } } } > -{"execute": "chardev-add", "arguments":{ "id": "compare1", "backend": > {"type": "socket", "data": {"addr": { "type": "inet", "data": { "host": > "0.0.0.0", "port": "9004" } }, "server": true } } } } > -{"execute": "chardev-add", "arguments":{ "id": "compare0", "backend": > {"type": "socket", "data": {"addr": { "type": "inet", "data": { "host": > "127.0.0.1", "port": "9001" } }, "server": true } } } } > -{"execute": "chardev-add", "arguments":{ "id": "compare0-0", "backend": > {"type": "socket", "data": {"addr": { "type": "inet", "data": { "host": > "127.0.0.1", "port": "9001" } }, "server": false } } } } > -{"execute": "chardev-add", "arguments":{ "id": "compare_out", "backend": > {"type": "socket", "data": {"addr": { "type": "inet", "data": { "host": > "127.0.0.1", "port": "9005" } }, "server": true } } } } > -{"execute": "chardev-add", "arguments":{ "id": "compare_out0", "backend": > {"type": "socket", "data": {"addr": { "type": "inet", "data": { "host": > "127.0.0.1", "port": "9005" } }, "server": false } } } } > - > -== Primary resume replication == > -Resume replication after new Secondary is up. > - > -Start the new Secondary (Steps 2 and 3 above), then on the Primary: > -{"execute": "drive-mirror", "arguments":{ "device": "colo-disk0", "job-id": > "resync", "target": "nbd://127.0.0.2:9999/parent0", "mode": "existing", > "format": "raw", "sync": "full"} } > - > -Wait until disk is synced, then: > -{"execute": "stop"} > -{"execute": "block-job-cancel", "arguments":{ "device": "resync"} } > - > -{"execute": "human-monitor-command", "arguments":{ "command-line": > "drive_add -n buddy > driver=replication,mode=primary,file.driver=nbd,file.host=127.0.0.2,file.port=9999,file.export=parent0,node-name=replication0"}} > -{"execute": "x-blockdev-change", "arguments":{ "parent": "colo-disk0", > "node": "replication0" } } > - > -{"execute": "object-add", "arguments":{ "qom-type": "filter-mirror", "id": > "m0", "netdev": "hn0", "queue": "tx", "outdev": "mirror0" } } > -{"execute": "object-add", "arguments":{ "qom-type": "filter-redirector", > "id": "redire0", "netdev": "hn0", "queue": "rx", "indev": "compare_out" } } > -{"execute": "object-add", "arguments":{ "qom-type": "filter-redirector", > "id": "redire1", "netdev": "hn0", "queue": "rx", "outdev": "compare0" } } > -{"execute": "object-add", "arguments":{ "qom-type": "iothread", "id": > "iothread1" } } > -{"execute": "object-add", "arguments":{ "qom-type": "colo-compare", "id": > "comp0", "primary_in": "compare0-0", "secondary_in": "compare1", "outdev": > "compare_out0", "iothread": "iothread1" } } > - > -{"execute": "migrate-set-capabilities", "arguments":{ "capabilities": [ > {"capability": "x-colo", "state": true } ] } } > -{"execute": "migrate", "arguments":{ "uri": "tcp:127.0.0.2:9998" } } > - > -Note: > -If this Primary previously was a Secondary, then we need to insert the > -filters before the filter-rewriter by using the > -""insert": "before", "position": "id=rew0"" Options. See below. > - > -== Secondary resume replication == > -Become Primary and resume replication after new Secondary is up. Note > -that now 127.0.0.1 is the Secondary and 127.0.0.2 is the Primary. > - > -Start the new Secondary (Steps 2 and 3 above, but with primary_ip=127.0.0.2), > -then on the old Secondary: > -{"execute": "drive-mirror", "arguments":{ "device": "colo-disk0", "job-id": > "resync", "target": "nbd://127.0.0.1:9999/parent0", "mode": "existing", > "format": "raw", "sync": "full"} } > - > -Wait until disk is synced, then: > -{"execute": "stop"} > -{"execute": "block-job-cancel", "arguments":{ "device": "resync" } } > - > -{"execute": "human-monitor-command", "arguments":{ "command-line": > "drive_add -n buddy > driver=replication,mode=primary,file.driver=nbd,file.host=127.0.0.1,file.port=9999,file.export=parent0,node-name=replication0"}} > -{"execute": "x-blockdev-change", "arguments":{ "parent": "colo-disk0", > "node": "replication0" } } > - > -{"execute": "object-add", "arguments":{ "qom-type": "filter-mirror", "id": > "m0", "insert": "before", "position": "id=rew0", "netdev": "hn0", "queue": > "tx", "outdev": "mirror0" } } > -{"execute": "object-add", "arguments":{ "qom-type": "filter-redirector", > "id": "redire0", "insert": "before", "position": "id=rew0", "netdev": "hn0", > "queue": "rx", "indev": "compare_out" } } > -{"execute": "object-add", "arguments":{ "qom-type": "filter-redirector", > "id": "redire1", "insert": "before", "position": "id=rew0", "netdev": "hn0", > "queue": "rx", "outdev": "compare0" } } > -{"execute": "object-add", "arguments":{ "qom-type": "iothread", "id": > "iothread1" } } > -{"execute": "object-add", "arguments":{ "qom-type": "colo-compare", "id": > "comp0", "primary_in": "compare0-0", "secondary_in": "compare1", "outdev": > "compare_out0", "iothread": "iothread1" } } > - > -{"execute": "migrate-set-capabilities", "arguments":{ "capabilities": [ > {"capability": "x-colo", "state": true } ] } } > -{"execute": "migrate", "arguments":{ "uri": "tcp:127.0.0.1:9998" } } > - > -== TODO == > -1. Support shared storage. > -2. Develop the heartbeat part. > -3. Reduce checkpoint VM’s downtime while doing checkpoint. > diff --git a/docs/system/index.rst b/docs/system/index.rst > index > 427b020483104f6589878bbf255a367ae114c61b..6268c41aea9c74dc3e59d896b5ae082360bfbb1a > 100644 > --- a/docs/system/index.rst > +++ b/docs/system/index.rst > @@ -41,3 +41,4 @@ or Hypervisor.Framework. > igvm > vm-templating > sriov > + qemu-colo > diff --git a/docs/system/qemu-colo.rst b/docs/system/qemu-colo.rst > new file mode 100644 > index > 0000000000000000000000000000000000000000..4b5fbbf398f8a5c4ea6baad615bde94b2b4678d2 > --- /dev/null > +++ b/docs/system/qemu-colo.rst > @@ -0,0 +1,360 @@ > +Qemu COLO Fault Tolerance > +========================= > + > +| Copyright (c) 2016 Intel Corporation > +| Copyright (c) 2016 HUAWEI TECHNOLOGIES CO., LTD. > +| Copyright (c) 2016 Fujitsu, Corp. > + > +This work is licensed under the terms of the GNU GPL, version 2 or later. > +See the COPYING file in the top-level directory. > + > +This document gives an overview of COLO's design and how to use it. > + > +Background > +---------- > +Virtual machine (VM) replication is a well known technique for providing > +application-agnostic software-implemented hardware fault tolerance, > +also known as "non-stop service". > + > +COLO (COarse-grained LOck-stepping) is a high availability solution. > +Both primary VM (PVM) and secondary VM (SVM) run in parallel. They receive > the > +same request from client, and generate response in parallel too. > +If the response packets from PVM and SVM are identical, they are released > +immediately. Otherwise, a VM checkpoint (on demand) is conducted. > + > +Architecture > +------------ > +The architecture of COLO is shown in the diagram below. > +It consists of a pair of networked physical nodes: > +The primary node running the PVM, and the secondary node running the SVM > +to maintain a valid replica of the PVM. > +PVM and SVM execute in parallel and generate output of response packets for > +client requests according to the application semantics. > + > +The incoming packets from the client or external network are received by the > +primary node, and then forwarded to the secondary node, so that both the PVM > +and the SVM are stimulated with the same requests. > + > +COLO receives the outbound packets from both the PVM and SVM and compares > them > +before allowing the output to be sent to clients. > + > +The SVM is qualified as a valid replica of the PVM, as long as it generates > +identical responses to all client requests. Once the differences in the > outputs > +are detected between the PVM and SVM, COLO withholds transmission of the > +outbound packets until it has successfully synchronized the PVM state to the > SVM. > + > +Overview:: > + > + Primary Node > Secondary Node > + +------------+ +-----------------------+ > +------------------------+ +------------+ > + | | | HeartBeat +<----->+ HeartBeat > | | | > + | Primary VM | +-----------+-----------+ > +-----------+------------+ |Secondary VM| > + | | | | > | | > + | | +-----------|-----------+ > +-----------|------------+ | | > + | | |QEMU +---v----+ | |QEMU +----v---+ > | | | > + | | | |Failover| | | |Failover| > | | | > + | | | +--------+ | | +--------+ > | | | > + | | | +---------------+ | | +---------------+ > | | | > + | | | | VM Checkpoint +-------------->+ VM Checkpoint | > | | | > + | | | +---------------+ | | +---------------+ > | | | > + |Requests<--------------------------\ /-----------------\ > /--------------------->Requests| > + | | | ^ ^ | | | | > | | | > + |Responses+---------------------\ /-|-|------------\ > /-------------------------+Responses| > + | | | | | | | | | | | | | > | | | > + | | | +-----------+ | | | | | | | | | | +----------+ > | | | > + | | | | COLO disk | | | | | | | | | | | | COLO disk| > | | | > + | | | | Manager +---------------------------->| Manager | > | | | > + | | | ++----------+ v v | | | | | v v | +---------++ > | | | > + | | | |+-----------+-+-+-++| | ++-+--+-+---------+ | > | | | > + | | | || COLO Proxy || | | COLO Proxy | | > | | | > + | | | || (compare packet || | |(adjust sequence | | > | | | > + | | | ||and mirror packet)|| | | and ACK) | | > | | | > + | | | |+------------+---+-+| | +-----------------+ | > | | | > + +------------+ +-----------------------+ > +------------------------+ +------------+ > + +------------+ | | | | > +------------+ > + | VM Monitor | | | | | > | VM Monitor | > + +------------+ | | | | > +------------+ > + +---------------------------------------+ > +----------------------------------------+ > + | Kernel | | | | | Kernel | > | > + +---------------------------------------+ > +----------------------------------------+ > + | | | | > + +--------------v+ +---------v---+--+ +------------------+ > +v-------------+ > + | Storage | |External Network| | External Network | | > Storage | > + +---------------+ +----------------+ +------------------+ > +--------------+ > + > +Components introduction > +^^^^^^^^^^^^^^^^^^^^^^^ > +You can see there are several components in COLO's diagram of architecture. > +Their functions are described below. > + > +HeartBeat > +~~~~~~~~~ > +Runs on both the primary and secondary nodes, to periodically check platform > +availability. When the primary node suffers a hardware fail-stop failure, > +the heartbeat stops responding, the secondary node will trigger a failover > +as soon as it determines the absence. > + > +COLO disk Manager > +~~~~~~~~~~~~~~~~~ > +When primary VM writes data into image, the colo disk manager captures this > data > +and sends it to secondary VM's which makes sure the context of secondary VM's > +image is consistent with the context of primary VM 's image. > +For more details, please refer to docs/block-replication.txt. > + > +Checkpoint/Failover Controller > +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > +Modifications of save/restore flow to realize continuous migration, > +to make sure the state of VM in Secondary side is always consistent with VM > in > +Primary side. > + > +COLO Proxy > +~~~~~~~~~~ > +Delivers packets to Primary and Secondary, and then compare the responses > from > +both side. Then decide whether to start a checkpoint according to some rules. > +Please refer to docs/colo-proxy.txt for more information. > + > +Note: > +HeartBeat has not been implemented yet, so you need to trigger failover > process > +by using 'x-colo-lost-heartbeat' command. > + > +COLO operation status > +^^^^^^^^^^^^^^^^^^^^^ > + > +Overview:: > + > + +-----------------+ > + | | > + | Start COLO | > + | | > + +--------+--------+ > + | > + | Main qmp command: > + | migrate-set-capabilities with x-colo > + | migrate > + | > + v > + +--------+--------+ > + | | > + | COLO running | > + | | > + +--------+--------+ > + | > + | Main qmp command: > + | x-colo-lost-heartbeat > + | or > + | some error happened > + v > + +--------+--------+ > + | | send qmp event: > + | COLO failover | COLO_EXIT > + | | > + +-----------------+ > + > + > +COLO use the qmp command to switch and report operation status. > +The diagram just shows the main qmp command, you can get the detail > +in test procedure. > + > +Test procedure > +-------------- > +Note: Here we are running both instances on the same host for testing, > +change the IP Addresses if you want to run it on two hosts. Initially > +``127.0.0.1`` is the Primary Host and ``127.0.0.2`` is the Secondary Host. > + > +Startup qemu > +^^^^^^^^^^^^ > +**1. Primary**: > +Note: Initially, ``$imagefolder/primary.qcow2`` needs to be copied to all > hosts. > +You don't need to change any IP's here, because ``0.0.0.0`` listens on any > +interface. The chardev's with ``127.0.0.1`` IP's loopback to the local qemu > +instance:: > + > + # imagefolder="/mnt/vms/colo-test-primary" > + > + # qemu-system-x86_64 -enable-kvm -cpu qemu64,kvmclock=on -m 512 -smp 1 > -qmp stdio \ > + -device piix3-usb-uhci -device usb-tablet -name primary \ > + -netdev tap,id=hn0,vhost=off,helper=/usr/lib/qemu/qemu-bridge-helper \ > + -device rtl8139,id=e0,netdev=hn0 \ > + -chardev socket,id=mirror0,host=0.0.0.0,port=9003,server=on,wait=off \ > + -chardev socket,id=compare1,host=0.0.0.0,port=9004,server=on,wait=on \ > + -chardev > socket,id=compare0,host=127.0.0.1,port=9001,server=on,wait=off \ > + -chardev socket,id=compare0-0,host=127.0.0.1,port=9001 \ > + -chardev > socket,id=compare_out,host=127.0.0.1,port=9005,server=on,wait=off \ > + -chardev socket,id=compare_out0,host=127.0.0.1,port=9005 \ > + -object filter-mirror,id=m0,netdev=hn0,queue=tx,outdev=mirror0 \ > + -object > filter-redirector,netdev=hn0,id=redire0,queue=rx,indev=compare_out \ > + -object > filter-redirector,netdev=hn0,id=redire1,queue=rx,outdev=compare0 \ > + -object iothread,id=iothread1 \ > + -object > colo-compare,id=comp0,primary_in=compare0-0,secondary_in=compare1,\ > + outdev=compare_out0,iothread=iothread1 \ > + -drive > if=ide,id=colo-disk0,driver=quorum,read-pattern=fifo,vote-threshold=1,\ > + > children.0.file.filename=$imagefolder/primary.qcow2,children.0.driver=qcow2 -S > + > + > +**2. Secondary**: > +Note: Active and hidden images need to be created only once and the > +size should be the same as ``primary.qcow2``. Again, you don't need to change > +any IP's here, except for the ``$primary_ip`` variable:: > + > + # imagefolder="/mnt/vms/colo-test-secondary" > + # primary_ip=127.0.0.1 > + > + # qemu-img create -f qcow2 $imagefolder/secondary-active.qcow2 10G > + > + # qemu-img create -f qcow2 $imagefolder/secondary-hidden.qcow2 10G > + > + # qemu-system-x86_64 -enable-kvm -cpu qemu64,kvmclock=on -m 512 -smp 1 > -qmp stdio \ > + -device piix3-usb-uhci -device usb-tablet -name secondary \ > + -netdev tap,id=hn0,vhost=off,helper=/usr/lib/qemu/qemu-bridge-helper \ > + -device rtl8139,id=e0,netdev=hn0 \ > + -chardev socket,id=red0,host=$primary_ip,port=9003,reconnect-ms=1000 \ > + -chardev socket,id=red1,host=$primary_ip,port=9004,reconnect-ms=1000 \ > + -object filter-redirector,id=f1,netdev=hn0,queue=tx,indev=red0 \ > + -object filter-redirector,id=f2,netdev=hn0,queue=rx,outdev=red1 \ > + -object filter-rewriter,id=rew0,netdev=hn0,queue=all \ > + -drive > if=none,id=parent0,file.filename=$imagefolder/primary.qcow2,driver=qcow2 \ > + -drive > if=none,id=childs0,driver=replication,mode=secondary,file.driver=qcow2,\ > + > top-id=colo-disk0,file.file.filename=$imagefolder/secondary-active.qcow2,\ > + > file.backing.driver=qcow2,file.backing.file.filename=$imagefolder/secondary-hidden.qcow2,\ > + file.backing.backing=parent0 \ > + -drive > if=ide,id=colo-disk0,driver=quorum,read-pattern=fifo,vote-threshold=1,\ > + children.0=childs0 \ > + -incoming tcp:0.0.0.0:9998 > + > + > +**3.** On Secondary VM's QEMU monitor, issue command:: > + > + {"execute":"qmp_capabilities"} > + {"execute": "migrate-set-capabilities", "arguments": {"capabilities": [ > {"capability": "x-colo", "state": true } ] } } > + {"execute": "nbd-server-start", "arguments": {"addr": {"type": "inet", > "data": {"host": "0.0.0.0", "port": "9999"} } } } > + {"execute": "nbd-server-add", "arguments": {"device": "parent0", > "writable": true } } > + > +Note: > + a. The qmp command ``nbd-server-start`` and ``nbd-server-add`` must be run > + before running the qmp command migrate on primary QEMU > + b. Active disk, hidden disk and nbd target's length should be the > + same. > + c. It is better to put active disk and hidden disk in ramdisk. They > + will be merged into the parent disk on failover. > + > +**4.** On Primary VM's QEMU monitor, issue command:: > + > + {"execute":"qmp_capabilities"} > + {"execute": "human-monitor-command", "arguments": {"command-line": > "drive_add -n buddy > driver=replication,mode=primary,file.driver=nbd,file.host=127.0.0.2,file.port=9999,file.export=parent0,node-name=replication0"}} > + {"execute": "x-blockdev-change", "arguments":{"parent": "colo-disk0", > "node": "replication0" } } > + {"execute": "migrate-set-capabilities", "arguments": {"capabilities": [ > {"capability": "x-colo", "state": true } ] } } > + {"execute": "migrate", "arguments": {"uri": "tcp:127.0.0.2:9998" } } > + > +Note: > + a. There should be only one NBD Client for each primary disk. > + b. The qmp command line must be run after running qmp command line in > + secondary qemu. > + > +**5.** After the above steps, you will see, whenever you make changes to > PVM, SVM will be synced. > +You can issue command ``{ "execute": "migrate-set-parameters" , > "arguments":{ "x-checkpoint-delay": 2000 } }`` > +to change the idle checkpoint period time > + > +Failover test > +^^^^^^^^^^^^^ > +You can kill one of the VMs and Failover on the surviving VM: > + > +If you killed the Secondary, then follow "Primary Failover". > +After that, if you want to resume the replication, follow "Primary resume > replication" > + > +If you killed the Primary, then follow "Secondary Failover". > +After that, if you want to resume the replication, follow "Secondary resume > replication" > + > +Primary Failover > +~~~~~~~~~~~~~~~~ > +The Secondary died, resume on the Primary:: > + > + {"execute": "x-blockdev-change", "arguments":{ "parent": "colo-disk0", > "child": "children.1"} } > + {"execute": "human-monitor-command", "arguments":{ "command-line": > "drive_del replication0" } } > + {"execute": "object-del", "arguments":{ "id": "comp0" } } > + {"execute": "object-del", "arguments":{ "id": "iothread1" } } > + {"execute": "object-del", "arguments":{ "id": "m0" } } > + {"execute": "object-del", "arguments":{ "id": "redire0" } } > + {"execute": "object-del", "arguments":{ "id": "redire1" } } > + {"execute": "x-colo-lost-heartbeat" } > + > +Secondary Failover > +~~~~~~~~~~~~~~~~~~ > +The Primary died, resume on the Secondary and prepare to become the new > Primary:: > + > + {"execute": "nbd-server-stop"} > + {"execute": "x-colo-lost-heartbeat"} > + > + {"execute": "object-del", "arguments":{ "id": "f2" } } > + {"execute": "object-del", "arguments":{ "id": "f1" } } > + {"execute": "chardev-remove", "arguments":{ "id": "red1" } } > + {"execute": "chardev-remove", "arguments":{ "id": "red0" } } > + > + {"execute": "chardev-add", "arguments":{ "id": "mirror0", "backend": > {"type": "socket", "data": {"addr": { "type": "inet", "data": { "host": > "0.0.0.0", "port": "9003" } }, "server": true } } } } > + {"execute": "chardev-add", "arguments":{ "id": "compare1", "backend": > {"type": "socket", "data": {"addr": { "type": "inet", "data": { "host": > "0.0.0.0", "port": "9004" } }, "server": true } } } } > + {"execute": "chardev-add", "arguments":{ "id": "compare0", "backend": > {"type": "socket", "data": {"addr": { "type": "inet", "data": { "host": > "127.0.0.1", "port": "9001" } }, "server": true } } } } > + {"execute": "chardev-add", "arguments":{ "id": "compare0-0", "backend": > {"type": "socket", "data": {"addr": { "type": "inet", "data": { "host": > "127.0.0.1", "port": "9001" } }, "server": false } } } } > + {"execute": "chardev-add", "arguments":{ "id": "compare_out", "backend": > {"type": "socket", "data": {"addr": { "type": "inet", "data": { "host": > "127.0.0.1", "port": "9005" } }, "server": true } } } } > + {"execute": "chardev-add", "arguments":{ "id": "compare_out0", > "backend": {"type": "socket", "data": {"addr": { "type": "inet", "data": { > "host": "127.0.0.1", "port": "9005" } }, "server": false } } } } > + > +Primary resume replication > +~~~~~~~~~~~~~~~~~~~~~~~~~~ > +Resume replication after new Secondary is up. > + > +Start the new Secondary (Steps 2 and 3 above), then on the Primary:: > + > + {"execute": "drive-mirror", "arguments":{ "device": "colo-disk0", > "job-id": "resync", "target": "nbd://127.0.0.2:9999/parent0", "mode": > "existing", "format": "raw", "sync": "full"} } > + > +Wait until disk is synced, then:: > + > + {"execute": "stop"} > + {"execute": "block-job-cancel", "arguments":{ "device": "resync"} } > + > + {"execute": "human-monitor-command", "arguments":{ "command-line": > "drive_add -n buddy > driver=replication,mode=primary,file.driver=nbd,file.host=127.0.0.2,file.port=9999,file.export=parent0,node-name=replication0"}} > + {"execute": "x-blockdev-change", "arguments":{ "parent": "colo-disk0", > "node": "replication0" } } > + > + {"execute": "object-add", "arguments":{ "qom-type": "filter-mirror", > "id": "m0", "netdev": "hn0", "queue": "tx", "outdev": "mirror0" } } > + {"execute": "object-add", "arguments":{ "qom-type": "filter-redirector", > "id": "redire0", "netdev": "hn0", "queue": "rx", "indev": "compare_out" } } > + {"execute": "object-add", "arguments":{ "qom-type": "filter-redirector", > "id": "redire1", "netdev": "hn0", "queue": "rx", "outdev": "compare0" } } > + {"execute": "object-add", "arguments":{ "qom-type": "iothread", "id": > "iothread1" } } > + {"execute": "object-add", "arguments":{ "qom-type": "colo-compare", > "id": "comp0", "primary_in": "compare0-0", "secondary_in": "compare1", > "outdev": "compare_out0", "iothread": "iothread1" } } > + > + {"execute": "migrate-set-capabilities", "arguments":{ "capabilities": [ > {"capability": "x-colo", "state": true } ] } } > + {"execute": "migrate", "arguments":{ "uri": "tcp:127.0.0.2:9998" } } > + > +Note: > +If this Primary previously was a Secondary, then we need to insert the > +filters before the filter-rewriter by using the > +""insert": "before", "position": "id=rew0"" Options. See below. > + > +Secondary resume replication > +~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > +Become Primary and resume replication after new Secondary is up. Note > +that now 127.0.0.1 is the Secondary and 127.0.0.2 is the Primary. > + > +Start the new Secondary (Steps 2 and 3 above, but with primary_ip=127.0.0.2), > +then on the old Secondary:: > + > + {"execute": "drive-mirror", "arguments":{ "device": "colo-disk0", > "job-id": "resync", "target": "nbd://127.0.0.1:9999/parent0", "mode": > "existing", "format": "raw", "sync": "full"} } > + > +Wait until disk is synced, then:: > + > + {"execute": "stop"} > + {"execute": "block-job-cancel", "arguments":{ "device": "resync" } } > + > + {"execute": "human-monitor-command", "arguments":{ "command-line": > "drive_add -n buddy > driver=replication,mode=primary,file.driver=nbd,file.host=127.0.0.1,file.port=9999,file.export=parent0,node-name=replication0"}} > + {"execute": "x-blockdev-change", "arguments":{ "parent": "colo-disk0", > "node": "replication0" } } > + > + {"execute": "object-add", "arguments":{ "qom-type": "filter-mirror", > "id": "m0", "insert": "before", "position": "id=rew0", "netdev": "hn0", > "queue": "tx", "outdev": "mirror0" } } > + {"execute": "object-add", "arguments":{ "qom-type": "filter-redirector", > "id": "redire0", "insert": "before", "position": "id=rew0", "netdev": "hn0", > "queue": "rx", "indev": "compare_out" } } > + {"execute": "object-add", "arguments":{ "qom-type": "filter-redirector", > "id": "redire1", "insert": "before", "position": "id=rew0", "netdev": "hn0", > "queue": "rx", "outdev": "compare0" } } > + {"execute": "object-add", "arguments":{ "qom-type": "iothread", "id": > "iothread1" } } > + {"execute": "object-add", "arguments":{ "qom-type": "colo-compare", > "id": "comp0", "primary_in": "compare0-0", "secondary_in": "compare1", > "outdev": "compare_out0", "iothread": "iothread1" } } > + > + {"execute": "migrate-set-capabilities", "arguments":{ "capabilities": [ > {"capability": "x-colo", "state": true } ] } } > + {"execute": "migrate", "arguments":{ "uri": "tcp:127.0.0.1:9998" } } > + > +TODO > +---- > +1. Support shared storage. > +2. Develop the heartbeat part. > +3. Reduce checkpoint VM’s downtime while doing checkpoint.
Reviewed-by: Fabiano Rosas <[email protected]>
