Re: [Qemu-devel] [PATCH COLO-Frame (Base) v20 16/17] docs: Add documentation for COLO feature

[Eric Blake]

On 09/29/2016 03:46 AM, zhanghailiang wrote:
> Introduce the design of COLO, and how to test it.
> 
> Signed-off-by: zhanghailiang <address@hidden>
> ---
>  docs/COLO-FT.txt | 190 
> +++++++++++++++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 190 insertions(+)
>  create mode 100644 docs/COLO-FT.txt
> 

> +
> +== Background ==
> +Virtual machine (VM) replication is a well known technique for providing
> +application-agnostic software-implemented hardware fault tolerance
> +"non-stop service".

Do you want s/tolerance/tolerance, also known as/ ?


> +== Architecture ==
> +
> +The architecture of COLO is shown in the bellow diagram.

s/bellow diagram/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

s/Both/both/

> +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.
> +

> +== Components introduction ==
> +
> +You can see there are several components in COLO's diagram of architecture.
> +Their functions are described as bellow.

s/as bellow/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 manger captures this 
> data
> +and send it to secondary VM’s which makes sure the context of secondary VM's

s/send/sends/

> +image is consentient with the context of primary VM 's image.

s/consentient/consistent/
s/VM 's/VM's/

> +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 always be consistent with VM 
> in

s/always be/is always/

> +Primary side.
> +
> +COLO Proxy:
> +Delivers packets to Primary and Seconday, and then compare the responses from
> +both side. Then decide whether to start a checkpoint according to some rules.
> +
> +Note:
> + a. HeartBeat is not been realized, so you need to trigger failover process

s/is/has/
s/realized/implemented yet/

Is this note going to be stale once heartbeat is implemented?

> +    by using 'x-colo-lost-heartbeat' command.
> + b. COLO proxy compents is work-in-process, it only support periodic 
> checkpoint

s/compents is/components are a/

> +    mode now, just as Micro-checkpointing.
> +

> +3. 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=xx.xx.xx.xx,file.port=8889,file.export=colo-disk0,node-name=node0'}}

It would be really nice if we could get this done through QMP
blockdev-add instead of HMP drive_add.

> +
> +Before issuing '{ "execute": "x-colo-lost-heartbeat" }' command, we have to
> +issue block related command to stop block replication.
> +Primary:
> +  Remove the nbd child from the quorum:
> +  { 'execute': 'x-blockdev-change', 'arguments': {'parent': 'colo-disk0', 
> 'child': 'children.1'}}
> +  { 'execute': 'human-monitor-command','arguments': {'command-line': 
> 'drive_del blk-buddy0'}}
> +  Note: there is no qmp command to remove the blockdev now

Don't we have x-blockdev-del?

> +
> +Secondary:
> +  The primary host is down, so we should do the following thing:
> +  { 'execute': 'nbd-server-stop' }
> +
> +== TODO ==
> +1. Support continuously VM replication.

s/continuously/continuous/

> +2. Support shared storage.
> +3. Develop the heartbeat part.
> +4. Reduce checkpoint VM’s downtime while do checkpoint.

s/do/doing/

> 

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

signature.asc
Description: OpenPGP digital signature