tideway foundation and data centre migration

Tideway Systems Inc., 2008 of 18

Tideway Foundation and Data Centre Migration

Version No 1.0


1. Contents 1. Contents ............................................................................................................................ 2

2. Preface............................................................................................................................... 3

2.1. Purpose........................................................................................................................... 3

2.2. Document History ........................................................................................................... 3

3. Data Centre Migration ...................................................................................................... 4

3.1. A common approach....................................................................................................... 4

3.2. Common Issues .............................................................................................................. 5

4. How does Tideway Tideway Foundation help?............................................................. 6

4.1. Key Benefits .................................................................................................................... 6

4.2. Tideway Deployment ...................................................................................................... 7

5. Example Output ................................................................................................................ 8

5.1. Full Infrastructure Baseline ............................................................................................. 8

5.2. Full Server Detail ............................................................................................................ 9

5.2.1. Example Passport.................................................................................................. 11

5.3. Dependency Information............................................................................................... 12

5.3.1. Group communication............................................................................................ 12

5.3.2. Software Communication from a Server................................................................ 14

5.3.3. Business Service Dependency.............................................................................. 15

5.4. Lifecycle Management .................................................................................................. 17

5.5. Hardware Reference Data ............................................................................................ 17


2. Preface

2.1. Purpose

This document describes a common data centre migration programme and illustrates how

Tideway Tideway Foundation discovered data is used to understand the existing estate and de-

risk the transition to a new environment.

2.2. Document History

Date Version Details

22nd

April 2009 0.1 Initial Draft

22nd

April 2009 1.0 Final Draft. M.Wallenstein


3. Data Centre Migration Data centre migrations are complex to plan and execute. A great deal of preliminary work is

required to minimise project over-runs and unplanned downtime. The fundamental component

of planning a migration is a clear and complete understanding of the current infrastructure. This

includes all of your hardware, software and dependencies.

3.1. A common approach

The high level process below describes a common approach to planning and executing a data

centre migration.

The crucial initial steps involve gathering intelligence of the existing estate. This information is

vital for planning the new data centre, de-risking the transition, and helping to understand

opportunities for consolidation or virtualisation on the way.

•Manual inventory of

servers

•Manual host-host

diagrams

•Manual host -

application dependency

diagrams

The DC Move Process

>1 Year Cycle

UAT

Handover

to Support

As is Picture

Risk

Analysis

Perform

Migration

Backup Prepare

Migration

Create

Plan

Backout

Go/No go

Go/No go

Go/No go

Standard

Migration

Methods

Manual audit

Audit and due

diligence phase

Design phase

Transition phase

Design

new DC

Schedule Awareness

Campaign


Typically a ‘passport’ is created for each system and/or business service that will be moved.

The passport details all of the steps in the relocation process that a business service or system

must go through.

The passport also includes significant detail about the business service or system, as well as

the owners of the systems that must sign-off at each stage of the move.

Once passport creation is completed the full planning and design phase can begin. This would

normally include a migration plan as well as a backup plan.

In the transition phase the systems and services are moved, tested, and backed out or fixed as

required.

In order to carry out such a significant task effectively and with minimal service disruption it is

vital that the underpinning data is accurate and up-to-date.

3.2. Common Issues

A significant number of errors arise due to the quality of the data used to plan, design and

execute the move. Data describing systems and business services for a typical data centre

move are normally supplied from manual audits and a selection of management agents (with

limited estate coverage).

Issues normally associated with these data sources include:

• Manual audit data cannot provide a complete picture of the environment

• Time to baseline the estate is very slow, typically 0.3 – 2 days per server

• Cost of manual audit; typically 85% more than auto-discovery solutions

• Inaccuracies in knowledge captured from application owners, as opposed to the ‘as-is’

deployed state of the application

• Audit data can quickly become out of date before the move; increasing the risk of

downtime

• No way to automatically track the progress of the migration during the lifecycle of the

migration project

Taking into account these issues, the data centre migration project can be seriously impacted

by fixing errors on the fly and backing out of moves due to unexpected configuration changes.


4. How does Tideway Tideway Foundation help? Tideway Foundation helps by providing the critical ‘as-is’ view of the estate in a single

repository. Agent-less discovery will rapidly build a view of servers and their configuration,

software running, and dependencies to and between critical business services. Importantly,

Tideway Foundation is able to continue discovery on a daily basis to ensure that the

configuration data is kept up to date right up until the move date.

By grouping servers and software components into logical business services planning and

design decisions can be made with greater confidence, subsequently this data can be used to

de-risk the transition phase significantly.

4.1. Key Benefits

Tideway Foundation provides full configuration information for servers and business services,

as well as many reports and dashboards which aid planning and transition phases as well as

tracking progress of a migration.

• Detailed discovery data per server and business service. Subsequently reduce time,

cost and risk of the project.

• Better visibility of changes that need to be re-planned

• Automatic detailed passport generation per server.

• Upstream and downstream dependencies for business services.

• Hardware reference data and OS & Software EOL – highlight systems that may be

possible candidates for removal/consolidation.

• Lifecycle management views to track migration process in new data centre.


4.2. Tideway Deployment

The following chart describes reporting coverage during a typical Tideway Tideway Foundation

deployment.

Presuming all pre-requisites are met prior to deployment it is possible to attain rapid coverage of

the estate. From the very earliest discovery of the estate useful data can be extracted from

Tideway Foundation.

Agent-less discovery provides a significant head start for data centre migration projects;

coverage can be attained rapidly, and data can be captured and updated on a regular basis.

• IP addresses of devices

• IP to DNS mapping

• Partial default HW and SW reports

• Partial default HW and SW dependencies reports

• Partial host - host visualizations

• Partial SI - SI visualizations

• Partial count of network connections

• Partial utilization and distribution dashboards

• Host count progress line chart

Day 1 Week 1-2 Month 1-2

• Partial HW and SW reports

• Partial HW and SW dependencies reports

• Partial host - host visualizations

• Partial SI - SI visualizations

• Partial count of network connections

• Partial utilization and distribution dashboards

• Software Instance Report with unique SI type and host

• Citrix Servers and Software Instances

• Citrix Servers’ Installed Software Packages

• Complete host - host visualizations

• Complete SI - SI visualizations

• Complete Process-to-process visualizations

• Report for each host including HW and SW info as well as current communications excluding local-only communications

• Utilization and distribution dashboards

Estate coverage


5. Example Output Tideway Foundation supplies various ways to report and consume the discovered data. These

include:

• Management Dashboards

o Graphs and pie charts

o Tabular reports

• Out of the box reports for software

• Custom report capability

• Export Capability to CSV and RDMS

5.1. Full Infrastructure Baseline

Once credentials are available for discovery, Tideway Foundation will rapidly build a baseline

view of the estate; number and type of servers, Operating Systems deployed, hardware vendor

coverage:

Infrastructure breakdown

Track server footprint over time

Identify non-standard OS

Identify virtual servers


High level view

• Hardware vendor

• Services supported

• Link to running software

Contextual data included by

dynamic SQL query or CSV

import

Full OS details; type, version,

patches, packages

OS End of Life & Support details

5.2. Full Server Detail

Full details regarding servers can be viewed and reported upon within Tideway Foundation as

well as exported to CSV and Passport PDFs.


Server detail continued:

NIC Details, links

to switch and port

from CiscoWorks

HBA Details


5.2.1. Example Passport


5.3. Dependency Information

Tideway Foundation will identify dependencies in 3 scenarios:

1. Groups of servers observed communicating

2. Network communications from an individual server and its software components

3. Dependency from a business service perspective

Each of these views provides powerful visibility of the impact of moving servers. Understanding

server and software communication allows better planning and de-risks the migration process.

5.3.1. Group communication

This view is automatically discovered and visualised. Groups of servers that are observed

communicating are generally indicative of a business service being present.

Server Groups communicating:


Drill through to a group of servers:

From the visualisations it is possible to drill through an icon to view the detail regarding the

servers.


Auto generated server & software dependencies

Server

Software Network Communication

5.3.2. Software Communication from a Server

This view is available from each server that has been discovered. The dependency information

is gathered automatically during discovery (subject to pre-requisites being met), and is

automatically visualised.

This view describes the software communication from the server at the top of the image to

software components running on other servers. From this view it is reasonable to infer that if

the software component at the top of the image is moved or stopped it may impact the other

software components and servers that is communicating with.


5.3.3. Business Service Dependency

Using the discovered data described previously, a short modelling exercise produces a pattern

that will automatically identify and group components into logical business services in the

estate. This provides a business perspective of the underlying infrastructure:

Logical Business Service

Software

Components

Servers

Edge network


Once several business services have been modelled it is possible to view dependencies

between business services:

Again, these views enable better understanding of change impact during a migration, and allow

better planning of the transition of critical services.

Mail Hub London Instance

Dependency links to

other Business Services


5.4. Lifecycle Management

Tideway Foundation’s Lifecycle Management feature allows the user to define views on the

discovered data. In this example the user has defined a view that shows the footprint of

physical servers being migrated into a new data centre:

Each line has a link to a server that has been discovered in the new estate. Against each

server is a status; ‘Current’ – meaning that the server has been seen by discovery, and

‘Expected’ – a field that is updated by the user as new servers are alerted to him by discovery.

As servers are introduced into the estate and discovered their initial status will be ‘Unknown’ –

the user checks the migration plan to confirm the move date for the server and whether that

server should be in the estate. If the server has been moved as planned the user can update

the status to ‘Expected’.

This feature allows a fine level of control when reviewing the progress of the project lifecycle.

Additional views can be created to track the migration of business services; ensuring that they

have been migrated and reconfigured correctly.

5.5. Hardware Reference Data

Data centre migrations provide an opportunity to attempt to identify servers that are redundant,

obsolete, candidates for consolidation or virtualisation. Much of the data provided by the

Tideway Foundation baseline helps with these activities. Armed with the data regarding

hardware models, software running, network communication activity it is possible to identify

servers that should be examined in more detail to determine their best use.


Tideway Foundation’s dashboards allow the user to drill straight into this pertinent information.

This dashboard provides various views of server hardware based on different metrics.

Additional hardware data is supplied by Tideway via the monthly Tideway Knowledge Update.

This dashboard provides a breakdown of servers by:

• CPU speed and count

• Host type and RAM

• Compute power by BTU/h (heat output)

• Compute power and Watts (peak power consumption)

• Servers with RAM gap (servers that can have more RAM installed)

Each of these reports provide a list of servers that are potential candidates for optimisation

through consolidation, upgrades or removal.

Breakdown by power consumption

Breakdown by BTU/h

Servers capable of having more

RAM installed

tideway foundation and data centre migration

Documents

new data centre

wallenstein tideway

migration plan

underpinning data

tideway deployment

common approach

hardware reference data

data centremigration