数据迁移典型问题分析

主机存储基础平台数据迁移（存储迁移、数据库迁移、虚拟化迁移）典型问题分析

一、存储迁移

活动中大量的问题是针对于不同品牌存储直接的数据迁移，相同品牌存储数据直接的迁移，使用存储虚拟网关利弊等，下面是会员针对此类的问题的解决方法，技巧与相关参考意见。

以下是几个比较典型的问题：

V7000和DS8000直接的数据迁移问题?

1、不借助第三方工具，可以考虑使用基于系统的lvm mirror，aix linux hp-ux 都支持也可以通过应用本身来做，如oracle的asm。或者oracle rman的backup as copy 以及db2的重定向恢复（但需要短暂停机时间）。

2、只能基于主机或应用。如果一定要基于存储做，建议使用svc

3、使用svc即可。但也要有个短暂的停机时间。使用vdm 或migration都可以

4、完全不停业务的话考虑lvm mirror

5、如果目前两个环境都是独立使用的情况下，不停机的迁移基本上不可能。因为不管你怎么做，前端主机都要有一个再识别的过程。前端加一个SVC可能会比较好。V7000 这个产品如果用作去充当svc的作用的话，可能在性能上后续会差点意思。

刀箱的盘阵列上的存储数据，迁移到新的存储上方法与考虑？

目前刀箱上的磁盘是刀箱本地磁盘还是刀箱通过光纤模块连接的外置存储，这个需要说明一下。如果是刀箱内置硬盘，是否和本地刀片里的磁盘做过mirror。

是否考虑迁移。是否配置连接存储的光纤模块。如果是通过光纤模块连接的那也就没什么了，和普通环境一样。使用LVM 的方式进行迁移。

使用存储网关，迁移同系列存储和异构存储考虑?

1、IO 能力：

目前来说存储网关产品配合着闪存可以覆盖95%以上的应用，io能力在几年内还是可以的。对于io极为苛刻的场景可以选择其他的具体方案

2、扩展能力：

很多时候官方产品宣传的很好，比如说我可以支持多少个节点的扩展能力，纵向到什么程度，横行到什么程度。但我们需要进一步去看拨开宣传华丽的面纱去看技术的实现。

是成对的扩容啊，还是一个整体的扩容，其实现原理和规模是不太一样的。

3、兼容性

是支持摸一个具体型号，还是支持摸一个品牌系列，这里边有很多种学问。会不会因为实施了虚拟网关后整体的io能力反而下降了，是产品不行还是实施的方案不对，曾经有的客户抱怨实施后的应用io能力下降了。这个里边需要做的工作太多了。

不同品牌的主机或存储服务器之间进行数据迁移？

1、底层存储用svc或vplex虚拟化，随时可以进行数据迁移，无需申请停机窗口

2、使用存储虚拟网关产品对于前端主机是透明的，可以忽略底层数据的存放和迁移工作，前段主机安装一种多路径软件，管理维护性比较好。

存储经常会报警：链路不在最优路径上，诊断处理思路？

1、lun 链路不在最优路径是指在创建lun是选择lun所在控制器的优先级，就是lun首先被那个控制器管理，如果不在这个控制器就会提示你说的那个错误，

这种情况下把lun切过去就可以了，如果经常发生这样的错误告警提示就得注意了，检查链路，控制器日志等等

2、排除了zone配置，一般都是链路问题。ds4k ds5k系列有时候切回到最优路径还会报错。临时解决方法：自己切自己，空切玩就没事了

3、很多时候经常会遇到主机扫描新映射的磁盘的时候存储链路就会切换的情况的出现，手工切换回去也就老实了，也没事。

4、有的时候经常是因为主机hba卡故障导致链路不在最优路径上。曾经vmware 集群多台机器中的一台hba卡故障，导致存储上出现链路切换的工作。换了就OK。

5、出现链路切换的时候大多还是链路方面的问题，比如线路不太稳定，尝试换一端口尝试解决一下。曾经碰到一次链路衰减的问题，识别巨慢，读写都不正常，换条线换个口基本上可以解决此类问题。

分析：

以上此类问题大多聚焦于存储层面的数据迁移工作，主要是相同品牌之间和不同品牌之间。经过多年的发展，存储虚拟网关已经是非常成熟的产品，每个厂商的产品名称不一样，但是效果大多还是不错的。除了个别存储兼容性以外，主要考虑的就是存储虚拟网关的性能与后期扩展性方面。存储虚拟网关对前端主机透明，很好的屏蔽或封装了后端存储的复制性。提高了管理和运维的效率。

存储虚拟网关已经是此类场景一个比较成熟的解决方案，后续其他应用场景广大同仁可以参考使用。

二、数据库迁移

还有很多问题主要关注的是主机数据库平台，遇到数据库迁移问题的描述，希望了解通过哪种方式可以降低RTO和RPO，尽可能的在线完成存储，主机或数据本

身的方面的迁移。这里将此类问题进行一个梳理，为后续此类数据迁移场景提供一个参考。

Oracle RAC生产系统，存储和主机都要更换？

1、之前一个基于ORACLE的项目策划，在测试环境通过，但没有最终实施测试环境是 ORACLE11201，其中主机部分是通过添加RAC节点并通过数据库服务模式来逐台更换，存储部分是通过ASM NOR切换。

2、主机和存储都要换的话还是比较繁琐的，当然需要做一些严格测试工作，工作需要做的充分一些。存储端的在线迁移相对来说简单一些，只是主机端多路径设备识别一块可能有限异常，可能需要重启，这个可以逐台进行，后续ASM在线迁移一般不会有什么大的问题。主机端目前不停机的办法好像只有rac添加节点和删除节点一种方式比较合适了。

3、尝试一下RAC+DG的方式

RAC环境迁移到云环境？

1、Oracle RAC或者oracle 从Power到X86 或者是X86 到Power平台之间的迁移由于系统平台不一样，文件识别的字节序等方面不一样，不能直接使用物理文件拷贝或者rman恢复的方式进行。

迁移参照办法：

- 使用导入导出方式

- 使用表空间传输方式。

至于说能不能迁移主要是考虑，业务系统是否支持或者是否需要其他特殊的要求，和内网有无大数据量的交互，有关性能一个方面不是太大的问题，可以通过其他方式解决。架构问题，每个企业都不一样，且业务场景不同。需要依据具体情况实施。

2、如果考虑把数据库迁移到云上，可以有两种方式交付，一种是通过从云服务提供商采购虚机，在虚机集群上构建oracle RAC，但是需要考虑RAC集群的性