???We look at three things when selecting data warehouse disks. Price per terabyte, throughput capabilities, and availability features. With the HP Virtual Array 7100, the price per terabyte was extremely competitive and the throughput was phenomenal. Our current Superdome VA7100 configuration is capable of driving three to four gigabytes of I/O per second, and the autoraid features of the VA7100 exceed our availability requirements.???

Mark Dunlap

Director of Data Warehousing

Amazon.com

Room & Board

???In consolidating from eight controllers to the HP Surestore VA7100 we expected to see some performance degradation in running our Children, Youth, and Family Department databases. We haven't seen any degradation and are pleased with the performance. We've found it very easy to allocate space with the VA7100 and have saved time with reduced administrative overhead. With the AutoRAID feature, we've eliminated worrying about mirroring. We let AutoRAID go to work and don't even have to think about it.???

Tom Elder

DBA 3 Children, Youth and Family

Department

State of New Mexico

???data always grows, but human head count doesn???t???virtualization reduces the number of people required to manage storage

key features of hp???s patented virtual technology

???automatically stripes every LUN across all disks in a very large redundancy group Benefit: simplifies overall management; reduces the number of LUNs required to

???allows any combination of disk drive capacities and speeds within the array Benefit: simplifies disk drive inventory control and capacity management

???allows disk drives and controllers to be moved to any slot in the array

Benefit: reduces the chance for human error

Data centers have become enormously complex. Interestingly, new technologies that initially held the promise of simplifying the data center have, in fact, added to the complexity???at least for now. Fibre Channel, SANs, and the low cost and ease of adding storage have enabled data centers to expand both in size and complexity.

The world is moving from SCSI to Fibre Channel. Fibre Channel and SANs allow for more devices to be connected together, with greater performance, and at far greater distances. All of these are wonderful benefits, but along with those benefits comes an ability to now create configurations that are larger, more complex, further apart, and harder to manage than anything envisioned even a few years ago. Couple this new reality with the exponential increase in storage, fueled by its low cost, and you have a recipe for losing control of the data center.

Consider this: while human resources remain static, environments grow larger and more complex. Simplification is the only realistic answer. Adding newer and slicker management software oftentimes can help, but in the long term, adding software tends to have the opposite effect of reducing complexity. Software may give you a central place from which to manage your hardware and it may simplify processes, but it doesn???t necessarily eliminate those processes. Armed with better management software, environments are encouraged to add more hardware and eventually the environment becomes as complex as it was before, but for different reasons. And when the human resources are already stretched to the breaking point, this is a recipe for complexity, stress, long hours, and human error. Virtualization is the answer. It solves the basic underlying problem. It permanently simplifies the environment for the system administrator.

???Chessmaster Savielly Grigorievitch Tartakower on the game???s opening position

Configuring and managing traditional storage is time-consuming and challenging even for experienced system administrators. When configuring storage, a wide variety of factors must be accounted for, judgments must be made, and steps repeated over and over again.

The potential for error is high. The cost of configuring an array improperly is also high. The administrator must consider the following factors:

???capacity, cost, performance and availability requirements

???requirements for future additional capacity and performance

???number of disk drives and their capacity

???performance characteristics of the disks

???which RAID level will meet desired capacity, cost, and availability needs

???number and type of RAID groups

???number of LUNs based on application, performance, and array configuration needs

???size of LUNs

???configuration of the server volume manager

???cache configuration options

???stripe depth configuration

???implementation plan: who, what, and when

???time to bind LUNs

???desired additional capacity, performance, and availability

???whether the new disks will be stripe extensions of existing disks or be independent groups

here is a typical process for setting up a traditional array:

1.Determine number of disks, number of RAID groups, disks and disk type per RAID group, RAID level of each group, total LUNs, LUNs per RAID group, stripe depth.

2.Determine volume manager configuration, stripe size and depth, LUNs per logical volume.

3.Using the command station, set up the LUNs and their RAID levels and assign them to particular disks.

4.Set up the cache page size depending on the size of the I/Os coming in from the host.

5.Finally, before the new LUNs can be used, disks must be formatted, which can take many hours per array.

configuring an array for a database

Properly configuring an array for a database typically involves a large problem set with many variables. Many database administrators have been taught to isolate different pieces of the database in an attempt to optimize performance, availability, and recovery. This process, although based on sound objectives, is far too error-prone. This typically involves a large problem set with many, many variables. Unfortunately, database

In these real-world environments, it is typically far too time-consuming to try a number of different storage configurations, so database administrators typically apply rules from previous installations. The changing characteristics of newer versions of the database typically result in an unbalanced configuration that has ???hot spots??? that limit the performance of the system.

This entire process can take from a few hours to several days, depending on the skill of the administrator and the number and size of the LUNs. During much of this time the array is either unusable or must operate in a degraded performance mode. In other words, LUNs cannot be utilized until they have been formatted. This formatting takes up a lot of the array???s internal resources and bandwidth. After a LUN has been formatted, it can be used; but as long as other LUNs in the array are also going through their format process, the entire array will suffer from degraded performance.

Now, a short word about human error. Every step of this process has the potential for human error. Except in the grossest cases, errors would probably not result in data loss, but every miscalculation in this process would easily result in a decline in performance. Some of these declines could be huge. For example, miscalculating the RAID levels or the cache page size could severely degrade the array???s performance.