table of contents - dell · 2020-07-06 · the value proposition offered by data center...

mailto:[email protected]

2013 EMC Proven Professional Knowledge Sharing 2

Table of Contents

Introduction ................................................................................................................................ 3

Benefits .................................................................................................................................. 4

Challenges ............................................................................................................................. 4

Virtualization and Migration Options ....................................................................................... 5

Expected End Result .............................................................................................................. 5

Agile Data Center Virtualization and Consolidation Process....................................................... 6

Process Overview ................................................................................................................... 7

Process Characteristics .......................................................................................................... 9

Teams ...................................................................................................................................10

Discover ....................................................................................................................................11

Infrastructure Data Collection ................................................................................................11

Virtualization Analysis ............................................................................................................12

Migration Analysis .................................................................................................................12

Bundling ................................................................................................................................13

Reports ..................................................................................................................................14

Agility .....................................................................................................................................14

Plan ..........................................................................................................................................15

Capacity Planning ..................................................................................................................15

Detailed Plan .........................................................................................................................15

Tasks for the Execution Workstream .....................................................................................16

Little’s Formula ......................................................................................................................17

Reports ..................................................................................................................................18

Agility in the Plan Workstream ...............................................................................................18

Execute .....................................................................................................................................18

Workflow ...............................................................................................................................18

Retrospection ........................................................................................................................20

Agility in the Execute Workstream .........................................................................................21

Tools .........................................................................................................................................21

Case Study ...............................................................................................................................23

Summary ..................................................................................................................................24

References ...............................................................................................................................24

Biography ..................................................................................................................................26

Disclaimer: The views, processes or methodologies published in this article are those of the author They do not necessarily reflect EMC Corporation’s views, processes or methodologies.


Introduction

The value proposition offered by data center virtualization is now well accepted [1]. A data

center primarily contains servers running one or more applications, network equipment, and

storage. By virtualizing a data center, organizations can realize significant benefits such as:

Reduced hardware, power, and space requirements through server consolidation and

centralization.

Ability to quickly and easily provision new servers.

Ability to quickly move Virtual Machines to enable continuous load balancing.

Migrating Virtual Machines in the event of hardware failures.

Dynamic allocation of hardware resources.

In addition to data center virtualization, we also need to consider data center consolidation.

Consolidation includes migration and decommissioning. Until a few years ago, it was necessary

to have the data center in close proximity with the business. But thanks to advances in

telecommunications technology, it is now possible to have a virtualized data center at a location

where real estate and energy costs are low. Therefore, migration of physical or virtualized

servers to a different data center is beneficial as long as it makes economic sense without

jeopardizing application performance. Decommissioning a server that is no longer needed

saves money through elimination of licensing and maintenance costs. Therefore, we need to

have the holistic view of consolidation, instead of limiting ourselves to just virtualization.

A few years ago a few software developers got together and started the agile movement [2].

This resulted in several methodologies and frameworks such as Scrum [3],[4] that make the

process of software development more efficient. This article shows how the key concepts in the

Scrum framework, such as close coordination between business and IT, an iterative approach

to construction, frequent demonstrations to the business, a cross-functional team, and

continuous refinement can be applied to make data center virtualization and consolidation more

efficient.


Benefits

An agile approach to data center virtualization and consolidation offers several significant

benefits, including:

Better risk management.

Incremental addition to business value.

Better resource utilization with minimal waste of time and effort.

Faster execution.

As a by-product, the analysis of existing inventory identifies servers that can be

decommissioned, which leads to savings in real estate, power, licensing, and support

costs.

Challenges

There are numerous challenges to overcome when virtualizing and consolidating data centers,

such as:

Application owners need to be convinced that their applications will work correctly and at

an acceptable performance level in the target data center.

Knowing all infrastructure requirements including load balancing and clustering, and

fulfilling them in the target data center.

Reaching consensus about dates when servers can be migrated.

Limited migration window, i.e. normally 48 hours, typically from Friday 6 PM to Sunday 6

PM. Downtime that exceeds the planned migration window can seriously impact the

business.

Network latency can affect migration speed when migrating to a data center far from the

original data center.

We will show how these challenges can be overcome with the Agile Data Center virtualization

process.


Virtualization and Migration Options

There are basically two options for virtualizing and consolidating a data center:

Big Bang: As the name suggests, this approach virtualizes all the servers and migrates

servers, storage, and network equipment in one “Big Bang” during the migration window.

Business value increases and risk goes down only after the “Big Bang” migration is

complete. This approach is suitable only for a very small data center with a handful of

servers. With a large number of servers, the Big Bang approach presents tremendous

risk and therefore is not practical.

Incremental: The Agile Data Center virtualization and consolidation process

recommends an incremental, iterative approach which involves virtualizing and migrating

servers and related storage in logical groups. This approach is attractive because it

limits the risk and lends itself to completing the migration of a group of logically selected

servers within a limited migration window. At the end of each iteration, with each

successfully completed migration, business value increases and the overall risk

decreases, as shown in the Figure 1.

Figure 1: Business Value and Risk

Expected End Result

By following the Agile Data Center virtualization and consolidation process, the expected end

result is that the target data center will have;

Virtualized servers running on Hypervisor [5] servers.

Storage Area Network (SAN) and Network Attached Storage (NAS) required by the

virtual servers with required data replicated from the original data center.


LAN, WAN, and other networking equipment such as load balancing, provisioned in the

target data center.

All applications working on physical or virtual servers in the original data center,

functioning satisfactorily in the target data center.

Agile Data Center Virtualization and Consolidation Process

At a high level, the Agile Data Center virtualization and consolidation process is organized

around four workstreams as shown in Figure 2.

Figure 2: Agile Data Center Virtualization and Consolidation Process Workstreams

As shown in Figure 2, the Discover workstream starts after scope definition is complete.

Discovery involves understanding the current server, storage, and network configuration and

determining a virtualization type to each server. Discovery also includes identifying logical

groups of servers—called “Bundles”—that need to be virtualized and migrated at the same time.

The Discover workstream proposes migration dates for each defined bundle. The Agile process

expects that proposed migration dates will change and allows the Discover workstream to

update them as required. The Plan workstream involves planning the capacity required at the

target data center and assigning server bundles to Iterations. The Execution phase involves

multiple iterations. An iteration consists of primarily three components:

1. Activities that need to be completed prior to the “migration window”, e.g. IP address

setup at the target data center.

2. Migration window in which server bundles identified in the planning phase are virtualized

and migrated.

3. Retrospection meeting.


An iteration is of a fixed duration. Such an interval is normally short, e.g. a week or two.

Regardless of the duration of the iteration, the “migration window” could be only 12 hours (i.e. a

weeknight) to 48 hours (i.e. a weekend) long. At the conclusion of the migration window, there is

a “retrospection” meeting attended by all the stakeholders in which lessons learned from the

iteration that just finished are reviewed and discussed within the team.

Finally, in addition to the Discover, Plan, and Execute workstreams, there is a “Project

Management” workstream responsible for managing scope, change control, communication with

stakeholders and sponsors, resolving issues, and mitigating risks. The Project Management

workstream also establishes the overall goals from a cost, quality, and schedule perspective,

and reviews any exceptions. The Project Management workstream also includes a Quality

Assurance component which ensures that proper organizational guidelines are followed

throughout the virtualization and consolidation process.

Process Overview

The key tasks and teams required to do the virtualization and consolidation are identified in

Figure 3.

Figure 3: Agile Data Center Virtualization and Consolidation Process


As shown in Figure 3, the Migration Management team collects data regarding servers and

infrastructure in the data center. For each server, the Migration Management team determines

whether it should be; virtualized and then moved, left as a physical server in the original data

center, or moved physically to another data center. Then the Migration Management team

assigns migration dates and defines logical groups of servers, called “Bundles”. The Migration

Management team produces a “Bundling Report” which shows all the servers, applications,

application disposition (e.g. virtualize, decommission, etc.), the bundle name to which a server

belongs, and a proposed date on which the server should be virtualized and migrated.

After reviewing the Bundling Report with the Application Owners, the Migration Management

team requests the Capacity Planning team to approve the capacity required. The Capacity

Planning team estimates the CPU, memory, and network capacity required to support the server

in a target virtual environment. The approved virtualization request is then sent to the Migration

Planning team which takes into account the amount of storage that needs to be copied from the

source to the target location. The Migration Planning team may adjust migration dates in the

Bundling Report based on estimated volume and network bandwidth. The Migration Planning

team creates an “Iteration backlog” in which each item identifies the server to be migrated. The

Iteration backlog is processed by a cross-functional team consisting of the following sub-teams.

1. Networking specialists who implement static IP addresses, DNS changes, load

balancing, etc. at the target data center.

2. Data Base Administration (DBA) specialists who shut down databases prior to server

virtualization and start up the database after server virtualization is complete.

3. Virtualization team members who are responsible for creating an image of the server in

the form of a file that can be processed by a Hypervisor server.

4. Storage team members who manage the replication of storage from the source to the

target data center.

5. Platform team specialists who confirm that the server starts up correctly after migration,

i.e. the server Operating System initializes correctly at the target data center.

6. Data Protection specialists who back up the server before it is migrated. This allows a

quick recovery to the original server in case there are issues in virtualizing and moving

the virtualized server.

7. Security specialists who check and implement firewall rules in the target data center.


The cross-functional team members repeat the process until all data center servers are

virtualized and consolidation is complete.

Consolidation includes decommissioning servers that are no longer needed. For the sake of

brevity, the decommissioning team is not shown in the above drawing. The Migration

Management team notifies the decommissioning team which servers are no longer needed and

the date by which they can be decommissioned. The decommissioning team confirms the

server retirement date with the application owners and retires the server after backing up the

server image according to organizational policies. Second, the Migration Management team

monitors the progress across the Plan and Execute workstreams and provides an update to the

Application owners about the progress made and issues encountered.

Process Characteristics

“Agile Data Center Virtualization” has several important characteristics:

Alacrity: It is assumed that no matter how much you plan, changes will continue

happening. For example, the Application Owner might cancel a virtualization due to

conflicting dates because the server needs to be upgraded and the originally proposed

migration window is not acceptable. It is expected that all teams, i.e. Migration

Management, Migration Planning, Capacity Planning, as well as cross-functional

Execution team accept such changes with “alacrity”, i.e. cheerfully and promptly.

General–purpose: Agile Data Center Virtualization is a general purpose process

applicable to all servers of all types. The process supports physical as well as virtual

server migration.

Iterative: Move in small steps rather than big chunks. Each iteration add business value

and consequently reduces risk.

Lean: There are minimal overheads and no waste of time and effort. There are no

bottlenecks and gating items that prevent progress.

Easy: This process is easy to learn and easy to follow.


As mentioned earlier, the Agile Data Center Virtualization and Consolidation process shares

several principles with the Scrum software development methodology. Table 1 shows the

similarities.

SCRUM

Agile Data center Virtualization and Consolidation

1 Allows requirements to evolve during construction

Provides flexibility in terms of what servers and applications to migrate and when to migrate them

2 Features developed are demonstrated to the users on a regular basis

After an iteration is complete, users start using the virtualized server(s) that migrated during that iteration

3 Retrospection meeting is held after each iteration

A meeting is held after each iteration to review “lessons learned” and issues encountered during the iteration

4 Backlog items for the Construction Team include user stories and non-functional requirements

A Backlog item for the Cross-functional migration team represents a specific operation, e.g. virtualize server, configure the VM, implement a networking change, etc.

5 Cross-functional team for code construction

Cross-functional team with virtualization, storage migration, DBA, and networking operations specialists

6 Each iteration adds business value through features implemented

Each iteration adds business value through servers and storage that are migrated successfully to the target data center

Table 1: Comparison between Scrum and Agile Data Center Virtualization and Consolidation

Teams

An important aspect of a process is the people who use it to reach a goal. Table 2 shows what

each team is responsible for, what it receives as input, and what it delivers.

Team Receives Responsibility Delivers

1 Migration Management

Input from Application Owners, Server, and Application information through Request for Change (RFC) questionnaire

Discovery and analysis of data center resources, bundling, oversight of entire Virtualization and Migration

Virtualized data center, Bundling Report, Disposition Report, Status Reports

2 Application Owners

Disposition Report, Bundling Report, and Exception Reports

Identify servers/Applications, migration dates, verify applications at Target Data center, provide server and application details through RFC questionnaire

Feedback on migration dates, tested applications to Business users

3 Capacity Planning Capacity Planning Analyze requests, assign Approved capacity


Request number of CPUs, memory, etc. for requested server

request with a specification

4 Migration Planning

Approved Request from Capacity Planning

Plan virtualization and migration dates, planning details of each migration iteration

Tickets for Networking, DBA, Virtualization, and Storage teams, detailed migration iteration plan

5 Networking Request for a networking change at the target data center

Analyze and implement changes e.g. load balancing and static IP addresses

Functional networking equipment

6 Database Administration (DBA)

Request for DB operations

Provide database backup and restore services

Database operations

7 Virtualization Request for virtualization Use the right tool to do the server virtualization

Server virtualized

8 Storage Request for Storage Migration

Use the right tool to migrate stored files or copy entire volumes from one data center to target

Storage migrated

9 Security Request for any firewall changes

Implement firewall changes required

Firewall configured

10 Data Protection Request for server back-up

Do an incremental server back-up

Server backed up before virtualization

11 Platform Request for server start-up

Starts up the virtual server at the target data center

Fully functional virtual server

Table 2: Agile Data Center Virtualization and Consolidation Teams

Discover

In this section, we review the activities performed by the Discover workstream. Discovery is a

three-step process including:

a. Collect infrastructure details, i.e. server, application, and storage information

b. Virtualization analysis, i.e. identifying candidate servers for virtualization

c. Migration analysis, i.e. whether to keep the server at the original data center or

migrate it to a different data center in order to realize cost savings

Infrastructure Data Collection

The first step in the Discover workstream should be to meet with data center managers and

Application Owners and collect infrastructure data for servers, applications, and network

storage. Infrastructure data can be collected through a simple Request for Change (RFC)

questionnaire, which the application owners fill out. Portfolio Discovery tools can also be used.


Note the many-to-many relationships involved, e.g. one server runs multiple applications and

one application runs on multiple servers. For the sake of simplicity, it is a good idea to maintain

the same server-to-application relationships after virtualization and migration. Moving the

applications to a different server will significantly increase complexity.

Virtualization Analysis

After collecting infrastructure details, the second step is to determine which servers to virtualize.

Two factors influencing the virtualization decision include which hardware/software platforms

are supported and not supported by the Hypervisor server, e.g. VMware ESX Server [6], as well

as the performance characteristics of the physical server that needs to be virtualized.

Reasons why a server should not be virtualized are:

The Hypervisor server does not support the server hardware architecture and Operating

System.

The Application(s) running on the server have not been certified by the application

vendor to run on a virtual server.

Server CPU and Disk I/O utilization is so high that it cannot be supported in a virtual

environment. Many data centers maintain server utilization history over a three-month

period. The migration team should review average CPU utilization and Disk I/O Busy

Utilization and if both are less than 50%, the server is a good candidate for

virtualization.

Due to advancements in hypervisor technology, it should be easily possible to virtualize x86-

based servers running Windows or Linux operating systems. If for some reason a server cannot

be virtualized, exception documentation should be prepared and necessary approvals taken to

confirm why a server cannot be virtualized.

Migration Analysis

After completing virtualization analysis, the next step is to do the migration analysis, i.e.

deciding the target location for a server. If the target location is going to be far from the users,

network simulation should be done to understand the impact of WAN latency on throughput and

end user experience. Migration Analysis should conclude with a determination of the “Migration

Type” and a “Disposition” for each server, i.e. whether the server will be moved and which data

center it will finally reside in. Table 3 shows possible migration types and what they mean.


Special consideration is given to Solaris servers because of the Zone concept supported by

Solaris.

Migration Type Meaning

1 P2P Server is installed in another physical server

2 P2V Server is virtualized and the virtualized server is run by the Hypervisor. The virtual server may run in a target data center which could be different from the original data center location.

3 V2V Server is already virtualized. Virtualized server is moved to target data center.

4 P2Z Physical Solaris server is moved to a zone on another Solaris server in target data center.

5 Z2Z Solaris server already exists in a zone and is moved to a zone on another Solaris server in target data center.

6 Forklift Server is not virtualized and physically fork-lifted to target data center.

7 Decommission Server is retired

Table 3: List of Migration Types

Migration Analysis should identify servers that cannot be moved to a target data center. For

example, a server responsible for the physical data center security at the original data center

must remain there and is not a good candidate for moving to another data center.

Bundling

Bundling is the process of grouping servers and applications for migration purposes. It is

important from a planning perspective because all servers in one bundle have to be virtualized

and migrated in the same migration window. The Agile Data Center Virtualization and

Consolidation process aims to have only one migration window for a single application, i.e. the

server or set of servers on which the application is running should be brought down only once

and not multiple times. This minimizes impact on the business because the application is

unavailable only once during the migration window. To meet this goal, if a single application is

running on multiple servers, all those servers should be virtualized and migrated together as a

group. This is referred to as a “Bundle”. A server can exist in only one bundle and a bundle can

have multiple servers within it, as shown in the Figure 4.

.


Figure 4: Relationships between Server Bundles, Servers, Applications, and Storage

Reports

The key reports produced by the Discover workstream are mentioned below. Each report should

be reviewed and accepted by Application Owners.

Disposition Report lists servers, applications running on each server, SAN and NAS

storage used by each server and, most importantly, the Migration Status. The

Disposition Report is useful because it identifies all the servers that are part of the

migration project scope. It can be also used to determine whether SAN and NAS

connectivity is needed by a server and if so, how much storage is used.

Bundling Report shows groups of servers are candidates for virtualization and should

migrate together along with a proposed date for the migration. The Bundling Report is

used as an input in all migration planning activity.

Exceptions Report listing servers that were not virtualized with an explanation for why it

was decided not to go ahead with virtualization.

Agility

To improve agility, the Agile Data Center Virtualization and Consolidation process recommends

completing the Data Collection process for the entire data center and then moving incrementally

with analysis after that. After collecting infrastructure data, a subset of servers should be

identified, for which Virtualization Analysis, Migration Analysis, and Bundling are done. The

Disposition Report and the Bundling Report should be prepared for the subset of servers and

provided to the “Plan” workstream. This will allow the “Plan” workstream to make progress and

feedback from the “Plan” workstream will be helpful to the “Discover” workstream in

accomplishing their activities. Not requiring the “Plan” workstream to wait for “Discover” to finish

makes the overall Data Center Virtualization process more agile and efficient.


Plan

The Plan workstream works on three different activities in the Agile Data Center Virtualization

and Consolidation process:

1. Reviewing the capacity needed in the target data center and making sure the needed

capacity is provisioned.

2. Creating a detailed “hour-by-hour” plan showing all the activities in an iteration, i.e.

identifying which servers should be virtualized and moved within the migration window.

3. Creating tasks for the Execution team so that appropriate planning steps can be taken

before the migration window starts.

Capacity Planning

Capacity planning involves analyzing historical CPU, memory, and I/O utilization details for the

server that will be virtualized and ensuring that adequate CPU, memory, and storage resources

are provisioned on the Hypervisor server. Also included is an identification of which physical

Hypervisor server the virtualized server will run on. Additionally, capacity planning involves

determining the adequate number of Hypervisor servers, the capacity of each Hypervisor

server, and storage (SAN and NAS) at the target data center.

Detailed Plan

As mentioned earlier, a major challenge in data center virtualization and consolidation is the

limited migration window of typically 48 hours over a weekend and 12 hours over a weeknight. If

virtualization and migration of given servers that do not finish within the planned window leads

to a negative impact on the business. Therefore, based on the Bundling Report, the Plan

workstream identifies which servers to virtualize within a migration window and estimates the

time required for virtualization and migration activities.

The main parameters involved in the time estimate include the size of the file that contains the

server image (typically in gigabytes), the rate at which virtualization is done based on the

virtualization tool used, and the rate at which the virtual server can be transferred across the

wide area network with the available tool or tools.

As an example, Figure 5 models the execution time line for a specific server. Suppose the

server is using 80 Gbytes of disk space for the Operating System and Application binaries and

an additional 40 Gbytes for application data files. Based on the server size and the time


historically taken to complete various tasks, the Execution team estimates the time required to

complete the migration.

As shown Figure 5, the database on the server would be shut down at 1 AM. Based on the

server size of 120 Gbytes, virtualization is estimated to take four hours. The virtualized server

would then be moved from SAN to NAS storage for migration purposes, which would take three

hours. Assuming a typical WAN data transfer rate of 20 Gbytes/hour, migrating to the target

data center is estimated to take six hours. Three hours would be needed to start up the virtual

server at the target location which includes any DNS operations at the target data center.

Migration across the wide area network is always somewhat unpredictable. If migration does not

complete in time, it might have to be rolled back. Therefore, the timeline also includes a check-

point to review the overall progress and, if migration is not complete by that point, initiate a roll-

back. In this example, if migration across the WAN is not complete by 6 PM, it is better to roll-

back rather than continue with the migration. Finally, three hours are allocated for database start

up and three hours are also allocated for application verification. Such detailed planning should

be done for each server to be virtualized and migrated. An “hour-by-hour” plan should be

prepared showing various activities involved.

Figure 5: An example execution time line for a server

Tasks for the Execution Workstream

Based on the time required for each server and the total number of hours in the migration

window, the Planning team should decide which server bundles to migrate in a given iteration.

To support the servers, network configuration at the target data center is an important activity

that needs to be planned well ahead of the migration iteration. This involves creating task

requests for the Networking team so that network equipment such as routers and load

balancers can be configured at the target data center ahead of the migration window. Also, new

IP addresses or static IP addresses can be acquired ahead of the server migration. Additionally,

task requests need to be created for other execution teams including Database Administrators,


Data Protection, Security, and Platform teams so that they can perform the necessary activities

prior to migration.

Little’s Formula

Migration planners have to be cognizant of the fact that multiple servers have to be processed in

the same migration window. As such, there are multiple points where bottlenecks can appear

which will result in queuing. For example, there could be multiple servers pending to be

migrated from one data center to another or multiple servers waiting in a queue, waiting to be

processed by the System Administrator. In order to model the behavior of items waiting in

queue, we refer to Little’s Formula [13], [14] which states that

Where Wq = average waiting time in the queue for a standard job

Lq = average number of items in the queue

λ= average service rate at which items in the queue are processed

For example, if it takes a system administrator 15 minutes to configure and start a virtual

server—meaning four servers can be started per hour—and if there are 0 to 20 servers always

waiting to be started—meaning an average of 10 servers to be started—the average wait time

per server will be

= 2.5 hours

To reduce the wait time, if you have two systems administrators, you will increase the service

rate to eight servers per hour to start. Therefore, average wait time will reduce to 1.25 hours.

Alternatively, migration planners can investigate if there is a way to reduce the time it takes to

configure a virtual server. For example, if that period can be reduced to 10 minutes per server,

—meaning six servers per hour can be configured—the average wait time would be

In summary, Little’s Formula shows how planners can use various ways to improve the agility of

the overall migration process.


Reports

The key reports produced within the planning workstream include an updated Bundling Report

as well as an “Hour-By-Hour” plan of activities to take place during the Execution workstream.

Updates to the Bundling Report are done after analyzing the timeline of execution for each

server. Such updates to the Bundling Report as well as the Hour-By-Hour execution plan should

be reviewed and approved by the Application Owners.

Agility in the Plan Workstream

Agility in the Planning workstream is brought about in several ways. First, the plan workstream

should start working with a subset of bundles and work incrementally toward completing the

entire set of bundles. Second, task requests for other execution teams should be created ahead

of the execution phase, so that there is minimal waiting when the execution starts. Finally, the

planning workstream should take into account various ways to reduce service time per task and

reduce the wait time in queue.

Execute

The Execute workstream involves virtualizing and migrating data center resources into the

target data center. The actual migration is done in migration windows, which are scheduled at

regular intervals, e.g. every weekend when business users can afford not to use the

applications running on the server to be virtualized. For servers with smaller storage sizes,

smaller—less than 12 hours—migration windows may be possible meaning that such migrations

can be done on weeknights as well. The “Hour-by-Hour” plan produced by the Plan workstream

is the input for the Execution workstream. Also, the task requests created by the Plan

workstream for the Execution workstream are important inputs for the Execution workstream.

Workflow

Figure 5 shows how various cross-functional teams collaborate within the Execute workstream

to migrate a server during the migration window. As shown in Figure 5, the top swim lane

represents the main workflow with callouts to different functions within the cross-functional

team.

The workflow shows a server migrating from a source data center to a target data center. The

workflow begins with the Application Team bringing down the applications on the server that is

scheduled to migrate. If the server is running the database, the database services are stopped.

The server is then virtualized and the server image is transferred from the original data center to


the target data center. At the target data center, after the server lands at the appropriate

location, it is started and after the Operating System shows the server starting normally,

networking changes such as DNS updates are made. If necessary, database services are

started and then the applications are started. The Application Team tests the applications in the

new environment and the workflow ends only after the Application Team confirms that the

applications are functioning normally.

For the sake of brevity, the data protection function—i.e. incremental server back up—and the

remote data replication function—i.e. copying data from the SAN or NAS in the source data

center to the target data center are not shown. Throughout the workflow, the cross-functional

team is engaged and communicates through a conference call. A command center manages

the conference call and makes sure that the right team members investigate and resolve

problems that arise.


Execution Work-StreamD

atab

ase

Wo

rkfl

ow

Vir

tual

izat

ion

Sto

rage

M

igra

tio

nP

latf

orm

Ap

p O

wn

ers

Ne

two

rkin

gEr

ror

Man

age

me

nt

Server runs Database?

Y

Shutdown Database Services

Start Virtualization

N

Virtualize Server and

produce Virtual Server Image

Errors?

Log Error and Notify

Migrate to Target Location

N

Migrate Server Virtual Image

Errors?

Start up Virtual Server

Y

N

Y

Start up the Operating

System Errors?

Y

Make Networking

Changes

N

Server runs Database?

StartupDatabaseServices

Set up DNS and IP Address at

the Target Location

Errors?

VerifyApplications

N

Y

Verify Applications at Target Location

Shutdown applications on

the server

Figure 5: Workflow showing how cross-functional sub-teams collaborate

Retrospection

During each iteration, the leader of the cross-functional team makes detailed notes about issues

that arose and how they were resolved. After the iteration is complete, a “Retrospection”

session is organized in which all the team members from Migration Management, Migration

Planning, and Execution teams as well as Application Owners get together and review the

accomplishments and problems encountered during the iteration. Steps are taken to ensure that


the same problems don’t appear again. Team members may make suggestions about process

improvement. For example, the team may suggest that the iteration backlog needs to be

planned more carefully with consideration to migration speeds over the WAN. Such suggestions

are taken into account while starting the next iteration, which leads to continuous process

improvement.

Agility in the Execute Workstream

The workflow shown in Figure 5 represents the set of activities performed on a single server. In

reality, multiple servers are processed simultaneously during an iteration. Therefore, as

previously mentioned, there is a possibility of queues building within the workflow. Minimizing

queuing delays increases the agility of the execution workstream. As discussed before, various

avenues such as increasing the number of resources to process the tasks and reducing the

duration of each task should be explored to reduce the execution time of each task, thereby

increasing the service rate and the overall throughput of the work-flow.

A dashboard to monitor the status of each server that is being virtualized is a very useful tool

that will also increase agility. Such a tool enables identifying bottlenecks, errors, and remedial

actions.

Another important factor contributing to agility is a continuous “command center” running a

conference call throughout the iteration. Because of the conference call, a problem is noted

quickly, people who can resolve the problem are identified, and the solution is made available in

real time.

Tools

Data center virtualization and consolidation is a complex operation, requiring several

productivity tools. This section provides a brief review of a set of tools that can be used by each

workstream mentioned in the Agile Data Center Virtualization process. The tools mentioned

here are just examples of commercially available products and should not be interpreted as

products recommended for the Agile Data Center Virtualization process.

Discover: The portfolio of servers and applications in a data center can be discovered

through VMware vCenter Application Discovery Manager (ADM) [7]. A custom

database solution called “Configuration Management Database (CMDB)” is used to

track all assets. Figure 6 models various entities in the CMDB. The Discover

workstream should use a tool such as eHealth [8] to monitor the CPU, disk I/O, and


network utilization on a historical basis. To understand the performance profile of an

application when it is accessed over a WAN, a simulator such as Shunra NV [9] should

be used to see how the application performs when subjected to WAN latency.

Figure 6: Entity-Relationship Model within the Configuration Management Database

Plan: A custom database solution is needed for tracking bundling and scheduling of all

servers. Such a database solution works as an adjunct to the CMDB. Additionally, a

custom database solution is needed to manage the CPU, memory, and storage

requirements for all virtual servers in the target data center.

Execute: For virtualizing, physical server tools such as VMware vCenter Converter [10]

and PlateSpin Migrate [11] should be considered. An important tool that influences

server migration agility is how the virtual server is migrated from the source data center

to the target data center. Off-the-shelf products such as Open Replicator [15] or SRDF®

[16] can be used to copy the virtual server image from EMC storage at the original data

center to EMC storage at the target data center. For copying from NetApp storage to

NetApp storage at the target data center, SnapMirror [17] can be used. It copies a


virtualized server to a remote location while the server is functional. Thus, as changes

occur on the source side, SnapMirror copies them to the target data center. For a short

time, the virtual server is shut down so that no more changes can occur on the source

side and the final set of changes are copied to the target side. Another option to

consider is an off-the-shelf product such as Aspera Sync [12] which employs a high

speed file transfer protocol which utilizes the maximum amount of available network

bandwidth in copying the virtual server to the target data center. The downside of the

Aspera Sync approach is that the virtual server needs to be shut down while the

migration is in progress. However, if the migration window size is adequate, this is not a

severe downside.

Finally, a customized workflow management solution is required to manage the

interaction between people and tasks to be performed. Such a solution enables a

cross-functional team member—e.g. a System Administrator—to select a pending task

from the Iteration backlog, work on it, and then mark the task complete. A dashboard

integrated with the workflow solution gives visibility about the number of tasks pending

and completed.

Case Study

A large multinational company operated a data center in Japan. The data center had nearly 400

x86 servers running Windows. Applications running on the servers consisted of mission-critical

financial, marketing, sales, and business intelligence applications. The organization used to pay

close to $2.3 million per year toward leasing room for the data center.

By successfully applying the Agile Data Center Virtualization and Consolidation process, over a

period of six months nearly 300 servers were virtualized and consolidated to three target data

centers outside of Japan. Nearly 70 servers were decommissioned and it was decided to retain

only 30 servers in Japan. By migrating servers to other parts of the world, the company

drastically reduced the data center footprint in Japan, yielding almost $2 million in savings on

data center leasing costs alone. Additionally, significant savings were realized on maintenance

and licensing costs as a result of the server decommissioning exercise.


Summary

This article describes the Agile Data Center Virtualization and Consolidation process, which

centers around four concurrent workstreams—Discover, Plan, Execute, and Project

Management. The activities performed by each workstream, the roles of various teams, and the

deliverables of each workstream are explained. The key principles used in the process include,

concurrent discovery, planning, and execution workstreams, continuous alignment with the

business, flexibility in terms of which servers to virtualize and when, an iterative approach to

execution followed by retrospection, and adding business value continuously over a period of

time. Productivity tools required for planning, bundling, scheduling, virtualization, server

migration, and workflow management are also identified. A case study presented how applying

the Agile Data Center Virtualization and Consolidation process resulted in significant savings.

References

[1] Griesser, Tim. “Enabling Datacenter Automation with Virtualized Infrastructure”,

IDC, August 2008

[2] www.agilemanifesto.org. “Manifesto for Agile Software Development”

[3] Pichler, Roman. “Agile Product Management with Scrum”, Addison Wesley,

2010

[4] Schwaber, Ken. “Agile Project Management with Scrum”, Microsoft Press, 2004

[5] Goldberg, Robert P. “Architectural Principles for Virtual Computer Systems”,

Harvard University, 1973

[6] www.vmware.com/products/vsphere/esxi-and-esx/index.html. “VMware vSphere

ESX and ESXi information center”, VMWare Corporation, 2013

[7] www.emc.com/products/detail/software/vmware-vcenter-application-discovery-

manager.htm. “VMware vCenter Application Discovery Manager”, EMC Corporation

[8] www.ca.com/us/~media/Files/ProductBriefs/eHealth_PS.pdf

“CA eHealth”, CA Technologies

[9] http://www.shunra.com/products/shunra-nv-network-virtualization. “Shunra NV

(Network Virtualization)”, Shunra

[10] http://www.vmware.com/products/converter/. “VMWare vCenter Converter”,

VMWare Corporation

[11] https://www.netiq.com/products/migrate/. “PlateSpin Migrate”, NetIQ

[12] http://asperasoft.com/software/synchronization/. “Aspera Sync”, Aspera

http://www.agilemanifesto.org/

http://www.emc.com/

http://www.ca.com/us/~media/Files/ProductBriefs/eHealth_PS.pdf

http://www.shunra.com/products/shunra-nv-network-virtualization

http://www.vmware.com/products/converter/

https://www.netiq.com/products/migrate/

http://asperasoft.com/software/synchronization/


[13] Leon-Garcia, Alberto. “Probability, Statistics and Random Processes for

Electrical Engineering (3rd Edition)”, Prentice Hall Publications.

[14] Allen, Arnold A. “Probability, Statistics, and Queuing Theory: With Computer

Science Applications”, Gulf Publishing.

[15] http://www.emc.com/storage/symmetrix-vmax/migration.htm. “Open Replicator”,

EMC Corporation

[16] http://www.emc.com/storage/symmetrix-vmax/srdf.htm. “SRDF for Symmetrix”,

EMC Corporation

[17] http://www.netapp.com/us/products/protection-software/snapmirror.aspx.

“SnapMirror”, NetApp Corporation

http://www.emc.com/storage/symmetrix-vmax/migration.htm

http://www.emc.com/storage/symmetrix-vmax/srdf.htm

http://www.netapp.com/us/products/protection-software/snapmirror.aspx


Biography

Suhas Joshi is an Advisory Solutions Architect within EMC Corporation’s Global Services

organization. He serves on the Enterprise Architecture and Standards (EAS) team within the

Application, Architecture, Design, and Development service line.

Since December 2011, Suhas has been leading a major effort involving data center

virtualization, migration, and consolidation. His background includes firmware and application

software development, application integration, and project and program management. Suhas

holds a U. S. patent for an algorithm he developed for fast switching of permanent virtual

circuits. He is a certified Project Management Professional (PMP), Certified Scrum Master

(CSM) as well as an EMC Proven® Professional.

Suhas received a Master of Engineering (Electrical) degree from Cornell University in Ithaca,

New York and a Bachelor of Engineering (Electronics and Telecommunications) degree from

University of Pune, India. He has written several technical papers which have been published in

review journals and has also spoken at major technical conferences.

EMC believes the information in this publication is accurate as of its publication date. The information is subject to change without notice.

THE INFORMATION IN THIS PUBLICATION IS PROVIDED “AS IS.” EMC CORPORATION MAKES NO RESPRESENTATIONS OR WARRANTIES OF ANY KIND WITH RESPECT TO THE INFORMATION IN THIS PUBLICATION, AND SPECIFICALLY DISCLAIMS IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Use, copying, and distribution of any EMC software described in this publication requires an

applicable software license.

table of contents - dell · 2020-07-06 · the value proposition offered by data center...

Documents