eBook
A Successful Data Center Migration
- Cradle to Grave
“Given the dynamic operational environment in which today’s 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
Table of Contents
1 Introduction 4
4
1.1 Executive Summary 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 5.5.1 Individual Servers & Databases Associated with an application 2 | Infosys – eBook
22
23
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 6 Move Plans 28
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
Typical Risks, Challenges & Mitigation options – Build & Test Phase 38
7.5
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
Infosys – eBook | 3
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 today’s 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 Center’s 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
4 | Infosys – eBook
• 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
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.
• 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
Key Considerations
• 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
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)
Key Considerations
(Option B)
• To build-out a new data center with state• Depending on the size & criticality
of the art facilities infrastructure while
of current data center infrastructure,
maintaining current data center environment
temporarily move applications to a
hosting environment and upgrade facilities
• Migrate applications to newly built data
infrastructure of the existing data center
center
• Relocate applications from hosted
environment back to the upgraded data
center infrastructure.
• 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.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.
• 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
• Ensure optimal costs are incurred on Hardware, Software & Labor by making smart decisions
on:
Key Considerations
• Hardware & Software re-usability
• Appropriate program phases to minimize bubble period
• Utilization of appropriate tools & technologies
• Processes & best practices
• Deploying right resources
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
• 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
Key Considerations /
Drivers
• 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
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.
•
•
•
•
Key Considerations /
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
• 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
6 | Infosys – eBook
2.7
Scenario G – Hybrid
Scenario G – Hybrid
Hybrid Scenario – This may be a combination of one or more scenarios discussed above
Key Considerations /
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
Infosys – eBook | 7
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 environment’s 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 application’s 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-todate 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
3.2
Application
Name
Line of Business Contact Type
Contact Name
Email
Contact #
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.
8 | Infosys – eBook
Below table illustrates some of the key business service parameters for an application that would be helpful in further
due-diligence
Particular
App ID
Description
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 application’s 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
Infosys – eBook | 9
Below table illustrates some of the key infrastructure parameters an application that would be helpful in further due-diligence
for Data Center Migration.
Particular
Description
Database instance
Database name
App Databases
Database Role (Production / DR / Test / Dev)
Database Server Hostname
Database Vendor (Oracle / SQL / Sybase etc.)
Appliance Category (Shared / Dedicated)
Appliances
Appliance Name (e.g. Data Power, Security devices etc.)
Appliance Type (Facilities / Network / Security etc.)
Appliance Vendor, Model
Hardware Model
Hardware Vendor
Hostname
Local Disk size
Location (City, Rack location etc.)
Individual Servers
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)
Any other specific network hardware solely deployed for the application
Associated Security Zone (if any)
Network
IP address
Network Traffic volume (Low / Medium / High)
Third Party Circuit Details
Shared Databases
Shared Servers
Brief description about the dependent Shared Database
Location (City, Rack location etc.)
Shared Server / Hosting environment name
Number of licenses
Software
Software Name
Software Role (Backup / Monitoring / Remote connection etc.)
Software Vendor & Version
Any other specific storage hardware solely deployed for the application
Backup Type (Tape / Disk-to-Disk / DAS)
Storage
External SAN storage size (if any)
Local Disk Size
Replication Type (synchronous / asynchronous)
Storage Tier (if Hierarchical storage exists)
10 | Infosys – eBook
3.4
Application Interdependencies
Today’s 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:
Particular
Interface Name
Description
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
Infosys – eBook | 11
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 customer’s 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.
12 | Infosys – eBook
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.
Infosys – eBook | 13
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
A - Up to 15 minutes of data loss
(Target: 15 minutes)
Typical Use
Transaction Processing Applications
Notes
• 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 platformspecific data replication solutions
• Target data loss of less than
24 hours
C - Equal to or greater than 24 hours of Departmental Applications
data loss (Targets: 24 hours or 48 hours)
• 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
4.3
• Requires completing Exception
Process for approval
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 customer’s tolerance for this service not being available?
• What reputation risk or regulatory consequences are at stake for certain processing commitments
14 | Infosys – eBook
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
Greater then
99.95%
Monthly
Availability
(22 minutes
/ month
unavailable)
Peak Service
Availability
100% Monthly
Availability
(zero minutes
/ month
unavailable)
Scheduled
Service Outage
No scheduled
outages
(changes can
be made w/o
customer
impact)
Service
Restoration
2 minutes
to restore
application /
service
Targeted
Solution
2 completely
independent
Production
environments
Business Need
Objective
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
Platinum
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.
Infosys – eBook | 15
RTO
RTO 5
Duration (Tolerable Time to Recover)
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 chargeback’s
• Server system administration chargeback’s
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.
16 | Infosys – eBook
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
Target Data Center Facilities requirements (Space, Power, Cooling, Cabling etc.)
Core Infrastructure Layer
Target Data Center Rack Layout
Core Network, Security & Storage Infrastructure design
Shared Services Layer
Application Layer
Definition of Deployment
Patterns
5.1
Enterprise Shared Services (Authentication, Shared Databases, Messaging, Internet,
Monitoring & Management systems etc.)
Application Architecture at target state (in view of capacity, scalability, BSR expectations)
Individual Application specific Hardware, Software requirements
Selection of appropriate technologies to ensure Availability, Data protection at Target Data
Center in-line with BSR expectations)
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
Infosys – eBook | 17
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 proactive 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.
18 | Infosys – eBook
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.
Infosys – eBook | 19
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 node’s 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.
20 | Infosys – eBook
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
Infosys – eBook | 21
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 application’s 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
22 | Infosys – eBook
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
Host Name
Source Data Center
<current hostname>
Target Data Center
<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
Infosys – eBook | 23
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
Web Server
I/O Subsystems
CPU, Network
Anticipated Suitability
HIGH
Examples
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
MS Terminal Services and Citrix
on concurrent users and
Presentation server
dependent on the application
footprint
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
24 | Infosys – eBook
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
Software ID (if any)
Remarks
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
Infosys – eBook | 25
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
Appliance Name
Remarks
<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
Network Diagram for Application
Remarks
<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
Firewall Rules
Remarks
<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>
26 | Infosys – eBook
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
Latency sensitive hosts
Remarks
<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
External Storage type (if any)
Remarks
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>
Infosys – eBook | 27
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
Software ID (if any)
Remarks
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 enterprise’s 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.
28 | Infosys – eBook
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.
Infosys – eBook | 29
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 earth’s 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
30 | Infosys – eBook
6.3.1 Move Build Package Template (Illustrative)
Particular
Bundle ID
Description
<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)
Particular
Application ID
Target Server /s
(Relocate from Source
Data Center)
Description
<Unique Application / Infrastructure Identifier>
Server
Hostname
Source Data Center’s Server Information
Server Type
Vendor
Model
OS
(Web/App/DB)
CPU type, size Memory
& count
Target Server /s
(Physical Builds)
Server
Hostname
Server
Hostname
Virtual
processor
count
Location
Source Data Center’s Server Information
Server Type
Vendor
Model
OS
(Web/App/DB)
CPU type, size Memory
& count
Target Server /s
(Virtual Builds)
Local Disk size
Local Disk size
Location
Security Zone
Software
Security Zone
Software
Source Data Center’s Server Information
Server Type (Web/App/DB)
Virtual Memory
Security Zone
OS
Software
Location
Local Disk size
Appliances Needed
Appliances Needed
Third Party Circuit
Details
<Circuit info> e.g. New York to Atlanta 1 Gbps AT&T <circuit id>
Infosys – eBook | 31
Particular
Databases
Description
Database Name
Database Information
Database Type (Oracle/
Instance Name
DB2/Sybase etc.)
Storage
6.4
Storage Information
Allocated SAN /NAS Storage Size
Hostname
Storage Tier
Hostname
Network & Security Information
IP address
Firewall Rules (if any)
Network & Security
Database Server
Hostname
Static Routes (if any)
Update Disaster Recovery Plans
After having completed the detailed analysis of an application’s 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
32 | Infosys – eBook
• 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
Planning
& Design
Phase
Typical Risk / Challenge
• Complexity of interdependencies between various
applications and sharing of hardware poses
availability risk while migrating applications
Mitigation Option
• Detailed application interdependencies analysis
and individual mitigations to either unlink
dependency transfer the dependency to another
application / hardware.
• Some legacy applications run on obsolete /
• Re-architect the application to be able to host on
unsupported Hardware & OS. While migrating
newer Hardware / OS platform
to new data center, the intent is to migrate to
• Virtualize older OS versions (wherever possible)
newer Hardware, OS but Legacy Application is not
until application is re-architected. This may also
supported on the newer Hardware/OS
be a better option if application is anticipated to be
• Some vendor supported software & tools are
sunset in the short term.
not compatible with technology refresh activities
included in the Migration
• 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.
Infosys – eBook | 33
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. OSHA’s 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.
34 | Infosys – eBook
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 corporation’s 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
Today’s 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.)
Infosys – eBook | 35
• 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 application’s 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.
36 | Infosys – eBook
Based on the move bundle group’s 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 / Forklifting 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, it’s 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.
Infosys – eBook | 37
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
• 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
• Procurement & equipment delivery times are high
and have tendency to impact Build Schedule
Build
& Test
Phase
Mitigation Option
• 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.
• Enterprise resources are engaged in day to day
• Engage professional services partner for a smooth
operational activities depriving the necessary focus
migration.
on build and test migration activities
• 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
8
• Ensure that third party circuits are commissioned
in time & Vendors are ready to support the tests as
applicable.
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
38 | Infosys – eBook
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
center’s 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.
Infosys – eBook | 39
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 application’s 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.
40 | Infosys – eBook
• 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.
9Appendix
9.1
Virtualization Candidacy Criteria (Illustrative)
Metrics
Processor
Candidacy Scoring Criteria (Windows and Linux)
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
Requirements:
Determine Physical Memory
Determine Physical Memory Utilization or Average Memory Usage
Memory
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
Requirements:
Determine Daily Average Total I/O Rate (4K pages per second)
Disk
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
Infosys – eBook | 41
Metrics
Candidacy Scoring Criteria (Unix)
Requirements:
Determine number of processors as component to virtualization ratio
Processor (Count)
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
Requirements:
Determine processor Mhz as component to virtualization ratio
Processor (Mhz)
Formula:
Processor Mhz = CPU Mhz Score
Candidacy Scoring:
CPU Mhz Score <= 1593 = Good Candidate
CPU Mhz Score > 1593 = Possible Candidate
Requirements:
Paging I/O Traffic in 4K
Paging
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
Requirements:
Determine Daily Average Total I/O Rate (4K pages per second)
Disk
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
Requirements:
Determine Daily Total Average Network Utilization (KB per second)
Network
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
42 | Infosys – eBook
9.2
Acronyms & Glossary
Acronym
AO
Description
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
Infosys – eBook | 43
9.3References:
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.