This chapter provides a brief introduction to some common storage management concepts.
This chapter contains the following information:
How you choose to manage your storage determines how you control the devices that store the active data on your system. To be useful, active data must be available and remain persistent even after unexpected events, such as a hardware or software failure.
There are many different devices on which data can be stored. The selection of devices to best meet your storage needs depends primarily on three factors:
Performance
Availability
Cost
You can use Solaris Volume Manager to help manage the trade-offs in performance, availability, and cost. You can often mitigate many of the trade-offs with Solaris Volume Manager.
Solaris Volume Manager works well with any supported storage on any system that runs the Solaris operating system.
RAID is an acronym for Redundant Array of Inexpensive (or Independent) Disks. RAID refers to a set of disks, called an array or a volume, that appears to the user as a single large disk drive. Depending on the configuration, this array provides improved reliability, response time, or storage capacity.
Technically, there are six RAID levels, 0-5. Each level refers to a method of distributing data while ensuring data redundancy. (RAID Level 0 does not provide data redundancy, but is usually included as a RAID classification anyway. RAID Level 0 provides the basis for the majority of RAID configurations in use.) Very few storage environments support RAID Levels 2, 3, and 4, so those environments are not described here.
Solaris Volume Manager supports the following RAID levels:
RAID LEVEL 0 – Although stripes and concatenations do not provide redundancy, these volumes are often referred to as RAID-0. Basically, data are spread across relatively small, equally-sized fragments that are allocated alternately and evenly across multiple physical disks. Any single drive failure can cause data loss. RAID-0 offers a high data transfer rate and high I/O throughput, but suffers lower reliability and lower availability than a single disk.
RAID Level 1 – Mirroring uses equal amounts of disk capacity to store data and a copy (mirror) of the data. Data is duplicated, or mirrored, over two or more physical disks. Data can be read from both drives simultaneously, meaning that either drive can service any request, which provides improved performance. If one physical disk fails, you can continue to use the mirror with no loss in performance or loss of data.
Solaris Volume Manager supports both RAID-0+1 and (transparently) RAID-1+0 mirroring, depending on the underlying volumes. See Providing RAID-1+0 and RAID-0+1 for details.
RAID Level 5 – RAID-5 uses striping to spread the data over the disks in an array. RAID-5 also records parity information to provide some data redundancy. A RAID-5 volume can withstand the failure of an underlying device without failing. If a RAID-5 volume is used in conjunction with hot spares, the volume can withstand multiple failures without failing. A RAID-5 volume will have a substantial performance degradation when operating with a failed device.
In the RAID-5 model, every device has one area that contains a parity stripe and other areas that contain data. The parity is spread over all of the disks in the array, which reduces the write time. Write time is reduced because writes do not have to wait until a dedicated parity disk can accept the data.
When you are planning your storage management configuration, keep in mind that for any given configuration, there are trade-offs in performance, availability, and hardware costs. You might need to experiment with the different variables to determine what works best for your configuration.
This section provides guidelines for working with the following types of volumes:
RAID-0 (concatenation and stripe) volumes
RAID-1 (mirror) volumes
RAID-5 volumes
Soft partitions
File systems that are constructed on Solaris Volume Manager volumes
Before you implement your storage management approach, you need to decide what kinds of storage devices to use. This set of guidelines compares the various types of storage to help you choose. Additional sets of guidelines apply to specific types of storage as implemented in Solaris Volume Manager. See specific chapters about each volume type for details.
The types of storage that are listed here are not mutually exclusive. You can use these volumes in combination to meet multiple goals. For example, you could first create a RAID-1 volume for redundancy. Next, you could create soft partitions on that RAID-1 volume to increase the possible number of discrete file systems.
The following table provides a comparison between the features available for each type of storage.
Table 2–1 Comparison of Types of Storage
Requirements |
RAID-0 (Concatenation) |
RAID-0 (Stripe) |
RAID-1 (Mirror) |
RAID-5 |
Soft Partitions |
---|---|---|---|---|---|
Redundant data |
No |
No |
Yes |
Yes |
No |
Improved read performance |
No |
Yes |
Depends on underlying device |
Yes |
No |
Improved write performance |
No |
Yes |
No |
No |
No |
More than 8 slices per device |
No |
No |
No |
No |
Yes |
Larger available storage space |
Yes |
Yes |
No |
Yes |
No |
The following table outlines the trade-offs in write operations, random reads, and hardware costs between RAID-1 and RAID–5 volumes.
Table 2–2 Optimizing Redundant Storage
RAID-1 (Mirror) |
RAID-5 |
|
---|---|---|
Write operations |
Faster |
Slower |
Random read |
Faster |
Slower |
Hardware cost |
Higher |
Lower |
The following list summarizes the information outlined in the tables:
RAID-0 volumes (stripes and concatenations) and soft partitions do not provide any redundancy of data.
Concatenation works well for small random I/O operations.
Striping performs well for large sequential I/O operations and for random I/O operations.
Mirroring might improve read performance, but write performance is always degraded in mirrors.
Because of the read-modify-write nature of RAID-5 volumes, volumes with over 20 percent writes should not be RAID-5. If redundancy is required, consider mirroring.
RAID-5 writes cannot be as fast as mirrored writes, which in turn cannot be as fast as unprotected writes.
Soft partitions are useful for managing very large storage devices.
In addition to these generic storage options, see Hot Spare Pools for more information about using Solaris Volume Manager to support redundant devices.
When you design your storage configuration, consider the following performance guidelines:
Striping generally has the best performance, but striping offers no data redundancy. For write-intensive applications, RAID-1 volumes generally have better performance than RAID-5 volumes.
RAID-1 and RAID-5 volumes both increase data availability, but both types of volumes generally have lower performance for write operations. Mirroring does improve random read performance.
RAID-5 volumes have a lower hardware cost than RAID-1 volumes, while RAID-0 volumes have no additional hardware cost.
Both stripes and RAID-5 volumes distribute data across multiple disk drives and help balance the I/O load.
Identify the most frequently accessed data, and increase access bandwidth to that data with mirroring or striping.
Use available performance monitoring capabilities and generic tools such as the iostat command to identify the most frequently accessed data. Once identified, the access bandwidth to this data can be increased using striping, RAID-1 volumes or RAID-5 volumes.
The performance of soft partitions can degrade when the soft partition size is changed multiple times.
RAID-5 volume performance is lower than stripe performance for write operations. This performance penalty results from the multiple I/O operations required to calculate and store the RAID-5 volume parity.
For raw random I/O reads, the stripe and the RAID-5 volume are comparable. Both the stripe and RAID-5 volumes split the data across multiple disks. RAID-5 volume parity calculations are not a factor in reads except after a slice failure.
For raw random I/O writes, the stripe is superior to RAID-5 volumes.
For configuration guidelines specific to Solaris Volume Manager, see Solaris Volume Manager Configuration Guidelines.
This section explains strategies for optimizing your configuration.
If you do not know if sequential I/O or random I/O predominates on the Solaris Volume Manager volumes you are creating, do not implement these performance tuning tips. These tips can degrade performance if the tips are improperly implemented.
The following optimization suggestions assume that you are optimizing a RAID-0 volume. In general, you would want to optimize a RAID-0 volume, then mirror that volume to provide both optimal performance and data redundancy.
In a random I/O environment, such as an environment used for databases and general-purpose file servers, all disks should spend equal amounts of time servicing I/O requests.
For example, assume that you have 40 Gbytes of storage for a database application. If you stripe across four 10 Gbyte disk spindles, and if the I/O is random and evenly dispersed across the volume, then each of the disks will be equally busy, which generally improves performance.
The target for maximum random I/O performance on a disk is 35 percent or lower usage, as reported by the iostat command. Disk use in excess of 65 percent on a typical basis is a problem. Disk use in excess of 90 percent is a significant problem. The solution to having disk use values that are too high is to create a new RAID-0 volume with more disks (spindles).
Simply attaching additional disks to an existing volume cannot improve performance. You must create a new volume with the ideal parameters to optimize performance.
The interlace size of the stripe does not matter because you just want to spread the data across all the disks. Any interlace value greater than the typical I/O request will suffice.
You can optimize the performance of your configuration in a sequential I/O environment, such as DBMS servers that are dominated by full table scans and NFS servers in very data-intensive environments. To take advantage of a sequential I/O environment, set the interlace value low relative to the size of the typical I/O request.
For example, assume a typical I/O request size of 256 Kbytes and striping across 4 spindles. A good choice for the stripe unit size in this example would be:
256 Kbytes / 4 = 64 Kbytes, or smaller
This strategy ensures that the typical I/O request is spread across multiple disk spindles, thus increasing the sequential bandwidth.
Seek time and rotation time are practically zero in the sequential I/O environment. When you optimize sequential I/O, the internal transfer rate of a disk is most important.
In sequential applications, the typical I/O size is usually large, meaning more than 128 Kbytes or even more than 1 Mbyte. Assume an application with a typical I/O request size of 256 Kbytes and assume striping across 4 disk spindles, thus:
256 Kbytes / 4 = 64 Kbytes
So, a good choice for the interlace size would be 32–64 Kbytes.