With the growth of your business, there is a good chance that your storage environment will not be as good. Data migration projects in a SAN environment are labor intensive and complex. But with good planning and the checklist set out in this article, your project will not exceed the time and budget.
In general, data migration is simply moving data from an old storage array to a new one. But this is ultimately wrong. Moving data is only a small part of data migration and usually the easiest part.
The migration process consists of a series of manual and intensive tasks. SANpulse Technologies, a storage migration company, identifies 43 distinct tasks. Only six of these tasks are semi-automatable and 37 of them require a lot of human work. They range from pre-planning analysis to migration execution, disabling existing systems, migration validation, data integrity verification, and final cleanup and recovery. documentation
Many of these tasks are repetitive actions. For example, consider discovering and collecting data from physical and virtual servers. All processes must be repeated for each server. But it’s server remediation – make sure it starts, is up-to-date, has the right drivers, microcode, and storage adapters, that it works with the new SAN, that it has the right directories, etc. – which requires a lot of time and effort. And such remediation must be done for each physical and virtual server. This represents many steps for a single task.
The following is a list of 43 tasks that SANpulse has developed to perform a complete SAN data migration . These tasks are divided into six steps to facilitate organization and planning. All tasks are listed below.
Step 1: Collect data before migration
The first step in a data migration is to collect and correlate all host and array data needed for the migration.
The tasks to be performed in this context are:
Identify hosts for migration
Collect data from the migration host (host audit);
Collect data from the storage array (bay audit);
Group information about areas and masks;
Correlate all the data.
Step 2: Establish the remediation rules
There is a need to assess storage remediation and repository requirements before beginning data migration. This process minimizes errors while putting in place procedures to handle the correct patches.
The three tasks to be performed are:
Analyze the migration and sanitation of the target;
Remediation of the host;
Document versions and compatibility of source software and target storage arrays, and correct any incompatibilities.
Step 3: Preparation Phase
This step consists of preparing hosts and source and target storage systems for migration. The 18 tasks involved are:
Configure the source and the target storage array for ease of migration;
Create the link between the source and the target bay
Collect all host storage configuration information, including installed operating system, cluster status, and disaster recovery system
Collect the configuration of each array, including the RAID, the Front-end (FA) port, and the status of each local and remote replication;
Collect SAN configuration, including managers, switches, and gateways
Plan the layout of the storage space on the target bays;
Create configuration scripts for migrating and matching source and target arrays;
Create configuration scripts for FA port mapping and LUN assignment in target arrays;
Create the LUN masking scripts for the target arrays;
Creation of the definition scripts for device aliases;
Prepare the SAN zoning host ;
Group host migrations in cooperation with the operational units;
Update all backup and restore scripts;
Run all host audits before the migration;
Create and execute the relationship matching scripts R1 to R2;
Create and execute the mapping and masking scripts for the target arrays;
Apply all host zoning configurations;
Confirm host connections to the target storage array.
Step 4: Start the migration process
All of the following tasks are required to migrate the data to a new storage array. They range from backup or data protection to stopping applications, stopping hosts, and creating scripts to link to the new array. Once the migration is complete, the tasks are reversed. This will restart the host applications. Specific tasks to follow are:
Start of data migration to the new array
Capture, replicate, or back up all old host configurations;
Sleep (shutdown) the applications, and then shut down the hosts;
Create and execute the scripts that will distribute the new relationships between bays 1 and 2 as soon as the data has been synchronized;
Verify and validate data from host backups
Restart the applications;
Obtaining a validation of business departments so that data migration is considered complete.
Step 5: Validation, restart and cleaning
Validate the migration, re-enable all applications on the new target storage, and disable the old storage system. Research, correct, clean up errors. To do this, you must perform the following tasks:
Check if there were activities on the old bays;
Create and execute the link deletion scripts between Bay 1 and Bay 2;
Create and execute scripts to remove all devices from FAs on the source array;
Create and execute scripts to clear meta-configurations on source arrays;
Create and execute scripts to unmask the source devices of migrated hosts;
Restart the hosts and confirm the visibility of the new target devices;
Clean areas and remove all unused areas;
Check the final connection table on the old bays;
Update device groups, if any.
Step 6: Final Documentation
Complete, document and validate the migration
Create reports and update them by documenting all the processes performed.
Manual migration against approach with scripts
The majority of data migration projects are managed manually, usually using Excel spreadsheets. This approach requires processes, and most importantly, discipline. Indeed, an excel sheet of data migration must be continuously updated by several administrators.
Scripts are a common alternative. The advantage of scripts is that they can be customized based on the environment, storage, servers, applications, vendors, and infrastructure. Nevertheless, the bad point: these scripts are rarely documented, tested, corrected or updated. They usually need to be rewritten for each SAN data migration project. The scripts always seem like a good idea … until they are implemented.
These data migration technologies save time
It is possible to implement four different technologies in order to limit the manual tasks of a data migration. While each has trade-offs, they can all dramatically reduce workloads and errors:
Use programmable physical storage appliances or virtual SDS appliances (VSAs).
Make sure the new SAN is a newer version or version of the old SAN and enable data replication between them.
Use a scalable SAN system.
Use VMware vSphere Storage vMotion.
SDS appliances are generally considered to simplify the migration of SAN data. This solution migrates storage systems behind the SDS appliance or VSA without touching the servers or infrastructure in front of the appliance or virtualization system. The disadvantage: these appliances add very significant costs that increase the total cost of ownership. In addition, the complexity is increased by having to manage all SDS or VSA appliances, hypervisor resources for the VSA and back-end storage arrays.
In addition, this adds complexity when refreshing the SDS appliance – although this is typically handled by the sequential migration of active-active appliances or scale-out appliances. This is not a problem for VSAs.
Staying with the same storage vendor and using the latest version of SAN being migrated is a relatively common but not necessarily perfect approach. This requires a replication license on both systems and all servers connected to the storage must be reconnected to the new storage. This is usually a solid workaround.
The use of a scalable SAN has grown in popularity. With these systems, processing and capacity can be transparently upgraded in the data center. After the data migration, the old node is simply removed. We clean and then repeat the operation until all the nodes are upgraded. Applications, servers, virtual machines (VMs) and connected containers are not disrupted by this approach and this eliminates the need to migrate data. Just add a new node and remove the old one. The data is quickly rebuilt on the new remaining nodes.
VMware Storage vMotion has become a popular alternative. The VMware solution migrates data from each of the SAN bay LUNs assigned to that VMware server to the LUNs in the new SAN array. VM virtual LUNs do not change, masking the actual physical change in the storage arrays. The disadvantage of this approach is that it only works for virtual machines running in a VMware infrastructure. The solution also does not provide SAN remediation or VMware host remediation. In addition, it does not move data from LUNs that are not assigned to that particular VMware host. There is also no test or validation of data migration.
Of course, these four alternatives all involve a commitment to their supplier. The first requires a commitment to the SDS provider, the second to the storage array provider, the third to the scalable storage provider, and the fourth to VMware.