Capita Group has an on-going project to migrate computing services located in individual business data centres to Capita Business Services’ main data centre. Prior to this centralisation/consolidation most of the group’s applications had been delivered from a local data centre to the end-users via a LAN, but with the ongoing data centre migration programme these are now delivered across a WAN-based network.

The need for applications (often bespoke) to continue guaranteeing first class performance was a prerequisite. In migrating these applications, the servers they were running on were also scheduled to be virtualised to save on power, cooling and the cost of redundant server resources.

While it might have been possible to specify the use of Citrix or another thin client solution for end-user access in all cases, this would have been cost-prohibitive, as well as not being a panacea for all network related issues.

Steve Brankin, data centre transition & integration manager comments “We had a requirement to move all the related servers for the application to the new data centre at the same time and so we needed to understand any potential issues that may arise. For example we needed to understand and eliminate WAN requests for server to server communications which we felt could severely hamper our applications. The measurement of the entire server to client and server to server traffic is vital. It’s also very important for to us to know how much network load would be placed onto the WAN link from Capita Business Services’ main data centre to the individual business that was migrating.”

The solution needed to show how bandwidth availability and latency would impact the applications’ performance and also how much network load would be required on the physical servers which would be hosting the multiple virtual servers and their applications. A further major question needing to be answered was would the physical server NICs (network interface cards) have the capability to handle all the traffic?

 “While attending a Sun Virtualisation conference we came across iTrinegy,” says Brankin. “Two of their products seemed to answer our needs: one measured application performance while their network emulation technology allowed us to simulate the network prior to migration, and the use of both of these product sets was found to be essential in preventing costly fixes including failed migrations or overuse of expensive tools like Citrix.”

The solution was piloted on a data centre migration being performed from Capita Insurance Services in Salisbury to Capita Business Services main data centre in West Malling (a road distance of some 120 miles). There were several concerns with this project:

•             The application had been designed for delivery over the LAN – it was unclear how much WAN traffic would be generated or what size of WAN pipe would be required;

•             How would the WAN latency (a lowly 10ms) affect the application;

•             What response times could the users expect;

•             With some of the application being legacy there was no one available to provide a complete data flow analysis. Exactly what talked to what?

First AppQoS was used by Brankin’s team to rapidly determine all server-to-server and client-to-server connections being made by the application. This allowed Capita to determine that it had correctly identified all the services being used by the application servers including minor ‘gotchas’ such as systems incorrectly picking up time services (NTP), DNS etc from the ‘old’ site. This prevented repeating any errors in this area.

It also allowed Capita to gauge the total volume of network traffic flowing between all clients and the Tier 1 server as this would now be flowing over the WAN. This process allowed the identification of a potential problem. At certain times (logon in particular) a huge amount (several hundred Mbps) of traffic was flowing from clients to the server. The network links from Salisbury to West Malling were not that large – they might need upgrading or a lighter weight (in bandwidth terms) method of application access might be required.

“We used Network Emulator in the first instance to provide a moderate network experience of 10Mbps and 10ms latency (the latency from Salisbury to West Malling) for a member of the support team familiar with the application(s). It was as though the application had been moved to West Malling with the user still in Salisbury. Immediately, we found that logon times for the application went from 10-20 seconds to many minutes, which was completely unacceptable,” explains Brankin.

The team made use of the emulator’s real time network graphing functionality to see that the entire 10Mbps was being used up. This was with just one client whereas in the mornings a couple of hundred users logged on at approximately the same time in the real network.

They decided that it would be useful to experiment by ‘upgrading’ the bandwidth and with the network emulator it took just a few seconds to replicate a 1Gb link. The logon test was repeated and while it was still too slow, it also showed that much less than 100Mbps of the 1Gb link was being used.

iTrinegy explained that the application was now being constrained by the latency and no amount of increasing bandwidth, for example, using their circuit with 1Gb or better capacity would solve this for a single user, unless it also came with a huge latency reduction. It was clear that without a major re-design, to make this application work in the WAN they would require it to use a thin client like Citrix, RDP or SunRay, or make use of WAN acceleration technology (if this proved cost effective).

Capita used AppQoS which allowed it to quickly identify the WAN loading as well as the server NIC loading and also ensure that no stray time-critical server-server requests were still going across the WAN.

Using this AppQoS data as well as that obtained from the Network Emulator, effectively allowed Capita to ‘try out’ the migration for a community of users without actually doing it! This showed it that the application would not work (perform even reasonably) on the existing link and that adding bandwidth to solve the problem was a waste of money.

“We avoided a failed migration and understood that we would need to invest in thin client or WAN acceleration technologies to complete the task,” says Brankin. “All in all, it was a case of money very well spent, especially given that we could use the tools again on our ongoing migration/virtualisation projects and monitor the applications post migration with AppQoS too.”

“The tools were straightforward and we found the technical support excellent,” concludes Brankin. “Assisting on site, helping us to rapidly use the products as well as explaining network issues such as how applications that are ‘latency bound’ do not respond to increased bandwidth for single users, all proved invaluable to us. The tools were set up in a very short time and within one day we had the answers to the important issues in migrating and virtualising the application for the pilot site.”

www.itrinegy.com

These systems are great for reporting the state (or availability) of the infrastructure just like a service management dashboard. What they fail to show is how long a particular driver’s journey is going to take. And so it is again with service management dashboards. In essence, there is an obsession with availability which completely ignores the user experience: the journey.

When I first started out in the application performance monitoring space, the majority of tools developed were for monitoring systems and application availability from a server perspective, using tools such as Tivoli, BMC Patrol, and Microsoft MOM etc. Later, products like HP Openview would monitor network devices, displaying maps showing “red lights” when there was an issue. Sound familiar?

While these tools were great at telling you whether or not an application, server or network component was available, they didn’t help you understand the user’s experience of accessing and using that application.

And as we recognize today, service management is not just about how available the technology is but making sure the customer is happy with their experience of it. An application or service can be showing on the monitoring panel as being 100 percent available but responding so slowly as to be regarded as being unavailable as far as the user is concerned. At best, this could be regarded as an annoyance but if application performance is really poor there are productivity implications for the end-user organisation and possibly financial penalties for the service management provider. Indeed, even for ‘internal’ applications poor performance simply leads to non-use.

Add to this, a move to datacentre consolidation/virtualisation, cloud computing, branch office initiatives and home service applications and you will find more and more applications today are expected to run across WANs, Satellite, 3G, GPRS, WiFi etc and this adds a very significant extra dimension to the far simpler problem of internal monitoring of application performance and availability. After all, before the external network arrived most of the factors in application delivery, number of users, server capability (CPU, Memory, Disk…) were understood and controlled. Now it’s like making a journey from Manchester to London – how long will it take? Who knows?

I remember the software industry entering into the uncontrolled world of network delivery of their applications under guises such as application service provider (ASP) or on-demand software and later renamed SaaS (software as a service). Generally these were supported by the service industry in the form of ‘hosting’. Equally, companies may have decided to externally ‘host’ some of their applications. Both imply a network (usually WAN, sometimes Internet) delivery of the application with all the uncertainty that brings.

Now we have cloud computing which is fundamentally SaaS, platform as a service (PaaS) and infrastructure as a service (IaaS). All will be ‘hosted’ and delivered over networks as uncontrolled as the Internet. This is an important marketplace with estimated market revenue in the USA of over $4 billion. If you are in doubt about this brave new world, look at the success of salesforce.com.

So, companies today are looking for more from their service management providers. There are more mobile applications needed for remote workers, to be delivered on mobile devices. It has been estimated that more than 52 percent of corporate workforces are now working outside of headquartered offices and so there is an increasing need to guarantee the performance of applications no matter what devices are being deployed. Recent adverts for the iPhone bear witness to this trend with an increasing number of business-oriented applications being made available on this device.

Unfortunately, there is a whole world of difference between how an application runs in a LAN and how it runs over the WAN, satellite, mobile 3G/GPRS networks etc and it’s not just about increasing bandwidth in the event of performance problem as ISPs would have you believe. There are other important factors such as latency (delay), losses and congestion in the ISPs core network or in the client end of the network and the service management providers need to have a focus on this.

Networked applications are very much at the ‘Core’ of the things we do every day, both professionally and personally. Examples include accessing our bank accounts online, booking travel tickets, social networking (Facebook), accessing web-based CRM systems such as Salesforce, controlling traffic lights, modern IP based public CCTV, and smart phone applications. So, keeping tabs on the performance of networked applications is just as essential in service management as it is to the end user.

So, from being of negligible interest network performance must now rank with the other major system resources of CPU, Memory, Disk I/O and storage. It’s the least controllable too, so at the very least we must make it visible and understandable.

While solutions already exist that enable service providers and IT departments to understand application quality of service and response times, typically these have been large, appliance-based systems that are prohibitively expensive. Some designs are centred on network protocol analysers or ‘packet sniffers’ that capture huge quantities of data, some of it commercially sensitive, and much of it irrelevant to pinpointing and resolving service availability problems. So what’s the answer?

Recognizing the cost-conscious times we operate in, one possible solution is AppQoS Live! This is an example of a networked applications monitoring solution that can be readily accessed, is easy to use and can be deployed on any modern server or even laptops and PCs, without the need for installation. It enables any IT specialist or consultant to investigate issues such as: application usage; application response time; network performance; and quality of service, all in real time.

It initially starts delivering information regarding application response times, transfer rates, bandwidth usage, etc, from a ‘satellite’ level perspective but then allows its users to drill down in order provide detailed analysis of the root cause of the poor performance. For example, it can help determine:

•             Whether it is a network or server issue;

•             Whether the application really is performing badly / worse than normal;

•             Who is effected (single or multiple users);

•             Where in the network the problem exists;

•             What is running over the network;

•             Whether other applications or traffic types are responsible;

•             Is the other traffic relevant or undesirable;

•             What other requests are being issued to the server.

When placed into a rack mount server, laptop, or PC, the software transforms it into a powerful application monitoring appliance. There is no need to install any software and the operating system (Windows, Linux, Unix etc) or other applications on the host machine are not impacted in any way.

Next, this system would be plugged into the network segment of interest and with no configuration, would provide concise, organised and easy-to understand views of key network activity data within minutes. Data gathered would be stored in a folder on any existing hard drive or on other writeable or flash media such a USB stick or SD card. This data could be exported for inclusion in reports, presentations etc. If it is no longer needed, it is simply removed from the host machine which then can be used for other activities.

The real benefit is that there is no need for a dedicated appliance in order to achieve sophisticated networked applications monitoring, so significant savings can be achieved. You can choose the hardware (within limits) from your regular suppliers. At the same time, on the portable front, having a team of consultants equipped with copies of the CD also means they can respond rapidly when service level issues arise, rather than waiting for the right appliance to be set up or re-configured. As a result, it should be possible to resolve issues more efficiently, leading to improved customer satisfaction levels.

If you’re offering any kind of hosted, centralised or managed service then managing the service in a cost-effective way is important. Solutions like AppQoS Live! allow for greater utilisation of the standard hardware you have invested. At the same time, the issue of dedicated hardware appliance obsolescence is completely overcome. This coupled with the substantially lower acquisition cost, less hardware management costs, lower training costs and ease of deployment, amount to a substantially lower TCO and hence a greater ROI than alternative and proprietary hardware based appliances, a real win for anyone offering a service where networked applications are part of the equation.

www.itrinegy.com