Return to Conference Proceedings
Data storage, in a very real sense, is what computing is all about. Computers compute, for sure. But in the commercial world, they normally use their computing power to manipulate information rather than crunch numbers. The Australian
And how true this is!
In today's tougher economic times, all too often the dollars - or lack of dollars - force many IT departments to skimp on storage, which is arguably the most important component of a computer system. Many IT departments would rather overcapitalise on CPU power. They purchase the 'latest and greatest' computing technology, which promises great increases in performance, only to find in practice that their I/O subsystems cannot keep up with the new CPUs, hence resulting in significant CPU idle time and only a marginal difference in terms of response or functionality to users. Organisations of today cannot gamble on storage technology.
Whilst in some organisations, raw computing power is by far the most important measure of the IT department's ability to deliver service to their customers, I hesitate to suggest that for the majority of organisations, one of the most important indicators for an IT department's ability to be effective is system uptime.
Poor response from a system can be explained away by a lack of CPU grunt, slow or archaic disks or a lack of memory. Management can understand that if the financial resources are not invested in the computing system, then users of the system, including management, must resign themselves to slower response.
In these organisations however, there is now no excuse for a lack of availability to the system, especially with the advancements which have been made in RAID technology, which provides significant front-line redundancy features against minor 'disasters', such as disk failures, for a very little premium over non-RAIDed disk arrays. Further fault tolerance can be introduced via failover or 'clustered' systems which provides fault tolerance against CPU failures.
Unfortunately, not even the redundancy and fault-tolerant attributes inherent in RAID technology are likely to withstand the occurrence of a major disaster. As a result, regular backups are made to allow an organisation to restore its data in the event of major disasters. Therefore, backups are made to allow restores to take place.
Although these issues seem basic, they are too often forgotten. Therefore, this paper will attempt to examine the technologies available today to overcome the 'system's down' syndrome. This paper will concentrate on these two storage technologies: RAID and tape storage. In each case, this paper will examine the how best to apply these technologies to your environment as well as examining the performance of each of these technologies. Under the RAID section, we will also break down the idea of RAID into five other key areas: redundancy, fault-tolerance, availability, integrity and flexibility.
We are operating in an Open Systems environment. No matter whether you are running a Sun, HP, IBM, DEC, etc. machine, there are storage technologies (which may or may not be from your CPU vendor) which will best suit the applications you are running.
One of the more popular forms of storage technology available today is RAID. RAID has the benefit of providing greater redundancy and fault tolerance to a storage subsystem. However, field experience has shown - no one RAID product has all the answers! RAID subsystems offer the redundancy benefits, but so many RAID subsystems in the field can be damaging to your computer environments by introducing a single point of failure and/or dramatically degrading the performance of your total system.
With so many computer companies doing away with their storage divisions, after-sales support is no longer an issue in considering so-called 'third party' storage. After all, most computer manufacturers use third party products and rebadge them any way. With so many companies vying to provide your organisation with on-site service, you will find that your computer manufacturer is likely to welcome taking your storage solution on board your existing maintenance agreement with them.
Whilst this can be done on a software level, implementing RAID on a hardware level frees up the CPU to perform application-related tasks rather than mundane operating system related tasks such as I/O, etc.
Users choose RAID for one or more of the following six reasons:
Although these terms all look similar, do not be fooled. They are interrelated, and each hold an important place in deciding the most appropriate storage architecture for your organisation.
There are several versions or levels of RAID. The performance of the RAID subsystem is often directly related to the RAID level implemented. As a general guide, applications which require large sequential reads and writes (such as CAD) will benefit from RAID levels 3 or 4. Relational databases (such as Oracle, Informix, Sybase, etc.) will often benefit from the introduction of RAID level 5. However, it must be noted that these are general guides. The benefits gained from RAID (or in fact any storage subsystem) are highly dependent on the applications being run, and the way the applications interact with the file system.
RAID 0 (which incidentally was never a defined RAID level in the original RAID paper) is often known as disk striping. What this means is that data is spread (or 'striped') across a number of disks. The benefit of this is that when you read the data back, there are a number of disk heads doing a read which will result in significantly higher read performance. However, writes will take longer and there is no fault tolerance in this RAID level.
RAID 1
RAID 1 is disk mirroring. Known also as disk shadowing, this provides the highest level of redundancy as two physical copies of the data are kept (usually) on separate disks. Often this can improve performance and there is usually little or no write degradation.
RAID 2
RAID 2 is not a commercially available (nor viable) RAID level.
RAID 3/4
RAID 3 or 4 is similar to RAID 0 in that data is striped across a number of disks. However, extending this model, parity data is calculated based on the data being written and the result of the calculation is written onto a dedicated disk set aside for the storage of this parity data. In the event of a disk failure, the algorithm used to calculate the parity data is reversed to reconstruct the data which was stored on the failed disk. Under RAID 3, the data is striped across multiple drives on a byte level. RAID 4 stripes data on a sector level. Most tests have shown that RAID 4 will provide a better performance in comparison to RAID 3. Performance from these subsystems vary greatly depending on the applications being run.
RAID 5
RAID 5 extends the RAID 3/4 model again by interleaving the parity data across all the disks. In effect, both actual data and parity data is striped across the whole array of disks. Performance from these subsystems varies greatly depending on the applications being run.
For many years, users had been using RAID 1 to provide protection from disk failures. This was, however, very costly. The designers of RAID experimented with many different techniques to bring about both an efficient and effective form of data redundancy.
RAID levels 3, 4 and 5 do not need twice the number of disks. In the long run, this does reduce the overall cost of ownership whilst maintaining a reasonable level of data redundancy.
The implementation of RAID will inherently reduce the effects of disk failures. However, other environmentally preventative measures such as the use of UPSs and a separate battery backed up cache will eliminate the effects of power outages. Controller failure can be overcome by having dual redundant controllers and/or having two hosts connected to the RAID subsystem in a 'cluster' type environment. The ability to have load sharing, hot swappable power supplies and cooling fan assemblies will prevent disasters happening as a result of general wear and tear over time.
The implementation of RAID as hardware or software will make a significant difference to the performance of the subsystem. Some operating systems like Windows NT have RAID 5 technology built in. In some cases where the file server is not critical or the applications it is serving are not important - software RAID is sufficient. However, in most places where RAID is implemented, the data that it is serving is critical. In these cases, there is a strong argument for the installation of hardware-based RAID subsystems.
Disk specifications play a big part. RAID environments require a lot of disk access. The specifications such as the mean-time-between-failure (MTBF), the seek, latency and access times will play a big part in the performance of the subsystem. It is a little known fact that the seek and latency time of a disk make up over 95% of a disk I/O operation. The bandwidth (that is, the data transfer rate) of a disk makes up for under 5% of a disk I/O. Thus, investment in Fast/Wide interfaced disks which only run at 5,400 rpm is unlikely to add to the performance of the RAID subsystem. With disk prices dropping so quickly, users should be looking at purchasing 7,200 rpm drives and increasing the investment in cache, which will ultimately lead to increased performance.
The capability of the controller, such as:
Most RAID controllers only have one main processor. It looks after the RAID algorithms, cache negotiations, host negotiations and disk device management. Just as many organisations are now investing in symmetrical multi-processor (SMP) computers, why not invest in a RAID controller which has multiple processors, each dedicated to a specific task? (for example, one processor for RAID algorithms, one for cache management, one for each host connected, and one for each SCSI bus generated).
The number of SCSI buses generated will also effect the performance of the RAID subsystem. Some RAID controllers generate 2 buses, others will generate 7 or more. By having a greater number of buses (which should be married with an accompanying processor to handle the disk management), this spreads the load across many more buses (and processors), which leads to increased performance.
Industry analysts agree that in most environments, cache equals performance. If your organisation is running a high end processor (for example, IBM's PowerPC 604, HP's PA8000, or Digital's Alpha chip), in order to match the performance of these controllers, it will be necessary to have significant amounts of cache. A controller which can host say 512 MBytes of cache will allow your organisation to scale the amount of performance required from your subsystem.
Many controllers are now able to be configured in a dual redundant configuration. However, in most implementations, the second controller is passive - not doing any I/O serving unless the first controller fails. There are now a few manufacturers making controllers which provide active/active configurations. This allows the controllers to balance the load between each other, thus offering twice the performance to your organisations.
Where availability is an issue, fault tolerance will also be an issue. As a result, your organisation should look at RAID subsystems offering multiple controllers which will automatically fall over if one controller fails and which also offers the ability to connect to several hosts to overcome the availability concerns.
The smarter subsystems available today use battery-backed cache and a power monitor which will complete the outstanding write in the event of power outages. This is one system. Another way to provide constantly integral data is to use RAID levels which do not require cache such as RAID 0, RAID 1 or a combination of both.
Now that is off my chest ...
The argument over which tape technology is better has been going on for years. To be frank, each of them has their particular place in the market. Undoubtedly, the 4mm DAT tape drive is the predominant tape drive in the workstation market. To date, the 8mm Exabyte style of drives has provided greater capacity and higher throughput. However, of late, the DLT technology from Quantum (nee Digital!) has made quite an impact on the marketplace.
One of the most difficult things to judge when looking at tape drives is how each of them will perform. Some manufacturers quote a two-to-one compression ratio, others quote a four-to-one ratio. Some manufacturers quote sustained versus peak or burst throughput, so below is a table which summarises what is available (and a couple of what will be available):
Technology
|
DLT
|
8mm
|
4mm
|
||||||||||
| Product
|
DLT
2000
|
DLT
2000XT
|
DLT
4000
|
DLT
7000
|
EXB
8205
|
EXB
8205XL
|
EXB
8505
|
EXB
8505XL
|
EXB8900
Mammoth
|
DDS1
|
DDS2
|
DDS3
| |
| Capacity
(GBytes)
|
|||||||||||||
| Uncompressed
(native)
|
10
|
15
|
20
|
35
|
2.5
|
3.5
|
5
|
7
|
20
|
2
|
4
|
12
| |
| Compressed(1)
|
20
|
30
|
40
|
70
|
5
|
7
|
10
|
14
|
40
|
4
|
8
|
24
| |
| Sustained
Transfer Rate
|
|||||||||||||
| Uncompressed
|
1.25
|
1.25
|
1.5
|
5
|
0.26
|
0.26
|
0.5
|
0.5
|
3
|
0.23
|
0.41
|
0.75
| |
| Compressed
|
2.5
|
2.5
|
3
|
10
|
0.5
|
0.5
|
1
|
1
|
6
|
0.47
|
0.82
|
1.5
| |
| Average
access time
or Search Rate(2)
|
45
secs
|
68
secs
|
68
secs
|
60
secs
|
19
Mb/s
|
19
Mb/s
|
75
Mb/s
|
75
Mb/s
|
376
Mb/s
|
94
Mb/s
|
164
Mb/s
|
N/A
| |
| Load
time (secs)
|
30-45
|
30-45
|
30-45
|
30-45
|
8-10
|
8-10
|
8-10
|
8-10
|
8-10
|
6-8
|
6-8
|
6-8
| |
| 10
GByte Backup Time(3)
(estimated(4) hours:mintues)
|
|||||||||||||
| Uncompressed
|
2:10
|
2:10
|
1:51
|
0:33
|
10:41
|
10:41
|
5:33
|
5:33
|
0:55
|
12:04
|
6:46
|
3:42
| |
| Compressed
|
1:10
|
1:10
|
0:55
|
0:17
|
5:33
|
5:33
|
2:47
|
2:47
|
0:28
|
5:55
|
3:23
|
1:51
| |
| Tapes
required for a full backup - 100 GBytes(5)
|
5
|
4
|
3
|
2
|
20
|
15
|
10
|
8
|
3
|
25
|
13
|
5
|
Other factors relating to the type of system relate to whether the system is fast enough to drive the tape drives. Where DLT's are being considered, the size of the system is going to play a major part in the decision. In general - 'if your computer can "flood" your SCSI bus with data over a long period of time, then the DLT is likely to be of benefit to you'.
As high end processors like the Digital Alpha class servers hit the market, more and more UNIX systems will be able to take full advantage of the DLT's speed and capacity. For those organisations not having quite the budget to buy the new processors, the Exabyte Mammoth drives will certain solve the capacity and performance issues relating to tape backup.
The use of this command allows the tape drive to do the compression, not the software. After all, the tape drive was purchased on the basis that it will perform wonders in the compression department. Yet so many users go out and buy backup software which also promise high compression. If the data the tape drive is receiving is compressed, it is unlikely that it will compress any more!
Furthermore, by allowing the tape drive to do the compression, it is the hardware which will ultimately uncompress not the software when the crunch comes and you need to do a restore. After all, backups are made to facilitate restores.
The added benefit in having no additional backup software apart from the performance and compression considerations, is that when you do have a major disaster, and you need to make a major restore of all your data, you are faced with the re-installation of UNIX, followed by the installation, configuration, etc. of the backup software before you begin your install. If you calculate the time needed to do all of that, then the additional backup software is worth, in the least, a second thought.
Backups should never be done during business hours and tape drives should always go on a separate SCSI bus. This has the benefits of performance and easier maintenance. If there is only one device on a SCSI bus, then the likelihood is that it can be removed and replaced without shutting the system down.
In a similar vain, how the data is organised plays a large part. If you are backing up data from many different sources, it may be worth considering consolidating the data on an older scratch disk before submitting the backup job - again to improve the flow of data to the tape drive.
The lack of the constant flow will directly affect the performance of the subsystem.
If your backup window is small, then it is critical that the issues discussed in this paper are considered in preparing your backup. A well-tuned backup job can aid the performance of your backup device dramatically.
Return to Conference Proceedings