[Bug 1922561] Re: osd shutdown may flood the cluster log with 'osd.X reported immediately failed by osd.Y'

Mauricio Faria de Oliveira 1922561 at bugs.launchpad.net
Fri May 14 12:05:04 UTC 2021


New ceph hotfix releases for Nautilus (v14.2.21) and Octopus (v15.2.12)
have pushed this another release further.

** Description changed:

  [Impact]
  
  The `osd_fast_shutdown` option (available in Nautilus and enabled
  by default) may cause the cluster log to receive too many entries
  of `osd.X reported immediately failed by osd.Y` on large clusters.
  
  This happens as the monitor no longer receives the OSD message to
  notify that the OSD is shutting down and now relies on other OSDs
  telling it about the failed OSD (not really 'failed' but shutdown.)
  
  This might be an issue for LMA stacks/tools that check ceph logs
  for failed lines, and then require additional logic to filter on
  an intended OSD (fast) shutdown; might not be an option/possible,
  and require an admin to analyze.
  
  [Fix]
  
  The `osd_fast_shutdown_notify_mon` option for OSDs (disabled by
  default) can tell the monitor it is shutting down (done in slow/
  non-fast shutdown) under `osd_fast_shutdown`.
  
  This introduces minimal delay (the ack from the mon is required
  to prevent the messages), and addresses the cluster log issue.
  PS: the `osd_mon_shutdown_timeout` option can be used to control
  the maximum amount of time waiting for the monitor ack to arrive.
  
  The new option should be available in the following Ceph releases:
  - Pacific 16.2.0 [1] [Hirsute+]
- - Octopus 15.2.12 [2] [Focal/Groovy; Ussuri+]
- - Nautilus 14.2.21) [3] [Eoan is EOL; Train]
+ - Octopus 15.2.13 [2] [Focal/Groovy; Ussuri+]
+ - Nautilus 14.2.22) [3] [Eoan is EOL; Train]
  
  This bug tracks the release of this patch in Ubuntu/Cloud Archive.
  
  [Test Case]
  
  - Stop an OSD and watch the OSD and MON logs.
  
  - Before / or with `osd_fast_shutdown_notify_mon = false`:
  
  ```
  osd log:
  
  2021-01-09T18:59:52.448+0000 7f937fcdc700 -1 received  signal: Terminated from -bash  (PID: 408) UID: 1000
  2021-01-09T18:59:52.448+0000 7f937fcdc700 -1 osd.2 22 *** Got signal Terminated ***
  2021-01-09T18:59:52.448+0000 7f937fcdc700 -1 osd.2 22 *** Immediate shutdown (osd_fast_shutdown=true) ***
  
  mon log:
  
  $ cat out/mon.a.log | grep '^2021-01-09T18:59:' | grep 'osd.0 reported immediately failed by osd.' | rev | cut -d: -f1 | rev | sort | uniq -c
        4  osd.0 reported immediately failed by osd.1
        4  osd.0 reported immediately failed by osd.2
        4  osd.0 reported immediately failed by osd.3
        4  osd.0 reported immediately failed by osd.4
        4  osd.0 reported immediately failed by osd.5
        4  osd.0 reported immediately failed by osd.6
        4  osd.0 reported immediately failed by osd.7
        4  osd.0 reported immediately failed by osd.8
        4  osd.0 reported immediately failed by osd.9
  ```
  
  - After / with `osd_fast_shutdown_notify_mon = true`:
  
  ```
  osd log:
  
  2021-01-14T17:21:10.825+0000 7feceded1700 -1 received  signal: Terminated from -bash  (PID: 1750) UID: 1000
  2021-01-14T17:21:10.825+0000 7feceded1700 -1 osd.0 80 *** Got signal Terminated ***
  2021-01-14T17:21:10.825+0000 7feceded1700 -1 osd.0 80 *** Immediate shutdown (osd_fast_shutdown=true) ***
  2021-01-14T17:21:10.825+0000 7feceded1700  0 osd.0 80 prepare_to_stop telling mon we are shutting down
  ...
  2021-01-14T17:21:11.021+0000 7fecdac0c700  0 osd.0 80 got_stop_ack starting shutdown
  2021-01-14T17:21:11.021+0000 7feceded1700  0 osd.0 80 prepare_to_stop starting shutdown
  
  mon log:
  
  2021-01-14T17:21:10.829+0000 7f62fce61700  0 log_channel(cluster) log [INF] : osd.0 marked itself down
  2021-01-14T17:21:10.885+0000 7f62ff666700  1 mon.a at 0(leader).osd e80 do_prune osdmap full prune enabled
  2021-01-14T17:21:10.889+0000 7f62ff666700  0 log_channel(cluster) log [WRN] : Health check failed: 1 osds down (OSD_DOWN)
  2021-01-14T17:21:10.957+0000 7f62fb65e700  1 mon.a at 0(leader).osd e81 e81: 10 total, 9 up, 10 in
  2021-01-14T17:21:11.013+0000 7f62fb65e700  0 log_channel(cluster) log [DBG] : osdmap e81: 10 total, 9 up, 10 in
  ```
  
  [Where problems could occur]
  
  Any regression from this patch should manifest in OSD shutdown, but only
  when the option is enabled.
  
  The patch is quite small and contained to the OSD shutdown path.
  
  It is effectively a nop when the option is disabled (by default).
  
  It is a small change from the newly introduced default behavior,
  but it just re-introduces a message in the shutdown path, which
  is how it used to be done on previous releases and even earlier
  stable releases in Nautilus.
  
  [1] https://tracker.ceph.com/issues/49683
  [2] https://tracker.ceph.com/issues/49681
  [3] https://tracker.ceph.com/issues/49682

-- 
You received this bug notification because you are a member of Ubuntu
OpenStack, which is subscribed to ceph in Ubuntu.
https://bugs.launchpad.net/bugs/1922561

Title:
  osd shutdown may flood the cluster log with 'osd.X reported
  immediately failed by osd.Y'

Status in Ubuntu Cloud Archive:
  Invalid
Status in Ubuntu Cloud Archive train series:
  Confirmed
Status in Ubuntu Cloud Archive ussuri series:
  Confirmed
Status in Ubuntu Cloud Archive victoria series:
  Invalid
Status in Ubuntu Cloud Archive wallaby series:
  Invalid
Status in ceph package in Ubuntu:
  Fix Released
Status in ceph source package in Focal:
  Confirmed
Status in ceph source package in Groovy:
  Confirmed
Status in ceph source package in Hirsute:
  Fix Released

Bug description:
  [Impact]

  The `osd_fast_shutdown` option (available in Nautilus and enabled
  by default) may cause the cluster log to receive too many entries
  of `osd.X reported immediately failed by osd.Y` on large clusters.

  This happens as the monitor no longer receives the OSD message to
  notify that the OSD is shutting down and now relies on other OSDs
  telling it about the failed OSD (not really 'failed' but shutdown.)

  This might be an issue for LMA stacks/tools that check ceph logs
  for failed lines, and then require additional logic to filter on
  an intended OSD (fast) shutdown; might not be an option/possible,
  and require an admin to analyze.

  [Fix]

  The `osd_fast_shutdown_notify_mon` option for OSDs (disabled by
  default) can tell the monitor it is shutting down (done in slow/
  non-fast shutdown) under `osd_fast_shutdown`.

  This introduces minimal delay (the ack from the mon is required
  to prevent the messages), and addresses the cluster log issue.
  PS: the `osd_mon_shutdown_timeout` option can be used to control
  the maximum amount of time waiting for the monitor ack to arrive.

  The new option should be available in the following Ceph releases:
  - Pacific 16.2.0 [1] [Hirsute+]
  - Octopus 15.2.13 [2] [Focal/Groovy; Ussuri+]
  - Nautilus 14.2.22) [3] [Eoan is EOL; Train]

  This bug tracks the release of this patch in Ubuntu/Cloud Archive.

  [Test Case]

  - Stop an OSD and watch the OSD and MON logs.

  - Before / or with `osd_fast_shutdown_notify_mon = false`:

  ```
  osd log:

  2021-01-09T18:59:52.448+0000 7f937fcdc700 -1 received  signal: Terminated from -bash  (PID: 408) UID: 1000
  2021-01-09T18:59:52.448+0000 7f937fcdc700 -1 osd.2 22 *** Got signal Terminated ***
  2021-01-09T18:59:52.448+0000 7f937fcdc700 -1 osd.2 22 *** Immediate shutdown (osd_fast_shutdown=true) ***

  mon log:

  $ cat out/mon.a.log | grep '^2021-01-09T18:59:' | grep 'osd.0 reported immediately failed by osd.' | rev | cut -d: -f1 | rev | sort | uniq -c
        4  osd.0 reported immediately failed by osd.1
        4  osd.0 reported immediately failed by osd.2
        4  osd.0 reported immediately failed by osd.3
        4  osd.0 reported immediately failed by osd.4
        4  osd.0 reported immediately failed by osd.5
        4  osd.0 reported immediately failed by osd.6
        4  osd.0 reported immediately failed by osd.7
        4  osd.0 reported immediately failed by osd.8
        4  osd.0 reported immediately failed by osd.9
  ```

  - After / with `osd_fast_shutdown_notify_mon = true`:

  ```
  osd log:

  2021-01-14T17:21:10.825+0000 7feceded1700 -1 received  signal: Terminated from -bash  (PID: 1750) UID: 1000
  2021-01-14T17:21:10.825+0000 7feceded1700 -1 osd.0 80 *** Got signal Terminated ***
  2021-01-14T17:21:10.825+0000 7feceded1700 -1 osd.0 80 *** Immediate shutdown (osd_fast_shutdown=true) ***
  2021-01-14T17:21:10.825+0000 7feceded1700  0 osd.0 80 prepare_to_stop telling mon we are shutting down
  ...
  2021-01-14T17:21:11.021+0000 7fecdac0c700  0 osd.0 80 got_stop_ack starting shutdown
  2021-01-14T17:21:11.021+0000 7feceded1700  0 osd.0 80 prepare_to_stop starting shutdown

  mon log:

  2021-01-14T17:21:10.829+0000 7f62fce61700  0 log_channel(cluster) log [INF] : osd.0 marked itself down
  2021-01-14T17:21:10.885+0000 7f62ff666700  1 mon.a at 0(leader).osd e80 do_prune osdmap full prune enabled
  2021-01-14T17:21:10.889+0000 7f62ff666700  0 log_channel(cluster) log [WRN] : Health check failed: 1 osds down (OSD_DOWN)
  2021-01-14T17:21:10.957+0000 7f62fb65e700  1 mon.a at 0(leader).osd e81 e81: 10 total, 9 up, 10 in
  2021-01-14T17:21:11.013+0000 7f62fb65e700  0 log_channel(cluster) log [DBG] : osdmap e81: 10 total, 9 up, 10 in
  ```

  [Where problems could occur]

  Any regression from this patch should manifest in OSD shutdown, but
  only when the option is enabled.

  The patch is quite small and contained to the OSD shutdown path.

  It is effectively a nop when the option is disabled (by default).

  It is a small change from the newly introduced default behavior,
  but it just re-introduces a message in the shutdown path, which
  is how it used to be done on previous releases and even earlier
  stable releases in Nautilus.

  [1] https://tracker.ceph.com/issues/49683
  [2] https://tracker.ceph.com/issues/49681
  [3] https://tracker.ceph.com/issues/49682

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-archive/+bug/1922561/+subscriptions



More information about the Ubuntu-openstack-bugs mailing list