21701: Reject requests with unused non-empty manifest_text.
[arvados.git] / doc / admin / storage-classes.html.textile.liquid
1 ---
2 layout: default
3 navsection: admin
4 title: Configuring storage classes
5 ...
6
7 {% comment %}
8 Copyright (C) The Arvados Authors. All rights reserved.
9
10 SPDX-License-Identifier: CC-BY-SA-3.0
11 {% endcomment %}
12
13 Storage classes (alternately known as "storage tiers") allow you to control which volumes should be used to store particular collection data blocks.  This can be used to implement data storage policies such as moving data to archival storage.
14
15 In the default Arvados configuration, with no storage classes specified in the configuration file, all volumes belong to a single implicit storage class called "default". Apart from that, names of storage classes are internal to the cluster and decided by the administrator.  Other than the implicit "default" class, Arvados currently does not define any standard storage class names.
16
17 To use multiple storage classes, update the @StorageClasses@ and @Volumes@ sections of your configuration file.
18 * Every storage class you use (including "default") must be defined in the @StorageClasses@ section.
19 * The @StorageClasses@ section must use @Default: true@ to indicate at least one default storage class. When a client/user does not specify storage classes when creating a new collection, the default storage classes are used implicitly.
20 * If some storage classes are faster or cheaper to access than others, assign a higher @Priority@ to the faster ones. When reading data, volumes with high priority storage classes are searched first.
21
22 Example:
23
24 <pre>
25     StorageClasses:
26
27       default:
28         # When reading a block that is stored on multiple volumes,
29         # prefer a volume with this class.
30         Priority: 20
31
32         # When a client does not specify a storage class when saving a
33         # new collection, use this one.
34         Default: true
35
36       archival:
37         Priority: 10
38
39     Volumes:
40
41       ClusterID-nyw5e-000000000000000:
42         # This volume is in the "default" storage class.
43         StorageClasses:
44           default: true
45
46       ClusterID-nyw5e-000000000000001:
47         # This volume is in the "archival" storage class.
48         StorageClasses:
49           archival: true
50 </pre>
51
52 Refer to the "configuration reference":{{site.baseurl}}/admin/config.html for more details.
53
54 h3. Using storage classes
55
56 "Discussed in the user guide":{{site.baseurl}}/user/topics/storage-classes.html
57
58 h3. Storage management notes
59
60 When uploading data, if a data block cannot be uploaded to all desired storage classes, it will result in a fatal error.  Data blocks will not be uploaded to volumes that do not have the desired storage class.
61
62 If you change the storage classes for a collection, the data is not moved immediately.  The "keep-balance":{{site.baseurl}}/install/install-keep-balance.html service is responsible for deciding which blocks should be placed on which keepstore volumes.  As part of the rebalancing behavior, it will determine where a block should go in order to satisfy the desired storage classes, and issue pull requests to copy the block from its original volume to the desired volume.  The block will subsequently be moved to trash on the original volume.
63
64 If a block is assigned to multiple storage classes, the block will be stored on @desired_replication@ number of volumes for storage class, even if that results in overreplication.
65
66 If a collection has a desired storage class which is not available in any keepstore volume, the collection's blocks will remain in place, and an error will appear in the @keep-balance@ logs.