The Next Generation Massively Scalar Architectures

Up to now you needed a couple of million to play in the massively scalar market

Traditionally massively scalar architectures have incorporated high-end heavy data processing machinery such as the systems produced by Cray Computers and Tandem amongst a slew of other proprietary machines from Intel, nCUBE etc. These high-end systems not only exhibit high performance figures, but similarly high price tags. When one plots the cost per user of systems in general, based on the total number of users the system is capable of supporting the following graph provide an approximation of typical cost trends exhibited:

Single user systems are naturally more expensive to run on a per user basis since resources are not shared amongst users. However we find a dip in the curve in the 30 to 100 user systems. These systems are essentially off-the-shelf high powered microprocessor's (PC's and workstations). The problem here, of course, is that if we have an application that requires more horse power than can be provided by low cost servers, we typically have to resort to purchasing high priced super servers from the high-end vendors.

When one examines the architectures of high-end servers it becomes immediately apparent that one of the key ways to build systems capable of supporting heavy loads is to attempt to split the problem into separate smaller elements. Mainframes have separated off individual processors for IO, Front End Processors for handling terminal and network load etc. The high end Cray's, Tandem's, nCUBE's, Intel Paragon and iPSC2's etc. parallelise the system infrastructure. All the highly successful Symmetrical Multi Processor systems from vendors such as Sequent, Sun, HP and Pyramid and other systems such as IBM's SP2's all use the same basic approach of splitting the problem domain into parallel tasks. This allows simultaneous execution of application code on multiple parallel processors. Some of the key differences in high-end system implementations revolve primarily around differences in bus and memory architectures.

Of the more common multi-processor architectures, the SMP systems, which have been successful in the past couple of years in capturing high end RDBMS market, have in themselves been evolving. Early SMP boxes were designed with single global memory segments attached to multiple small caches on each CPU (typically 128k caches). One of the key advantage of these systems was that you could take existing applications that had been written for uniprocessors and run them on the SMP boxes. With a little tweaking and often minor architectural changes, these applications could be made to perform efficiently across multiple processors in parallel. RDBMS applications typically take advantage of the multiple processors by spawning new processes for each user that logs on to the system, these separate processes can in turn be run in parallel across multiple CPU's (Incidentally this very advantage can become a serious disadvantage when the processes start to consume more real memory than is available while managing the contexts becomes a burden on the OS, TP monitors and some of the more modern RDBMS's solve this problem by allowing you to tune the system to share processes amongst users).

When examining current SMP implementations you will find that the cache sizes on SMP boxes have become quite large, typically 2MB. This represents a significant distributed cache management problem for the SMP systems. The problem is that when a process migrates from one CPU to another it is necessary to move the cached contents along with it - effectively eliminating the advantage of high cache hits (Cache hits are a key to high performance, since the cache is capable of feeding the hungry processor at fast enough rates, while slower memory and disk systems tend to cause the processor to have to wait and consequentially loose processing cycles). Features such as cache affinity become important in SMP architectures. Cache affinity assists in migrating a process or binding a process to an individual CPU and cache.

SMP architectures are starting to look a lot more like loosely coupled multiprocessor architectures. These large caches essentially represent distributed memory segments. Loosely coupled architectures are not new, Tandem's Guardian series and Cray's have been around for some time, amongst many other high end systems. Newer Distributed Multi Processors (DMP) such as the architecture found in IBM's SP2 or the new Sequent Numa cube architecture also reflect a loosely coupled DMP bias.

Other two attempts to create large scale systems revolve around clustering technology. Clustering technology has also been available for many years. The early DEC HSC50 controllers allowed you to attach disk subsystems to more than one host. Hosts could effectively access the same data residing on shared disks, thus making it possible to process requests on separate systems for shared data. It should be noted that much of the existing cluster technology available from UNIX and NT vendors does not allow simultaneous access to the shared disk systems. These clusters permit only one system can access the disks at any time. The second system acts as a hot standby, and requires the disks to be 'failed over' for access. This type of fail over results in what can be a significant switch-over time - hence the name 'High Availability" and not what some vendors incorrectly refer to as Fault Tolerance. The second attempt in this same category worth mentioning, is Oracle's OPS architecture. With OPS, systems are attached to the same disk subsystems while a lock manager which resides across the systems mitigates locks and controls disk access, giving both systems 'simultaneous' access to the same data on the shared disk subsystem. A separate network connection is used to pass lock information between systems. The fundamental problem with these types of disk clustering architectures is that they are founded on utilizing the very slowest element of a system, the disk drives, as the integration mechanism! These systems will only be as fast as the disk drives.

Make it Proprietary and you've got em locked in.

Coupled with this change in multiprocessor architectures is the problem of designing applications to run effectively across multiple parallel CPU's with separate memory segments. This is no simple task and has typically required highly specialized proprietary programming of the systems. Each vendor provides it's own implementation, API's and control infrastructure. Most of these systems essentially provide a library of high speed message passing routines, each unique to the implementation.. In other words the systems are PROPRIETARY, which has at last been recognized by most industry experts as equating to BAD. Many systems do however support UNIX based micro-kernel implementations that run on the nodes, or UNIX interfaces which improve application portability. However vendors who have been capable of building these high end systems have in all cases utilized their proprietary message passing architectures which lock-in customers allowing the vendors to continue to charge high premiums. The message passing API's on these systems have in nearly all cases maintained proprietary interfaces.

There is light at the end of the tunnel

The major problem with existing massively scalar systems, apart from their price, is their proprietary interfaces. Work being done in the Object arena does however promise to provide standardized interfaces across distributed systems.

Early research work into micro-kernel architectures spawned the introduction of the Object Request Broker (ORB) architecture. ORB architectures started emerging as Open Systems were taking their grip in the late 80's and early 90's. This resulted in many of the key players getting together to establish ground rules and standards to ensure that there ORB's were 'open'. From these efforts the CORBA standard emerged. This standard has effectively left most proprietary Middleware vendors, some of whose products could also be classified as ORB's, out in the cold.

There are exceptions of course, the new gorilla on the block, who seems to be effectively displacing and gaining on the big blue gorilla, our dear friend Microsoft. Microsoft it appears, seems to have seen the vision of ORB's early on in their career, or they stumbled on ORB architectures through natural evolution of their infrastructure. Regardless of how Microsoft got to where it is now, the company has in the face of the general industry consensus, decided to go against the CORBA grain and 'standardize' on their own OLE based infrastructure called DCOM (Now also marketed under the ActiveX name).

These ORB standards represent the next computer systems holy wars (after the OS wars which are becoming old hat).

Life is of course, not always as simple as two choices, there is one other 'non standard standard' worth mentioning. This new wild card in the ORB arena has emerged surprisingly from one of the earliest proponents of the CORBA standard, Sun Microsystems. Sun jumping on the rampant success of the newly named Oak product (Java) decided that they too could go it alone, and introduced a new non CORBA compliant ORB called Java RMI. Java RMI however currently only addresses Java to Java communications so it is still somewhat limited in it's use, particularly in regard to the integration of legacy infrastructure.

We cover these ORB architectures in detail in our ORB seminar so I will not spend much more time getting side tracked off our massively scalar systems topic.

The key aspect to realize is that we now have firmly established standard interfaces for communicating across distributed systems: CORBA IDL, and Microsoft MIDL. These standard interfaces open up a whole new era of computer systems architectures. With these ORB's it is now possible to create advanced distributed applications that run across multiple different distributed platforms.

ORB's open up new boundaries.

One of the key advantages to an ORB based architecture is that the ORB provides the 'glue' or message passing infrastructure for communications between distributed applications (objects).

It is possible to dynamically route messages in through the ORB infrastructure, enabling for example, the design of n-way fault tolerance in applications. A message sent to a failed server can in real time be sent to another fault tolerant standby. In a similar fashion, it is easy to replicate messages as they are transmitted through the ORB.

ORB's make it easily possible to farm out processing requests in parallel across the network. Load may for example be distributed based on individual systems loads, creating dynamic distributed load balancing and parallel processing across the network.

Depending on application architecture, it is often possible to split applications across multiple nodes creating server clusters with effectively no limitation on scalability. The big difference with these types of clusters to disk based clusters, is that the network and the ORB is used for integration and not the slow disk drives. One simply adds servers and networks as the load increases. Multicast technology in ORB's provide key features for allowing the implementation of these massively scalar systems (a topic of a future white paper, but currently covered in our seminars)

All this with off-the-shelf hardware and software!

The key aspect to realize, is that standards are now available to build massively scalar implementations using off-the-shelf hardware and software. The new interface standards even make it possible to communicate across disparate platforms - from MVS to NT to UNIX and PC's without the applications on either platform knowing or caring what type of system the message came from, the interface is the same regardless of the platform.

Understanding how these architectures work is key to building the next generation systems. Learning the tricks and techniques used to implement fault tolerance and clusters provide the systems architect with an arsenal of new techniques and tools. ORB's have enabled us to tackle problems that have never before been possible, even when using the fastest hardware solutions in the market. ORB's open up numerous new possibilities with high-end applications that could not afford the high cost of super computers.

ORB's are here now, they have already been used in massively scalar implementations and are providing corporations with key competitive advantages. Are you and your organization up to speed?

These details, principals and standards are addressed extensively in our seminar program. If you are interested in learning more, give us a call and come along to one of our seminars. We guarantee we will change your strategy. Details can be found at the following links:

ATSI Seminars

Comprehensive Overview of Distributed Systems Technologies
Detailed Architectural Comparisons of Object Request Brokers

ATSI Seminar Registration