William Hanna, vice president of technical services at the University of Pittsburgh Medical Center (UPMC), went out looking for a way to add capacity to a backup network and found what he wanted in Software Defined Networking (SDN) tools from Alcatel-Lucent. Network World Editor in Chief John Dix sat down with Hanna to learn about the process and experience.
Let’s start with a quick synopsis of your tech environment.
UPMC is an $11 billion per year healthcare payer and provider, so we have a health plan and we also provide care in Western Pennsylvania and internationally. We have approximately 450 remote sites, including 21 hospitals, and we support everything out of a couple data centers. We tie it all together with an MPLS core network that we run using about 150 carrier-grade MPLS routers — we’re in the process of replacing Alcatel-Lucent’s 7750 Platform to the 7950 SRX, which is their latest MPLS router — linked over multiple fiber rings, and then a WAN attaches to that.
We started doing virtualization with IBM on the AIX platform (very large pSeries machines) and VMware on the Intel side back in 2006, and now close to 90% of our hosts are virtualized. On the x86 side we buy IBM servers and each supports 60 to 80 operating system instances (either Windows or Linux) and we have more than 6,500 VMware instances across both data centers.
+ ALSO ON NETWORK WORLD 11 tips to prepare for SDN +
Our data center network architecture was based on the Cisco 6500 Platform, and then later the Nexus Platform. We’ve used Cisco equipment since the early ’90s. There’s nothing wrong with it, but we didn’t have a way to provision the network that was up to date with what was happening with server virtualization. To provision network connections – dealing with virtual LANs, IP addressing schemes, DNS and everything else — was taking two to three weeks. The laggard was truly the network itself. So that provisioning time was one of the things driving our interest in SDN.
So that’s where you started with SDN?
Actually the first SDN opportunity for us was when we needed to add capacity to our backup network as we were growing. The backup network is essentially a Layer 2 network that spans both data centers, and its sole purpose is backup. It’s very important, but that is all it does. Some of the Cisco and some of the Alcatel-Lucent Enterprise equipment on that network was nearing end-of-life, end-of-support, so we had to make new investments as we grew.
So, going back to our Alcatel-Lucent carrier-grade routers for a moment — we have enjoyed using their SROS operating system in the core network for some time. It’s very stable, and Nuage was created with a subset of the engineers that did SROS, and they came to us several years ago and said, “Hey, would you be interested in a product to put in your data center based on SROS that supports this thing called Software Defined Networking?” And so a little over a year ago we started getting pretty serious about this and running trials of Nuage in our test networks. We did a number of tests with bare metal servers and VMware to test out the principles of SDN, failover and provisioning and all of those things, and they all worked very well.
So when we needed to expand our backup network, we had already tested the Nuage product and we were comfortable with it, so we made an investment in Nuage to add capacity to that network. And that’s where we’re at right now.
How does it work?
The major components include a Nuage service directory, then Nuage spine and leaf network switches and what Nuage calls the virtual route switch, which is software that lives on a VMware host. In Stage One the early benefits will be added capacity and faster provisioning. With a spine and leaf architecture versus what we have today, you don’t just have one path carrying traffic, you have multiple paths, which gives you more capacity and makes it easier to scale up from there.
And then there are a lot of other things SDN will bring to the table. Everything from improving the provisioning process with a Graphical User Interface and scripting engine that takes the place of the engineer entering the device configuration line by line through CLI, to improving security with multi tenancy and improving quality-of-service. For quality of service today, you deal with capacity for traffic that’s going east-west within your data center between, say, database servers and application servers, by creating oversubscription models, and you make that ratio smaller and smaller and smaller. With SDN, we can provision the network and specify how much pipe to give it, with what priority, etc.
Then there are a lot of SDN benefits folks will have more appreciation for in the future, like spanning tree elimination. That’s a huge thing. We’re just at the beginning phase. We’re in the middle of rack and stack and we’ve done some initial testing. We have staff going through training, and the feedback so far is very, very positive.
You mentioned Stage One. Where do you go after that?
The next step, providing SDN does all they say it’s supposed to do, will be to essentially connect the Nuage infrastructure into our data center Cisco Nexus infrastructure. So, where that backup network was its own network before, we start to add capacity to the production network so it supports both backup and production.
So instead of two switching infrastructures and a routing infrastructure, now I’m going to have a single infrastructure that will run backup and production. It will attach to our Nexus environment for Layer 3 type decisions, and then talk to the rest of the network.
How far out is Phase Two?
I think it will probably start with the next big changeover in servers, which is probably July, August.
Did you look at any other SDN options other than Nuage?
We looked at other folks’ products, but we didn’t get to trials. We’re still opting to trial products from a couple of more manufacturers.
Do you think ultimately you’ll end up with a mix of different SDN approaches?
It is going to be interesting. I think where SDN is going next is into the WAN and eventually the campus. In the WAN, for example, you can get a small, non-MPLS-based router today for $2,500 to $5,000, and they are good routers, but they can’t pedal fast enough. They usually have a limit of anywhere between 20 to 25 megabits per second, and they’re not MPLS.
If you want to build your network with MPLS, you’re talking about three to four times the cost. So if someone came to you with a product which essentially would be an SDN MPLS product that could run on x86-based hardware and could support up to a gig worth of data with redundancy, you would be very interested.
If you had legacy-type T-1 connections it’s not going to solve that problem. But if you were looking at Ethernet service or using your own dark fiber service, that would be something that you would be interested in, which we are. And I know folks are going to come out with products like that.
Obviously Cisco is hell-bent on pushing its SDN vision, as is VMware, both of whom you partner with. Are they banging on your door trying to get in here and take you in a different direction?
We’ve had conversations with both. But at the time it was a question of, who’s shipping product? But we’ve watched the presentations, our architects and engineers have had discussions. They are certainly interesting. We have talked to Cisco about the Insieme product, and they’re more open-minded now, that’s for sure.
So just because you’ve gone this route to start, you’re not precluding picking up any of these other tools to supplement the network.
Never is a long time, right? That’s the way I look at it. We use the products that we need to meet the requirements. We have Juniper firewalls and we have Palo Alto next-generation firewalls. So we’re not a one-vendor shop.
SDN is going to be with us for a long time. It’s the biggest thing I’ve seen in networking in probably 20 years. I think we’re going to make people more efficient. We’re going to be able to do more work.
