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

write down my notes on a first plan for accounting and non-generic introduction 

[Imported from Trac: page QuotaManagement, version 1]
warner 2007-12-15 00:51:43 +00:00
parent 343df97ac6
commit 9fa0b9a975
1 changed files with 47 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

47
QuotaManagement.md Normal file

@ -0,0 +1,47 @@
Here's a basic plan for how to configure "managed introducers". The basic
idea is that we have two types of grids: managed and unmanaged. The current
code implements "unmanaged" grids: complete free-for-all, anyone who can get
to the Introducer can thus get to all the servers, anyone who can get to a
server gets to use as much space as they want. In this mode, each client uses
their 'introducer.furl' to connect to the the Introducer, which serves two
purposes: tell the client about all the servers they can use, and tell all
other clients about the server being offered by the new node.
The "managed introducer" approach is for an environment where you want to be
able to keep track of who is using what, and to prevent unmanaged clients
from using any storage space.
In this mode, we have an Account Manager instead of an Introducer. Each
client gets a special, distinct facet on this account manager: this gives
them control over their account, and allows them to access the storage space
enabled by virtue of having that account. This is stored in
"my-account.furl", which replaces "introducer.furl" for this purpose.
In addtion, the servers get an "account-manager.furl" instead of an
"introducer.furl". The servers connect to this object and offer themselves as
storage servers. The Account Manager remembers a list of all the
currently-available storage servers.
When a client wants more storage servers (perhaps updated periodically, and
perhaps using some sort of minimal update protocol (Bloom Filters!)), they
contact their Account object and ask for introductions to storage servers.
This causes the Account Manager to go to all servers that the client doesn't
already know about and tell them "generate a FURL to a facet for the benefit
of client 123. Give me that FURL.". The Account Manager then sends the list
of new FURLs to the client, who adds them to its peerlist. This peerlist
contains tuples of (nodeid, FURL).
The Storage Server will grant a facet to anyone that the Account Manager
tells them to. The Storage Server is really just updating a table that maps
from a random number (the FURL's swissnum) to the system-wide small-integer
account number. The FURL will dereference to an object that adds an
accountNumber=123 to all write() calls, so that they can be stored in leases.
In this approach, the Account Manager is a bottleneck only for the initial
contact: the clients all remember their list of Storage Server FURLs for a
long time. Clients must contact their Account to take advantage of new
servers: the update traffic for this needs to be examined. I can imagine this
working reasonably well up to a few hundred servers and say 100k clients if
the clients are only asking about new servers once a day (one query per
second).