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 |