Before and After Series. Data Center Migrations. Data Center Migrations with Legacy Infrastructure

Transcription

1 Before and After Series Data Center Migrations SimpliVity's revolutionary hyperconverged platform based on x86 hardware and VMware hypervisor technology, abstracts data from its underlying hardware to provide unparalleled data mobility, operational efficiency and TCO reduction, while eliminating the high risk and expense associated with the traditional technology refresh lifecycle. With 50x growth projected in the next decade, virtualized data centers must be able to manage, store, protect, and transfer this massive amount of data, which has led to gaps in management, performance, mobility, protection, and capacity that cannot be solved with legacy infrastructure stacks and multiple management consoles. Companies are struggling to keep pace, driving higher CAPEX and OPEX. SimpliVity provides 300% TCO savings across both CAPEX and OPEX. The CAPEX benefits come from the hyperconvergence of 8-12 different hardware appliances into one 2U modular building block. The OPEX benefits come from a combination of reduced maintenance, reduced power and cooling, reduced bandwidth and reduced labor. In this Before and After Series we will demonstrate how much simpler OmniCube is to operate compared to legacy technologies. Data Center Migrations with Legacy Infrastructure 1. Ask: Do we have replica hardware and software at the new data center? o If so, Ensure remote sites are aware of each other and are communicating at all levels. Wide Area Network (WAN). Permissions. Target storage on the remote site. Local storage. Backup servers. Local repositories. o If not, spend hours, days or weeks deciding: How to load balance ESXi hosts in order to provide a phased migration of hardware from one DC to another. How to ensure enough capacity and resource are available at the primary site to continue normal operations. How to mitigate in case of a failure. 2. Configure Replication software. o If array-based, then Ensure you are licensed on both the production side and at the DR site (could be very expensive on a per-tb basis) Open your array-based replication management console or scripts, and repeat as necessary for each different vendor array Assign a disk, LUN or volume for the replicas on the DR site Ensure you have enough duplicate storage on the DR site Set the replication software to on on both sides

2 o If network-based, then Ensure that the sites are able to see each other over a VPN. Make sure that Replication servers are able to ping each other and the necessary firewall ports are configured. Apply local QoS to the network in case of high volume workloads to ensure that production traffic is not affected. Apply QoS to the WAN to ensure production workloads (remote access for users for apps, desktop etc) is not affected. Ensure that the scheduling of the remote replication jobs are staggered so as not to cause a bottleneck, and not to overrun the replication window. 3. Fight for the permission of the application owner to be among the first to move data centers o Ask: Do these applications that we re moving have any dependencies on other applications that will therefore have to migrate simultaneously as part of an application group? 4. Perform a final back up that should be held in the original data center in case something goes wrong. o Then you ll have the ability roll back to a state prior to the attempted move. 5. Obtain agreement with the business on a cut-off time for that application to be finally backed up. 6. Ensure that the backup was successful, quiesced if necessary, and held in a place that is easy to restore from. 7. Design the new site, including: o Designing the IP scheme. o Implementing the new IP scheme once at the remote site. o Attempting to get all of the users to point at the new IP correctly. 8. If certain applications that have dependencies haven t been migrated simultaneously for any number of reasons (politics, scheduling, etc.) then they must either be: o Cloned - and work out a way for it all to co-exist on the same network - and re-ip them on the new site. o Or rely on the WAN to provide sufficient bandwidth for the applications to communicate back to the primary site. 9. If working within a migration window, determine the cut-off point at which any attempted migration and any issues arising therein have to be solved. o If that cut off is breached, roll back to the original site and restore working function before the business resumes operation. 10. Conduct User Acceptance Testing (UAT) on the new site, again before the cut off window for the migration expires, which often requires the involvement of the application owner 11. The issue of running everything in a split datacenter scenario remains until such time as the entire migration is completed, leading to the decision: o Do we perform the migration live, or do we stage this over a period of a number of months and have the whole infrastructure running in parallel, migrating users very slowly over to the new datacenter? Depending on the decision, tradeoffs may be made, including: Buying a lot of hardware to solve a temporary problem. Worrying about getting updated copies of the data/vm s synchronizing on either a set time period, or ideally working in a synchronous fashion. Depending on available WAN bandwidth and migration time allotted, the entire scenario described above may not even be possible, leading to tasks such as: 1. Fly a member or multiple members of the IT staff to the original data center. Often over a weekend. 2. Fly a second storage array to the original data center. 3. Perform local data replication. 4. Fly the member(s) of the IT staff, and the second storage array, to the new data center.

3 a. Often, this includes checking the storage array into the cargo of the plane and/or packing the array in the back of a truck. 5. Pre-seed the new storage array in the new data center. 6. Hope that all of the data has migrated correctly. 7. vmotion the VMs to the new data center. 8. Hope that the data aligns to the VMs that have been vmotioned over. 9. If not, return the IT staff and array to the original data center and start all over again. Data Center Migrations with SimpliVity OmniCube 1. Deploy an OmniCube at the original data center 2. vmotion the VMs and storage vmotion the data. 3. Deploy an OmniCube at the remote site a. Give it an IP and add it to the Federation 4. Right click a VM and click Backup.

4 5. Assign a name and pick a location. 6. The backup has completed and appears in the list of all global backups of that VM, locally and remote. 7. Right click a VM and click Move

5 8. Select the destination and datastore, and click Move 9. The VM has been moved and appears in the new data center, all in the same pane of glass across the SimpliVity OmniCube global federation. In just a few clicks, you ve now performed a data center migration with SimpliVity OmniCube. SimpliVity Corporation 8 Technology Drive Westborough, MA Phone: