Well…. while there I had a quick Twitter exchange with Scott Lowe and Amnon Izhar about fabrics.  This is another topic that gets the old juices flowing.

Cisco UCS Kicking Some @rse

Not that long ago I recorded a podcast on the topic of Cisco UCS.  At the beginning of the podcast, Rick and I did a goofy intro making fun of former HP CEO Leo Apotheker’s apparent comment that if Cisco were selling UCS they must be selling it on planet Zircon, because HP weren’t coming up against it in the real world. 

Well…since then I know of loads of people taking up Cisco UCS, whether it be straight UCS or as part of a Vblock.  So it’s pretty clear that Cisco have really taken the game to HP in the compute market.  And clearly, in some people’s opinions, it has advantages over and above HP’s offerings.

Yes, UCS scores points on management, but they also score technical points too.  UCS has good tech.

HP have traditionally taken a steady approach to pushing server based technologies forward.  Things like Virtual Connect FlexFabric are ….. well….. OK.  Kind of average.  But with Cisco in this market, average won’t cut it any more!

Software

No doubt that HP has to improve their software.  Now that is a task that I do not envy.  If describing HP’s software I’d have to use words like clunky, bloated, slow, cumbersome, flaky…  Making significant strides in this area will be long a hard.  Good luck HP.

The Cool Stuff – Fabrics

It’s my opinion that HP need to up their game on the server technology front.  They need to be bolder and more innovative (even if via acquisition).  HP needs to get back to being best of breed and not rely on the fact that they are HP.

One way to do this, and at the same time take the game right back to Cisco, would be to buy Xsigo Systems.

NOTE: I am in no way suggesting HP are even remotely thinking of buying Xsigo – how the hell would I know! I'm just saying I think it's a cracking technology and they would make a cracking combo!

Xsigo’s Server Fabric would really cloud enable HP solutions and put them ahead of the 10Gbps curve, as well as simplify and add flexibility to HP solutions.  And all of this to an extent not possible with average technologies like VC FlexFabric.

One of the things I like about Xsigo solutions is similar to what VMware have been doing with vMotion technology.  VM movement operations (using the fs3dm datamover with hardware offload) can now be done within the storage controller without the data ever having travel up the stack from the array, through the fabric to the ESXi host and then back down again.  As a result not only are storage vMotions faster but the load is taken off the fabric and ESXi hosts.  It just makes good sense to do things this way!

Similarly, Xsigo allows us to do things in networking and server-to-server or VM-to-VM connectivity that just make sense.  Things like server to server traffic not having to travel up and over the network -

Now I’m no stupid, yes I expect the network guys to come out with their pitchforks and tell me how this doesn’t fit with their legacy backwards current models and I expect the network security card to be played.  But hey, the best technologies are always disruptive and force us to rethink the way we have traditionally done things.  And that’s only one of the advantages Xsigo brings.     

In a nutshell Xsigo would leapfrog HP servers past Cisco UCS (yes I think UCS is probably ahead o HP on a technology front right now).

What About A PCIe Fabric

So I like the idea of that and yes I know that the number of PCIe nodes deployed makes Ethernet look niche, but when I looked into this in the past (~2 years ago) PCIe wasn;t so scalable lacked a lot of networking capability and scalability.  Server fabrics dont necessarily have have all of the features of networks, but when I looked in to it back then I didn't feel that PCIe was a great fit.  Mental note: Go and revisit this.

Anyway, may be a blog and a podcast on Xsigo is required…

Earlier this week Dell wrecked my day when they announced their intention to acquire 3PAR, the company that – in my personal opinion – has the best storage array architecture on the market.

Why did this wreck my day? 

Personally I felt that 3PAR, and their top-notch architecture, deserved somebody better than Dell – no offence Dell.  Let’s face it though, Dell isn’t exactly synonymous with great enterprise storage…  If Id had my pick, I would have preferred HP pick up 3PAR. But hey, life goes on.

Best of Breed

However, now that I've had a chance to think, I’ve made an about-turn and changed my opinion.  Here’s why -

Dell already have a quality iSCSI array in guise of the Dell EqualLogic line, and I think that iSCSI has a great future in the SMB space.  Big tick in that box for Dell.

Now they have a best of breed FC block storage array that can compete with the Symmetrix and USP gorillas of the storage world!  And let’s face it, while it might not be growing at a huge pace, block storage shows no signs of going away in the enterprise space.  And even if FCoE eventually gets its act together and gobbles up the FC market, the 3PAR technology will adapt to that as easily as any other FC block storage array out there.  So, big tick in the Enterprise storage box for Dell too.

In fact, Dell now look better positioned than HP at the high end.  HP currently still OEM the Hitachi enterprise line of products in the enterprise block storage space.  These days companies are scrambling to own the stack, and Dell owning the 3PAR technology looks better than HP OEM’ing the Hitachi technology – emphasis on “owning”.

Let’s also remember that a few weeks ago Dell announced their intention to acquire Ocarina Networks.  I’ve been to Ocarina HQ, talked with some of their guys and know a little about their technology.  Smarts like those provided by the likes of Ocarina that allow for compression, de-dupe and other means of storing our data more efficiently have a great future in my opinion.  If Dell are able to integrate the Ocarina IP into the EqualLogic and 3PAR lines then they will have a really compelling story.  So that’s another big tick in the box for Dell.

With the above in mind, the Dell storage portfolio looks to be at serious risk of becoming synonymous with “Best of Breed”.  Surely not! :-S

What’s missing

With so many ticks in boxes, what is still missing for Dell?

Well, a line-up that includes a top-notch block array (3PAR), a top-notch iSCSI array (EqualLogic) and some top-notch storage optimisation technologies (Ocarina) deserves a top-notch NAS device. 

I’m not convinced that Exanet fits the top “top-notch” moniker in today’s ultra-cometetive scale-out NAS world

Looking at what is potentially available on the market, Isilon Systems must be in the potential line of fire.  They recently became a Billion dollar company so they won’t be cheap, but heck, you get what you pay for right! 

I remember hearing rumours that HP’s first choice scale-out NAS acquisition might have been Isilon when they went shopping for scale-out NAS and ended up buying IBRIX.  So, what better way to land a heavy kick to the cahoonas of one of your most fierce rivals than to go out and land something they supposedly weren’t able to land.  Of course I am only speculating that HP would have preferred to buy Isilon!  Let me just add that I personally like the looks of IBRIX, or the X9000 range as HP now call it.

Anyway, adding Isilon to the Dell storage portfolio would pretty much give Dell a store line-up to be reckoned with.  Granted, a million miles away from being integrated with each other, but nonetheless really cool and compelling technologies.

Without any doubt though, if Dell are to complete the acquisition of 3PAR and then went on to pick up someone like Isilon, then we would be waking up to a world with a new storage superpower called “Dell”.

All that would then remain in order to truly compete with the likes of Cisco, HP and IBM would be a networking platform – may be something innovative and different like Xsigo might be in order?

Oh and of course they would need to go out there and invest in acquiring a decent server platform

PS. You can join in the real-time tech talk by following me on Twitter – @nigelpoulton

On the topic of I/O Virtualisation, we look into a product that takes I/O adapters (NIC and HBA) out of physical servers and places them into a Top of Rack switch and extends PCIe out of the server chassis to the ToR switch.  The notion of extending PCIe out of the server and plumbing a rack with PCIe is very interesting.

In this inaugural episode of the Technical Deep Dive Podcast I'm joined by Greg Ferro from Etherealmind.com and Camden Ford from Xsigo Systems.  Cam talks to us about Xsigo Systems and the technologies and solutions they offer.

This is available as a two-parter due to length.  Part 1 is about 30 minutes long and Part 2 is about 40.  What can I say, you cant dive deep in 20 minutes!

Comments welcome!

As early as last summer I was involved in specking and purchasing some HP BladeSystem Matrix based solutions – essentially a shrink-wrapped Rack based solution that had compute, networking, storage and management tools.  Granted, HP Matrix is an early attempt and not much different from the norm, but a step towards the Rack Area Network (RAN).

So… Rack based solutions are on their way, and the way I see it – from speaking with peers, customers and vendors – the following two high level Rack based designs will be predominant and will slug it out over the next few years:

1.  The FCoE RAN Solution

Of the two solutions, this one most closely resembles what we know today.  The only major difference being the use of FCoE between the server and the Top of Rack (ToR) switch.  This solution requires Converged Network Adapters (CNA), copper twinax cabling and FCoE ToR switches.  As it happens this is really the only practical place that FCoE can currently be deployed.  Fortunately, however, the FCoE products in this space (the RAN) are maturing quickly – we already have 2nd generation, single chip, single driver code base, high performance CNAs shipping and supported by most good server vendors….

In the FCoE based RAN solution there is very little in the ways architectural change – no blurring of the server/network edges and no change to the design of servers or networks.  This gives the comfort factor. 

Anyway, the sketch below shows a high level view of of this type of solution -

2.  The IOV solution

This second solution is slightly more innovative.  It requires slight changes to existing server/blade designs, there is some blurring of the server and network edges, and some re-thinking of network design and management is required.  Not quite the same comfort factor that the FCoE RAN solution gives,but as the saying goes – No pain, No gain! 

The IOV solution can be summarised in the following -

Servers and blades are reduced to pure compute and memory.  The I/O components are disaggregated from the server chassis and re-housed in an external ToR I/O Director.  Servers connect to the external I/O cards by either PCIe cables or IB.  These I/O adapters can be CNAs or traditional NICs and HBAs.  They are next generation in that each one can be carved into multiple logical adapters which can each be dynamically assigned and unassigned to any server and VM within the Rack.  The I/O adapters and I/O Directors have built-in switching functionality, enabling traffic to be switched either within the I/O adapter or between adapters within the same I/O Director without the need to travel up to a traditional network switch (hairpinning in the adapter or I/O Director).  Essentially, access layer switching will be moved on to the PCIe I/O adapter!

The diagram below shows this at a high level -

No room in the RAN

Personally I like the idea of using PCIe as the main interconnect within the Rack.  Every chipset on every server already has a bunch of PCIe bandwidth that is essentially….. well…. FREE!  Who doesn’t like the sound of that!?  10Gbps CEE and FCoE licensing of ports is … well…. definitely not free.

Of course there is the other side.  PCIe muscling Ethernet out of the RAN will not go down well with some, nor will implementing switches within NICs/CNAs and I/O Directors.  Not only will this tread on certain vendors markets and margins, it also brings with it several network design and management challenges.  But what the heck… we grow from our challenges and come out the better for it – right?  Point being, knee-jerk self-preservation type reactions from the network guys should be expected

Final thought on FCoE

While the IOV solution could potentially muscle Ethernet out of the RAN, it can still branch out to FCoE switches in the core.  So either way, FCoE will play a role. 

And if we are being creative, we could run our I/O up to the ToR I/O Director over PCIe within the RAN and then branch out via a CNA in one of those I/O Directors to a core switch with FCoE ports.  One way of utilising FCoE ports that are currently available in core switches.

Interesting times!

PS. I will be featuring on the Wikibon FCoE Fact vs Fiction call on 2nd February along with Stu Miniman, Dave Graham and  Dennis Martin  If you’re interesting in FCoE put it in your calendar.

I thought it was pretty cool, so gave it a shout on Twitter.  It seems other folks thought it was more than pretty cool, with comments like way cool being thrown about.

While I think the idea is cool, I’m not sure how interested companies would be –> management and configuration changes to production kit from an iPhone ….. sounds a bit ahead of its time to me.   Cool, yes.  But is cool what major companies and managers of large Data Centres are looking for?  Remember that Xsigo kit is pretty squarely pitched at enterprise customers.  Would such applications cause more worries and concerns than they would solve problems?

Think about it this way……. Matt Davis pinged me back saying that he had once done “symcli over ssh over VPN ….. via my iPhone” to administer a Symmetrix DMX!!  Not sure what your initial thoughts are on hearing that, but mine were trepidation.  Sure, that’s pretty damn cool, but pretty flipping scary too!  Kudos to Matt, but more scary than cool in my books

But that is comparing apples to oranges, SYMCLI is an entirely different beast to the Xsigo UI.  If nothing else, one thing that the Xsigo iPhone app does demonstrate, is the simplicity of administering Xsigo kit.  I’d feel a lot safer administering a Xsigo director via an iPhone app than performing SYMCLI via an iPhone. 

Thought:  Hows about administering Cisco UCS via an iPhone?  I hear rumours that Cisco UCS is so complicated to configure, Cisco will only let you have it if they do the configuration work! 

Anyhow, even if the Xsigo kit is so simple to manage ….. not sure how comfortable the powers that be would be with it?  Id be interested in other peoples thoughts on this.

So assuming enterprise data centres are not quite ready (Im open to being wrong) for staff administering production kit via their iPhone, what would they be happy doing via an iPhone? 

How’s about iPhone apps for monitoring and reporting?

Not quite as cool, but once people become comfortable with monitoring and reporting via an iPhone…. may be bolder moves like configuring and managing might be more palatable.

Video courtesy of the XsigoVirtualIO’s Channel on YouTube

Heck may be apps like this will help propel the iPhone in to large corporate accounts as a serious business phone.  Probably about as close to enterprise as Apple are going to get.

Initial opinion: Very cool, unsure how popular it would be in enterprise accounts. May be slightly ahead of its time.

UPDATED OPINION (6th Jan 2010): The more and more I think about this, the more and more I like it.  We will no doubt be seeing more and more apps like these in the future, and this could be an absolute godsend under certain circumstances.  A great little tool to have in your toolbox.  It probably wont be long before we wonder how we got by without apps like these.  But the hard part will still be trying to convince the risk averse "steady as she goes" powers that be.

I’m interested to hear what anybody else thinks.  I've also placed a related poll on the Homepage please cast your vote.

 DISCLAIMER: I use a BlackBerry…….. and wish it was an iPhone

So…. when discussing I/O Virtualisation (IOV) it’s usually not long before the concept of hair-pinning arises.  The conversation usually goes like this –

If a single physical port is being carved into multiple virtual ports, can you switch traffic between two virtual ports sharing the same hardware, without the I/O having to leave the physical adapter?

The diagram below shows this concept, which is sometimes called Virtual Ethernet Bridging, switching within the adapter, hair-pinning or a hairpin turn –

In the above diagram there is a single server running two Virtual Machines.  The server has a single physical NIC configured to present two virtual NICs (vNIC).  vNIC 1 is assigned to VM1 and vNIC 2 is presented to VM2.  When VM1 sends data to VM2, in the diagram above, the physical NIC switches the packets without having to send them on to the edge switch – requiring the physical NIC to have a built-in switch, blurring the lines between server and network and a boat load more…..!

Sound interesting?  Sound disruptive?  Sound bold?  Sound cool? …….. It should!

Some Theoretical Examples

Like you might expect, there are several different ways that hair-pinning can be implemented and the diagrams below show 3 possibilities –

SR style

The above Single Root (SR) style implementation has a single physical NIC in a single physical server, with vNICs being presented only to VMs executing on a single physical server.  It can switch frames between vNICs carved from the same physical NIC.

  MR Style

The above can be either Single Root (SR) or Multi Root (MR) and removes the physical NIC from the server chassis and re-houses it in an external I/O Aggregator such as those offered by Xsigo and VirtenSys.  The potential exists to switch frames between vNICs from either the same physical or different physical NICs.  It can switch frames between VMs on different physical machines without touching the network.

Hairpinning in the switch

The above example actually performs the hairpin turn in the edge switch rather than the I/O adapter.  A single physical switch port is carved in to multiple virtual switch ports (referred to as VP in my above sketch).  Normally Ethernet switches don’t switch frames back out over the same prot that they arrived on. 

Like most new technologies and disruptive concepts, there are die-hard advocates for each approach.  There are also equally die-hard opponents.  Naturally this creates some interesting and often intense discussion – after all, taking a moment to think about the possibilities, this could potentially be very disruptive to existing networking models, and as always, there will be people who will not take this lying down.

Obviously there are pro’s and con’s as well as pre-req’s for each approach, and I intend to highlight and discuss some of them in future posts.

Hopefully this has shwd some light for now, and feel free to pitch in with thoughts, experiences and questions. 

Nigel

PS. FAO Standalone Sysadmin, the diagrams are not crayon   Oh and I kind of like them!

PPS.  Just so that folks don’t think Im making this stuff up again go search terms such as VNTag and VN-Link.  These are technologies that Cisco is all over and they relate to being able to hairpin on physical switch ports.  In fact when I get a minute I might get my crayons out again and add some detail to the diagrams

Other RAN and IOV related posts –

Introducing the RAN concept

IOV vNICs and vHBAs

And before anybody asks……. yes the stubble is designer, no Im not wearing a toupee, and the bags under my eyes are from 16 hours of travelling and then chatting in the hotel bar until silly o’clock in the morning

Nigel Poulton Tech Field Day Interview from Stephen Foskett on Vimeo.

Feel free to check out the following link to the GestaltIT Tech Field Day home page on Vimeo, with links to all of the uploaded videos form the event.  It was an amazing event with some very interesting technologies and companies in participation.

Nigel

If you work deploying VMware, Hyper-V, XenServer etc or if you have anything to do with the so called Virtual Data Centre, then you need to be all over IOV.

This is the second post in my mini-series on RAN and IOV.  In this particular post Im going to talk about the concept virtual adapters – Virtual NICs and Virtual HBAs.

The vNIC and the vHBA

The concept is simple: Take a physical NIC, perform some magic on it, and make it appear to the OS as multiple NICs.  Same goes for HBAs.

The diagram below shows a single physical NIC carved into 4 virtual NICs (vNIC) and a single HBA carved in to 4 virtual HBAs (vHBA). 

The benefits of such technologies should be obvious – higher utilisation, requirement for fewer physical NICs, fewer cables, and fewer edge switch ports – just to name a few.

Another added benefit is flexibility.  Assume you have a 10Gbps NIC in a server which you have carved in to 2 vNICs.  That server now has a requirement for an additional NIC.  You no longer have to power down the server, open it up, install a new physical card and then wait for new cables to be laid.  Instead, you can simply create a new vNIC, from the already installed physical NIC, and have it dynamically discovered and initialised by the OS.  All done in software – no cracking the server open and no waiting for cables!  Talk about reducing the time taken to implement a change, not to mention reducing the risk (there is always added risk when opening up servers and messing around in the floor void….).

The CNA

In the above diagram we labelled the vNIC solution as Good.  If we swap out that IOV capable NIC and replace it with a CNA (Converged Network Adapter) that can act as both a NIC and a CNA, then we suddenly have the ability to carve vNICs and vHBAs from a single physical Adapter.  The diagram below has been expanded to now include a CNA based solution.  The CNA solution is labelled as “Better”.

NOTE: I should point out that in most IOV solutions most of the  legwork is done in hardware.  The vNIC and vHBA devices are created in hardware, as well as most modern CNAs providing protocol offloads…..

Single Root

The above approach – of creating multiple virtual adapters from a single physical adapters located within a single server – falls under the category of Single Root (SR).  Single Root being another way of saying single server (PCIe root complex).  Single Root approaches are limited to presenting their virtual adapters to a single PCIe root complex – operating systems executing within a single physical server.

While talking about Single Root technologies I need to mention SR-IOV.  SR-IOV is a semi-open PCI-SIG standard for SR style I/O Virtualisation.  As with all standards, it will take time to take-off and become widely deployed, and is open to implementation interpretation (some vendors may implement SR-IOV slightly differently to others).

True PCI-SIG SR-IOV requires the following components to be SR-IOV aware in order to support it -

• BIOS
• OS/Hypervisor
• Physical I/O Adapter
• Driver

Changes to the above components are required due to the fact that SR-IOV changes the architecture and model for PCIe adapters.  It introduces the concept of Virtual Functions (VF) which look and feel like a normal physical I/O adapter.  However, VFs are a lightweight version of a physical I/O adapter and inherit some configuration options from their parent physical I/O adapter.  As a result, vNICs and vHBAs are enumerated on a servers PCIe device tree as VFs, and the BIOS, OS and driver must understand this.

Citrix recently demoed XenServer working with SR-IOV NICs and Intel VT-d technology.

While SR-IOV is a great technology and is destined to play a role in driving IOV forward, it is very early days for the technology and the many of the currently shipping IOV technologies are using proprietary techniques and not PCI-SIG SR-IOV.  Some of these technologies include -

• HP Virtual Connect Flex-10
• IBM Virtual Fabric

NOTE: While the Virtual Fabric for IBM BladeCenter solution is not currently SR-IOV, the chip that powers the Emulex CNA that sits at the heart of the solution, is SR-IOV capable….. just waiting for the other components (BIOS, OS, Drivers…) to catch up.

Good, better, BEST!

So far we have talked about SR style solutions where the vNIC and vHBA devices are only available to Operating Systems executing on the same physical server that the adapter is installed in.  While these technologies are all good and a step in the right direction, there exists a superior solution – Multi Root (MR).

Taking IOV to the next step involves removing the physical I/O adapters from the physical server chassis and re-house them in an external device that I am generically referring to as the I/O Aggregator. 

The diagram below has been expanded to include an example I/O Aggregator approach.

Such technologies can be referred to as Multi Root (MR).

There are already Multi Root I/O Aggregator style solutions shipping from the likes of NextIO, VirtenSys and Xsigo – all are delivering next generation IOV benefits today!

Of the currently available solutions, these MR technologies offer the greatest levels of virtualisation and flexibility and for me represent the future.  By removing the I/O adapter from within the physical confines of the server chassis, you enable any vNIC or vHBA to be assigned to any server.  Your physical server becomes entirely stateless from an I/O perspective!

I used to be excited about LOM style CNA implementations…. until I discovered I/O Aggregators.

NOTE: PCI-SIG also have a specification for MR-IOV.  However, I do not know of anybody deploying it at the moment

Moving Home

Opinion time here, but they way I see it, the I/O adapter is folding its underwear and packing its bags ready to ship out of the server chassis into a bigger, better and more comfortable new home – the I/O Aggregator. 

PCIe adapters in servers…… don’t be so yesterday

Would love to know what anybody else thinks.

Nigel

You can follow me on Twitter. I’m @nigelpoulton and I only talk about technology.

I am also available as an independant freelance consultant and can be contacted via the Contact Me page.

Other RAN and IOV related posts –

IOV and introducing hairpin turns

Introducing the RAN concept

The term, as well as the concept, of Rack Area Networking is one I’m hearing more and more often.  As a result of this, as well as the fact that I’m convinced this is going to be one of the most interesting and important areas of Data Center computing over the next few years, I’ve decided to write a mini-series on the topic. 

This post is instalment number 1 and is intended to introduce the concept and get the ball rolling.  The whole thing is a bit of me thinking out-loud and attempting to generate some awareness and conversation around the topic, as .  So please pitch in!

Rack Area Network – the concept

For me, Rack Area Networking, or RAN for short, is an umbrella term for most of the clever networking and I/O virtualization stuff that goes on within a rack – a 42u rack. 

With it being “Rack Area”, it is a close proximity network and as a result operates over very high-speed low-latency interconnects.  

Physically, RAN technologies include a new generation of at least the following: I/O adapters, cabling, Top of Rack (ToR), and may be even End of Row (EoR), switches.  However, for reasons which will become clear, the emphasis is heavily on the clever – technologies that enable the flexible, the dynamic and the virtual aspects.

For example, the I/O Adapters driving the RAN evolution are not just faster than the legacy adapters they are replacing, they have built-in cleverness – hardware virtualization and huge flexibility! 

Some of the other technologies that define and operate within the RAN include – SR-IOV, MR-IOV, vNIC, vHBA, CNA, FCoE, Hairpin-turns, switching in the adapter, VNTag, VN-Link…. just to name a few.  In future posts we will discuss most of them.

As well as the above new hardware and technologies, the RAN also requires and includes a new generation of management software and functionality.  True value is often in the software – the glue that holds it all together and makes it all happen.

The best part being, there are early RAN technologies already out there in the wild.  And they are already delivering real-world tangible benefits.

Some technologies driving the evolution…

It’s really important to note that while technologies in the RAN are experiencing a period of accelerated evolution, it is most definitely an evolution.  The changes are happening fast, but they are not huge disruptive changes.  For the most part, they are improvements and enhancements, albeit major, on what we already know and are comfortable with.  E.g. take PCIe adapters and create multiple virtual adapters (vNIC and vHBA) in hardware….

Just a few of the currently shipping RAN technologies include -

• HP Virtual Connect Flex-10
• IBM Virtual Fabric Solution w/ Emulex UCNA
• Cisco UCS w/ Palo adapter
• Xsigo I/O Director
• Virtensys VIO switches

NOTE: Let me know if I’ve missed any major RAN technologies off the list

Some of the above technologies are very much generation 1 and only a small step towards the RAN, bringing only small benefits.  Whereas others are a major step with huge benefits.  All vendors are scrambling to take the lead in this evolving area.  In later posts we’ll dig deep into most of them.

Blurring the Lines and Causing Havoc

Naturally, many of these technologies are challenging and threatening the traditional server/network edge configurations we are used to. 

Hairpin turns, switching in the adapter and avoiding edge switches are just some of the paradigm shifts that RAN technologies might force us to consider.  Such topics are the subject of intense and engaging debate.  All very interesting and some of the concepts are very cool!

In upcoming posts we’ll talk about the likes of – SR-IOV MR-IOV Hairpin-turns VirtenSys Flex-10 VEB Xsigo VNTag NextIO VNLink InfiniBand PCIe

Thanks for dropping by and feel free to throw in your penny’s worth.

Nigel

I am available as an independant freelance consultant and can be reached via the Contact Me page.

If you're thinking that I might just bemaking some of this stuff up or inventing buzwords, then you need to check out my follow-on RAN and IOV related posts listed below -

IOV vNICs and vHBAs

IOV and introducing hairpin turns