Redundancy in Disks Groups

From Open-E Wiki
Jump to navigation Jump to search

Disk group redundancy refers to the ability of a zpool to maintain data integrity and availability in the event of disk failures. This is achieved through mirrored or RAID-Z configurations, which store multiple copies of data across different disks. When a disk fails or data corruption is detected, ZFS can use the redundant copies to repair or reconstruct the lost data, ensuring the system continues to operate without data loss.

It is important not to mix the types of data groups (vdevs) inside your storage zpool, as it might lead to potential issues, so it is strongly recommended to consistently use only one type of vdev.


Data Group redundancy level: 2-way mirror (2 disks per group)

  • The chances of suffering multiple disk failures increase with the number of mirror vdevs in the zpool.
  • The 2-way mirror accepts a single disk failure in a given vdev.
  • The 2-way mirrors can be used for mission critical applications, but it is recommended not to exceed 12 vdevs in a zpool (recommended up to 12 x 2 = 24 disks for mission-critical applications and 24 x 2 = 48 disks for non-mission critical applications in a zpool).
  • Note: as a rule, the zpool performance increases with the number of vdevs in the pool. For mission-critical applications and using more than 12 groups, It is recommended to use 3-way mirrors or RAID-Z2 or RAID-Z3.
  • For mission critical applications it is not recommended to use HDDs bigger than 4TB.


Data Group redundancy level: 3-way mirror (3 disks per group)

  • The chances of suffering multiple disk failures increase with number of mirror vdevs in the zpool.
  • The 3-way mirror accepts up to two disks failures in a given vdev.
  • 3-way mirrors can be used for mission critical applications, but it is recommended not to exceed vdevs in a zpool (recommended up to 16 x 3 = 48 disks for mission critical applications and 24 x 3 = 72 disks for non-mission critical applications in a zpool).
  • Note: the zpool performance increases with the number of vdevs in a zpool. For mission-critical applications, it is recommended to use RAID-Z3.
  • For mission critical applications it is not recommended to use HDDs bigger than 10TB.


Data Group redundancy level: 4-way mirror (4 disks per group)

  • The chances of suffering multiple disk failures increase with number of mirror vdevs in the zpool.
  • The 4-way mirror accepts up to three disks failures in a given vdev.
  • The 4-way mirror is recommended for a Non-Shared HA Cluster that can be used for mission-critical applications.
  • It is also recommended not to exceed 24 of 4-way mirror vdevs in a zpool as a single group damage results in the destruction of the entire zpool (recommended up to 24 x 4 = 96 disks for mission-critical applications in a zpool).
  • Note: as a rule, the zpool performance increases with the number of vdev in the pool.
  • HDDs bigger than 16TB should be avoided for mission critical applications.


Data Group redundancy level: RAIDZ-1 (3-8 disks in a group)

  • The chances of suffering multiple disk failures increase with the number of disks in a RAID-Z1 vdev.
  • RAID-Z1 accepts one disk failure in a given vdev.
  • The RAID-Z1 can be used for non-mission critical applications and it is not recommended to exceed 8 disks in a vdev. HDDs bigger than 4TB should be avoided.
  • It is also not recommended to exceed 8 RAID-Z1 vdevs in a zpool as a single group damage results in the destruction of entire zpool (recommended up to 8 x 8 = 64 disks for non-mission critical applications in a zpool).
  • RAID-Z1 configuration is not possible in a Non-Shared HA Cluster configuration.
  • Note: the zpool performance is doubled with 2 x RAID-Z1 with 4 disks each comparing to a single RAID-Z1 vdev with 8 disks.


Data Group redundancy level: RAIDZ-2 (4-24 disks per group)

  • The chances of suffering multiple disk failures increase with the number of disks in the RAID-Z2 group.
  • The RAID-Z2 accepts up to two disks failures in a given vdev.
  • The RAID-Z2 can be used for mission-critical applications.
  • It is not recommended to exceed 12 disks in a vdev for mission-critical and 24 disks for non-mission critical applications.
  • It is also not recommended to exceed 16 of RAID-Z2 groups in a zpool as a single group damage results in the destruction of the entire zpool (recommended up to 16 x 12 = 192 disks for mission-critical applications and 16 x 24 = 384 disks for non-mission critical in a zpool). HDDs bigger than 16 TB should be avoided.
  • If 3 disks failure in a vdev is required, it is recommended to use RAID-Z3.
  • RAID-Z2 configuration is not possible in a Non-Shared HA Cluster configuration.
  • Note: the pool performance is doubled with 2 x RAID-Z2 with 6 disks each comparing to a single RAID-Z2 with 12 disks.


Data Group redundancy level: RAIDZ-3 (5-48 disks per group)

  • The chances of suffering multiple disk failures increase with the number of disks in the RAID-Z3 group.
  • The RAID-Z3 accepts up to three disks failure in a given vdev.
  • The RAID-Z3 can be used for mission-critical applications.
  • It is not recommended to exceed 24 disks in a vdev for mission-critical and 48 disks for non- mission critical applications.
  • It is also not recommended to exceed 24 of RAID-Z3 groups in a zpool as a single group damage results in the destruction of the entire zpool (recommended up to 24x 24 =576 disks for mission critical applications and 24x 48 = 1152 disks for non-mission critical applications in a zpool). HDDs bigger than 16TB should be avoided.
  • RAID-Z3 configuration is not possible in a Non-Shared HA Cluster configuration.
  • Note: the zpool performance is doubled with 2 x RAID-Z3 with 12 disks each comparing to single RAID-Z3 vdev with 24 disks.


Write Log redundancy level

  • In both single nodes and HA clusters, it should be configured as a 2-way mirror.
  • When choosing a disk model for the Write Log, make sure to take the endurance parameter into consideration. Selecting a disk classified by the manufacturer as write intensive is strongly recommended.
  • When selecting a disk size for the write log, consider the potential amount of data that’ll be able to reach the server in three consecutive ZFS transactions, e.g. based on the network card bandwidth for the data transfer. If the transaction length is set to 5 seconds (default), the write log device should be able to accommodate the amount of data that can be transferred within three transaction groups, i.e. 15 seconds of writing. Using a larger disk does not make sense economically, while a smaller one can be a performance bottleneck during synchronous writes. Practically speaking, 100GB for a write log should be more than enough.


Read Cache redundancy level

Read Cache disks can only be configured as single disks, but it is possible to configure any number of them. In an HA cluster, Read Cache can only be configured as local disks on both nodes on the cluster.


Special devices and deduplication group redundancy level

In both single nodes and HA clusters, it should be configured as a 2-way mirror.

Retrieved from "https://wiki.open-e.com/default/wiki/index.php?title=Redundancy_in_Disks_Groups&oldid=12196"