MAID

The concept of MAID (Massive Array of Inactive Disks) has been recently introduced. It refers to a collection of low-cost SATA (or even PATA) disks drives that are not active until they are accessed. Once a disk is going to be accessed, it is activated. This results in a lower acquisition cost and a lower operation cost, owing to the reduced electrical consumption. Of course, response time is heavily increased as compared with active disks, since the typical starting time of a disk is about 10 seconds. MAID can be used wherever access time is not a key factor; for instance, a MAID can serve as a cache to a tape library or as an alternative to tapes.


Intelligent Discs
We must also discuss a proposal from University of California at Berkeley researchers. The proposal addresses making use of the intelligence embedded within today’s disks. They call the proposal Intelligent Disks.

The rationale is straightforward: as the industry migrates towards higher-level interfaces such as SCSI or FC-AL, disk drives needed to embed greater processing power, nowadays typically making use of a 32-bit microprocessor and several megabytes of memory. The suggestion is simply to move some file system or database functionality onto this microprocessor.

Clearly, there is a question of balance; during IBM’s introduction of the S/360, processors were relatively slow, and thus there was substantial pressure to off-load tasks from them. This lead to the use of intelligent disk controllers allowing disk searches to be done according to specified criteria (the interface was called CKD or ECKD). As time passed, minicomputers and early microprocessor systems became rather higher performance and cheap, driving the adoption of simple, low-cost disk interfaces such as SMD and later ESDI. These interfaces had limitations, and once more an intelligent interface, this time SCSI, was introduced to overcome them, necessitating the presence of microprocessors and memory in the disk drives themselves.
Choosing commodity low-cost processors provided much more computer power than was needed by the task, but kept costs down.

The success of this approach, however, does not rest on hardware technology but rather requires that the industry adopt the standards, that operating systems support it, and—perhaps most significantly—that the major database vendors also adopt it.

Source of Information : Elsevier Server Architectures

The Story of RAID

If you’ve got only one hard drive in your server, feel free to skip ahead. Otherwise, let’s talk about putting those extra drives to use. The acronym RAID stands for redundant array of inexpensive disks, although if you’re a businessperson, you can substitute the word independent for inexpensive. We forgive you. And if you’re in France, RAID is short for recherche assistance intervention dissuasion, which is an elite commando unit of the National Police—but if that’s the RAID you need help with, you’re reading the wrong book. We think RAID is just a really awesome idea for data: When dealing with your information, it provides extra speed, fault tolerance, or both.

At its core, RAID is just a way to replicate the same information across multiple physical drives. The process can be set up in a number of ways, and specific kinds of drive configurations are referred to as RAID levels. These days, even low- to mid-range servers ship with integrated hardware RAID controllers, which operate without any support from the OS. If your new server doesn’t come with a RAID controller, you can use the software RAID functionality in the Ubuntu kernel to accomplish the same goal.

Setting up software RAID while installing your Linux system was difficult and unwieldy only a short while ago, but it is a breeze these days: The Ubuntu installer provides a nice, convenient interface for it and then handles all the requisite backstage magic. You can choose from three RAID levels: 0, 1, and 5.

RAID 0 A so-called striped set, RAID 0 allows you to pool the storage space of a number of separate drives into one large, virtual drive. The important thing to keep in mind is that RAID 0 does not actually concatenate the physical drives—it actually spreads the data across them evenly, which means that no more space will be used on each physical drive than can fit on the smallest one. In practical terms, if you had two 250GB drives and a 200GB drive, the total amount of space on your virtual drive would equal 600GB; 50GB on each of the two larger drives would go unused. Spreading data in this fashion provides amazing performance but also significantly decreases reliability. If any of the drives in your RAID 0 array fail, the entire array will come crashing down, taking your data with it.

RAID 1 This level provides very straightforward data replication. It will take the contents of one physical drive and multiplex it to as many other drives as you’d like. A RAID 1 array does not grow in size with the addition of extra drives—instead, it grows in reliability and read performance. The size of the entire array is limited by the size of its smallest constituent drive.

RAID 5 When the chief goal of your storage is fault tolerance, and you want to use more space than provided by the single physical drive in RAID 1, this is the level you want to use. RAID 5 lets you use n identically sized physical drives (if different-sized drives are present, no more space than the size of the smallest one will be used on each drive) to construct an array whose total available space is that of n–1 drives, and the array tolerates the failure of any one—but no more than one—drive without data loss.

Which RAID to Choose? If you’re indecisive by nature, the past few paragraphs may have left you awkwardly hunched in your chair, mercilessly chewing a No. 2 pencil, feet tapping the floor nervously. Luckily, the initial choice of RAID level is often a no-brainer, so you’ll have to direct your indecision elsewhere. If you have one hard drive, no RAID for you. Do not pass Go, do not collect $200. Two drives? Toss them into RAID 1, and sleep better at night. Three or more? RAID 5. Unless you really know what you’re doing, avoid RAID 0 like the plague. If you’re not serving mostly read-only data without a care about redundancy, RAID 0 isn’t what you want.

The Mythical Parity Drive
If you toss five 200GB drives into a RAID 5 array, the array’s total usable size will be 800GB, or that of four drives. This makes it easy to mistakenly believe that a RAID 5 array “sacrifices” one of the drives for maintaining redundancy and parity, but this is not the case. Through some neat mathematics of polynomial coefficients over Galois fields, the actual parity information is striped across all drives equally, allowing any single drive to fail without compromising the data. Don’t worry, though. We won’t quiz you on the math.

Other RAID Modes
Though the installer offers only the most common RAID modes—0, 1, and 5—many other RAID modes exist and can be configured after the installation. Take a look at http://en.wikipedia.org/wiki/RAID for a detailed explanation of all the modes.

Source of Information : Prentice Hall The official Ubuntu Book 5th Edition 2010

When considering the whole system (hardware, software, network and applications) isn’t the cost of the hardware negligible?

Hardware cost is just a fraction of total system cost, although it must be noted that the cost of storage is an increasing porting of hardware cost. This has given rise to some new storage approaches (SAN for Storage Area Network and NAS for Network-Attached Storage). And hardware cost is far from being negligible for high-end systems.

Just because hardware cost is reducing does not mean that choice of hardware is irrelevant. Indeed, the choice of a platform sets compatibility constraints within which the company will have to live for many years; migrating to another platform brings costs and risks. As indicated in some earlier FAQs, hardware costs and, even more, price/performance continually decrease. Software prices have also dropped significantly, although not to the same degree, because of the volume effects (compare the price of proprietary operating systems to those of UNIX and NT).

The price reduction in software has been less than for hardware because standardization of software is much less than for hardware. It is worth noting that well standardized fields generally show very low prices (operating systems, for example), while more fragmented domains see much higher prices, offering comfortable margins to their vendors (as with cluster-based systems).

It seems likely that current software trends (such as free software, Java, software components, etc.) will drive software cost erosion faster than in the past. This will drive the major portions of IT expenditure towards exploitation: integration, operation, administration, safety, performance tuning, and so on.

Source of Information : Elsevier Server Architectures 2005

Given that they are extremely complex to implement, will MPP architectures be confined to scientific and technical markets?

To take advantage of a massively parallel architecture, one must have applications written for it. The cost of developing such applications—or of adapting other applications for MPP use—restricts the number of applications. For applications needing intense numerical computation, companies computed the ROI (Return On Investment) and decided that the investment was worthwhile.

MPP architectures force the development of applications using the message- passing paradigm. For a long time, the major barrier was the lack of interface standards and development environments. Some candidate standards have appeared (such as PVM, MPI, or OpenMP), and there is a steadily-increasing number of applications built on these.

We should note here that the efficiency of such applications is usually dependent on the performance (in particular, the latency) of message-passing (including all relevant hardware and software times). Not unreasonably, the first MPP applications to appear were those that could straightforwardly be decomposed into more or less independent subtasks, which needed only a small number of synchronizations to interwork effectively. Thus, mainly scientific and technical applications (in fields like hydrodynamics, thermodynamics, and seismology) were first to appear for MPP.

There is another brake on the flourishing of this class of machine—the lack of low-level standards providing access to the interconnect. This lack means that there is substantial difficulty in adapting higher-level libraries to the various hardware (and interconnect) platforms; effecting such a port requires high technical knowledge and skills, so moving between one manufacturer and another is difficult. Various industry initiatives, such as VIA or Infiniband, could bring sufficient standardization that MPP could spread.

MPP products are challenged in yet another direction: the appearance of peer- to-peer systems, grid computing, and clusters of PCs. A key factor of such solutions is low cost, driving the development of applications that can quickly turn into industry standards. The rise of these approaches could condemn the MPP proper to an early grave.

To finish this discussion, recall that in 1984 Teradata brought to market what were probably the first MPP systems. These systems, deploying Teradata’s own proprietary DBMS, were used in decision support, needing the processing of very large volumes of data (several terabytes). With the advent of large clusters and MPP systems from other manufacturers, the major database vendors subsequently produced versions of their software to run on this class of machine.

Are RISC processors dead, killed by Intel?

Source of Information : Elsevier Server Architectures 2005