From: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
To: Tkid <zhangchen.fnst@cn.fujitsu.com>
Cc: zhang.zhanghailiang@huawei.com, lizhijian@cn.fujitsu.com,
jan.kiszka@siemens.com, jasowang@redhat.com,
eddie.dong@intel.com, qemu-devel@nongnu.org,
peter.huangpeng@huawei.com, arei.gonglei@huawei.com,
stefanha@redhat.com, guijianfeng@cn.fujitsu.com
Subject: Re: [Qemu-devel] [POC]colo-proxy in qemu
Date: Tue, 10 Nov 2015 10:54:29 +0000 [thread overview]
Message-ID: <20151110105428.GC2456@work-vm> (raw)
In-Reply-To: <56418003.9010208@cn.fujitsu.com>
* Tkid (zhangchen.fnst@cn.fujitsu.com) wrote:
> Hi,all
>
> We are planning to reimplement colo proxy in userspace (Here is in qemu) to
> cache and compare net packets.This module is one of the important components
> of COLO project and now it is still in early stage, so any comments and
> feedback are warmly welcomed,thanks in advance.
>
> ## Background
> COLO FT/HA (COarse-grain LOck-stepping Virtual Machines for Non-stop
> Service)
> project 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
> responses 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.
> Paper:
> http://www.socc2013.org/home/program/a3-dong.pdf?attredirects=0
> COLO on Xen:
> http://wiki.xen.org/wiki/COLO_-_Coarse_Grain_Lock_Stepping
> COLO on Qemu/KVM:
> http://wiki.qemu.org/Features/COLO
>
> By the needs of capturing response packets from PVM and SVM and finding out
> whether they are identical, we introduce a new module to qemu networking
> called
> colo-proxy.
>
> This document describes the design of the colo-proxy module
>
> ## Glossary
> PVM - Primary VM, which provides services to clients.
> SVM - Secondary VM, a hot standby and replication of PVM.
> PN - Primary Node, the host which PVM runs on
> SN - Secondary Node, the host which SVM runs on
>
> ## Our Idea ##
>
> COLO-Proxy
> COLO-Proxy is a part of COLO,based on qemu net filter and it's a plugin for
> qemu net filter.the function keep SVM connect normal to PVM and compare
> PVM's packets to SVM's packets.if difference,notify COLO do checkpoint.
>
> == Workflow ==
>
>
> +--+ +--+
> |PN| |SN|
> +-----------------------+ +-----------------------+
> | +-------------------+ | | +-------------------+ |
> | | | | | | | |
> | | PVM | | | | SVM | |
> | | | | | | | |
> | +--+-^--------------+ | | +-------------^----++ |
> | | | | | | | |
> | | | +------------+ | | +-----------+ | | |
> | | | | COLO | | (socket) | | COLO | | | |
> | | | | CheckPoint +---------------------> CheckPoint| | | |
> | | | | | | (6) | | | | | |
> | | | +-----^------+ | | +-----------+ | | |
> | | | (5) | | | | | |
> | | | | | | | | |
> | +--v-+--------------+ | Forward(socket) | +-------------+----v+ |
> | |COLO Proxy | +-------+(1)+--------->seq&ack adjust(2)| | |
> | | +-----+------+ | | +-----------------+ | |
> | | | Compare(4) <-------+(3)+---------+ COLO Proxy | |
> | +-------------------+ | Forward(socket) | +-------------------+ |
> ++Qemu+-----------------+ ++Qemu+-----------------+
> | ^
> | |
> | |
> +--------v-+--------+
> | |
> | Client |
> | |
> +-------------------+
>
>
> (1)When PN receive client packets,PN COLO-Proxy copy and forward packets to
> SN COLO-Proxy.
> (2)SN COLO-Proxy record PVM's packet inital seq & adjust client's ack,send
> adjusted packets to SVM
> (3)SN Qemu COLO-Proxy recieve SVM's packets and forward to PN Qemu
> COLO-Proxy.
What protocol are you using for the data carried over the Forward(socket)?
I'm just wondering if there's an existing layer2 tunneling protocol that
it would be best to use.
> (4)PN Qemu COLO-Proxy enqueue SVM's packets and enqueue PVM's packets,then
> compare PVM's packets data with SVM's packets data. If packets is different,
> compare
> module notify COLO CheckPoint module to do a checkpoint then send PVM's
> packets to
> client and drop SVM's packets, otherwise, just send PVM's packets to client
> and
> drop SVM's packets.
> (5)notify COLO-Checkpoint module checkpoint is needed
> (6)Do COLO-Checkpoint
>
> ### QEMU space TCP/IP stack(Based on SLIRP) ###
> We need a QEMU space TCP/IP stack to help us to analysis packet. After
> looking
> into QEMU, we found that SLIRP
>
> http://wiki.qemu.org/Documentation/Networking#User_Networking_.28SLIRP.29
>
> is a good choice for us. SLIRP proivdes a full TCP/IP stack within QEMU, it
> can
> help use to handle the packet written to/read from backend(tap) device which
> is
> just like a link layer(L2) packet.
I still think SLIRP might be painful; but it might be an easy one to start
with.
> ### Packet enqueue and compare ###
> Together with QEMU space TCP/IP stack, we enqueue all packets sent by PVM
> and
> SVM on Primary QEMU, and then compare the packet payload for each
> connection.
Dave
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
next prev parent reply other threads:[~2015-11-10 10:54 UTC|newest]
Thread overview: 63+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-11-10 5:26 [Qemu-devel] [POC]colo-proxy in qemu Tkid
2015-11-10 7:35 ` Jason Wang
2015-11-10 8:30 ` zhanghailiang
2015-11-11 2:28 ` Jason Wang
2015-11-10 9:35 ` Tkid
2015-11-11 3:04 ` Jason Wang
2015-11-10 9:41 ` Dr. David Alan Gilbert
2015-11-11 3:09 ` Jason Wang
2015-11-11 9:03 ` Dr. David Alan Gilbert
2015-11-11 1:23 ` Dong, Eddie
2015-11-11 3:26 ` Jason Wang
2015-11-10 10:54 ` Dr. David Alan Gilbert [this message]
2015-11-11 2:46 ` Zhang Chen
2015-11-13 12:33 ` Dr. David Alan Gilbert
-- strict thread matches above, loose matches on Subject: below --
2015-07-20 6:42 [Qemu-devel] [POC] colo-proxy " Li Zhijian
2015-07-20 10:32 ` Stefan Hajnoczi
2015-07-20 11:55 ` zhanghailiang
2015-07-20 13:12 ` Vasiliy Tolstov
2015-07-20 15:01 ` Stefan Hajnoczi
2015-07-21 1:59 ` zhanghailiang
2015-07-28 22:13 ` Samuel Thibault
2015-07-21 6:13 ` Jan Kiszka
2015-07-21 9:49 ` Stefan Hajnoczi
2015-07-27 10:13 ` Stefan Hajnoczi
2015-07-27 11:24 ` zhanghailiang
2015-07-27 11:31 ` Samuel Thibault
2015-07-27 13:33 ` Jan Kiszka
2015-07-28 22:12 ` Samuel Thibault
2015-07-29 7:36 ` Jan Kiszka
2015-07-20 12:02 ` Li Zhijian
2015-07-24 2:04 ` Dong, Eddie
2015-07-24 2:12 ` Jason Wang
2015-07-24 8:04 ` Yang Hongyang
2015-07-27 3:24 ` Jason Wang
2015-07-27 3:54 ` Yang Hongyang
2015-07-27 4:49 ` Jason Wang
2015-07-27 5:51 ` Yang Hongyang
2015-07-27 7:37 ` Jason Wang
2015-07-27 7:49 ` Yang Hongyang
2015-07-27 8:06 ` Jason Wang
2015-07-27 8:22 ` Yang Hongyang
2015-07-27 7:53 ` Jason Wang
2015-07-27 8:17 ` Yang Hongyang
2015-07-27 18:33 ` Dr. David Alan Gilbert
2015-07-27 10:40 ` Dr. David Alan Gilbert
2015-07-27 13:39 ` Yang Hongyang
2015-07-24 2:05 ` Dong, Eddie
2015-07-30 4:23 ` Jason Wang
2015-07-30 7:16 ` Gonglei
2015-07-30 7:47 ` Dong, Eddie
2015-07-30 8:03 ` Dr. David Alan Gilbert
2015-07-30 8:15 ` Jason Wang
2015-07-30 11:56 ` Dr. David Alan Gilbert
2015-07-30 12:10 ` Gonglei
2015-07-30 12:30 ` Dr. David Alan Gilbert
2015-07-30 12:42 ` zhanghailiang
2015-07-30 13:59 ` Dr. David Alan Gilbert
2015-07-30 15:17 ` Yang Hongyang
2015-07-30 17:53 ` Dr. David Alan Gilbert
2015-07-31 1:08 ` Yang Hongyang
2015-07-31 1:28 ` zhanghailiang
2015-07-31 1:31 ` Yang Hongyang
2015-07-31 1:26 ` zhanghailiang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20151110105428.GC2456@work-vm \
--to=dgilbert@redhat.com \
--cc=arei.gonglei@huawei.com \
--cc=eddie.dong@intel.com \
--cc=guijianfeng@cn.fujitsu.com \
--cc=jan.kiszka@siemens.com \
--cc=jasowang@redhat.com \
--cc=lizhijian@cn.fujitsu.com \
--cc=peter.huangpeng@huawei.com \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@redhat.com \
--cc=zhang.zhanghailiang@huawei.com \
--cc=zhangchen.fnst@cn.fujitsu.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).