]>
Commit | Line | Data |
---|---|---|
7c673cae FG |
1 | ========================= |
2 | Monitoring OSDs and PGs | |
3 | ========================= | |
4 | ||
5 | High availability and high reliability require a fault-tolerant approach to | |
6 | managing hardware and software issues. Ceph has no single point-of-failure, and | |
7 | can service requests for data in a "degraded" mode. Ceph's `data placement`_ | |
8 | introduces a layer of indirection to ensure that data doesn't bind directly to | |
9 | particular OSD addresses. This means that tracking down system faults requires | |
10 | finding the `placement group`_ and the underlying OSDs at root of the problem. | |
11 | ||
12 | .. tip:: A fault in one part of the cluster may prevent you from accessing a | |
c07f9fc5 | 13 | particular object, but that doesn't mean that you cannot access other objects. |
7c673cae FG |
14 | When you run into a fault, don't panic. Just follow the steps for monitoring |
15 | your OSDs and placement groups. Then, begin troubleshooting. | |
16 | ||
17 | Ceph is generally self-repairing. However, when problems persist, monitoring | |
18 | OSDs and placement groups will help you identify the problem. | |
19 | ||
20 | ||
21 | Monitoring OSDs | |
22 | =============== | |
23 | ||
24 | An OSD's status is either in the cluster (``in``) or out of the cluster | |
25 | (``out``); and, it is either up and running (``up``), or it is down and not | |
26 | running (``down``). If an OSD is ``up``, it may be either ``in`` the cluster | |
27 | (you can read and write data) or it is ``out`` of the cluster. If it was | |
28 | ``in`` the cluster and recently moved ``out`` of the cluster, Ceph will migrate | |
29 | placement groups to other OSDs. If an OSD is ``out`` of the cluster, CRUSH will | |
30 | not assign placement groups to the OSD. If an OSD is ``down``, it should also be | |
31 | ``out``. | |
32 | ||
33 | .. note:: If an OSD is ``down`` and ``in``, there is a problem and the cluster | |
34 | will not be in a healthy state. | |
35 | ||
f91f0fd5 TL |
36 | .. ditaa:: |
37 | ||
38 | +----------------+ +----------------+ | |
7c673cae FG |
39 | | | | | |
40 | | OSD #n In | | OSD #n Up | | |
41 | | | | | | |
42 | +----------------+ +----------------+ | |
43 | ^ ^ | |
44 | | | | |
45 | | | | |
46 | v v | |
47 | +----------------+ +----------------+ | |
48 | | | | | | |
49 | | OSD #n Out | | OSD #n Down | | |
50 | | | | | | |
51 | +----------------+ +----------------+ | |
52 | ||
53 | If you execute a command such as ``ceph health``, ``ceph -s`` or ``ceph -w``, | |
54 | you may notice that the cluster does not always echo back ``HEALTH OK``. Don't | |
55 | panic. With respect to OSDs, you should expect that the cluster will **NOT** | |
56 | echo ``HEALTH OK`` in a few expected circumstances: | |
57 | ||
58 | #. You haven't started the cluster yet (it won't respond). | |
59 | #. You have just started or restarted the cluster and it's not ready yet, | |
60 | because the placement groups are getting created and the OSDs are in | |
61 | the process of peering. | |
62 | #. You just added or removed an OSD. | |
63 | #. You just have modified your cluster map. | |
64 | ||
65 | An important aspect of monitoring OSDs is to ensure that when the cluster | |
66 | is up and running that all OSDs that are ``in`` the cluster are ``up`` and | |
67 | running, too. To see if all OSDs are running, execute:: | |
68 | ||
69 | ceph osd stat | |
70 | ||
11fdf7f2 TL |
71 | The result should tell you the total number of OSDs (x), |
72 | how many are ``up`` (y), how many are ``in`` (z) and the map epoch (eNNNN). :: | |
7c673cae | 73 | |
11fdf7f2 | 74 | x osds: y up, z in; epoch: eNNNN |
7c673cae FG |
75 | |
76 | If the number of OSDs that are ``in`` the cluster is more than the number of | |
77 | OSDs that are ``up``, execute the following command to identify the ``ceph-osd`` | |
c07f9fc5 | 78 | daemons that are not running:: |
7c673cae FG |
79 | |
80 | ceph osd tree | |
81 | ||
82 | :: | |
83 | ||
11fdf7f2 TL |
84 | #ID CLASS WEIGHT TYPE NAME STATUS REWEIGHT PRI-AFF |
85 | -1 2.00000 pool openstack | |
86 | -3 2.00000 rack dell-2950-rack-A | |
87 | -2 2.00000 host dell-2950-A1 | |
88 | 0 ssd 1.00000 osd.0 up 1.00000 1.00000 | |
89 | 1 ssd 1.00000 osd.1 down 1.00000 1.00000 | |
7c673cae FG |
90 | |
91 | .. tip:: The ability to search through a well-designed CRUSH hierarchy may help | |
11fdf7f2 | 92 | you troubleshoot your cluster by identifying the physical locations faster. |
7c673cae FG |
93 | |
94 | If an OSD is ``down``, start it:: | |
95 | ||
96 | sudo systemctl start ceph-osd@1 | |
97 | ||
98 | See `OSD Not Running`_ for problems associated with OSDs that stopped, or won't | |
99 | restart. | |
100 | ||
101 | ||
102 | PG Sets | |
103 | ======= | |
104 | ||
105 | When CRUSH assigns placement groups to OSDs, it looks at the number of replicas | |
106 | for the pool and assigns the placement group to OSDs such that each replica of | |
107 | the placement group gets assigned to a different OSD. For example, if the pool | |
108 | requires three replicas of a placement group, CRUSH may assign them to | |
109 | ``osd.1``, ``osd.2`` and ``osd.3`` respectively. CRUSH actually seeks a | |
110 | pseudo-random placement that will take into account failure domains you set in | |
111 | your `CRUSH map`_, so you will rarely see placement groups assigned to nearest | |
112 | neighbor OSDs in a large cluster. We refer to the set of OSDs that should | |
113 | contain the replicas of a particular placement group as the **Acting Set**. In | |
114 | some cases, an OSD in the Acting Set is ``down`` or otherwise not able to | |
115 | service requests for objects in the placement group. When these situations | |
116 | arise, don't panic. Common examples include: | |
117 | ||
118 | - You added or removed an OSD. Then, CRUSH reassigned the placement group to | |
119 | other OSDs--thereby changing the composition of the Acting Set and spawning | |
120 | the migration of data with a "backfill" process. | |
121 | - An OSD was ``down``, was restarted, and is now ``recovering``. | |
122 | - An OSD in the Acting Set is ``down`` or unable to service requests, | |
123 | and another OSD has temporarily assumed its duties. | |
124 | ||
125 | Ceph processes a client request using the **Up Set**, which is the set of OSDs | |
126 | that will actually handle the requests. In most cases, the Up Set and the Acting | |
127 | Set are virtually identical. When they are not, it may indicate that Ceph is | |
128 | migrating data, an OSD is recovering, or that there is a problem (i.e., Ceph | |
129 | usually echoes a "HEALTH WARN" state with a "stuck stale" message in such | |
130 | scenarios). | |
131 | ||
132 | To retrieve a list of placement groups, execute:: | |
133 | ||
134 | ceph pg dump | |
135 | ||
136 | To view which OSDs are within the Acting Set or the Up Set for a given placement | |
137 | group, execute:: | |
138 | ||
139 | ceph pg map {pg-num} | |
140 | ||
141 | The result should tell you the osdmap epoch (eNNN), the placement group number | |
142 | ({pg-num}), the OSDs in the Up Set (up[]), and the OSDs in the acting set | |
143 | (acting[]). :: | |
144 | ||
11fdf7f2 | 145 | osdmap eNNN pg {raw-pg-num} ({pg-num}) -> up [0,1,2] acting [0,1,2] |
7c673cae FG |
146 | |
147 | .. note:: If the Up Set and Acting Set do not match, this may be an indicator | |
148 | that the cluster rebalancing itself or of a potential problem with | |
149 | the cluster. | |
150 | ||
151 | ||
152 | Peering | |
153 | ======= | |
154 | ||
155 | Before you can write data to a placement group, it must be in an ``active`` | |
156 | state, and it **should** be in a ``clean`` state. For Ceph to determine the | |
157 | current state of a placement group, the primary OSD of the placement group | |
158 | (i.e., the first OSD in the acting set), peers with the secondary and tertiary | |
159 | OSDs to establish agreement on the current state of the placement group | |
160 | (assuming a pool with 3 replicas of the PG). | |
161 | ||
162 | ||
f91f0fd5 TL |
163 | .. ditaa:: |
164 | ||
165 | +---------+ +---------+ +-------+ | |
7c673cae FG |
166 | | OSD 1 | | OSD 2 | | OSD 3 | |
167 | +---------+ +---------+ +-------+ | |
168 | | | | | |
169 | | Request To | | | |
170 | | Peer | | | |
171 | |-------------->| | | |
172 | |<--------------| | | |
173 | | Peering | | |
174 | | | | |
175 | | Request To | | |
176 | | Peer | | |
177 | |----------------------------->| | |
178 | |<-----------------------------| | |
179 | | Peering | | |
180 | ||
181 | The OSDs also report their status to the monitor. See `Configuring Monitor/OSD | |
182 | Interaction`_ for details. To troubleshoot peering issues, see `Peering | |
183 | Failure`_. | |
184 | ||
185 | ||
186 | Monitoring Placement Group States | |
187 | ================================= | |
188 | ||
189 | If you execute a command such as ``ceph health``, ``ceph -s`` or ``ceph -w``, | |
190 | you may notice that the cluster does not always echo back ``HEALTH OK``. After | |
191 | you check to see if the OSDs are running, you should also check placement group | |
192 | states. You should expect that the cluster will **NOT** echo ``HEALTH OK`` in a | |
193 | number of placement group peering-related circumstances: | |
194 | ||
195 | #. You have just created a pool and placement groups haven't peered yet. | |
196 | #. The placement groups are recovering. | |
197 | #. You have just added an OSD to or removed an OSD from the cluster. | |
198 | #. You have just modified your CRUSH map and your placement groups are migrating. | |
199 | #. There is inconsistent data in different replicas of a placement group. | |
200 | #. Ceph is scrubbing a placement group's replicas. | |
201 | #. Ceph doesn't have enough storage capacity to complete backfilling operations. | |
202 | ||
203 | If one of the foregoing circumstances causes Ceph to echo ``HEALTH WARN``, don't | |
204 | panic. In many cases, the cluster will recover on its own. In some cases, you | |
205 | may need to take action. An important aspect of monitoring placement groups is | |
206 | to ensure that when the cluster is up and running that all placement groups are | |
207 | ``active``, and preferably in the ``clean`` state. To see the status of all | |
208 | placement groups, execute:: | |
209 | ||
210 | ceph pg stat | |
211 | ||
11fdf7f2 TL |
212 | The result should tell you the total number of placement groups (x), how many |
213 | placement groups are in a particular state such as ``active+clean`` (y) and the | |
214 | amount of data stored (z). :: | |
7c673cae | 215 | |
11fdf7f2 | 216 | x pgs: y active+clean; z bytes data, aa MB used, bb GB / cc GB avail |
7c673cae FG |
217 | |
218 | .. note:: It is common for Ceph to report multiple states for placement groups. | |
219 | ||
11fdf7f2 TL |
220 | In addition to the placement group states, Ceph will also echo back the amount of |
221 | storage capacity used (aa), the amount of storage capacity remaining (bb), and the total | |
7c673cae FG |
222 | storage capacity for the placement group. These numbers can be important in a |
223 | few cases: | |
224 | ||
225 | - You are reaching your ``near full ratio`` or ``full ratio``. | |
c07f9fc5 | 226 | - Your data is not getting distributed across the cluster due to an |
7c673cae FG |
227 | error in your CRUSH configuration. |
228 | ||
229 | ||
230 | .. topic:: Placement Group IDs | |
231 | ||
232 | Placement group IDs consist of the pool number (not pool name) followed | |
233 | by a period (.) and the placement group ID--a hexadecimal number. You | |
234 | can view pool numbers and their names from the output of ``ceph osd | |
11fdf7f2 TL |
235 | lspools``. For example, the first pool created corresponds to |
236 | pool number ``1``. A fully qualified placement group ID has the | |
7c673cae FG |
237 | following form:: |
238 | ||
239 | {pool-num}.{pg-id} | |
240 | ||
241 | And it typically looks like this:: | |
242 | ||
11fdf7f2 | 243 | 1.1f |
7c673cae FG |
244 | |
245 | ||
246 | To retrieve a list of placement groups, execute the following:: | |
247 | ||
248 | ceph pg dump | |
249 | ||
250 | You can also format the output in JSON format and save it to a file:: | |
251 | ||
252 | ceph pg dump -o {filename} --format=json | |
253 | ||
254 | To query a particular placement group, execute the following:: | |
255 | ||
256 | ceph pg {poolnum}.{pg-id} query | |
257 | ||
258 | Ceph will output the query in JSON format. | |
259 | ||
11fdf7f2 | 260 | The following subsections describe the common pg states in detail. |
7c673cae FG |
261 | |
262 | Creating | |
263 | -------- | |
264 | ||
265 | When you create a pool, it will create the number of placement groups you | |
266 | specified. Ceph will echo ``creating`` when it is creating one or more | |
267 | placement groups. Once they are created, the OSDs that are part of a placement | |
268 | group's Acting Set will peer. Once peering is complete, the placement group | |
269 | status should be ``active+clean``, which means a Ceph client can begin writing | |
270 | to the placement group. | |
271 | ||
f91f0fd5 TL |
272 | .. ditaa:: |
273 | ||
7c673cae FG |
274 | /-----------\ /-----------\ /-----------\ |
275 | | Creating |------>| Peering |------>| Active | | |
276 | \-----------/ \-----------/ \-----------/ | |
277 | ||
278 | Peering | |
279 | ------- | |
280 | ||
281 | When Ceph is Peering a placement group, Ceph is bringing the OSDs that | |
282 | store the replicas of the placement group into **agreement about the state** | |
283 | of the objects and metadata in the placement group. When Ceph completes peering, | |
284 | this means that the OSDs that store the placement group agree about the current | |
285 | state of the placement group. However, completion of the peering process does | |
286 | **NOT** mean that each replica has the latest contents. | |
287 | ||
11fdf7f2 | 288 | .. topic:: Authoritative History |
7c673cae FG |
289 | |
290 | Ceph will **NOT** acknowledge a write operation to a client, until | |
291 | all OSDs of the acting set persist the write operation. This practice | |
292 | ensures that at least one member of the acting set will have a record | |
293 | of every acknowledged write operation since the last successful | |
294 | peering operation. | |
295 | ||
296 | With an accurate record of each acknowledged write operation, Ceph can | |
297 | construct and disseminate a new authoritative history of the placement | |
298 | group--a complete, and fully ordered set of operations that, if performed, | |
299 | would bring an OSD’s copy of a placement group up to date. | |
300 | ||
301 | ||
302 | Active | |
303 | ------ | |
304 | ||
305 | Once Ceph completes the peering process, a placement group may become | |
306 | ``active``. The ``active`` state means that the data in the placement group is | |
307 | generally available in the primary placement group and the replicas for read | |
308 | and write operations. | |
309 | ||
310 | ||
311 | Clean | |
312 | ----- | |
313 | ||
314 | When a placement group is in the ``clean`` state, the primary OSD and the | |
315 | replica OSDs have successfully peered and there are no stray replicas for the | |
316 | placement group. Ceph replicated all objects in the placement group the correct | |
317 | number of times. | |
318 | ||
319 | ||
320 | Degraded | |
321 | -------- | |
322 | ||
323 | When a client writes an object to the primary OSD, the primary OSD is | |
324 | responsible for writing the replicas to the replica OSDs. After the primary OSD | |
325 | writes the object to storage, the placement group will remain in a ``degraded`` | |
326 | state until the primary OSD has received an acknowledgement from the replica | |
327 | OSDs that Ceph created the replica objects successfully. | |
328 | ||
329 | The reason a placement group can be ``active+degraded`` is that an OSD may be | |
330 | ``active`` even though it doesn't hold all of the objects yet. If an OSD goes | |
331 | ``down``, Ceph marks each placement group assigned to the OSD as ``degraded``. | |
332 | The OSDs must peer again when the OSD comes back online. However, a client can | |
333 | still write a new object to a ``degraded`` placement group if it is ``active``. | |
334 | ||
335 | If an OSD is ``down`` and the ``degraded`` condition persists, Ceph may mark the | |
336 | ``down`` OSD as ``out`` of the cluster and remap the data from the ``down`` OSD | |
337 | to another OSD. The time between being marked ``down`` and being marked ``out`` | |
338 | is controlled by ``mon osd down out interval``, which is set to ``600`` seconds | |
339 | by default. | |
340 | ||
341 | A placement group can also be ``degraded``, because Ceph cannot find one or more | |
342 | objects that Ceph thinks should be in the placement group. While you cannot | |
343 | read or write to unfound objects, you can still access all of the other objects | |
344 | in the ``degraded`` placement group. | |
345 | ||
346 | ||
347 | Recovering | |
348 | ---------- | |
349 | ||
350 | Ceph was designed for fault-tolerance at a scale where hardware and software | |
351 | problems are ongoing. When an OSD goes ``down``, its contents may fall behind | |
352 | the current state of other replicas in the placement groups. When the OSD is | |
353 | back ``up``, the contents of the placement groups must be updated to reflect the | |
354 | current state. During that time period, the OSD may reflect a ``recovering`` | |
355 | state. | |
356 | ||
c07f9fc5 | 357 | Recovery is not always trivial, because a hardware failure might cause a |
7c673cae FG |
358 | cascading failure of multiple OSDs. For example, a network switch for a rack or |
359 | cabinet may fail, which can cause the OSDs of a number of host machines to fall | |
360 | behind the current state of the cluster. Each one of the OSDs must recover once | |
361 | the fault is resolved. | |
362 | ||
363 | Ceph provides a number of settings to balance the resource contention between | |
364 | new service requests and the need to recover data objects and restore the | |
365 | placement groups to the current state. The ``osd recovery delay start`` setting | |
366 | allows an OSD to restart, re-peer and even process some replay requests before | |
367 | starting the recovery process. The ``osd | |
368 | recovery thread timeout`` sets a thread timeout, because multiple OSDs may fail, | |
369 | restart and re-peer at staggered rates. The ``osd recovery max active`` setting | |
370 | limits the number of recovery requests an OSD will entertain simultaneously to | |
371 | prevent the OSD from failing to serve . The ``osd recovery max chunk`` setting | |
372 | limits the size of the recovered data chunks to prevent network congestion. | |
373 | ||
374 | ||
375 | Back Filling | |
376 | ------------ | |
377 | ||
378 | When a new OSD joins the cluster, CRUSH will reassign placement groups from OSDs | |
379 | in the cluster to the newly added OSD. Forcing the new OSD to accept the | |
380 | reassigned placement groups immediately can put excessive load on the new OSD. | |
381 | Back filling the OSD with the placement groups allows this process to begin in | |
382 | the background. Once backfilling is complete, the new OSD will begin serving | |
383 | requests when it is ready. | |
384 | ||
385 | During the backfill operations, you may see one of several states: | |
c07f9fc5 | 386 | ``backfill_wait`` indicates that a backfill operation is pending, but is not |
11fdf7f2 TL |
387 | underway yet; ``backfilling`` indicates that a backfill operation is underway; |
388 | and, ``backfill_toofull`` indicates that a backfill operation was requested, | |
7c673cae | 389 | but couldn't be completed due to insufficient storage capacity. When a |
c07f9fc5 | 390 | placement group cannot be backfilled, it may be considered ``incomplete``. |
7c673cae | 391 | |
eafe8130 TL |
392 | The ``backfill_toofull`` state may be transient. It is possible that as PGs |
393 | are moved around, space may become available. The ``backfill_toofull`` is | |
394 | similar to ``backfill_wait`` in that as soon as conditions change | |
395 | backfill can proceed. | |
396 | ||
7c673cae FG |
397 | Ceph provides a number of settings to manage the load spike associated with |
398 | reassigning placement groups to an OSD (especially a new OSD). By default, | |
11fdf7f2 TL |
399 | ``osd_max_backfills`` sets the maximum number of concurrent backfills to and from |
400 | an OSD to 1. The ``backfill full ratio`` enables an OSD to refuse a | |
7c673cae | 401 | backfill request if the OSD is approaching its full ratio (90%, by default) and |
11fdf7f2 | 402 | change with ``ceph osd set-backfillfull-ratio`` command. |
7c673cae | 403 | If an OSD refuses a backfill request, the ``osd backfill retry interval`` |
11fdf7f2 | 404 | enables an OSD to retry the request (after 30 seconds, by default). OSDs can |
7c673cae FG |
405 | also set ``osd backfill scan min`` and ``osd backfill scan max`` to manage scan |
406 | intervals (64 and 512, by default). | |
407 | ||
408 | ||
409 | Remapped | |
410 | -------- | |
411 | ||
412 | When the Acting Set that services a placement group changes, the data migrates | |
413 | from the old acting set to the new acting set. It may take some time for a new | |
414 | primary OSD to service requests. So it may ask the old primary to continue to | |
415 | service requests until the placement group migration is complete. Once data | |
416 | migration completes, the mapping uses the primary OSD of the new acting set. | |
417 | ||
418 | ||
419 | Stale | |
420 | ----- | |
421 | ||
422 | While Ceph uses heartbeats to ensure that hosts and daemons are running, the | |
c07f9fc5 | 423 | ``ceph-osd`` daemons may also get into a ``stuck`` state where they are not |
7c673cae | 424 | reporting statistics in a timely manner (e.g., a temporary network fault). By |
11fdf7f2 | 425 | default, OSD daemons report their placement group, up through, boot and failure |
7c673cae FG |
426 | statistics every half second (i.e., ``0.5``), which is more frequent than the |
427 | heartbeat thresholds. If the **Primary OSD** of a placement group's acting set | |
428 | fails to report to the monitor or if other OSDs have reported the primary OSD | |
429 | ``down``, the monitors will mark the placement group ``stale``. | |
430 | ||
431 | When you start your cluster, it is common to see the ``stale`` state until | |
432 | the peering process completes. After your cluster has been running for awhile, | |
433 | seeing placement groups in the ``stale`` state indicates that the primary OSD | |
434 | for those placement groups is ``down`` or not reporting placement group statistics | |
435 | to the monitor. | |
436 | ||
437 | ||
438 | Identifying Troubled PGs | |
439 | ======================== | |
440 | ||
c07f9fc5 FG |
441 | As previously noted, a placement group is not necessarily problematic just |
442 | because its state is not ``active+clean``. Generally, Ceph's ability to self | |
7c673cae FG |
443 | repair may not be working when placement groups get stuck. The stuck states |
444 | include: | |
445 | ||
446 | - **Unclean**: Placement groups contain objects that are not replicated the | |
447 | desired number of times. They should be recovering. | |
448 | - **Inactive**: Placement groups cannot process reads or writes because they | |
449 | are waiting for an OSD with the most up-to-date data to come back ``up``. | |
450 | - **Stale**: Placement groups are in an unknown state, because the OSDs that | |
451 | host them have not reported to the monitor cluster in a while (configured | |
452 | by ``mon osd report timeout``). | |
453 | ||
454 | To identify stuck placement groups, execute the following:: | |
455 | ||
456 | ceph pg dump_stuck [unclean|inactive|stale|undersized|degraded] | |
457 | ||
458 | See `Placement Group Subsystem`_ for additional details. To troubleshoot | |
459 | stuck placement groups, see `Troubleshooting PG Errors`_. | |
460 | ||
461 | ||
462 | Finding an Object Location | |
463 | ========================== | |
464 | ||
465 | To store object data in the Ceph Object Store, a Ceph client must: | |
466 | ||
467 | #. Set an object name | |
468 | #. Specify a `pool`_ | |
469 | ||
470 | The Ceph client retrieves the latest cluster map and the CRUSH algorithm | |
471 | calculates how to map the object to a `placement group`_, and then calculates | |
472 | how to assign the placement group to an OSD dynamically. To find the object | |
473 | location, all you need is the object name and the pool name. For example:: | |
474 | ||
11fdf7f2 | 475 | ceph osd map {poolname} {object-name} [namespace] |
7c673cae FG |
476 | |
477 | .. topic:: Exercise: Locate an Object | |
478 | ||
479 | As an exercise, lets create an object. Specify an object name, a path to a | |
480 | test file containing some object data and a pool name using the | |
481 | ``rados put`` command on the command line. For example:: | |
482 | ||
483 | rados put {object-name} {file-path} --pool=data | |
484 | rados put test-object-1 testfile.txt --pool=data | |
485 | ||
486 | To verify that the Ceph Object Store stored the object, execute the following:: | |
487 | ||
488 | rados -p data ls | |
489 | ||
490 | Now, identify the object location:: | |
491 | ||
492 | ceph osd map {pool-name} {object-name} | |
493 | ceph osd map data test-object-1 | |
494 | ||
495 | Ceph should output the object's location. For example:: | |
496 | ||
11fdf7f2 | 497 | osdmap e537 pool 'data' (1) object 'test-object-1' -> pg 1.d1743484 (1.4) -> up ([0,1], p0) acting ([0,1], p0) |
7c673cae FG |
498 | |
499 | To remove the test object, simply delete it using the ``rados rm`` command. | |
500 | For example:: | |
501 | ||
502 | rados rm test-object-1 --pool=data | |
503 | ||
504 | ||
505 | As the cluster evolves, the object location may change dynamically. One benefit | |
506 | of Ceph's dynamic rebalancing is that Ceph relieves you from having to perform | |
507 | the migration manually. See the `Architecture`_ section for details. | |
508 | ||
509 | .. _data placement: ../data-placement | |
510 | .. _pool: ../pools | |
511 | .. _placement group: ../placement-groups | |
512 | .. _Architecture: ../../../architecture | |
513 | .. _OSD Not Running: ../../troubleshooting/troubleshooting-osd#osd-not-running | |
514 | .. _Troubleshooting PG Errors: ../../troubleshooting/troubleshooting-pg#troubleshooting-pg-errors | |
515 | .. _Peering Failure: ../../troubleshooting/troubleshooting-pg#failures-osd-peering | |
516 | .. _CRUSH map: ../crush-map | |
517 | .. _Configuring Monitor/OSD Interaction: ../../configuration/mon-osd-interaction/ | |
518 | .. _Placement Group Subsystem: ../control#placement-group-subsystem |