最好还是逐步迁移,有了新存储。就尽量搭建新环境,迁移旧系统数据。可能存在的最大困难就是新旧硬件,操作系统之间的兼容性问题。具体的要看业务需求了。或许虚拟化迁移原有的旧平台。或者搭建新环境。升级业务系统,迁移数据。后者可能投入大一些。困难也多一切。但相对来说后患少一些。
举个简单的例子一样。家里的电脑旧了。上面还是ddr2甚至DDR的内存。觉得不够用了。想换新的。可现在都DDR3了。新条子旧系统不支持。总不能为了省钱买个DDR2的做小规模的升级吧。这种升级的作用很小。对系统稍有改善。但用不了多久还要升级。所谓长痛不如短痛。
收起基本上有以下几种方案:
1. 假设既有环境有存储虚拟化设备,那么方案就很简单:
1)新的存储设备加入到存储虚拟化网关当中。
2)做好SAN交换机上的后端配置。
3)将生产上用到的LUN做镜像(例如:A是在用生产上的LUN、A-Mirror是新存储上分配出来的同样大小及类型的LUN),无论是数据库还是虚拟化环境。
4)等待数据同步完成,挨个拆掉原来的存储LUN,验证应用。
5)等到全部存储LUN拆分结束后,并且稳定一段时间后,拆除旧存储。
2. 没有存储虚拟化设备情况,分以下几种类型应用:
ORACLE
1)新的存储设备加入到SAN环境。
2)做好SAN交换机上的前端配置。
3)划分同规格LUN给到数据库服务器上。
4)配置ASM冗余策略,利用ASM将新LUN加入到磁盘组的冗余组当中。
5)待数据同步完毕,并且稳定一段时间后,拆除旧存储。
6)重新配置ASM冗余策略。
VMARE
1)新的存储设备加入到SAN环境。
2)做好SAN交换机上的前端配置。
3)划分同规格LUN给到集群中所有ESXI上。
4)利用Vmotion执行虚拟机迁移。
5)待全部迁移完毕,并且稳定一段时间后,拆除旧存储LUN。
LVM
1)新的存储设备加入到SAN环境。
2)做好SAN交换机上的前端配置。
3)划分同规格LUN给到服务器上。
4)利用LVM逻辑卷镜像方式配置LV镜像。
5)待LV同步完成,并且稳定一段时间后,拆除LVM原来镜像,拆除PV。
6)拆除原来的存储LUN。
收起
开放性的问题,个人的一些观点,抛砖引玉,欢迎大家跟进。
关于存储迁移是个比较老的话题了,根据实现的角度来看,实现的方法也太多太多,我简单聊几种。
1. 比如主机是aix操作系统,直接使用系统自带的lvm功能即可。安全无副作用。新的存储划lun后加入现有存储的vg,通过mklvcopy(个人首推)或migratepv功能可将数据在线迁移到新的存储。期间不用停机。如果数据量打大,还可以根据业务梳理lv 分配迁移。迁移完后直接剔除老存储,下线即可。
2. 基于应用自身特性的。比如直接使用oracle的asm功能。或者使用rman的backup copy功能,也可以做到较短的停机时间。可参考如下的案例
3. 基于复制软件的。如oracle的golden gate,ibm的cdc等软件。可以解决海量数据迁移问题,做到在线迁移不停机。
4. 基于存储自身功能。比如ibm的svc v7000系列的vdm功能。或者emc的vplex等都可以基于存储的特性来做。也可以做到极少的停机时间。优点是对上层的应用透明,上层应用不需要做改动,工作都由底层存储完成。
收起我们内部还没有系统在线数据迁移的案例,
一般迁移应用服务器和数据库全套环境的步骤如下
1.在新的设备搭建一套新的环境,包括数据库、应用服务器
2.在新的环境中导入测试数据,前端从业务层进行相关可用性验证
3.进行数据被备份迁入到测试环境的相关数据迁移时间实测评估
4.停止应用系统,一般选择的停止窗口在业务低峰期
5.进行数据迁移,包括数据库和一些存储文件等。
6.验证应用并进行F5层面的相关切换。
如果只是切换应用服务器,则一般采用灰度切换的方式
1.部署应用服务器并验证
2.通过F5切换流量到新部署的应用服务器
收起