主机存储基础平台数据迁移（存储迁移、数据库迁移、虚拟化迁移）典型问题分析
一、存储迁移
活动中大量的问题是针对于不同品牌存储直接的数据迁移，相同品牌存储数据直接的迁移，使用存储虚拟网关利弊等，下面是会员针对此类的问题的解决方法，技巧与相关参考意见。
以下是几个比较典型的问题：
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的项目策划，在测试环境通过，但没有最终实施测试环境是RHEL6.5 ORACLE11201，其中主机部分是通过添加RAC节点并通过数据库服务模式来逐台更换，存储部分是通过ASM NOR切换。
2、主机和存储都要换的话还是比较繁琐的，当然需要做一些严格测试工作，工作需要做的充分一些。存储端的在线迁移相对来说简单一些，只是主机端多路径设备识别一块可能有限异常，可能需要重启，这个可以逐台进行，后续ASM在线迁移一般不会有什么大的问题。主机端目前不停机的办法好像只有rac添加节点和删除节点一种方式比较合适了。
3、尝试一下RAC+DG的方式
RAC环境迁移到云环境？
1、Oracle RAC或者oracle 从Power到X86 或者是X86 到Power平台之间的迁移由于系统平台不一样，文件识别的字节序等方面不一样，不能直接使用物理文件拷贝或者rman恢复的方式进行。
迁移参照办法：
- 使用导入导出方式 - 使用表空间传输方式。
至于说能不能迁移主要是考虑，业务系统是否支持或者是否需要其他特殊的要求，和内网有无大数据量的交互，有关性能一个方面不是太大的问题，可以通过其他方式解决。架构问题，每个企业都不一样，且业务场景不同。需要依据具体情况实施。
2、如果考虑把数据库迁移到云上，可以有两种方式交付，一种是通过从云服务提供商采购虚机，在虚机集群上构建oracle RAC，但是需要考虑RAC集群的性能问题，是否仍然能够满足之前的业务容量需求；另外一种交付模式就是类似阿里云RDBS的云数据库模式，用户比较省心，不必担心性能问题，成本也比较低。
3、Oracle从Power架构迁移到云上是不存在任何技术障碍的，问题的关键是在于现有的应用架构是否能支撑基于云的计算，另外，如果云主机提供的处理能力无法匹配现有Power主机的处理能力，那么数据库架构也需要进行调整。
X86 RAC 迁移到Power平台RAC
1、感觉这个还是看停机窗口和数据量。因为跨平台了，如果停机窗口足够可以使用数据泵导出再导入的方式。这样操作起来比较简单。如果停机窗口不够，可以考虑使用ogg之类的复制方案来做。
2、参考 RAC迁移云环境的解决思路。
关于数据仓库跨品牌数据库迁移、数据异地同步 1、第一 如果你的业务迁移涉及到数据库品牌切换，这个就需要完整的厂家解决方案来确认了，比如从DB2迁移到ORACLE，这就需要2个品牌（主要是ORACLE）的厂商来确认数据的可用性， 另外ORACLE OGG，QUEST
SharePlex号称可以在异构平台上进行不同数据库的数据同步，但没有测试，不敢确定，
2、另外异地同步，已经类似传统两地三中心的第三中心了。 在带宽有限制的情况下，推荐本地双活、异地容灾/实时备份
Oracle RAC从HP存储迁移到IBM存储
1、这种跨平台的迁移，很难直接通过基于块的存储复制迁移。最后通过数据库本身提供的工具。以oracle为例，跨平台的迁移可选择数据泵导出，再导入的方式。也可以选择ogg、dsg等数据库复制软件。 具体选择哪种方案，以停机窗口和数据量大小来综合判断。
2、如果只是更换存储的话，主机端使用参考使用LVM方式，主机识别多个存储，rac前端进行迁移也是可以的。
DB2迁移Oracle的相关问题
问题1：非空字段判定：DB2可在非空约束中插入空字符串，且大量存在业务表中，但Oracle不允许此类数据存在
解答：在迁移的时候进行转换 问题2: 数据库对象长度不同：DB2数据库存在较多超长的数据库对象名，但Oracle最多支持30个字符。
解答：目前还是无解的
问题3：自增列的迁移：DB2存在自增列，Oracle没有相关匹配？
解答：可以在迁移完成后再添加序列对象实现
分析：
在数据层面的数据迁移还是比较多，主要涉及的几个方面：存储更换，主机更换，不同数据库之间的转换迁移，数据所在平台的迁移。数据库层面的迁移问题，在此只是做了简单梳理，其实还有大量的问题由于时间问题没有提出来，比如oracle如何迁移至mysql，sqlserver等，其他数据库直接的相互迁移或转换。是否已经有比较成熟的产品供我们参考利用，在实际迁移过程当中又遇到过哪些疑难杂症，后续我们可以准备针对数据库方面迁移做一些探讨。
本次活动当中涉及到的数据库层面层面迁移相应的参考借鉴方案主要有以下几种：
1. 使用虚拟网关迁移屏蔽存储的迁移
2. 使用LVM 一台主机挂接多个存储完成存储更换
3. 使用rac或dg完成oracle层面的迁移
4. 使用第三方工具进行数据层面的迁移或转换。
三、虚拟化迁移
本次涉及到的虚拟化迁移主要包括vmware 平台，powervm平台以及vmware平台和其他虚拟平台直接的迁移转换的问题与思考。
Vmware P2V 常用场景
1、vmware4.1 可以使用的集群的安装插件在集群上选择导入的方式进行p2v的转换。
2、在从5.0版本以后，好像已经不能再集群端进行直接的导入方式，只能选择使用VMware vCenter Converter Standalone Client 进行转换，在兼容模式下的操作系统基本上问题不大。
3、还可以考虑在主机端直接手工安装agent或者使用cold converter 光盘进行迁移。
4、曾经遇到一个只有256Ｍ内存的windows 执行在线导入的操作，由于内存太低不支持，后来扩容到512就好了。
5、还有一些时候经常会在p2v 迁移到了99%以后报错，次迁移就Ok，每次情况可能都不一样。很多时候因为网络或者其他不稳定，具体情况具体分析。
6、我个人觉得实际生产中一般肯定是冷的，
7、假设是数据库，热的肯定不一致了。