]>
Commit | Line | Data |
---|---|---|
f6b5b4d7 TL |
1 | Cephadm Concepts |
2 | ================ | |
3 | ||
4 | .. _cephadm-fqdn: | |
5 | ||
6 | Fully qualified domain names vs bare host names | |
7 | ----------------------------------------------- | |
8 | ||
9 | cephadm has very minimal requirements when it comes to resolving host | |
10 | names etc. When cephadm initiates an ssh connection to a remote host, | |
11 | the host name can be resolved in four different ways: | |
12 | ||
13 | - a custom ssh config resolving the name to an IP | |
14 | - via an externally maintained ``/etc/hosts`` | |
15 | - via explicitly providing an IP address to cephadm: ``ceph orch host add <hostname> <IP>`` | |
16 | - automatic name resolution via DNS. | |
17 | ||
18 | Ceph itself uses the command ``hostname`` to determine the name of the | |
19 | current host. | |
20 | ||
21 | .. note:: | |
22 | ||
23 | cephadm demands that the name of the host given via ``ceph orch host add`` | |
24 | equals the output of ``hostname`` on remote hosts. | |
25 | ||
26 | Otherwise cephadm can't be sure, the host names returned by | |
27 | ``ceph * metadata`` match the hosts known to cephadm. This might result | |
28 | in a :ref:`cephadm-stray-host` warning. | |
29 | ||
30 | When configuring new hosts, there are two **valid** ways to set the | |
31 | ``hostname`` of a host: | |
32 | ||
33 | 1. Using the bare host name. In this case: | |
34 | ||
35 | - ``hostname`` returns the bare host name. | |
36 | - ``hostname -f`` returns the FQDN. | |
37 | ||
38 | 2. Using the fully qualified domain name as the host name. In this case: | |
39 | ||
40 | - ``hostname`` returns the FQDN | |
41 | - ``hostname -s`` return the bare host name | |
42 | ||
43 | Note that ``man hostname`` recommends ``hostname`` to return the bare | |
44 | host name: | |
45 | ||
46 | The FQDN (Fully Qualified Domain Name) of the system is the | |
47 | name that the resolver(3) returns for the host name, such as, | |
48 | ursula.example.com. It is usually the hostname followed by the DNS | |
49 | domain name (the part after the first dot). You can check the FQDN | |
50 | using ``hostname --fqdn`` or the domain name using ``dnsdomainname``. | |
51 | ||
f91f0fd5 | 52 | .. code-block:: none |
f6b5b4d7 TL |
53 | |
54 | You cannot change the FQDN with hostname or dnsdomainname. | |
55 | ||
56 | The recommended method of setting the FQDN is to make the hostname | |
57 | be an alias for the fully qualified name using /etc/hosts, DNS, or | |
58 | NIS. For example, if the hostname was "ursula", one might have | |
59 | a line in /etc/hosts which reads | |
60 | ||
61 | 127.0.1.1 ursula.example.com ursula | |
62 | ||
63 | Which means, ``man hostname`` recommends ``hostname`` to return the bare | |
64 | host name. This in turn means that Ceph will return the bare host names | |
65 | when executing ``ceph * metadata``. This in turn means cephadm also | |
66 | requires the bare host name when adding a host to the cluster: | |
67 | ``ceph orch host add <bare-name>``. | |
68 | ||
69 | .. | |
70 | TODO: This chapter needs to provide way for users to configure | |
71 | Grafana in the dashboard, as this is right no very hard to do. | |
72 | ||
73 | Cephadm Scheduler | |
74 | ----------------- | |
75 | ||
76 | Cephadm uses a declarative state to define the layout of the cluster. This | |
77 | state consists of a list of service specifications containing placement | |
78 | specifications (See :ref:`orchestrator-cli-service-spec` ). | |
79 | ||
80 | Cephadm constantly compares list of actually running daemons in the cluster | |
81 | with the desired service specifications and will either add or remove new | |
82 | daemons. | |
83 | ||
84 | First, cephadm will select a list of candidate hosts. It first looks for | |
85 | explicit host names and will select those. In case there are no explicit hosts | |
86 | defined, cephadm looks for a label specification. If there is no label defined | |
87 | in the specification, cephadm will select hosts based on a host pattern. If | |
88 | there is no pattern defined, cepham will finally select all known hosts as | |
89 | candidates. | |
90 | ||
91 | Then, cephadm will consider existing daemons of this services and will try to | |
92 | avoid moving any daemons. | |
93 | ||
94 | Cephadm supports the deployment of a specific amount of services. Let's | |
95 | consider a service specification like so: | |
96 | ||
97 | .. code-block:: yaml | |
98 | ||
99 | service_type: mds | |
100 | service_name: myfs | |
101 | placement: | |
102 | count: 3 | |
103 | label: myfs | |
104 | ||
105 | This instructs cephadm to deploy three daemons on hosts labeled with | |
106 | ``myfs`` across the cluster. | |
107 | ||
108 | Then, in case there are less than three daemons deployed on the candidate | |
109 | hosts, cephadm will then then randomly choose hosts for deploying new daemons. | |
110 | ||
111 | In case there are more than three daemons deployed, cephadm will remove | |
112 | existing daemons. | |
113 | ||
114 | Finally, cephadm will remove daemons on hosts that are outside of the list of | |
115 | candidate hosts. | |
116 | ||
117 | However, there is a special cases that cephadm needs to consider. | |
118 | ||
119 | In case the are fewer hosts selected by the placement specification than | |
f91f0fd5 | 120 | demanded by ``count``, cephadm will only deploy on selected hosts. |