In the first part to this four-part series, Migration with DataCore SANsymphony – Part 1, we covered why storage administrators are forced to cover migration at some point and what the solution to that may be. Take a look now as we dive deeper into the different type of migrations that can benefit your infrastructures.
MIGRATION TYPE #1: SYNCHRONOUS MIGRATION
DataCore SANsymphony provides both synchronous and asynchronous operations and we will explore both, starting with synchronous.
Synchronous migration refers to migrating the data between two systems that have a relatively-near proximity to each other (typically within 100 km, or 62 mi). In most scenarios, this would represent a migration within the local datacenter, between campuses, or even between nearby cities.
The diagram above shows two SANsymphony engines each with their own respective storage system attached. In this scenario where we will be performing a migration, the underlying storage systems will be placed into a special mode called Pass-Through mode. I will explain this mode in more detail later in this article.
Let’s take a look at what this configuration would look like in the real world within the DataCore Management Console.
The screenshot above shows two SANsymphony Engines, DCSSV01 and DCSSV02 respectively. Under Physical Disks in the tree to the left, notice that the volume (labeled Existing Storage LUN 0) which contains the data we want to migrate, appears as Locked. This is an automatic protection mechanism that SANsymphony imposes to ensure that the LUN remains unaltered until directed by the operator.
The is also true of the other volume on DCSSV02. Under Physical Disks in the tree to the left you will see the volume which will be migrated to (New Storage LUN 0) is also Locked.
IMPORTANT NOTE: Although I am not showing it here, you can re-present the “Existing Storage LUN 0” back to the application server(s) so they can continue working as normal while the migration occurs.
In order to begin the process of migrating the data from the LUN connected to DCSSV01 to the LUN connected to DCSSV02, we must first create a DataCore Virtual Disk. Simply right-click on the Virtual Disks object in the tree under DCSSV01 and select Create Virtual Disks.
The Create Virtual Disk wizard should now be visible. Simply give the virtual disk a friendly name which denotes its purpose, select a disk type of Mirrored, and set a size for the virtual disk to any non-zero value. The size of the disk will be automatically resized later based on the geometry of the source volume. Click Next to continue.
The next screen is where you will designate the physical disk which is backing the virtual disk. Normally this would be a disk pool, however in this case since we are migrating a disk with existing data blocks, we will need to select Pass-Through Disk in the dropdown box for both DCSSV01 and DCSSV02.
The last screen is simply an acceptance screen. Verify that the storage source for each DataCore Engine is correct. In this case, we will be migrating the data from DCSSV01 to DCSSV02.
You will also be reminded that the second pass-through disk (which is DCSSV02 in this case) will be overwritten and the size of the virtual disk will be adjusted to match the source volume.
Once the process starts, you will be presented with the progress of the migration on the Info tab as shown below. Notice that the source volume status is immediately set to “Up to date” and the destination volume status is “In full recovery”. This indicates the migration of data from the “Existing Storage LUN 0” to “New Storage LUN 0”. The rate of migration is also shown in the progress bar on the right-hand side.
Once the migration has completed, the both statuses will show as “Up to date”.
At this point, the data is fully mirrored on both sides. You can now proceed with the migration of additional LUNs. When completed with the migration, you can either split the mirrors, continue migrating other volumes, or simply shutdown the DataCore Engines and remap the New Storage LUNs to the original application servers. All the data structures have been migrated and are now available on the new storage system.