Data Center Migration

Note: This blog is written with the help of my friend Rajanikanth

Data Center Migrations / Data Center Consolidations
Data Center Consolidations, Migrations are complex projects which impact entire orgnization they support. They usually dont happen daily but once in a decade or two. It is imperative to plan carefully, leverage technology improvements, virtualization, optimizations.
The single most important factor for any migration project is to have high caliber, high performing, experienced technical team in place. You are migrating business applications from one data center to another and there is no scope for failure or broken application during migration. So testing startegy should be in place for enterprise business applications to be migrated.

Typical DCC and Migrations business objectives

Business Drivers

·            Improve utilization of IT assets

·            DC space & power peaked out - business growth impacted

·            Improve service levels and responsiveness to new applications

·            Reduce support complexity

·            Reduce IT costs (facility, staff, power, # of servers, taxes etc)

Data Center Migration Strategy

The Migration Strategy looks like this:

§  Data Center Migration projects usually organized in 3 to 4 phases

1.     Assessment and High Level Planning/Strategy

§   During the initial assessment phase each of the applications in scope will be analyzed and categorized according to criticality, complexity and time to move.

2.     Detailed Planning

3.     Migration execution

§  Migration Schedule will be developed after assessment

•          Migration schedule is based on

§  Risk

§  Resource Contention

§  Complexity

§  Migration Type (P2V, V2V, Build New, Forklift)

§  Migration schedule assumes WAN throughput available to support  data (GB/hour)  transfer rate from old data center to new facility

§  Waves or Move group created and mapped according to complexity of applications; workload spread over multiple weekends

§  Applications will be grouped according to dependencies

§  Current support of customer required for migrations during waves

Various Approaches to Migration

Migration strategy	Strategy to minimize required downtime	Strategy to minimize risk of failed cut-over
Physical to Virtual (P2V)	P2V requires 2 down times    P2V    Cut-Over	P2V brings a copy of the production application The copied application (non-production) can be tested as long as required
Virtual to virtual (V2V)	V2V requires 2 down times   V2V   Cut-Over	V2V brings a copy of the production application The copied application (non-production) can be tested as long as required
Build New	Build New only requires 1 down time for the cut-over.	Build new brings a copy of the production application The copied application (non-production) can be tested as long as required
Forklift	Downtime required by forklifting the hardware prohibitive (several days)	Risk of transporting old hardware prohibitive
Swing	Swing only requires 1 down time for the cut-over.

Physical to Virtual (P2V) Conversions

The Physical-to-Virtual (P2V) is one migration approach for taking a standard physical device and generating a new virtual machine automatically based on the physical device’s configurations and settings.  To accomplish a P2V migration, tools such as VMware Converter, Leostream’s P2V tool or Platespin’s Power Convert software are often utilized.  Requirements for this migration option include:

·                     Need to purchase P2V or Power Convert licenses

·                     Limits on data size when transferring across the WAN

·                     Approximately 24 hours downtime required for cut-over

·                     No non-standard drivers can be installed on the existing device

The P2V tools provide a feature called synch which gives option to do final synch after doing a full P2V image. The final delta changes can be synched during cutover window.

It is not uncommon for a P2V migration to fail/hang, therefore requiring the creation of a new virtual machine from scratch.  This risk needs to be taken into consideration when planning for application downtimes. 

Virtual to Virtual (V2V) Conversions

Existing virtual machines that are to be migrated to a different host machine in the target data center, it is possible to copy the logical server from the source VM to the destination VM.  This migration option is accomplished using the same tool(s) as the P2V option.  An advantage of this option is that the complexity of and time for testing is significantly less that other options, since the existing server is already virtual. However, it is still important to note that for a V2V migration to be possible, both the existing and future host servers must be running compatible ESX versions.  Limitations on storage size requirements should also be considered.

Rebuild New

Server that either do not meets hardware standards or have hardware issues (for P2V to go through) and application support team is comfortable to do this can be rebuilt from scratch on target VM.  This option is can be chosen when it is more cost-effective to build new than to purchase a P2V licenses.  It is important to note that with this option:

·         OS and Applications must be reinstalled

·         Installation Software and licenses must be available

·         Longer time is needed for setup

·         Business must be able to afford downtime of related IT services

The alternative to avoid business downtime is to for a Swing Approach on target VMs, which is non disruptive. However rebuild always takes longer time than any other migration approach.

Swing is a traditional migration method where target environment including hardware, OS, software are built from scratch and original environment is not affected.

Once target environment is thoroughly tested, than cutover from physical to virtual environment.

Forklift Migration

When a server is Forklifted, all of its configurations and properties must remain as-is.  Upon arrival at the target data center, the device should boot up properly with only minimal changes needed (e.g. – IP/DNS changes).  As an alternate approach, IP address configurations could also be changed prior to system shutdown at the local data center.  Servers selected for the Forklift option either have specific utilization requirements, are not up-to-par in terms of hardware standards or are set to retire in the near future. 

For a server to be Forklifted, the following should be considered:

·         Business must be able to afford significant downtime

·         Full backup of all systems is required

·         Reboot needed prior to full shutdown

·         Network changes necessary (IP, DNS, etc.)

·         Firewall updates may be required

Clone

Cloning a server involves making an exact replicate of the server onto a different physical device.  To clone a server, software tools such as DRD Clone (HP-UX), Symantec Ghost or Robocopy are typically utilized.  When cloning a device, the following should be considered:

·         Minimal downtime for applications

·         Identical hardware required – test needs to be done if it works on VM

·         Network and firewall changes necessary, unless on same LAN segment

·         Temporary software licenses may be need for applications.

·         Recommended to do POC

Database Migration

All the leading database vendors provide export/import programs in order to dump the contents of a database

to a file that can be transferred to the destination environment and imported again.  The export file will contain whatever it is specified to contain at the time of the export.  It can contain definitions of all database objects, including tables, views, grants and stored procedures that make up a complete database instance.  The export binary file is normally compatible across operating systems and versions of the Relational Database Management System (RDBMS).

This approach is the preferred migration alternative for databases and will be used when downtime is allowed

Typical Implementation Plan for Server Migration using P2V Approach

•       Phase I - Discover the server (One weekend before cut-over)

•       Install two server in Source DC (Image Server and Convert Server)

•       Un-hardening server for discover

•       Phase II - First Image the server and transfer the data (First Week)

•       Make the image for all servers

•       Send the image data from Old DC to New Data Center

•       Phase III - Final Sync (Next Week)

•       Open the firewall port for the server sync

•       Final Sync and change the service load to new server

•       Hardening the new server and setting firewall rules back

•       Phase IV - Decommission the Old Server (Post Action)

Decommission the Old Server

Data Migration Strategy

Large amount of data migration options:

§  Storage Array Based (Recommended)

§  Host Based (Volume Managers, P2V Tools)

§  NFS – Mostly for Unix only

Backup to Disk (Next to Array based, this is recommended) and ship the disk and restore. From a technical standpoint, the current and target server (VM) must have compatible drives / hardware in order to write and read the shipped tapes.

  

Data Center Site Strategy

Option 1

•          Single Global Data Center (Tier 3 or Tier 4)

•          One large DR site

•          Active - Passive

Option 2

•          Single Global Data Center ( Tow Tier 3 sites managed as one)

•          One small – medium DR site

•          Active – Active – Passive

•          More GDCs for companies with aggressive consolidation targets

•          Dedicated DR site not required with multiple GDCs

DC Classification	Tier	Hosting
Global Data Centers (GDC) Tier  3 - 4	•       5-9s availability •        Site redundancy •        24x365 staffing •       Two independent utility paths • 2N power and cooling systems • Able to sustain 96 hour power outage • Stringent site selection criteria	. ERP . Mission   Critical . Extremely high cost of downtime
Regional Data Centers Tier  3	• Two utility paths (active and passive) • Redundant power and cooling systems • Redundant service providers • Able to sustain 72-hour power outage • Careful site selection planning	. Majority of revenue from online business . High dependence on IT . High cost of downtime . Latency &bandwidth sensitive App’s . World-wide presence
Regional Data Centers Tier 2	• Some redundancy in power and cooling systems • Generator backup • Able to sustain 24 hour power outage • Minimal thought to site selection • Vapor barrier • Formal data room separate from other areas	• Some amount of online revenue generation • Multiple servers • Phone system vital to business • Dependent on email • Some tolerance to scheduled downtime

Introduction to Data Migration

When it comes to Data Migration in a Data Center Migration / Consolidation projects, some typical questions asked are:
- How do I migrate my SAN data
- How do I migrate my DAS data
- How do I migrate my Operating System Volume Groups
- How do I migrate all this data across data centers
-What is WAN link bandwidth
-What is total Storage I'm looking to migrate
-Can I migrate data given the downtime and meet my SLAs..
-How do I migrate my Database data

The answer is, it depends. It depends on the customer environment. No one solution fits all. As discussed else where in this blog, doing a proper discovery / assessment of the existing environment, re-use what existing methods/tools already existing, minimize service downtime, and most important, making sure applications are not broken during migration are key.

At conceptual level, data migration can be classified into following:
  1 - SAN (Storage Area Network) based
  2 - Host based

SAN based: with this method, SAN replication tools already existing can be used. Not necessary that SAN replication is configured between source data center and new data center. It can be used where the strategy permits. Eg:- EMC SRDF, SAN Copy, HP Continuous Access etc..
Host Based: This consumes some host based CPU cycles, but less expensive or where no SAN based technologies available. eg: Volume Mangers like - VxVM mirroring, TDMF

There are even more traditional OS based tools, mostly for unix - tar, cpio, rsync etc..these does the job and even have incremental transfer and final sync when rsync is used.

There are other vendor tools like PlateSpin Migrate, VMware Converter which are specialized for Windows/Linux workloads. PlateSpin for example is not free. It is licensed  based on per conversion or workload.

And when migrating database like oracle, it is always recommended to use oracle tools in combination with SAN replication methods. 
For OS, a jumpstart image, flar image, Ignite-Ux recovery image etc..based on OS flavor will do. When you are migrating from old storage array to a new storage array, side by side, a simple Volume Mirroring is best approach. Or what about backup & restore when none is feasible.

So it is all depends on the environment.
For example - 
what is best approach when moving from old array to new array side by side (technology refresh)
what is best approach when migrating data across data centers (DC Migration)
what is best approach when consolidating storage from DAS(Direct Attached Storage) to SAN

Data Migration Methods

	Controller based	SAN based	Host Vol Mgr	Host SW Mirroring	DB Exports	DB table copy	Standby DB	File/image copy	Backup/Restore	TDMF
Migrate all host OS	yes	yes	no	no	no	no	no	no	no	no
Storage devices supported	same type	most	all	all	all	all	all	all	all	all
Migrate direct connect devices	no	no	yes	yes	yes	yes	yes	yes	yes	yes
Migrate on-line	no	no	yes	yes	no	no	yes	no	no	yes
Change data distribution	some	some	some	yes	yes	yes	yes	yes	yes	yes
Change LUN geometry	no	no	no	yes	yes	yes	yes	yes	yes	yes
Change striping, sector offset	no	no	no	yes	yes	yes	yes	yes	yes	yes
Uses host software	no	no	yes	yes	no	no	no	no	no	yes
Need DBA	no	no	no	no	yes	yes	yes	no	no	no
Moves host appl and data	yes	yes	yes	yes	no	no	no	yes	yes	yes
Distance migration	yes	yes	no	yes	no	no	yes	no	no	yes
Uses host TCP/IP for distance	no	no	N/A	yes	N/A	N/A	yes	no	no	yes
Throughput (typ MB/s)	75-150	50-160	50-120	25-60	30-150	30-150	N/A	75-150	20-80	30-150
Throttle speed	no	no	no	no	no	no	no	no	no	yes
Interruptions	1	1	0	1	1	1	1	1	1	2
Addl software purchase req	yes	no	yes	yes	no	no	no	no	no	no

Data Center Optimization

Data Center Optimization

Data Center Migrations and Consolidation gives an opportunity for Data Center Optimization which consists of leveraging virtualization opportunities to optimize server utilization, storage tiring, Application performance over the network and server sprawl, network optimization. It also includes green IT initiatives like Power & cooling efficiency, Floor space

Consolidation & Virtualization

•        Virtualization will reduce the no. of servers in data center reducing required server power and consequently the size of the necessary cooling equipment.

•       Increase server utilization by consolidation multiple standalone workloads to virtual servers

•       Increase availability by utilizing virtual environment options like clustering across virtual servers

Storage Optimization

•       Use Tiered Storage to efficiently utilize high end storage and by migrating less-critical information to low-cost storage

•        Choose right RAID level (RAID5, RAID10 etc)  to improve application performance based on application usage patterns (read intensive vs write, large block vs small , random vs sequential etc..)

•       Move from DAS to SAN and consolidate SAN islands

•       Consolidate multiple instances of  databases instances to single instance using  Oracle RAC on high end, high performance, tiered storage

Network Optimization

•       Leverage data center consolidation to move from Application traffic over WAN to internal traffic in LAN

•       Use edge caching to improve application performance

•       Utilized FCOE instead of  traditional approach  of separating data and storage traffic across Ethernet and fiber channel

•       Consider WAN Accelerators for multi-tier applications with WAN latency bottlenecks

 Automation

•        Automate Server administration tasks – OS provisioning, patching, configuration, security compliance  etc. e.g.: 100’s of patches can be applied to Solaris using  Opsware SAS (now HP SAS) automatically without manual intervention in short change window