cluster have access to the same data. A cluster of computers is scalable, fast, and fault-tolerant.
Unfortunately, we don't live in a theoretical world. The main obstacle to this transparent clustering is that different hardware and different OSes don't often cooperate with each other. To set up a cluster today,
you'd have to purchase your systems from the same vendor, run the same OS on them all, and run the same clustering software on them to have a perfect cluster.
There is hope, however, in the form of emerging standards, especially in the Windows NT arena. Here's a look at where clustering technology stands and where it's headed.
What Clustering Is Good For
Simply put, clusters increase availability and performance by loosely coupling two or more systems. These systems, however, appear to you as one. When you log in to a cluster, you needn't know which system in that cluster you're logged in to. If one system in the cluster fails, another takes over.
It sounds like a simple fault-tolerant system, but it has an advantage. In a fault-tolerant system, you will typically have duplicate components that stand by until something bad happens. In a cluster, however, all components are hard at work divvying up work. When something goes wrong, the other systems in the cluster compens
ate. Unlike a fault-tolerant system, however, you may notice performance degradation when something fails because the cluster will balance the same load on fewer systems.
According to Donna Scott, research director at the Gartner Group, an information technology consultancy, the performance angle for clustering is sometimes overstated. "Clusters are good for reducing downtime," she says. "It's possible you can get a performance boost by adding a node," but you may generate more contention for a shared device, thereby actually lowering the overall performance. "Scalability has not been shown to be terrific in a shared data cluster," according to Scott.
An excellent example of clustering occurred two years ago, when 1500 computers on the Internet worked for about eight months to break RSA Data Security's encryption key challenge. This cluster exemplifies high performance (it was the first system to break the key), fault tolerance (the systems involved went on and off the Internet unpredictably), s
calability (1500 systems), and load balancing (the whole system used only free CPU cycles on the systems involved).
Nodes in small clusters that are aimed at business applications typically are connected together using standard network links or other common interfaces. For example, it is quite common to link servers over an Ethernet or Fiber Distributed Data Interface (FDDI) network. Similarly, you might see systems sharing resources, such as memory, through a SCSI connection or a proprietary link. Digital Equipment's VMSclusters, for example, can run over either the proprietary Cluster Interconnect (CI) bus, DSSI (which is similar to SCSI), or SCSI. And we're just starting to see clusters brought together using newer technologies such as asynchronous transfer mode (ATM) or through a Memory Channel Interconnect interface, a clustering interface developed by Digital.
Lock Management Is Key
Any application can run on some kind of cluster, even if it isn't designed to do so: If yo
u log into a VMScluster and run a spreadsheet, you're running the same spreadsheet as you would if the VAX weren't part of a cluster.
But this spreadsheet isn't taking advantage of all the cluster's features. Say you had some difficult computation to run in that spreadsheet. It would run on only one processor in the cluster, and if the system that the spreadsheet were running on failed, it would crash.
To take advantage of a cluster's load balancing and fault tolerance, you have to write it to use the OS's clustering APIs. Such APIs give an application access to system resources, including CPUs, memory, storage devices, and I/O drivers to peripherals. It is often a nontrivial task. Why? The answer is lock management. This becomes an issue when two users try to access the same record in a database, but they're coming in through two different systems on the cluster--two systems that share the same disk farm, but not memory or processors.
Fortunately, major database management system vendor
s, such as Informix, Oracle, and Sybase, have taken care of this problem for you. They offer versions or add-ons of their programs that are geared to run in clustered environments.
One way this is accomplished is through a clustering scheduling program called a distributed lock manager. It works in a similar way to a file-locking mechanism in a traditional DBMS. With a DBMS, one user, for example, cannot change a table that is being edited by another user. In a traditional DBMS program, the program resides on one server. This makes it somewhat easier to lock files. You will need a similar type of locking when an application is distributed over several servers in a cluster.
But what if you want to write an application? Ideally, you could write it without worrying about things like record locking between systems. That's accomplished by using APIs to give applications access to services that synchronize multiple CPUs and other system resources. An alternative is to use a distributed OS that handles
many of these things for you.
There are also other ways to accomplish the same thing. For example, third-party solutions, such as Local Area Multicomputer and Distributed Queuing System, help you break up an application so that it can run over a cluster.
Also, middleware packages help you build clusters. One example of this type of software is Hewlett-Packard's ServiceGuard middleware, which gives you the ability to create a cluster of T500 servers.
There are also some hardware vendors who are gearing their products toward the clustered distributed relational DBMS (RDBMS) approach. For example, NCR offers a combination of servers and middleware to provide what is essentially a turnkey data warehouse system for large organizations.
Kinds of Clusters
You can think of clusters in two main ways: from the perspective of how storage devices are shared, or from the point of view of how an application executes on the cluster. Both these perspectives have alternative impl
ementations.
According to Scott, there are three main cluster architectures, divided by how they share their storage: shared disk, shared disk with lock management, and shared nothing.
In a shared-disk architecture, an application has access to data on disks on all other nodes. Examples are IBM's High Availability Cluster Multiprocessing (HACMP) for AIX and Hewlett-Packard's Multi-Computer Service Guard. This method is quite useful since it lets you keep data on machines that are optimized for just such a purpose.
Shared disk with lock management is basically the same, but it adds software that deals efficiently with contention for the same data (e.g., two users who want to access the same record in a database). IBM's HACMP, Oracle's Parallel Server, and HP's Multi-Computer Lock Manager are examples in this arena.
In the shared-nothing architecture, an application running on a node has access only to the data on its own disk drives. This architecture is optimized for processor-to-p
rocessor communication. According to Scott, this type of cluster usually employs data replication or also uses a shared-disk architecture to share data among the systems.
From an application's standpoint, there are two approaches to sharing a cluster's resources. With data-sharing concurrency, applications know about shared storage resources but take little advantage of the other CPUs in the cluster (see the figure
"Breaking Up Isn't Hard to Do"
). With parallel-execution concurrency, the application can run in parallel on several processors. The former requires few code changes to give an application access to the cluster, while the latter requires a major coding effort so that the application runs in parallel on several nodes within a cluster.
One of the troubles with developing a system based on parallel-execution concurrency is that there are many ways to partition an application. For example, you might take a complex SQL statement and split it into a number of discrete e
lements such as scan, sort, and join. Each operation is then carried out in parallel within the cluster. In this way, a single SQL query is carried out more quickly. Alternatively, you might instead keep the query intact but execute it on a number of data volumes or tables at the same time.
Choosing between parallel-execution and data-sharing concurrency often depends on the application. With data sharing, you essentially execute the same algorithm on every machine. The algorithm must be modified so that it can take advantage of the fact that all the data the algorithm needs for its search or computation is not on any one node. So the algorithm must know, for example, that some rows of a database table are on this node and other rows on that node. However, overall the algorithm remains largely unchanged. With parallel execution, there must be a high degree of inherent parallelism in the algorithm. Such algorithms typically perform a number of independent operations sequentially.
With either clus
tering approach, you'll need a way to monitor the application and to ensure that the system is working as it should.That's where you should see some action this year. For example, HP has announced a package called ClusterView, which lets you manage clusters. It works on clusters formed using ServiceGuard, which lets you link HP T500 servers over a Fibre Channel connection.
With ClusterView, you get a graphical view of clusters and the nodes making up the cluster. Like most management systems, icons representing the nodes change colors when a problem occurs.
Help Is on the Way
We can all think of many applications that would benefit from clustering--from databases to e-mail servers. As appealing as it is to make applications cluster-enabled, there's a big obstacle holding everyone back: You have to customize the clusterization of an application for each environment the application will run in.
The reason for such one-at-a-time modifications of applications is that there a
re so many parameters to take into consideration. For example, one company may be running an Oracle database on a Windows NT-based Alpha server and a Unix RISC-based server. Another might use all NetWare servers. Still another may have a mix of NetWare and VAX systems.
The challenge today is to develop a common way to partition an application so that it can easily be ported to the clustering environment. One step in that direction is I superscript 2 O, a platform-independent device-driver specification (see the sidebar
"Clustering's Path to Platform Independence?"
). Ultimately, however, it's going to take more than device drivers.
To that end, Microsoft formed a consortium with other vendors including Digital to develop a set of clustering APIs for NT. Microsoft officials said that the consortium intends to deliver clustering APIs in two phases. In the first phase, it will deliver an API that enables you to write applications that can fail over to a second Windows NT server. In the seco
nd phase, the API will enable load balancing. This solution, however, is still OS-specific. Unfortunately, it's not likely that any vendor will overcome the technical and market hurdles to develop a truly cross-platform cluster.
illustration_link (11 Kbytes)
Data-sharing clusters are good when applications only need to share storage resources. If you also need concurrent processing, choose parallel-execution clusters.
Salvatore Salamone is a BYTE news editor. You can contact him on the Internet at
editors@bix.com
.
Clusters for the Masses
