A virtual migration
Frank Puranik of iTrinegy explains how network emulation helped Capita to virtualise its data centres.
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.”
