Red Hat Goes Grid and Real Time with Enterprise MRG Distro
Published: December 11, 2007
by Timothy Prickett Morgan
Commercial Linux distributor Red Hat is in the process of fleshing out its so-called Linux Automation strategy, and last week announced one of the key add-ons to its core Linux product that it hopes will allow it to attain a 50 percent market share of server shipments by 2015, a goal the company announced a month ago as it released Red Hat Enterprise Linux 5.1, an update to the virtualization-enabled Linux variant the company introduced in March.
That new add-on, which will be called Red Hat Enterprise MRG (pronounced "merge"), will weave together a number of technologies that make servers running this software an appropriate platform on which to deploy applications that rely on messaging, real-time, or grid technologies. Enterprise MRG will be sold under a separate subscription, according to Bryan Che, a RHEL product manager at Red Hat; pricing is not available for the product yet, since it is not expected to be delivered until sometime in the first half of 2008. In the case of the real-time extensions to RHEL enabled in Enterprise MRG, this will require the swapping of the generic Linux kernel with a real-time kernel based on the CONFIG_PREEMPT_RT patch set, which Red Hat, Novell, IBM, Silicon Graphics, and a few others are developing under the watchful eye of Ingo Molnar, a hard-core hacker who is in the employ of Red Hat at the moment. (If you want to get al the gory details about the CONFIG_PREEMPT_RT patch set, you can read all about it on the real-time Wiki at the kernel.org site where the Linux kernel lives.).
In this regard, Enterprise MRG is similar to Novell's SUSE Linux Enterprise Real Time, or SLERT 10, variant of SUSE Linux Enterprise Server 10. However, Enterprise MRG is more than just a real-time operating system, as the name suggests, and even where there are similarities, Che says that Red Hat is being careful to use the same set of compilers for both RHEL and Enterprise MRG so applications certified for RHEL (in either a physical or virtual instance) will be supported without the need to recertify on Enterprise MRG. (He suggested that Novell, by adopting extensions to the GNU GCC compiler set with SLERT 10, was requiring software makers and in-house software developers to recertify their SLES 10 applications on SLERT 10.) In any event, Novell charges $2,500 per server for the SLERT extensions to SLES 10, which costs $799 for a standard license. You can expect the same kind of premium price for Enterprise MRG relative to RHEL 5.1 licenses.
Enterprise MRG will be interesting in that Red Hat will be able to peddle a real-time variant of Linux--which it has arguably done the most work in bringing to market with the latest set of patches. There certainly are customers who want a more streamlined Linux with lower transaction latencies, particularly in the financial services and embedded processing markets. But the new software is more than that.
Perhaps equally significantly, Enterprise MRG is expected to be the first commercial operating system to deploy an open standard messaging technology called Advanced Message Queuing Protocol (AMQP). This is the "M" in Enterprise MRG, and for many companies--again, here we go in financial services--this is as important as low latency. The Advanced Message Queuing Protocol working group is developing a specification for a common messaging client and server broker; the resulting specification will provide a standard for the many different kind of messaging products that are used on the market, including store-and-forward transactional messaging, batch file transfer messaging, and high-performance publish and subscribe event notification. There are myriad products that allow for the relatively loose coupling of distributed computing platforms--IBM's WebSphere MQ, Microsoft's Message Queuing Middleware, Tibco Rendezvous financial transaction messaging, and the Java Messaging Service are examples, just to name four. Messaging is necessary for a number of reasons, but mainly because in a distributed application environment, where you cannot assume that network and applications will always be available, you nonetheless want distributed applications to finish their transactions. Messaging allows for the elements of transactions to be buffered and then completed later.
AMQP will be different from all of these in that it is an open specification that software vendors will in turn implement--so it is hoped by members of the working group, and considering who they are, it is reasonable to believe this will happen. It's not just the vendor community, but the user community that is driving this standard. So far Cisco Systems, Credit Suisse, Deutsche Börse Systems, Envoy Technologies, Goldman Sachs, Iona Technologies, iMatix Corporation, JPMorgan Chase, Novell, Rabbit Technologies, Red Hat, Twist Process Innovations, and 29West are members of the working group. Once the specification is out, Microsoft, IBM, Tibco, and other sellers of messaging products will have little choice to see what this technology is and wonder when customers start expecting them to implement the AMQP standard. And the transition might be good for them and transparent to customers, such as when IBM switched from its own (and not very good) HTTP Web server to the open source Apache server within its WebSphere middleware many years ago. The AMQP spec enables application programming interfaces for C, C++, Python, C# or any other language on Linux, Unix, Windows, z/OS, and any other operating system you might think of.
The final part of Enterprise MRG is the grid part, and for this, Red Hat has been working with the nerds at the University of Wisconsin on its "Condor" grid project. According to Che, one of the first things that Red Hat did when it joined Condor was to integrate the libvirt virtualization hypervisor manager in RHEL 5 into the Condor grid management software. So now instead of trying to deploy applications on a RHEL 5 grid, the software stack you want to run on the grid can be virtualized and decoupled from the iron. So, for instance, if you have a network of Windows PCs, you do not have to deploy a special agent running your software in background on the PCs (coded and compiled for Windows) or deploy an actual Windows application from the grid management software. Rather, you deploy a virtual instance of whatever operating system is running (presumably on X86 or X64 processors) and just deploy that natively on a virtualized PC, and you leave the Windows instance untouched. You can deploy a Linux workload in a Linux partition today, and do a Solaris or Windows Compute Cluster Server partition for another workload tomorrow.
As part of the agreement between Red Hat and the University of Wisconsin, the Condor software will seek an OSI-compliant software license that will allow the code to be distributed as part of a RHEL stack (which one has not been specified yet), and Red Hat is kicking in funds and probably coders to help with the ongoing development of the Condor code.
As is the case with SLERT 10 from Novell, the real-time extensions to RHEL 5.1 that make up Enterprise MRG will only be available on X86 and X64 server platforms. However, according to Che, the AMQP messaging and Condor grid software will eventually support other server architectures that support RHEL 5.1 today.
The software will also support local and remote deployment as well as provisioning and deployment on various compute clouds. Red Hat is already beta testing RHEL 5.1 on the Amazon Enterprise Compute Cloud (EC2), and more are sure to follow. Some of them will be internal compute clouds, some will be commercial.
Novell Swaps the Kernel Guts in Real-Time Linux
Red Hat and Platform Computing Partner for Supercomputing
Red Hat Puts Out Fedora 8 Rev of Development Linux
The Low-Down on Red Hat Enterprise Linux 5.1 Enhancements
Red Hat to Use Automation, Virtualization to Eat the Server Space
Red Hat Puts Out Fedora 7 Community Release
Red Hat, IBM Commit to Better Mainframe Linux
RHEL 5: How's It Going?
Red Hat to Push Desktop Linux with Intel Partnership
Red Hat Integrates and Simplifies with RHEL 5
Post this story to del.icio.us
Post this story to Digg
Post this story to Slashdot