Network Configurations

There are several ways that people might want to use Tahoe-LAFS. We're not necessarily committed to satisfying all of these use cases -- these are just possibilities.

As these network configurations develop, the node roles section develops in complement.

name	typical number of nodes	administrative domains	node capacity	node availability	churn
non-RAID	1 host, multiple nodes	one	potentially mixed	uniform	low
friendnet	2-25	many domains, but all trusted	mixed	mixed	low
sneakernet (#1657)	2-10	many domains, but all trusted	mixed	low	low
commercial service	1 server per customer	one domain for servers, many for clients	as required	high	low
private grid	2-10	one domain	mixed	mixed	medium
hivecache	10-1000	one domain, but not as well controlled	somewhat uniform	high	low
customer-to-customer	10-10,000	many	mixed	mixed	medium
global grid	any	many	mixed	mixed	high

• non-RAID: Turn the traditional redundancy stack on its head, applying filesystem-redundancy-crypto-filesystem by running a storage node on each disk. Has the advantages over RAID that storage is encrypted, any mix of capacities is fine, redundancy is freely selectable per file, and recovery does not require entire disks.
• friendnet: You and your friends share a virtual filesystem. It remains accessible even when some of your friends' computers are unreachable. Your friends can't see your files by default, but you can share individual files and directories with individual friends or with all friends.
• sneakernet: see #1657
• commercial service -- 1x upload: Pay a company such as ​Least Authority Enterprises $1/GB/month, say, and you can store your stuff on a grid they set up for you.
• private grid: Run your own grid by buying a few servers, so that you can backup your own stuff on it.
• hivecache: Install a tahoe node on each of the workstations in your office, turning their unused disk space into a giant storage pool.
• customer-to-customer: A company provides a shared grid for its customers using space on the customers' computers. (This would have to overcome obstacles of firewalls and limited upload bandwidth.)
• global grid: A large, diverse ecosystem of people and organizations who want a storage grid with extremely high reliability and availability.
• website hosting: One or more grids providing hosting and execution of web applications by means of out-of-the-box web server software to serve files from one or more dircaps. see #2144.

See also the ServerSelection page.

Node Roles

Network configurations can usually be thought of in terms of a topology connecting particular node roles. These roles often fulfill the same abstraction across network configurations. By allowing specialized role configurations, a plethora of custom network configurations can be deployed without modifying the code.

Here are some archetypal roles:

• The Available Migrator consumes storage from a changing address.
  • Migration Pattern Availability - Availability is high, but address changes are frequent.
  • Examples: Laptops, mobile devices, poor DHCP configurations.
  • We think that the foolscap/introducer mechanism will dynamically adjust to the changing IP address and make this appear to be a server with good availability, but this use case hasn't been much tested. Please let us know if you try it.

• The Ephemeral Consumer consumes storage, but lacks availability.
  • Poor availability - Availability is low, such as a node that is only up when consuming storage service.
  • Examples: Backup service customer.
  • Hints:
    • Set 'no_storage' config option.

• A Grid Storage Server provides storage but does not consume it.
  • High Availability - An individual file's availability is largely dependent on average storage availability.
  • Remote Control - Typically a provider configures many nodes through a centralized manner for convenience.
  • Non Consumer - Specialized storage providers do not consume storage services.

• A Grid Manager does not provide storage services but controls storage server.