Professional Documents
Culture Documents
Apr 2009
Table of Contents
1 Introduction
11
11
12
12
14
14
15
16
16
16
17
17
19
19
20
20
20
21
2 | Infosys eBook
22
23
23
25
26
5.5.5 Application specific LAN/ WAN & Third Party network connectivity requirements
26
26
27
27
28
6 Move Plans
28
29
29
30
30
31
31
32
32
34
35
7.1 Core Infrastructure & Shared Services Build & Readiness Testing
35
36
36
37
37
37
37
38
Typical Risks, Challenges & Mitigation options Build & Test Phase
38
7.5
38
39
40
9 Appendix
41
41
43
9.3 References:
44
Infosys eBook | 3
Introduction
1.1
Executive Summary
Business decisions to migrate data centers can be as a result of IT cost reduction initiative, regulatory requirement, business
service risk mitigation plan, a newer data center operations strategy, or other legacy data center environments incapable of
hosting modern & dense IT infrastructure. Among the biggest risks organizations face when transitioning their Data Center
is migrating IT systems and applications. A data center migration is a highly strategic project that must be executed without
impacting business operations, Service Level Agreements, performance/availability and data protection requirements. Given
the dynamic operational environment in which todays data centers operate, wherein applications and data in the production
environment is changing consistently and is being replicated to a remote DR facility on a regular basis, it becomes even more
important to look at all the facets of the IT environment and carefully carve the Data Center migration strategy.
Every environment has its own challenges and one migration strategy does not fit every client environment.
The bottom line consideration for a good migration strategy is near-zero disruption of business services. This objective drives
a deeper & thorough understanding of following major subsystems of a data center.
Nature & Criticality of Applications that cater to different business services
Servers, Shared hosting environments, Databases that host the applications or service logic.
Network that provides the access & security to information within Intranet, from Internet and VPNs.
Finally, most applications require disk storage for storing data and the amount of disk space and the frequency of
access varies greatly between different services/applications.
Performance & Service levels requirements.
By necessity, moving or migrating services from one data center to another need to consider all of these components. The
level & effort for such due diligence is based on the current Data Centers application and Infrastructure portfolio, tolerance
to unavailability of applications & services as well as time & budget constraints.
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
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
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
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
2.5
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
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
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
It appears as if moving / building infrastructure at target data center is predominantly about planning hardware infrastructure.
However, in order to ensure that business services are not disrupted in an unplanned fashion, a detailed application &
infrastructure assessment is needed. The purpose of Application & Infrastructure Analysis of Source Data Center environment
is to create a document package for each application, with sufficient understanding about current IT footprint. Further, based
on current environments understanding & other dependencies discussed later in this document, evolve a target state design
to be implemented at new data center. This includes, but not limited to:
Key contacts for an application (Application Manager, Technology Delivery Manager, and System Administrator,
Business continuity Manager, Architects etc.)
Number & Type of Hardware devices (Servers, Network, Storage, and Security) deployed
Number & type of Operating Systems, business & Enterprise software services deployed
Shared hosting environments and shared database environments deployed
Obsolete Hardware & Software Services that need to be refreshed along with Migration
Existing Availability, Recovery Time & Recovery Point objectives of each application
Architectural information, Physical and Logical diagrams exhibiting an applications deployment & geographical foot
prints.
Information on application & infrastructure interdependencies and affinities to assist in grouping Applications into
move bundles.
Current Service levels, Change Windows, Production issues.
3.1
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
Contact Name
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
App Description
App Type
App Environment
L.O.B
Risk Rating
Current RTO
Current RPO
Current AO
SLA
Status
Is Application time zone sensitive? (Applicable if target data center is in a different Time Zone)
Sunset Date
Shared Environment
3.3
Infrastructure Profile
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
Appliances
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
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
10 | Infosys eBook
3.4
Application Interdependencies
Todays complex application architectures interface with large number of other Enterprise & business applications. Migrating
complete / partial application infrastructure to another data center does not only need a due-diligence from all the facets of
application in question, but also need a thorough assessment of its impact to other interfacing applications. This analysis
would assist in first understanding the existing interdependencies and then in evolving appropriate Move Bundles. Some
Applications may be able to tolerate the unavailability of some non-critical interdependencies during migration window.
However many other critical interfaces such as Real time business critical data processing may require that such applications
be bundled together for the purpose of migration.
Following table illustrates some of the critical parameters to assess Application Interdependencies:
Particular
Interface Name
Description
Name of the interface
Related Application
Initiator
Description
Direction
Latency Sensitivity
Protocol
Bind Environment
Specify if dependency exist with Mainframe / distributed / both component /s. (Applicable if
Applications have both Mainframe and distributed components.)
Frequency of Access
Can process without impact / Can process with impact / cannot process at all
Integration Type
3.5
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
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
Business Service Reviews are intended to seek answers to following illustrative questions so that most appropriate / cost
effective Service level objectives are defined / agreed at.
What level of availability does your business require?
How much data is the business willing to lose in a catastrophic event?
How will you mitigate data loss?
How much revenue will be lost or additional expenses incurred by an unscheduled system outage for different
durations (i.e. 10 minutes, half hour, one hour, etc.)?
Is this financial impact more likely to be felt during certain peak processing times? If so, what are the peak periods?
What hard processing commitments do we have to external agencies or trading partners that are critical?
What is your customers tolerance for this service not being available?
What reputation risk or regulatory consequences are at stake for certain processing commitments?
Business Partners should be educated to appropriately gauge the target state Service Level objectives for their Business
Services. Following concepts about availability and recoverability should be made clear before seeking these Service level
objectives.
Availability is different from Disaster Recovery.
Availability provides for recovery from localized routine or non-routine events, with potential end-user impact.
Disaster Recovery involves recovery between data centers following catastrophic/extraordinary events, with certain
end-user impact from a disruption in service.
The business lens used for what would be reasonable to accept in a true disaster (Recoverability) has no relevance in
normal processing (Availability).
Recoverability has both a technology and business operations component
The technology will recover the application to the RPO and then the individual business unit will need to recover lost
transactions.
Application interdependencies will need to be clearly understood to accurately assign both the AO and RPO.
12 | Infosys eBook
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
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
Data Warehouses
X - Not Applicable
Pass-Through applications
Custom IT solution
4.3
Availability Objective (AO) is defined as the ability of a component or service to perform its required function at a stated
instant or over a stated period of time. In determining the most appropriate/cost effective Availability Objective, the following
business considerations must be addressed:
How much revenue will be lost or additional expenses incurred by an unscheduled system outage for different
durations (i.e. 10 minutes, half hour, one hour, etc.)?
Is this financial impact more likely to be felt during certain peak processing times? If so, what are the peak periods?
What hard processing commitments do we have to external agencies or rading partners that are critical
(i.e. Fed deadline or Balance Reporting)?
What is your customers tolerance for this service not being available?
What reputation risk or regulatory consequences are at stake for certain processing commitments
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
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
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
RTO 4
5 - 24:59 hours
RTO 3
RTO 2
RTO 1
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
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:
16 | Infosys eBook
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.)
5.1
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 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
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
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
20 | Infosys eBook
i. Active Server Cluster at Production & Active / Passive Server Cluster at DR site
Infosys eBook | 21
b. Load Balancing between Production & DR Server Clusters in two data centers
5.5
At this point, we are ready to design application specific infrastructure requirements. Following list describes the various
components that need to be looked at to evolve an applications infrastructure architecture:
Logical Application Architecture
Physical deployment architecture in the source data center
Appropriate Physical Deployment Model for the target state
Individual Servers & Databases Associated with an application
Application specific software requirements
Application specific appliances
Application specific LAN/ WAN & Third Party network connectivity requirements
Network Performance / Latency Sensitivity assessment (This will help in feasibility assessment / impact analysis &
mitigation planning for moving an application from source to target data center)
Application specific External Storage & Backup requirements
Any client software needed on application specific servers to access Enterprise shared services
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:
Location
Vendor
Model
RAM
CPU Type
RISC / INTEL
RISC / INTEL
CPU Count
<count>
<count>
Server Class
Migration Type
Not Applicable
Virtualization Status
In Secured Zone?
No / <Name of Zone>
No / <Name of Zone>
No / <Name of environment>
No / <Name of environment>
HA Model
Hostname /s
Hostname /s
DR Model
Server DR Partner
Hostname
Hostname
DR Partner Location
Location
Location
Devices Attached
CPU Speed
Operating System
OS with version
Server Role
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.
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
Disk, Network
HIGH
Database Server
MEDIUM
Note: Additional DBMS
consolidation methodologies
exist
Transactional Server
MEDIUM to HIGH
Note: Suitability is
dependent upon the
applications utilization
patterns
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
Application Server
MEDIUM
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.
Remarks
Unique Software Identifier
Software Name
<Software Name>
<Software version>
Software Description
<Description>
Software Vendor
Software Category
Associated Server /s
<hostname /s>
<count>
Responsible Party
Remarks
<Name of appliance>
<Name>
Appliance Type
Appliance Category
<Shared / Dedicated>
Responsible 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
<A.B.C.D>, <hostname>
Remarks
<Source IP addresses>
<Destination IP addresses>
<TCP/UDP ports>
<Access Permit / Deny>
<Rules to be logged>
26 | Infosys eBook
Remarks
<hostname>
<MB/sec>
<MB/sec>
<hh:mm>
<Mon-Sun>
Remarks
SAN / NAS/ other
<GB>
<GB>
Estimated Growth
<GB>/month
Storage Tier
<GB>
<GB>
Infosys eBook | 27
Remarks
Unique Software Identifier
Software Name
<Software Name>
<Software version>
Software Description
<Description>
Software Vendor
Software Category
Associated Server /s
<hostname /s>
<count>
5.6
At this point, we have designed the target state IT infrastructure that will house the target data center. It is important to
ensure that the facilities infrastructure in the target data center is capable of catering to target IT Hardware. It should also
provide sufficient capacity for growth as defined through enterprises data center strategy.. In the age of multi-core processors,
blade server racks and grid computing environments, modern data centers are housing much dense IT hardware thereby
requiring a very careful facilities design. Earlier while conducting the assessment of source data center, we had captured its
facilities profile that now needs to be reviewed again in view of target IT infrastructure & scalability requirements. Following
are some of the key considerations that should be kept in mind while planning facilities infrastructure at target data center.
Estimation of total UPS & raw power requirement for the hardware design to be implemented at target data center.
Number of Racks & Square footage needed in the target data center
Power requirements in terms of Watts / Rack & by type of power Single Phase / Three Phase
New redundancy requirements to eliminate single points of failure
Change in density & capacity of servers as compared to source data center. E.g. blade servers, disk arrays, high end
Proprietary Server racks etc.
Backup generators needed for fault tolerance
HVAC capacity, cool air distribution design to ensure there are no hot spots
Need for any spot / rack mounted cooling systems
Hot Aisle, Cold Aisle design and methodology to collect heat from hot aisle to optimizing HVAC performance
Weight of the hardware and strength of floor needed
Any new regulatory / safety requirements
Capacity of Power Distribution Units, MCBs
Data Center Energy usage monitoring system
These considerations provide inputs for any adjustments to already provisioned facilities / assist in quantifying requirements
for any new facilities infrastructure.
28 | Infosys eBook
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
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
6.2
In instances, where target data center operates in a different time-zone, it is required to assess time-zone sensitivity of
applications that are being planned for migration. Generally, applications that are time-zone sensitive or use timestamps
or interface with either external or internal systems in their normal processing of data and transactions require a common
time. In a disaster scenario, data replication and recovery to a different system time may influence the integrity of the data
and transaction processing. Moreover, Highly Available applications using any sort of active-active configuration between
Production and DR data Centers require use of a single system time. Log Shipping, Data Replication, and Message Queue
processes depend on applications using the same system time.
Recommended solution to this issue is to synchronize all platforms and their corresponding infrastructure components to a
common time (i.e. Greenwich Mean Team (GMT) or Universal Time Coordinated (UTC). UTC is a high precision atomic time
standard. UTC has uniform seconds defined by International Atomic Time (TAI), with leap seconds announced at irregular
intervals to compensate for the earths slowing rotation, and other discrepancies.
When local time is required to be displayed or used within an application, provide a utility, routine or service to determine
local time and day based on location
Following are some illustrative planning activities that should be done in this regard, prior to Application Migration to target
data center.
Means of storing data and transaction timestamps in UTC format
Methods to Convert local timestamps to UTC format
Development of scripts or processes to identify program logic that needs remediation
6.3
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
Description
<Unique Bundle / Move Group Identifier>
Application ID
Application Name
Line of Business
Target AO
Target RTO
<hh:mm>
Target RPO
<1-5>
Component Type
Application environment
Application Manager
<Name>
<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.
Description
<Unique Application / Infrastructure Identifier>
Server
Hostname
Server
Hostname
Server
Hostname
Virtual
processor
count
Location
Location
Security Zone
Software
Security Zone
Software
Security Zone
OS
Software
Location
Local Disk size
Appliances Needed
Appliances Needed
<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
Database Server
Hostname
After having completed the detailed analysis of an applications target state, it is important to update all the Disaster Recovery
documents prior to their migration. The Disaster Recovery Plan comprises of both, the Application and Infrastructure
Recovery Plans. Necessity to update Disaster Recovery plans may be required because of one or more target state scenarios
mentioned (but not limited to) below:
Changes to Application Architecture to meet target service level objectives defined by business.
Physical to Virtual Server Deployment
Technology Refresh to overcome retiring Hardware and OS issues
Changes to physical deployment architecture to overcome any network latency / performance issues
Revisions in High Availability / Data Protection implementation
Changes in other Applications / Infrastructure / Shared Services environment impacting the type of integration with an
application.
Business continuity team is generally engaged in making changes to current Disaster Recovery Plans (DRP) to ensure that
Recovery plans are updated considering all facets viz. Workflows, Technologies & Processes.
6.5
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
Planning
& Design
Phase
Mitigation Option
Detailed application interdependencies analysis
and individual mitigations to either unlink
dependency transfer the dependency to another
application / hardware.
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. OSHAs electrical standards are designed to protect employees exposed to dangers such as
electric shock, electrocution, fires, and explosions.
National Electrical Code (NEC)
The National Electrical Code (NEC) is a United States standard for the safe installation of electrical wiring and equipment. It
is part of the National Fire Codes series published by the National Fire Protection Association (NFPA).
NEPA - National Environmental Policy Act
NEPA requires agencies to undertake an assessment of the environmental effects of their proposed actions prior to making
decisions. It offers analysis of the environmental effects of the proposed action and possible mitigation of potential harmful
effects of such actions.
HIPAA - Health Care Companies data processing
HIPAA regulation includes the establishment of national standards for electronic health care transactions and national
identifiers for providers, health insurance plans, and employers. It helps people keep their information private. It defines the
security and data privacy requirements for organizations handling healthcare information.
34 | Infosys eBook
7.1
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:
Infosys eBook | 35
7.2
At this point, it is recommended to group a small set of applications encompassing varied technologies / complexity of
environment for the pilot build. This pilot build phase is beneficial to verify that:
Implementation plan is flawless
All internal & external dependencies have been taken care of.
To confirm the feasibility of build on a specific technology & environment
Actual Migration time is within available change window
No business services are being hampered in an unplanned fashion.
Hardware & Software for application (as per target design) are compatible.
Below is a list of illustrative applications build & test activities that cover a majority of data center migration initiatives.
Installation & Testing of
Application Specific Servers (Web / App / DB etc.)
Application specific software & necessary patches (.NET, Java, Oracle Apps etc.)
Core Business Application / Service (Core Banking / ecommerce / Payroll etc.)
Necessary client software (FTP / NDM / MQ / Backup clients etc.)
Provisioning & Testing of
Application specific Network Access & Security e.g. (Firewall Rules / Static Routes)
Application specific logging & monitoring (Performance / Utilization / Security / Access logs / agents etc.)
Interconnectivity with other applications & enterprise shared services
Data Migration & Acceptance testing (for New Server builds only)
Load snapshot of data from Source Data Center
Conduct test transactions on the application
Capture test results and incorporate any lessons learned in the build & test plans of Move Bundle Groups.
Lessons learned from the pilot implementation may suggest some alternatives / mitigation steps to enhance the
implementation plan for successful build & test activities.
7.3
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 groups composition, generally a move bundle group requires co-ordination between various
resources on a full time / part-time basis. Below are some of the illustrative roles for a typical move group:
Build Project Manager
Build Specialist (s) e.g. Unix / Intel specialist
SMEs of Applications included in Move Bundle. (e.g. Application Architect, Application Manager, Technology Delivery
Manager)
System Administrator for servers included in the relevant application build packages.
Data Center Operations team for allocation of Space / Rack / cabling / Power & other facilities.
Server Virtualization team for virtual server builds, as applicable.
Data Center Infrastructure Engineering team Storage, Network, and Security etc.
Each organization follows its standard operating procedures for provisioning of servers. These should be followed in build
activities. Further, as discussed earlier migration of a server to a target data center can fall under one of the following
categories:
Building a New Physical Server
Building a new Virtual Server
Moving / Fork-lifting existing server
Building new physical / virtual servers does not interrupt existing operations at source data center whereas Moving / 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
A series of test cycles is necessary to ensure that all build activities meet the program goals. Generally, following test events
are adequate
Infosys eBook | 37
7.5
Typical Risks, Challenges & Mitigation options Build & Test Phase
Risk Area
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.
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
Data Migration is a biggest challenge for a successful cutover / rollout of an application. This is primarily applicable to the
new physical / virtual server builds. It is expected that application whose all servers have been relocated from source to target
data center have already been connected to target storage environment and their data migration has already been taken care
during build activity itself.
Whereas, applications for which some servers have been built new whereas a few fall in forklift / trucking category, data
migration needs to be planned appropriately. Below are some of the illustrative options in such scenarios:
Withhold Forklift/Trucking of any data sensitive servers until cutover change window to ensure that snapshot of data
for all servers of an application is taken at one given point in time. Data migration & hardware relocation go hand in
hand in this scenario.
If servers of an application are not latency sensitive / distance between target and source data centers does not add
any latency, Forklift/ Truck relevant servers to target data center during build activity itself and continue running an
application with infrastructure / servers split across two data centers until the time when data migration for all new
physical/ virtual builds has also been completed. After which, the application will be fully running from target data
centers infrastructure. This option may require additional assessment on capacity of network to handle data traffic
between the two data centers, availability of data replication / storage infrastructure over the network.
In the case of a physical / virtual server build since a new instance of application has been created at target data center at
the same time when earlier instance is also functional at source data center, it is necessary to smoothly bring the operational
data from source to target data center. This would additionally need that users are seamlessly being pointed to the target data
center environment which would need necessary network and security configuration changes in the environment.
Based on an application profile, some applications may have higher tolerance for unavailability & thus provide enough time
to
Backup data from source data center environment
To discontinue new transactions until data is restored at the target data center
To redirect the users to utilize the target data center environment.
However, data migration becomes challenging in case of applications that operate 24x7 / real-time because of the
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 applications migration.
Tools & templates to capture the test results / incidents for IT service management aspects
Compliance to any regulatory requirements in handling the data security & privacy.
Configuration Changes
Engagement of Network & Security folks in changes to network routing, DNS, firewall rules, and load balancers etc.
Configuration & Readiness of external storage environment at target data center to receive the data being brought into
target data center environment
Testing & Validation
Conduct pilots as necessary in a test bed to ensure that data migration plan works as expected prior to moving entire
production data store of an application.
Pre-Cutover and Post-Cutover validation testing.
Plan for point in time for restore based on business defined RTO/ RPOs.
Test scripts to validate integrity & performance of an application loaded with actual data prior to certifying for
production launch.
Testing the availability of data to other interfacing applications as per interdependencies / application architecture
including external vendors
8.2
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.
9 Appendix
9.1
Metrics
Processor
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
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
Acronym
AO
Description
Availability Objectives
ASP
DAS
DBMS
DHCP
DNS
DR
Disaster Recovery
DRP
FTP
HA
High Availability
HTTP
HVAC
I/O
Input/Output
IDS
IP
Internet Protocol
LAN / VLAN
MB/sec
Mega Bytes/sec
MQ
Queue Manager
NAS
NDM
OS
Operating System
P2P
Physical to Physical
P2V
Physical to Virtual
PDU
RISC
RPO
RTO
SAN
SMS
SOAP
TCP
UDP
UTC
V2V
Virtual to Virtual
VPN
WAN
Infosys eBook | 43
9.3 References:
Telecommunications Industry Association
www.tiaonline.org
www.osha.gov
www.epa.gov/Compliance/nepa
www.nfpa.org
www.hhs.gov/ocr/privacy/hipaa/understanding/
www.sec.gov/about/laws.shtml#sox2002