Chapter 3 Hot Spare Pools

This chapter explains hot spare pools. Use the following table to proceed directly to the section that provides the information you need.

• "Overview of Hot Spare Pools and Hot Spares"

• "Hot Spares"

• "Hot Spare Pools"

• "Administering Hot Spare Pools"

Overview of Hot Spare Pools and Hot Spares

A hot spare pool is an ordered list (collection) of slices (hot spares) that DiskSuite uses to provide increased data availability for mirrors and RAID5 metadevices. A hot spare is reserved by DiskSuite to be automatically substituted in case of a slice failure in either a submirror or RAID5 metadevice.

A hot spare cannot be used to hold data while it is idle. A hot spare must remain ready for immediate use in the event of a slice failure in the metadevice with which it is associated. Because of the way in which hot spares operate, an additional investment in disks is necessary.

Hot Spares

A hot spare is a slice (not a metadevice) that is running but not in use. It is reserved, meaning that the hot spare stands ready to substitute for an errored slice in a submirror or RAID5 metadevice.

Because slice replacement and the resyncing of failed slices is automatic, hot spares provide protection from hardware failure. The hot spare can be used temporarily until a failed submirror or RAID5 metadevice slice is either fixed or replaced.

Hot spares remain idle most of the time, and so do not contribute to normal system operation. In addition, slices designated as hot spares cannot be used in any other metadevice, nor can they be used to hold data while idle.

You create hot spares within hot spare pools. Individual hot spares can be included in one or more hot spare pools. For example, you may have two submirrors and two hot spares. The hot spares can be arranged as two hot spare pools, with each pool having the two hot spares in a different order of preference. This enables you to specify which hot spare is used first. It also improves availability by having more hot spares available.

You cannot use hot spares within other metadevices, for example within a submirror. They must remain ready for immediate use in the event of a slice failure. A hot spare must be a physical slice. It cannot be a metadevice. In addition, hot spares cannot be used to hold state database replicas.

A submirror or RAID5 metadevice can use only a hot spare whose size is equal to or greater than the size of the failed slice in the submirror or RAID5 metadevice. If, for example, you have a submirror made of 1 Gbyte drives, a hot spare for the submirror must be 1 Gbyte or greater.

A prerequisite for hot spares is that the metadevices with which they are associated have replicated data. When a hot spare takes over, any data on the failed slice must be recreated. For this reason, only mirrors and RAID5 metadevices use hot spares.

Hot Spare Pools

A hot spare pool is an ordered list (collection) of hot spares.

You can place hot spares into one or more pools to get the most security from the fewest slices. Then, a hot spare pool can be assigned to any number of submirror metadevices or RAID5 metadevices.

You can assign a single hot spare pool to multiple submirrors or RAID5 metadevices. On the other hand, a submirror or a RAID5 metadevice can be associated with only one hot spare pool.

When errors occur, DiskSuite checks the hot spare pool for the first available hot spare whose size is equal to or greater than the size of the slice being replaced. If found, DiskSuite changes the hot spare's status to "In-Use" and automatically resyncs the data. In the case of a mirror, the hot spare is resynced with data from a good submirror. In the case of a RAID5 metadevice, the hot spare is resynced with the other slices in the metadevice. If a slice of adequate size is not found in the list of hot spares, the submirror or RAID5 metadevice that failed goes into an "errored" state. In the case of the submirror, it no longer replicates the data which that slice represented. In the case of the RAID5 metadevice, data redundancy is no longer available.

Hot Spare Pool Conventions

• How are hot spare pools named?

  Hot spare pools are named hspnnn, where nnn is in the range 000-999.

• What are "empty" hot spare pools?

  You can create empty hot spare pools, enabling you to add hot spares when they become available.

• How many hot spare pools are permitted?

  1000.

• Must a hot spare be a physical device?

  Yes. It cannot be a metadevice.

• How does the hot spare replacement algorithm work?

  When a slice in a submirror or RAID5 metadevice goes into the "errored" state, a slice from the associated hot spare pool is used to replace it. DiskSuite selects the first hot spare (slice) that is large enough to replace the errored slice.

  DiskSuite searches a hot spare pool for a hot spare based on the order in which hot spares are added to a hot spare pool. The first hot spare found that is large enough is used as a replacement. When adding hot spares to a hot spare pool, it is best to add them from smallest to largest. This avoids potentially wasting "large" hot spares as replacements for small slices.

• What are the size requirements for hot spares?

  Hot spares must be equal to or greater than the smallest slice in the submirror or RAID5 metadevice with which the hot spare pool is associated. If DiskSuite cannot substitute an appropriately sized hot spare for a failed slice in a submirror or RAID5 metadevice, hot sparing will not occur for that metadevice.

• Can a hot spare pool be associated with a "normal" stripe?

  No. Hot sparing can only be used for mirrors and RAID5 metadevices. A hot spare pool must be associated with a submirror or a RAID5 metadevice.

• What should I do if no hot spares are marked as Available?

  Some hot spares must be marked as Available. If all hot spares are marked In-Use, you should either add more hot spares to the hot spare pool or repair the spared slices and return them to service.

• Can I assign a hot spare pool to a one-way mirror?

  Do not assign a hot spare pool to a submirror in a one-way mirror. Failed slices in a one-way mirror cannot be replaced by a hot spare. In these metadevices, no other copy of data is available to reconstruct on the hot spare.

• Why should hot spares be defined on different controllers?

  To maximize their availability in case of controller errors or failures.

Example -- Hot Spare Pool

Figure 3-1 illustrates a hot spare pool, hsp000, that is associated with submirrors d11 and d12 in mirror d1. If a slice in either submirror were to become errored, a hot spare slice would automatically be substituted for the errored slice. The hot spare pool itself is associated with each submirror metadevice, not the mirror. The hot spare pool could also be associated with other submirrors or RAID5 metadevices if desired.

Figure 3-1 Hot Spare Pool Example

Administering Hot Spare Pools

DiskSuite enables you to dynamically add, delete, replace, and enable hot spares within hot spare pools. You can use either DiskSuite Tool or the command line utilities to administer hot spares and hot spare pools.

You can add a hot spare to one or more hot spare pools. When you add a hot spare to a hot spare pool, it is added to the end of the list of slices in the hot spare pool.

You can delete a hot spare from any or all of the hot spare pools to which it has been associated. Once the hot spare is deleted, the order of the remaining hot spares in the hot spare pool changes to reflect the new position. For example, if the second of three hot spares is deleted, the third hot spare moves to the second position. You cannot delete a hot spare that is currently in-use.

You can replace a hot spare in any or all of the hot spare pools to which it has been associated. The order of hot spares does not change after a replacement. You cannot replace a hot spare that is currently in use.

If a hot spare needs to be repaired, you make it available again by enabling it.

See Solstice DiskSuite 4.2.1 User's Guide for information on adding, deleting, replacing, and enabling hot spares.