[Sheepdog] Backup/Images

[MORITA Kazutaka]

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