Successfully reported this slideshow.
Your SlideShare is downloading. ×

Persistent storage tailored for containers

Upcoming SlideShare
Why docker | OSCON 2013
Why docker | OSCON 2013
Loading in …3
×

Check these out next

1 of 43 Ad
1 of 43 Ad
Advertisement

More Related Content

Viewers also liked (20)

Advertisement

Similar to Persistent storage tailored for containers (20)

More from Docker, Inc. (20)

Advertisement

Persistent storage tailored for containers

  1. 1. Persistent storage tailored for containers Quentin “mefyl” Hocquet mefyl@infinit.sh CTO @ Infinit Version 1.2-26-gbcb3c69
  2. 2. Plan Containers and persistent storage Infinit storage platform Dive-in Demo Q&A
  3. 3. Containers and persistent storage Containers are fast, scalable and flexible.
  4. 4. Containers and persistent storage Containers are fast, scalable and flexible. • Fast and easy to start and stop.
  5. 5. Containers and persistent storage Containers are fast, scalable and flexible. • Fast and easy to start and stop. • Fast and easy to scale.
  6. 6. Containers and persistent storage Containers are fast, scalable and flexible. • Fast and easy to start and stop. • Fast and easy to scale. • Unified from development to production.
  7. 7. Containers and persistent storage Containers are fast, scalable and flexible. • Fast and easy to start and stop. • Fast and easy to scale. • Unified from development to production. • Yet customizable for every situation.
  8. 8. Containers and persistent storage Containers are fast, scalable and flexible. • Fast and easy to start and stop. • Fast and easy to scale. • Unified from development to production. • Yet customizable for every situation. However containers tend to be stateless, which can be quite limiting. We need persistent storage for containers.
  9. 9. Containers and persistent storage Containers are fast, scalable and flexible. • Fast and easy to start and stop. • Fast and easy to scale. • Unified from development to production. • Yet customizable for every situation. However containers tend to be stateless, which can be quite limiting. We need persistent storage for containers. • It should be created and started as easily as a container.
  10. 10. Containers and persistent storage Containers are fast, scalable and flexible. • Fast and easy to start and stop. • Fast and easy to scale. • Unified from development to production. • Yet customizable for every situation. However containers tend to be stateless, which can be quite limiting. We need persistent storage for containers. • It should be created and started as easily as a container. • It should be able to scale with your container pool.
  11. 11. Containers and persistent storage Containers are fast, scalable and flexible. • Fast and easy to start and stop. • Fast and easy to scale. • Unified from development to production. • Yet customizable for every situation. However containers tend to be stateless, which can be quite limiting. We need persistent storage for containers. • It should be created and started as easily as a container. • It should be able to scale with your container pool. • It should work the same way for development, tests, production, …
  12. 12. Containers and persistent storage Containers are fast, scalable and flexible. • Fast and easy to start and stop. • Fast and easy to scale. • Unified from development to production. • Yet customizable for every situation. However containers tend to be stateless, which can be quite limiting. We need persistent storage for containers. • It should be created and started as easily as a container. • It should be able to scale with your container pool. • It should work the same way for development, tests, production, … • It should adapt to all situations.
  13. 13. Infinit storage platform Infinit is a storage platform designed with containers in mind providing several APIs: POSIX filesystem, object, block. It aggregates local nodes storage into a single virtual pool.
  14. 14. Infinit storage platform The Infinit platform is truly distributed. There are no leader or followers, all nodes are equal.
  15. 15. Infinit storage platform The Infinit platform is truly distributed. There are no leader or followers, all nodes are equal. • Works the same with 1 or 10k nodes.
  16. 16. Infinit storage platform The Infinit platform is truly distributed. There are no leader or followers, all nodes are equal. • Works the same with 1 or 10k nodes. • No node is a point of failure, no bottleneck.
  17. 17. Infinit storage platform The Infinit platform is truly distributed. There are no leader or followers, all nodes are equal. • Works the same with 1 or 10k nodes. • No node is a point of failure, no bottleneck. • Nodes can come and go: scaling in and out is easy, both capacity and throughput.
  18. 18. Infinit storage platform The Infinit platform is truly distributed. There are no leader or followers, all nodes are equal. • Works the same with 1 or 10k nodes. • No node is a point of failure, no bottleneck. • Nodes can come and go: scaling in and out is easy, both capacity and throughput. • Uniform API from development to production.
  19. 19. Infinit storage platform The Infinit platform is truly distributed. There are no leader or followers, all nodes are equal. • Works the same with 1 or 10k nodes. • No node is a point of failure, no bottleneck. • Nodes can come and go: scaling in and out is easy, both capacity and throughput. • Uniform API from development to production. • Customizable for every setup.
  20. 20. Infinit storage platform The Infinit platform is truly distributed. There are no leader or followers, all nodes are equal. • Works the same with 1 or 10k nodes. • No node is a point of failure, no bottleneck. • Nodes can come and go: scaling in and out is easy, both capacity and throughput. • Uniform API from development to production. • Customizable for every setup. Thus, Infinit: • Can be created and run as seamlessly as a container.
  21. 21. Infinit storage platform The Infinit platform is truly distributed. There are no leader or followers, all nodes are equal. • Works the same with 1 or 10k nodes. • No node is a point of failure, no bottleneck. • Nodes can come and go: scaling in and out is easy, both capacity and throughput. • Uniform API from development to production. • Customizable for every setup. Thus, Infinit: • Can be created and run as seamlessly as a container. • Can scale with you container pool.
  22. 22. Infinit storage platform The Infinit platform is truly distributed. There are no leader or followers, all nodes are equal. • Works the same with 1 or 10k nodes. • No node is a point of failure, no bottleneck. • Nodes can come and go: scaling in and out is easy, both capacity and throughput. • Uniform API from development to production. • Customizable for every setup. Thus, Infinit: • Can be created and run as seamlessly as a container. • Can scale with you container pool. • Is the same in all situations: development, unit tests, production …
  23. 23. Infinit storage platform The Infinit platform is truly distributed. There are no leader or followers, all nodes are equal. • Works the same with 1 or 10k nodes. • No node is a point of failure, no bottleneck. • Nodes can come and go: scaling in and out is easy, both capacity and throughput. • Uniform API from development to production. • Customizable for every setup. Thus, Infinit: • Can be created and run as seamlessly as a container. • Can scale with you container pool. • Is the same in all situations: development, unit tests, production … • Can be configured for each situation: encryption, redundancy, compression, …
  24. 24. How to achieve this Infinit fundamental principles:
  25. 25. How to achieve this Infinit fundamental principles: • Federate all nodes in an overlay network for lookup and routing.
  26. 26. How to achieve this Infinit fundamental principles: • Federate all nodes in an overlay network for lookup and routing. • Store data as blocks in a distributed hashtable (key-value store) with a per-block consensus.
  27. 27. How to achieve this Infinit fundamental principles: • Federate all nodes in an overlay network for lookup and routing. • Store data as blocks in a distributed hashtable (key-value store) with a per-block consensus. • Use cryptographic access control to dispense from any leader.
  28. 28. How to achieve this Infinit fundamental principles: • Federate all nodes in an overlay network for lookup and routing. • Store data as blocks in a distributed hashtable (key-value store) with a per-block consensus. • Use cryptographic access control to dispense from any leader. • Use symmetrical operations to ensure resilience and flexibility.
  29. 29. Dive-in: DHT blocks Because we are symetric and use cryptographic access control, all blocks must be self-certified and ciphered.
  30. 30. Dive-in: DHT blocks Because we are symetric and use cryptographic access control, all blocks must be self-certified and ciphered. • Mutable blocks ◦ Subject to conflicts. ◦ Subject to invalidation. ◦ Hard to certify and cipher.
  31. 31. Dive-in: DHT blocks Because we are symetric and use cryptographic access control, all blocks must be self-certified and ciphered. • Mutable blocks ◦ Subject to conflicts. ◦ Subject to invalidation. ◦ Hard to certify and cipher. • Immutable blocks ◦ No conflicts. ◦ No invalidation: cachable forever. ◦ Easy to certify since content addressable: address = hash(contents).
  32. 32. Dive-in: DHT blocks Because we are symetric and use cryptographic access control, all blocks must be self-certified and ciphered. • Mutable blocks ◦ Subject to conflicts. ◦ Subject to invalidation. ◦ Hard to certify and cipher. • Immutable blocks ◦ No conflicts. ◦ No invalidation: cachable forever. ◦ Easy to certify since content addressable: address = hash(contents). Immutable block are fetchable from any source with permanent on-disk LRU cache.
  33. 33. A file is mostly a mutable block with metadata and a FAT of immutable block. Dive-in: filesystem layer
  34. 34. A file is mostly a mutable block with metadata and a FAT of immutable block. Dive-in: filesystem layer File contents is cachable at will, cheap and atomic writes.
  35. 35. Dive-in: filesystem layer The POSIX API is inherently sequential. We are highly parallel.
  36. 36. Dive-in: filesystem layer Directories prefetching and files look-ahead enables batching and pipelining.
  37. 37. Dive-in: consensus Each block is managed by a specific quorum of node with a variable composition, running multipaxos.
  38. 38. Dive-in: consensus Each block is managed by a specific quorum of node with a variable composition, running multipaxos. No failure point or bottleneck, strong read after write consistency.
  39. 39. Dive-in: overlay The overlay layer is one major customization point of the platform.
  40. 40. Dive-in: overlay The overlay layer is one major customization point of the platform. Algorithm choice: • Several thousands machines: kelips, kademlia, chord. • Few hundreds machines and dozen of terabytes: global knowledge.
  41. 41. Dive-in: overlay The overlay layer is one major customization point of the platform. Algorithm choice: • Several thousands machines: kelips, kademlia, chord. • Few hundreds machines and dozen of terabytes: global knowledge. Data placement: rack-aware, zone-aware, reliability-aware, ensure local copies, ...
  42. 42. Demo! Let's persist that storage!

×