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