Keep server » History » Version 4
Tom Clegg, 02/24/2014 03:36 PM
1 | 1 | Tom Clegg | h1. Keep server |
---|---|---|---|
2 | |||
3 | This page describes the Keep backing store server component, keepd. |
||
4 | |||
5 | {{toc}} |
||
6 | |||
7 | See also: |
||
8 | * [[Keep manifest format]] |
||
9 | * [[Keep index]] |
||
10 | * source:services/keepd (implementation: imminent) |
||
11 | |||
12 | 4 | Tom Clegg | h2. Todo |
13 | |||
14 | * Implement server daemon |
||
15 | * Implement integration test suite |
||
16 | * Spec public/private key format and deployment mechanism |
||
17 | * Spec permission signature format |
||
18 | * Spec event-reporting API |
||
19 | * Spec quota mechanism |
||
20 | |||
21 | 2 | Tom Clegg | h2. Responsibilities |
22 | |||
23 | * Read and write blobs on disk |
||
24 | * Enforce maximum blob size |
||
25 | * Enforce key=hash(value) during read and write |
||
26 | * Enforce permissions when reading data (according to permissions on Collections in the metadata DB) |
||
27 | * Enforce usage quota when writing data |
||
28 | * Delete blobs (only when requested by data manager!) |
||
29 | * Report read/write/exception events |
||
30 | * Report free space |
||
31 | 3 | Tom Clegg | * Report hardware status (SMART) |
32 | 2 | Tom Clegg | |
33 | h2. Other parties |
||
34 | |||
35 | * Client distributes data across the available Keep servers (using the content hash) |
||
36 | * Client attains initial replication level when writing blobs (by writing to multiple Keep servers) |
||
37 | * Data manager decides which blobs to delete (e.g., garbage collection, rebalancing) |
||
38 | |||
39 | 1 | Tom Clegg | h2. Discovering Keep server URIs |
40 | |||
41 | * @GET https://endpoint/arvados/v1/keep_disks@ |
||
42 | * see http://doc.arvados.org/api/schema/KeepDisk.html |
||
43 | * Currently "list of Keep servers" is "list of unique {host,port} across all Keep disks". (Could surely be improved.) |
||
44 | |||
45 | h2. Supported methods |
||
46 | |||
47 | For storage clients |
||
48 | * GET /hash |
||
49 | * GET /hash?checksum=true → verify checksum before sending |
||
50 | * POST / (body=content) → hash |
||
51 | * PUT /hash (body=content) → hash |
||
52 | * HEAD /hash → does it exist here? |
||
53 | * HEAD /hash?checksum=true → read the data and verify checksum |
||
54 | |||
55 | For system (monitoring, indexing, garbage collection) |
||
56 | * DELETE /hash → delete all copies of this blob (requires privileged token!) |
||
57 | 4 | Tom Clegg | * GET /index.txt → get full list of blocks stored here, including size [and whether it was PUT recently?] (requires privileged token) |
58 | * GET /state.json → get list of backing filesystems, disk fullness, IO counters, perhaps recent IO statistics (requires privileged token) |
||
59 | 1 | Tom Clegg | |
60 | h2. Authentication |
||
61 | |||
62 | * Client provides API token in Authorization header |
||
63 | * Config knob to ignore authentication & permissions (for fully-shared site, and help transition from Keep1) |
||
64 | |||
65 | h2. Permission |
||
66 | |||
67 | A signature token, unique to a {blob_hash, arvados_api_token, expiry_time}, establishes permission to read a block. |
||
68 | |||
69 | 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). |
||
70 | |||
71 | Writing: |
||
72 | * 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. |
||
73 | * The API server @collections.create@ method verifies signatures before giving the current user can_read permission on the collection. |
||
74 | 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?)* |
75 | 1 | Tom Clegg | |
76 | Reading: |
||
77 | * 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. |
||
78 | * Keep server verifies signatures before honoring @GET@ requests. |
||
79 | * The signature might come from either the Keep node itself, a different Keep node, or the API server. |
||
80 | * A suitably intelligent client can notice that the expirytime on its blob hashes is too old, and request a fresh set via @collections.get@. |