4. Containers and persistent storage
Containers are fast, scalable and flexible.
• Fast and easy to start and stop.
5. Containers and persistent storage
Containers are fast, scalable and flexible.
• Fast and easy to start and stop.
• Fast and easy to scale.
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. 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. 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. 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. 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. 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. 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. 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. Infinit storage platform
The Infinit platform is truly distributed. There are no leader or followers, all nodes are equal.
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. 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. 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. 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. 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. 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. 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. 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. 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, …
25. How to achieve this
Infinit fundamental principles:
• Federate all nodes in an overlay network for lookup and routing.
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. 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. 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.
30. Dive-in: DHT blocks
Because we are symetric and use cryptographic access control, all blocks must be self-certified and ciphered.
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.
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).
33. 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.
34. A file is mostly a mutable block with
metadata and a FAT of immutable
block.
Dive-in: filesystem layer
35. 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.
38. Dive-in: consensus
Each block is managed by a specific quorum of node with a variable composition, running multipaxos.
39. 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.
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.
42. 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, ...