Data Center Migration

eBook
A Successful Data Center Migration

- Cradle to Grave
Given the dynamic operational environment in which todays data centers
operate, wherein applications and data in the production environment is
changing consistently and is being replicated to a remote DR facility on a
regular basis, it becomes even more important to look at all the facets of the
IT environment and carefully carve the Data Center migration strategy.
This document exhibits an end to end approach to successfully migrate
large data center environments to meet regulatory requirements / realize cost
efficiencies / improve availability & recoverability of business IT services.
Apr 2009
2 | Infosys eBook
Table of Contents
1 Introduction 4
1.1 Executive Summary 4
2 Data Center Migration - Key Drivers 4
2.1 Scenario A Regulatory Requirements 4
2.2 Scenario B Multiple Regional Data Centers 5
2.3 cenario C Obsolete Data Center Facilities Infrastructure 5
2.4 Scenario D Legacy IT infrastructure 6
2.5 Scenario E Fully utilized, out of Capacity 6
2.6 Scenario F Merger / De-merger 6
2.7 Scenario G Hybrid 7
3 Application & Infrastructure Analysis Source Data Center 8
3.1 Application & Infrastructure Contacts 8
3.2 Application Profile 8
3.3 Infrastructure Profile 9
3.4 Application Interdependencies 11
3.5 Current Facilities Profile 11
4 Business Service Reviews (BSR) 12
4.1 Why do we need to conduct BSR? 12
4.2 Application - Recovery Point Objective 14
4.3 Application - Availability Objective 14
4.4 pplication - Recovery Time Objective 15
4.5 High Level Cost estimation 16
4.5.1 ecurring Expenses 16
4.5.2 One-Time Expenses 16
5 Application & Infrastructure Design Target Data Center 17
5.1 Core Infrastructure Design 17
5.2 Enterprise Shared Services Design 19
5.3 Application Re-Architecture As needed 19
5.4 Selection of Deployment Model / Patterns Infrastructure Perspective 20
5.4.1 Active-passive failover: 20
5.4.2 Active-active failover: 20
5.4.3 Load balancing 21
5.5 Application specific Infrastructure Design 22
5.5.1 Individual Servers & Databases Associated with an application 23
Infosys eBook | 3
5.5.2 Virtualization / Consolidation Assessment of Servers 23
5.5.3 Application specific software requirements 25
5.5.4 Application specific appliances 26
5.5.5 Application specific LAN/ WAN & Third Party network connectivity requirements 26
5.5.6 Security Requirements 26
5.5.7 Network Performance / Latency Sensitivity assessment 27
5.5.8 Application specific External Storage & Backup requirements 27
5.5.9 Client software needed to access Enterprise shared services 28
5.6 Facilities Requirements / Design 28
6 Move Plans 29
6.1 Application & Infrastructure Interdependencies 29
6.2 ime Zone Dependencies 30
6.3 Create Move Bundle Packages 30
6.3.1 Move Build Package Template (Illustrative) 31
6.3.2 Application Build Package template (Illustrative) 31
6.4 Update Disaster Recovery Plans 32
6.5 Create Detailed Implementation plan 32
6.6 Regulatory Considerations 34
6.7 Enterprise Contractual considerations 35
7 Build Applications & Infrastructure - Target Data Center 35
7.1 Core Infrastructure & Shared Services Build & Readiness Testing 35
7.2 Pilot Applications Build & Test 36
7.3 Build Move Bundle Packages 36
7.4 Test Move Bundle Packages 37
7.4.1 Unit Testing 37
7.4.2 Shared Infrastructure Testing 37
7.4.3 System Integration Testing Move Group level 37
7.4.4 System Integration Testing Program level 38
7.5 Typical Risks, Challenges & Mitigation options Build & Test Phase 38
8 Roll out & decommission 38
8.1 Rollout / Cutover applications to Target Data Center 39
8.2 Decommissioning Source Data Center Hardware 40
9 Appendix 41
9.1 Virtualization Candidacy Criteria (Illustrative) 41
9.2 Acronyms & Glossary 43
9.3 References: 44
4 | Infosys eBook
1 Introduction
1.1 Executive Summary
Business decisions to migrate data centers can be as a result of IT cost reduction initiative, regulatory requirement, business
service risk mitigation plan, a newer data center operations strategy, or other legacy data center environments incapable of
hosting modern & dense IT infrastructure. Among the biggest risks organizations face when transitioning their Data Center
is migrating IT systems and applications. A data center migration is a highly strategic project that must be executed without
impacting business operations, Service Level Agreements, performance/availability and data protection requirements. Given
the dynamic operational environment in which todays data centers operate, wherein applications and data in the production
environment is changing consistently and is being replicated to a remote DR facility on a regular basis, it becomes even more
important to look at all the facets of the IT environment and carefully carve the Data Center migration strategy.
Every environment has its own challenges and one migration strategy does not fit every client environment.
The bottom line consideration for a good migration strategy is near-zero disruption of business services. This objective drives
a deeper & thorough understanding of following major subsystems of a data center.
Nature & Criticality of Applications that cater to different business services
Servers, Shared hosting environments, Databases that host the applications or service logic.
Network that provides the access & security to information within Intranet, from Internet and VPNs.
Finally, most applications require disk storage for storing data and the amount of disk space and the frequency of
access varies greatly between different services/applications.
Performance & Service levels requirements.
By necessity, moving or migrating services from one data center to another need to consider all of these components. The
level & effort for such due diligence is based on the current Data Centers application and Infrastructure portfolio, tolerance
to unavailability of applications & services as well as time & budget constraints.
2 Data Center Migration - Key Drivers
Below are some of the commonly seen Business-IT situations that trigger a Data Center Migration initiative. Beginning next
section, we will understand a generic data center migration process flow that applies to most of the scenarios discussed in this
section. However the level of focus in a specific area will differ based on scenario being addressed.
2.1 Scenario A Regulatory Requirements
Scenario A Regulatory Requirements
Existing Production & Disaster Recovery Data Centers are in same seismic zone / are in proximity to each other. Regulators
mandate an out-of-region recoverability capability for mission critical applications.
Key Considerations Relocate DR instance of all mission critical applications to another data center in a different
seismic zone.
Ensure that availability and recoverability of the applications is not impacted in transition
Ensure that all interdependent applications are able to communicate with each other in view of
mission critical applications being relocated while others being retained.
Ensure optimal costs are incurred on Hardware, Software & Labor by making smart decisions
on :
Hardware & Software re-usability
Appropriate program phases to minimize bubble period
Utilization of appropriate tools & technologies
Processes & best practices
Deploying right resources
Infosys eBook | 5
2.2 Scenario B Multiple Regional Data Centers
Scenario B Multiple Regional Data Centers
Multiple regional data centers exist in the current state, lacking standardization, efficiencies & growth scalability & unable
to meet end to end Service level objectives.
Key Considerations
Build-out a state of the art Dual / Multiple site Data Center environment that meets required
levels of resiliency and data protection
Migrate all common type of business IT processes & Infrastructure services that serve the entire
or most part of enterprise, to a Resilient Enterprise data center model. Retain (if needed), only
the unique functionality in the regional data centers that is required specific to a region. e.g.
A newspaper publishing company may want to keep all local news feeds to its regional data
center but rely on Enterprise Data Center for all Shared and Core Services
on :
2.3 Scenario C Obsolete Data Center Facilities Infrastructure
Scenario C Obsolete Data Center Facilities Infrastructure
Existing production / DR / both data centers have obsolete facilities infrastructure either in terms of high power
consumption, a large chunk of legacy / unsupported equipment, or poor availability benchmarks
(Option A) (Option B)
Key Considerations
To build-out a new data center with state-
of the art facilities infrastructure while
maintaining current data center environment
Migrate applications to newly built data
center
Depending on the size & criticality
of current data center infrastructure,
temporarily move applications to a
hosting environment and upgrade facilities
infrastructure of the existing data center
Relocate applications from hosted
environment back to the upgraded data
center infrastructure.
on :
6 | Infosys eBook
2.4 Scenario D Legacy IT infrastructure
Scenario D Legacy IT infrastructure
Existing data center IT infrastructure is legacy & most of the Hardware & Software is nearing end-of support. Moreover,
current IT infrastructure is inefficient, space taxing, and does not integrate well with modern applications and technologies.
This scenario is generally seen in combination with other scenarios.
Key Considerations
Redesign and /or Rebuild applications on modern hardware and software technologies.
Adopt virtualization & consolidation technologies, Enterprise Shared Services Model
Mitigate any data integrity challenges while migrating to modern infrastructure
on:
2.5 Scenario E Fully utilized, out of Capacity
Scenario E Fully utilized, Out of Capacity
Current data center floor space is nearly 100% utilized, needs optimization to enable growth capabilities
Key Considerations /
Drivers
Consolidate and virtualize IT infrastructure
Re-visit facilities infrastructure to ensure it is capable of providing power and cooling to high
density IT infrastructure
Free up Rack Space & facilities
on:
2.6 Scenario F Merger / De-merger
Scenario F - Merger / De-Merger
Merger / De-merger of two organizations driving a newer data center strategy for the merged / split entity.
Drivers
Application & Infrastructure technologies selection for the merged entity
Data Center Strategy for Infrastructure consolidation / separation & standardization
Build-out of Data Center Facilities in-line with new strategy
Migration and relocation of infrastructure to align with new data center strategy
on:
Infosys eBook | 7
2.7 Scenario G Hybrid
Scenario G Hybrid
Hybrid Scenario This may be a combination of one or more scenarios discussed above
Drivers
This may be a combination of one or more key considerations discussed above
Hybrid Data Center Migration (Scenario A & D)
So, we have seen that there can be multiple drivers that trigger a data center migration initiative. Data Center Migration
methodology discussed further in this document is based on an experience with a Hybrid situation (Scenario A & D above)
In view of this understanding, the scope of Data Center Migration consists of following broader steps. We will understand
each of these in much deeper detail as we follow:
1. Application & Infrastructure Analysis / Design
a. Source Data Center environment (From where Applications & Infrastructure needs to be migrated)
b. Business Service Reviews (Capture Target Service level objectives, IT budgets)
c. Target Data Center Infrastructure Planning & Design (where Applications & Infrastructure would reside finally)
2. Move Plans
d. Migration options (Build New Hardware at Target Data Center./ Forklift or Truck Hardware from Source to Target
Data Center / Interim Build to swing Hardware to Target Data Center)
e. Create Move Bundle & Application Build Packages
3. Build & Test Applications & Infrastructure
4. Roll-out Applications at Target Data Center
5. Decommission Source Data Center Infrastructure
f. Cutover users to Target Data Center
g. Shutdown / Clean up corresponding source Data Center components
8 | Infosys eBook
3 Application & Infrastructure Analysis Source Data Center
It appears as if moving / building infrastructure at target data center is predominantly about planning hardware infrastructure.
However, in order to ensure that business services are not disrupted in an unplanned fashion, a detailed application &
infrastructure assessment is needed. The purpose of Application & Infrastructure Analysis of Source Data Center environment
is to create a document package for each application, with sufficient understanding about current IT footprint. Further, based
on current environments understanding & other dependencies discussed later in this document, evolve a target state design
to be implemented at new data center. This includes, but not limited to:
Key contacts for an application (Application Manager, Technology Delivery Manager, and System Administrator,
Business continuity Manager, Architects etc.)
Number & Type of Hardware devices (Servers, Network, Storage, and Security) deployed
Number & type of Operating Systems, business & Enterprise software services deployed
Shared hosting environments and shared database environments deployed
Obsolete Hardware & Software Services that need to be refreshed along with Migration
Existing Availability, Recovery Time & Recovery Point objectives of each application
Architectural information, Physical and Logical diagrams exhibiting an applications deployment & geographical foot
prints.
Information on application & infrastructure interdependencies and affinities to assist in grouping Applications into
move bundles.
Current Service levels, Change Windows, Production issues.
3.1 Application & Infrastructure Contacts
In a dynamic IT environment, role and responsibilities of various resources keeps changing based on Business & IT
requirements. During the initial assessment phase of each application it is important to capture the names of all up-to-
date stakeholders that will enable in key decisions pertaining to application & infrastructure architecture & IT service
management considerations for data center migration. Large enterprises maintain an inventory called Application Portfolio
Management that generally maintains application profile & key contacts information. Below table illustrates useful set of
information about key stakeholders for an application. These contacts will need to be interviewed for target state design
activities, build and test planning activities & to seek sign-off of end of phase activities of the program.
Application ID Application
Name
Line of Business Contact Type Contact Name Email Contact #
3.2 Application Profile
The objective of capturing basic profile of each application is understand certain key parameters such as criticality of
application, primary business area served, tolerance for downtime, time-zone sensitivity etc. of each application. This profile
helps in
Prioritizing & scheduling application analysis design & build activities, breakdown of program into smaller, more
manageable work packages.
Optimizing co-ordination effort by grouping Application Analysis, Design & Build activities that fall under common
stakeholders
Applying a common set of guiding principles, processes, procedure, testing methods for applications that meet a
common set of criteria e.g. all applications with X RTO or Y of AO to be dealt in a specific manner.
Infosys eBook | 9
Below table illustrates some of the key business service parameters for an application that would be helpful in further
due-diligence
Particular Description
App ID Unique Application Identifier
App Name Name of the Application
App Description Brief description about the application
App Type Software only or Software w /hardware
App Environment Mainframe / Distributed / both
L.O.B Primary Business Area Served
Risk Rating High / Medium / Low based on criticality
Current RTO Existing Recovery Time Objectives
Current RPO Existing Recovery Point Objectives
Current AO Existing Availability Objectives
SLA Service level agreement (if any)
Status Dev / Prod / Obsolete
Weekend Down Time Weekend change window for planned activities
Max Down Time Max. no. of hours available in a given change window
Time zone Sensitive Is Application time zone sensitive? (Applicable if target data center is in a different Time Zone)
Sunset Date Planned retirement / sunset date for the application (if any)
Shared Environment Dependent Shared hosting environment (if any)
Dependent Shared databases (if any)
3.3 Infrastructure Profile
The objective of capturing infrastructure profile of each application is to
Understand the size and complexity of applications physical environment
Geographical foot print
Type of hardware and software that has been deployed
Any unique security & appliance requirements
Dependency of Enterprise Shared Infrastructure
External Vendor communication dependencies
10 | Infosys eBook
Below table illustrates some of the key infrastructure parameters an application that would be helpful in further due-diligence
for Data Center Migration.
App Databases
Database instance
Database name
Database Role (Production / DR / Test / Dev)
Database Server Hostname
Database Vendor (Oracle / SQL / Sybase etc.)
Appliances
Appliance Category (Shared / Dedicated)
Appliance Name (e.g. Data Power, Security devices etc.)
Appliance Type (Facilities / Network / Security etc.)
Appliance Vendor, Model
Individual Servers
Hardware Model
Hardware Vendor
Hostname
Local Disk size
Location (City, Rack location etc.)
No. of CPUs
OS Type (Linux, Unix, Windows etc.)
OS Version
RAM
Server DR Partner Hostname (if any)
Server HA cluster Partner (if any)
Server Role (Test / Dev / Production / DR)
Server Type (Web / App / DB)
Virtualization status (Virtualized / Not virtualized)
Network
Any other specific network hardware solely deployed for the application
Associated Security Zone (if any)
IP address
Network Traffic volume (Low / Medium / High)
Third Party Circuit Details
Shared Databases Brief description about the dependent Shared Database
Shared Servers
Location (City, Rack location etc.)
Shared Server / Hosting environment name
Software
Number of licenses
Software Name
Software Role (Backup / Monitoring / Remote connection etc.)
Software Vendor & Version
Storage
Any other specific storage hardware solely deployed for the application
Backup Type (Tape / Disk-to-Disk / DAS)
External SAN storage size (if any)
Local Disk Size
Replication Type (synchronous / asynchronous)
Storage Tier (if Hierarchical storage exists)
Infosys eBook | 11
3.4 Application Interdependencies
Todays complex application architectures interface with large number of other Enterprise & business applications. Migrating
complete / partial application infrastructure to another data center does not only need a due-diligence from all the facets of
application in question, but also need a thorough assessment of its impact to other interfacing applications. This analysis
would assist in first understanding the existing interdependencies and then in evolving appropriate Move Bundles. Some
Applications may be able to tolerate the unavailability of some non-critical interdependencies during migration window.
However many other critical interfaces such as Real time business critical data processing may require that such applications
be bundled together for the purpose of migration.
Following table illustrates some of the critical parameters to assess Application Interdependencies:
Interface Name Name of the interface
Related Application Unique Application Identifier of the interfacing Application
Initiator Application / Bound Application
Description A brief description of the interface
Direction Direction of dependency (Inbound / Outbound / Both)
Layer Making Connection Web / Application / Database Layer
Latency Sensitivity Yes (If tolerance is < 50 ms, No if tolerance is > 50 ms)
Protocol HTTP / SOAP / NDM / FTP etc.
Bind Environment Specify if dependency exist with Mainframe / distributed / both component /s. (Applicable if
Applications have both Mainframe and distributed components.)
Frequency of Access Daily Batch, Real-time, Adhoc etc.
Tolerance for unavailability Can process without impact / Can process with impact / cannot process at all
Integration Type Provides Information & Support to / Receives information & depends on / Is a component
of
3.5 Current Facilities Profile
In order to plan the capacity & nature of facilities environment needed in the target data center viz. Floor Space, Number
& Type of Racks, Power, Power Distribution system, Network & Storage Cabling, Air-conditioning systems etc. it is
important to conduct an assessment of source data center facilities infrastructure. The utilization and pain points (if any)
in existing facilities will provide meaningful data to plan capacity, distribution & design of target data center facilities. A
mapping between the IT Infrastructure profile (hardware devices deployed), allocated facilities capacity, utilization patterns,
Assessment of past outages, shortcomings provides information about:
Total Allocated UPS power, % utilization (peak & average)
Battery backup time
BTUs of Heat dissipated by different hardware
Distribution pattern of dissipated heat based on Server rack layout and hardware mounted in each rack.
Any hot spots needing extra cooling, suction of heat / redistribution of hardware dissipating heat to racks where
enough cooling is available etc.
Any issues with cooling distribution such as Air flow blockages / Low Air pressure
Energy consumption patterns
Handling capacity of PDUs, % utilization
Any Single points of failure
Any capacity bottlenecks
12 | Infosys eBook
4 Business Service Reviews (BSR)
It is very important to understand the service level expectations defined by business to ensure that all Data Center Migration
Planning, Build & Test work is base lined in view of the same.
4.1 Why do we need to conduct BSR?
Business Service Reviews are intended to seek answers to following illustrative questions so that most appropriate / cost
effective Service level objectives are defined / agreed at.
What level of availability does your business require?
How much data is the business willing to lose in a catastrophic event?
How will you mitigate data loss?
How much revenue will be lost or additional expenses incurred by an unscheduled system outage for different
durations (i.e. 10 minutes, half hour, one hour, etc.)?
Is this financial impact more likely to be felt during certain peak processing times? If so, what are the peak periods?
What hard processing commitments do we have to external agencies or trading partners that are critical?
What is your customers tolerance for this service not being available?
What reputation risk or regulatory consequences are at stake for certain processing commitments?
Business Partners should be educated to appropriately gauge the target state Service Level objectives for their Business
Services. Following concepts about availability and recoverability should be made clear before seeking these Service level
objectives.
Availability is different from Disaster Recovery.
Availability provides for recovery from localized routine or non-routine events, with potential end-user impact.
Disaster Recovery involves recovery between data centers following catastrophic/extraordinary events, with certain
end-user impact from a disruption in service.
The business lens used for what would be reasonable to accept in a true disaster (Recoverability) has no relevance in
normal processing (Availability).
Recoverability has both a technology and business operations component
The technology will recover the application to the RPO and then the individual business unit will need to recover lost
transactions.
Application interdependencies will need to be clearly understood to accurately assign both the AO and RPO.
Infosys eBook | 13
Exhibit A below demonstrates differences between Availability & Recoverability.
Based on this understanding, the ultimate goal of this exercise is to capture RPO, AO & RTO values for the target state so
that Application & Infrastructure design activities can be based on these business requirements. In the next section we will
understand the definitions of these Service level objectives and how typically these objectives are classified in an organization.
14 | Infosys eBook
4.2 Application - Recovery Point Objective
Recovery Point Objective (RPO) is defined as the maximum amount of active transaction data, expressed in units of time,
which may be irretrievably lost before a disaster event in order to meet business requirements. Some applications can handle
up to 24 hours or more of data loss in the event of a true disaster, while others require near zero data loss.
Below table illustrates how typically Recoverability Objectives are defined for each application. These will be utilized while
defining the target state and further in Bundling of Applications for creating move groups.
RPO Typical Use Notes
A - Up to 15 minutes of data loss
(Target: 15 minutes)
Transaction Processing Applications RPO standard for critical
applications
Minimal data loss via hardware
based data replication solutions
B - greater than 15 min and less than
24 hours (Targets: 1 hour, 4 hours, 8
hours, or 16 hours)
Data Warehouses Intra-day snapshots or platform-
specific data replication solutions
Target data loss of less than
24 hours
C - Equal to or greater than 24 hours of
data loss (Targets: 24 hours or 48 hours)
Departmental Applications RPO Standard for non-critical
Applications Impact - up to 2
business days of data loss
X - Not Applicable Pass-Through applications Applications do not store any
business data, database, or file
structures
Z - Near Zero data loss Third- Party custom solution, e.g. Wire
Transfer System
Custom IT solution
Requires completing Exception
Process for approval
4.3 Application - Availability Objective
Availability Objective (AO) is defined as the ability of a component or service to perform its required function at a stated
instant or over a stated period of time. In determining the most appropriate/cost effective Availability Objective, the following
business considerations must be addressed:
How much revenue will be lost or additional expenses incurred by an unscheduled system outage for different
durations (i.e. 10 minutes, half hour, one hour, etc.)?
Is this financial impact more likely to be felt during certain peak processing times? If so, what are the peak periods?
What hard processing commitments do we have to external agencies or rading partners that are critical
(i.e. Fed deadline or Balance Reporting)?
What is your customers tolerance for this service not being available?
What reputation risk or regulatory consequences are at stake for certain processing commitments
Infosys eBook | 15
Below table illustrates how typically Availability Objectives are defined for each application. These will be utilized while
defining the target state and further in Bundling of Applications for creating move groups.
App Category Overall Service
Availability
Peak Service
Availability
Scheduled
Service Outage
Service
Restoration
Targeted
Solution
Business Need
Objective
Platinum Greater then
99.95%
Monthly
Availability
(22 minutes
/ month
unavailable)
100% Monthly
Availability
(zero minutes
/ month
unavailable)
No scheduled
outages
(changes can
be made w/o
customer
impact)
2 minutes
to restore
application /
service
2 completely
independent
Production
environments
Used for
Extremely
Time Critical
Products or
Services.
Gold Between 99.9%
- 99.95%
Monthly
Availability
(44 minutes
/ month
unavailable)
99.95%
Monthly
Availability
(22 minutes
/ month
unavailable)
Infrequently
scheduled
outages (ex
quarterly)
1 hour
to restore
application /
service
Fully
redundant
Production
environment
with no single
points of failure
Used for Highly
Time Critical
Products or
Services
Silver Between
99.5% - 99.9%
Monthly
Availability
(3.65 hours
/ month
unavailable)
99.9% Monthly
Availability
(44 minutes
/ month
unavailable)
Regularly
scheduled
outages
(ex monthly)
2 hours
to restore
application /
service
Partially
redundant
Production
environment
with some
single points of
failure
Used for
Important
Products or
Services that
need Intraday
Support
Bronze Between
99.0% - 99.5%
Monthly
Availability (7.3
hours / month
unavailable)
99.5% Monthly
Availability
(3.65 hours
/ month
unavailable)
Regularly
scheduled
outages (ex
monthly)
6 hours
to restore
application /
service
Single
Production
environment
with no
redundancy
Used for
Products or
Services that
are not Intraday
Time Critical
4.4 Application - Recovery Time Objective
Recovery Time Objectives (RTO) represents the expectations of how much time can elapse after a business interruption until
the process or application needs to be restored. Typically, the Business Continuity Planning Group works with partners in
the lines of business and technology to ensure each system/application has an RTO assigned reflective of the criticality of the
business services delivered.
Depending on the level of RTOs, appropriate technologies, processes, roles and responsibilities are laid to ensure that
applications / business services can recover from a disaster in a given time frame. E.g. in table below, an RTO 1 (i.e. lowest in
criticality from RTO standpoint) may require only a warm / cold DR and thereby save energy, rack space maintenance costs.
In such cases, sufficient time is available to make technology & configuration changes to turn warm / cold DR infrastructure
into production without compromising on RTO objectives. Similarly, an RTO 5 application is deemed as a critical application
with a very little time to recover from a disaster. Applications with RTO 5 may need a hot DR with automated failover
technologies in place since no human intervention is expected to recover such mission critical applications from a disaster.
16 | Infosys eBook
RTO Duration (Tolerable Time to Recover)
RTO 5 0 - 4:59 hours
RTO 4 5 - 24:59 hours
RTO 3 25 - 72:59 hours (1-3 days)
RTO 2 73 168 hours (4-7 days)
RTO 1 Greater than 168 hours (more than 1 week)
So, the Availability and Recoverability objectives for an application drive the mechanisms to be put in place to ensure that
business services supported on that application are being provisioned as per expectations and to prevent outages. Selection
of appropriate technologies to meet these service level objectives has been discussed further in the target state design process
where deployment patterns are explained in detail.
4.5 High Level Cost estimation
The cost discussion in Business Service Reviews (BSR) is needed to set expectations on what sort of changes in cost the
business can expect to see based on the target data center configuration. This is also necessary to support decision making
around the appropriate Availability and Recovery objectives.
The Availability & Recoverability objectives defined by business translate to the level of High Availability & Data Protection
technologies to be implemented on Servers, Network & Storage environment. Therefore, Enterprises generally attach
standard costs on the basis of type of hardware, selected Availability & Recoverability objectives for planning purposes.
At this point in the program we are not aiming for actual Bill of Material / target state costs as those will be assessed towards
the end of Target State Application & Infrastructure design. The objective to undergo this high level estimation is to ensure
that business understands:
Selecting a higher AO, RPO, and RTO values for the target state would translate to a certain standard cost levels
If business wants to revisit selected service level objectives, they are prompted to do so before proceeding with detailed
Application & Infrastructure Design activities for target state.
Seek sign-off prior to detailed target state design.
In general, key components of Cost Data are described as below:
4.5.1 Recurring Expenses
Illustrative Expenses that business would see as recurring, as a result of Data Center Migration include:
Data retention and recovery
Server support
Network chargebacks
Server system administration chargebacks
4.5.2 One-Time Expenses
Illustrative Expenses that business would see as one-time, as a result of Data Center Migration include:
Approximate cost of new servers, and other hardware associated with new data center configuration
Approximate cost of the Data Center Migration Move project and associated application testing.
Infosys eBook | 17
5 Application & Infrastructure Design Target Data Center
Application & Infrastructure design for the target state is based on multiple parameters such as business defined service
level objectives, Enterprise IT Hardware & Software standards, opportunities for Infrastructure optimization, Data Center
efficiencies and reduction in IT costs.
In general, Target Application & Infrastructure Architecture is designed keeping in mind:
Current & Target Availability, Recovery Time & Recovery Point Objectives
Status of Applications (Development, Production, Sunset, Obsolete etc.)
Retiring Hardware & Software requiring technology refresh
Dependencies on Shared Hosting environments / Shared Databases.
Storage requirements
Virtualization & Consolidation opportunities
Existing single points of failure
Capacity, Performance & Scalability requirements
Network & Security requirements
External Vendor communication requirements
Supported Vendor products & technologies
Latency Sensitivity Analysis (in view of revised network routes connecting to Target Data Center)
Target State Application & Infrastructure design would consist of following components that are discussed further in detail as
we follow:
Design Layer Description
Core Infrastructure Layer
Target Data Center Facilities requirements (Space, Power, Cooling, Cabling etc.)
Target Data Center Rack Layout
Core Network, Security & Storage Infrastructure design
Shared Services Layer Enterprise Shared Services (Authentication, Shared Databases, Messaging, Internet,
Monitoring & Management systems etc.)
Application Layer
Application Architecture at target state (in view of capacity, scalability, BSR expectations)
Individual Application specific Hardware, Software requirements
Definition of Deployment
Patterns
Selection of appropriate technologies to ensure Availability, Data protection at Target Data
Center in-line with BSR expectations)
5.1 Core Infrastructure Design
Assessment of the Source Data Center environment carried out earlier provides all the necessary high level indications to the
scale, size, and type of hardware that will be built / moved to the target data center. Although, a detailed application level
design is not available at this point in the program, the design and build out of Core Infrastructure layer needs to occur in
parallel / prior to the actual application Infrastructure build, for obvious reasons. For capacity planning purposes, current
state analysis along with all known considerations would help in estimation of:
Number of racks of each category based on power ratings / cooling requirements / physical size of hardware to be
deployed
Power & Cooling requirement based on expected number of Servers, Network & Storage devices to be hosted in the
target data center.
Type & capacity of network & security hardware to be deployed
Overlaying technologies to be deployed
SAN / NAS / DAS / Backup Hardware & technologies to be deployed
18 | Infosys eBook
Enterprise Technology standards are followed in creating a skeleton of Infrastructure layer such as standard hardware, Core
Distribution Access framework for aggregation & Distribution of Network & Storage traffic, deployment of security zones
to host different applications / services in a systematic fashion, setup of Monitoring & Management framework to enable pro-
active monitoring, troubleshooting and administration of Core infrastructure.
Core Infrastructure is not only designed to accommodate the present IT requirements, but also to accommodate business
growth projections of the enterprise in the near future. So, Core Infrastructure should be flexible, modular, scalable &
capable of meeting varying service level objectives defined by business for different applications.
Below is an illustrative exhibit showing Core Infrastructure components.
Infosys eBook | 19
5.2 Enterprise Shared Services Design
Enterprise shared services serve as common service infrastructure for all the other business applications of the organization.
As, a large number of applications utilize enterprise shared services for their full functionality, it is logical to design and
build them prior to actual application migration e.g. Authentication, Authorization, DNS, Messaging, Monitoring, Antivirus,
Security Services etc.
Following are some of the parameters that should considered while planning the capacity of shared services infrastructure at
target data center.
Enterprise vision on selection of Shared Services technologies to be deployed at the target data center
Number of Intranet / Internet / VPN users accessing different shared services in the source data center
Expected number of Intranet / Internet / VPN users accessing these shared services in the target data center (based on
growth trends)
Expected Differences in IT workload on various systems & associated hardware & software sizing.
Number of network hosts / mailboxes / backup clients / security zones / DNS zones etc. needed in the target data
center based on Applications & Business Services being migrated to the target data center.
Geographical locations from where shared services at target data center will be accessed, performance requirements
thereof.
Any additional shared services that can enhance the value to services offered by business should be considered in the
target state architecture.
Criticality of Shared Services planned to be offered to serve business needs. These services should be evaluated
for appropriate Service Level Objectives (AO, RPO, RTOs). So that, their resiliency & data protection is planned
accordingly.
Explore opportunities to conduct a technology refresh in the target state if any of the Shared Services at Source Data
Center are running on near End of Life Hardware / Software.
Network, Server, Storage & Database Monitoring requirements in the target data center.
Shared Database requirements (e.g. Oracle Grid, SQL cluster etc.)
Shared hosting requirements (e.g. Shared Web / Application Server farms)
5.3 Application Re-Architecture As needed
Re-architecture of certain applications is needed on a case to case basis. Based on the current state analysis of certain
Applications, it may be need to make revisions to their logical architecture. Some of the illustrative reasons are:
End of life of associated Hardware / Software / both.
Consolidation of applications for cost optimization
Rationalization & Consolidation of databases / Business application logic e.g. reduced individual application related
database instances and moving towards utilization of Shared Databases / Application hosting farms.
Feature Upgrades to cater new business scenarios
OS / DB Platform Migration requirements e.g. Mainframe to Distributed or DB2 to Oracle etc.
Changes to application interdependencies in target state that pose an impact on application architecture
New security requirements in the target state data center .e.g. Enterprise strategy might enforce maintaining
Application & DB Servers in different Tiers based on certain parameters in Application profile.
Any latency intolerance with other dependent applications triggering an architectural change to mitigate the same.
Requirements to adhere to any new Enterprise Standards in the target state.
20 | Infosys eBook
5.4 Selection of Deployment Model / Patterns Infrastructure Perspective
Generally, large enterprises follow certain guiding principles to categorize level of redundancy, reliability & data protection
to its physical deployment. These guiding principles enable a standard way of deploying applications in a data center
configuration. Moreover, these patterns help for a better co-ordination between IT and Business in terms of identifying what
infrastructure IT needs to provision in order to provide a certain grade of service to the business users.
From a data center migration standpoint, selection of deployment patterns may be needed to either enhance or optimize the
infrastructure implementation in the target state. e.g. in the source data center if a lower criticality RTO / RPO application
has been deployed with unnecessary redundancies, there may be a potential to optimize the infrastructure deployment in
the target state. Similarly, if the current business conditions require an upgrade to RTO / RPO of an application, it may mean
deployment of additional availability infrastructure or implementation of other technologies to facilitate quicker data retrieval
/ better performance / zero human intervention / elimination of any other points of failure etc.
Service Level Objectives defined by the business & Application-level design principles need to be applied to databases,
messaging servers, application servers, web servers, and nearly any other type of workload. The deployment architecture
should consider the High Availability requirements (based on Availability objectives) and Data protection requirements (based
on the Recovery Point and Recovery Time Objectives). As a result, three popular deployment patterns can be derived:
Active-Passive failover
Active-Active failover
Load Balanced
5.4.1 Active-passive failover:
This model works for nearly all application types, including databases, application servers, web servers, and messaging
servers. Cluster management software (such as Microsoft Cluster Service or VERITAS Cluster Server) detects either a software
or hardware failure on one node in the cluster and starts that workload on the idle node, allocating the failed nodes IP
address to the takeover node.
5.4.2 Active-active failover:
This model also works for nearly all application types, since it is essentially just a variation on the active-passive failover
model above. All nodes in the cluster are running applications, with enough reserve capacity across all of them to take over
workloads from a failed node. Cluster management software monitors all nodes and services in the cluster and enables for
migration of services from failed nodes to active nodes. As with active-passive failover, applications that maintain state with a
client application or end user will lose any data not committed to disk at the time of failure.
Infosys eBook | 21
Refer to below illustrative high availability patterns.
h. Active Server at Production & Active / Passive at DR site
i. Active Server Cluster at Production & Active / Passive Server Cluster at DR site
5.4.3 Load balancing
This model works for both stateless and stateful applications and can be used for web servers, application servers, messaging
servers, database servers, and software developed in-house. Although load balancing may not always be feasible, where it can
be implemented it provides a very high level of resiliency, performance, and can also provide a point-of-presence advantage
for some applications.
Stateless applications
Multiple nodes in a cluster run the same application. Load balancing can be easily implemented at the network layer.
Stateful applications without session state replication
Affinity must be maintained between a particular client and a particular host in the cluster for the duration of the session.
This can be done at the network layer with specially configured load balancers, or at the application layer.
a. Load Balancing between Production & DR servers in two data centers
22 | Infosys eBook
b. Load Balancing between Production & DR Server Clusters in two data centers
5.5 Application specific Infrastructure Design
At this point, we are ready to design application specific infrastructure requirements. Following list describes the various
components that need to be looked at to evolve an applications infrastructure architecture:
Logical Application Architecture
Physical deployment architecture in the source data center
Appropriate Physical Deployment Model for the target state
Individual Servers & Databases Associated with an application
Application specific software requirements
Application specific appliances
Application specific LAN/ WAN & Third Party network connectivity requirements
Network Performance / Latency Sensitivity assessment (This will help in feasibility assessment / impact analysis &
mitigation planning for moving an application from source to target data center)
Application specific External Storage & Backup requirements
Any client software needed on application specific servers to access Enterprise shared services
Infosys eBook | 23
Type of information that should be captured for each of the above mentioned infrastructure components are explained in
further detail as follows:
5.5.1 Individual Servers & Databases Associated with an application
Particular Source Data Center Target Data Center
Host Name <current hostname> <Target hostname>
Location <Source Server location> <Target Server location>
Vendor <Current Hardware Vendor> <Target Hardware Vendor>
Model <Current Hardware Model> <Target Hardware Model>
RAM Allocated capacity (GB) Planned capacity (GB)
CPU Type RISC / INTEL RISC / INTEL
CPU Count <count> <count>
Server Class UNIX / Linux / Windows UNIX / Linux / Windows
Server General Class Size Large / Medium / Small Large / Medium / Small
Migration Type Not Applicable Retain as at Source Data Center /
Virtualization Status Already exists / Not virtualized Retain as at Source / cannot virtualize / To
be virtualized
In Secured Zone? No / <Name of Zone> No / <Name of Zone>
Belongs to a Shared environment No / <Name of environment> No / <Name of environment>
HA Model Active-Active / Active - Passive / Load
Balanced
Active-Active / Active - Passive / Load
Balanced
Server HA Cluster Partner Hostname /s Hostname /s
DR Model Active-Active / Active - Passive Active-Active / Active - Passive
Server DR Partner Hostname Hostname
DR Partner Location Location Location
Devices Attached Printer, CD writer etc. Printer, CD writer etc.
CPU Speed <in Giga Hertz> <Proposed in Giga Hertz>
Operating System OS with version Target OS with version
Server Role Test / Dev / Prod / DR Target server role <Test / Dev / Prod / DR>
Above table shows the details of information pertaining to servers in the source data center & a similar disposition needed
against the same in the target data center. Once the application architecture for target state is designed, logical & physical
diagrams are created, details about servers in the target state will need to be defined.
5.5.2 Virtualization / Consolidation Assessment of Servers
Virtualization & Consolidation offer substantial benefits to Enterprises in terms of Infrastructure & Data Center Space
optimization & thereby reduction of IT costs. Below are some the key benefits:
Reduction in
server and related infrastructure footprint in the data center
server management and maintenance costs
server delivery time & thus a higher level of business agility
OS licensing requirements
Costs by delivering high availability and failover capabilities to a broader scope of servers
Maximizes / Optimizes
Infrastructure and server utilization
standardization of DR
24 | Infosys eBook
Provides
servers with complete hardware independence and allow to move, migrate or upgrade servers with the least possible
risk
Increased consistency with device driver configuration which can simplify upgrades and migrations.
Centralized capacity management and planning
delegation of certain functions, while allowing for effortless delegation of administration for the virtual machines
themselves
However, a careful consideration is necessary to arrive at a decision on whether a particular server should be built on a
physical server or in a virtualized / consolidated environment. Following are some of the objectives that should be kept in
mind while conducting an assessment on virtualization candidates.
Avoid negative performance impacts to an application
Maximize performance-per-watt.
Simplify disaster recovery processes.
Improve recoverability of all applications to be migrated to virtual servers.
Maintain availability levels of all applications.
Enable faster provisioning and re-provisioning of applications on virtual machines.
Assess the effort required to migrate a typical server to a virtual instance.
If needed, conduct a preliminary testing to ensure compatibility & performance of an Application
Applications which can be migrated to a shared environment (Shared App Farm, Shared Databases, Hosting
environments etc.) should be migrated to those environments instead of migrating to virtual servers where it allows for
better utilization, performance, or cost.
Each organization follows its own Enterprise standards & considers virtualization as a right option for a certain set of
Databases / Operating systems etc. based on the maturity level and support infrastructure in place. Below chart provides
general guidelines on which I/O subsystems are utilized by the various server types. Utilization statistics based on Server
Type & I/O systems enables decisions around their anticipated suitability from Infrastructure standpoint. After Virtualization
assessment from Infrastructure perspective, Applications residing on this infrastructure need to be assessed for their
compatibility / Vendor support.
Server Type I/O Subsystems Anticipated Suitability Examples
Web Server CPU, Network HIGH IIS, Apache
File and Print Server Disk, Network HIGH Windows 2003 FP, SMS Dist. Point
Database Server Disk, Memory, CPU*
(*indicative of an issue)
MEDIUM
Note: Additional DBMS
consolidation methodologies
exist
SQL, DB2, UDB
Transactional Server CPU, Network, Memory MEDIUM to HIGH
Note: Suitability is
dependent upon the
applications utilization
patterns
MQ, Widows Domain Controller,
MOM, DNS, DHCP,
Terminal/Citrix
Server
CPU, Memory MEDIUM, dependent
on concurrent users and
dependent on the application
footprint
MS Terminal Services and Citrix
Presentation server
Utility/
Administration
Server
Memory HIGH MQ Admin Tool, Tivoli
configuration Management server
Application Server CPU, Memory, Network,
Disk
MEDIUM Anti-Virus, Websphere, Messaging,
DB Reporting, Patch Deployment,
SMS
Infosys eBook | 25
Based on the guidelines for preliminary assessment mentioned above & detailed virtualization assessment criteria at
Appendix A, a metrics score can be arrived at, to quantify the potential virtualization candidates as Good / Likely / Possible /
Not Possible (as discussed below).
Good Candidate
A good score in all metrics associated with the candidate server reflects infrastructure resource usage well within the
virtualization target server capabilities. Candidate server is considered a viable virtualization candidate as per the
infrastructure analysis review. Further Application teams confirm that vendor support is available on the virtual instance &
no performance issues are anticipated. Some scenarios may need a pilot testing to arrive at conclusion.
Likely Candidate
A likely score in any of the metrics for this candidate reflects greater infrastructure resource requirements for the server but
the candidate server is still considered a viable virtualization candidate per the infrastructure analysis. Further Application
teams confirm that vendor support is available on the virtual instance & no performance issues are anticipated. Some
scenarios may need a pilot testing to arrive at conclusion.
Possible Candidate
A possible score in any of the metrics for this candidate reflects greater infrastructure resource requirements beyond present
virtualization capabilities, and thus the server is not considered a viable virtualization candidate at this time. However, vendor
supports the application on virtual instance but there may still be a remote possibility to virtualize it.
Not a good candidate
Neither performance metrics reflect this candidate as a viable virtualization candidate from Infrastructure analysis standpoint,
nor does vendor support the application on virtual instance. This is not a good candidate for virtualization
Finally Likely and Possible candidates go through some level proof of concept or a deeper dive assessment to confirm their
candidacies as Good or Not Good candidates.
5.5.3 Application specific software requirements
An application requires different pieces of software to be installed once basic installation of Hardware/OS is completed.
Some of these software components may be industry standard off the shelf products while others may be in-house developed
software applications developed to meet specific business requirements.
Following are three commonly seen categories of software:
Business Application e.g. (Core Banking / Brokerage / Liquidity Management / Reporting etc.)
Monitoring Software (Database / Network / Server Monitoring etc.)
Infrastructure Software (Backup / Terminal Services / Citrix / .NET / Oracle etc.)
Below table illustrates typical information needed about each software, in the target state.
Particular Remarks
Software ID (if any) Unique Software Identifier
Software Name <Software Name>
Software Version / Service Pack <Software version>
Software Description <Description>
Software Vendor <Vendor Name> / in-house
Software Category <Application / Monitoring / Infrastructure>
Number of licenses (as applicable) <count /CPU or no. of users etc.>
Associated Server /s <hostname /s>
Number of instances needed <count>
Business Criticality on Software Low / Medium / High
Responsible Party Application Team / Infrastructure Team / Third Party
26 | Infosys eBook
5.5.4 Application specific appliances
An application may require specific appliances to be installed for its overall functionality. Some of the devices that may fall
in this category are Application Protection Devices (APS), Data Power, Dedicated Network / SAN switch modules etc. that
are not covered in Enterprise Infrastructure. Following table briefly describes the type of appliance related information that
should be assessed for the target state of an application.
Following table briefly describes the type of appliance related information that should be assessed for the target state of an
application.
Particular Remarks
Appliance Name <Name of appliance>
Vendor / Manufacturer Name <Name>
Appliance Type <Security / Facilities / Network / Storage>
Appliance Category <Shared / Dedicated>
Business Criticality on Appliance Low / Medium / High
Responsible Party Application Team / Infrastructure Team / Third Party
5.5.5 Application specific LAN/ WAN & Third Party network connectivity requirements
Network requirements are an important piece of information that needs to be captured during target state design of an
application, to ensure that application is accessible by all desired users / customers. Below table describes typical network
related information that needs to be defined for the target state of an application.
Particular Remarks
Network Diagram for Application <Physical & Logical Diagram>
DNS requirements <Zone / Domain & Sub domain Name>, <IP Address>
IP addresses for all hosts of application <A.B.C.D>, <hostname>
Static Routes needed <specify the routes>
Third Party Circuits <Circuit ID>, <Bandwidth>, <From - To>
Load Balancing requirements <Global Server Load Balancing / Local Server Load Balancing etc>
Virtual LAN requirements < No. & Type of VLANs needed> (if any)
Application specific network monitoring (if any) < Bandwidth utilization / Network Performance / Network Availability
to application etc.>
5.5.6 Security Requirements
Security requirements are important to secure the application against any potential threats to fraudulent / intrusion activities
& to ensure that different types of users are granted access based on their profile and business model in place.
Below table describes typical security related information that needs to be defined for the target state of an application.
Particular Remarks
Firewall Rules <Source IP addresses>
<Destination IP addresses>
<TCP/UDP ports>
<Access Permit / Deny>
User / Employee Access Requirements User / Employee IDs
Access requirement - From Intranet <Permitted Zones / Locations / User Groups / Domains>
Access requirement - From Internet <Permitted Zones / Locations / User Groups / Domains>
Firewall / IDS logs <Rules to be logged>
Infosys eBook | 27
5.5.7 Network Performance / Latency Sensitivity assessment
In many data center migration scenarios, latency between the production & DR sites changes because of the revised distance
between new locations. In cases, where latency / round trip delay between production & DR sites increase, there is a need
to evaluate its impact to all applications. Individual application specific mitigation plans will need to be created if any
application poses intolerance to increased latency.
Below table show some important performance information that should be assessed for an application & its associated servers
to ensure that due considerations have been made in this regard.
Particular Remarks
Latency sensitive hosts <hostname>
Hosts with High data transfer rate Source & Destination Host IP addresses
Estimated Average Load <MB/sec>
Estimated Peak Load (MB/sec) <MB/sec>
Any additional Week / Month / Year end load <Amount of load on network>
Peak Time of the day <hh:mm>
Peak Day of the week <Mon-Sun>
5.5.8 Application specific External Storage & Backup requirements
Any external storage requirements (not on physical disks of associated servers) needs to be defined so that Enterprise Storage
Infrastructure team can ensure that SAN/NAS/Tape library infrastructure have sufficient capacity on disk arrays / switch
fabrics etc., to accommodate the requirements of an application.
Below table illustrates typical information that needs to be captured to enable Storage Infrastructure Engineering teams in
necessary planning & design.
Particular Remarks
External Storage type (if any) SAN / NAS/ other
External Storage Data Volume <GB>
Volume Of Data Change Per Day <GB>
Estimated Growth <GB>/month
Data Protection Type Synchronous / Asynchronous Replication OR Non replicated
(Tapes)
Storage Tier Tier 1-5 (Based on business criticality)
Full Backup Size <GB>
Incremental Backup Size <GB>
Data Retention Requirements <Duration in Months / Years>
28 | Infosys eBook
5.5.9 Client software needed to access Enterprise shared services
This information is needed to know if any software clients are needed on any of the servers of an application to access
Enterprise Shared Services. This will help in correctly quantifying the application specific requirements to Enterprise Shared
Services Infrastructure group
Particular Remarks
Software ID (if any) Unique Software Identifier
Software Name <Software Name>
Software Version / Service Pack <Software version>
Software Description <Description>
Software Vendor <Vendor Name> / in-house
Software Category <Application / Monitoring / Infrastructure>
Number of licenses (as applicable) <count /CPU or no. of users etc.>
Associated Server /s <hostname /s>
Number of instances needed <count>
5.6 Facilities Requirements / Design
At this point, we have designed the target state IT infrastructure that will house the target data center. It is important to
ensure that the facilities infrastructure in the target data center is capable of catering to target IT Hardware. It should also
provide sufficient capacity for growth as defined through enterprises data center strategy.. In the age of multi-core processors,
blade server racks and grid computing environments, modern data centers are housing much dense IT hardware thereby
requiring a very careful facilities design. Earlier while conducting the assessment of source data center, we had captured its
facilities profile that now needs to be reviewed again in view of target IT infrastructure & scalability requirements. Following
are some of the key considerations that should be kept in mind while planning facilities infrastructure at target data center.
Estimation of total UPS & raw power requirement for the hardware design to be implemented at target data center.
Number of Racks & Square footage needed in the target data center
Power requirements in terms of Watts / Rack & by type of power Single Phase / Three Phase
New redundancy requirements to eliminate single points of failure
Change in density & capacity of servers as compared to source data center. E.g. blade servers, disk arrays, high end
Proprietary Server racks etc.
Backup generators needed for fault tolerance
HVAC capacity, cool air distribution design to ensure there are no hot spots
Need for any spot / rack mounted cooling systems
Hot Aisle, Cold Aisle design and methodology to collect heat from hot aisle to optimizing HVAC performance
Weight of the hardware and strength of floor needed
Any new regulatory / safety requirements
Capacity of Power Distribution Units, MCBs
Data Center Energy usage monitoring system
These considerations provide inputs for any adjustments to already provisioned facilities / assist in quantifying requirements
for any new facilities infrastructure.
Infosys eBook | 29
6 Move Plans
Once Current & Target State Application & Infrastructure analysis / design activities are completed, Data Center move
planning activities need to begin. A careful Migration / Relocation planning is key to the success of the program. Ensuring
the business continuity and availability of production applications while carrying out data center migration is more
challenging than build a data center for the first time. We are dealing with wires that are already carrying electric current,
and hence much deeper due diligence is needed to avoid any shocks. Following are some of the illustrative activities that are
recommended to create an efficient Move / Migration plan.
Assessment of Application & Infrastructure Interdependencies
Assessment of Time Zone Dependencies (Applicable, if target Data Center is in a different Time Zone)
Creation of Move Bundles (Based on logical interdependencies & Business priorities)
Dispositions on Infrastructure Build decisions such as:
Build New Hardware & Software at Target Data Center such as
Cold Build
Virtualize (Physical to-Virtual (P2V) or Virtual-to-Virtual (V2V))
Physical-to-Physical Move over Network (P2P)
Forklift / Truck Hardware from Source to Target Data Center
Temporary build to swing the hardware from Source to Target Data Center
In this section we will understand these considerations in more detail
6.1 Application & Infrastructure Interdependencies
This assessment is needed to ensure that build out of applications and infrastructure is phased out appropriately and
applications are grouped logically for near zero business impact.
30 | Infosys eBook
For each application, review all the interdependencies and assess:
Is this application REQUIRED to be deployed at Target Data Center in order for the parent application to operate?
(Based on business functions / processes supported by the parent application & its dependency on the bound application
to meet that requirement)
Can stand-in functionality or data be created for the parent application so that it can operate for predefined period of
time without the related / dependent application?
Can the parent application be modified so that it could operate for required amount of time without the related
application?
Tolerance levels for unavailability should be classified to assess most critical dependencies e.g. (No impact / Can
process with impact / cannot process).
This assessment will enable in base minimum / most necessary applications that must be grouped together for the purpose of
migration.
6.2 Time Zone Dependencies
In instances, where target data center operates in a different time-zone, it is required to assess time-zone sensitivity of
applications that are being planned for migration. Generally, applications that are time-zone sensitive or use timestamps
or interface with either external or internal systems in their normal processing of data and transactions require a common
time. In a disaster scenario, data replication and recovery to a different system time may influence the integrity of the data
and transaction processing. Moreover, Highly Available applications using any sort of active-active configuration between
Production and DR data Centers require use of a single system time. Log Shipping, Data Replication, and Message Queue
processes depend on applications using the same system time.
Recommended solution to this issue is to synchronize all platforms and their corresponding infrastructure components to a
common time (i.e. Greenwich Mean Team (GMT) or Universal Time Coordinated (UTC). UTC is a high precision atomic time
standard. UTC has uniform seconds defined by International Atomic Time (TAI), with leap seconds announced at irregular
intervals to compensate for the earths slowing rotation, and other discrepancies.
When local time is required to be displayed or used within an application, provide a utility, routine or service to determine
local time and day based on location
Following are some illustrative planning activities that should be done in this regard, prior to Application Migration to target
data center.
Means of storing data and transaction timestamps in UTC format
Methods to Convert local timestamps to UTC format
Development of scripts or processes to identify program logic that needs remediation
6.3 Create Move Bundle Packages
Following exhibits show how Current & Target State Analysis / Design information along with Application & Infrastructure
dependencies are considered to create these Move Bundle packages
Infosys eBook | 31
6.3.1 Move Build Package Template (Illustrative)
Bundle ID <Unique Bundle / Move Group Identifier>
Application ID <Unique Application / Infrastructure Identifier>
Application Name <Brief description about the application / infrastructure>
Line of Business <Business unit name>
Target AO <Bronze / Silver / Gold/ Platinum>
Target RTO <hh:mm>
Target RPO <1-5>
Component Type <Application / Infrastructure / Other Software>
Application environment <Mainframe / Distributed / Both>
Application Manager <Name>
Technology Delivery Manager <Name>
System Administrator <Name>
Each move bundle package should have a list of participating applications & is a work package that can be allocated to a
Build Project Manager for build & test work. Further to the move bundle package information as described above, for each
participating application an application build package is created based on Current & Target state Application & Infrastructure
analysis / design work conducted earlier.
6.3.2 Application Build Package template (Illustrative)
Application ID <Unique Application / Infrastructure Identifier>
Target Server /s
(Relocate from Source
Data Center)
Source Data Centers Server Information
Server
Hostname
Server Type
(Web/App/DB)
Vendor Model OS Security Zone
CPU type, size
& count
Memory
Local Disk size
Location Software
Target Server /s
(Physical Builds)
Server
Hostname
Server Type
(Web/App/DB)
Vendor Model OS Security Zone
CPU type, size
& count
Memory
Local Disk size
Location Software
Target Server /s
(Virtual Builds)
Server
Hostname
Server Type (Web/App/DB)
Virtual Memory
Security Zone
Virtual
processor
count
OS
Local Disk size
Location Software
Appliances Needed Appliances Needed
Third Party Circuit
Details
<Circuit info> e.g. New York to Atlanta 1 Gbps AT&T <circuit id>
32 | Infosys eBook
Databases
Database Information
Database Name Database Type (Oracle/
DB2/Sybase etc.)
Instance Name Database Server
Hostname
Storage
Storage Information
Hostname Storage Tier Allocated SAN /NAS Storage Size
Network & Security
Network & Security Information
Hostname IP address Firewall Rules (if any) Static Routes (if any)
6.4 Update Disaster Recovery Plans
After having completed the detailed analysis of an applications target state, it is important to update all the Disaster Recovery
documents prior to their migration. The Disaster Recovery Plan comprises of both, the Application and Infrastructure
Recovery Plans. Necessity to update Disaster Recovery plans may be required because of one or more target state scenarios
mentioned (but not limited to) below:
Changes to Application Architecture to meet target service level objectives defined by business.
Physical to Virtual Server Deployment
Technology Refresh to overcome retiring Hardware and OS issues
Changes to physical deployment architecture to overcome any network latency / performance issues
Revisions in High Availability / Data Protection implementation
Changes in other Applications / Infrastructure / Shared Services environment impacting the type of integration with an
application.
Business continuity team is generally engaged in making changes to current Disaster Recovery Plans (DRP) to ensure that
Recovery plans are updated considering all facets viz. Workflows, Technologies & Processes.
6.5 Create Detailed Implementation plan
Now that we have a full clarity on Target Applications, Infrastructure and move considerations, a detailed implementation
plan needs to be created. This plan should detail following activities (illustrative)
Scope, Phases & Statement of Work for various work streams of the program
Detailed cost breakup & funding approvals
Procurement of necessary hardware & software
Network
Servers
Application & Infrastructure Software
Storage
Security
Integrated Program Schedule in view of Infrastructure readiness at Target Data Center,
Availability of change windows, key resources, equipment etc.
Roles & Responsibilities for Build & Test activities
Team structure
Education & training
Relocation / Deputation of resources
Infosys eBook | 33
Project Management Plans
Scope Management Plan
Change Management Plan
Risk Assessment & Mitigation Plan
Risk Management Plan
Communication Plan
Schedule Management Plan
Cost Management Plan
Progress Tracking Tools / Repositories
Documented procedures & processes to Build & Test
Pre-Move / Post Move validation Checklists
Core Infrastructure installation & configuration plan
Third Party Network circuits
Co-ordination with External vendor Services
Forklift / Trucking (As needed)
Application Service Providers - ASPs (As needed)
Network Carriers (As needed)
Sub-contractors (As needed)
Identification of stakeholders for sign-offs on Build & Test milestones.
Risk Area Typical Risk / Challenge Mitigation Option
Planning
& Design
Phase
Complexity of interdependencies between various
applications and sharing of hardware poses
availability risk while migrating applications
Detailed application interdependencies analysis
and individual mitigations to either unlink
dependency transfer the dependency to another
application / hardware.
Some legacy applications run on obsolete /
unsupported Hardware & OS. While migrating
to new data center, the intent is to migrate to
newer Hardware, OS but Legacy Application is not
supported on the newer Hardware/OS
Some vendor supported software & tools are
not compatible with technology refresh activities
included in the Migration
Re-architect the application to be able to host on
newer Hardware / OS platform
Virtualize older OS versions (wherever possible)
until application is re-architected. This may also
be a better option if application is anticipated to be
sunset in the short term.
Increased distance between new data centers
disables from utilizing Active - Active / load
balancing deployment pattern
Transfer Availability dependency to local / other
nearby data centers i.e. enhancing the redundancy
& capacity.
Implement Network & Storage configuration
changes
Budgetary constraints consistently driving changes
to program scope
Divide the program scope into multiple phases
based on priorities to prevent from losing focus on
at least critical phases because of such constraints.
34 | Infosys eBook
6.6 Regulatory Considerations
There are various Regulatory requirements pertaining to the build out of Data Center facilities as well as security & privacy of
data. Generally, depending upon the location of the data center, relevant country specific regulations are applicable. Below are
some of the regulatory considerations that should be complied to while engineering / re-engineering data centers.
Telecommunication Infrastructure Standards (TIA-942)
TIA-942 is a standard developed by the Telecommunications Industry Association (TIA) to define guidelines for planning and
building data centers, particularly with regard to cabling systems and network design. The standard deals with both copper
and fiber optic media.
The TIA-942 specification references private and public domain data center requirements for applications and procedures
such as:
Network architecture
Electrical design
File storage, backup and archiving
System redundancy
Network access control and security
Database management
Web hosting
Application hosting
Content distribution
Environmental control
Protection against physical hazards (fire, flood, windstorm)
Power management
Grounding Standards (TIA-607)
The purpose of this Standard is to enable the planning, design, and installation of telecommunications grounding systems
within a building with or without prior knowledge of the telecommunication systems that will subsequently be installed. This
telecommunications grounding and bonding infrastructure supports a multi-vendor, multi-product environment as well as
the grounding practices for various systems that may be installed on customer premises.
OSHA Electrical Safety requirements
Its mission is to prevent work-related injuries, illnesses, and deaths by issuing and enforcing rules (called standards) for
workplace safety and health. OSHAs electrical standards are designed to protect employees exposed to dangers such as
electric shock, electrocution, fires, and explosions.
National Electrical Code (NEC)
The National Electrical Code (NEC) is a United States standard for the safe installation of electrical wiring and equipment. It
is part of the National Fire Codes series published by the National Fire Protection Association (NFPA).
NEPA - National Environmental Policy Act
NEPA requires agencies to undertake an assessment of the environmental effects of their proposed actions prior to making
decisions. It offers analysis of the environmental effects of the proposed action and possible mitigation of potential harmful
effects of such actions.
HIPAA - Health Care Companies data processing
HIPAA regulation includes the establishment of national standards for electronic health care transactions and national
identifiers for providers, health insurance plans, and employers. It helps people keep their information private. It defines the
security and data privacy requirements for organizations handling healthcare information.
Infosys eBook | 35
Sarbanes Oxley - Data Protection and Retention
The Sarbanes-Oxley Act (often shortened to SOX) is legislation enacted to protect shareholders and the general public
from accounting errors and fraudulent practices in the enterprise. The act is administered by the Securities and Exchange
Commission (SEC), which sets deadlines for compliance and publishes rules on requirements.
Sarbanes-Oxley is not a set of business practices and does not specify how a business should store records; rather, it defines
which records are to be stored and for how long. The legislation not only affects the financial side of corporations, it also
affects the IT departments whose job it is to store a corporations electronic records. The Sarbanes-Oxley Act states that all
business records, including electronic records and electronic messages, must be saved for not less than five years.
6.7 Enterprise Contractual considerations
Todays Data Center environments are a blend of in-house & vendor supported infrastructure. Overlooking these contractual
obligations may have huge cost and/or legal implications. Below are some of the contractual considerations that should kept
in mind while conducting a data center migration.
Lease agreements with Hardware Vendors who have leased equipment that now needs to be migrated. This will
require necessary permissions / negotiations with leasing vendor prior to relocation to target data center.
Any existing maintenance contracts with IT hardware vendors should be evaluated prior to planning a voluntary
retirement / decommissioning.
Network Communication links are also generally provided on fixed duration like 6 month / 1 year contract type. So,
these contractual obligations should be kept in mind while scheduling the migration
Current Data Center facilities lease agreements (if any) will also need to be seen. E.g. notice period required to vacate
current data center space & any maintenance contracts for Power, UPS, HVAC, Fire Suppressions systems and other
facilities should be evaluated prior to scheduling migration.
7 Build Applications & Infrastructure - Target Data Center
7.1 Core Infrastructure & Shared Services Build & Readiness Testing
Now that we have a detailed implementation plan, before we can migrate applications & their servers, core infrastructure &
Enterprise Shared Services need to be in place at target data center. Core infrastructure serves as common backbone for all the
applications & any unavailability of the same in the production environment will adversely impact a significant number of
applications. Therefore, every core infrastructure component should be built with appropriate level of redundancy & should
have enough capacity.
Below are some of the illustrative Core Infrastructure & Shared services Build Activities that should be undertaken at target
data center
Racks, Physical mounting of hardware
Installation & Configuration of Core Infrastructure components:
Network Switching & Routing environment
SAN / NAS / Backup Infrastructure
Firewalls, IDS & other security appliances
Activation of Network Connections with carriers.
Creation of Security Zones
Installation & Configuration of Enterprise Shared Services
Authentication & Authorization (Identity Management etc.)
Logging & Monitoring (Servers, Databases, OS etc.)
Antivirus & Anti-spyware
Shared Databases (Oracle RAC etc.)
Messaging (Email, MQ etc.)
File Sharing (FTP, NDM etc.)
Security Services (Digital Certificates / PKI etc.)
36 | Infosys eBook
Testing of Core Infrastructure & Shared Services:
Intranet, Extranet, Internet & VPN connectivity testing
High Availability / Failover testing
Performance / Stress testing
Ethical Hacking / Vulnerability Assessment / Penetration testing
Shared Services Availability & Integrity testing
7.2 Pilot Applications Build & Test
At this point, it is recommended to group a small set of applications encompassing varied technologies / complexity of
environment for the pilot build. This pilot build phase is beneficial to verify that:
Implementation plan is flawless
All internal & external dependencies have been taken care of.
To confirm the feasibility of build on a specific technology & environment
Actual Migration time is within available change window
No business services are being hampered in an unplanned fashion.
Hardware & Software for application (as per target design) are compatible.
Below is a list of illustrative applications build & test activities that cover a majority of data center migration initiatives.
Installation & Testing of
Application Specific Servers (Web / App / DB etc.)
Application specific software & necessary patches (.NET, Java, Oracle Apps etc.)
Core Business Application / Service (Core Banking / ecommerce / Payroll etc.)
Necessary client software (FTP / NDM / MQ / Backup clients etc.)
Provisioning & Testing of
Application specific Network Access & Security e.g. (Firewall Rules / Static Routes)
Application specific logging & monitoring (Performance / Utilization / Security / Access logs / agents etc.)
Interconnectivity with other applications & enterprise shared services
Data Migration & Acceptance testing (for New Server builds only)
Load snapshot of data from Source Data Center
Conduct test transactions on the application
Capture test results and incorporate any lessons learned in the build & test plans of Move Bundle Groups.
Lessons learned from the pilot implementation may suggest some alternatives / mitigation steps to enhance the
implementation plan for successful build & test activities.
7.3 Build Move Bundle Packages
Based on the lessons learned from pilot implementation activities discussed above, we are set to execute the move bundle
& application build packages defined earlier. Successful execution of move bundle packages requires excellent program
management capabilities and involvement of build specialists for various platforms / technologies.
Infosys eBook | 37
Based on the move bundle groups composition, generally a move bundle group requires co-ordination between various
resources on a full time / part-time basis. Below are some of the illustrative roles for a typical move group:
Build Project Manager
Build Specialist (s) e.g. Unix / Intel specialist
SMEs of Applications included in Move Bundle. (e.g. Application Architect, Application Manager, Technology Delivery
Manager)
System Administrator for servers included in the relevant application build packages.
Data Center Operations team for allocation of Space / Rack / cabling / Power & other facilities.
Server Virtualization team for virtual server builds, as applicable.
Data Center Infrastructure Engineering team Storage, Network, and Security etc.
Each organization follows its standard operating procedures for provisioning of servers. These should be followed in build
activities. Further, as discussed earlier migration of a server to a target data center can fall under one of the following
categories:
Building a New Physical Server
Building a new Virtual Server
Moving / Fork-lifting existing server
Building new physical / virtual servers does not interrupt existing operations at source data center whereas Moving / Fork-
lifting existing servers from source data center require additional planning and co-ordination for a seamless relocation.
Appropriate change windows need be co-coordinated with application, business & support teams. Further, standard
shutdown and startup procedures & checklists will need to be followed to ensure that all services are successfully restored in
the target data center.
7.4 Test Move Bundle Packages
A series of test cycles is necessary to ensure that all build activities meet the program goals. Generally, following test events
are adequate
7.4.1 Unit Testing
Once each application build package gets implemented, its important to conduct a unit testing for all components of that
application. This test ensures that Hardware, Operating System, Application Modules and associated software components
are functional as expected. All interconnectivity within different Tiers of an application e.g. Web to App / App to DB are
tested in this test cycle. Further, stress testing for various servers of an application is also carried out at this stage to ensure
that hardware is capable of meeting desired performance levels for a given workload.
7.4.2 Shared Infrastructure Testing
After the successful completion of unit testing, based on the application architecture, there is a need to test all interfaces to
Shared Services environment. e.g. if an application requires a Shared Database / a Digital Certificate / Authentication Service
then necessary tests should be conducted to ensure that relevant users / queries / RPCs etc. are performing successfully. A
stress testing on Shared infrastructure potion is also expected in this test cycle. This will provide feedback for capacity and
scalability of Shared Infrastructure environment.
7.4.3 System Integration Testing Move Group level
Next level of testing is to ensure that all interdependent applications within a move group / under the purview of a build
project manager are able to successfully interact with each other. e.g. if an application A in Move Bundle Group 1 needs to
transfer a batch file using NDM to an application B of the same Move Bundle group, then some sample files may need to be
transmitted between the two applications to ensure the network connectivity, performance, configuration parameters.
38 | Infosys eBook
7.4.4 System Integration Testing Program level
This final test is generally managed by a program level test manager. The purpose of this test is to ensure that all inter Move
group dependencies are successfully tested. This test is also an opportunity to test all interfaces of an application including
those that were not in the same Move Bundle group as that of the application.
7.5 Typical Risks, Challenges & Mitigation options Build & Test Phase
Risk Area Typical Risk / Challenge Mitigation Option
Build
& Test
Phase
Interdependencies on multiple work streams
& their timely readiness such as Data Center
Facilities, Equipment availability, Core & Shared
Service Infrastructure, Third party Vendor circuits
pose risk to Build & Test schedule
Set up a PMO to manage multiple work stream
projects
Adopt PMI best practices for project management
Define Bill of Material & initiate Procurement
processes earlier in the cycle to accommodate
sufficient lead time.
Procurement & equipment delivery times are high
and have tendency to impact Build Schedule
Enterprise resources are engaged in day to day
operational activities depriving the necessary focus
on build and test migration activities
Engage professional services partner for a smooth
migration.
Inability to test all the interdependent applications
in a single test cycle as some interfacing
applications is not ready yet.
Sequence the build activities appropriately to finish
the build of closely related applications around the
same time.
Ensure that dependent Enterprise Shared Services
are ready by completion schedule of dependent
applications
Ensure that firewalls rules & other connectivity
requirements are implemented & tested prior to
application level test activities.
Security zones & network connectivity is not
ready
Ensure that third party circuits are commissioned
in time & Vendors are ready to support the tests as
applicable.
8 Roll out & decommission
Now that we have built and tested all relevant applications & infrastructure at target data center, it is the time to commence
the rollout activities.
Rollout / Cutover plan varies for each application based on multiple factors such as:
Application Criticality (Based on its Service level objectives)
Number & Type of Servers
Interdependencies with Shared Infrastructure & other business applications.
Type of Build (Relocated / Built a new physical server / Virtualized)
Associated Databases
External Storage (On SAN / NAS / Tape media)
Third Party Network & Software dependencies
Change Windows & Availability of key contacts.
Data Migration plan (from Source to Target Data Center)
Additional Resource requirements
Infosys eBook | 39
Decommissioning is the last part of the program after successful rollout. The objective of decommissioning is basically to
Release and clean up Infrastructure at source data center.
Data Archives
Power-off / Enable re-use of released hardware
Update Asset Management systems to reflect release of hardware and software from Source Data Center.
Free up racks, power and data center space for other IT initiatives.
We will discuss on these two in further detail in the next section:
8.1 Rollout / Cutover applications to Target Data Center
Data Migration is a biggest challenge for a successful cutover / rollout of an application. This is primarily applicable to the
new physical / virtual server builds. It is expected that application whose all servers have been relocated from source to target
data center have already been connected to target storage environment and their data migration has already been taken care
during build activity itself.
Whereas, applications for which some servers have been built new whereas a few fall in forklift / trucking category, data
migration needs to be planned appropriately. Below are some of the illustrative options in such scenarios:
Withhold Forklift/Trucking of any data sensitive servers until cutover change window to ensure that snapshot of data
for all servers of an application is taken at one given point in time. Data migration & hardware relocation go hand in
hand in this scenario.
If servers of an application are not latency sensitive / distance between target and source data centers does not add
any latency, Forklift/ Truck relevant servers to target data center during build activity itself and continue running an
application with infrastructure / servers split across two data centers until the time when data migration for all new
physical/ virtual builds has also been completed. After which, the application will be fully running from target data
centers infrastructure. This option may require additional assessment on capacity of network to handle data traffic
between the two data centers, availability of data replication / storage infrastructure over the network.
In the case of a physical / virtual server build since a new instance of application has been created at target data center at
the same time when earlier instance is also functional at source data center, it is necessary to smoothly bring the operational
data from source to target data center. This would additionally need that users are seamlessly being pointed to the target data
center environment which would need necessary network and security configuration changes in the environment.
Based on an application profile, some applications may have higher tolerance for unavailability & thus provide enough time
to
Backup data from source data center environment
To discontinue new transactions until data is restored at the target data center
To redirect the users to utilize the target data center environment.
However, data migration becomes challenging in case of applications that operate 24x7 / real-time because of the
Ensuring the availability of application during transition
Integrity requirements of the data snapshot
Recording the incremental changes to data after snapshot taken
Restoration of incremental data during transition
These requirements pose potential risks to data corruption & integrity. A careful planning is needed to ensure that data
restoration is successful & achievable within the available change window. In many instances decisions such as airlifting a
business critical data on a Chartered flight are needed to ensure the business continuity and security of business critical data.
For some non-critical applications, replication of data over WAN or shipment through Tape backups may be an option.
As an illustration, applications such as ecommerce, online banking, online brokerage etc. are critical business applications
that are operational 24x7 and their data migration may be done through airlift to minimize the migration time, safeguard data
security & reduce the probable impact to the business. Weekends are generally utilized for such events to minimize service
outages. Other applications such as product catalogs / survey repositories / market trends etc. are comparatively less critical
and alternate migration plan may work well for them.
40 | Infosys eBook
So the typical cutover activities include (but not limited to) are:
Planning
Selection of a change window.
Identification of Change management team
Definition of Roles, Responsibilities, Processes to be followed during change window.
Definition of Escalation matrix to enable key decisions like GO/NO GO based on progress of cutover activities and
issues in hand.
Detailed Cut-over plan including selection of Data migration options (Airlift / Road transport / over WAN / over iSCSI/
SAN etc.)
Business and Technology Partners for Post implementation validation testing
Checklist of critical business services that define the success criteria for an applications migration.
Tools & templates to capture the test results / incidents for IT service management aspects
Compliance to any regulatory requirements in handling the data security & privacy.
Configuration Changes
Engagement of Network & Security folks in changes to network routing, DNS, firewall rules, and load balancers etc.
Configuration & Readiness of external storage environment at target data center to receive the data being brought into
target data center environment
Testing & Validation
Conduct pilots as necessary in a test bed to ensure that data migration plan works as expected prior to moving entire
production data store of an application.
Pre-Cutover and Post-Cutover validation testing.
Plan for point in time for restore based on business defined RTO/ RPOs.
Test scripts to validate integrity & performance of an application loaded with actual data prior to certifying for
production launch.
Testing the availability of data to other interfacing applications as per interdependencies / application architecture
including external vendors
8.2 Decommissioning Source Data Center Hardware
Though, a successful cutover/rollout is key to the success of a data center migration program, appropriate steps to
decommission the source data center are necessary to ensure the IT infrastructure maintenance costs are optimized and all
security, environmental and regulatory requirements are met. Typical decommissioning activities include:
Ensure that none of the applications / service is needed on the source data center infrastructure after the cutover of
applications. In instances where some servers are shared across multiple applications, it is necessary to ensure that all
stakeholders utilizing services / applications on a hardware are communicated about the decommissioning plans and
schedule so that users and network is enabled to utilize the newly build applications.
Decommissioning of certain applications that share hardware will need to wait until all the applications sharing that
hardware have been successfully rolled out to target data center or their dependency / sharing on the hardware has
been mitigated otherwise (e.g. moving to a different hardware / changes to application architecture that eliminates the
need of shared hardware etc).
Archival of data for regulatory and compliance requirements (as necessary).Backup all software components /
configuration files / scripts that may be needed in future.
Follow Enterprise security guidelines while handling safe disposal of electronic hardware, data and media in transit.
Power-off servers & other hardware infrastructure that is released post cutover of applications... Based on the
reusability of released hardware (Model, OS etc.), it may be reused for the build of other applications. This would save
power, needless cooling in the data center and provide some re-usable equipment.
Infosys eBook | 41
Un-mounting the released hardware to free up Data Center floor and Rack space.
Decommission any third party circuits that were terminated to source data center that are no longer needed as
applications have now been migrated to target data center. If any other applications that were out of scope of
migration still need any of third party circuits, the capacity requirements should be revisited to optimize the
bandwidth requirements.
Completed documentation on IT assets deployed in the target data center and those that have been released from the
source data center.
9 Appendix
9.1 Virtualization Candidacy Criteria (Illustrative)
Metrics Candidacy Scoring Criteria (Windows and Linux)
Processor
Requirements:
Determine Number of Processors
Determine Processor Speed
Determine Average Utilization % of Processor
Formula:
Number of Processors x Processor Speed x CPU Utilization % = CPU Score
Candidacy Scoring:
CPU Score < or = 4096 = Good Candidate
CPU Score > 4096 = Possible Candidate
Memory
Requirements:
Determine Physical Memory
Determine Physical Memory Utilization or Average Memory Usage
Formula:
Total Memory x Memory Utilization % = Memory Score
Candidacy Scoring:
Memory Score < or = 4096 = Good Candidate
Memory Score > 4096 and <= 6144 = Likely Candidate
Memory Score > 6144 = Possible Candidate
Disk
Requirements:
Determine Daily Average Total I/O Rate (4K pages per second)
Formula:
Daily Average Total I/O Rate (4K pages per second) = Disk I/O Score
Candidacy Scoring:
Disk I/O Score < or = 1000 I/O per second = Good Candidate
Disk I/O Score > 1000 and <= 3000 I/O per second = Likely Candidate
Disk I/O Score > 3000 I/O per second = Possible Candidate
42 | Infosys eBook
Metrics Candidacy Scoring Criteria (Unix)
Processor (Count)
Requirements:
Determine number of processors as component to virtualization ratio
Formula:
Number of Processors = CPU Score
Candidacy Scoring:
Total CPU Score <= 8 = Good Candidate
Total CPU Score > 8 = Possible Candidate
Total CPU Score > or = 4 Total CPU = Possible Candidate
Processor (Mhz)
Requirements:
Determine processor Mhz as component to virtualization ratio
Formula:
Processor Mhz = CPU Mhz Score
Candidacy Scoring:
CPU Mhz Score <= 1593 = Good Candidate
CPU Mhz Score > 1593 = Possible Candidate
Paging
Requirements:
Paging I/O Traffic in 4K
Formula:
Paging I/O Traffic = Paging
Candidacy Scoring:
Paging Score < or = 100 I/O per second = Good Candidate
Paging Score > 100 I/O and < 200 I/O = Likely Candidate
Paging Score > 200 or = 400 I/O = Possible Candidate
Disk
Requirements:
Determine Daily Average Total I/O Rate (4K pages per second)
Formula:
Daily Average Total I/O Rate (4K pages per second) = Disk I/O Score
Candidacy Scoring:
Disk I/O Score < or = 286760 I/O per second = Good Candidate
Disk I/O Score > 286760 and < 1024000 I/O per second = Likely Candidate
Disk I/O Score > 1024000 I/O per second = Possible Candidate
Network
Requirements:
Determine Daily Total Average Network Utilization (KB per second)
Formula:
Daily Average Total Network Utilization (MB per second) = Network Score
Candidacy Scoring:
Network Score < or = 40MB per second = Good Candidate
Network Score > 40MB per second and < 160MB per second = Likely Candidate
Network Score > or = 160MB per second = Possible Candidate
Virtual Score
Requirements:
Virtual Score is the combination of all associated metrics noted above. The specific metric is
given a calculated score and highest score across the five metrics is the score the server will be
given.
Example: Processor Score = Good, Processor (Mhz) Score = Good, Paging Score = Good, Disk
I/O Score = Possible, Network I/O = Good. Overall Score for Server = Possible
Infosys eBook | 43
9.2 Acronyms & Glossary
Acronym Description
AO Availability Objectives
ASP Application Service Provider
DAS Direct Attached Storage
DBMS Database Management System
DHCP Dynamic Host Configuration Protocol
DNS Domain Name System
DR Disaster Recovery
DRP Disaster Recovery Plan
FTP File Transfer Protocol
HA High Availability
HTTP Hyper-text transfer protocol
HVAC Heating Ventilation & Air Conditioning
I/O Input/Output
IDS Intrusion Detection System
IP Internet Protocol
LAN / VLAN Local Area Network / Virtual Local Area Network
MB/sec Mega Bytes/sec
MQ Queue Manager
NAS Network Attached Storage
NDM Network Data Mover
OS Operating System
P2P Physical to Physical
P2V Physical to Virtual
PDU Power Distribution units
RISC Reduced Instruction set computer
RPO Recovery Point Objectives
RTO Recovery Time Objectives
SAN Storage Area Network
SMS Systems Management Server
SOAP Simple object access protocol
TCP Transmission Control Protocol
UDP User Datagram Protocol
UTC Universal Time Co-ordinated
V2V Virtual to Virtual
VPN Virtual Private Network
WAN Wide Area Network
9.3 References:
Telecommunications Industry Association www.tiaonline.org
Occupational Safety & Health Administration www.osha.gov
National Environmental Policy Act (NEPA) www.epa.gov/Compliance/nepa
National Fire Protection Association (NFPA) www.nfpa.org
Health Info. Portability and Accountability Act www.hhs.gov/ocr/privacy/hipaa/understanding/
Sarbanes Oxley Act www.sec.gov/about/laws.shtml#sox2002
About The Author
Anil Chawla
Anil Chawla is a Senior IT leader with 14 years of professional experience including large technical program
leadership, Data Center Solution Consulting, IT Infrastructure Architecture & Strategy.

Data Center Migration

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Data Center Migration

Uploaded by

Copyright:

Available Formats

eBook

A Successful Data Center Migration

You might also like