Your guide to embedding SDN in data centers, from start to ...cdn.ttgtmedia.com/searchNetworking/Downloads/Your... · 4 YOUR GUIDE TO EMBEDDING SDN IN DATA CENTERS, FROM START TO

Your guide to embedding SDN in data centers, from start to finish

FEBRUARY 2017NETWORKING HANDBOOK

IST

OC

K

2 YOUR GUIDE TO EMBEDDING SDN IN DATA CENTERS, FROM START TO FINISH

In this handbook:

Editor’s Letter

Easier data center SDN deployments would enable private clouds

How to assess the benefits of SDN in your network

Moving data center strategies: What to consider in an SDDC transition

NETWORKING HANDBOOK

After you define an SDN data center, what’s the next step?

ALISSA IREI

Because the answer still varies depending on whom you ask, many

conversations about software-defined networking wisely begin with the

question: “What is SDN?” According to our own definition, “In a software-

defined network, a network administrator can shape traffic from a centralized

control console without having to touch individual switches, and can deliver

services to wherever they are needed in the network, without regard to what

specific devices a server or other device is connected to.”

Simple, right? Well, maybe not simple. As it turns out -- in the data center at

least -- plenty of complications remain. While the technology has come a

long, long way over the past several years, deployments can still require a fair

amount of heavy lifting. In the three articles that comprise this guide to the

SDN data center, our experts explore the challenges of the SDDC transition

and how to anticipate and overcome them. For instance, building a private

cloud using SDN is not for the understaffed or the faint of heart, despite the


In this handbook:

Editor’s Letter




NETWORKING HANDBOOK

clear benefits of software-defined networking. To decide what to do, there are

key questions you should ask as you weigh whether software-defining your

data center is right for your organization right now.

If you do decide to move forward in deploying an SDN data center, then you’ll

need a clear plan for your legacy equipment; that is why we also offer insights

into several possible approaches for strategically reconciling old and new.

As our experts explore SDDCs, they not only explain the nature of the SDN

data center, they help you determine where you need to go from here.


JOHN BURKE

Software-defined networking has tremendous potential to transform all

data networking due to its ability to separate network control from packet


In this handbook:

Editor’s Letter




NETWORKING HANDBOOK

delivery. But most organizations are currently focused on what SDN can do

for them in the data center. On one hand, by making the network completely

programmable, SDN promises to make the network as agile and automated

as virtual servers and storage, which makes the data center function more like

a cloud. On the other hand, through microsegmentation, SDN offers a more

flexible and manageable technology for improving the data center security

landscape.

Given all that, and the fact that SDN has been talked about in one way or

another for five years or more, fewer than 10% of organizations have deployed

data center SDN in production. It turns out that even as technologies have

matured to the point where they are stable and scalable enough to serve, they

are not yet easy to deploy, or at least not easy enough for broad and deep

deployment.

Early adopters tell similar stories. They say it’s possible to achieve what they

were hoping for in terms of simplification, but that success requires a lot of

hard work. The hard work comes in terms of thoroughly mapping out the web

of relationships in the data center to understand how to segment the network

properly. In production, complexity also comes in terms of manually building


In this handbook:

Editor’s Letter




NETWORKING HANDBOOK

out the security groups and policies and knitting together the various tools

required to provide true cloud-like behavior.

CLOUD MANAGEMENT, DATA CENTER SDN AS INTERNAL CLOUD PIECES

For enterprises that want to build a true private cloud, the data center SDN

issues are only one facet of the larger question of how to justify it. Anyone

committed to the effort must make a hard calculation. Organizations have

to decide whether the effort involved in creating a private cloud using

virtualization, SDN and a cloud management platform is worth the investment.

To make it work for the organization, they either must buy or build layers of low-

level building blocks that include virtual servers of various sorts, virtual storage

services and networking.

They will also have to develop or acquire middleware functions: an internal

platform as a service of various sorts to provide database services and

application services with load balancing and redundancy. Then they must

bring it all together in a portal and catalog, with appropriate accounting

to prevent re-enacting the tragedy of the commons with their resource

pools. Then, of course, they must provide the orchestration layer to make it

responsive to changes in demand and load.


In this handbook:

Editor’s Letter




NETWORKING HANDBOOK

Even with a cloud management platform, it takes a lot of layers of effort and the

significant burden of systems integration. For some organizations, there’s no

question that the effort is worth the reward. For others, using a public cloud is

not an option as a matter of policy.

For those who can, the alternative is to make use of public cloud offerings,

or cloud services. Amazon, Microsoft, Google, IBM, Oracle and others have

already done the low-level work -- and in varying degrees, the middle-level

work as well -- and they are providing much of the necessary orchestration

behind the scenes.

Given the fact that 75% of organizations make some use of infrastructure as a

service already, for example, can they justify the effort of deploying an internal

cloud at this point? Is it worth it to them to recreate the engineering effort of

developing a scalable, resilient database service given that so many cloud

service providers already have? On careful examination, they will more than

likely find that sticking with virtualized but not fully “cloudified” operations in

their own data centers while expanding use of the public cloud makes more

sense, at least until building a private cloud using a cloud manager and data

center SDN and all the rest, is much simpler.


In this handbook:

Editor’s Letter




NETWORKING HANDBOOK


JOHN BURKE

Software-defined networking has matured from a science experiment into

deployable, enterprise-ready technology in the last several years, with

vendors from Big Switch Networks and Pica8 to Hewlett Packard Enterprise

and VMware offering services for different use cases. Still, Nemertes

Research’s 2016 Cloud and Data Center Benchmark survey found a little more

than 9% of organizations now deploying SDN in production.

In terms of the benefits of SDN, let’s look at three of the most important

problems the technology can solve, along with some considerations you can

use to decide how SDN could help you.

More intelligent access. One of the main benefits of SDN technologies is to

help you make the access edge of your branch and campus networks more

intelligent for both security and performance management. For example,

SDN can simultaneously provide a platform for network access control and


In this handbook:

Editor’s Letter




NETWORKING HANDBOOK

for dynamically applied optimization of unified communications sessions that

include voice, collaboration and video.

Network virtualization. One of the key pillars and expected benefits of SDN is

the ability to virtualize the network -- or, in other words, to overlay one or more

logically separate networks on top of the single physical one. As a result, in

network architectures not determined by cabling, network functions can be

applied when and where they are needed. Virtual networks provide the basis

for microsegmentation as a security strategy in the data center. They can also

be a part of an intelligent access layer by recognizing a video phone when it

is plugged in and assigning it to a specific virtual network for performance

management, for example.

Data center network automation. For many IT shops, the data center network

continues to be the sticking point in fast deployment of new services, products

and virtual infrastructure. One of the benefits of SDN is to help make the

network more directly scriptable by using APIs for the product or service.


In this handbook:

Editor’s Letter




NETWORKING HANDBOOK

QUESTIONS TO HELP YOU DETERMINE THE BENEFITS OF SDN

So, is it time for you to look at SDN? Consider the answers to the following

questions as you go through the decision-making process.

■■ Is the relevant network -- access edge, data center or both -- ready

for SDN as is? In other words, is your network gear of relatively recent

enough vintage that it can be a part of an OpenFlow-based software-

defined network?

■■ If not, is it time for a refresh? If the answer is yes, you can make SDN a key

criterion in the decision about what to replace it with.

■■ If it’s not refresh time, is the problem you face acute enough to justify a

replacement outside of the regular refresh cycle? You can also consider

overlaying an SDN infrastructure selectively, adding the necessary gear

only where it is needed most urgently and expanding from there.

■■ Can your vendor or provider give you a validated architecture or blueprint

for deployment that addresses your specific requirements?


In this handbook:

Editor’s Letter




NETWORKING HANDBOOK

■■ Can your vendor give you references to people in other organizations

who have done what you want to do, or who have done something similar

enough that their experience can serve as a guidepost?

■■ Can you carve off a meaningful piece of the problem to solve in a pilot

deployment with minimal investment of equipment and time? You

shouldn’t have to make an all-or-nothing transition to a new platform with-

out a chance to test in place that it can work for you.

■■ Do you have a robust change management process? You need one when

you make a fundamental shift in technology.

■■ If you are aiming to address a data center issue, especially in support of

microsegmentation, do you have solid relationship mapping information

for the systems there? That is, do you understand fully the relationships

among the systems to which you are seeking to apply microsegmenta-

tion? Early adopters in the space have repeatedly told Nemertes their

projects slowed down dramatically when they realized how incomplete

their knowledge was about which systems really needed to talk to each

other. It isn’t hard to find out which ones are talking to each other. It’s

much harder to know which ones should be talking to each other.


In this handbook:

Editor’s Letter




NETWORKING HANDBOOK

Nemertes has been saying for a of couple years now that all network

acquisitions should be made with eventual SDN deployment in mind. Now is

the time to start identifying what the first steps in that deployment should be

and whether the time has come to begin looking at the benefits of SDN for

your organization.


RUSS WHITE

So, you’ve decided to move ahead with building, or transitioning to, a software-

defined data center, or SDDC. At this point, walking down the hot aisle of your

existing data center may seem like an exercise in frustration. What should you

do with your existing equipment -- and the applications running on it? The

answer -- as with most things in information technology -- is, “It depends.”


In this handbook:

Editor’s Letter




NETWORKING HANDBOOK

There are two basic models to consider when moving data centers: running

the old and new in parallel during some form of transition phase, or integrating

your existing equipment with the newer SDDC. The second, integrating

existing equipment within a single data center fabric, is not one, but two

answers: integrating at the pod level, or running the SDDC over the top of

existing equipment.

The first answer, running the old and new data centers in parallel, may seem

like the simpler -- even ideal -- case. But even in the ideal case, there are issues

to sort out. Will workloads be transitioned between the data centers? And if

so, how will this take place? Much of the answer to this question is going to

depend on the applications themselves, of course. There are several important

questions to ask in this area.

How well will the new data center fabric meet the requirements for each spe-

cific application? It’s important to take into consideration commonly consid-

ered issues, such as bandwidth utilization and delay and jitter requirements.

But it’s also important to consider the existence of such services as domain

name system, dynamic management of elephant flows, the creation of security

zones, overlay networks and other factors.


In this handbook:

Editor’s Letter




NETWORKING HANDBOOK

While a lot of problems related to services offered by the fabric can -- and

should -- be avoided in the design phase, there will always be some that are

missed. No inventory will ever be complete, at the very least, because few

application owners will know all the services their application relies on, or they

will make invalid assumptions in the process of performing such an inventory.

For these situations, there needs to be a clear action plan in place when mov-

ing data centers from Day 1.

It’s easy to assume every service can be supplied on the new fabric, but using

this as a planning baseline will often lead to very bad results. It’s better to

assume application owners will need to modify or update applications to work

around some of these problems, rather than throwing the entire weight of the

problem on the network engineering team.

APPLICATIONS WILL DETERMINE HOW DATA CENTERS ARE LINKED

During the time when the two fabrics are running in parallel, there will need

to be some form of connectivity between them -- a data center interconnect

(DCI). Application requirements are going to determine some of what this

DCI looks like, such as whether or not there needs to be an Ethernet-on-top


In this handbook:

Editor’s Letter




NETWORKING HANDBOOK

connection, or alternatively, a simpler-to-support IP, or routed, connection. The

challenges here are similar to the DCI challenges facing any other pair of data

centers, with the added restriction of what the SDDC system will support and

expect.

The second solution, integrating the SDDC and existing equipment at the pod

level, presents a different set of challenges. The idea is illustrated below.

If there is no need to connect data center fabrics for resilience -- not likely in

most modern networks -- this type of solution can remove one challenge from

the list above: DCI. Another advantage is it allows you to use canaries -- that is,

simulations -- to test your SDDC design approach for individual applications

over time. In this situation, a canary would involve running the two infrastruc-

tures in parallel, moving applications from the legacy foundation to the SDDC

to evaluate them, leaving them there if they appear to run correctly in the new

environment. This is actually how most hyper- and/or web-scale operators

transition to new infrastructures.

However, it adds a new element of complexity to consider: How will the SDDC

control plane interact with the existing control plane? Somehow, traffic must


In this handbook:

Editor’s Letter




NETWORKING HANDBOOK

be drawn from the newer SDDC pods into the legacy hardware and back again.

If there are few traffic engineering, security and other policy requirements,

this might be as simple as just redistributing routing information between the

two control planes. If moving data centers require the inclusion of security

zones that cross the two domains, or some form of dynamic traffic shaping,

the problems here can be very complex. The most likely situation is some form

of redistribution combined with manual or automated tuning along the edges

between the two operational zones.

Such arrangements tend to start simply, but they also tend to end complex,

consuming more resources than anticipated. It’s best, if this is the chosen

migration path, to push applications from one environment to the other as a

set. This approach reduces the depth and breadth of the interaction surface

between the two environments.

RUNNING THE SDDC AS OVERLAY NETWORK

The final option, mentioned in the opening paragraph of this section, is to run

the SDDC as an overlay on top of existing equipment. This is probably the most

common tactic sold by SDDC vendors, as it allows the SDDC to consume the


In this handbook:

Editor’s Letter




NETWORKING HANDBOOK

existing equipment into its control and management planes. This, too, can

appear to be a simple answer, but complexity can often play into the mix very

quickly.

The general idea is to use the power of the SDDC to replace legacy equip-

ment with new gear over time, using the capabilities of existing equipment as a

physical layer for the SDDC. This situation should be no different than the nor-

mal lifecycling of equipment over time in an SDDC environment. To that end,

the same tools and processes should be applicable from Day 1 until the day the

legacy equipment the SDDC is replacing is removed from service. But the initial

equipment mix cannot be as good of a match for the requirements of the SDDC

as any future purchases, potentially leading to several problems.

At the physical layer, will the equipment support the southbound interfaces

required by the SDDC? For instance, if the SDDC requires OpenFlow support

at a certain level, such as 1.3, to operate properly, does all the existing legacy

equipment support this level of operation? If the vendor claims support, has

it been tested? To know for certain, all the existing equipment must be revali-

dated for operation in the new environment.


In this handbook:

Editor’s Letter




NETWORKING HANDBOOK

At the control plane, how will the SDDC overlay interact with existing control

planes that tie the equipment together and draw traffic from one part of the

fabric to another? Can all the features of the existing control plane -- features

which tools and capabilities have been built around -- be integrated into the

SDDC overlay? This is a more difficult issue to resolve if the existing control

plane is some sort of fabric overlay designed to provide an API into the net-

work, rather than a collection of devices running a more traditional distributed

protocol -- such as IS-IS or Border Gateway Protocol.

MANAGEMENT APPROACHES ADD TO COMPLEXITY

The problems multiply when moving from the control to management. Each

device in the existing network is designed to be managed in a specific way.

Some may only have management information base interfaces; others may

only have command-line interfaces; others may have RESTful interfaces using

a set of YANG models; and, still, others might be best managed through a gRPC

interface.

Can the SDDC draw information from, and push configuration to, this wide

array of interfaces across all devices? What pieces of telemetry might you


In this handbook:

Editor’s Letter




NETWORKING HANDBOOK

gain, and what will you lose? This is another area that calls for extensive test-

ing and validation, especially against future requirements. Never count on “the

hardware will be replaced before we need that function” as an out. Think long

and hard about where your applications may bump up against the walls of lim-

ited functionality in the future, and what that means for your business.

A parallel concern is the ability to troubleshoot and resolve problems quickly

-- the mean time to repair a network is directly related to overall availability, a

crucial measure of the network’s effectiveness at supporting the business.

Telemetry, in this context, allows you to see the condition of the network, in

order to resolve problems before they affect operations, and to quickly find

problems that are affecting operations. It is important to examine current pro-

cesses used to quickly restore services against the capabilities of the SDDC

overlay to determine where there might be any gaps.

Perhaps the one piece of legacy gear that will be the most difficult to man-

age through an SDDC transition is the appliance-based firewall. While widely

deployed to create security zones within a fabric, and to separate zones within

the fabric from zones without, appliance-based firewalls are likely to be the

most difficult devices to effectively manage. Overlaying an SDDC on top of


In this handbook:

Editor’s Letter




NETWORKING HANDBOOK

existing equipment will challenge appliance-based firewalls with tunneling

encapsulations, dynamic policies and other issues that will be difficult to solve.

In the overlay model, security will need to be rethought entirely, including how

security zones will be migrated from existing appliance-based firewalls to

other techniques provided by the SDDC system itself.

Moving data centers to an SDDC can result in a cleaner network over time,

with many new options for building and managing a network at scale that

meets business needs. The intermediate steps required to transition existing

equipment to the SDDC environment, however, can be complex. Network

operators need to consider these challenges, and plan around them, carefully.

Documents

Your guide to embedding SDN in data centers, from start to ...cdn.ttgtmedia.com/searchNetworking/Downloads/Your... · 4 YOUR GUIDE TO EMBEDDING SDN IN DATA CENTERS, FROM START TO