Ellison speaks on the Oracle Grid architecture

When you run one of the world's largest companies, you get to redefine common terms, and Ellison explained that enterprise grid computing is fundamentally different from the traditional notion of grid computing. In traditional grid computing, a massively parallel problem is broken down into tiny chunks and solved in parallel on thousands of remote processors (the grid). In Oracle's enterprise grid computing, resources are allocated and deallocated from a rack of small Intel-based blade servers.

However, grid computing is not a mainframe-like approach. Ellison has reservations about the robustness and capacity of the large, single-server approaches to Oracle consolidation, claiming that the large mainframe-like UNIX servers are constrained to 128 CPUs. Ellison also claimed that these large monolithic systems introduce a single point of failure.

The Oracle enterprise grid architecture gets around this problem of scale and reliability by allowing blade servers to be allocated and deallocated from the grid depending upon usage requirements. This concept of on-demand server allocation and deallocation is well known within Oracle circles, and is not a new technology. Savvy Oracle Real Application Cluster (RAC) DBAs know that Oracle instance servers can be allocated and removed from a RAC cluster in real time, providing extreme flexibility and scalability. Oracle Application Server administrators can also add and remove Web cache servers and HTTP servers from their architecture when processing demands change.

Ellison noted that the movement to his vision of enterprise grid computing is economic, and noted the high speed and low-cost of the 64-bit Intel Itanium processors. Abandoning his endorsements of Sun Microsystems back in 2002, Ellison embraced the Intel solution, noting that small server blades are cheap ($2,500) and are a better buy than the proprietary UNIX servers.

In Oracle's vision, a single all-encompassing monitor will govern the use of blade servers, tracking both current and historical usage patterns. The promise of a proactive monitor was very well received by those in the Oracle community who want to be able to track repeating patterns of usage over time and allocate just-in-time computing resources. Ellison also made the important point that current server farms are incredibly wasteful, with hundreds of servers having overallocated CPU and RAM to handle sporadic spikes in processing needs.

Will the market respond?

It seems that all of Ellison's points were firm and well understood, and most industry analysts agree that the immediate future of large computer systems will be with server consolidation. However, the vendors of the large servers (i.e., 32 CPU, 64-gig RAM) pointed-out several flaws in the logic:
 

• Better reliability?Mainframe-like processors can be configured to avoid the single-point-of-failure problem. Vendors note that fault-tolerant components can be used to make a single server as reliable as a distributed scheme. They also note that Oracle's own failover tools (Data Guard and Oracle Streams) can make systems resilient to hardware failure.
   
• Better on-demand CPU and RAM allocation?Critics say that the mainframe-like UNIX behemoths provide internal resource allocation that will be more efficient than a distributed model.
   
• Better scalability?Critics noted that the server blade approach to grid computing allocated independent units of dyadic or quadratic processors, making Oracle Parallel Query less efficient. A 32-CPU monolith will be able to process a large Oracle table far faster than a grid of small independent processors.

In sum, Ellison's visionary plan is based on well-accepted economic and scalability principles, but there is disagreement on whether grid computing will be accepted over the server consolidation approach, and only time will tell whether Ellison has a hot technology.