New RHEL 5.2, new SLES 10 sp2

Wow, Red Hat company released today second update of their RHEL 5. Read the release notes and Red Hat NEWS. The most important enhancements are related to virtualization and Infiniband technology. RHEL 5.2 contains OFED in version 1.3 now. More about it in my previous article.

Further, Novell released the second service pack for their SLES 10. It is written about it at Novell NEWS. And what's new here? The second service pack is delivering XEN in version 3.2., updated Heartbeat2 or OCFS2 filesystem. More about enhancements is here. Official release notes are available as well.

So, let's go to download and test the products.

SLES life cycle explaination

SUSE Linux Enterprise Server or shortly SLES is a Linux distribution widely deployed by many enterprise environments. The first version SLES 8 was released in April 2001. The successor SLES 9 was released three years later in 2004. And the latest available revision SLES 10 was released in the middle of 2006. The prepared SLES 11 is planned for the current year 2008.

Let's suppose we were using SLES since its starting point. We began to install SLES 8 on our servers. Then we upgraded some to SLES 9. And after all, we preinstalled a few new servers with SLES 10. So we began in 2001 and ended in 2008! Now, have you ever thought about your server lifetime? Or have you ever realised that your older installations would have to be migrated to the most recent release of SLES due to its maintenance and support cutoff?

The product support life cycle was more precisely defined in 2005 after acquisition of SUSE company by Novell. Perfect! With help of this, we are able to figure out how long will be our installations supported. I think it's interesting because Novell split the life cycle into three stages:

1. general support (gs) - bug fixes, security patches and enhancements of the product are available, a service packs may be released and a customer may request an installation or configuration support. It is provided for five years at least.
2. extended support (es) - only the most critical bugs are fixed if the bug is considered appropriate and strategic, security patches are always available. It is provided for two years at least and after gs end.
   
3. self-support (ss) - like knowledge base or discussion forums are available during the all stages until the product end and minimally for 10 years.

We don't have to forget that self-support is free of charge while the general and extended support is typically available for a fee. All in all, we have defined a minimum time for which Novell will take care of the product. If you want it is possible to find out more accurate periods here. And more about software maintenance is written here and here.

Now, let's try to apply the life cycle policies to the SLES releases and compare the results with official data from Novell:

1. SLES 8 - released in 2001, gs ends in 2006, es in 2008 and ss in 2011
   official dates: gs ends in 2007 , es is not offered and ss in 2012
   
2. SLES 9 - released in 2004, gs ends in 2009, es in 2011 and ss in 2014
   official dates: gs ends in 2009 , es in 2011 and ss in 2014
   
3. SLES 10 - released in 2006, gs ends in 2011, es in 2013 and ss in 2016
   official dates: gs ends in 2011, es in 2013 and ss in 2016
   

The only difference is for SLES 8 and it is caused by the acquisition in 2003 and redefinition of support policies. I hope the article will help you with proper planning of lifecycle of your servers based on SLES. It is difficult to decide when to move to newer release but it is really important to do it. Otherwise you risk your servers will stay unsupported and the chance to abuse them will grow. And that's not the goal.

Infiniband, RDMA, SDP ... a few facts

In the article about RHEL support of Infiniband technology I used a few keywords which should be explained in more details.

At first, what does RDMA means? The RDMA is simply an extension of DMA which allows computer devices to bypass CPU when accessing data in memory. The RDMA extends this feature so that LAN/SAN host bus adapters can access memory directly without CPU assistance. The CPU only instructs the hardware where the required data are.

What is SDP useful for? The SDP protocol allows to use network applications with Infiniband without rewriting them to understand the Infiniband technology. It is responsible for translating network socket operations to the RDMA layer. Of course, there exists a little descent of performance but it is still very near to the native bandwidth and latency characteristic.

The next scenario is you can apply IPoIB if you intend to use the Infiniband as your physical medium for TCP/IP protocol stack instead of standard Ethernet.

So, you have an network application and its standard communication scheme looks like this:

• app -> socket api -> TCP/IP stack -> Ethernet hardware
  

If you use RDMA then it will be like this:

• app -> socket api -> SDP -> RDMA -> Infiniband hardware
  

And the last variant based on IPoIB is this:

• app -> socket api -> TCP/IP stack -> IPoIB -> Infiniband hardware
  

Of course, you can port the application:

• app -> Infiniband api -> Infiniband hardware
  

And why we should know about these things? Why should we use it? There is a few important reasons why:

1. it provides a model when you don't need to port you application
   
2. it is really really suitable for CPU and I/O intensive environments

Next time, I would like to present some results for comparing the Infiniband with other transport technologies.