tahoe-lafs/trac-2024-07-25
2
0
Issues 1.1k Wiki Activity

link to wiki page on server selection 

[Imported from Trac: page FAQ, version 72]
zooko 2012-04-18 21:54:14 +00:00
parent 08f8b2fb91
commit 60d6df911f
1 changed files with 3 additions and 9 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

12
FAQ.md

@ -71,18 +71,12 @@ This is great for long-term servers, but can cause a problem right then the node
**<a name="Q12_server_location_distribution">Q12:</a> If I had 3 locations each with 5 storage nodes, could I configure the grid to ensure a file is written to each location so that I could handle all servers at a particular location going down?**
A: Not directly. We have a ticket about that one (#467, #302), but it's deeper than it looks and we haven't come to a conclusion on how to
A: Not directly. We have [a wiki page](ServerSelection) and some tickets (linked from the wiki page) about this but it's deeper than it looks and we haven't come to a conclusion on how to
build it.
The current system will try to distribute the shares as widely as possible, using a different pseudo-random permutation for each file, but
it is completely unaware of server properties like "location". If you have more free servers than shares, it will only put one share on any
given server, but you might wind up with more shares in one location
than the others.
The current system will try to distribute the shares as widely as possible, using a different pseudo-random permutation for each file, but it is completely unaware of server properties like "location". If you have more free servers than shares, it will only put one share on any given server, but you might wind up with more shares in one location than the others.
For example, if you have 15 servers in three locations A:1/2/3/4/5, B:6/7/8/9/10, C:11/12/13/14/15, and use the default `3-of-10` encoding,
your worst case is winding up with shares on 1/2/3/4/5/6/7/8/9/10, and not use location C at all. The most *likely* case is that you'll wind up
with 3 or 4 shares in each location, but there's nothing in the system to enforce that: it's just shuffling all the servers into a ring,
starting at 0, and assigning shares to servers around and around the ring until all the shares have a home.
For example, if you have 15 servers in three locations A:1/2/3/4/5, B:6/7/8/9/10, C:11/12/13/14/15, and use the default `3-of-10` encoding, your worst case is winding up with shares on 1/2/3/4/5/6/7/8/9/10, and not use location C at all. The most *likely* case is that you'll wind up with 3 or 4 shares in each location, but there's nothing in the system to enforce that: it's just shuffling all the servers into a ring, starting at 0, and assigning shares to servers around and around the ring until all the shares have a home.
The possible distributions of shares into locations (A, B, C) are: