[Sheepdog] Backup/Images

[Yibin Shen]

Use mmap is much simpler than local backup image, and without
any influence to consistency. but it doesn't improve availability
while whole sheepdog cluster is die(such as some odd network
partition issue).

anyway, if no one againsts, I will try to implement it in the
near future (after we solved most stability issues)

Yibin Shen

On Sun, Oct 9, 2011 at 1:01 AM, MORITA Kazutaka <morita.kazutaka at lab.ntt.co.jp<mailto:morita.kazutaka at lab.ntt.co.jp>> wrote:
At Sat, 8 Oct 2011 11:12:00 +0800,
Yibin Shen wrote:
> we have talked about similar topic in the past weeks.
>
> IMO, let sheepdog support local backup image will promote the availability effectively,
> the local backup image is located in the machine where vm runs,
> then writeback policy is adopted just like what qcow/qcow2's backup image do.
>
> the storage size issue can be solved through decrease the number of copies.
>
> benefits:
> 1)network traffic will be reduced, which will also make corosync work more stable.
> 2)even whole sheepdog cluster crashed, the local image can still provide service.
>
> tradeoffs:
> 1)stronge consistency is damaged for I/O is not triggered synchronously now.
>   to solve this problem, at least we need maintain a journal for local backup image.
> 2)migration of vm will became much more complicated.
>
> so, maybe this is only a transitionary solution before sheepdog archive industry available standard.

Someone suggested a bit similar idea before.  The idea is:

 - A VM use a local mmaped file as a disk cache of a Sheepdog volume.
 - Write requests are regarded as completed when the data are written
  to the mmap address (write-back).
 - If the VM sends a sync request, its response will be blocked until
  the data is replicated to multiple storage nodes.

I think this improves a performance significantly, especially when
network latency is high (e.g. WAN environment).  The data consistency
is not a problem if sync requests ensure that the data is replicated.

To support this idea, we need to support a write-back mode in
Sheepdog; we need to add a sync operation to Sheepdog protocols and
implement bdrv_co_flush() in the Sheepdog QEMU block driver.


Thanks,

Kazutaka

>
>
> Yibin Shen
> On Sat, Oct 8, 2011 at 3:28 AM, Mark Pace <pace at jolokianetworks.com<mailto:pace at jolokianetworks.com><mailto:pace at jolokianetworks.com<mailto:pace at jolokianetworks.com>>> wrote:
>
> On 10/7/2011 1:20 AM, MORITA Kazutaka wrote:
>
>
> - hide quoted text -
>
> Other than the storage size issue, the backup node would be a
> bottleneck if there are many VMs. The backup node requires a huge
> amount of disk space and bandwidth, but if we could use such machine,
> we wouldn't need a clustered storage system. However, on a small
> cluster environment with a few nodes, the backup node idea looks good.
> If someone sends a patch to support it, I'll accept it.  Thanks,
> Kazutaka
>
>
> I'm not sure I agree.  Shared storage is a single point of failure and
> the reason we're looking to Sheepdog is the ability to survive a shared
> storage outage.  Pumping a shared storage box up to provide a backup
> location is not nearly as expensive as creating a redundant/replicated
> shared storage environment that is capable of serving virtual machines
> properly.  But, that being said, your absolutely correct in that machine
> is going to be beefy in large environments, etc.
>
> Now, I'm not a programmer, but would happily pay for someone to write it
> -- if anyone is interested, please contact me.
>
>
> Mark Pace
--
sheepdog mailing list
sheepdog at lists.wpkg.org<mailto:sheepdog at lists.wpkg.org>
http://lists.wpkg.org/mailman/listinfo/sheepdog


________________________________

This email (including any attachments) is confidential and may be legally privileged. If you received this email in error, please delete it immediately and do not copy it or use it for any purpose or disclose its contents to any other person. Thank you.

本电邮(包括任何附件)可能含有机密资料并受法律保护。如您不是正确的收件人，请您立即删除本邮件。请不要将本电邮进行复制并用作任何其他用途、或透露本邮件之内容。谢谢。
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.wpkg.org/pipermail/sheepdog/attachments/20111009/53a3aa9c/attachment-0003.html>