Taking a Good Hard Look at SDN

SDN is sitting at the peak of it’s hype cycle (at least I hope it’s the peak.)  Every vendor has a definition and a plan.  Most of those definitions and plans focus around protecting their existing offerings and morphing those into some type of SDN vision.  Products and entire companies have changed their branding from whatever they were to SDN and the markets flooded with SDN solutions that solve very different problems.  This post will take a deep dive into the concepts around SDN and the considerations of a complete solution.  As always with my posts this is focused on the data center network, because I can barely spell WAN, have never spent time on a campus and have no idea what magic it is that service providers do.

The first question anyone considering SDN solutions needs to ask is: What problem(s) am I trying to solve.  Start with the business drivers for the decision.  There are many that SDN solutions look to solve, a few examples are:

  • Faster response to business demands for new tenants, services and applications.
  • More intelligent configuration of network services such as load balancers, firewalls etc.  The ability to dynamically map application tiers to required services.
  • Reductions in cost i.e. CapEx via enabling purchase of lower cost infrastructure and OpEx via reducing administrative overhead of device centric configuration.
  • Ability to create new revenue streams via more intelligent network service offerings.
  • Reduction in lock-in from proprietary systems.
  • Better network integration with cloud management systems and orchestration tools.
  • Better network efficiency through closer match of network resources to application demands.

That leaves a lot of areas with room for improvement in order to accomplish those tasks.  That’s one of the reasons the definition is so loose and applied to such disparate technologies.  In order to keep the definition generic enough to encompass a complete solution there are three major characteristics I prefer for defining an SDN architecture:

  • Flow Management – The ability to define flows across the network based on characteristics of the flow in a centralized fashion.
  • Dynamic Scalability – Providing a network that can scale beyond the capabilities of traditional tools and do so in a fluid fashion.
  • Programmability – The ability for the functionality provided by the network to be configured programmatically typically via APIs.

The Complete Picture:

In looking for a complete solution for Software Defined data center network it’s important to assess all aspects required to deliver cohesive network services and packet delivery:

  • Packet delivery – routing/switching as required.  Considerations such as requirements for bridging semantics (flooding, broadcast), bandwidth, multi-pathing etc.
  • L4-L7 service integration – The ability to map application tiers to required network services such as load-balancers and firewalls.
  • Virtual network integration – Virtual switching support for your chosen hypervisor(s).  This will be more complex in multi-hypervisor environments.
  • Physical network integration – Integration with bare-metal servers, standalone appliances, network storage and existing infrastructure.
  • Physical management – The management of the physical network nodes, required configuration of ports, VLANs, routes, etc.
  • Scalability – Ability to scale application or customer tenancy beyond the 4000 VLAN limit.
  • Flow management – The ability to program network policy from a global perspective.

Depending on your overall goals you may not have requirements in each of these areas but you’ll want to analyze that carefully based on growth expectations.  Don’t run your data center like congress kicking the can (problem) down the road.  The graphic below shows the various layers to be considered when looking at SDN solutions.

image

Current Options:

The current options for SDN typically provide solutions for one or more of these issues but not all.  The chart below takes a look at some popular options.

 

 

VLAN Scale

L4-7

Bare Metal Support

Physical Network Node MGMT

KVM

VMware

Xen

HyperV

L3

Flow MGMT

Nicira/VMware X 3rd Party *   X * X   3rd Party X
Overlays X       X X X X    
OpenFlow     X   X X X X X X
Midokura X X     X   X   X  

X = Support

* = Future Support
This chart is not intended to be all encompassing or to compare all features of equal products (obviously an overlay doesn’t compete with a Nicira or Midokura solution, and each of those rely on overlays of some type.)  Instead it’s intended to show that the various solutions lumped into SDN provide solutions for different areas of the data center network.  One or more tools may be necessary to deploy a full SDN architecture and even then there may be gaps in areas like bare metal support, integration of standalone network appliances and provisioning/monitoring/troubleshooting of physical switch nodes (yes that all still matters.)
API Model:
Another model lumped into SDN is northbound APIs for network devices.  Several networking vendors are in various stages of support for this model.  This model does provide programmability but I would argue against it’s scale.  Using this model requires top down management systems that understand each device, its capabilities and its API.  To scale this type of management system and program network flows this way is not easy and will be error prone.  Additionally this model does not provide any additional functionality, visibility or holistic programmability, simply a better way to configure individual devices. That being said managing via APIs is light years ahead of screen scrapes and CLI scripting.
Hardware Matters:
Let me preface with what I’m not saying: I’m not saying that hardware will/won’t be commoditized, and I’m not saying that custom silicon or merchant silicon is better or worse.
I am saying that the network hardware you choose will matter.  Table sizes, buffer space, TCAM size will all factor in, and depending on your deployment model will be a major factor.  The hardware will also need to provide maximum available bandwidth and efficient ECMP load-balancing for network throughput.  This load-balancing can be greatly affected by the overlay method chosen based on available header information for hashing algorithms.  Additionally your hardware must support the options of the SDN model you choose.  For example in a Nicira/VMware deployment you’ll have future support for management of switches running OVS, you may want these to tie in physical servers, etc.  The same would apply if you choose OpenFlow.  You’ll need switch hardware that provides OpenFlow support, additionally it will need to support your deployment model hybrid or pure OpenFlow.
The hardware also matters in configuration, management, and troubleshooting.  While there is a lot of talk of “We just need any IP connectivity” that IP network still has to be configured and managed.  Layer 2/3 constructs must be put in place, ports must be configured.  This hardware will also have to be monitored, and troubleshot when things fail.  This will be more difficult in cases where the overlay is unknown to the L3 infrastructure at which point two separate independent networks will be involved: physical and logical.
Management Model:

There are several management models to choose from and two examples in the choices I compared above.  OpenFlow uses a centralized top down approach with the controller pushing flows to all network elements and handling policy for new flows forwarded from those devices.  The Nicira/VMware solution uses the same model as OpenFlow.  Midokura on the other hand takes a play from distributed systems and pushes intelligence to the edges in that fashion.  Each model offers various pros/cons and will play a major role in the scale and resiliency of your SDN deployment.

Northbound API:

The Northbound API is different than the device APIs mentioned below.  This API opens the management of your SDN solution as whole up to higher level systems.  Chances are you’re planning to plug your infrastructure into an automation/orchestration solution or cloud platform.  In order to do this you’ll want a robust northbound API for your infrastructure components, in this case your SDN architecture.  If you have these systems in place, or have already picked your horse you’ll want to ensure compatibility with the SDN architectures you consider.  Not all APIs are created equal, and they are far from standardized so you’ll want to know exactly what you’re getting from a functionality perspective and ensure the claims match your upper layer systems needs.

Additional Considerations:

There are several other considerations which will effect both the options chosen and the architecture used some of those:

  • How are flows distributed?
  • How are unknown flows handled?
  • How are new end points discovered?
  • How are required behaviors of bridging handled?
  • How are bad behaviors of bridging minimized (BUM traffic)?
  • What happens during controller failure scenarios?
  • What is the max theoretical/practical scalability?
    • Does that scale apply globally, i.e. physical and virtual switches etc.?
  • What new security concerns (if any) may be introduced?
  • What are the requirements of the IP network (multicast, etc.)
  • How is multi-tenancy handled?
  • What is the feature disparity between virtualized and physical implementation?
  • How does it integrate with existing systems/services?
  • How is traffic load balanced?
  • How is QoS provided?
  • How are software/firmware upgrades handled?
  • What is the disparity between the software implementation and the hardware capabilities, for example OpenFlow on physical switches?
  • Etc.

Summary:

SDN should be putting the application back in focus and providing tools for more robust and rapid application deployment/change.  In order to effectively do this an SDN architecture should provide functionality for the full life of the packet on the data center network.  The architecture should also provide tools for the scale you forecast as you grow.  Because of the nature of the ecosystem you may find more robust deployment options the more standardized your environment is (I’ve written about standardization several times in the past for example:http://www.networkcomputing.com/private-cloud-tech-center/private-cloud-success-factor-standardiza/231500532 .)  You can see examples of this in the hypervisor support shown in the chart above.

While solutions exist for specific business use cases the market is far from mature.  Products will evolve and as lessons are learned and roadmaps executed we’ll see more robust solutions emerge.  In the interim choose technologies that meet your specific business drivers and deploy them in environments with the largest chance of success, low hanging fruit.  It’s prudent to move into network virtualization in the same fashion you moved into server virtualization, with a staged approach.

GD Star Rating
loading...

The App on the Crap (An SDN Story)

I’m feeling Seussish again and looking to tackle SDN this time.  If you missed my first go it was on Hadoop: Horton Hears Hadoop.  Here’s another run:

 

The app could not flow

Net was too slow to change.

It sat on the server

Waiting on admin for change.

 

It sat there quite idly

Customers did too

The dev thought, “How I wish

They’d let my app through!”

 

Too slow to adapt

Too rigid and strict.

The business can’t move.

And that’s my verdict.

 

So all they could do was to

Sit!

   Sit!

      Sit!

         Sit!

The dev did not like it.

Not one little bit.

 

And then

Someone spoke UP!

How that speech gave us PUMP!

 

We listened!

And we heard it move into the hype!

We listened!

A network of SDN type!

The message quite clear,

“You’ve got no need to gripe.”

 

“I know it is slow

and the network is messy.

There is a fix

With software that’s dressy!”

 

“I know some good tricks we can use,”

SDN gal said.

“A header or two,”

Said the gal with the plan.

“Controllers as well.

I will show them to you.

Your CTO

Will not mind if I do.”

 

Then app and dev

Did not know what to say.

The CTO was out playing golf

For the day.

 

But the net admin said, “No!

Make that gal go away!

"Tell the SDN gal

You do NOT want to play.

She should not be here.

She should not be about.

She should not be here

When the CTO is out!”

 

“Now! Now! Have no fear.

Have no fear!” Said the gal.

“My tricks are not bad,”

Said the SDN gal.

“Why you’ll have

So many options from me,

With some tricks that I call

Virtualization you see!”

 

“Stop this nonsense!” admin said.

“We don’t need to scale!

Stop this nonsense!” Admin said.

“The net cannot fail!”

 

“Have no fear!” said the gal.

“I will not let net fail.

I will make it dynamic

And people will hail.

Its changes are quick!

It grows very fast!

But there is much more it can do!”

 

“Look at it!

Look at it now said the gal.”

“With a new overlay

And control from a pal!

It can adapt very fast!

It’s managed quite nicely!

The scale is much greater!

And admin less dicey!

And look!

You can change flows from here!

But there is more dear!

Oh, no.

There is more dear…

 

“Look at it!

Look at it!

Look at it now!

It’s better you see

But you have to know how.

How it can adapt

And respond to new apps!

How it grows to scale!

And helps those dev chaps!

Can grow past those VLANs

And direct traffic, see!

We wrap Layer two

In Layer three IP!

And we route the IP!

As we grow big from small!

But that is not all.

Oh, no.

That is not all….”

 

That’s what the gal said…

Then the net went dead!

The apps all went down

From out at the NOC.

The developers,

Watched with eyes open in shock!

 

And the admin cried out.

With a loud angry shot!

He said, “Do I like this?

Oh no! I do not.

This is not a good trick,”

Said the admin with grit.

“no I don’t like it,

Not one little bit!”

 

“Now look what you did!”

Said admin to gal.

“Now look at this net!

Look at this mess now pal!

You brought down the apps,

Crashed services too

You cost us some sales

And caused lost revenue.

You SHOULD NOT be here

When the CTOs not.

Get out of the data center!”

Admin said from his spot.

 

“But I like to be here.

Oh, I like it a lot”

Said the SDN girl

To the admin she shot.

“I will not go away.

I do not wish to go!

And so,” said the SDN girl,

“So

    So

       So…

I will show you

Another good trick that I know!”

 

And then she ran out.

And, then fast as a fox,

The SDN gal

Came back with a box.

 

A big green wood box.

It was shut with a hook.

“Now look at this trick,”

Said the gal.

“Take a look!”

 

Then she got up on top

And with no rationale.

“I call this game SDN-IN-A-BOX,”

Said the gal.

“In this box are four things

I will show to you now.

You will like these four things.”

Said the gal with a bow.

 

“I will pick up the hook.

You will see something new.

Four things. And I call them

The SDN glue.

These things will not harm you.

They want to move frames.”

Then, out of the box

Came her SDN claims!

And they came out quite fast.

They said, “Are you ready?

Now should we get started

Let’s get going already!”

 

The devs and the apps

Did not know what to do.

So they sat and they watched

Watched the SDN glue.

They stood in their shock

But the admin said “No!

Those things should not be

On this net! Make them go!”

 

“They should not be here

When the CTOs not!

Put them out! Put them out!”

Admin yelled with a shot.

 

“Have no fear, Mr. admin,”

Said the SDN gal.

“These things are good things

And good for morale.”

“They’re great.  Oh so great!

They have come to fix things.

They will give back control

To the network today.”

 

“The first is an overlay,

Number two a vSwitch

But that’s only halfway.”

Was the gals latest pitch.

 

“We’ll next need control

For the flows as they go.

Something to manage

Those flows as they flow.

But there’s still one more piece

Of this SDN madness.

Device management system

To avoid admin sadness.”

 

Then the SDN gal

Said with conviction

“We aren’t quite done yet

There’s one more restriction.

We must tie these together

In a cohesive fashion,

If we do not

It’s all stormy weather.

We will organize things

With apps at the center

And let those developers

For once spread their wings.”

 

“You see in the past,”

Said the SDN gal.

“The net was restrictive

the apps were in hell.

Now we change things around

Put the apps back in focus.

Using these tricks,

And some good hocus pocus.

With a sprinkle of tears

From the unicorn clan,

And a dash of fine dust

A pixie put in this can.

We’ll accomplish the task.”

SDN gal said as she drank from her flask.

 

And lo and behold,

The network sprang back.

The packets were flowing,

TCP sent it’s ACK.

The admin stood shocked,

As he used the controller.

With this type of thing,

He would be the high roller!

He gaped in amazement

At the tenancy scale.

No longer 4000,

It was net holy grail.

 

The apps back online,

As CTO entered.

A disaster avoided, he was left with no sign.

Of the mess that had happened,

While he was out and about.

But the faint sound of snoring

SDN girl drunk and passed out.

GD Star Rating
loading...