Explaining RTI architectures

Posted on: June 10th, 2009 by Pete Manca 1 Comment

With the entry of new products to the market such as Cisco’s UCS and HP’s Matrix Operating Environment – a new name for HP’s collection of tools – I thought it would be worthwhile to re-visit the architectures for Real Time Infrastructure and discuss the different approaches and what the strengths/weaknesses are of each. Specifically, I’ll discuss the different fabric architectures used in these products, as that is one of the key differentiators between the various offerings.

The three types of fabrics I’ll discuss here are Converged Fabrics, Dynamic Fabrics, and Managed Fabrics.

Converged Fabrics

I’ve blogged about Converged Fabrics in the past, though when I looked at the date I found out that it was 2 1/2 years ago! Time flies when you’re having fun, and certainly the market has changed quite a bit since then.

A converged fabric architecture takes a single type of fabric (e.g. Ethernet) and converges various protocols on it in a shared fashion. For example, Cisco’s UCS converges IP and Fiber Channel (FC) packets on the same Ethernet fabric. Egenera’s fabric does the same thing on both Ethernet fabrics (with our Dell PAN System solution) and on an ATM fabric (on our BladeFrame solution).

At the endpoint of this fabric is an IO bridge, which is the convergence and conversion point. This is where the protocol gets converted to it’s native form. For example, when FC traffic is sent over an Ethernet converged fabric, the Ethernet packet carrying the FC data terminates at the IO Bridge. That Bridge then creates a new transmission in native Fiber channel and sends the data over the FC fabric.

The benefit of this approach is that a single fabric can be used to carry multiple types of traffic. This reduces cables, complexity, and cost. The downside is that packets get terminated and re-started at an IO bridge, which can add latency. However, the latency in the IO Bridge is typically much smaller than the latency of the external devices so, in reality, it’s not a major issue.

Vendors that use this fabric architecture include Egenera, Cisco, and the Infiniband vendors such as Xsigo and Voltaire. There are also a host of switch vendors who will take advantage of the new IEEE Ethernet standards to deliver switches that can support this type of architecture. While Cisco’s fabric is new to the market, Egenera has been selling this solution for 7+ years and has hundreds of customers and over 1400 installations. This architecture has been proven in the market.

Dynamic Fabrics

Dynamic Fabrics are not converged, but rather separate fabrics that can be have their configuration modified dynamically.  This is the approach that HP uses. Rather than utilize a converged fabric, HP has separate fabrics for FC and Ethernet. These fabrics can be dynamically re-configured to account for server fail-over and migration. HP’s VirtualConnect and Flex10 products are separate switches for Fiber Channel and Ethernet traffic, respectively.  When a server is moved (maintenance, fail-over, etc.) the switch is re-programmed so that the communication paths are re-wired to match where the server has been moved. For example, HP’s VirtualConnect leverages NPIV technology, which allows a WorldWideName to be re-deployed from one switch port to another, thus allowing a server to be moved and still have access to its LUNs. This removes the need to re-zone the SAN when a server is moved. It’s useful technology.

The benefits of this type of fabric is that it reduces port count (NPIV ports can be shared) and complexity. However, it doesn’t reduce the cost. The servers need to have both Ethernet and Fiber Channel cards and there are multiple fabrics which are fairly expensive.

Vendors that use this type of technology include HP and Fujitsu.

Managed Fabrics

The 3rd type of fabric is a Managed Fabric. In this architecture there is no convergence at all. Rather, the vendor programs the Ethernet and Fiber Channel switches to allow servers to migrate. This is a bit like the Dynamic Fabric above, however, these typically are not captive switches and there is no convergence whatsoever.

The advantage of this approach is that it allows the customer to use their existing switches. The downside to this approach is that the management software is literally re-programming the premise switches (Ethernet and SAN) on the fly, which is typically not allowed in a well-run data center. This can lead to security issues, maintenance issues, compliance issues, and data center policy issues. This approach is better suited for test/dev environments where switch re-programming is not as big of an issue (though still an issue I maintain).

Vendors that use this approach include Scalent.


So, that was a quick trip through the various fabric architectures for a real time infrastructure. Each has its plusses and minuses. I believe the Converged Fabric approach is the correct architecture (big surprise there!) and also the future of where the data center is headed. It provides so many customer advantages, as customers can use an interconnect they are already familiar with (Ethernet), with a large ecosystem and a strong roadmap. It also is the best fabric architecture for lowering costs and complexity. As the IEEE standard gets finalized and the price for 10G Ethernet and Converged Network Adapters come down, I predict that that data center will finally see wide spread adoption of the Converged Fabric.

Sign Up

Stay up to date with all of the latest news, promotions and events.

  • Latest Whitepaper

    Egenera Cloud Suite - An Overview

    > download
  • Latest Videos

    Visit Egenera’s Video Library

    > click here
  • Latest Webinars

    Visit Egenera’s Webinar Library

    > click here