Original URL: https://www.theregister.com/2013/11/17/services_fuel_data_centre_evolution/

Services fuel the next generation data centre

It's more than just boxes

By Dave Cartwright

Posted in Systems, 17th November 2013 20:00 GMT

In its basic form, a data centre is just a big room full of cages and cabinets, with highly reliable power, efficient security, fire and flood protection and a variety of internal and external network connectivity.

In recent years providers have tried to differentiate their offerings but there is not really that much you can do to dress up what is basically a big noisy room. So for “cold aisle technology”, for instance, read “we have improved the airflow a bit”.

How, then, can data centres evolve into anything better? Simple: if there is not much you can do with the environment, develop what you can do in that environment and what you can connect it to.

Keep it private

If you are a data centre provider with multiple premises, you have the opportunity to provide high-speed physical links between locations.

Giving your customers the ability to extend their LAN between premises has huge benefits for their disaster recovery strategies and capabilities: with a low-latency physical Gigabit Ethernet link between your premises you can do real replication.

If your data centres are not close to each other, though, point-to-point links are too costly. One alternative is to look at a layer 3 offering – managed MPLS services are ten-a-penny these days.

The emerging concept, though, is the virtual private LAN service, or VPLS. This is a virtualised layer 2 service – think of it as a virtual LAN switch in the cloud, into which you can plumb your endpoints.

VPLS is less well known but the concept has been around for some time. Just as we now have the word “cloud” to refer to managed services that we have had for years, the idea of a virtual layer 2 service came along long before most of us (myself included) had heard of VPLS.

Back in 2009, for example, PacketExchange (now part of GT-T) was offering me the ability to have a VLAN connecting my data centre in Jersey to my data centre in India, another connecting Jersey to the London office, another providing a “dirty” internet service, and so on.

The trouble with layer 2

There is, of course, a fundamental problem with VPLS. In fact, on reflection, there are two.

The first is that if layer 2 were a good way to do wide area networking (WAN), we wouldn't bother with layer 3 in any of our WAN applications. Layer 2 is brilliant when you want to connect A to B in a point-to-point sense because it gives a native connection to the endpoints that looks just like they are plugged into the same LAN switch.

Move a box to the other end of the link, plug it in, and it will still work (as long as you have not broken your database mirroring by messing up the latency figures, of course).

The big problem with layer 2 networks is broadcast domains. A layer 2 network or VLAN is a single broadcast domain, and if you suddenly connect five distant things together via VPLS you have made yourself a great big broadcast domain whose traffic levels grow exponentially as you introduce new nodes.

Connect three offices at 10Mbps and two data centres at 100Mbps (a fairy typical starting point) without enough thought, and a broadcast storm on a data centre edge port will wipe out your offices' connectivity. Not great.

So what you will end up doing is putting in layer 3 transit networks to control the traffic flowing over the VPLS network and restrict wide area layer 2 operations to the devices that really need to talk natively at layer 2 to their distant counterparts.

And if you are thinking this is a slightly odd approach, so did I, so I checked it out with someone who works with VPLS networks. “Yup, that's how I'd do it,” he said.

The second issue is that a VPLS service will, by its nature, operate over some kind of layer 3 (IP/MPLS) network. So in the scenario above you are running layer 3 on a layer 2 tunnel that is established through a layer 3 network, which sits on top of layer 2 technologies.

So yes, it may well be slower than just having a boring old MPLS network in the first place.

Service included

A quick re-cap: we have said that the way forward for data centre evolution revolves around VPLS, but that VPLS isn't actually good for very much.

In fact, VPLS is only a bad choice if you are trying to shoehorn it into a traditional network model. If you use it for the cool things it can provide, it is perfect.

We said earlier that we can't make the data centre do much more than be a data centre, and that the opportunity for evolution is what you can do with it and what you can hook it into. Services are the answer, so let's set up an example scenario.

You have a data centre and customers A and B both have their kit there. Each has a point-to-point link from its office into the data centre.

Like many data centres you don't provide internet connectivity yourself but instead have three pet internet providers – let's call them X, Y and Z – with presentations in your telco room. Each of your customers signs up to one of them for its internet service and you patch it into the right ISP with an Ethernet cross-connect. All very traditional.

Nothing has changed so far as either customer is concerned, except perhaps to add a millisecond to the round trip time

Now let's flex this and introduce VPLS. You define two virtual private switches, one for each customer, in your VPLS network. You break client A's point-to-point link and instead connect its office and data centre cabinets into A's virtual switch.

You do a similar thing with B. Then you do the same with the internet cross-connects. Nothing has really changed so far as either customer is concerned, except perhaps to add a millisecond or two to the office-to-data-centre round trip time and perhaps asking them to change their switch port presentation from Access to Trunk and enable a couple of VLANs.

The clients cannot see or trample over each other's data (they are virtual private switches, after all) and all is well.

By hook or by crook

All pretty pointless thus far, but now you start introducing value-add services and you invite service providers to do the same in your data centre, either on their own account or via a white-label agreement.

So you introduce your own managed backup service, third-party P brings a CRM offering, party Q runs up a virtual desktop service and maybe you run up a direct connection into Amazon Web Services (very easy to do).

How do you hook your customers into these services? Easy: you present each on a different VLAN. Customer A wants your backup service, you light up the right VLAN on its virtual switch. Customer B wants Amazon Web Services connectivity, you light up its VLAN on its virtual switch.

If you are thinking “but I could do that at layer 3”, yes, you could – with a big “but”. If you are a customer with a backup service being presented to you at layer 2, and you are running a virtualised infrastructure, all you need to do is introduce the new backup VLAN into your virtual infrastructure.

Then you can back up natively from your virtual servers to the backup server without having to kill your own layer 3 routers – the backup runs entirely at layer 2.

Similarly if a customer has layer 2 connectivity from its office to provider Q's desktop service and wants to do maintenance on its data centre switches, it can do so without affecting its desktop users. The customer’s own kit is not involved in getting the traffic from office to virtual desktop.

Oh, and want to introduce your own cloud server solution and persuade client B to move to it? No problem: present the right VLANs, configure the virtual server architecture right and plan it properly and you can achieve a zero-downtime migration.

And of course when provider R brings along its virtualised telephony service, you can light up the right VLANs to allow customer A's virtual desktops to talk to provider R's virtual PBX and throw desktop popups by looking up caller ID against the customer's own Exchange server.

Make the connection

Data centre evolution is initially all about services. Some data centres I have come across have known this for a long time. In fact I have known providers whose entire raison d'être is to sell services; they are almost reluctant to rent rack space and do so only because the customer demands it. Others have continued to simply be big, noisy, low-risk rooms.

More than this, though, data centre evolution is about connectivity to services. Yes, you can achieve a lot using layer 3 networking, but the VPLS model makes service provision an order of magnitude more flexible and quicker to market.

It also means you and your clients don't end up with routing tables that would frighten Medusa's hairdresser. With some sensible use of virtual NAT firewalls on your part and on the part of your third parties, you can easily deal with IP range clashes and the like.

Most importantly, when you have done your five-minute service setup process by lighting up a VLAN, you can enjoy the benefits of having two distant devices talking at layer 2. You can let your customers talk to your services without having to send high-volume (replication, backup and so on) traffic through their routers.

Even better, though, more and more telcos are cranking up VPLS services. So, data centre owners, you have no excuse. ®