]>
Commit | Line | Data |
---|---|---|
11fdf7f2 TL |
1 | .. _msgr2: |
2 | ||
3 | Messenger v2 | |
4 | ============ | |
5 | ||
6 | What is it | |
7 | ---------- | |
8 | ||
9 | The messenger v2 protocol, or msgr2, is the second major revision on | |
10 | Ceph's on-wire protocol. It brings with it several key features: | |
11 | ||
12 | * A *secure* mode that encrypts all data passing over the network | |
13 | * Improved encapsulation of authentication payloads, enabling future | |
14 | integration of new authentication modes like Kerberos | |
15 | * Improved earlier feature advertisement and negotiation, enabling | |
16 | future protocol revisions | |
17 | ||
18 | Ceph daemons can now bind to multiple ports, allowing both legacy Ceph | |
19 | clients and new v2-capable clients to connect to the same cluster. | |
20 | ||
21 | By default, monitors now bind to the new IANA-assigned port ``3300`` | |
22 | (ce4h or 0xce4) for the new v2 protocol, while also binding to the | |
23 | old default port ``6789`` for the legacy v1 protocol. | |
24 | ||
f67539c2 TL |
25 | .. _address_formats: |
26 | ||
11fdf7f2 TL |
27 | Address formats |
28 | --------------- | |
29 | ||
f67539c2 | 30 | Prior to Nautilus, all network addresses were rendered like |
11fdf7f2 TL |
31 | ``1.2.3.4:567/89012`` where there was an IP address, a port, and a |
32 | nonce to uniquely identify a client or daemon on the network. | |
f67539c2 | 33 | Starting with Nautilus, we now have three different address types: |
11fdf7f2 TL |
34 | |
35 | * **v2**: ``v2:1.2.3.4:578/89012`` identifies a daemon binding to a | |
36 | port speaking the new v2 protocol | |
37 | * **v1**: ``v1:1.2.3.4:578/89012`` identifies a daemon binding to a | |
38 | port speaking the legacy v1 protocol. Any address that was | |
39 | previously shown with any prefix is now shown as a ``v1:`` address. | |
f67539c2 TL |
40 | * **TYPE_ANY** ``any:1.2.3.4:578/89012`` identifies a client that can |
41 | speak either version of the protocol. Prior to nautilus, clients would appear as | |
11fdf7f2 TL |
42 | ``1.2.3.4:0/123456``, where the port of 0 indicates they are clients |
43 | and do not accept incoming connections. Starting with Nautilus, | |
44 | these clients are now internally represented by a **TYPE_ANY** | |
45 | address, and still shown with no prefix, because they may | |
46 | connect to daemons using the v2 or v1 protocol, depending on what | |
47 | protocol(s) the daemons are using. | |
48 | ||
49 | Because daemons now bind to multiple ports, they are now described by | |
50 | a vector of addresses instead of a single address. For example, | |
51 | dumping the monitor map on a Nautilus cluster now includes lines | |
52 | like:: | |
53 | ||
54 | epoch 1 | |
55 | fsid 50fcf227-be32-4bcb-8b41-34ca8370bd16 | |
56 | last_changed 2019-02-25 11:10:46.700821 | |
57 | created 2019-02-25 11:10:46.700821 | |
58 | min_mon_release 14 (nautilus) | |
59 | 0: [v2:10.0.0.10:3300/0,v1:10.0.0.10:6789/0] mon.foo | |
60 | 1: [v2:10.0.0.11:3300/0,v1:10.0.0.11:6789/0] mon.bar | |
61 | 2: [v2:10.0.0.12:3300/0,v1:10.0.0.12:6789/0] mon.baz | |
62 | ||
63 | The bracketed list or vector of addresses means that the same daemon can be | |
64 | reached on multiple ports (and protocols). Any client or other daemon | |
65 | connecting to that daemon will use the v2 protocol (listed first) if | |
66 | possible; otherwise it will back to the legacy v1 protocol. Legacy | |
67 | clients will only see the v1 addresses and will continue to connect as | |
68 | they did before, with the v1 protocol. | |
69 | ||
70 | Starting in Nautilus, the ``mon_host`` configuration option and ``-m | |
71 | <mon-host>`` command line options support the same bracketed address | |
72 | vector syntax. | |
73 | ||
74 | ||
75 | Bind configuration options | |
76 | ^^^^^^^^^^^^^^^^^^^^^^^^^^ | |
77 | ||
78 | Two new configuration options control whether the v1 and/or v2 | |
79 | protocol is used: | |
80 | ||
20effc67 | 81 | * :confval:`ms_bind_msgr1` [default: true] controls whether a daemon binds |
11fdf7f2 | 82 | to a port speaking the v1 protocol |
20effc67 | 83 | * :confval:`ms_bind_msgr2` [default: true] controls whether a daemon binds |
11fdf7f2 TL |
84 | to a port speaking the v2 protocol |
85 | ||
86 | Similarly, two options control whether IPv4 and IPv6 addresses are used: | |
87 | ||
20effc67 | 88 | * :confval:`ms_bind_ipv4` [default: true] controls whether a daemon binds |
11fdf7f2 | 89 | to an IPv4 address |
20effc67 | 90 | * :confval:`ms_bind_ipv6` [default: false] controls whether a daemon binds |
11fdf7f2 TL |
91 | to an IPv6 address |
92 | ||
f67539c2 | 93 | .. note:: The ability to bind to multiple ports has paved the way for |
11fdf7f2 TL |
94 | dual-stack IPv4 and IPv6 support. That said, dual-stack support is |
95 | not yet tested as of Nautilus v14.2.0 and likely needs some | |
96 | additional code changes to work correctly. | |
97 | ||
98 | Connection modes | |
99 | ---------------- | |
100 | ||
101 | The v2 protocol supports two connection modes: | |
102 | ||
103 | * *crc* mode provides: | |
104 | ||
105 | - a strong initial authentication when the connection is established | |
106 | (with cephx, mutual authentication of both parties with protection | |
107 | from a man-in-the-middle or eavesdropper), and | |
108 | - a crc32c integrity check to protect against bit flips due to flaky | |
109 | hardware or cosmic rays | |
110 | ||
111 | *crc* mode does *not* provide: | |
112 | ||
113 | - secrecy (an eavesdropper on the network can see all | |
114 | post-authentication traffic as it goes by) or | |
115 | - protection from a malicious man-in-the-middle (who can deliberate | |
116 | modify traffic as it goes by, as long as they are careful to | |
117 | adjust the crc32c values to match) | |
118 | ||
119 | * *secure* mode provides: | |
120 | ||
121 | - a strong initial authentication when the connection is established | |
122 | (with cephx, mutual authentication of both parties with protection | |
123 | from a man-in-the-middle or eavesdropper), and | |
124 | - full encryption of all post-authentication traffic, including a | |
125 | cryptographic integrity check. | |
126 | ||
127 | In Nautilus, secure mode uses the `AES-GCM | |
128 | <https://en.wikipedia.org/wiki/Galois/Counter_Mode>`_ stream cipher, | |
129 | which is generally very fast on modern processors (e.g., faster than | |
130 | a SHA-256 cryptographic hash). | |
131 | ||
132 | Connection mode configuration options | |
133 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | |
134 | ||
135 | For most connections, there are options that control which modes are used: | |
136 | ||
20effc67 TL |
137 | .. confval:: ms_cluster_mode |
138 | .. confval:: ms_service_mode | |
139 | .. confval:: ms_client_mode | |
11fdf7f2 TL |
140 | |
141 | There are a parallel set of options that apply specifically to | |
142 | monitors, allowing administrators to set different (usually more | |
143 | secure) requirements on communication with the monitors. | |
144 | ||
20effc67 TL |
145 | .. confval:: ms_mon_cluster_mode |
146 | .. confval:: ms_mon_service_mode | |
147 | .. confval:: ms_mon_client_mode | |
11fdf7f2 TL |
148 | |
149 | ||
20effc67 TL |
150 | Compression modes |
151 | ----------------- | |
152 | ||
153 | The v2 protocol supports two compression modes: | |
154 | ||
155 | * *force* mode provides: | |
156 | ||
157 | - In multi-availability zones deployment, compressing replication messages between OSDs saves latency. | |
158 | - In the public cloud, inter-AZ communications are expensive. Thus, minimizing message | |
159 | size reduces network costs to cloud provider. | |
160 | - When using instance storage on AWS (probably other public clouds as well) the instances with NVMe | |
161 | provide low network bandwidth relative to the device bandwidth. | |
162 | In this case, NW compression can improve the overall performance since this is clearly | |
163 | the bottleneck. | |
164 | ||
165 | * *none* mode provides: | |
166 | ||
167 | - messages are transmitted without compression. | |
168 | ||
169 | ||
170 | Compression mode configuration options | |
171 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | |
172 | ||
173 | For all connections, there is an option that controls compression usage in secure mode | |
174 | ||
175 | .. confval:: ms_compress_secure | |
176 | ||
177 | There is a parallel set of options that apply specifically to OSDs, | |
178 | allowing administrators to set different requirements on communication between OSDs. | |
179 | ||
180 | .. confval:: ms_osd_compress_mode | |
181 | .. confval:: ms_osd_compress_min_size | |
182 | .. confval:: ms_osd_compression_algorithm | |
183 | ||
11fdf7f2 TL |
184 | Transitioning from v1-only to v2-plus-v1 |
185 | ---------------------------------------- | |
186 | ||
187 | By default, ``ms_bind_msgr2`` is true starting with Nautilus 14.2.z. | |
188 | However, until the monitors start using v2, only limited services will | |
189 | start advertising v2 addresses. | |
190 | ||
191 | For most users, the monitors are binding to the default legacy port ``6789`` for the v1 protocol. When this is the case, enabling v2 is as simple as:: | |
192 | ||
193 | ceph mon enable-msgr2 | |
194 | ||
195 | If the monitors are bound to non-standard ports, you will need to | |
196 | specify an additional port for v2 explicitly. For example, if your | |
197 | monitor ``mon.a`` binds to ``1.2.3.4:1111``, and you want to add v2 on | |
198 | port ``1112``,:: | |
199 | ||
200 | ceph mon set-addrs a [v2:1.2.3.4:1112,v1:1.2.3.4:1111] | |
201 | ||
202 | Once the monitors bind to v2, each daemon will start advertising a v2 | |
203 | address when it is next restarted. | |
204 | ||
205 | ||
9f95a23c TL |
206 | .. _msgr2_ceph_conf: |
207 | ||
11fdf7f2 TL |
208 | Updating ceph.conf and mon_host |
209 | ------------------------------- | |
210 | ||
211 | Prior to Nautilus, a CLI user or daemon will normally discover the | |
212 | monitors via the ``mon_host`` option in ``/etc/ceph/ceph.conf``. The | |
213 | syntax for this option has expanded starting with Nautilus to allow | |
214 | support the new bracketed list format. For example, an old line | |
215 | like:: | |
216 | ||
217 | mon_host = 10.0.0.1:6789,10.0.0.2:6789,10.0.0.3:6789 | |
218 | ||
219 | Can be changed to:: | |
220 | ||
221 | mon_host = [v2:10.0.0.1:3300/0,v1:10.0.0.1:6789/0],[v2:10.0.0.2:3300/0,v1:10.0.0.2:6789/0],[v2:10.0.0.3:3300/0,v1:10.0.0.3:6789/0] | |
222 | ||
223 | However, when default ports are used (``3300`` and ``6789``), they can | |
224 | be omitted:: | |
225 | ||
226 | mon_host = 10.0.0.1,10.0.0.2,10.0.0.3 | |
227 | ||
228 | Once v2 has been enabled on the monitors, ``ceph.conf`` may need to be | |
229 | updated to either specify no ports (this is usually simplest), or | |
230 | explicitly specify both the v2 and v1 addresses. Note, however, that | |
231 | the new bracketed syntax is only understood by Nautilus and later, so | |
232 | do not make that change on hosts that have not yet had their ceph | |
233 | packages upgraded. | |
234 | ||
235 | When you are updating ``ceph.conf``, note the new ``ceph config | |
236 | generate-minimal-conf`` command (which generates a barebones config | |
237 | file with just enough information to reach the monitors) and the | |
238 | ``ceph config assimilate-conf`` (which moves config file options into | |
239 | the monitors' configuration database) may be helpful. For example,:: | |
240 | ||
241 | # ceph config assimilate-conf < /etc/ceph/ceph.conf | |
242 | # ceph config generate-minimal-config > /etc/ceph/ceph.conf.new | |
243 | # cat /etc/ceph/ceph.conf.new | |
244 | # minimal ceph.conf for 0e5a806b-0ce5-4bc6-b949-aa6f68f5c2a3 | |
245 | [global] | |
246 | fsid = 0e5a806b-0ce5-4bc6-b949-aa6f68f5c2a3 | |
247 | mon_host = [v2:10.0.0.1:3300/0,v1:10.0.0.1:6789/0] | |
248 | # mv /etc/ceph/ceph.conf.new /etc/ceph/ceph.conf | |
249 | ||
250 | Protocol | |
251 | -------- | |
252 | ||
253 | For a detailed description of the v2 wire protocol, see :ref:`msgr2-protocol`. |