source: trunk/docs/proposed/old-accounts-introducer.txt

Last change on this file was 5f2f95a, checked in by Brian Warner <warner@…>, at 2009-03-24T01:54:57Z

docs/proposed: move old accounting docs out of the way

  • Property mode set to 100644
File size: 7.0 KB
Line 
1This is a proposal for handing accounts and quotas in Tahoe. Nothing is final
2yet.. we are still evaluating the options.
3
4
5= Account Management: Introducer-based =
6
7A Tahoe grid can be configured in several different modes. The simplest mode
8(which is also the default) is completely permissive: all storage servers
9will accept shares from all clients, and no attempt is made to keep track of
10who is storing what. Access to the grid is mostly equivalent to having access
11to the Introducer (or convincing one of the existing members to give you a
12list of all their storage server FURLs).
13
14This mode, while a good starting point, does not accomodate any sort of
15auditing or quota management. Even in a small friendnet, operators might like
16to know how much of their storage space is being consumed by Alice, so they
17might be able to ask her to cut back when overall disk usage is getting to
18high. In a larger commercial deployment, a service provider needs to be able
19to get accurate usage numbers so they can bill the user appropriately. In
20addition, the operator may want the ability to delete all of Bob's shares
21(i.e. cancel any outstanding leases) when he terminates his account.
22
23There are several lease-management/garbage-collection/deletion strategies
24possible for a Tahoe grid, but the most efficient ones require knowledge of
25lease ownership, so that renewals and expiration can take place on a
26per-account basis rather than a (more numerous) per-share basis.
27
28== Accounts ==
29
30To accomplish this, "Accounts" can be established in a Tahoe grid. There is
31nominally one account per human user of the grid, but of course a user might
32use multiple accounts, or an account might be shared between multiple users.
33The Account is the smallest unit of quota and lease management.
34
35Accounts are created by an "Account Manager". In a commercial network there
36will be just one (centralized) account manager, and all storage nodes will be
37configured to require a valid account before providing storage services. In a
38friendnet, each peer can run their own account manager, and servers will
39accept accounts from any of the managers (this mode is permissive but allows
40quota-tracking of non-malicious users).
41
42The account manager is free to manage the accounts as it pleases. Large
43systems will probably use a database to correlate things like username,
44storage consumed, billing status, etc.
45
46== Overview ==
47
48The Account Manager ("AM") replaces the normal Introducer node: grids which
49use an Account Manager will not run an Introducer, and the participating
50nodes will not be configured with an "introducer.furl".
51
52Instead, each client will be configured with a different "account.furl",
53which gives that client access to a specific account. These account FURLs
54point to an object inside the Account Manager which exists solely for the
55benefit of that one account. When the client needs access to storage servers,
56it will use this account object to acquire personalized introductions to a
57per-account "Personal Storage Server" facet, one per storage server node. For
58example, Alice would wind up with PSS[1A] on server 1, and PSS[2A] on server
592. Bob would get PSS[1B] and PSS[2B].
60
61These PSS facets provide the same remote methods as the old generic SS facet,
62except that every time they create a lease object, the account information of
63the holder is recorded in that lease. The client stores a list of these PSS
64facet FURLs in persistent storage, and uses them in the "get_permuted_peers"
65function that all uploads and downloads use to figure out who to talk to when
66looking for shares or shareholders.
67
68Each Storage Server has a private facet that it gives to the Account Manager.
69This facet allows the AM to create PSS facets for a specific account. In
70particular, the AM tells the SS "please create account number 42, and tell me
71the PSS FURL that I should give to the client". The SS creates an object
72which remembers the account number, creates a FURL for it, and returns the
73FURL.
74
75If there is a single central account manager, then account numbers can be
76small integers. (if there are multiple ones, they need to be large random
77strings to ensure uniqueness). To avoid requiring large (accounts*servers)
78lookup tables, a given account should use the same identifer for all the
79servers it talks to. When this can be done, the PSS and Account FURLs are
80generated as MAC'ed copies of the account number.
81
82More specifically, the PSS FURL is a MAC'ed copy of the account number: each
83SS has a private secret "S", and it creates a string "%d-%s" % (accountnum,
84b2a(hash(S+accountnum))) to use as the swissnum part of the FURL. The SS uses
85tub.registerNameLookupHandler to add a function that tries to validate
86inbound FURLs against this scheme: if successful, it creates a new PSS object
87with the account number stashed inside. This allows the server to minimize
88their per-user storage requirements but still insure that PSS FURLs are
89unguessable.
90
91Account FURLs are created by the Account Manager in a similar fashion, using
92a MAC of the account number. The Account Manager can use the same account
93number to index other information in a database, like account status, billing
94status, etc.
95
96The mechanism by which Account FURLs are minted is left up to the account
97manager, but the simple AM that the 'tahoe create-account-manager' command
98makes has a "new-account" FURL which accepts a username and creates an
99account for them. The 'tahoe create-account' command is a CLI frontend to
100this facility. In a friendnet, you could publish this FURL to your friends,
101allowing everyone to make their own account. In a commercial grid, this
102facility would be reserved use by the same code which handles billing.
103
104
105== Creating the Account Manager ==
106
107The 'tahoe create-account-manager' command is used to create a simple account
108manager node. When started, this node will write several FURLs to its
109private/ directory, some of which should be provided to other services.
110
111 * new-account.furl : this FURL allows the holder to create new accounts
112 * manage-accounts.furl : this FURL allows the holder to list and modify
113                          all existing accounts
114 * serverdesk.furl : this FURL is used by storage servers to make themselves
115                     available to all account holders
116
117
118== Configuring the Storage Servers ==
119
120To use an account manager, each storage server node should be given access to
121the AM's serverdesk (by simply copying "serverdesk.furl" into the storage
122server's base directory). In addition, it should *not* be given an
123introducer.furl . The serverdesk FURL tells the SS that it should allow the
124AM to create PSS facets for each account, and the lack of an introducer FURL
125tells the SS to not make its generic SS facet available to anyone. The
126combination means that clients must acquire PSS facets instead of using the
127generic one.
128
129== Configuring Clients ==
130
131Each client should be configured to use a specific account by copying their
132account FURL into their basedir, in a file named "account.furl". In addition,
133these client nodes should *not* have an "introducer.furl". This combination
134tells the client to ask the AM for ...
Note: See TracBrowser for help on using the repository browser.