Revision 94309823
b/doc/design-storagespace.rst | ||
---|---|---|
20 | 20 |
Configuration changes |
21 | 21 |
--------------------- |
22 | 22 |
|
23 |
Add a new attribute "enabled_storage_methods" (type: list of strings) to the
|
|
23 |
Add a new attribute "enabled_storage_types" (type: list of strings) to the
|
|
24 | 24 |
cluster config which holds the types of storages, for example, "plain", "drbd", |
25 |
or "ext". We consider the first one of the list as the default method.
|
|
25 |
or "ext". We consider the first one of the list as the default type.
|
|
26 | 26 |
|
27 | 27 |
For file storage, we'll report the storage space on the file storage dir, |
28 | 28 |
which is currently limited to one directory. In the future, if we'll have |
29 | 29 |
support for more directories, or for per-nodegroup directories this can be |
30 | 30 |
changed. |
31 | 31 |
|
32 |
Note that the abovementioned enabled_storage_methods are just "mechanisms"
|
|
33 |
parameters that define which storage methods the cluster can use. Further
|
|
32 |
Note that the abovementioned enabled_storage_types are just "mechanisms"
|
|
33 |
parameters that define which storage types the cluster can use. Further
|
|
34 | 34 |
filtering about what's allowed can go in the ipolicy, but these changes are |
35 | 35 |
not covered in this design doc. |
36 | 36 |
|
... | ... | |
45 | 45 |
----------- |
46 | 46 |
|
47 | 47 |
The noded RPC call that reports node storage space will be changed to |
48 |
accept a list of <method>,<key> string tuples. For each of them, it will
|
|
48 |
accept a list of <type>,<key> string tuples. For each of them, it will
|
|
49 | 49 |
report the free amount of storage space found on storage <key> as known |
50 |
by the requested storage type method. For example methods are ``lvm``,
|
|
50 |
by the requested storage type types. For example types are ``lvm``,
|
|
51 | 51 |
``filesystem``, or ``rados``, and the key would be a volume group name, in |
52 | 52 |
the case of lvm, a directory name for the filesystem and a rados pool name |
53 | 53 |
for rados storage. |
54 | 54 |
|
55 | 55 |
For now, we will implement only the storage reporting for non-shared storage, |
56 |
that is ``filesystem`` and ``lvm``. For shared storage methods like ``rados``
|
|
56 |
that is ``filesystem`` and ``lvm``. For shared storage types like ``rados``
|
|
57 | 57 |
and ``ext`` we will not implement a free space calculation, because it does |
58 | 58 |
not make sense to query each node for the free space of a commonly used |
59 | 59 |
storage. |
60 | 60 |
|
61 | 61 |
Masterd will know (through a constant map) which storage type uses which |
62 |
method for storage calculation (i.e. ``plain`` and ``drbd`` use ``lvm``,
|
|
62 |
type for storage calculation (i.e. ``plain`` and ``drbd`` use ``lvm``,
|
|
63 | 63 |
``file`` uses ``filesystem``, etc) and query the one needed (or all of the |
64 | 64 |
needed ones). |
65 | 65 |
|
66 | 66 |
Note that for file and sharedfile the node knows which directories are |
67 | 67 |
allowed and won't allow any other directory to be queried for security |
68 | 68 |
reasons. The actual path still needs to be passed to distinguish the |
69 |
two, as the method will be the same for both.
|
|
69 |
two, as the type will be the same for both.
|
|
70 | 70 |
|
71 | 71 |
These calculations will be implemented in the node storage system |
72 | 72 |
(currently lib/storage.py) but querying will still happen through the |
... | ... | |
75 | 75 |
Ganeti reporting |
76 | 76 |
---------------- |
77 | 77 |
|
78 |
`gnt-node list`` can be queried for the different storage methods, if they
|
|
78 |
`gnt-node list`` can be queried for the different storage types, if they
|
|
79 | 79 |
are enabled. By default, it will just report information about the default |
80 |
storage method. Examples::
|
|
80 |
storage type. Examples::
|
|
81 | 81 |
|
82 | 82 |
> gnt-node list |
83 | 83 |
Node DTotal DFree MTotal MNode MFree Pinst Sinst |
... | ... | |
98 | 98 |
that there is enough space for the meta volume group. |
99 | 99 |
|
100 | 100 |
When storage pools are implemented, we switch from referencing the storage |
101 |
method to referencing the storage pool name. For that, of course, the pool
|
|
102 |
names need to be unique over all storage methods. For drbd, we will use the
|
|
101 |
type to referencing the storage pool name. For that, of course, the pool
|
|
102 |
names need to be unique over all storage types. For drbd, we will use the
|
|
103 | 103 |
default 'lvm' storage pool and possibly a second lvm-based storage pool for |
104 | 104 |
the metavg. It will be possible to rename storage pools (thus also the default |
105 | 105 |
lvm storage pool). There will be new functionality to ask about what storage |
106 | 106 |
pools are available and of what type. |
107 | 107 |
|
108 |
``gnt-cluster info`` will report which storage methods are enabled, i.e.
|
|
108 |
``gnt-cluster info`` will report which storage types are enabled, i.e.
|
|
109 | 109 |
which ones are supported according to the cluster configuration. Example |
110 | 110 |
output:: |
111 | 111 |
|
... | ... | |
113 | 113 |
[...] |
114 | 114 |
Cluster parameters: |
115 | 115 |
- [...] |
116 |
- enabled storage methods: plain (default), drbd, lvm, rados
|
|
116 |
- enabled storage types: plain (default), drbd, lvm, rados
|
|
117 | 117 |
- [...] |
118 | 118 |
|
119 | 119 |
``gnt-node list-storage`` will not be affected by any changes, since this design |
120 |
describes only free storage reporting for non-shared storage methods.
|
|
120 |
describes only free storage reporting for non-shared storage types.
|
|
121 | 121 |
|
122 | 122 |
Allocator changes |
123 | 123 |
----------------- |
... | ... | |
158 | 158 |
``exclusive_storage`` flag, which is currently only meaningful for the |
159 | 159 |
LVM back-end. Additional flags like the ``external_storage`` flag |
160 | 160 |
for lvm might be useful for other storage types as well. We therefore |
161 |
extend the RPC call with <method>,<key> to <method>,<key>,<params> to
|
|
162 |
include any storage-method specific parameters in the RPC call.
|
|
161 |
extend the RPC call with <type>,<key> to <type>,<key>,<params> to
|
|
162 |
include any storage-type specific parameters in the RPC call.
|
|
163 | 163 |
|
164 | 164 |
The reporting of free spindles, also part of Partitioned Ganeti, is not |
165 | 165 |
concerned with this design doc, as those are seen as a separate resource. |
Also available in: Unified diff