Keep server » History » Version 7
Tom Clegg, 04/08/2014 11:13 AM
1 | 7 | Tom Clegg | h1. Keep server |
---|---|---|---|
2 | 1 | Tom Clegg | |
3 | 7 | Tom Clegg | This page describes the Keep backing store server component, keepd. |
4 | 1 | Tom Clegg | |
5 | {{toc}} |
||
6 | |||
7 | See also: |
||
8 | 7 | Tom Clegg | * [[Keep]] (overview, design goals, client/server responsibilities, intro to content addressing) |
9 | 5 | Tim Pierce | * [[Keep manifest format]] |
10 | * [[Keep index]] |
||
11 | * source:services/keep (implementation: in progress) |
||
12 | |||
13 | 4 | Tom Clegg | h2. Todo |
14 | |||
15 | 5 | Tim Pierce | * Implement server daemon (*in progress*) |
16 | * Implement integration test suite (*in progress*) |
||
17 | 4 | Tom Clegg | * Spec public/private key format and deployment mechanism |
18 | * Spec permission signature format |
||
19 | * Spec event-reporting API |
||
20 | * Spec quota mechanism |
||
21 | |||
22 | 2 | Tom Clegg | h2. Responsibilities |
23 | |||
24 | * Read and write blobs on disk |
||
25 | * Enforce maximum blob size |
||
26 | * Enforce key=hash(value) during read and write |
||
27 | * Enforce permissions when reading data (according to permissions on Collections in the metadata DB) |
||
28 | * Enforce usage quota when writing data |
||
29 | * Delete blobs (only when requested by data manager!) |
||
30 | * Report read/write/exception events |
||
31 | * Report free space |
||
32 | 3 | Tom Clegg | * Report hardware status (SMART) |
33 | 2 | Tom Clegg | |
34 | h2. Other parties |
||
35 | |||
36 | * Client distributes data across the available Keep servers (using the content hash) |
||
37 | * Client attains initial replication level when writing blobs (by writing to multiple Keep servers) |
||
38 | * Data manager decides which blobs to delete (e.g., garbage collection, rebalancing) |
||
39 | |||
40 | 1 | Tom Clegg | h2. Discovering Keep server URIs |
41 | |||
42 | * @GET https://endpoint/arvados/v1/keep_disks@ |
||
43 | * see http://doc.arvados.org/api/schema/KeepDisk.html |
||
44 | * Currently "list of Keep servers" is "list of unique {host,port} across all Keep disks". (Could surely be improved.) |
||
45 | |||
46 | h2. Supported methods |
||
47 | |||
48 | For storage clients |
||
49 | * GET /hash |
||
50 | * GET /hash?checksum=true → verify checksum before sending |
||
51 | * POST / (body=content) → hash |
||
52 | * PUT /hash (body=content) → hash |
||
53 | * HEAD /hash → does it exist here? |
||
54 | * HEAD /hash?checksum=true → read the data and verify checksum |
||
55 | |||
56 | For system (monitoring, indexing, garbage collection) |
||
57 | * DELETE /hash → delete all copies of this blob (requires privileged token!) |
||
58 | 4 | Tom Clegg | * GET /index.txt → get full list of blocks stored here, including size [and whether it was PUT recently?] (requires privileged token) |
59 | * GET /state.json → get list of backing filesystems, disk fullness, IO counters, perhaps recent IO statistics (requires privileged token) |
||
60 | 1 | Tom Clegg | |
61 | h2. Authentication |
||
62 | |||
63 | * Client provides API token in Authorization header |
||
64 | * Config knob to ignore authentication & permissions (for fully-shared site, and help transition from Keep1) |
||
65 | |||
66 | h2. Permission |
||
67 | |||
68 | A signature token, unique to a {blob_hash, arvados_api_token, expiry_time}, establishes permission to read a block. |
||
69 | |||
70 | The controller and each Keep server has a private key. Everyone can know the public keys (but only the controller and keep servers need to know them; clients don't need to verify signatures). |
||
71 | |||
72 | Writing: |
||
73 | * If the given hash and content agree, whether or not a disk write is required, Keep server creates a +Asignature@expirytime portion to the returned blob locator. |
||
74 | * The API server @collections.create@ method verifies signatures before giving the current user can_read permission on the collection. |
||
75 | 4 | Tom Clegg | * A suitably intelligent client can notice that the expirytimes on its blob hashes are getting old, and refresh them by generating a partial manifest, calling @collections.create@ followed by @collections.get@, and optionally deleting the partial manifest(s) when the full manifest is written. If extra partial manifests are left around, garbage collection will take care of them eventually; the only odd side effect is the existence of partial manifests. *(Should there be a separate "refresh all of these tokens for me" API call to avoid creating these intermediate manifests?)* |
76 | 1 | Tom Clegg | |
77 | Reading: |
||
78 | * The API server @collections.get@ method returns two manifests. One has plain hashes (this is the one whose content hash is the collection UUID). The other has a @+Asignature@expirytime@ portion on each blob locator. |
||
79 | * Keep server verifies signatures before honoring @GET@ requests. |
||
80 | * The signature might come from either the Keep node itself, a different Keep node, or the API server. |
||
81 | * A suitably intelligent client can notice that the expirytime on its blob hashes is too old, and request a fresh set via @collections.get@. |