DS8000数据迁移至EMC存储项目案例

IBM DS8100存储在企业当中已经使用有将近10个年头，其高性能，高可靠性一直是企业核心业务数据存放的首选，随着企业需求的变化和DS8100设备的使用年久远，企业在2年前已经考虑购买新的存储用来逐步替换8100的数据，去年设备替换预算已经审批完毕，就等今年新的设备采购逐步完成数据迁移工作，DS8100 后续用于其它用途。
好像凡事都有安排是的，新的存储已经采购完成，尚处于测试，试运行阶段，今年的4月底DS8100 突然就出现了一个控制器异常的现象，经过MA厂商多次尝试解决也没有恢复至正常状态，怎么办？
DS8100 目前上面还都是核心数据，如果它挂了，结果可想而知。迁移，领导当即立断，可悲了我的五一劳动节啊，我的五一是在数据迁移过程中度过，结果是好的，迁移完成。一个五一完成了我全年的kpi，哈哈，是祸也是福。
在此我在这里分享一下本次DS8100迁移其他存储的过程，希望可以对大家有所帮助，也是对本次迁移来个总结。

场景描述：

原有连接DS8100存储的业务系统环境介绍以及准备迁移至新存储后的环境描述

业务系统 操作系统 多路径软件 其他环境 lun大小 数据量(TB) 新多路径软件 迁移至存储 迁移lun大小 停机窗口
app1 aix6.1 sdd powerha6.1+GPFS 80 6 powerpath Emc1 300 2h
app2 aix6.1 sdd powerha6.1+GPFS 80 7 powerpath Emc1 300 4h
app3 aix6.1 sdd powerha6.1+GPFS 80 1 powerpath Emc2 300 4h
app4 aix6.1 sdd powerha6.1 80 0.8 powerpath Emc2 300 4h
app5 aix6.1 sddpcm oracle rac 80 3 sddpcm v7000 500 2h
app6 redhat5.6 multipath oracle rac 80 1 multipath Emc1 300 2h

其他业务系统同种环境的还有一些，在此以上面几个业务系统为参考。

迁移方案：

通过对业务系统环境的梳理，选择的方案是影射新存储到主机环境，主机层面进行相关的迁移操作，按照业务系统迁移有易到难和优先级由低到高的迁移过程。原因有以下几个方面：

1. 应用的等级不一样，且由于前期只是做过简单的测试工作，需要由低优先级到高，降低风险。
2. 新存储和老存储属于不同品牌，使用的多路径软件不同
3. 迁移前后使用的存储lun大小不同，本次迁移由小盘到大盘(业务系统数据量比较大，后期增长也比较大)，后期管理方便。
4. Powerha 环境下直接使用盘替换的方式容易出现hang死现象，且盘大小相差比较多
5. 目前环境中没有svc相关产品，一个V7000 不足以承载io性能问题，故放弃使用存储虚拟化方式
6. 能够在线迁移就先迁移，从线上迁移到半线上方式进行迁移

基于以上几方面的考虑，所以决定还是利用主机层面完成本次迁移工作。具体迁移安排如下：

业务系统 迁移方式描述
app5 映射v7000存储，使用Oracle RAC的ASM方式在线迁移
app6 映射emc存储，使用multipath识别，Oracle RAC的ASM方式在线迁移
app4 映射emc存储，使用Aix自带的mpio识别，停止HA，删除磁盘心跳，单机完成迁移，删除sdd，安装powerpath，配置PowerHA，启动，迁移完毕。
app3 映射emc存储，使用Aix自带的mpio识别，完成GPFS迁移，然后app4后半段操作并且完成GPFS集群重新识别磁盘工作以及心跳盘配置
app2 参考app3方式完成
app1 参考app3方式完成

本次方案虽然繁琐，但灵活度比较大，每个环节先后顺序需要严格执行，每个环节的进度都可以很好把控，按照原先设想的进行，达到完美效果。

迁移过程：

　　本次迁移操作，前提是协调好业务窗口，严格按照前期计划执行，且每个业务系统迁移过程当中步骤不能前后颠倒，否则就会得到自己不想看到的结果。
　　在这里我主要描述一下在整个迁移过程当中容易出现的问题和具体的每个业务系统迁移过程当中的具体技术细节。

App5 :

在app5迁移过程当中，由于使用的aix操作系统（扫描方便），后端新迁移到V7000存储，两个存储属于同一品牌，且都是使用sddpcm多路径软件，所以在线直接映射存储识别，然后修改磁盘属性和属组后，直接使用Oracle ASM在线添加和删除磁盘。后续删除原有DS8100存储的磁盘信息。完成数据迁移工作，难度较小

App6:
App6的迁移参照App5的方式，由于使用的linux 系统，在线扫描和识别存储时遇到了一点点问题，随后协调业务时间窗口，重启主机完成识别。其他和App5方式一样
完成迁移，难度较小。

App4:
由于APP4系统涉及到多路径软件的替换和powerha环境，具体操作如下：

1. 在线扫描存储，识别
2. 停止powerha，删除心跳磁盘,集群各节点修改VG属性，使用migratepv和migratelp完成各自节点的数据迁移后台进行
3. 在各节点配置原有生产ip，启动业务，直至后台数据迁移完成。
4. 删除原有DS8100磁盘信息, 删除sdd多路径软件(需要停止sddsrv服务，dpo设备删除)，删除原DS8100　zone信息。
5. 安装powerpath，删除emc磁盘，重启识别磁盘.
6. 配置powerHA ,添加心跳磁盘,同步完毕，启动服务
7. 迁移完毕

容易出错的地方：

1. 删除sdd软件的时候容易忘记dpo设备的删除，导致删除不干净
2. 由于powerpath软件可以驱动识别sdd等其他多路径软件的磁盘，所以一定要等数据迁移完毕后再安装powerpath 软件。

APP3:
App3 相对于app1,app2唯一不同的地方就是它的优先级比较低，重要程度没那么高，先迁移它是为了迁移app1,app2 做准备，梳理整个迁移过程细节。
然而app3 相对app4 唯一的不同就是多了一个GPFS环境，由于前期还没有太细致的做过GPFS集群环境的迁移操作测试，故本次操作尽可能梳理整体过程细节。
步骤如下：

1. 映射新存储，在线识别
2. 使用AIX自带的mpio识别设备，先完成GPFS　集群环境的迁移
   Ⅰ> 创建disk profile ，格式化为nsd磁盘
   Ⅱ> 添加nsd磁盘到集群，数据会后台重新分布
   Ⅲ> 删除老的nsd磁盘，数据会后台重新分班
   Ⅳ> 暂时先不修改gpfs集群的总裁盘(修改总裁盘需要停止集群，影响业务，且磁盘名字powerpath也不一样)
3. 停止业务，停止PowerHA，删除powerHA的心跳磁盘。
4. 集群各节点修改vg属性，添加大磁盘进行数据迁移(migratepv和migratelp)，后台编写脚本批处理迁移
5. 在各节点配置原有生产ip，启动业务，直至后台数据迁移完成。
6. 删除原有DS8100磁盘信息, 删除sdd多路径软件(需要停止sddsrv服务，dpo设备删除)，删除原DS8100　zone信息
7. 安装powerpath，删除emc磁盘，重启识别磁盘.
8. 配置GPFS心跳磁盘和配置powerHA ,添加心跳磁盘,同步完毕，启动服务
9. 迁移完毕。

整个迁移过程需要严格按照此顺序执行，这样整个迁移过程当中只需要两次重启窗口，且每次停机窗口1个小时均可以完成，大大缩小了业务的停机时间。

其中APP1和APP2 均参照APP3的方式进行，整个过程比较顺利。

注：
由于本次迁移过程由于前后变化的东西比较多，所以在操作中需要严格的准守先后顺序，方可得到比较满意的结果。

学习新知识 ctrl-z：
在app2迁移的过程当中，我犯了一个小错误，本来计划好后台执行编写好的shell脚本进行迁移，当时一个小的疏忽，导致前台执行，搞的差一点不能好好休息一下(连续奋斗了2-3天)，后来想到ctrl+z的命令，这个命令可以让当前执行的命令放到后台执行，可解决了大问题，要不然就得盯着，太费神。

所谓生命不息，战斗不止，活到老，学到老。