Egenera Blog

Egenera – as well as much of the IT industry – is standing at an exciting point in its evolution.

When Egenera was founded in 2000, nearly nobody had heard of virtual I/O or converged networking. In fact, blade servers were hardly part of the vernacular. But the company had a vision of simplified data center management, more “universal” HA and DR, and a more integrated approach to re-purposing servers.

Where we are

Today, with the maturing OS virtualization market and the newly developing unified computing domain, industry terminology has changed but our vision hasn’t.  We’re still focused on how unified computing, converged networking, virtual I/O and unified provisioning can radically simplify how availability and scale are easily delivered.  And using these concepts, virtual (or physical!) Infrastructure-as-a-Service (IaaS) platforms for cloud computing are simple to create and manage.

The inflection point the industry is going through is one where the management of workloads and infrastructure is changing. The change is away from physical point products, and toward a disruptive approach levering fully abstracted OS, I/O and networks, with unified, integrated services. Just look at the number of  products being replaced by VM management systems. And similarly, Egenera software is replacing the need for dozens of infrastructure management point-products with a unified, simplified approach.

The inflection point Egenera is going through is slightly different, but designed to help accelerate the disruptive changes happening in the industry. When we began the company, there was no hardware to support unified fabric computing, no virtual I/O, and no volume blade servers. But today, there are… so we are re-making the company to take advantage of two important assets: our PAN Manager Software, deployed in over 1,400 locations globally, and the advent of volume blade servers that are becoming pervasive in the data center.

Where we’re headed

One central tenet in Clay Christensen’s The Innovator’s Dilemma is that companies often need to re-invent themselves if they intend to excel in a changing market – even going so far as to introduce seemingly competitive products to their traditional base.  Which is why we’re taking our PAN Manager software and making it available on third-party platforms in addition to our battle-tested BladeFrame platform. This is not meant to imply that we are de-emphasizing BladeFrame in any way; rather, we are offering choice.

In so doing, we’re also changing the format of our company. We’re emphasizing our software. We’re emphasizing working with more hardware partners. Our management changes also reflect this, and our staffing does too… in fact, we’re hiring software engineers and field personnel in many important areas.

And our results so far?  Well, you’ve probably already read about new customers who’ve discovered the value of Egenera software coupled with Dell hardware. And you’ll be hearing shortly about how we’re beating some very large new entrants into the converged data center management space.  You’re also going to be hearing a great deal about the value of unified management in concert with unified computing architectures – radically simplifying how availability, disaster recovery, scale and IaaS are managed.

We’re betting on the fact that unified computing and converged data center management will evolve to perfectly complement the advent of OS virtualization.  And so, we’re organizing today to be the only independent provider of unified computing across multiple platforms, including our own. Our mission continues to be to bring radical simplification to creating highly available, highly agile data centers.  And stay tuned regarding our new products and platforms.

Tags: Add new tag

I had to chuckle a bit when I read a recent claim that Cisco’s UCS was the “first” unified computing system certified on Oracle 10g and 11g RAC.  That’s just plain false.

So stop the presses: To set the record straight, it was actually Egenera (using PAN Manager software) that was first… announcing 9i support back in 2003… even before Oracle had the “Certification/Validation” program in place!  Then we have the Validated 10g RAC solution last year, and the  Validated 11g RAC solution in May of this year. Check out the Egenera/Oracle history and Documentation and white papers.

What, you say? Egenera does Unified Computing?  Yes! And we’ve been doing so since 2001. Although we refer to our PAN (Processing Area Network) software by a different name, “Unified Computing” is characterized by use of stateless blades, abstracted/virtualized I/O, and converged/virtualized networking. In this manner, servers (both physical and virtual) and infrastructure can be instantly re-purposed in the cases of changing demand or equipment failure.

Now, for some perspective

Now, why does all of this matter? In a word, Maturity.

Obviously, being “first” is good for a bit of chest-thumping. But in this business, what matters to customers regarding  being first is (a) that you adhere to solid technology vision, and (b) that you’ve been evolving the product longer than others.

Regarding vision, Egenera has had our technology vision of the Processing Area Network, of stateless virtual I/O and of virtual networking (including load balancing) since 2001.  This was well before even OS virtualization was mainstream.

Regarding product evolution, Egenera’s software is currently in its fifth-generation version, and on two (soon to be more) hardware platforms. It’s all about maturity-of-solution, and of years listening to customer requirements. Some illustrations:

• Simplicity: First-and-foremost, our approach is simpler than anything else we’ve seen on the market. That includes the fact that it’s simple-to-use, and that it obviates the need for nearly a dozen IT operations point-products.
• Functionality: Our system is more than just about converged networking.  It bundles virtual I/O and converged/virtual networking with automated services like High Availability, Disaster Recovery, pre-configured server profiles, multi-tennancy, chargeback facilities and more. Plus it has been scaled to support hundreds of blades across dozens of locations.
• Platform support: Our unified computing approach is based on PAN Manager software, which first operated our  BladeFrame products, and now the same software operates the Dell PAN System
• Endorsement:  Finally,  our approach is in use by hundreds of companies in thousands of worldwide locations.

Net-net: Let our vision and maturity speak for itself.  And if/when others claim a “first”, dig a little deeper to check for the facts.

Everybody’s talking about IT infrastructure/operations simplification, but only a few are taking concrete action to do something about it.

So consider two views of simplification: (1) simplification at the “modular building-block” scale, and (2) simplification at the management/operations scale.

Egenera’s customers have been driving us on both of these issues, hence our announcement of a number of recent wins — across a variety of industries — which endorse our chosen approach. Follows are some concrete areas where we’ve focused our energies:

On simpler modular building blocks:

Working alongside Dell, we recently announced the Dell PAN Datacenter-in-a-Box. While I admit the name may not be as elegant as the product, it takes the most frequent configuration needs, and bundles them all with a mission-critical level of availability.  It’s essentially a standard blade enclosure with standard networking HW and standard SAN storage… complete with embedded virtualization (if you choose to use), fast server provisioning, and N+1 high-availability for any blade running any workload. And it takes < 1 day to install and have up-and-running.

So if you’re installing, say, an ERP system, here’s what you should think: I’ll run my scale-out DBs native, I’ll virtualize app servers and other services (using the VM of your choice), and I’ll wrap the entire environment (Including VLANs, embedded Load Balancing etc etc) with an N+1failover safety-net.  And you only have to buy a single item.

Or, for example, if you’re rolling-out a new VDI environment, you’ll want to run controllers, presentation servers and virtualized O/S instances all within a highly-available environment with local storage and HA. Again, a perfect use for a building-block approach to adding new services to your datacenter.

Elegant idea you say? But isn’t this just the equivalent of throwing a bunch of piece-parts together with a bow? Nope. Read on….

On Simplification of management & operations

So the next challenge is to simplify the more granular aspect of datacenter management - all of those pesky point-products you have to integrate, page between, and keep updated.  The diagram here illustrates what I’m talking about… as many as 13 products are needed if you’re in a reasonably sophisticated org managing both physical and virtual servers in a production environment.

The approach customers tasked Egenera with is to simplify operations and to make architecture more elegant.  So we sought to understand why these 13 products have been traditionally needed, and then how we can re-design providing these in a simplified, holistic, and unified manner.  The solution was our PAN Manager software that allows configuration and deployment of all of these functions in about 6 steps.  That’s essentially 1 product with 1 window to provide these 13 functions.

Don’t believe things could really be this simple?  Just read about our customers, the value they’ve derived, and what they have to say. They’re running production data centers in every industry, worldwide.

Lots of buzz in the air about Cisco entering the server market with the Unified Computing System – using the words “Revolutionary”, “Breakthrough”, etc.   Now, to have Cisco enter the server market is certainly revolutionary… but neither their technology nor their business value is particulary new. But their marketing sure turned-up the volume on it all.

Cisco has sat by the sidelines for a number of years, and watched Egenera in particular — as well as IBM, HP and even a few smaller players – enter the market with ‘converged’ networking and repurposeable servers.  As long as 7 years ago, Egenera was selling our BladeFrame, which is essentially what UCS is.   Stateless x86 servers, converged network backplane. Low component counts, low complexity. Extraordinarily low TCO compared with tradtional servers, I/O and networking.

7 years of maturity in the making

So what does 7 years (and hundreds of customers w/thousands of  installs) get you? Well, a few things. First, on the Hardware side, Egenera knows how to move to standard, lower-cost, volume hardware, demonstrated by teaming with Dell. And, Egenera knows how to make the entire *converged* system work over standard Ethernet – to keep costs, simplicity and risk to minimum.

On the Software side, Egenera has also figured out how to make the “special sauce” (our PAN Manager) run on other hardware too.  That means that all of the experience we have with running BladeFrames now comes as a mature 7th-generation software package.  That’s a lot of development.

So big deal. What does that mean?  Well, if you  look at Cisco’s solution (or HP’s for that matter), you find a very rich set of controls for the converged network, I/O and servers. Yawn.  (Egenera did all that years ago). Cisco then partnered with VMware for virtualization, and BMC for higher-level management like SW provisioning and failover. Good for them.  In the mean time, Egenera’s software had already embedded all of these functions within our “single pane of glass” GUI. That’s complete integration of a VM environment as well as HA and DR/COOP functionality – rather than working across multiple vendor GUIs.

What else you should know about Egenera

With this level of product maturity comes a few more things you should think about:

• Mission-critical production references – Yep, we got ‘em. In just about every market, in just about every geography.
• Refined, simple-to-use operation—the GUI is simple to use – and environments  can be set up in 6 easy steps.
• TCO studies, uptime statistics – Got those too. In fact, we can show you statistics from some of the largest users & hosting companies that show “five 9’s” of availability month-to-month.
• HW and SW certifications – Oh yeah… and by being around for so long, we’ve certified tons of applications and O/Ss on our system, so you don’t have to worry
• Integratability – And finally, we “play nice” in your sandbox. With a full Web Services interface (say you want to build a self-service xSP portal) as well as a monitoring API so you can use us with your favorite accounting/chargeback system.

And finally, let’s talk about Value. A bunch is coming out about Cisco’s Pricing.  Then there’s the analysis.  But either way, you’ll find that from a price/performance perspective, the joint Dell/Egenera solution stacks-up against the Cisco approach.

Ask us and you’ll see.

Well, the June 12th Channel Register report on Cisco UCS prices certainly changes the conclusions of the original Cisco price comparison done in April.

For Blades, assuming the “Legacy” Blade Price used by Cisco in the original comparison is the actual List Price of a “Legacy” Nehalem Blade (Cisco agreed that HP was the “Legacy” system, so for this analysis I use an HP BL 460c G6), I was able to configure a “Legacy” Blade and come up with a list price close to the price in the original Cisco comparison. The configuration is two Intel Nehalem 2.53Ghz processors with 32Gb of “slow” memory and a 73GB SAS 15k Hard Disk.

Then using the prices in the Register article, I configured a Cisco Blade with equivalent configuration. In the comparison of Blade prices, Cisco originally used a price of $5665 per blade compared against the “Legacy” Blade at $5732. BUT, using that configuration with the Register-reported prices, the comparison is $9497 for Cisco and $5732 for the “Legacy” Blade.

Another takeaway from the Register-reported prices is the Cisco Interconnect Extender. The Register quotes $3749 EACH – not for two as quoted by Cisco. These two items – though mainly the Blade prices – changes the results of the 8-Blade comparisons with the Cisco UCS being 48% MORE expensive rather than the reported 13% lower cost.

These items roll into the 320-Blade comparison as well – changing the results for that comparison, which now shows the Cisco UCS solution being 13% MORE expensive rather than the estimated 31% cheaper as quoted in the original comparison. Now, I’ve seen some responses claiming discounts will affect “actual” prices, but that’s not relevant to the point of an “apples to apples” comparison.

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.

Summary

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.

Seems like virtual switches are now the new “it” thing. Cisco announced one that plugs in to VMWare environments. Now comes news from Citrix Syngergy that they are also developing a virtual switch for Xen and KVM. Why all the buzz over virtual switching?

There are 2 good reasons for virtual switches  - one is to make it easy to deploy and migrate virtual servers. The other is to allow network administrators access to managing virtual switches deployed by hypervisors. The former is a technical solution to help virtual machines become more flexible; the latter is a solution to an operational issue, where network administrators want control over every switch that is deployed in the data center.

There is also another benefit of vswitches. It’s easier to roll out new functionality in a virtual switch than it is to change a physical switch, even if it’s just software in either case. Customers are less willing to upgrade their hardware/firmware on their premise networks compared to a virtual switch in a virtual environment. As a result, you may see quicker deployment of features like QoS, enhanced security, and more granular network statistics that not only monitor the physical hardware, but also the virtual networks.

Be careful when looking at these virtual switches, though. A close inspection might reveal some unwanted performance side effects. For example, rather than allow two virtual machines connected on the same vswitch to communicate directly, Cisco’s vswitch forces the packets to flow out of one virtual machine, to a physical switch, and then back to the destination virtual machine. That seems kind of inefficient to me.

Egenera has been providing virtual switching for physical and virtual servers for many years. Because we were the first unified fabric computing system on the market, we had to face these same technology challenges on the way. Virtual switching is a natural evolution allowing server personalities to migrate to different physical hardware while at the same time preserving the network configuration and topology.

The key to virtual switching is that it must fit in with the current operational environment and existing switching environment in your data center. If not, you may be getting more of a headache than a solution.

Back on 16 April, Cisco began its marketing push on its Unified Computing System (UCS) hyping the fundamental cost savings it provides – as much as 31% over traditional approaches for a large scale-out implementation.

But after close scrutiny, Cisco either needs to check their math or adjust their pricing. Their claims about TCO, bandwidth etc. are overstated, creating  erroneous conclusions on bottom-line savings.

Unfortunately, the media probably accepted this analysis without taking a close look. BTW, we’re referring to slides they used during a webinar, available at http://blogs.zdnet.com/BTL/?p=16477.

Setup: Analysis of Cisco’s Slide “Sample Configuration - 8 blades”

Management is shown as $7,000 for 8 Blades. This is either $7,000 per chassis or $875 per blade. An interesting coincidence that HP’s Virtual Center Enterprise Management software has a list price of $7,000 per HP c7000 Bladesystem chassis. Another coincidence – for the 8 Blade configuration, Cisco lists “adaptors” for the blades costing $5,992 – that’s $749 each. The 4Gb/s Fiber Channel SAN mezzanine adaptors for the HP Bladesystem cost $749 each on the HP website. And there’s more – the 10Gb Ethernet switches are listed at $24,398 by Cisco – that’s $12,199 each. The HP FLEX10 Virtual Connect Ethernet switch costs $12,199. OK, last coincidence – Cisco lists Fiber Channel switches at $18,998 = $9,499 each. Yes, HP’s website lists 4Gb/s Virtual Connect Fiber Channel switches for $9,499. So, I think we can conclude the “Legacy System” Cisco is comparing to is an HP cClass Bladesystem. Knowing all of this, we can now analyze the 320 blade configuration to reconcile the costs.

Analysis of Cisco’s Slide “Sample Configuration - 320 blades”

On this slide, management Software is listed at $554,400. Since we know this is an HP c7000 Blade System which holds 16 Blades, there are 20 chassis – each with 16 Blades. The calculations work out correctly - $8,713 from the 8 Blade configuration times 20 = $174,260.  If Management software is a chassis-based price ( $7,000 from above) - with 20 chassis this total should be $140,000 – however Cisco shows $554,400 – a $414,000 mistake. Cisco’s $554,000 comes out to $27,700 per Blade chassis, or $1,732 per Blade. No that’s a pretty big mistake.

Bottom-Line: So, if we adjust for this mistake, the difference between Cisco’s UCS total and the “Legacy” total (for 320 blades) is really only 14% - not 31%.

Cisco’s error comparing “apples-to-apples”:

Also, the Cisco configuration for 320 blades includes 40 Extenders. We know this because if you divide the 8 Blade “Extender” cost into the 320 Blade configuration extender cost – it equals 40. We also know that each Cisco Blade chassis holds 8 blades, so 40 chassis’ are needed to support 320 blades. SO, there is ONE Extender in each Cisco Blade chassis in this cost comparison. That’s ONE extender for each of the 40 blade chassis. That means that the extender is a single point of failure for each blade chassis in this configuration. In contrast, the (HP) “legacy system” is priced with full redundancy.

Bottom-Line: Cisco is not providing a fair comparison. Advantage HP.

A bit of hype regarding network bandwidth:

The 40 Fabric Extenders mentioned above means there is a maximum throughput of 40Gb/s for each chassis with 8 Blades.  The Extenders have only four 10Gb/s FCoE ports for attachment to the fabric switch. So, that amortizes to 5Gb/s for each Blade – “IF” the ports on the Cisco Blades can be teamed or configured as Active/Active – if not, then this is a fabric throughput of 2.5Gb/s per Cisco Blade. So, this Cisco UCS configuration is not a 10Gb/s fabric – it is either 2.5Gb/s or 5Gb/s fabric best case. We can answer this question too. There is another factor at play. EACH Fabric Interconnect (aka Nuovo Switch) supports 40 Fabric connections to the Cisco Blade chassis. In order to support 320 Blades, each Cisco Blade chassis can only have ONE 10Gb/s connection to EACH of the redundant Cisco 61000 Fabric Interconnect switches. So, this results in EACH Cisco Blade chassis having a maximum of TWO(redundant) 10Gb/s fabric connections shared by 8 Blades. So this calculates to 20Gb/s for 8 Blades – or 2.5Gb/s per Blade. This, this tells us that the Cisco 320 Blade solution has a 2.5Gb/s fabric capacity. Now, for the “Legacy” (HP), recall the blades have redundant (2x) 10Gb/s Ethernet ports and redundant (2) 4Gb/s Fiber Channel Ports. The redundant (2) 10Gb/s Ethernet Switches in the “Legacy” system have a total of 16×10Gb/s uplink ports – so there is enough fabric and switch bandwidth for a true 10Gb/s Ethernet throughput for each Blade. The redundant (2) Fiberchannel Switches have 8x 4Gb/s fiber channel ports. Which is an additional 0.5Gb/s of Fiber channel through put per Blade in the Legacy system.

Bottom line: This is an unfair cost comparison of a 10Gb/s “Legacy” (HP) system to a 2.5Gb/s Cisco UCS system.

High bandwidth limited to low blade count

Cisco’s 320-Blade configuration shows us that the “Fabric Interconnect” to support it actually costs $138,182. Cisco recommends two Fabric Interconnect units for the Cisco 5020 products, assuming this is the same case here. So, each of these Cisco 6100 Fabric Interconnect units costs $69,091.  These are the 40-Port switches which are needed to support the 320-Blade configuration. If a customer wants a full 10Gb/s fabric, each Blade Chassis will need two Fabric Extenders ($3,998 each) AND must use all 8×10Gb/s uplinks on the Fabric extenders. This also means the 40 Port Fabric Interconnect switch will only support –Five– blade chassis’ – not 40. So achieving a 10Gb/s fabric version of the Cisco UCS is limited to 40 Blades maximum.

Bottom line: If a customer is interested in full bandwidth 10Gb/s connections to each of the Blades, the entry cost is $138,182 for the networking only, and only for 40 slots. That’s $3,304 per Blade slot for infrastructure. And then the blades themselves are additional costs!

Gartner’s recent article Oracle RAC Moved to Mainstream Use made me think about how important Oracle’s work has been around RAC — but also how its progress could have been even faster if not for stubborn complexity of the underlying physical infrastructure.

Let me explain with an example. Oracle Grid, aka Oracle RAC, allows database administrators to string multiple (I have heard up to 50) x86 white boxes or blades together to create one large Oracle Engine for mission-critical databases. If you lose one blade, the engine is still running while you replace it. If you run out of capacity in the engine, just add another blade and scale or shrink accordingly.

But physical infrastructure complexity hurts the stability, scalability and flexibility of larger RAC environments. For example, to set up a 50 node RAC, an IT organization must string an estimated 200 to 300 Network and SAN cables together…the very definition of hairball! I believe RAC adoption for databases has been slowed because of this remaining complexity.

As you can see, the server platform holding the RAC node really DOES matter. Eliminate the “hairball” and you can get on with achieving GRID for even the largest installations.

Ok. . .so there’s the catch. Most hardware vendors that offer commodity boxes or blades don’t solve the physical complexity problem. Some of the larger SMP machine vendors have solved this, but large SMP machines don’t make sense for RAC. It doesn’t make sense to set up an 8-node RAC with 8 Superdomes. Imagine needing to add a ninth node: ”Boss, I need to buy another superdome . . .can you help?”

Now there are a handful of vendors (shameless plug for the Egenera-Dell partnership) that have solutions to counter the physical complexity problem by consolidating IO and leveraging SAN and NAS infrastructure to the fullest. We use blades as do HP and IBM. But, Egenera and Dell PAN System blades are very different.

For starters, they’re stateless with most of the physical complexity associated with standard blades replaced by IO and network virtualization software. Stateless blades can be virtually strung together and added to the cluster at the click of a button. Stateless blades means that instead of 300 cables for a 50 node RAC, you end up with 50 cables, a much more manageable issue.

After removing the physical complexity of an Oracle Grid by replacing the physical mess with software, our clients have successfully set up double-digit RAC Node environments and maximized their return on investment.

Do you agree? Weigh-in with your thoughts.

Check out the post fellow blogger and colleague Ken Oestreich wrote recently. It’s a great description of the Processing Area Network. Sometimes a picture/video is better than text and Ken does a great job illustrating the architecture and value of PAN.

Given all the buzz around Cisco UCS, Ken’s blog is timely and informative. Way to go Ken!