mirror_zfs/cmd/zed/agents
Brian Behlendorf b2255edcc0
Distributed Spare (dRAID) Feature
This patch adds a new top-level vdev type called dRAID, which stands
for Distributed parity RAID.  This pool configuration allows all dRAID
vdevs to participate when rebuilding to a distributed hot spare device.
This can substantially reduce the total time required to restore full
parity to pool with a failed device.

A dRAID pool can be created using the new top-level `draid` type.
Like `raidz`, the desired redundancy is specified after the type:
`draid[1,2,3]`.  No additional information is required to create the
pool and reasonable default values will be chosen based on the number
of child vdevs in the dRAID vdev.

    zpool create <pool> draid[1,2,3] <vdevs...>

Unlike raidz, additional optional dRAID configuration values can be
provided as part of the draid type as colon separated values. This
allows administrators to fully specify a layout for either performance
or capacity reasons.  The supported options include:

    zpool create <pool> \
        draid[<parity>][:<data>d][:<children>c][:<spares>s] \
        <vdevs...>

    - draid[parity]       - Parity level (default 1)
    - draid[:<data>d]     - Data devices per group (default 8)
    - draid[:<children>c] - Expected number of child vdevs
    - draid[:<spares>s]   - Distributed hot spares (default 0)

Abbreviated example `zpool status` output for a 68 disk dRAID pool
with two distributed spares using special allocation classes.

```
  pool: tank
 state: ONLINE
config:

    NAME                  STATE     READ WRITE CKSUM
    slag7                 ONLINE       0     0     0
      draid2:8d:68c:2s-0  ONLINE       0     0     0
        L0                ONLINE       0     0     0
        L1                ONLINE       0     0     0
        ...
        U25               ONLINE       0     0     0
        U26               ONLINE       0     0     0
        spare-53          ONLINE       0     0     0
          U27             ONLINE       0     0     0
          draid2-0-0      ONLINE       0     0     0
        U28               ONLINE       0     0     0
        U29               ONLINE       0     0     0
        ...
        U42               ONLINE       0     0     0
        U43               ONLINE       0     0     0
    special
      mirror-1            ONLINE       0     0     0
        L5                ONLINE       0     0     0
        U5                ONLINE       0     0     0
      mirror-2            ONLINE       0     0     0
        L6                ONLINE       0     0     0
        U6                ONLINE       0     0     0
    spares
      draid2-0-0          INUSE     currently in use
      draid2-0-1          AVAIL
```

When adding test coverage for the new dRAID vdev type the following
options were added to the ztest command.  These options are leverages
by zloop.sh to test a wide range of dRAID configurations.

    -K draid|raidz|random - kind of RAID to test
    -D <value>            - dRAID data drives per group
    -S <value>            - dRAID distributed hot spares
    -R <value>            - RAID parity (raidz or dRAID)

The zpool_create, zpool_import, redundancy, replacement and fault
test groups have all been updated provide test coverage for the
dRAID feature.

Co-authored-by: Isaac Huang <he.huang@intel.com>
Co-authored-by: Mark Maybee <mmaybee@cray.com>
Co-authored-by: Don Brady <don.brady@delphix.com>
Co-authored-by: Matthew Ahrens <mahrens@delphix.com>
Co-authored-by: Brian Behlendorf <behlendorf1@llnl.gov>
Reviewed-by: Mark Maybee <mmaybee@cray.com>
Reviewed-by: Matt Ahrens <matt@delphix.com>
Reviewed-by: Tony Hutter <hutter2@llnl.gov>
Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Closes #10102
2020-11-13 13:51:51 -08:00
..
fmd_api.c Fix typos in cmd/ 2019-08-30 09:43:30 -07:00
fmd_api.h Add illumos FMD ZFS logic to ZED -- phase 2 2016-11-07 15:01:38 -08:00
fmd_serd.c Fix typos in cmd/ 2019-08-30 09:43:30 -07:00
fmd_serd.h Add illumos FMD ZFS logic to ZED -- phase 2 2016-11-07 15:01:38 -08:00
README.md Add illumos FMD ZFS logic to ZED -- phase 2 2016-11-07 15:01:38 -08:00
zfs_agents.c Replace ZFS on Linux references with OpenZFS 2020-10-08 20:10:13 -07:00
zfs_agents.h Various ZED fixes 2017-12-08 16:58:41 -08:00
zfs_diagnosis.c Update build system and packaging 2018-05-29 16:00:33 -07:00
zfs_mod.c Distributed Spare (dRAID) Feature 2020-11-13 13:51:51 -08:00
zfs_retire.c Distributed Spare (dRAID) Feature 2020-11-13 13:51:51 -08:00

Fault Management Logic for ZED

The integration of Fault Management Daemon (FMD) logic from illumos is being deployed in three phases. This logic is encapsulated in several software modules inside ZED.

ZED+FM Phase 1

All the phase 1 work is in current Master branch. Phase I work includes:

  • Add new paths to the persistent VDEV label for device matching.
  • Add a disk monitor for generating disk-add and disk-change events.
  • Add support for automated VDEV auto-online, auto-replace and auto-expand.
  • Expand the statechange event to include all VDEV state transitions.

ZED+FM Phase 2 (WIP)

The phase 2 work primarily entails the Diagnosis Engine and the Retire Agent modules. It also includes infrastructure to support a crude FMD environment to host these modules. For additional information see the FMD Components in ZED and Implementation Notes sections below.

ZED+FM Phase 3

Future work will add additional functionality and will likely include:

  • Add FMD module garbage collection (periodically call fmd_module_gc()).
  • Add real module property retrieval (currently hard-coded in accessors).
  • Additional diagnosis telemetry (like latency outliers and SMART data).
  • Export FMD module statistics.
  • Zedlet parallel execution and resiliency (add watchdog).

ZFS Fault Management Overview

The primary purpose with ZFS fault management is automated diagnosis and isolation of VDEV faults. A fault is something we can associate with an impact (e.g. loss of data redundancy) and a corrective action (e.g. offline or replace a disk). A typical ZFS fault management stack is comprised of error detectors (e.g. zfs_ereport_post()), a disk monitor, a diagnosis engine and response agents.

After detecting a software error, the ZFS kernel module sends error events to the ZED user daemon which in turn routes the events to its internal FMA modules based on their event subscriptions. Likewise, if a disk is added or changed in the system, the disk monitor sends disk events which are consumed by a response agent.

FMD Components in ZED

There are three FMD modules (aka agents) that are now built into ZED.

  1. A Diagnosis Engine module (agents/zfs_diagnosis.c)
  2. A Retire Agent module (agents/zfs_retire.c)
  3. A Disk Add Agent module (agents/zfs_mod.c)

To begin with, a Diagnosis Engine consumes per-vdev I/O and checksum ereports and feeds them into a Soft Error Rate Discrimination (SERD) algorithm which will generate a corresponding fault diagnosis when the tracked VDEV encounters N events in a given T time window. The initial N and T values for the SERD algorithm are estimates inherited from illumos (10 errors in 10 minutes).

In turn, a Retire Agent responds to diagnosed faults by isolating the faulty VDEV. It will notify the ZFS kernel module of the new VDEV state (degraded or faulted). The retire agent is also responsible for managing hot spares across all pools. When it encounters a device fault or a device removal it will replace the device with an appropriate spare if available.

Finally, a Disk Add Agent responds to events from a libudev disk monitor (EC_DEV_ADD or EC_DEV_STATUS) and will online, replace or expand the associated VDEV. This agent is also known as the zfs_mod or Sysevent Loadable Module (SLM) on the illumos platform. The added disk is matched to a specific VDEV using its device id, physical path or VDEV GUID.

Note that the auto-replace feature (aka hot plug) is opt-in and you must set the pool's autoreplace property to enable it. The new disk will be matched to the corresponding leaf VDEV by physical location and labeled with a GPT partition before replacing the original VDEV in the pool.

Implementation Notes

  • The FMD module API required for logic modules is emulated and implemented in the fmd_api.c and fmd_serd.c source files. This support includes module registration, memory allocation, module property accessors, basic case management, one-shot timers and SERD engines. For detailed information on the FMD module API, see the document -- "Fault Management Daemon Programmer's Reference Manual".

  • The event subscriptions for the modules (located in a module specific configuration file on illumos) are currently hard-coded into the ZED zfs_agent_dispatch() function.

  • The FMD modules are called one at a time from a single thread that consumes events queued to the modules. These events are sourced from the normal ZED events and also include events posted from the diagnosis engine and the libudev disk event monitor.

  • The FMD code modules have minimal changes and were intentionally left as similar as possible to their upstream source files.

  • The sysevent namespace in ZED differs from illumos. For example:

    • illumos uses "resource.sysevent.EC_zfs.ESC_ZFS_vdev_remove"
    • Linux uses "sysevent.fs.zfs.vdev_remove"
  • The FMD Modules port was produced by Intel Federal, LLC under award number B609815 between the U.S. Department of Energy (DOE) and Intel Federal, LLC.