CONFIGURING ftscalable STORAGE ARRAYS ON OpenVOS SYSTEMS

Transcription

1 Best Practices CONFIGURING ftscalable STORAGE ARRAYS ON OpenVOS SYSTEMS

2 Best Practices 2 Abstract ftscalable TM Storage G1, G2 and G3 arrays are highly flexible, scalable hardware storage subsystems that offer a variety of configuration options for capacity, performance, and availability. Understanding the benefits and pitfalls of the various configuration options, especially how they interact with the OpenVOS operating system, allows you to create an optimal disk topology. This white paper details the various RAID types supported by ftscalable Storage, outlining their strengths and weaknesses, typical usages, and ways to design a disk topology best suited to your OpenVOS application. NOTE: The Glossary of terms on pages 10 and 11 define some of the common storage-industry terms used in this document. Operating system data versus user data New VOS systems ship with pre-initialized system disk, usually named sid_master_disk. This disk is intended to support operating system files, data, logs, and configuration information. Do not place your own user data (files, programs, logs, etc.) on this disk. Instead, create one or more data disks for your information. In addition to defining a clear separation between system data and user data, there is also a performance advantage. Each virtual disk (VDISK) or storage pool is assigned to one of two storage controllers, and so using at least two virtual disks or pools allows the storage array to use both storage controllers for greater performance. As additional virtual disks are created, they are balanced across the two controllers. See Balancing VDISKs between Storage Controllers later in this document. Linear versus pooled storage/tiered storage Linear allocation is the only method supported on earlier G1 and G2 ftscalable Storage while ftscalable G3 storage supports two types of storage allocation: linear and pooled. With linear allocation the administrator assigns physical disks to create a VDISK and then creates one or more volumes on that VDISK. With pooled storage the administrator creates disk groups which make up a storage pool and then creates volumes within the pool. All volumes thus created will span all disk groups in the pool. Storage pools can be made up of differently sized disks. If a customer s storage requirements increase, additional disk groups can be dynamically added to the storage pool. With linear storage it is a best practice to create volumes (LUNs) sized to match the capacity of the VDISK. This step is not necessary with pooled storage due to the introduction of tiered storage. If all the physical disks in a pool are the same type there is no functional difference between a storage pool and a large VDISK. However, pools may be made up of physical disks with dissimilar performance characteristics, e.g. some rotating HDDs and some SSDs. Such a pool is called tiered storage. ftscalable G3 storage will dynamically allocate the frequently used blocks of each volume in a tiered pool to the higher performance devices. Typically, volumes contain a large number of blocks that are infrequently accessed and a smaller number of blocks that are frequently used. Dynamically relocating the frequently accessed blocks to higher performance disks allows customers to gain most of the performance benefit of SSD storage at a lesser cost than an all-ssd implementation. When implementing tiered storage it is recommended that a minimum of 10-15% of the available storage in the pool consist of SSD storage. NOTE: Henceforth, the term VDISK refers to both a linear storage VDISK or a pooled storage disk group. RAID types The ftscalable Storage array supports a variety of RAID types. These include: Non-fault-tolerant RAID types (RAID-0, NRAID) Parity-based RAID types (RAID-3, RAID-5, and RAID-6) Mirroring RAID types (RAID-1) Combination RAID types (RAID-10, RAID-50) You must specify a RAID type when creating each VDISK. Each RAID type has unique availability, cost, performance, scalability, and serviceability characteristics. Understanding them allows you to make an informed selection when creating your array disk topology. Non-fault-tolerant RAID types There are two non-fault-tolerant RAID types available in ftscalable Storage, RAID-0 and NRAID. RAID-0 A RAID-0 VDISK consists of at least two physical disk drives, with data striped across all the physical disk drives in the set. It provides the highest degrees of I/O performance, but offers no fault tolerance. Loss of any physical disk drive will cause total loss of data in this VDISK. Since RAID-0 is a non fault-tolerant RAID type, the ftscalable Storage array cannot automatically take marginal or failing physical disk drives out of service and proactively rebuild the data using an available spare disk drive. Instead, recovery completely depends on the traditional OpenVOS system of fault tolerance via duplexed disks.

3 Best Practices 3 As a result, a series of manual service operations are required to recreate and recover any RAID-0 VDISK. These operations include: deleting the failing VDISK, physically removing the bad physical disk, installing a replacement physical drive, recreating the VDISK, reformatting the logical disk, and re-duplexing via VOS. Your data is simplexed until all these recovery operations are completed. For further information regarding the impacts that physical drive insertions or removals have on I/O processing, see Physical Disk Drive Insertions and Removals: Impacts to I/O Performance. Stratus does not recommend using this RAID type without also using the software-based mirroring available in OpenVOS. Even with OpenVOS mirroring, you should strongly consider the potential for data loss given the manual service operations and associated time required to restore your data to full redundancy. NRAID An NRAID VDISK is basically a single physical disk drive without any fault tolerance. It offers no striping and thus has the performance characteristics of a single physical disk drive. NRAID VDISKs have all the same availability and serviceability characteristics as a RAID-0 VDISK. Parity-Based RAID types: RAID-3, RAID-5, RAID-50, and RAID-6 The ftscalable Storage array supports four types of parity-based VDISKs: RAID-3, RAID-5, RAID-50 and RAID-6. Given the low usage of RAID-3 and RAID-50, this whitepaper focuses on the more commonly used RAID-5 and RAID-6 types. These RAID types use parity-based algorithms and striping to offer high availability at a reduced cost compared to mirroring. A RAID-5 VDISK uses the capacity equivalent of one physical disk drive for storing XOR generated parity data, while a RAID-6 VDISK uses the equivalent of two physical disk drives, as both XOR and Reed-Solomon parity data is generated and stored. Both RAID-5 and RAID-6 VDISKs distribute parity and data blocks among all the physical disk drives in the set. VDISKs using parity-based RAID types require less storage capacity for RAID overhead compared to mirroring RAID types. The minimum number of physical disk drives to create a RAID-5 VDISK is three, while a RAID-6 requires at least four. A RAID-5 VDISK can survive a single disk drive failure without data loss, while a RAID-6 VDISK can survive two drive failures. The ftscalable Storage array can proactively remove a marginal or failing physical disk drive from the VDISK without affecting availability of data. In addition, if a spare drive is available, recovery mode starts automatically. Since the recovery is handled transparently at the storage array level, there is no need for any operator intervention, physical drive insertions, or need to re-duplex logical disks in OpenVOS. You can then schedule a time to replace the failed disk drive and create a new spare. See Physical Disk Drive Insertions and Removals: Impacts to I/O Performance, for further information regarding the impacts that a physical drive removal and insertion have on I/O processing. Both types offer excellent read performance, but write performance is impacted by needing to write not only the data block, but also by the calculation and read / modify/re-write operations necessary for the parity block(s). A RAID-5 or RAID-6 VDISK running in degraded mode after a single physical disk drive failure has a medium impact on throughput. However, a VDISK in recovery mode with data being rebuilt has a high impact on throughput. A RAID-6 VDISK running in degraded mode resulting from two failed physical disk drives has a medium to high impact on throughput, while one running in recovery mode with two drives being rebuilt has an extremely high impact on throughput. Review Table 1 for the estimated impact to I/O when running with a RAID-5 or RAID-6 VDISK in degraded or recovery mode. Table 1. Estimated degradation to I/O performance RAID 5 / RAID 6 degraded mode single drive failure RAID 5 / RAID 6 recovery mode single drive failure RAID 6 degraded mode dual drive failure RAID 6 recovery mode dual drive failure Read performance 40-50% 50-60% 50-60% 60-70% Write performance 10-15% 15-25% 20-25% 25-35% NOTE: These are estimates, and the actual impact in your environment may vary depending on your configuration, workload, and your application I/O profile.

4 Best Practices 4 Mirroring RAID types: RAID-1 and RAID-10 With ftscalable Storage, you can create two types of mirroring RAID VDISKs, RAID-1 and RAID-10. RAID-1 A RAID-1 VDISK is a simple pair of mirrored physical disk drives. It offers good read and write performance and can survive the loss of a single physical disk drive without impacting data availability. Reads can be handled by either physical drive, while writes must be written to both drives. Since all data is mirrored in a RAID-1 VDISK, there is a high degree of RAID overhead compared to parity-based RAID types. Recovery from a failed physical disk drive is a straight-forward operation, requiring only a re-mirroring from the surviving partner. The ftscalable Storage array can proactively remove a marginal or failing physical disk drive from a RAID-1 VDISK without affecting availability of data. As with parity-based RAID types, if a spare drive is available, recovery mode starts automatically. Since the recovery is handled transparently at the ftscalable Storage array level, there is no need for any operator intervention, physical drive insertions, or need to re-duplex logical disks in OpenVOS. You can then schedule a time to replace the failed disk drive and create a new spare. See Physical Disk Drive Insertions and Removals: Impacts to I/O Performance, for further information regarding the impacts that a physical drive removal and insertion have on I/O processing. There is typically a small impact on performance while running in either degraded or recovery mode. RAID-10 A RAID-10 VDISK is comprised of two or more RAID-1 disk pairs, with data blocks striped across them all. A RAID-10 VDISK offers high performance, scalability and the ability to potentially survive multiple physical drive failures without losing data. The serviceability, RAID overhead, and impact on performance while running in degraded or recovery mode is similar to that of a RAID-1 VDISK. RAID type characteristics summary Table 2 summarizes the characteristics of the RAID types discussed. It rates VDISKs of each type in several categories on a scale of 0 to 5, where 0 is very poor and 5 is very good. Selecting a RAID type Each RAID type has specific benefits and drawbacks. By understanding them, you can select the RAID type best suited to your environment. Keep in mind that you can create multiple VDISKs that use any of the RAID types supported by the ftscalable Storage array, allowing you to design a RAID layout that is optimal for your application and system environment. You do not need to use the same RAID type for all the VDISKs on your ftscalable Storage array. NOTE: Stratus s use of a specific RAID type and LUN topology for the OpenVOS system volume does not imply that is the optimal RAID type for your application or data. RAID-5 is a good choice for data and applications where write throughput or latency is not critical (for example, batch processing), or which are heavily biased toward reads versus writes. In return for accepting lower write throughput performance and higher latency, you can use fewer physical disk drives for a given capacity, yet still achieve a high degree of fault-tolerance. However, you must also consider the impact that running with a VDISK in either degraded or recovery mode could have on your application. Overall I/O performance and latency during degraded and recovery mode suffers more with parity-based RAID types compared to mirroring RAID types. Table 2. RAID type characteristics Category NRAID RAID 0 RAID 1 RAID 10 RAID 5 RAID 6 Availability RAID overhead Read performance Write performance Degraded mode performance N/A N/A Recovery mode performance N/A N/A NOTE: You should only compare values within each row; comparisons between rows are not valid.

5 Best Practices 5 Mirroring RAID types (RAID-1 or RAID-10) offer a better solution for data and applications which require optimum write throughput with smallest latencies (for example, online transaction processing systems), which perform more writes than reads, or which cannot tolerate degraded performance in the event of a physical drive failure. These RAID types eliminate the additional I/Os resulting from read-before-write penalty for parity data of RAID-5 or RAID-6, so writing data is a simple operation. RAID-10 is generally a better choice than RAID-1 because it allows you to stripe the data over multiple physical drives, which can significantly increase overall read and write performance. See OpenVOS Multi-Member Logical Disks Versus ftscalable RAID-10 VDISKs and OpenVOS Queue Depth and ftscalable Storage for additional information about OpenVOS I/O queuing, LUN counts and striping considerations. Consider using NRAID and RAID-0 VDISKs only if your data and applications can tolerate longer periods with simplexed data after a drive failure or which are not sensitive to longer latencies. If you use these RAID types, you must then use OpenVOS s mirroring to provide the fault tolerance. Selecting one of these RAID types allows using the fewest number of physical disk drives for a given capacity point, in exchange for lessened availability. Given these restrictions and availability implications, Stratus does not recommend using these RAID types. If you can t decide whether to select a parity-based or mirroring RAID type, then the prudent choice is to use one of the mirroring RAID types as they will offer the best performance and availability characteristics in the majority of applications. In summary, customers should carefully consider the following points when selecting a RAID type for a VDISK: RAID-0 and NRAID are not fault-tolerant and are therefore not recommended. RAID-5 and RAID-6 are fault-tolerant but are not suitable for high-volume, low-latency transaction processing environments due to their additional I/O overhead. RAID-5 and RAID-6 are acceptable for storing lightly-referenced data, such as historical data or archives. RAID-1 usually offers the maximum throughput and minimum response times. Customers who need larger capacity volumes than are available via RAID-1 should define RAID-10 volumes at the VOS level (via multi-member VOS disk volumes). This method usually offers higher throughput than defining RAID-10 volumes at the ftscalable Storage level. Drive types The ftscalable G2 and G3 storage array supports both HDDs and SSDs within the array. Each disk drive type has different availability, cost, performance, and capacity characteristics. Hard disk drives A hard disk drive is a device for storing and retrieving computer data. It consists of one or more rigid rapidly rotating discs (platters) coated with magnetic material, and with magnetic heads arranged to write data to the surfaces and read it from them. In order to satisfy a read, the disk performs what is called a seek where the magnetic head assembly is positioned over the track where the data resides, waits until the sector where the data resides rotates under the head assembly, and transfers the data to the host. ftscalable storage supports enterprise class HDDs that rotate at 15,000 revolutions per minute. Solid state disks An SSD is similar to a hard disk drive in that they both use the same physical host interface and host interface protocols. In an SSD however, the rotating media and head assembly have been replaced by flash memory to store the data and a controller to manage the memory and the interface to the host. In general, SSDs perform best when processing small block size random reads. Small block random writes also display significant improvement over HDDs. However, large block sequential reads do not deliver the same levels of improvement over HDDs since in both cases the data is essentially being read out of disk cache. ftscalable storage G2 and G3 supports enterprise class SSDs that utilize flash memory to deliver the highest availability and performance.

6 Best Practices 6 HDD versus SSD summary The table below compares the characteristics of the enterprise class HDDs and SSDs supported by ftscalable storage. It rates them in several categories on a scale of 0 to 5 where 0 is very poor and 5 is very good. Table 3. Drive type characteristics Category Creating VDISKs Hard disk drive Solid state disk Random read (small block) 2 5 Random write (small block) 2 4 Sequential read (large block) 2 2 Sequential write (large block) 2 2 Cost/GB 4 1 Capacity 4 3 Environmental tolerance (shock and vibration, temperature, etc.) 2 4 The G1 and G2 storage arrays allocate virtual disks (VDISKS) using a method known as linear storage. A VDISK created using linear storage has exclusive use of one or more physical disks. The number of physical disks varies by the RAID type you specify when you create the VDISK. This method is simple and provides total control over the relation of VDISKS to physical disks, but it can also waste disk space when a VDISK is smaller than the usable capacity of the underlying physical disks. It also requires that the replacement disks be identical to the original disks. The G3 storage array can allocate virtual disks using either the traditional linear storage technique, or a new pooled storage technique. With the pooled storage technique, physical disks are assigned to disk groups which make up a storage pool. Using this method, the size of each physical disk can vary, and the physical disks are essentially anonymous suppliers of disk capacity to the storage pools. See Linear vs. Pooled Storage/ Tiered Storage above in this document. While the ftscalable Storage array supports partitioning a VDISK into multiple LUNs, this can introduce significant performance penalties that affect both I/O throughput and latency for all the LUNs on that VDISK if the VDISK is configured with HDDs. As a result, Stratus does not recommend configurations using multiple LUNs per VDISK configured with HDDs for customer data. There are several reasons for the performance penalties seen running multi-lun VDISK configurations, but the basic ones are disk contention and head seeks. Each time the ftscalable Storage array has to satisfy an I/O request to one of the LUNs in a multi-lun VDISK configuration, it has to seek the physical disk drive heads. The more LUNs that comprise a VDISK, the more head movement occurs. The more head movement there is, the greater the latencies become as disk contention increases. Remember, all I/O must eventually be handled by the physical disk drives that make up the VDISK; the array s cache memory cannot replace this physical I/O. Since SSDs do not require a seek of the physical disk drive heads, this penalty is not incurred in VDISKS configured with SSDs and, on ftscalable G3, can be dramatically reduced when using tiered storage pools. See the discussion of Linear vs. Pooled Storage / Tiered Storage above. Stratus has run benchmarks demonstrating that the aggregate I/O throughput of a 4-LUN VDISK is about half the throughput of the same VDISK configured as a single LUN, while the average latency can be over four times greater. Figure 1 shows the impacts using multiple LUNs per VDISK have on performance. These charts show the aggregate of write I/Os per second (IOPS) and maximum latencies in milliseconds (ms) seen when using a 4 drive RAID-5 VDISK configured with one, two or three LUNs. Figure 1. Multiple LUNs per VDISK performance impacts Partitioning VDISKs into LUNs This section pertains to linear storage allocation. Before a VDISK can be used by OpenVOS, it must first be partitioned into one or more LUNs. Each LUN is assigned to a specific VOS member disk. One or more member disks are combined into a single OpenVOS logical disk. NOTE: These charts are based on results from Stratus internal lab testing under controlled conditions. Your actual results may vary.

7 Best Practices 7 Assigning OpenVOS logical disks to LUNs The simplest approach is to assign each member disk within an OpenVOS logical disk to a LUN. If you need a VOS logical disk that is bigger than a single LUN, or if you want the performance benefits of striping, you can create a VOS multi-member logical disk where each member disk is a single LUN. Figure 2 shows the relationship between physical disk drives, VDISKs, and LUNs on the ftscalable Storage array and OpenVOS logical disks. Figure 2. Logical/physical relationship This is an example of a simple OpenVOS logical disk, consisting of two member disks, where each member disk is a single RAID1 VDISK/LUN on an ftscalable Storage array. OpenVOS multi-member logical disks versus ftscalable RAID-10 VDISKs There are now a variety of ways in which you can implement striping in OpenVOS. Prior to the release of ftscalable Storage, the only method available was to use multiple physical disk drives configured as a VOS multi-member logical disk. With the advent of ftscalable Storage, you can create RAID-10 VDISKs where the array handles all striping. You can combine VOS disk striping with ftscalable Storage striping by creating a VOS multi-member logical disk, where each members is a LUN that uses one of the RAID striping methods (RAID-10, RAID-50). If you want to obtain the performance benefits of striping, Stratus recommends you use non-striping RAID type VDISKs (for example, RAID-1 or RAID-5), with a single LUN per VDISK, and combine them into VOS multi-member logical disks. This allows OpenVOS to maintain a separate disk queue for each LUN, maximizing throughput and while minimizing latency. Review OpenVOS Queue Depth and ftscalable Storage for some considerations regarding numbers of allocated LUNs and potential performance implications. OpenVOS queue depth and ftscalable storage All storage arrays, physical disk drives, Fibre Channel HBAs, and modern operating systems have various sized queues for I/O requests. The queue depth basically defines how many unique I/O requests can be pending (queued) for a specific device at any given time. A queue full condition occurs when a device becomes extremely busy and cannot add any additional I/O requests onto its queue. When a queue full condition exists, new I/O requests are aborted and re-tried until there is space on the queue again. This causes increased I/O latency, increased application response times, and decreased I/O throughput. Each host (Fibre Channel) port on the ftscalable Storage array has a single queue with a depth of 128 for G1 and G2 and 1024 for G3. OpenVOS maintains a separate queue for every LUN. The queue depth will be determined by the setting of the opt_for parameter for that particular volume in disks.table. Refer to the section on Per Volume Optimization Attributes later in this document for more detail. opt_for setting Queue depth thruput 18 response 6 balanced 12 In OpenVOS configurations with a large number of LUNs, it is possible to fill the host port queues on the ftscalable Storage array with a relatively small number of very busy LUNs. This results in I/O requests for other LUNs receiving a queue full condition status, delaying them and your application.

8 Best Practices 8 Assigning files to VOS logical disks When possible, assign randomly-accessed files and sequentially-accessed files to separate logical disks. Mixing the two types of file access methods on the same logical disk increases the worst-case time (maximum latency) needed to access the random-access files and reduces the maximum possible throughput of sequentially-accessed files. Also keep in mind that you can use a different RAID type for each logical disk, to best match the I/O access type. Balancing VDISKs between storage controllers The ftscalable Storage array has an active-active storage controller design, with two controllers actively processing I/O. However, every VDISK is assigned to a specific storage controller when allocated; either controller A or controller B. All I/O for a specific VDISK is handled by the assigned storage controller. If you do not specify which controller you want assigned to a particular VDISK, the ftscalable Storage array assigns them in a round-robin fashion, alternating between the two controllers. While this may balance the number of VDISKs between the two storage controllers, it may not ensure that the I/O workload is evenly split. For example, suppose that you have 6 VDISKs in your configuration, called VDISK1 through VDISK6. VDISK1 and VDISK3 handle all your primary online data and are both very I/O intensive, while the rest of the VDISKs handle offline archival data and are much less busy. If you did not explicitly assign the VDISKs to controllers, you will end up with VDISK1, VDISK3, and VDISK5 assigned to controller A, while VDISK2, VDISK4, and VDISK6 will be on controller B. This would result in an unbalanced I/O load between the two storage controllers. You should consider the estimated I/O workloads when allocating your VDISKs, and, if necessary manually assign specific VDISKs to controllers during the VDISK creation process. If you find that your workload changes or that you have an unbalanced I/O allocation, you can reassign an existing VDISK to a new storage controller. CAUTION: Changing controller ownership of a VDISK is a disruptive operation and cannot be done without temporarily impacting access to your data while the VDISK is moved between the two controllers and the LUN number is re-assigned. This cannot be done to online OpenVOS logical disks. Consult with Stratus for assistance before doing this operation. Single VDISK configurations While it is possible to create a single large VDISK on an ftscalable Storage array, you should avoid doing so as this has performance penalties and is not recommended by Stratus. As described previously, there are two storage controllers within each ftscalable Storage array, running in an active-active mode. Each VDISK is assigned to a specific storage controller that owns and executes all I/O processing for that VDISK. In a single VDISK configuration, you are halving the total available performance of the ftscalable Storage array, as you will have only one of the two storage controllers processing all I/O requests. In OpenVOS configurations, there is a separate queue of I/O disk requests for each LUN. By having only a single VDISK, you minimize OpenVOS ability to send parallel I/O requests to the ftscalable Storage array, again degrading your overall I/O throughput and latency. VDISK/LUN sizing implications on OpenVOS Raw versus usable capacity The OpenVOS operating system utilizes meta-data to ensure the highest degree of data integrity for disk data. This meta-data is stored as a separate physical sector from the data itself. As a result, OpenVOS uses nine physical sectors to store every eight sectors of usable data. When configuring ftscalable VDISKs and LUNs, remember that the size presented to OpenVOS represents RAW capacity and does not reflect the meta-data overhead. Your usable capacity is approximately 8/9ths (88%) of the raw physical size of the VDISK / LUN. In addition, OpenVOS also reserves approximately 1.1 GB of space for partitioning overheard. OpenVOS normally utilizes storage on a LUN rounded to the nearest 5 GB boundary. This allows partnering of LUNS with slightly dissimilar sizes. The only exception to this rounding is for LUNs that exactly match the size of certain legacy OpenVOS disk types (for example, a D913, or D914).

9 Best Practices 9 POSIX restrictions on logical disk size The number of disk members and the total size of a VOS logical disk determine the size of generated inode numbers used by POSIX applications. In earlier VOS releases, that value is restricted to 32-bits, which allows a logical disk size of approximately 545 GB. If that limit is exceeded, the VOS initialize_disk command generates a warning that this could present a compatibility issue for your existing POSIX applications. If all your POSIX applications that access logical disks have been recompiled on OpenVOS 17.1 with the preprocessor symbol _VOS_LARGE_INODE defined, and rebound with the OpenVOS 17.1 POSIX runtime routines that support both 32 and 64-bit inode numbers, there is no issue. The warning message for that disk may be ignored. You may suppress the message with the no_check_legacy_inodes option added to the initialize_disk command in OpenVOS release 17.1 and beyond. Refer to the Software Release Bulletin: OpenVOS Release 17.1 (R622-01) and OpenVOS System Administration: Disk and Tape Administration (R284-12) documentation for further information. Physical disk drive insertions and removals: Impacts to I/O performance The ftscalable Storage array supports online insertion and removal of physical disk drives without powering off the array, or stopping the host or application. After one or more drives are inserted or removed, the ftscalable Storage array must go through a process of remapping the underlying physical disk topology to determine if there are any relocated, removed or newly inserted physical disk drives. This is called a rescan. These rescans are done automatically by the ftscalable Storage array, without any manual operator commands. While this rescan process is occurring, any pending I/O requests may be temporarily delayed until it has completed. In the first-generation ftscalable Storage array, a drive insertion could cause multiple I/O delays ranging from 4 to 7 seconds over a period of approximately 40 seconds. A drive removal typically results in two I/O delays of between 3 to 11 seconds over a period of roughly 15 seconds. With ftscalable Storage G2 and G3 arrays, I/O delays resulting from drive insertions or removals are now 3 seconds or less. NOTE: These are results from Stratus internal lab testing under controlled conditions with the latest firmware versions and with maximum physical disk configurations (3 enclosures per array with 36 drives for the first-generation ftscalable Storage array, or 72 drives for ftscalable Storage G2 array). Your actual results may vary depending on your specific configuration and workload. Per-volume optimization attributes Beginning with VOS 17.1, you configure the per-volume optimization attributes by setting the value of the opt_for field in the disks.tin file as described in the following sections. Before per-volume optimization attributes were available, disk optimization involved setting a collection of separate tuning parameters. The tuning parameter method is complex and it only works on a system-wide basis. For example, it does not allow you to optimize some disks for fast response and others for maximum throughput. The per-volume usage feature is easy to use, it provides much more flexibility, and when used, it typically eliminates the need to make other cache-related tuning parameter adjustments. Fast response Some applications, such as those in online transaction processing environments, may require fast access to a certain group of files, because they may set an upper limit on the total elapsed time allowed to process a transaction. If it takes longer, the software may time-out or initiate retries. Fast disk response and minimal latency is required to insure optimal performance for such applications. To configure disks that contain such files for fast response, set the value of the opt_for field to response in those disks entries in the disks.tin file. For disks optimized in this way, both the cache manager and disk driver use tuning parameter values and algorithms which minimize latency. By default, file copy operations to or from such disks are paced in order to minimize access time for other files on the disk. By optimizing a disk for fast response, you typically impact its ability to achieve maximum throughput.

10 Best Practices 10 Maximum throughput You can improve the efficiency of some applications, such as those that write log files (or other files to which fast access is not essential), by optimizing the disks that contain such files for throughput. To configure disks for maximum throughput, set the value of the opt_for field to thruput in those disk s entries in the disks.tin file. For disks optimized in this way, both the cache manager and disk driver use tuning parameter values and algorithms which produce optimal disk throughput at the expense of fast response time. Balanced usage By default, disks which are not explicitly optimized for response or throughput are optimized for balanced usage. You can also explicitly designate disks to be optimized for balanced usage, by setting the value of the opt_for field to balanced in those disk s entries in the disks.tin file. Recommendations Potential I/O delays may occur during rescan processing can have a negative effect on latency-sensitive applications. There are several recommendations which can minimize those impacts. Configure at least one physical disk drive as a spare drive and use fault-tolerant RAID type VDISKs. By allocating a spare drive and using fault-tolerant RAID types, the ftscalable Storage array can automatically remove a marginal or failing physical disk from a VDISK and start the recovery process without requiring any drive insertion or removal, avoiding a rescan. You can replace the failing drive during a less critical period. If using non fault-tolerant RAID type VDISKs (RAID-0, NRAID), Stratus recommends creating an extra VDISK as a standby spare. You can use this standby VDISK as a replacement member disk and re-duplex using OpenVOS mirroring to provide redundancy. This allows you to replace the failing drive during a less critical period. Do not move physical drives to preserve specific enclosure slot positions after service operations. The ftscalable Storage array design does not require the physical drives for a VDISK to remain in the same enclosure slot positions as when allocated. Do not physically remove marginal or failing disk drives until a replacement is received and ready to be installed at the same time. By coordinating physical drive removals and insertions, you can minimize the number of times a rescan process occurs as multiple drive topology changes can occur within one rescan process. Summary The combination of the OpenVOS operating system with ftscalable Storage arrays gives you a robust, scalable and flexible storage environment to host your most critical applications. By understanding the benefits and drawbacks of the various RAID types, LUN topologies and configuration choices available, you can create an optimal storage layout to meet your business, performance and availability needs. Glossary of terms Degraded mode. The mode of operation of a VDISK after one of its physical disk drives has failed, but before any recovery operation starts. While in this mode of operation, the VDISK is not fully redundant, and a subsequent physical drive failure could result in loss of this VDISK. Disk group. A collection of physical disks with a specific RAID type. Disk Groups make up a storage pool. HBA or host bus adapter. A PCI-X or PCI-e circuit board or integrated circuit adapter that provides input/output (I/O) processing and physical connectivity between a server and a storage device. Linear storage. A type of storage allocation where physical disks make up a VDISK of a specified RAID type. Those VDISKs are then partitioned into volumes. Supported on ftscalable G1, G2 and G3. Logical disk. An OpenVOS logical volume that contains one or more member disks. Each member disk is either a single physical disk in a D910 Fibre Channel disk enclosure, a LUN in an ftscalable Storage array or a duplexed pair of either type or both types. LUN or logical unit number. The unique address identifier associated with a volume.

11 Best Practices 11 Glossary of terms (continued) Multi-member logical disk. An OpenVOS logical volume consisting of at least two pairs of duplexed member disks with data striped across all the member disk pairs. Pooled storage. A type of storage allocation where physical disks make up disk groups of a specified RAID type. One or more disk groups make up a storage pool. The storage pool is then partitioned into volumes. Supported on ftscalable G3 only. RAID overhead. The amount of physical drive capacity used in a specific RAID type to provide redundancy. For example, in a RAID1 VDISK, this would be 50% as one drive is mirrored to its partner. Recovery mode. The mode of operation of the VDISK while it is rebuilding after a drive failure. While in this mode of operation, the VDISK is not fully redundant and a subsequent physical drive failure could result in loss of this VDISK. Sector. A segment of a track on a hard disk drive. It is the smallest unit of data that can be accessed by a disk drive Tiered storage. Pooled storage which contains disk groups with dissimilar performance characteristics, e.g. HDDs and SSDs. With tiered storage the storage controllers will dynamically relocate the most frequently referenced blocks of each volume to the highest performing disk groups. Supported on ftscalable G3 only. Track. Any of the concentric circles on the magnetic coating on a disk platter over which one magnetic head passes while it is stationary but the platter is spinning VDISK or virtual disk. A group of one or more physical disk drives in an ftscalable Storage array, organized using a specific RAID type into what appears to the operating system as one or more disks, depending on the number of LUNs defined. Volume. A defined amount of storage that is contained within either a VDISK or a storage pool. The terms VOS and OpenVOS are used interchangeably in this document in reference to Stratus s OpenVOS operating system. Striping. A method of improving I/O performance by breaking data into blocks and writing the blocks across multiple physical disks. Specifications and descriptions are summary in nature and subject to change without notice. Stratus and the Stratus Technologies logo are trademarks or registered trademarks of Stratus Technologies Bermuda Ltd. All other marks are the property of their respective owners Stratus Technologies Bermuda Ltd. All rights reserved