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.
|
