大数据迁移典型问题分析报告Word格式.docx

大数据迁移典型问题分析报告Word格式.docx

《大数据迁移典型问题分析报告Word格式.docx》由会员分享，可在线阅读，更多相关《大数据迁移典型问题分析报告Word格式.docx（7页珍藏版）》请在冰豆网上搜索。

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

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配置，一般都是链路问题。

ds4kds5k系列有时候切回到最优路径还会报错。

临时解决方法：

自己切自己，空切玩就没事了

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

4、有的时候经常是因为主机hba卡故障导致链路不在最优路径上。

曾经vmware集群多台机器中的一台hba卡故障，导致存储上出现链路切换的工作。

换了就OK。

5、出现链路切换的时候大多还是链路方面的问题，比如线路不太稳定，尝试换一端口尝试解决一下。

曾经碰到一次链路衰减的问题，识别巨慢，读写都不正常，换条线换个口根本上可以解决此类问题。

分析：

以上此类问题大多聚焦于存储层面的数据迁移工作，主要是一样品牌之间和不同品牌之间。

经过多年的开展，存储虚拟网关已经是非常成熟的产品，每个厂商的产品名称不一样，但是效果大多还是不错的。

除了个别存储兼容性以外，主要考虑的就是存储虚拟网关的性能与后期扩展性方面。

存储虚拟网关对前端主机透明，很好的屏蔽或封装了后端存储的复制性。

提高了管理和运维的效率。

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

二、数据库迁移

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

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

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

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

2、主机和存储都要换的话还是比拟繁琐的，当然需要做一些严格测试工作，工作需要做的充分一些。

存储端的在线迁移相对来说简单一些，只是主机端多路径设备识别一块可能有限异常，可能需要重启，这个可以逐台进展，后续ASM在线迁移一般不会有什么大的问题。

主机端目前不停机的方法好似只有rac添加节点和删除节点一种方式比拟适宜了。

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

RAC环境迁移到云环境？

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

迁移参照方法：

-使用导入导出方式

-使用表空间传输方式。

至于说能不能迁移主要是考虑，业务系统是否支持或者是否需要其他特殊的要求，和网有无大数据量的交互，有关性能一个方面不是太大的问题，可以通过其他方式解决。

架构问题，每个企业都不一样，且业务场景不同。

需要依据具体情况实施。

2、如果考虑把数据库迁移到云上，可以有两种方式交付，一种是通过从云服务提供商采购虚机，在虚机集群上构建oracleRAC，但是需要考虑RAC集群的性能问题，是否仍然能够满足之前的业务容量需求；

另外一种交付模式就是类似阿里云RDBS的云数据库模式，用户比拟省心，不必担心性能问题，本钱也比拟低。

3、Oracle从Power架构迁移到云上是不存在任何技术障碍的，问题的关键是在于现有的应用架构是否能支撑基于云的计算，另外，如果云主机提供的处理能力无法匹配现有Power主机的处理能力，那么数据库架构也需要进展调整。

X86RAC迁移到Power平台RAC

1、感觉这个还是看停机窗口和数据量。

因为跨平台了，如果停机窗口足够可以使用数据泵导出再导入的方式。

这样操作起来比拟简单。

如果停机窗口不够，可以考虑使用ogg之类的复制方案来做。

2、参考RAC迁移云环境的解决思路。

关于数据仓库跨品牌数据库迁移、数据异地同步

1、第一如果你的业务迁移涉与到数据库品牌切换，这个就需要完整的厂家解决方案来确认了，比如从DB2迁移到ORACLE，这就需要2个品牌〔主要是ORACLE〕的厂商来确认数据的可用性，另外ORACLEOGG，QUESTSharePlex号称可以在异构平台上进展不同数据库的数据同步，但没有测试，不敢确定，

2、另外异地同步，已经类似传统两地三中心的第三中心了。

在带宽有限制的情况下，推荐本地双活、异地容灾/实时备份

OracleRAC从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平台和其他虚拟平台直接的迁移转换的问题与思考。

VmwareP2V常用场景

1、vmware4.1可以使用的集群的安装插件在集群上选择导入的方式进展p2v的转换。

2、在从5.0版本以后，好似已经不能再集群端进展直接的导入方式，只能选择使用VMwarevCenterConverterStandaloneClient进展转换，在兼容模式下的操作系统根本上问题不大。

3、还可以考虑在主机端直接手工安装agent或者使用coldconverter光盘进展迁移。

4、曾经遇到一个只有256Ｍ存的windows执行在线导入的操作，由于存太低不支持，后来扩容到512就好了。

5、还有一些时候经常会在p2v迁移到了99%以后报错，次迁移就Ok，每次情况可能都不一样。

很多时候因为网络或者其他不稳定，具体情况具体分析。

6、我个人觉得实际生产中一般肯定是冷的，

7、假设是数据库，热的肯定不一致了。

8、应用，没必要迁移了，直接搭建环境，发布应用就可以了。

简单快速，不停业务。

9、我觉得是一些开发环境，安装配置比拟复杂的环境适合p2v。

VMWARE虚拟化环境，更换新的存储

1、vmware的vmotion就是来干这个事的。

大多情况下还是使用vmware的vmfs形式去做的，直接在线迁移即可，如果存储做过心跳信号的，要注意把老旧的删除，新存储的添加

2、配置好vMotion，没有裸映射的虚拟机之间迁移，如果有裸映射需要设置成虚拟模式才可以迁移成虚拟磁盘，大于2T的需要在webclient里面迁移

3、使用vmware自带的storagevmotion功能即可，在线迁移虚拟机磁盘

小型机全分区环境向PowerVM全虚拟化环境迁移

1、你需要一台光纤存储和san网络,然后升级待迁移小鸡的AIX系统补丁，支持sanboot

把小机上的rootvg和其他vg迁移到光纤存储上，用mirrorvg和unmirrorvg

关掉旧小机.在新小机上创建新的虚拟机挂载对应的磁盘，开机就好。

因为网卡发生变动了，所以新的小鸡需要重新设置IP地址，就完成迁移工作了

2、在于原来的规划，rootvg只做系统，系统无非都是文件系统，都可以拷贝的，重要的datavg〔应在存储中〕也可以在新系统中〔powervm〕重新导入

Vmware迁移到KVM