]>
Commit | Line | Data |
---|---|---|
b5b8bbf5 FG |
1 | .. _ceph-volume-systemd: |
2 | ||
3 | systemd | |
4 | ======= | |
5 | As part of the :ref:`ceph-volume-lvm-activate` process, a few systemd units will get enabled | |
6 | that will use the OSD id and uuid as part of their name. These units will be | |
7 | run when the system boots, and will proceed to activate their corresponding | |
8 | volumes. | |
9 | ||
10 | The API for activation requires both the :term:`OSD id` and :term:`OSD uuid`, | |
11 | which get persisted by systemd. Internally, the activation process enables the | |
12 | systemd unit using the following convention:: | |
13 | ||
14 | ceph-volume@<type>-<extra metadata> | |
15 | ||
16 | Where ``type`` is the sub-command used to parse the extra metadata, and ``extra | |
17 | metadata`` is any additional information needed by the sub-command to be able | |
18 | to activate the OSD. For example an OSD with an ID of 0, for the ``lvm`` | |
19 | sub-command would look like:: | |
20 | ||
21 | systemctl enable ceph-volume@lvm-0-0A3E1ED2-DA8A-4F0E-AA95-61DEC71768D6 | |
22 | ||
23 | ||
24 | Process | |
25 | ------- | |
26 | The systemd unit is a :term:`systemd oneshot` service, meant to start at boot after the | |
27 | local filesystem is ready to be used. | |
28 | ||
29 | Upon startup, it will identify the logical volume using :term:`LVM tags`, | |
30 | finding a matching ID and later ensuring it is the right one with | |
31 | the :term:`OSD uuid`. | |
32 | ||
33 | After identifying the correct volume it will then proceed to mount it by using | |
34 | the OSD destination conventions, that is:: | |
35 | ||
36 | /var/lib/ceph/osd/<cluster name>-<osd id> | |
37 | ||
38 | For our example OSD with an id of ``0``, that means the identified device will | |
39 | be mounted at:: | |
40 | ||
41 | ||
42 | /var/lib/ceph/osd/ceph-0 | |
43 | ||
44 | Once that process is complete, a call will be made to start the OSD:: | |
45 | ||
46 | systemctl start ceph-osd@0 |