Printer Friendly

Backup & recovery using revolutionary MAID architecture: Part 2.

D2D2T Options

The first type of disk option, simply buying an inexpensive disk array and backing up to a filesystem, doesn't sound that expensive at first. The disk array alone will cost more than the average price of a similarly sized tape library, especially if you consider compression. Your backup software may also require a license to back up to a filesystem-type device, such as a disk array. Additionally, backing up to a filesystem is a little different than backing up to tape, and there will be a management cost associated with that difference. For example, while tape library systems can be dynamically shared across multiple backup servers, disk cannot. Therefore, you will need to create separate volumes for each backup server and manage those volumes as needs grow. Also, while most backup software products understand when a tape runs out of space, they don't like it very much when a filesystem runs out of space. A tape will get marked as full, while the disk will simply report an I/O error, and warnings will go off all over the place. Some backup software products keep attempting to write to a filesystem, even after it's full. The differences between filesystem-based backups and tape/virtual tape-based backups may manifest themselves as anything from a minor inconvenience to an actual loss of data.

[FIGURE 1 OMITTED]

The second option, a disk-based virtual tape library system, is easier to integrate into an existing backup and recovery system and gives you the benefit of both disk and tape, without the downsides of tape mentioned earlier in this paper. The challenge with most of today's VTL products is that they are priced based on their value relative to physical tape--typically 5-10 times the cost of a physical tape library. While their value may justify such a price, it does not allow for a cost-effective deployment of an all-disk-onsite solution.

Enter MAID

The recently introduced acronym MAID refers to a massive array of idle disks--as the disks in a MAID array power down when not being utilized. To fully understand the value of MAID, let's first examine the use of traditional RAID in an array designed for secondary storage needs, such as backups. While tapes were designed for backups, RAID wasn't. To explain, let's compare backups to a large database. An update to a single table will, at some point, cause the flushing of buffers, causing all data files to be written to disk. This write will write data to every disk in every volume on which the database resides. A large query will also require reading the entire database into memory, reading from all disks simultaneously. Therefore, a large database will constantly read from and write to the entire disk array.

Backups are a Write Once Read Occasionally (WORO) application. That is, they write data once, but only occasionally access that data. Also, when one backup is being written to one disk, it is not writing to the other disks in the RAID array. The same holds true for restores. A restore reading from one disk does not read from the other disks in the array. WORO applications, therefore, do not require access to the entire array all the time. That means that, at any given point in time, there are a lot of disks spinning in a RAID that are neither reading nor writing. Perhaps they're spinning because they're being used to write RAID-5 parity, which is written to all members of a RAID group. Perhaps they're spinning because a filesystem is actually striped across several disks. And perhaps they're spinning simply because that's what RAID arrays do. Of course, all of this unnecessary spinning of disks requires constant power, which generates constant heat; therefore, it requires constant cooling as well.

In a backup and recovery storage configuration, traditional RAID seems like overkill. Having all of the disks spinning at the same time seems like having all the tapes in a robot loaded in drives all the time. It's simply not necessary. The high-performance cache and non-blocking interconnect schemes used in RAID arrays are also designed for applications with a lot of IOPS, and are not designed for high-bandwidth applications like backup. What if there was a technology that brought the benefits of RAID to secondary storage, but didn't have the power and cooling overkill of RAID? What if you could have the benefits of parity protection without having to power on all the drives in a RAID set? What if you re-examined access requirements and minimized some of the expensive schemes used to maximize IOPS?

This is where MAID comes in. For the purposes of explanation, let's consider the first-ever disk storage system designed exclusively for WORO storage: COPAN Systems' Revolution 200T. Their innovative design has extended the concept of MAID and ultimately reduced purchase and maintenance costs, while simultaneously improving reliability--and increasing the service life of the disk drives in their array.

To understand the MAID concept, you need to understand that a virtual tape library has a finite number of virtual tapes, based on the number of disk drives in the array. Each of these virtual tapes is represented by a contiguous section of disk belonging to a virtual disk volume protected by a parity disk. This sounds like RAID-4, but it's not. If this were a traditional RAID-4 volume, backing up to a virtual tape residing on this RAID 4 volume would cause a stripe of data to be written across all data members of the RAID 4 array, and parity would be written to the parity disk (see Figure).

COPAN Systems concatenates the volumes instead of striping them, but still calculates parity for them. In a six-disk MAID volume, they write to and fill up disk 1 before writing to disk 2. Then they fill up disk 2 before writing to disk 3. That way, we can power off disks 2-5 while we're writing to disk 1, and power off disks 1, 3, 4 and 5 while writing to disk 2, respectively.

When they're writing to disk 1, they know that disks 2-5 contain all nulls, so they don't need to power them on to calculate parity. Once they're writing to disk 2, they can use the historical parity and combine it with the nulls on disks 3-5 to calculate parity for disk 1. The result is that at any one time, only the parity drive and the active drive need to be powered on.

A few issues might come to mind when thinking about this plan. Perhaps you're thinking that the parity drive would get busy and worn out with time. Perhaps you're thinking that the disk at the end of the concatenation might never get used, and might therefore never get powered on. Or worse, there might be virtual tapes that never get used, and their drives stay powered off all the time. The answers to these questions are found in COPAN Systems Disk Aerobics. Their goal is to distribute the workload (and rest periods) among all drives, ensuring that no individual drive gets worked too much or too little. Data that's on a drive that is getting used too much or is reaching an error threshold is transparently moved to a more idle drive, removing any hot drive concerns. This also will help avoid RAID rebuilds. A drive that's been idle for a while is powered on and exercised, while its data is checked for integrity.

This unique design means that a COPAN Systems disk array has 25% of the power and cooling requirements of a typical array. That means a higher density than tape and less real estate cost. That means 75% fewer power supplies and 75% fewer cooling systems. Instead of having a power supply in each disk shelf, they have a single N+1 power rack that supplies DC power to all the shelves. Since MTBF is based on power-on time, it also means that their SATA disks last four times longer than disks in a traditional RAID array, making it in the ballpark of a SCSI, with 1.2M MTBF hours.

COPAN Systems has released their first product as a virtual tape library in order to take advantage of the ease of integration with current environments. The result of their MAID architecture and the VTL personality is the first virtual tape library priced at the same price as tape. Where a fully populated tape library costs $1-$4/GB, a typical VTL solution can cost from $10-$22/GB. The Revolution 200T, expandable to 224TB and 720 MB/s, is priced at $3.50/GB. At that price, you can deploy a completely disk-based solution on site, and use tape only for off site. This system gives you all the speed and manageability benefits of disk and RAID for both backups and restores, without spending an arm and a leg.

Part 1 of this article appeared in the August edition of CTR and discussed issues with tape--both pros and cons.

W. Curtis Preston is vice president of service development at GlassHouse Technologies, Inc. (Framingham, MA)

www.glasshouse.com
COPYRIGHT 2004 West World Productions, Inc.
No portion of this article can be reproduced without the express written permission from the copyright holder.
Copyright 2004, Gale Group. All rights reserved. Gale Group is a Thomson Corporation Company.

Article Details
Printer friendly Cite/link Email Feedback
Title Annotation:Disaster Recovery & Backup/Restore; massive array of idle disks
Author:Preston, W. Curtis
Publication:Computer Technology Review
Geographic Code:1USA
Date:Oct 1, 2004
Words:1517
Previous Article:Comparing host-based D2D to VTLs for backup and restore: Part 2.
Next Article:Better backup and recovery with snapshots.
Topics:


Related Articles
NTI DriveBackup! Introduced By NewTech Infosystems.
Simplifying storage: how companies benefit with a backup appliance approach. (SAN).
IP SANs to the rescue: fortifying business continuity.
Assessing the foundation of long distance disaster recovery.
TCO should include value as well as cost.
Backup & recovery using revolutionary MAID architecture: part 1.
The scramble is on to solve recovery puzzle: virtual tape, MAID, SRM are some leading solutions.
Overcoming recovery barriers: rapid and reliable system and data recovery.
Understanding the new generation of data protection solutions.
Traditional backup software is no match for Exchange.

Terms of use | Copyright © 2017 Farlex, Inc. | Feedback | For webmasters