Dynamic SAN optimization: Leveraging SANs in ways never though possible. (SAN).

The typical SAN-attached server has high needs in the area of storage--very-large capacities (tens of terabytes) and/or high performance. These servers are also, typically, database servers. Initial SAN implementations were able to address the I/O performance issues. Unfortunately, over time the databases developed I/O bottlenecks that the initial SAN deployment could not fully handle. Daytime processing could not keep up with user requests, and nighttime batch cycles (large reports, database refreshes, data loads, etc.) exceeded the nightly windows. Usually, these I/O bottlenecks were caused by one or two areas of the database called "hot spots."

The DBA's job quickly turned to spending most of the time identifying, isolating and eliminating these hot spots, sometimes hundreds of hours to eliminate just one. DBAs would try reorganizing their databases; developers would be tasked with optimizing applications, which would initiate the expensive development lifecycle (design-code-test); and IT managers would purchase additional storage subsystems.

It quickly became evident that the hot spots often resulted from very large amounts of random I/O. With the very large host systems that run these databases, it is very easy to overpower a traditional disk subsystem with random I/Os causing the host to sit idle while waiting for the disks to respond. Many infrastructures contain larger disk subsystems that allow multiple gigabytes of cache to be added. Cache is an excellent way to speed up I/Os that are well behaved (the same data is read many times). Random I/Os, on the other hand, are read once, which means that the data would enter the cache on the initial read and then never be read again. The cache is useless when trying to address the performance of random I/Os.

Explosive Performance

One surefire way to eliminate a database I/O bottleneck is to add solid-state disk technology (like MTI's V-Cache enterprise application accelerator) to the solution. Solid-state disk technology packages very high-speed memory into a unit that emulates one or more disk drives. It differs from storage subsystem cache in that the solid-state disk is used exactly the same way as a normal disk; data is moved Onto the solid-state disk and never ages off the disk the way it would in cache on a disk subsystem. No search for data occurs with cache; the data is there as it would be with a regular disk. Also, there are none of the delays associated with normal disk drives (seek time, access time, etc.); when a database requests data from a file stored on solid-state disk, it is returned instantly. If a system has an I/O bottleneck, moving the data in question to solid-state disk will eliminate that bottleneck.

Most I/O-starved database systems will have one or more I/O bottlenecks, some occurring during the day and others at night. Because there was no way to dynamically move the solid-state disk to the current hot spot, multiple solid-state disk units typically were purchased to address the issues. With this approach, the solid-state disk that was busy during the day would be all but idle at night, and vice versa.

Traditionally, solid-state disks would be SCSI-attached to a single host, which made things very expensive. Each troubled server would need dedicated solid-state disk units. If one server had I/O issues during the day, its solid-state disk would sit idle at night. If a server had I/O issues only at night, it would need its own solid-state disk unit. There was no way to move the solid-state disk from one system to the other.

Maximizing Efficiencies

Storage administrators can maximize efficiencies by attaching a solid-state disk unit to a SAN directly, or through a SCSI bridge and logically dividing it into multiple LUNs, which allows multiple SAN-attached hosts to share the one resource. SAN-attached solid-state disk alleviates the need to buy one or more solid-state disk units per server.

Storage front ends such as FalconStor's IPStor can optimize the technology by using solid-state disk to emulate the cache pools found in most storage devices. In a SAN environment, where a large set of database servers or a few high-end database servers share a smaller set of storage devices, data tends to be randomly accessed. Even with a RAID controller that uses cache memory to increase performance and availability, hard disk storage often cannot keep up with application servers' I/O requests. In environments such as these, cache emulators work in conjunction with solid-state disks to "front" slower real disks, can significantly improve performance (Figure 1). Since solid-state disks are 100% immune to random access, the cache emulator can write data blocks sequentially to the persistent cache area and move them to the data disk (random write) as a secondary operation once the writes have been acknowledged; this effectively accelerates the performance of the slower disks. As with traditional storage cache, reads will also take advantage of this new cache pool. When a server initiates a read, the data is read from disk, loaded into the cache pool, and presented to the server. Subsequent reads of the same data block will be fulfilled from the solid-state disk cache pool.

An additional way to optimize solid-state disk is by increasing the performance of every I/O (read and write; sequential and random) that utilizes a predefined region on disk. One method is to use intelligent disk-based staging mechanisms to re-map frequently used areas of one or more pre-defined zones to solid-state disks (Figure 2). IPStor, for example, monitors reads/writes to each of the zones defined on the traditional disk and, based on the statistics it has collected, determines the most frequently accessed zones. Once they are identified, IPStor re-maps the data from these "hot zones" to the solid-state disk, resulting in enhanced read/write performance for the application accessing the storage. When a zone is no longer considered hot, the data from the high-performance disk is moved back to its original zone on the traditional disk. With I/O optimizers in place, fewer solid-state disks will need to be purchased, and those that are will provide a healthier return on investment than traditional solid-s tate disk purchases.

Jim McKinstry is a senior presales engineer at MTI Technology (Anaheim, Calif.)

www.mti.com