DOITAPP
DOIT数据智能产业媒体与服务平台
立即打开
DOITAPP
DOIT数据智能产业媒体与服务平台
立即打开

避免粗暴系统“拆迁” 数据迁移有妙招

几年前,数据中心最常见的迁移类型可能是操作系统的升级,通常情况下,操作系统的升级是伴随服务器硬件或应用程序升级同步发生的,在此期间,生产数据将不可避免要从一个地方转移到另一个地方。随着数据爆炸式增长和服务器虚拟化技术的普及,今天我们看到的更多是存储系统的升级,与操作系统是否升级无关,虚拟化物理服务器或提供更多存储空间已成为当务之急。

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

从一种存储类型迁移到另一种存储类型时,首先需要正确了解源和目标存储,你对它们的了解程度可能会最终左右你使用的数据迁移策略,面临的风险,以及所需的时间。

DAS到SAN迁移

最简单,最常见的存储迁移形式可能要数从物理服务器本地,直接附加存储迁移到SAN存储,假设你有一台部门文件服务器,本地磁盘空间已经快用光,为了满足用户的存储需求,你购买了一个新的SAN存储,于是想将用户的数据转移到它上面,但必须不惜一切代价,避免不必要的停机时间。

第一步是将物理服务器连接到SAN,不管你使用的是FC SAN还是iSCSI SAN,都需要给服务器添加SAN存储连接设备,如果是FC SAN,就需要FC HBA(主机总线适配器),如果是iSCSI SAN,用双端口千兆以太网网卡就行了,完成HBA或网卡的安装不应该超过1小时,同时,你最好在这个时间范围内将需要的软件也一并安装好,避免以后再停机或重启服务器。

配置好SAN后,在你的服务器上装载新的数据卷,并格式化,完成后,你的服务器上就拥有一个全新的空卷了,这时你可以预迁移数据副本,很多人在这一步会犯错,总是试图将所有数据全部移走,其实完全没必要这样做,不仅风险很大,数据迁移所需时间往往比你预计的要长得多,特别是迁移包含大量小文件的文件服务器,相反,你应该使用robocopy(Windows)或rsync(Linux,Windows)等数据卷镜像工具。如果配置得当,这些工具允许你将生产服务器上的数据同步到SAN,包括非常重要的安全描述符,因此不需要生产磁盘卷脱机,通过几天的连续同步,非生产SAN存储上的数据就和生产服务器上的文件完全同步了,这样就不需要中断生产系统,如果你要迁移的是数据库服务器,虽然不可能执行增量复制,但你可以通过复制测试确定迁移需要的时间,从而做好停机规划。

为了减少迁移时间,需确保没有用户打开或锁定共享服务器上的文件,如果是Windows Server操作系统,可以停止“Windows Netlogon”和“Server”服务,这样用户就无法访问服务器上的共享文件了,微软的Process Explorer或Linux下的lsof可以检查是否有进程锁定你需要复制的文件,在Windows服务器上,WMI服务通常是罪魁祸首。

当你确定源存储卷上没有文件被打开后,就可以开始做同步操作了,遇到复制失败错误时,应仔细阅读错误消息,因为某些系统文件是无法移动的,重点应放在用户数据上。

数据完全镜像后,最简单的办法就是交换盘符或挂载点,当然,你也可以修改共享设置和应用程序设置,如杀毒软件的排除选项,指向新的驱动器,最省时的办法还是交换挂载点,如果你的本地数据卷使用的是D:,先将本地卷的驱动器号移除,然后将其分配给SAN卷,完成后,重启服务器,再启动需要的服务,用户就可以访问和使用新的SAN卷了。

SAN到SAN迁移

从一个SAN向另一个SAN迁移大批量数据的方法很多,基本上和NAS到SAN的迁移方法一样,但也存在一些差异,动手之前,有必要先了解一下。

在SAN到SAN的迁移中,我经常遇到不同SAN厂商的多路径模块不兼容问题,例如,如果你在EMC Clariion和惠普EVA阵列之间迁移数据,EMC PowerPath DSM和EVA multipathing DSM是互不兼容的,我曾亲历过这种问题,当我同时安装了这两个DSM尝试管理对方的存储路径后,服务器居然启动不了。

为了避免这种问题,将新存储连接到服务器时最好不要使用多路径,如果源和目标SAN都是FC SAN,当你想执行临时数据同步时,present单一路径到新SAN。当你将生产服务器停机,准备正式迁移时,最好卸载旧的SAN的多路径DSM,并unpresent掉旧存储。

重启后,安装新的DSM并present其余路径到新存储,这个过程会因重启服务器使停机时间变长,因此在评估时应将其考虑进去。事实上,如果你已经有在同步的数据,花在调整软件上的时间也许比真正移动数据所需的时间还长。

从SAN到SAN迁移数据时需要考虑的另一个问题是,有些SAN和多协议SAN桥支持在存储网络内直接执行块级数据迁移,这些功能往往需要购买昂贵的许可,因此,只有当你要移动海量数据时才有必要这么做,它的确能节省很多时间,但有一点我需要强调的是,不管厂商声称它有多稳定,在迁移生产数据前,都应该反复测试。

服务器和存储虚拟化

如果你已经实现了服务器或存储虚拟化,从一个设备迁移到另一个设备这种任务就很简单了,例如,如果你运行着VMware的vSphere Enterprise或Enterprise Plus版,你可以使用Storage Vmotion移动整个虚拟机,并且无需关闭虚拟机,所有需求是虚拟主机可以同时看到和使用源和目标存储介质,一般来说,这并不难做到。

如果你已经拥有良好的存储虚拟化架构,你应该知道可以将整个SAN卷从一个SAN转移到另一个SAN,服务器是感觉不到这种变化的,实际上,许多大型企业早已提前实现了存储虚拟化,在这种环境中,要执行存储迁移是再简单不过的事情了。

总结

不管你要做什么类型的存储迁移,最重要的事情是确保你始终有一个可轻松执行的回退计划,这个最好不要偷懒或存在侥幸心理,如果你对新存储平台做了全面测试,任何可能遇到的问题都应该心中有数,确保正式迁移时不会手足无措。

未经允许不得转载:DOIT » 避免粗暴系统“拆迁” 数据迁移有妙招