Nadeem Mohd, Cloud Principal Consultant at Tata Consultancy Services
Datacentre (DC) Migration from incumbent vendor to your datacenter or cloud gets sometime challenging considering that incumbent vendor is reluctant to provide sufficient required information. Here are few tips which helps to achieve your goal fast.
Understanding Incumbent Vendor environment
Assessment and Discovery:
This step might have been completed by your pre-sales team and you have a excel or CMDB report in your hand with tons of servers, fileshare, application list with their resources (cores, socket, memory and storage size). However you still need to know few more important details to plan your migration i.e
What’s SAN storage and their connectivity? Is it iSCSI, FC based? Could you connect storage directly to your DCstorage SAN fabric. This is an important step to decide which will help to shorten your timeline drastically. If you are able to directly mount this storage to your DC SAN fabric or to VMware infrastructure i.e as VMFS filesystem to VMware ESXi. Voila!! you are half done.
Migration Links (Defaul link? 10g network or 16g SAN)
This is most important task to choose among the options of L2 extension, MPLS connectivity, public network (FTP, fileshare) or Routed L3 network. The most preferred option is go with L2 extension and choose the network bandwidth wisely in order to comply the total time in hand. This option give you much flexibility in terms of IP mobility or a small chunk of server Choosing 10G is easiest and expensive option which is mostly recommended in normal case, however, this purely depends upon the total number of workload, time in hand and incumbent vendors datacentre core LAN network. If the source datacentre is not supporting 10g network or mostly the workloads are on 1g, then its no worth to invest on 10g for migration link.
Apart from Network connection, you also need to consider the SAN FC link connectivity from the source DC, in order to consider your migration approach whether it would be host based or storage-to-storage mirroring. The later option is recommended however, this option is rarely allowed unless your customer do have a dedicated storage and SAN network. Often incumbent vendor do not allow to avail this easy option
Other bottlenecks from source server upto yours host:
Choosing only the 10g migration link not solving your timeline issue unless you are quite on jet on other component which are in series. If source DC network infrastructure is completely on 10g network but they are using the slower disk storage i.e. SATA disk or near line disk would reduce the overall migration window. So you have to choose your investment on migration link wisely.
Choosing Right Database Servers Migration Approach
Among Oracle, MS SQL or other database migrations method, I recommend to you use instance by instance migration without changing the DB instance or cluster Virtual IP (VIP). This option to be availed by creating MS SQL cluster setup on a temporary IP address and perform the Database backup and restore from source to target. During cut-over shutdown the source DB server/cluster and retain the DB instance VIP. This method would drastically reduce the troubleshooting setup since we are not touching the application side changes or we don’t need to bother how many application or where the corresponding DB is being accesses leaving a big job untouched.
Migration Tools: Physical vs Virtual (P2P, P2V, V2V, AIX, Oracle)
Where its is mandatory to retain the physical structure of server to physical only, we should consider the P2P (physical to physical) migration. Platespin Migrate or Doubletake Move could perform this job efficiently. Even you can move a multi node cluster environment to your DC. For P2V or V2V, VMware converter is quite a good tool without costing you anything.
If you are owing the Oracle Enterprise edition, the Oracle Data guard can do this job quite easily by setting up a passive node in your DB. If the Oracle is standard edition with data guard, then traditional approach of DB backup and restore with incremental changes to be applied. If you can spare few ,000 then use Doubletake Migrate for AIX which seems to be efficient tool for AIX migration in real time keeping your source server up with minimum downtime.
you can also choose some lengthy method of AIX LPAR mirroring if you database is also having some application on it and only DB replication wont help leaving some application behind in source DC.
if you are interested to know more useful tips, please write to me at info@nadeem.in or hansis4u@gmail.com