Skip to main content

We've Moved!

Product Documentation has moved to docs.hitachivantara.com
Hitachi Vantara Knowledge

System drive groups and dynamic write balancing

When used with a storage pool based on parity groups (RAID groups), dynamic write balancing ensures that the NAS server writes to all SDs in parallel, improving performance over older releases. Dynamic write balancing also improves flexibility by letting the server reflect the physical characteristics of the storage without the need to reconfigure spans.

Dynamic write balancing is enabled by default for storage pools. To implement dynamic write balancing, the NAS server requires some knowledge of the physical configuration of the storage. After SD groups have been configured (when using multiple logical devices from a single parity group of spinning disk), write operations are associated with SD groups rather than with SDs. Within each SD group, the NAS server scans the whole of one SD for free space before moving on to the next SD. For more information on SD Groups, see the sd-group man page.

NoteDynamic write balancing can also be used with HDP. With two or more HDP pools, it helps to balance load across all available storage. Even with two or more stripesets on a single HDP pool, it maximizes the use of the available queue depth.

Optimizing dynamic write balancing performance

Although dynamic write balancing removes many of the restrictions of older allocation schemes, a few important guidelines still apply:

  • Note Some software user interfaces have their own algorithms, usually creating even numbers of SDs in a stripe set
  • Never divide storage into dozens of tiny SDs, and then create a storage pool from the many small SDs.

All the SDs in a RAID group or an HDP pool should be used in the same storage pool. If multiple SDs in an SD group are shared between storage pools, the SD group mechanism will not prevent the server from writing to several of the shared SDs at once. Writing to several of the shared SDs at once can cause a performance reduction, because one HDP pool may be driving the storage pool very hard, causing a slow-down on the other storage pools using the same resources.

Troubleshooting system drive groups

To help with server to storage troubleshooting, keep the following in mind:

  • The server logs an event when a system drive becomes degraded on an HUS 100 family system. For example:

    Warning: Device 0 (span "SPAN" ID 5B95587A30A2A328) : Device reporting : SD 0: SCSI Lan Sense LU status reports DEGRADED"

  • A trouble command reporter will identify an SD that may have higher than average response times.

  • The output of the scsi-devices command includes the internal LUN value of any SD.

  • For solutions with Hitachi Universal Replicator and TrueCopy, if the primary SDs are visible only to one server (or cluster) and the secondaries only to another server (or cluster), the sd-mirror-remotely command must be used to add SD mirror relationship information to the server's the internal database.

 

  • Was this article helpful?