摘要：有人说数据迁移不就是从A点转移到B点吗?应该很简单，如果你有这种想法就错了，在IT领域，真正的麻烦在于细节。数据迁移的成败关键在于最终需要的停机时间，应尽最大努力确保停机时间最小化，并确保迁移期间不出现突发问题，下面我将介绍几种最常见的数据迁移情景，以及存在的陷阱。

　　几年前，数据中心最常见的迁移类型可能是操作系统的升级，通常情况下，操作系统的升级是伴随服务器硬件或应用程序升级同步发生的，在此期间，生产数据将不可避免要从一个地方转移到另一个地方。随着数据爆炸式增长和服务器虚拟化技术的普及，今天我们看到的更多是存储系统的升级，与操作系统是否升级无关，虚拟化物理服务器或提供更多存储空间已成为当务之急。
　　
　　有人说数据迁移不就是从A点转移到B点吗?应该很简单，如果你有这种想法就错了，在IT领域，真正的麻烦在于细节。数据迁移的成败关键在于最终需要的停机时间，应尽最大努力确保停机时间最小化，并确保迁移期间不出现突发问题，下面我将介绍几种最常见的数据迁移情景，以及存在的陷阱。
　　
　　从一种存储类型迁移到另一种存储类型时，首先需要正确了解源和目标存储，你对它们的了解程度可能会最终左右你使用的数据迁移策略，面临的风险，以及所需的时间。
　　
　　DAS到SAN迁移
　　
　　最简单，最常见的存储迁移形式可能要数从物理服务器本地，直接附加存储迁移到SAN存储，假设你有一台部门文件服务器，本地磁盘空间已经快用光，为了满足用户的存储需求，你购买了一个新的SAN存储，于是想将用户的数据转移到它上面，但必须不惜一切代价，避免不必要的停机时间。
　　
　　第一步是将物理服务器连接到SAN，不管你使用的是FCSAN还是iSCSISAN，都需要给服务器添加SAN存储连接设备，如果是FCSAN，就需要FCHBA(主机总线适配器)，如果是iSCSISAN，用双端口千兆以太网网卡就行了，完成HBA或网卡的安装不应该超过1小时，同时，你最好在这个时间范围内将需要的软件也一并安装好，避免以后再停机或重启服务器。
　　
　　配置好SAN后，在你的服务器上装载新的数据卷，并格式化，完成后，你的服务器上就拥有一个全新的空卷了，这时你可以预迁移数据副本，很多人在这一步会犯错，总是试图将所有数据全部移走，其实完全没必要这样做，不仅风险很大，数据迁移所需时间往往比你预计的要长得多，特别是迁移包含大量小文件的文件服务器，相反，你应该使用robocopy(Windows)或rsync(Linux，Windows)等数据卷镜像工具。如果配置得当，这些工具允许你将生产服务器上的数据同步到SAN，包括非常重要的安全描述符，因此不需要生产磁盘卷脱机，通过几天的连续同步，非生产SAN存储上的数据就和生产服务器上的文件完全同步了，这样就不需要中断生产系统，如果你要迁移的是数据库服务器，虽然不可能执行增量复制，但你可以通过复制测试确定迁移需要的时间，从而做好停机规划。
　　
　　为了减少迁移时间，需确保没有用户打开或锁定共享服务器上的文件，如果是WindowsServer操作系统，可以停止“WindowsNetlogon”和“Server”服务，这样用户就无法访问服务器上的共享文件了，微软的ProcessExplorer或Linux下的lsof可以检查是否有进程锁定你需要复制的文件，在Windows服务器上，WMI服务通常是罪魁祸首。
　　
　　当你确定源存储卷上没有文件被打开后，就可以开始做同步操作了，遇到复制失败错误时，应仔细阅读错误消息，因为某些系统文件是无法移动的，重点应放在用户数据上。
　　
　　数据完全镜像后，最简单的办法就是交换盘符或挂载点，当然，你也可以修改共享设置和应用程序设置，如杀毒软件的排除选项，指向新的驱动器，最省时的办法还是交换挂载点，如果你的本地数据卷使用的是D:，先将本地卷的驱动器号移除，然后将其分配给SAN卷，完成后，重启服务器，再启动需要的服务，用户就可以访问和使用新的SAN卷了。
　　
　　SAN到SAN迁移
　　
　　从一个SAN向另一个SAN迁移大批量数据的方法很多，基本上和NAS到SAN的迁移方法一样，但也存在一些差异，动手之前，有必要先了解一下。
　　
　　在SAN到SAN的迁移中，我经常遇到不同SAN厂商的多路径模块不兼容问题，例如，如果你在EMCClariion和惠普EVA阵列之间迁移数据，EMCPowerPathDSM和EVAmultipathingDSM是互不兼容的，我曾亲历过这种问题，当我同时安装了这两个DSM尝试管理对方的存储路径后，服务器居然启动不了。
　　
　　为了避免这种问题，将新存储连接到服务器时最好不要使用多路径，如果源和目标SAN都是FCSAN，当你想执行临时数据同步时，present单一路径到新SAN。当你将生产服务器停机，准备正式迁移时，最好卸载旧的SAN的多路径DSM，并unpresent掉旧存储。
　　
　　重启后，安装新的DSM并present其余路径到新存储，这个过程会因重启服务器使停机时间变长，因此在评估时应将其考虑进去。事实上，如果你已经有在同步的数据，花在调整软件上的时间也许比真正移动数据所需的时间还长。
　　
　　从SAN到SAN迁移数据时需要考虑的另一个问题是，有些SAN和多协议SAN桥支持在存储网络内直接执行块级数据迁移，这些功能往往需要购买昂贵的许可，因此，只有当你要移动海量数据时才有必要这么做，它的确能节省很多时间，但有一点我需要强调的是，不管厂商声称它有多稳定，在迁移生产数据前，都应该反复测试。
　　
　　服务器和存储虚拟化
　　
　　如果你已经实现了服务器或存储虚拟化，从一个设备迁移到另一个设备这种任务就很简单了，例如，如果你运行着VMware的vSphereEnterprise或EnterprisePlus版，你可以使用StorageVmotion移动整个虚拟机，并且无需关闭虚拟机，所有需求是虚拟主机可以同时看到和使用源和目标存储介质，一般来说，这并不难做到。
　　
　　如果你已经拥有良好的存储虚拟化架构，你应该知道可以将整个SAN卷从一个SAN转移到另一个SAN，服务器是感觉不到这种变化的，实际上，许多大型企业早已提前实现了存储虚拟化，在这种环境中，要执行存储迁移是再简单不过的事情了。
　　
　　总结
　　
　　不管你要做什么类型的存储迁移，最重要的事情是确保你始终有一个可轻松执行的回退计划，这个最好不要偷懒或存在侥幸心理，如果你对新存储平台做了全面测试，任何可能遇到的问题都应该心中有数，确保正式迁移时不会手足无措。

     责任编辑：handsome