Cloud

Network emulation for the cloud

For those considering a move from the LAN to the public cloud, network emulation offers a new way to test performance.

What's going to happen to performance when your applications are moved from the beautifully smooth local LAN to the rough remote cloud? Are you planning on implementing VoIP, or some other kind of streaming data? You really need to know about jitter. What is jitter? And what else should you know?

When an enterprise starts a project to migrate from on-premise computing to the cloud, there is a lot of guesswork that must be rooted out. Every organization that takes on a migration project like this examines the price, virtualization, SLA, and support. Some work on application performance monitoring (APM). Very few organizations test their current network by degrading its performance.

Network emulation is beyond the capability of most enterprises so it usually doesn't get done. It's a little crazy to not test network conditions –Internet and WAN conditions can transform an app from everyone's workhorse to an unusable embarrassment. iTrinegy, an APM company in the UK and USA,  think you should create cloud conditions in your test system using a network emulator.

Getting rid of guesswork

The migration team can't just move everything over a weekend and hope it's all okay on Monday morning. How do they take the risk out of the migration? How do they test performance?

If there were fewer applications, the enterprise testers could run up a copy in the cloud and get some users to test it. That just won't work here – there are so many apps and they vary so much that trying to build them all, generate test traffic and get some meaningful results is way too expensive.  

The iTrinegy way

iTrinegy sell a range of cloud-in-a-box network emulators for testing. This isn't cloud v2.0 that's become popular this millennium – huge computing and storage resources available for rent. This is the classic cloud v1.0 – the one on network diagrams that means "all the other networking stuff". The network emulator lets you know what kind of performance you are going to get by transforming your network.

A network emulator, coupled with an APM appliance, replaces networking guesswork with real numbers. Here's an overview of the process.
  1. Plug an iTrinegy APM (Application Performance Monitoring) appliance into the local network.

  2. Monitor what is happening on the local network. Use expert knowledge to interpret the results.

  3. Find out how the new network will behave. Look at the Internet and talk to the new cloud provider.

  4. Plug an iTrinegy network emulator appliance into the network.

  5. Configure this network emulator to behave like the new network.

  6. Route traffic through it. Route all work through it, if you are feeling brave.

  7. Fix issues - change the bandwidth, re-factor the application or change the migration plan.

  8. Leave the APM box in place permanently to keep an eye on the network. This is a good way of checking the SLA, detecting problems, and profiling behaviour.

Some big companies follow the iTrinegy way, but most follow a traditional approach.

The traditional approach

  1. Migrate piece by piece. The first migration wave picks on a handful of applications that serve up web traffic to customers. The mission critical stuff and the databases all stay put for now.

  2. Prepare the paperwork. Check the cloud provider, the SLA, regulatory requirements, and support contract.

  3. Prepare the applications. All apps are checked against the 12 operational principles and all work in a virtual environment.  

  4. Estimate the extra network latency the remote data center will add.

  5. Test the latency (maybe). The administrators increase the local network latency to make sure the apps still work after migration to the cloud.

Everything is prepared. The first applications are migrated. It can't go wrong.

It went wrong. The applications are unusable. People are angry. Technicians get on the case. The network latency is way bigger than it should be. The Internet is not behaving like the LAN.

Things a network emulator does

A network emulator plays around with network characteristics like latency, packet loss, congestion, and jitter in the same way a complex network does. An emulator is programmed to behave like ship-to-shore satellite link, a WAN, or a cloud hosting provider.

Latency

You start with an estimate of latency.

  • Latency between New York and the next city may be 30 milliseconds.

  • Latency between New York and Ireland, travelling through a transatlantic fibre optic cable, may be much higher at 90ms.

  • Latency between New York and Ireland going via a satellite is a relatively huge 700ms.

This latency gets multiplied by the behaviour of an application, and each application behaves differently.

As an example, think about a classic two tier application – an application and a database server. A database-driven application causes network traffic while it works with its database. The application can be halfway across the world from the database if the app occasionally fetches a little customer data with a SQL statement -- users will not notice a delay. If this app builds everything from the style sheets to the menu items using database calls, users will be angry with their terrible response.

Lost packets

The Internet is not like the LAN. The request and response packets fly across the LAN so fast and so reliably it's like streaming data. Internet packets misbehave – they go missing, arrive in the wrong order and arrive in erratic bursts.

The TCP protocol that works so smoothly on a LAN causes problems over the Internet. It can see packet loss as the sign of a congested network and make everything slow down.  If acknowledgement messages don't arrive, it will request big chunks of data to be resent. If application traffic is is sent by radio over a 3G network, 10% of the packets may go missing.

Congestion

The third problem is congestion. Everyone has sat in a traffic jam. Everyone understands congestion. This problem is solved by throwing money at the telecoms provider for a bigger pipe.

Jitter

The clean digital world is still built on an analog electric world of waves. Network noise is just as annoying on a data network as it is on a car stereo. Jitter screws up the synchronizing mechanisms and messes with performance. Networking nerds should check out Recommendation G.810  from the ITU (International Telecommunications Union), where this standards body nailed down the definition of jitter.

It's early days for network emulation

It's a new idea and early adopters will pay a premium for network emulation devices and consultants. In a few years, when the use of network emulation has spread, IT testers will wonder how they managed without it.

This will have a secondary impact on which cloud provider is chosen by an enterprise. When it comes down to a choice between two cloud providers -- one which is secretive about its network but tells you its performance is great, and one which is transparent about its network so you can prove performance is adequate -- which one will you choose?



About

Nick Hardiman builds and maintains the infrastructure required to run Internet services. Nick deals with the lower layers of the Internet - the machines, networks, operating systems, and applications. Nick's job stops there, and he hands over to the ...

1 comments
daboochmeister
daboochmeister

There's very often plenty of ROI to justify such a solution. But you can also very cheaply roll your own network emulation with some careful planning and use of Linux VMs as IP proxies/gateways. Then employ traffic control (tc command) to vary the network conditions (introduce latency, jitter, packet loss). Throw in something like Nagios/Zenoss to track and graph statistics, and you can learn a lot.

Editor's Picks