Safe and Secure Data Migration It s Not That Tough

Safe and Secure

Data Migration

“It’s Not That Tough”

David Clark

Agenda

• Drivers for Data Migration

• Why Data Migration is complex

• Seven Gremlins to a Safe DM

Data Migration

Data Migration

Leading Drivers

• End of Life/lease on storage systems

• Technology transitions

– Speed changes on FC 2Gb – 4Gb – 8 Gb – iSCSI, FCoE

• Operating Systems and Application Migration

• M&A activities

• Regulatory Compliance

• VMware / Virtualization driven server consolidation

• Storage Consolidation

• Tiered Storage Strategies

Why Data Migration is complex

Data Migration cuts across:

1. Multiple OS and applications

2. Multiple SAN islands & Storage protocols

3. Multi-Vendor Storage

IT Organizations within Data Centers

• Application team

– Manages applications

• Network team

– Manages Networks

• Storage team

– Manages storage

Data Migration involves interactions

amongst many IT teams

Storage

Different Types of Data Migration

• ONLINE / OFFLINE

– Depends on how much down time application can tolerate

• Local

– Within Data Center

• Remote

– Migration of Data Centers

• Across Storage Protocols

– FC, iSCSI, FCoE

• Many-to-one

Customer Concerns re: DM

1. Downtime

2. Human error

3. Data corruption

4. Infrastructure incompatibilities

5. Departmental conflict

6. Costs and resources

7. Poor planning (too many details)

Data Migration Methods

• Manual Methods

• Software based

• Network based appliance

• Array based

Manual Methods

• Backup & Restore

– Simple to use

– Protects Meta Data

– Requires Backup device – Extended down time – Expensive

– Requires scheduling with backup windows

• Manual copies

– If small amount of file-based data set, most inexpensive method – For repetitive work, develop scripts

– Tedious & prone to human error

– Must ensure the copy of application metadata – Extended down time

Software only Migration

tools

• Typically installed on the server

• Manages Migrations at Volume level

• Supports Migration

– From DAS to SAN – SAN to SAN

• Independent of Storage and SAN

• OS Specific

• Need a different tool or version of SW per OS type • Compatibility with many

different versions of OS and software is required

• Server Reboot Required after install FC SAN Source Array Servers Target Array Migration is OS vendor dependent

Software Migration Steps

1. Schedule application down time

2. Storage Manager kills Application Manager (or whatever is needed to load DM agents/apps)

3. Ensure that Agent/App supports proper OS release(s) 4. Create volume-to-LUN map

5. Take application offline

6. Run migration for selected volumes/LUNs 7. Rezone new storage to application

Network Based DM Tools

• Deployed in the Network • Independent of Operating

System & Storage Array • Block based migration tool • ONLine / OFFline Migration

• Today’s DM tools work only in a vendor specific Network

• May require a specific Fabric infrastructure already installed

• Cumbersome to setup

• Downtime during install

• Expensive

• May require new multi-path SW

FC SAN Source Array Servers Target Array Fabric Vendor Dependent

Network DM Steps

1. Determine fabric-based or direct-attach 2. Network Manager kills Storage Manager

a) Attach and zone new device

b) Disconnect storage and rezone

FC SAN Source Array Servers Target Array Fabric Vendor Dependent

Network DM Steps

3. Ensure fabric compatibility

4. Determine which Apps/LUNs to be migrated

5. Schedule downtime for some Apps

(SAN-attached) or all Apps (direct-(SAN-attached)

6. Reboot server/Apps to new storage

FC SAN Source Array Servers Target Array Fabric Vendor Dependent

Storage Array based

Deployment

• Software License on an array • New class of array

Independent of Operating

System and Fabric vendors Cost effective if used in very

narrow use case

Incompatible across

heterogeneous storage • SW often not compatible

within different family of arrays even from same vendor

• Software License tied to a specific array, allows

migration in and out of that specific array

Array-based Steps

1. Check array family compatibility

2. Acquire and load license for EACH array 3. Determine Volume-to-LUN map

4. Take application(s) offline 5. Perform block-level transfers 6. Rezone and reboot

FC SAN

Source Array Servers

Target Array

Need for DM tools

Must be Independent of:

 OS, Fabric, Storage Vendors

LUN 3 LUN 2 LUN 1

FC SAN

Old Storage New Storage

LUN 3 LUN 2 LUN 1 Migrated LUNs

Server “A” w/ LUN 1 Server “B” w/ LUN 2 Server “C” w/ LUN 3 DATA PATH Data Mover OFFLINE OFFLINE OFFLINE Low cost:

 Small Capital investment  Pay as you go model  Simple to transport

Minimize downtime

 Fast install and configuration  Simple to use

 Associate Server volumes to physical

LUNs

DM Tool requirement for Enterprise

• Independent of :

– Operating System – SAN Vendor

– Storage protocols (FC, iSCSI, FCoE) – Storage Array

• Need to support :

– Online / Offline – Local / Remote

• Many to One

DM Tool requirement for Enterprise

• Least intrusive

– Should not require any changes to Host Software or any other infrastructure already in place

– Should be able to insert ONLINE

• Management

– Manage Remotely

– Simple to install, configure and deploy

– Should provide detailed intelligent migration reports that are simple to understand

– Flexible scheduling of migration Jobs

– Should facilitate communication amongst multiple groups with Data Center – Association of Application Volume to Physical Luns

DM Tool requirement for Enterprise

• Provide Protection against Human errors

– Accidently migrating Destination LUN to Source LUN

– Selection of one of the other Data LUN as Destination LUN

• Security

– Provide the access to Job configuration only for authorized users

– Alerts on unauthorized attempt

• Address cost

– Low capital cost

Enterprise Online DM

1. Install appliance and new storage

(non-disruptive)

2. Create Volume/LUN map

3. Migrate and verify

4. Rezone and reboot

LUN 3 LUN 2 LUN 1

FC SAN

Old Storage New Storage

LUN 3 LUN 2 LUN 1 Migrated LUNs

Server “A” w/ LUN 1 Server “B” w/ LUN 2 Server “C” w/ LUN 3

DATA PATH

Online DM Scenario

• Standard zoning before DM

– Dual SAN, split path

SAN A

Old Storage New Storage

Online DM Scenario

• Rezone dual-path with DM appliance as target for server • Rezone dual-path with DM appliance as initiator for storage • Maintain one server path while configuring the other path

SAN A

Old Storage New Storage

Online DM Scenario

• Simplified topology for illustration

SAN

Old Storage New Storage

Source LUN

Sector 0 Sector N

Destination LUN

Online DM Scenario

• Simplified topology for illustration

SAN

Old Storage New Storage

Online DM Scenario

• Simplified topology for illustration

SAN

Old Storage New Storage

Summary

• Data Migration should be:

1. Managed by one group

2. Independent of OS, Fabric and Storage

environments

3. Minimally intrusive

4. Highly automated – less prone to error

5. Cost-effective

Safe and Secure Data Migration is now possible,

Questions?