Some vendors advertise enterprise automated tape libraries (ATLs) that support multiple platforms, but they don't support all platforms. Because of technical limitations, users deploy ATLs to support Unix servers or mainframe-hosted applications, yet they don't connect the two platforms to the same ATL. What's needed is a single enterprise tape environment that supports legacy and open platforms. But there are a number of reasons why cross-platform tape support is neither widespread nor well-exploited.
Enterprise disk arrays can be easily shared across platforms. But some observers believe tape vendors have gotten off easy, with barely a slap on the wrist for not enabling their products to connect to all of the platforms in the data center. For example, the Storage Networking Industry Association (SNIA) has developed a standard model for shared storage, but barely addresses cross-platform ATL sharing.
A recent SNIA presentation, "Tape in SNIA's Shared Storage Model," described methods for tape drive sharing, access and virtualization. Whether discussing LAN- or SAN-attached tape drives, Network Data Management Protocol NAS backup methodology or even newer Xcopy techniques for server-less backup, SNIA doesn't address cross-platform support.
Multiplatform support for ATLs is costly and complex. IBM Corp. offers the 3494 ATL, but it's rarely used for simultaneous Unix, Windows and mainframe connectivity; to do that, the library drives and slots must be physically and logically partitioned with no resource sharing.
Storage Technology Corp. (StorageTek) uses a similar approach with its Streamline SL8500, PowderHorn and TimberWolf ATLs, which all boast multiplatform support but are configured to support either mainframes or open systems. For cross-platform sharing, a complex assortment of software is needed, including Library Station, ACSLS and Gresham EDT-DistribuTape.
Simultaneous support for mainframes and open systems is difficult, but users can achieve some ATL sharing between Windows and Unix platforms. But even this basic sharing is a function of backup software or an intermediary device. The backup software (for example, Veritas Software Corp.'s Shared Storage Option) or device (for example, IBM's Virtual Tape Server [VTS] or StorageTek's Virtual Storage Manager [VSM]) controls access to the robot and associated drives, acting as a traffic cop so that no two tape mounts are made to the same drive at the same time by different tasks.
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
Typical data center tape library environment |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |

In most data centers, tape resources are dedicated to specific host platforms. Sharing tape drives could significantly reduce costs.
|
 |
 |
 |
 |
 |
 |
 |
What virtualization buys
Virtualizing tape devices allows host applications to access a logical tape drive while a virtual appliance accesses actual physical tape drives. Because the biggest bottleneck in disk-to-tape operations is writing data to tape, virtualization at this level allows logical mounts to be presented to the host whether physical tape drives are available or not. The virtual solutions can gather tape data residing in the disk cache and later write the data to tape, as mainframe tape management systems have done for years.
The biggest drawback to the virtualization products is that they're limited to either mainframe (for example, Bus-Tech, Diligent Technologies Corp., IBM's VTS or StorageTek's VSM) or open systems (for example, Advanced Digital Information Corp.'s Pathlight VX, Data Domain Inc.'s DD200, EMC's Clariion Disk Library or Quantum Corp.'s DX100). These systems aren't used for sharing but for enabling separate backup domains by OS or application platform. They're point solutions that improve backup windows and speed recovery time, but they don't provide simultaneous sharing.
Another drawback is that duplicate virtual appliances are needed at the disaster recovery site to recover data, and these devices are typically pricey. They may also require purchasing backup software upgrades. For example, Veritas charges by the number of tape drives (real or virtual) needed, so a 40-drive virtual environment at $3,000 per drive would cost $120,000. Veritas also adds $2,000 for a SAN-shared drive. If the 40 virtual drives were shared, the total cost would be $200,000.
Jeff Hackling, vice president of systems support at Global Payments Inc. in Atlanta, runs a data center with almost every major host type--mainframe, Unix, Windows, AS/400 and Tandem. "Thus far, Global has not pursued tape resource sharing," Hackling says. But, he adds, "as our open-systems data storage has significantly increased recently--from 2TB to 25TB--we may need to look at tape sharing."
Limits to tape sharing
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
Virtualize tape devices |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |

Centralized and heterogeneous tape virtualization enables the consolidation of multiplatform tape configurations where common backup/archiving policies can be set, tape devices can be managed easily and physical resources can be shared more effectively.
|
 |
 |
 |
 |
 |
 |
 |
The key to tape sharing is the ability to establish static mount points so that only one system can read/write to one tape at a time. The process of mounting/dismounting tape drives is time consuming. With disk arrays, several hosts can simultaneously access a set of disks and while each obtains the data it requested, the context switching is transparent to the host. This is impossible with current tape technologies because when host systems need access to the same set of tapes or tape drives, each must wait until the previous request has completed. In this scenario, aggregate data rate transfers drop dramatically, often to fewer than 100KB/sec.
Another operational risk for arrays and ATLs posed by multiplatform support is the need to quiesce the system to update microcode. When this occurs, some or all of the attached hosts are impacted. Every attempt to upgrade shared ATLs or tape drives requires coordination between mainframe, Unix and Windows groups. Array vendors have overcome this limitation by minimizing or eliminating these disruptive microcode upgrades so that elaborate coordination is no longer necessary.
Even sharing ATLs among open systems can be difficult. Brian Estes, lead systems engineer at James Madison University, Harrisonburg, VA, has Unix, Windows and NetWare in his shop. "We haven't had much luck with integrating NetWare into our Unix/Windows backup environment," he says. "We tried a couple of times, but the backups become unstable when ATL changes are made so we had to segment NetWare from all other systems."
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
Shortcomings of automated tape libraries |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
| Automated tape libraries (ATLs) lack a common control standard. Each manufacturer provides its own set of commands and protocols. Although ATLs can hold drives that support multiple connectivity types (e.g., Fibre Channel and FICON), they don't expose their unique command sets to a common interface or API set. Even backup software providers have difficulty recertifying their functionality with each library iteration. |
 |
 |
 |
| With the robot as the control point, only one operating system host can have access to a tape drive at a time. The host is typically running backup software that contains a catalog with configuration information. This host system becomes a logical single point of control, forcing any other host that wants access to the ATL to go through it for communication. There are ways to circumvent this monopolistic control with software like StorageTek's Automated Cartridge System Library Software (ACSLS), which provides some ability to arbitrate control away from the backup software, but only between common hosts. |
 |
 |
 |
| Tape vendors can help open their products by creating a standard set of ATL commands, moving more intelligence to the library using meta data about what's stored in the library, and by exposing robot control software like ACSLS with API extensions that can be manipulated and invoked by other software products, including the competition's. That, at least, would be a start. |
|
 |
 |
 |
 |
 |
 |
 |
Solving the problem
Last year, the Meta Group Inc., Stamford, CT, published "Tape Storage Virtualization--A New & Valuable Approach to Improve Data Center Efficiency," a whitepaper that offers benchmarks to determine when an operation merits consolidation of open systems and mainframe tape configurations.
According to Meta Group, a dramatic cost reduction may be realized if mainframe and open-systems tape can be centrally managed. There are some effective solutions--for example, Fujitsu Siemens' CentricStor and NearTek Inc.'s Virtual Storage Engine support all major platforms simultaneously. NearTek even extends this support to include legacy platforms like AS/400, Unisys mainframes and Hewlett-Packard MPE servers.
These products emulate all the major enterprise tape drive mount types, connect to major storage arrays and support all the major host processing platforms. They provide the impressive cross-platform functionality that many customers would prefer to see delivered natively by the tape library and drive vendors themselves. Instead, to achieve a robust consolidation of enterprise tape environments and to recover costs through improved use of physical assets, customers have to purchase these additional virtualization "engines." Interestingly, the engines commoditize the ATLs, which become passive recipients of data streams as the virtualization engine handles all management functions (see Virtualize tape devices).
Tape-sharing solutions for multiplatform environments will enable standardized, enterprise-wide backup and recovery and reduce the number of storage devices required. Nirvana will be when users can take any library, plug it into any multiplatform host environment and back up any system with a tool that migrates old data to the new environment seamlessly.