#1838 new enhancement

Add StorageLocation hint to Storage Server — at Version 6

Reported by: PRabahy Owned by: davidsarah
Priority: normal Milestone: undecided
Component: code-storage Version: 1.9.2
Keywords: storage location Cc:
Launchpad Bug:

Description (last modified by zooko)

I'm new to Tahoe, so sorry if I don't use all the correct terminology.

I believe that the Storage Server could be enhanced to announce a hint to where it stores its data. This will allow a Client to more intelligently choose which Storage Servers it chooses to trust with its data (#467, #573).

On ServerSelection it looks like Brian already thought about this: "I'd love to be able to get stronger diversity among hosts, racks, or data centers, but I don't yet know how to get that and get the properties listed above, while keeping the filecaps small."

My ideas that when a Client first connects to a Storage Server, the Storage Server can respond with a special string that describes where it believe that it is storing the data it receives. For example, any server that is using the S3 backend (#999) could reply "S3" while any server using the Google Drive backend (#1831) could reply "Google". A datacenter admin could set all of their servers to reply "ABC_DataCenter".

These hints would be non-authoritative because any Storage Server could easily lie about where it is storing the data, but even if all Storage Server were lying it would be no worse than today. The rogue Storage Servers could collude to say they were all using the same storage location, but then the Client would just avoid using more than one of the rogue servers. The rouge Storage Servers could also collude to say the were all using different storage locations (even though the were in the same location), but that simply trick the client back into the current behavior.

Finally, by adhering to a convention and parsing the string, a hierarchy of locations could be made. For example a company has 2 data centers so they set the hint for their servers as "ABC_DC1_RACK1", "ABC_DC1_RACK2", "ABC_DC2_RACK1", "ABC_DC2_RACK2", etc. (Related discussion pipermail/tahoe-dev/2009-April/001555.html)

Change History (6)

comment:1 Changed at 2012-11-01T23:05:11Z by davidsarah

  • Component changed from unknown to code-storage
  • Keywords storage location added

comment:2 Changed at 2012-11-02T16:55:07Z by PRabahy

  • Description modified (diff)

comment:3 Changed at 2013-06-28T04:19:10Z by nejucomo

  • Description modified (diff)

This may be useful to implement the "universal cap" use case: #2009

comment:4 Changed at 2013-08-21T03:09:12Z by zooko

Please read #2059, which had a succinct specification by markberger. Please also read #573, which had a lot of useful content.

comment:5 Changed at 2014-02-04T12:14:58Z by zooko

Project Voldemort is a distributed key-value store made by linkedin and used at scale in linkedin. They have a well-trodden solution for this kind of issue, described here: https://github.com/voldemort/voldemort/wiki/Topology-awareness-capability

comment:6 Changed at 2014-02-04T12:16:07Z by zooko

  • Description modified (diff)
Note: See TracTickets for help on using tickets.