doc/architecture/storage.html.textile.liquid

   1 ---
   2 layout: default
   3 navsection: architecture
   4 title: Introduction to Keep
   5 ...
   6 {% comment %}
   7 Copyright (C) The Arvados Authors. All rights reserved.
   8
   9 SPDX-License-Identifier: CC-BY-SA-3.0
  10 {% endcomment %}
  11
  12 Keep is a content-addressable storage system that yields high performance for I/O-bound workloads. Keep is designed to run on low-cost commodity hardware or cloud services and is tightly integrated with the rest of the Arvados system. It provides high fault tolerance and high aggregate performance to a large number of clients.
  13
  14 h2. Design goals and core features
  15
  16 * *Scale* - Keep installations are managing petabytes of data today. Keep scales horizontally.
  17
  18 * *Data deduplication* - Keep automatically deduplicates data through its use of content addressing.
  19
  20 * *Flexibility* - Keep can store data in S3, S3-compatible storage systems (e.g. Ceph) and Azure blob storage. Keep can also store data on POSIX file systems.
  21
  22 * *Fault-Tolerance* - Errors and failure are expected. Keep has redundancy and recovery capabilities at its core.
  23
  24 * *Optimized for Aggregate Throughput* - Like S3 and Azure blob storage, Keep is optimized for aggregate throughput. This is optimal in a scenario with many reader/writer processes.
  25
  26 * *Complex Data Management* - Keep operates well in environments where there are many independent users accessing the same data or users who want to organize data in many different ways. Keep facilitates data sharing without expecting users either to agree with one another about directory structures or to create redundant copies of the data.
  27
  28 * *Security* - Keep works well combined with encryption at rest and transport encryption. All data is managed through @collection@ objects, which implement a rich "permission model":{{site.baseurl}}/api/permission-model.html.
  29
  30 h2. How Keep works
  31
  32 Keep is a content-addressable file system.  This means that files are managed using special unique identifiers derived from the _contents_ of the file (specifically, the MD5 hash), rather than human-assigned file names.  This has a number of advantages:
  33 * Files can be stored and replicated across a cluster of servers without requiring a central name server.
  34 * Both the server and client systematically validate data integrity because the checksum is built into the identifier.
  35 * Data duplication is minimized—two files with the same contents will have in the same identifier, and will not be stored twice.
  36 * It avoids data race conditions, since an identifier always points to the same data.
  37
  38 In Keep, information is stored in @data blocks@.  Data blocks are normally between 1 byte and 64 megabytes in size.  If a file exceeds the maximum size of a single data block, the file will be split across multiple data blocks until the entire file can be stored.  These data blocks may be stored and replicated across multiple disks, servers, or clusters.  Each data block has its own identifier for the contents of that specific data block.
  39
  40 In order to reassemble the file, Keep stores a @collection@ manifest which lists in sequence the data blocks that make up the original file.  A @manifest@ may store the information for multiple files, including a directory structure. See "manifest format":{{site.baseurl}}/architecture/manifest-format.html for more information on how manifests are structured.