Ask Your Question
0

Can Swift function well if some zones have a slow or less reliable network connection?

asked 2011-06-15 18:28:03 -0500

david-kranz gravatar image

The description of zones implies that they could be separated geographically, which could be desirable for more protection against loss of an entire data center. In such a deployment, some connections between the proxies and storage nodes, or between storage nodes, could be somewhat slow or unreliable. How well does Swift handle such a situation? Is it reasonable to use this kind of deployment to protect against loss of an entire data center or is some higher-level replication needed? What are the performance requirements of the storage network?

edit retag flag offensive close merge delete

3 answers

Sort by ยป oldest newest most voted
0

answered 2011-06-20 13:14:43 -0500

david-kranz gravatar image

Thanks for the clear answer. I looked at the blueprint for container sync. Is there a more detailed description of this functionality somewhere?

edit flag offensive delete link more
0

answered 2011-06-18 00:37:04 -0500

gholt gravatar image

This is uncharted territory. There have been discussions around doing such a thing, but the software wasn't designed with differing performance characteristics across zones -- of course, it could certainly have its design improved to do so, at the cost of complexity.

Of the many things to consider is performance: When an object GET comes in, it is routed randomly to one of the three replicas in the system. With slower zones, one or even all of the replicas might be on the slow zones. Swift would need to be enhanced to understand fast vs. slow and try to distribute writes to be on both (with maybe the slow ones happening in the background) and distribute reads to the fast and fall back to the slow.

For a different solution, the upcoming container sync feature may fill the gap. Container sync simply sends updates from one container to another, presumably on different clusters. One might run two clusters each running with 2 replicas and then sync the two. There would be 4 total replicas, which means higher cost. The performance requirements would be met by using the cluster closest to a given client and falling back to the other cluster.

The main benefit of the container sync approach is that the Swift core is altered only slightly and the vast majority of the new complexity is contained within the sync feature itself. This keeps any new bugs outside of the standard Swift usage.

edit flag offensive delete link more
0

answered 2011-06-20 18:56:07 -0500

gholt gravatar image

Well, I haven't had time to get everything in order yet. But there is this:

https://dl-web.dropbox.com/get/Public/consync/Swift%20Container%20Sync.pdf?w=1835cb5d (https://dl-web.dropbox.com/get/Public...)

And of course the code itself:

https://code.launchpad.net/~gholt/swift/consync/+merge/63317 (https://code.launchpad.net/~gholt/swi...)

But it will need documentation before it goes out.

edit flag offensive delete link more

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Get to know Ask OpenStack

Resources for moderators

Question Tools

1 follower

Stats

Asked: 2011-06-15 18:28:03 -0500

Seen: 44 times

Last updated: Jun 20 '11