WIXLIB

Best Practices for DataCenter Relocation:Manage Expectations and Get It Right the First TimeINTRODUCTION: THE PROMISEPacking up and moving the resources in yourAccording to the article, IDC saw the number ofdata center means uprooting the digital brain-data centers worldwide continuing to climb untiltrust and nervous system of the business. And,2015, when the number reached 8.55 million. Theit costs a lot. According to Info-Tech Researchworldwide number would decline to 8.4 millionGroup, “The average data center relocation costsin 2017, IDC predicted last year, and again to 7.2 120,000 or 10,000 per rack.”million by 2021.So why do we do it? The reasons are compellingThe same article quotes Mike Leone, senior analystand diverse:at Enterprise Strategy Group, explaining thatcurrent efforts focus on “not only reducing the Mergers & acquisitions Business continuityadoption to deliver a cloud-like experience on- Cyber securityeasier to manage, easier to scale, and do it all Virtualizationcost-effectively.” This goal signals a shift from Information Technology (IT) cost reductionlarge regional facilities to that of scaling down onand operational efficiencieshardware footprint, but accelerating virtualizationpremises” and making “it easier to virtualize,consolidating lots of smaller data centers intoreal estate and power costs through virtualization.With the potential upside both lasting and huge,Whatever the goal, delivering on the promise ofdata center consolidation continues as new trendsdata center relocation and consolidation entailstake hold. An article by Data Center Knowledge,moving resources from one place or platforma division of the Informa, cited several leadingto another. This process invariably involvesexperts offering their take on the future.significant risk, change, and apprehension among

users as well as IT teams, and can impact applicationsas well as servers, in critical ways: Local users may suddenly become remote users The user experience may suffer as application responsetimes increase due to longer round-trips to and fromservers Server performance, and in turn, application scalability,may be degraded as servers handle more remotetransactions that take longer to completeMitigate Risk, Meet ExpectationsThe key to side-stepping the pitfalls and realizing the promiseof data center relocation is to eliminate surprises and addresspotential issues beforehand. Doing so means: Baselining application performance prior to the move Modeling and measuring performance of the newinfrastructure before physically relocating Continuing to validate service levels post-migrationMigration to the cloud introduces new challenges forOngoing testing includes measuring network latency andvisibility, security, and complianceother impairments and their impact on applications, businessIn fact, 20-40% of applications will fail to meet service levelobjectives during or after a data center relocation, somewith severe issues that render the application unusable.Addressing service level issues upon migration may meanadditional changes to server systems and even the re-codingof applications – both of which add delay, risk, cost, andfrustration. But it doesn’t have to be that way.processes, and users. The insight derived from these activitiesalso serves to fuel better plans for handling data backup,replication, security, and data compliance.In this paper, we will focus squarely on best practicesfor predicting and maximizing application performancethroughout data center relocation to meet user expectationsand service level requirements out of the gate. To do so, adeeper understanding of the risks proves useful.WHAT GIVES RISE TO RISK?You budget. You plan. You execute—and watch for theEach application will be impacted differently dependingunknowns that can come to light at any time. The trick toon their unique sensitivity to latency based on things like:minimizing the risk impact of unknowns is to eliminate as Application chattiness: How many messages mustbe exchanged between the client and the server foreach transaction?Application performance/transaction times Blocking: How many turns can be processed in parallel?Moving servers to a new location obviously changes the Protocol configuration for both clients and servers(buffering, authentication, etc.)many as possible by modeling and thoroughly assessingthe “knowns.” Priority areas of risk avoidance include:means by which applications get delivered over the network.Users previously considered local to directories, domainservers and desktop services now become remote. Withservers now being accessed from a distance, transactionresponse times increase for everything from booting up andlogging in to sharing and storing large files or repositoriesCareful planning and modeling of individual applicationperformance in the new target environment should beconducted in the lab to prevent noticeable degradation ofthe user experience.of data.Server performanceNetwork and geographic latency created by the distanceDuring data center relocation or consolidation, serverssupporting a given number of local users may suddenlybecome accessible to many more remote users conductingslower transactions due to increased distance and networklatency. Web-based applications in particular may resultin exponentially more users performing low-bandwidthbetween clients and servers gets compounded by highernumbers of users transacting with servers remotely viawide area network (WAN) connections. To users, thenetwork latency manifests as application latencywhich manifests for IT as a rise in complaints andtrouble tickets.but high-latency processes.02

These higher volumes of transactions queuing up andtaking longer to complete hinder the performance andscalability of servers themselves. Because servers allocateand lock in resources for the duration of a transaction,added latency causes transactions to complete moreslowly, tying up more server resources for longer periodsof time. Higher volumes of in-flight transactions caneventually exceed a server’s capacity resulting in criticaltransactions or data being dropped.maintained in two places for an extended period of time.Simply throwing more CPU power at the problem,however, does little good. Subtle changes to processesscheduling may be required, and it may even makesense to explore the option of offloading processingintensive functions such as decryption/encryption todedicated appliances.The team must contend with issues arising from temporarylatencies between critical back-end systems as well asthose created by clients and servers being in differentplaces. Both scenarios can wreak havoc on applicationperformance, especially when server systems are notdesigned to accommodate latency.Once again, it is critical to model all of this in the labbeforehand because, once the move takes place, itbecomes harder to replicate and troubleshoot the specificconditions causing problems. Server capacity planningteams must model and test performance ahead of timeby simulating a realistic mix of local and remote usersrunning real applications. QA teams must also considerlatencies between users and servers more carefullyand in a new light to support optimal budgeting andresource allocation.Server groups and dependencies must be fully consideredin planning data center relocations to avoid costly, highlyvisible impairments of business processes.Finger-pointingWhile the classic reaction to poor application performanceis “blame the network,” application architects, developers,and quality assurance (QA) teams must also understandand design higher tolerance for latency into applications.Issues linked to subtle yet complex interactions betweenapplications, networks and infrastructure cannot beresolved by working in silos. Unprecedented collaborationmust happen between application owners, systemsmanagers and network architects.Careful planning and detailed “before” and “after” insightinto performance equips project managers to join forcesto meet corporate goals for performance, time to value,and return on investment (ROI) through data centerrelocation.Business continuityThe larger the center, the longer it might take to safelyand systematically move it. Centers containinghundreds or thousands of servers could takeweeks, months, or longer with systems beingThis interim stage means that relocation managers mustfactor in challenges around: Inter-dependencies on back-end systemstemporarily located in different places Maintaining (or splitting up) server groups Replication and backupService-level expectationsThe very idea of change often elicits a negative reaction,at least at first. Who wants to risk having things break,leak, or take longer, even temporarily, in hopes of realizinggains that seem to mainly benefit IT, or “corporate”? Whowants to go first and be the guinea pig for the inevitable“fine tuning”?Again, the surest way to assuage these very legitimatefears is with very clear data: How exactly will applications perform during andafter the move? How long will moving take? How much will usersbe inconvenienced during the transition and howgood will IT support be throughout? What might the downtime cost various businessgroups?Business concerns such as these can cause rollbacks,delays, and a predisposition to complain during and afterthe process. Being able to provide clear, reproducibledata showing exactly what the impact on users andapplications will be beforehand goes a long way inalleviating concerns, as well as meeting expectationsand demonstrating value to stakeholders. Even whenperformance trade-offs are necessary, the ability toproactively manage expectations will help prepareusers and may inspire better methods.03