HP Blades Tech Day 1 is now over and what a whirlwind of a day it was.  Here’s a summary of the day’s activities:

• Overview of ISB (Infrastructure Software and Blades) from Gary Thome
• Partner Presentation from Mark Gonzalez
• Overview of Virtual Connect from Mike Kendall
• BladeSystem lab (hands on overview of the hardware) from Gary Thome
• BladeSystem Matrix & Insight Software demo from John Schmitz & Bryan Jacquot
• Competitive discussion (hardware) with Gary Thome
• Face-to-face discussion on strategy with Paul Perez (CTO for StorageWorks)

I can honestly say that there wasn’t a bad presentation all day.  We were given access to some senior technical people (for instance Gary is Chief Architect for ISB) and that showed – as we were all able to ask probing questions and get immediate answers.  For me, a number of things stood out for further investigation.

• The blade chassis themselves have a huge amount of engineering in them.  I’ve taken a lot of video of the lab presentation which talks about the power supplies, fans, physical layout and so on.  It will take time for me to review and digest but expect some posts on the engineering that has gone into the blade products.
• Power Management – this subject deserves a post in its own right as there’s some clever thinking here.
• Virtual Connect – virtualisation of the I/O infrastructure in any blade system is a key requirement and VC had some interesting features.  I’ll be looking to compare VC to other solutions in the marketplace.
• Software and Storage – I don’t think storage has been fully exploited in the current solutions.  Rather it is seen as a static configuration achieved separately and doesn’t form part of the workflow in the dynamic deployment of infrastructure.  Look out for a post discussing this whole issue.
• Futures.  Although Paul Perez didn’t explicitly provide futures information, he hinted at the direction HP may take for the storage products.  Expect to see a post on memristors and the future direction of hard drives.

In summary, day 1 was a great introduction (for me at least) to HP blade technology.  HP were open and willing to discuss their technology and I can say I learned a lot, with  plenty of research required.  Now onto day 2….

Disclosure: HP have funded my flight and accommodation for this trip. Everything else is self funded. I am under no obligation to write about what I see during the Tech Day and HP have no editorial rights over the content I produce.

© Chris for Gestalt IT, 2010. | HP Blades Tech Day 1
Read more posts categorized as Networking, Server Virtualization

HP recently commissioned Tolly Group to benchmark their BladeSystem c7000 against the Cisco UCS 5100. The short report focuses on two results, and reads like so many competitive benchmarks in the IT industry: Tolly focuses on metrics that highlight the strength of HP’s solution and the weaknesses of Cisco’s. I do not dispute the accuracy of these results, and HP and Tolly are doing exactly what tech companies do. But what’s the real value of pinpoint maximum-performance benchmarks like this?

0-100-0

Automotive media like Car and Driver and Top Gear frequently test the maximum performance of cars, racing to 100 mph or beyond, sliding around a skidpad, and slamming on the brakes. These tests can be enlightening when it comes to high-performance cars, and the punishing 0-100-0 test is especially impressive. But what’s the point of hammering an economy car or pickup truck like this? Maximal acceleration and cornering are entirely irrelevant to buyers of commuter cars and work vehicles.

Even though a given test can be conducted, it may not be enlightening. The Tolly report demonstrates two key findings:

1. Although 4-blade configurations perform the same under maximum stress, Cisco UCS performance declines with 6 blades while HP’s remains steady.
2. When using a shared blade uplink, Cisco UCS performance fell by half.

These are not startling results. Cisco blades sometimes need to share one I/O channel, and this can’t match the performance of an HP blade with dedicated I/O. Would it shock you to learn that a one-gallon bucket requires twice as many trips to the well as one that holds two gallons? Does it shock anyone to learn that a V6-powered Toyota RAV4 accelerates quicker than a four cylinder Honda CR-V? HP’s c7000 is bigger than Cisco’s UCS and offers more I/O channels, so HP beats Cisco whenever larger configurations with more I/O are tested.

Innocent Benchmarks

Greta examines the marks on an 18th century cooper’s bench

I’ll leave the deeper commentary on blade performance to experts like Kevin Houston and Martin Macleod, but these maximum-utilization benchmarks are only half the story. I’m much more interested in how the different approaches to I/O impact everyday (20%-40% load) performance and how oversubscription impacts performance as more blades are installed and workloads are moved around. In automotive terms, I’d like to know how well a car handles in the snow or how economical it is with three or four passengers. These real-world scenarios are much more telling than a test of a few blades under 100% load!

Clearly, HP wanted to call attention to specific shortcomings of a competitor’s product, and it was wise to do so with objective numbers instead of mudslinging and name-calling. I hope that future tests and releases include real-world workloads and logical configurations, not the extreme situation used in this report. The same lesson applies to all tech companies: Simple, objective tests of maximum performance are welcome, but customers need many more metrics!

Note: Along with 9 other independent bloggers, I attended HP’s Blades Tech Day in Houston on February 25 and 26. Most of my travel and living expenses were paid for by HP, and the company provided a small gift bag (pictured here).

© Stephen for Gestalt IT, 2010. | Innocence, Fairness, and Technology Benchmarks
Read more posts categorized as Networking, Server Virtualization

An post as Silicon Angle claims that an internal memo is suggesting that Cisco is dumping HP as a partner. Bang Bang: Cisco Dumps HP As Certified Partner HP Returns Fire With Deal with Qlogic

We have no confirmation from Cisco, it could just be rumour but it sure sounds like it could be true and it makes sense. After all, HP and Cisco have been trading blows for the last two years and progressively escalating the war. Once the Acadia / VCE project was announced, it was clear where Cisco is planning to go.

It’s my opinion that HP started the fight about three or four years ago when they restarted their Procurve networking products.

ProCurve – why did HP start ProCurve ?

HP set out to make low cost Ethernet switches that directly connected to a core Cisco network. They even convinced Cisco to license their CDP technology which reassured the network engineers that somehow Cisco approved of this new equipment.

More recently the ProCurve product grew to include chassis based switches that had some serious routing capability. At that point, it was clear that HP means to take on Cisco. Cisco regards those core ethernet switches as their own market and no one else should be in that space.

HP bought 3Com

While HP only had switches, Cisco resellers could always position their “portfolio”. That is, not only does Cisco have switches, but routers, security appliances, management software, WAN equipment and the whole show.

But after HP integrates 3Com, they have the whole portfolio too. In fact, not a very good one since 3Com equipment is not exactly recognised as quality. Most importantly, the people who design networks and layout strategy remember being completely shafted by 3Com in the early 2000’s and they haven’t forgotten.

So, now HP has a complete portfolio. It needs money and time to build this portfolio into a quality product offering (because the current product isn’t ready for the big time e.g. here). The HP ProCurve has a solid reputation for cheap and cheerful (and NOT enterprise grade).

So Cisco did some servers

As part of the FCoE push, Cisco released a bunch of Intel servers. Ultimately, the actual servers are a me-too product with some cute finishing touches. That is, if you glue Intel chips to a motherboard, you don’t get a lot of profit margin, Intel does. And this isn’t a strategy that Cisco has done before.

Several people/pundits have queried whether Cisco has been forced into servers. I maintain that Cisco had to respond to HP entering the network space. They have added some Cisco sauce by applying a network technology to their platform disguised as FCoE. This means they have a good marketing strategy, a differentiator for the customer.

it’s possible that this was the intent all along. Ditch HP before their network strategy is mature and enter the server space with a strong offering. They’ve got EMC for storage, and partnerships with all the majors such as Intel, VMware, Microsoft etc.

What Level?

The one partnership that matters between Cisco and HP is the “Gold Partner Status”. This entitles HP to preferential purchase price, deep technical support integration and many other benefits. If Cisco removes this partnership, then HP can no longer compete in the open market on price (unless they make a loss) or technical support.

But there are other partnership programs that have various names. Global partners, Corporate Partners, Strategy partners or whatever. They change quite often and they don’t have much impact at customer level. If Cisco is removing HP from one these programs, we won’t see much of a change.

Dell dumped too ?

Network World has reported that Cisco is planning to kill it’s partnership with Dell. Combine this with the HP termination and we might have a trend. John Chambers has been known to make big bets in the past, and this might be something they need to do.

Losing share in the telecomms area

Cisco has also been losing marketshare in the Telecomm / Service Provider space. This is where the really big money is, with millions spent on just a few projects. Juniper and Huawei are taking big chunks out of Cisco’s customer base. Does this leave Cisco with a revenue hole in a couple of years ?

“Forward Planning”

So, if it’s true, the Cisco is planning to move up the stack and sell Intel servers. Further, they mean to take HP head on in the existing customer base. It’s an aggressive move but a perfect time to do it.

First, HP ProCurve networking needs a couple of years to mature and stabilise. Second, HP Management is busy digesting their acquisition of EDS (which is having problems due to low profit margins in the EDS business) and may not be able to cope with a head on fight. Third, HP people are disorganised due to the number of re-organisations, cutbacks, and acquisitions.

As a customer, I’m delighted. I’m expecting to see price cuts and improved service. Cisco has been light on new features for the last couple of years and steadily increasing prices. HP has become fat and comfortable with it’s incumbent status.

Bring it on.

© Etherealmind for Gestalt IT, 2010. | What might it mean if Cisco Dumps HP As Certified Partner ?
Read more posts categorized as Featured, Networking

It has been nearly a year since Cisco shook up the IT infrastructure world with their unified computing system (UCS) server line. Predictably, although the introduction set the world buzzing, customer uptake has been somewhat slower. Although evaluations are reported to be widespread, production use has lagged. The high-end corporate environments that use devices like these simply don’t turn on a dime. Regardless, UCS is an important infrastructure element and deserves the continuing attention it has received.

Cisco recently reached out to a number of us in the IT infrastructure space, asking for our opinion on UCS as it stands today. Gestalt IT author, Greg Ferro, posted a number of keen thoughts over at his Ethereal Mind blog, and we (Bas Raayman and Stephen Foskett) put our heads together to come up with some additional thoughts. Although clearly directed at Cisco, we look forward to responses from other parties as well!

1. How successful has UCS been in production deployment? What were the expectations of early adopters and have these been met? What do Gestalt IT readers think?
2. What feedback has Cisco received from customers from customers regarding Fibre Channel over Ethernet (FCoE)? What do our readers think of FCoE at this point?
3. Many customers do not require a fully built-up stack, and instead need only a few blades. Are these smaller customers responding to UCS or is the product’s target market exclusively at the high end?
4. Will Cisco introduce a UCS model with multiple blade chassis?
5. What is the added value to a customer comparing a full width UCS blade to a regular 1U server?
6. What is the strategy if a customer needs extra I/O for an individual server within the UCS stack? Are any I/O extensions or upgrades planned?
7. Scalability is one of the key issues. What is the target scale for UCS and what is the biggest UCS deployment currently in use?

The VCE data center partnership resulted in taking the UCS computing system as a basis and integrated a storage unit and VMware to the solution stack. This is a solution that is sold as a “plug and play” virtualization building block and helped to establish UCS as a strategic platform. The Ionix part of the vBlock solution has “overall management” written over it, directed to allow management of all components from a central interface. More questions come to mind regarding VCE and UCS:

1. Are there any plans to provide the option to upgrade to a vBlock solution from a purchased UCS stack? If I currently have a UCS setup, can I add the missing components and have my setup validated so that I can add a storage array and the Ionix management to create my own vBlock?
2. I am putting “all of my eggs in one basket” by solely implementing the UCS solution. Of course I need to plan growth, but what happens if Cisco encounters issues in delivering new hardware? Small and medium enterprise sized companies usually need to have multiple suppliers to avoid such problems, but how does Cisco handle this?
3. How well do the UCS components work with other hardware beyond VCE, and is Cisco also offering a unified management solution for a heterogeneous environment? If not, what interfaces are they offering to implement central management?

We look forward to the response from Cisco and our readers!

© Gestalt for Gestalt IT, 2010. | One Year Later: Questioning Cisco UCS
Read more posts categorized as Exclusive, Featured, Networking, Server Virtualization, Storage, Top Story

There is a commonly held fallacy that FCoE provides a smooth migration path from your existing infrastructure to the new system. Its true that if you look narrowly enough at your infrastructure, then parts of your network don’t need upgrading. For example, your legacy FibreChannel switches, server cards and storage arrays don’t need replacing. The “Storage Stuff” gets to stay in place and ’seamlessly interconnect’ with the new technology.

In the bigger picture, however, the impact of DCB on the Data Networking means that your entire Data Networking infrastructure needs to be overhauled and probably forklifted. And that’s exactly what Cisco wants you to do.

Although it’s possible to implement “patches of green” using the VCE model where a cluster of compute power is brownfield developed in your existing data centre, you are not going to realise the benefits of a DCB infrastructure without having an entire network that has the hardware that is capable of doing so. You need to deliver end-to-end service guarantees in the Data Centre and a network that doesn’t support the QoS and performance guarantees on every device, isn’t going to work.

In a very real way, the technology emphasis is going to shift away from the server / storage and into the network layer for the coming year or two.

The Storage/SCSI/FC over Ethernet is a great use case that is being used by the Networking industry to drive the first phase of migration to DCB and spark a massive round of investment into networking infrastructure. Cisco is heavily marketing DCB to encourage a new round of spending on the data network that is long overdue and Brocade is being forced to follow along behind it (and looks a lot like an also-ran in the process).

Time to look up, not down

It’s time for Storage Professional to stop looking at where you are placing your feet and look at the road ahead. The future of Storage Networking is not FibreChannel all the time but some other technology yet to arrive. FCoE is THE transition technology that heralds the fact that the Storage is now a maturing business and ready to actively integrate in the IT Team and not continue to be a silo in the corner with it’s own special needs.

But for the next couple of years, it looks like the network is going to take a lot of funding away from Storage as the upgrades begin.

© Etherealmind for Gestalt IT, 2010. | FCoE IS about Rip’N'Replace (Just not your Storage)
Read more posts categorized as All, Networking

The Problems with 10GB Ethernet

Power

If you are using copper patch leads for 10GbE, you are going to a need a lot of power. Using standard copper can use up to 45W per port (although 10GBaseCX-4 apparently uses 4.5W per port).

The IEEE is working on Energy Efficient Ethernet (802.3az) technology that will allow links to auto-negotiate down to lower speeds or go to “sleep’ during periods of inactivity which will further reduce power consumption.

Cabling

10GBaseT copper uses 650Mhz frequency spectrum and needs high quality cabling to work reliably. This means that you need to test, properly, your existing Cat5 or replace it with Cat6A or better. If you use Cat6A or even Cat6, the cable is physically much larger (and you may not have the space in your computer room). In this case, you will have up to 100 metre cable length. If you use Cat5 or Cat5e, the distance is much shorter depending on the quality of your cable, typically less than 40 metres and would probably need testing for assured reliability.

10GBaseSR uses multimode cabling but has different cable lengths depending on type of cabling and certain combinations will require mode conditioning patch leads.

The current list of 10GB XENPAK / X2 interfaces from Cisco show the confusion that the different types of cabling causes. For example consider the following table showing the LAN options (I’ve removed the WAN units) and the variation in cabling types:

The impact of cabling

In a recent project to plan a refit of an existing data centre, the 10GbE cabling needs was a major problem. Because of constraints in the change control and risk management, we eventually decided to use 1Gb ethernet because the time needed to get long change windows exceeded the length of the project.

And in other projects, the cost of recabling the fibre optic to meet the new requirement for 10GbE was prohibitive for smaller works. That is, we couldn’t just add a “patch of green” to an existing facility and extend the new switch as funds became available.

Which is weird, because it reminds me of the Token Ring / FDDI / Ethernet wars back in 1995 or so.

High Cost

If you take the time build budgetary pricing around a Cisco Nexus 7000 you will quickly realise that the cost of 10GbE capable switch is really expensive. I found that a typically configured Nexus 7018 with a good number of 10GbE and some 1GbE was around GBP£500K / USD$800K. Admittedly, this was a fully loaded model but forms the basis for a cost analysis against our existing Cat6500 choices. Frankly, I couldn’t convince anyone that this was a good idea.

Sure, the Nexus 7000 is good product (not a great product in my opinion) and offers some 10GbE capability but the lack of features and high cost means that 10GbE is still not a part of our short term strategy. I wonder how many other people have a similar problem ?

Which Year was that ?

It seems that every year is the year of 10 Gigabit Ethernet.

2009

In March 2009 The Register posted an article
Intel dubs 2009 ‘The Year of 10Gb Ethernet’.

2008

Silvano Gai, in his book Data Center Networks and Fibre Channel over Ethernet, Section 1.5.2 claimed “2008 is the year of 10GE”.

2004

Amd as far back as 2004, people have been claiming that “this is the year ….”

The market for 10-Gigabit Ethernet might start to show some signs of life in 2004. An economy gone cold, combined with its comparatively high price tag, kept down shipments of 10-GigE ports to a few thousand last year. But vendors predict that the 10-Gbps version of Ethernet will continue along a familiar trajectory. “This will be the year of 10-Gigabit Ethernet,” declared Richard Brand, director of network architecture for Nortel’s advanced technology group

Highbeam – Note this is behind a registration wall

And this article on CNET (really) 10-Gigabit Ethernet comes alive

The market for 10-gigabit-per-second Ethernet switching got off to a slow start, but now that corporate customers are looking for more speed on their networks, the technology seems to be hitting its stride.

And the fact ?

10GbE hasn’t really happened has it ? The standards took a long time to finish, and the prices have been very high for both the cabling and switching equipment. Server manufacturers aren’t putting the chips on their motherboards because of high power consumption. But most importantly, almost no-one need the bandwidth except for certain niche applications.

My Prediction

There is no question that 10Gigabit Ethernet is going to happen. Eventually. But there isn’t enough money or momentum to make 2010 a watershed year. There still isn’t enough demand for bandwidth in most parts of the networks to require the upgrade and CIO’s are investing in Virtualisation this year, not Networking.

That said, areas that require long investment cycles may buy 10Gb Ethernet for preemption against future upgrades (and thus downtime) will drive a surge in 10GbE purchases this year. For example, upgrades to data centres and storage networks (for those using iSCSI and FCoE) may purchase 10GbE switches and routers to build high performance backbones but continue to connect servers and edge switches at 1GbE. These are high visibility, high value purchases that will create a lot of marketing noise and management attention. The reality, however, is that 10GbE will be adopted small scale, and will not be used in the distribution switches, or the wiring closet, or the WAN. ((Note that it’s different for Service Providers whom I expect will have a lot more interest in 10GbE for their WAN backbones and may actually make investments in their backbones soon.))

I’m expecting 10GbE to get slow, progressive adoption over the next three years. It’s not an industry revolution, and not enough people need to increase bandwidth to drive rapid. The only use for 10GbE in the Enterprise is for Data Centres where Storage and Virtualization/Blade Servers are driving adoption.

No one else cares.

© Etherealmind for Gestalt IT, 2010. | Is this the year of 10 Gigabit Ethernet in the LAN?
Read more posts categorized as Featured, Networking

Infiniband is something of a forgotten protocol these days but many of the marketing features of FCoE are directly derived from Infiniband concepts and architecture.

Paradigms of Data Center Virtualization

For example, this page is taken from the “Paradigms of Data Center Virtualization” by Cisco at Networkers 2005. If you are following Cisco UCS then it should be very familiar, perhaps surprising the the Unified Fabric idea is not new but either Infiniband or 10GB was going to be the networking fabric.

If you are reasonably new to Data Centres then you may not remember that Cisco has a moderately successful Infiniband product, and in 2005, it was the centrepiece of Cisco’s marketing strategy for a Unified Fabric for connectivity in the Data Centre. As an aggregator of connections from the server down to an Infiniband backbone it was the Unified Fabric that was going to unite the Data Centre for Grid Computing (the precursor of what is now virtualization).

Unified Fabric Server Clusters

And you can see a Case Study of this using a pure Infiniband backbone for a large scale server cluster in this slide (from the same presentation)

So what changed ?

So why didn’t Cisco continue with Infiniband ? I think it’s worth looking back and thinking how we got FCoE instead and looking for lessons to be learned. I can only speculate on what happened.

Recap on Key Infiniband Features

1. InfiniBand is a high speed, low latency technology used to interconnect servers, storage and networks within the datacenter
2. Standards Based – InfiniBand Trade Association http://www.infinibandta.org and has been working successfully for more than ten years.
3. Scalable Interconnect speeds in multiple of 2.5Gb/s, products are currently shipping at 40Gb/s and 120Gb/s products have been announced.
4. Low latency networking with delays around 20 microseconds (end-to-end) is one thousand times less than 20 milliseconds for a data centre ethernet network.

I also find it interesting that the silicon from QLogic and Mellanox has rapidly been repurposed for FCoE HBA’s. There must be strong similarities is these products for this to happen.

Ethernet is easy to sell

People will buy and use what they know. In that sense, faster ethernet or ‘newer’ ethernet is an easier decision. I assume that offering customers an easy choice, what they perceive as a simple upgrade path, is a much easier sale, than one that needs to teach customers new technologies. People tend to laziness, and this is a probable cause.

Cheap always wins

Ethernet is cheap and not very good at a lot of things but, there is a lot of it about and plenty of existing technology. And don’t forget skills, lots of people understand Ethernet and that has a price tag.

And history shows that cheap always wins.

Maybe Cisco wasn’t dominant

Cisco has a policy of being number one or two in any market. If they can’t do that, they will walk away or do something to kill that market. For example, in the early days of IPSec VPN, Cisco didn’t have a good story. They bought two or three companies before converging the code in the Cisco PIX (and later the ASA). They grew to number one by charging no license fee for their solution thus blocking all their competitors from making a profit. They same system appears to be happening today with SSL VPN which is now a small license fee for most customers.

If Cisco couldn’t dominate the Infiniband market, then perhaps Cisco spun out the Nuova Systems (the company that built FCoE and the Nexus family silicon as a startup) to give it a shot at collapsing that market.

FCoE cheaper but not better ?

If you spend some time with Infiniband, you realise that FCoE isn’t specifically a world beating technology innovation. FCoE is the VHS to Infiniband Betamax. And you can see that many of the ideas the FCoE Unified Fabric promotes are the same as those promoted in the past. In that sense, FCoE isn’t new, just a rehash of old ideas mashed onto existing technologies.

Now, I’m sure that FCoE and Cisco UCS strategy is working just fine for customers and it’s going to do well in the market. Given that Cisco has spent anything up to US$1billion buying, manufacturing and marketing the product, it’s a guaranteed success. But its worth looking back on older technologies with regret and cynically viewing these new developments to determine if they are really the best solutions for our networks.

So far, I’m not so sure. We could have had better, but FCoE will probably work just fine for a while until we need to scale and get faster than Ethernet can ever go. Maybe Ethernet will work for us in the future but Infiniband will still be there waiting for us to reuse it. Just like all the other technologies that we keep reusing.

© Etherealmind for Gestalt IT, 2009. | FCoE isn’t a replacement for Infiniband, it’s a cheaper copy that customers will buy
Read more posts categorized as All, Networking

Two technologies that seem to have come to the fore recently are NPIV (N_Port ID Virtualization) and NPV (N_Port Virtualization). Judging just by the names, you might think that these two technologies are the same thing. While they are related in some aspects and can be used in a complementary way, they are quite different. What I’d like to do in this post is help explain these two technologies, how they are different, and how they can be used. I hope to follow up in future posts with some hands-on examples of configuring these technologies on various types of equipment.

First, though, I need to cover some basics. This is unnecessary for those of you that are Fibre Channel experts, but for the rest of the world it might be useful:

• N_Port: An N_Port is an end node port on the Fibre Channel fabric. This could be an HBA (Host Bus Adapter) in a server or a target port on a storage array.
• F_Port: An F_Port is a port on a Fibre Channel switch that is connected to an N_Port. So, the port into which a server’s HBA or a storage array’s target port is connected is an F_Port.
• E_Port: An E_Port is a port on a Fibre Channel switch that is connected to another Fibre Channel switch. The connection between two E_Ports forms an Inter-Switch Link (ISL).

There are other types of ports as well—NL_Port, FL_Port, G_Port, TE_Port—but for the purposes of this discussion these three will get us started. With these definitions in mind, I’ll start by discussing N_Port ID Virtualization (NPIV).

N_Port ID Virtualization (NPIV)

Normally, an N_Port would have a single N_Port_ID associated with it; this N_Port_ID is a 24-bit address assigned by the Fibre Channel switch during the FLOGI process. The N_Port_ID is not the same as the World Wide Port Name (WWPN), although there is typically a one-to-one relationship between WWPN and N_Port_ID. Thus, for any given physical N_Port, there would be exactly one WWPN and one N_Port_ID associated with it.

What NPIV does is allow a single physical N_Port to have multiple WWPNs, and therefore multiple N_Port_IDs, associated with it. After the normal FLOGI process, an NPIV-enabled physical N_Port can subsequently issue additional commands to register more WWPNs and receive more N_Port_IDs (one for each WWPN). The Fibre Channel switch must also support NPIV, as the F_Port on the other end of the link would “see” multiple WWPNs and multiple N_Port_IDs coming from the host and must know how to handle this behavior.

Once all the applicable WWPNs have been registered, each of these WWPNs can be used for SAN zoning or LUN presentation. There is no distinction between the physical WWPN and the virtual WWPNs; they all behave in exactly the same fashion and you can use them in exactly the same ways.

So why might this functionality be useful? Consider a virtualized environment, where you would like to be able to present a LUN via Fibre Channel to a specific virtual machine only:

• Without NPIV, it’s not possible because the N_Port on the physical host would have only a single WWPN (and N_Port_ID). Any LUNs would have to be zoned and presented to this single WWPN. Because all VMs would be sharing the same WWPN on the one single physical N_Port, any LUNs zoned to this WWPN would be visible to all VMs on that host because all VMs are using the same physical N_Port, same WWPN, and same N_Port_ID.
• With NPIV, the physical N_Port can register additional WWPNs (and N_Port_IDs). Each VM can have its own WWPN. When you build SAN zones and present LUNs using the VM-specific WWPN, then the LUNs will only be visible to that VM and not to any other VMs.

Virtualization is not the only use case for NPIV, although it is certainly one of the easiest to understand.

<aside>As an aside, it’s interesting to me that VMotion works and is supported with NPIV as long as the RDMs and all associated VMDKs are in the same datastore. Looking at how the physical N_Port has the additional WWPNs and N_Port_IDs associated with it, you’d think that VMotion wouldn’t work. I wonder: does the HBA on the destination ESX/ESXi host have to “re-register” the WWPNs and N_Port_IDs on that physical N_Port as part of the VMotion process?</aside>

Now that I’ve discussed NPIV, I’d like to turn the discussion to N_Port Virtualization (NPV).

N_Port Virtualization

While NPIV is primarily a host-based solution, NPV is primarily a switch-based technology. It is designed to reduce switch management and overhead in larger SAN deployments. Consider that every Fibre Channel switch in a fabric needs a different domain ID, and that the total number of domain IDs in a fabric is limited. In some cases, this limit can be fairly low depending upon the devices attached to the fabric. The problem, though, is that you often need to add Fibre Channel switches in order to scale the size of your fabric. There is therefore an inherent conflict between trying to reduce the overall number of switches in order to keep the domain ID count low while also needing to add switches in order to have a sufficiently high port count. NPV is intended to help address this problem.

NPV introduces a new type of Fibre Channel port, the NP_Port. The NP_Port connects to an F_Port and acts as a proxy for other N_Ports on the NPV-enabled switch. Essentially, the NP_Port “looks” like an NPIV-enabled host to the F_Port on the other end. An NPV-enabled switch will register additional WWPNs (and receive additional N_Port_IDs) via NPIV on behalf of the N_Ports connected to it. The physical N_Ports don’t have any knowledge this is occurring and don’t need any support for it; it’s all handled by the NPV-enabled switch.

Obviously, this means that the upstream Fibre Channel switch must support NPIV, since the NP_Port “looks” and “acts” like an NPIV-enabled host to the upstream F_Port. Additionally, because the NPV-enabled switch now looks like an end host, it no longer needs a domain ID to participate in the Fibre Channel fabric. Using NPV, you can add switches and ports to your fabric without adding domain IDs.

So why is this functionality useful? There is the immediate benefit of being able to scale your Fibre Channel fabric without having to add domain IDs, yes, but in what sorts of environments might this be particularly useful? Consider a blade server environment, like an HP c7000 chassis, where there are Fibre Channel switches in the back of the chassis. By using NPV on these switches, you can add them to your fabric without having to assign a domain ID to each and every one of them.

Here’s another example. Consider an environment where you are mixing different types of Fibre Channel switches and are concerned about interoperability. As long as there is NPIV support, you can enable NPV on one set of switches. The NPV-enabled switches will then act like NPIV-enabled hosts, and you won’t have to worry about connecting E_Ports and creating ISLs between different brands of Fibre Channel switches.

I hope you’ve found this explanation of NPIV and NPV helpful and accurate. In the future, I hope to follow up with some additional posts—including diagrams—that show how these can be used in action. Until then, feel free to post any questions, thoughts, or corrections in the comments below. Your feedback is always welcome!

Disclosure: Some industry contacts at Cisco Systems provided me with information regarding NPV and its operation and behavior, but this post is neither sponsored nor endorsed by anyone.

© Scott for Gestalt IT, 2009. | Understanding NPIV and NPV
Read more posts categorized as Networking, Server Virtualization, Storage

I’ve been doing a pretty fair amount of work recently with the Cisco Nexus 5000 series of switches, as evidenced by the flurry of Nexus-related articles:

• Connecting Nexus 5000 to Older Gigabit Ethernet Switches
• Setting Up FCoE on a Nexus 5000
• FCoE and VLAN Trunking on Nexus 5000

One thing I hadn’t yet documented was how to enable jumbo frames on a Nexus 5000. Since jumbo frames are now officially supported for VMkernel traffic with VMware vSphere, the combination of jumbo frames and 10Gb Ethernet is an attractive one. I’ve covered the ESX/ESXi side (ordinary vSwitches here and distributed vSwitches here), but here’s the Nexus side.

The commands are pretty straightforward, and I’ve included the commands for both NX-OS 4.0 and NX-OS 4.1 (they are different between versions). Important note: if you enabled jumbo frames under NX-OS 4.0 and then upgraded the switch to version 4.1, you’ll need to re-do your jumbo frame configuration.

For NX-OS 4.1, the commands to enable jumbo frames are:

switch(config)# policy-map type network-qos jumbo
switch(config-pmap-nq)# class type network-qos class-default
switch(config-pmap-c-nq)# mtu 9216
switch(config-pmap-c-nq)# exit
switch(config-pmap-nq)# exit
switch(config)# system qos
switch(config-sys-qos)# service-policy type network-qos jumbo

Now, contrast the commands above with the following commands, which you would have used to enable jumbo frames on NX-OS 4.0:

switch(config)# policy-map jumbo
switch(config-pmap)# class class-default
switch(config-pmap-c)# mtu 9216
switch(config-pmap-c)# exit
switch(config)# system qos
switch(config-system)# service-policy jumbo

The end result of these differences is this: if you upgrade NX-OS from 4.0 to 4.1, then your jumbo frames configuration will go away, and you’ll need to enter the commands for version 4.1 in order to enable jumbo frame support again. This little gotcha caused me quite a headache when my NFS-based datastores suddenly went offline after the NX-OS upgrade.

More information on the necessary commands can be found here for version 4.0 and here for version 4.1.

© Scott for Gestalt IT, 2009. | Enabling Jumbo Frames on a Nexus 5000
Read more posts categorized as Networking, Server Virtualization

A bunch of CEO’s promising to play ‘nice’ with each others toys is not a convincing marketing exercise. Cisco and EMC/VMware need to merge to get big enough to compete with HP / IBM. In the last fifteen years, I have seen so many partnerships that come and go. I take a long

Merger or Buyout

EMC is too big for Cisco to buy and Wall St doesn’t look favourably on mergers of IT companies at the moment. The HP / Compaq merger proved that merging big companies isn’t a great idea.

There is little to no overlap between the companies, Cisco already owns 5% of VMware stock (and Intel owns a goodly percentage of VMware as well).

Servers don’t make a lot of margin, and Storage margins are under threat

Cisco likes big fat margins. EMC loves big fat margins. Servers make very little margin. . I take the view that Cisco is selling servers because HP is selling switches, and can see the market is currently moving away from Cisco’s strength in the network.

Cisco doesn’t own the smarts in their servers, Intel does. Cisco just glues the latest Intel chipsets to a board like every other server manufacturer and Intel makes the big profits. This is a big change for Cisco’s business strategy and signals how desperate they must be to enter this market. Specific concerns around the HP ProCurve and it’s penetration into their existing markets must be very worrying.

Cisco has product differentiation strategy for UCS is mostly built around a hybrid storage strategy using FCoE- a technology that isn’t ready for full market adoption yet. FCIP and significant market penetration of FCoE is still years away, and the supporting Ethernet standards (not even software and hardware) won’t be ready until the middle of next year.

Sure, Cisco can build metal boxes, power supplies and marketing material like anyone else. But they also market their ability to make their own silicon in their routers and switches and how this is ‘competitive advantage’. When they don’t have their own silicon, what is their value to customers ?

Whither EMC ?

EMC owns a fairly good sized chunk of the Storage market, but their position is being threatened in the long term by commoditisation in the storage market. The cost of ganging hard disk drives together with some metalwork and a power supply is now within reach of a moderately well funded startup, and the speed of software development means that EMC’s core business is being marginalised. Witness Lefthand and 3Par as examples. At the very least, EMC profits are going to a lot slimmer over the next five years as their technology becomes commoditised.

VMware is the magic sauce

EMC owns VMWare which is the glue. They did a deal with Intel for something 10%, and Cisco got 5% a while ago. Now we know why.

But there are alternatives to VMware. Microsoft’s Hyper-V, while generally laughed at, is a contender and the Citrix XenSource could still make a comeback from it’s current position.

Balkanisation

EMC needs to make sure they don’t ‘choke the chicken’ here. By aligning with Cisco, alternatives to VMware could become viable. That’s an unlikely scenario, and VMware must be praying that customers continue to demand VMware, and not turn to HP/IBM for other virtualisation systems. Even Sun Microsystems has a very good virtualisation strategy (of course, no one’s gonna touch that until Oracle comes up with a convincing message).

If the virtualisation market separates into a two sided battle, VMware on one side and everyone else on the other then we could see HP/IBM acting as frenemies with VMware, but really focussing on some other product that meets their own product goals.

One Throat to Choke

HP and IBM are a one stop shop for hardware, software and services. The “one throat to choke” or “one arse to kick” means that HP and IBM will be considered the strongest contenders for Private Clouds. Neither Cisco or EMC are getting traction with customers because they can’t guarantee and end to end solution. Remember we are talking about multi-million dollar purchases here and typically happen when a strategic shift occurs. The CIO/CTO isn’t going to sign off on a hugely political choice unless they are comfortable with the vendor.

One thing to note – Public Clouds don’t matter here. Most companies are years, and probably a decade away, from looking at actually using Public Clouds for anything serious. Don’t let a few articles on popular websites lead you astray, or a few Tweets from some loud mouth bonehead in a marketing team give the feeling that Clouds are anything but a bright idea. Things like reliability, liability, pricing, legal ownership and title are not even being discussed yet and solutions are a long way off. Customer acceptance and use, jeesh, not anytime soon. At least, not in a big way.

Resellers should be very worried

HP and IBM will be working directly with customers and reassuring them that they will have the full attention. Given that HP and IBM already manufacture and sell the most visible assets of a cloud (servers and storage) they have a very credible pitch.

When the price war starts, Cisco/EMC will HAVE to remove the reseller from the sale to remain competitive. The reseller needs between five and ten percent margin and many customers don’t see the value of a reseller in any case. Most customers have their own expertise and don’t need a reseller for ongoing maintenance. The value and influence of the reseller is diminishing at the top end of the market.

And resellers don’t have a market in pitching external clouds because that is a specialist business well funded by the VC market or covered by existing players such as Amazon or Rackspace.

Resellers will continue to eke out a living working with Medium to Small Businesses, but there probably isn’t enough money for many to survive. Indeed, Cisco’s willingness to partner has made them popular in the reseller community, but Cisco isn’t really giving them enough profit to survive.

Living together isn’t the same commitment as being married

No matter how much a couple of fancy CEO prance around claiming to have partnered to someone, proclaiming their unending love for each other, I frankly no longer believe it. The last ten years of ‘partnerships’ showed how transient, temporary and downright false that is.

The only way two companies can show they are serious about the relationship is to get married. Living together does work for some people, but marriage shows a real commitment.

Frankly it won’t matter

HP and IBM are going to run rings around Cisco/EMC/Acadia when it comes to closing deals. They are going to be spreading Fear Uncertainty and Doubt in the minds of customers:

Who is going to be the salesman ? Which engineer will do the design ? Who do I sue if it goes wrong Cisco or EMC ? Who do you call for tech support ? What is the escalation strategy ? Who is handling the training ? Do you want to be a three way argument ?

These questions are false of course. Acadia will have infrastructure and resources so,ewhere, but the emotions will resonate and be taken seriously when you deciding to spend a couple of million kwacha on a 1000 servers in a virtualisation farm.

Think about this:

Your typical CIO is comfortable buying servers and services from HP and IBM, and is going to want a much better story about minimising the risk of choosing Cisco/EMC.

CTO: “Yessir, I’m buying servers from Cisco”
CEO: “Cisco, who are they ? We haven’t used them before. Don’t they do firewall and routers ? ”
CTO: “Umm, yes. Forget I mentioned it.”

So, until Cisco and EMC can find the guts to merge, or Cisco buys EMC outright, it hard to see how this is going to go well.

© Etherealmind for Gestalt IT, 2009. | Cisco, EMC, VMware – living together isn’t the same as married
Read more posts categorized as All, Featured, Networking