Server consolidation and data center moves can deliver significant benefits – including cost savings, enhanced business continuity, optimized service management, and improved regulatory compliance.
The impact of this physical displacement should not be underestimated. If you don’t adequately understand and address the issues that arise when you put more physical distance between users and servers, you can set yourself up for serious pain and potential failure.
Here are four killer mistakes you should be particularly careful to avoid:
1) Confusing network latency with application latency
If moving your servers adds 50 milliseconds of network latency, that doesn’t mean that your application response times will only increase by 50 milliseconds. On the contrary, applications require many back-and-forth interactions between user and server (often referred to as application “turns"). So the addition of 50 milliseconds of network latency can cause an action that only took 3 seconds to complete locally to take 30 seconds to complete after a server move.
Network managers can’t change the speed of light, or make Tokyo closer to New York. So it doesn’t make sense to lay the problem entirely on them. In fact, because application design issues are often responsible for poor response times after a server move, additional investments in the network will be of little use whatsoever.
2) Failing to realize how network latency impacts server performance and scalability
Servers allocate resources to each client session and lock them up until the session is completed. Local clients complete their sessions quickly, because their application turns experience minimal network-related delay. Remote sessions take much longer to complete.
Thus, remote users keep the server’s resources busy for a longer period of time – preventing the server from releasing its resources for use by other clients and severely limiting its ability to scale. That’s why IT organizations should consider the possibility that network latency will require them to invest in additional server infrastructure.
3) Putting distance between servers – even temporarily – can crush performance
It can take weeks or months to complete a move to a new location. During interim stages, some systems will operate from their original locations while others will operate from the new location.
The impact this separation between servers has on application performance can be even more dramatic and unexpected than the introduction of latency between users and servers, because computing processes are almost never designed to accommodate significant inter-server latency.
Consider the following example of a credit application that authenticates users on an Active Directory (AD) server and accesses a database to validate customer credit scores:
1. Client accesses the credit application server (10 turns)
2. Credit application server authenticates client on the AD server (50 turns)
3. Credit application server gets credit data from database server (200 turns)
4. Client receives answer from the credit application server (5 turns)
Note that there aren’t many application turns between the client and the front-end credit application, but there are many turns between the servers. Thus, if distance between these servers is introduced during a move, there is likely to be a severe impact on application performance.
Any IT organization planning a data center move must therefore ask a variety of questions. What happens when servers with critical inter-dependencies are temporarily separated? Which servers must be moved with other servers? When should Active Directory servers be moved? Which servers will need to be replicated for the duration of the move?
4) Not dealing with users’ performance expectations until after the move
Sometimes, it doesn’t make sense to set a post-relocation Service Level Objective (SLO) that is identical to the SLO before the move. If it originally took a local user three seconds to execute a task, it is very unlikely that the task will take the same amount of time after servers are moved across the country. So an SLO of seven seconds, for example, may be more reasonable.
It’s therefore critical to address users’ service level expectations up front. If you wait until after the move and tell users they have to live with what you can deliver, you’re setting yourself up for a battle. But if you can get buy-in beforehand as part of the planning process, you can avoid such hassles and ensure that no one has unrealistic expectations.
To achieve this pre-relocation acceptance, IT must be able to predict and simulate post-relocation performance. These predictive and simulation capabilities enable IT to set up “acceptance environments" where users can experience post-relocation performance before the move is actually executed – and where they can buy into post-move SLOs before a single server is relocated.
Seven Steps for Project Success
IT organizations can avoid all of these mistakes. But to do so, they must leverage the expertise of the application team, systems managers and network architects. They also need to be able to create virtual models of both the pre- and post-relocation enterprise environment – as well as all transitional phases.
IT organizations can avoid all of these mistakes. But to do so, they must leverage the expertise of the application team, systems managers and network architects. They also need to be able to create virtual models of both the pre- and post-relocation enterprise environment – as well as all transitional phases.
The following seven-step plan highlights how collaboration and modeling can ensure the success of a data center move:
1. Build a virtual model of the pre- and post-relocation enterprise environment, as well as all planned transitional phases.
All participants in the planning process, including business users, need concrete information about how network infrastructure will impact application performance with the new data center.
2. Establish an SLO baseline by measuring application performance before the move.
Users’ needs and expectations don’t exist in a vacuum. Pre-move transaction response times provide essential context for determining reasonable SLOs for after the move.
3. Measure post-move application performance in a virtual environment.
The only way to accurately predict the impact of server moves on application performance is to run those applications in a fully simulated post-move environment. This will provide the specific data on potential performance degradations essential for proper planning.
4. Identify applications that need special performance tuning.
Rather than wasting time, effort and money on beefing up all elements of your enterprise infrastructure, focus instead on specific applications or network components that may be particularly problematic.
5. Assess dependencies between back-end servers to establish an appropriate move plan.
In addition to addressing network latencies between clients and servers, the team must fully understand the impact of latencies that may be created between servers during transitional stages of the move.
6. Analyze problems and validate potential fixes for failing applications.
Before investing in and deploying a solution, it’s important to make sure that it actually works. Assumptions about bandwidth or CPU power should always be tested before being executed in the production environment.
7. Manage user expectations and get buy-in commitments for performance improving investments through hands-on acceptance.
Users should therefore be given the opportunity to directly experience post-move application performance in advance, so they can offer informed consent to the relocation plan.
By following this seven-step plan, IT organizations can substantially reduce risk, eliminate unnecessary infrastructure spending, accelerate time-to-benefit, and overcome a wide range of potential political pitfalls. So if you’re planning a server consolidation or other type of data center move, consider investing in simulation technology that allows you to experiment with alternative scenarios and determine in advance what will work and what won’t. It’s a great way to ensure that your business reaps the full benefits of the move – without suffering any of its potentially disastrous consequences.
For this and other network performance articles, white papers, and industry resources, please visit Shunra at http://www.shunra.com/resource_center.aspx.
About Shunra
Shunra’s solutions empower organizations to address service level and performance concerns before rollout. The Shunra VE solution creates an exact replica of the production network environment, enabling IT professionals to safely develop, test and experiment with applications and infrastructure before deployment, and effectively plan for growth and change. Tailored for networking, performance and testing professionals, and software developers, Shunra VE facilitates collaboration across IT disciplines so IT organizations can quickly and more efficiently uncover and resolve problems before they impact the business. Over 1,500 leading enterprises and technology vendors worldwide are using Shunra’s award-winning solutions including 3M, Boeing, Cisco, Dow Chemical, EMC, FedEx, General Electric, General Motors, JPMorgan Chase, Kelly Services, Merrill Lynch, Motorola, Nestle, Pitney Bowes, and Vodafone. Shunra’s headquarters are located in New York City and Kfar Saba, Israel, with worldwide offices in the UK, Sweden and India. Shunra is also supported through a global network of channel partners.
