Project

General

Profile

Keep Proxy Specification » History » Version 1

Peter Amstutz, 04/28/2014 10:16 AM

1 1 Peter Amstutz
h1. Reverse Keep Proxy
2
3
h2. Problem
4
5
Need to be able to automatically upload huge (+1 TiB) datasets into Arvados.  Current proposed solution is to upload the data to a staging area and then put the data into Keep.  On further consideration, this solution is inadequate for a number of reasons:
6
* Must set aside staging area big enough to accommodate large uploads.
7
* When uploads are not occurring, this empty space just sits around, costing money.
8
* Amazon has a 1 TiB limit on EBS volumes, which means we can't accept +1 TiB datasets, unless we create a volume-spanning partitions
9
* Multiple users uploading to the same staging partition can end up in a starvation deadlock when if the volume fills up.
10
* Some of these problems could be addressed by allocating/deallocating volumes on the fly, but this adds significant complexity.
11
* Once data is uploaded, it still needs to be copied into Keep, which adds additional wait time from when the data is uploaded to when the data is actually ready to use.
12
13
h2. Solution
14
15
Provide a Keep client that sends blocks to a reverse Keep proxy, which forwards the blocks to appropriate internal Keep servers.  
16
* Doesn't require staging except in RAM of the Keep proxy.
17
* No dataset limits except Keep's overall capacity
18
* Fewer contention problems (although many uploaders could overwhelm the proxy node...)
19
* Data is available immediately once upload is completed
20
* This is the right thing to do in the long term anyway.  We shouldn't waste our time with messy hacks.
21
22
h2. Approach
23
24
Uploading functionality already largely exists