2) What is the solution’s main idea (nugget)?
They build up a shared and centralized storage system by multiplexing application's large-scale I/O across available throughput and latency budget of every disk in cluster. More precisely, they spread data over disks uniformly at a relatively fine grain.
System main components:
The system stores data in blobs and read/write to blob using tracts.
Every disk is managed by a process called tract server.
And the FDS also have a metadata server which maintains track locator table.
3) Why is solution different from previous work?
Previous work also proposes several "flat" storage models, like amazon S3, it has a large overhead from datacenter networks. FDS makes every job using cluster's I/O bandwidth instead of each node's local network bandwidth.
Different from previous research on solving specific problems brought by need for locality, FDS move datacenter back to a flat storage model so that all the "need for locality" issue are gone away.
4) Does the paper (or do you) identify any fundamental/hard trade-offs?
FDS spreads data over disks uniformly at fine grain. It makes the task/job to use all the CPU and cluster resources. However, the task/job failure becomes more frequently, since each task's data is on all the nodes, one fails, all fails. Even though the data recovery speed is fast, it still will have much overhead of job failure recovery.
I think it will have impacts in 10 years. I believe simple is best. To storage system, flat means simple and easy to control.
No comments:
Post a Comment