本次主机存储交流活动本着以实际工作当中的应用场景为基础，把在工作当中遇到的有关数据迁移方面的点点滴滴和实际经验予以交流与分享。

本次活动得到了社区会员的大力支持，涉及到工作当中的方方面面，并且集中在虚拟化，存储和数据库三个方面，广大的社区会员积极的分享了在数据迁移工作当中的经验和心得体会，为后续工作和广大同仁提供了借鉴与参考，从流程，方案，人员和细节等诸多方面进行了分享，真心可以希望为大家提供一些帮助，在这里再次向广大社区人员表示感谢。

在以下章节我们将着重的针对本次活动当中大家比较关心的话题进行一下进行整理和分享。

一、聚焦存储迁移

异构存储之间（V7000与DS800）数据迁移能否实现业务在线进行？如何保持数据的一致性?

如何将原有刀箱的盘阵列上的存储数据，迁移到新的存储上？需要注意哪些细节?

使用存储网关，迁移同系列存储和异构存储，所要考虑的因素有哪些，你都遇到过什么问题?

将普通存储上的数据迁移到闪存存储，还需要特别管理软件，还是自身就有这样功能?

存储经常会报警：链路不在最优路径上；针对这一问题有哪些诊断思路？具体解决效果如何?

应用数据从SAN存储迁移到NAS存储的方法有什么？迁移的风险和注意事项有哪些?

请问如何在不同品牌的主机或存储服务器之间进行数据迁移？底层（存储）迁移其优势是什么？最佳实践是什么?

银行金融系统双存储做mirror场景很多，其中有哪些细节和问题需要注意?

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

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的作用的话，可能在性能上后续会差点意思。

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

1. 目前刀箱上的磁盘是刀箱本地磁盘还是刀箱通过光纤模块连接的外置存储，这个需要说明一下。如果是刀箱内置硬盘，是否和本地刀片里的磁盘做过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. 出现链路切换的时候大多还是链路方面的问题，比如线路不太稳定，尝试换一端口尝试解决一下。曾经碰到一次链路衰减的问题，识别巨慢，读写都不正常，换条线换个口基本上可以解决此类问题。

分析：

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

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

二、聚焦数据库迁移

Oracle RAC生产系统，老系统要升级到新系统（存储和主机都换），能做到RTO=0吗？

将DB2迁移至Oracle时，可能遇到如非空字段判定、对象长度不同、自增列的迁移等问题，大家是如何处理的？

主机、存储异构数据库的迁移要注意哪些问题？如Oracle RAC从HP存储迁移到IBM存储？

Power平台、核心业务系统的Orace RAC有办法迁移到云上吗？该如何搭建架构和迁移？

X86服务器跑RAC数据库，搬迁新机房，存储与网络IP地址需要重新换新，请问是原环境修改还是重新搭建环境？

关于数据仓库跨品牌数据库迁移、数据异地同步的问题请教。

X86服务器上的Oracle RAC迁移到Power服务器上，能否有迁移案例分享一下？迁移方式、注意事项有哪些？

以上问题主要关注的是主机数据库平台，遇到的数据库迁移问题的描述，希望了解通过哪种方式可以降低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虚拟机迁移至华为SCAN 5平台，报错：请使用华为镜像导入，该如何解决？

小型机全分区环境向PowerVM全虚拟化环境迁移，尽量做到在线，有什么好的方案？

VMware P2V的场景下那哪些技术手段进行支撑，大家可以分享经验？

双vio环境+HA+数据库，要更换存储：如何规避数据风险？需要注意哪些方面？

VMWARE虚拟化环境，更换新的存储，如何不影响业务使用的情况下的无缝迁移？

VMware迁移到KVM迁移过程是的技术难题是什么？有什么注意事项

本次涉及到的虚拟化迁移主要包括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. 假设是数据库，热的肯定不一致了。
8. 应用，没必要迁移了，直接搭建环境，发布应用就可以了。简单快速，不停业务。
9. 我觉得是一些开发环境，安装配置比较复杂的环境适合p2v。

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

1. vmware的vmotion就是来干这个事的。大多情况下还是使用vmware的vmfs形式去做的，直接在线迁移即可，如果存储做过心跳信号的，要注意把老旧的删除，新存储的添加
2. 配置好vMotion，没有裸映射的虚拟机之间迁移，如果有裸映射需要设置成虚拟模式才可以迁移成虚拟磁盘，大于2T的需要在webclient里面迁移
3. 使用vmware自带的storage vmotion功能即可，在线迁移虚拟机磁盘

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

1. 你需要一台光纤存储和san网络,然后升级待迁移小鸡的AIX系统补丁，支持san boot
   把小机上的rootvg和其他vg迁移到光纤存储上，用 mirrorvg 和 unmirrorvg
   关掉旧小机.在新小机上创建新的虚拟机挂载对应的磁盘，开机就好。因为网卡发生变动了，所以新的小鸡需要重新设置IP地址，就完成迁移工作了
2. 在于原来的规划，rootvg只做系统，系统无非都是文件系统，都可以拷贝的，重要的datavg（应在存储中）也可以在新系统中（powervm）重新导入

Vmware 迁移到KVM

1. virt-v2v 工具是专门针对 VMware ESX/ESXi 的自动化迁移工具，而且支持的虚拟机系统仅限于 RHEL 和 Windows 虚拟机。Virt-v2v 在迁移后的 KVM 虚拟机中优先使用 virtio 虚拟驱动来提高系统 IO 的性能。如果不支持，才选用性能稍低，但更稳定可靠的虚拟硬件。而且这个过程全部自动化完成。
2. 手动迁移可以涵盖所有的 VMware 软件和所有的虚拟机系统。从而迁移中面临的问题也是多样化的，需要不同程度的手动干预。某些特定的环境下，可以使用一些工具来辅助手动迁移，比如 virt-goodies/vmware2libvirt。另外 libvirt 也在开发支持 VMware Workstation/Player 迁移的新功能。
3. 不论是 virt-v2v 自动化工具还是手动迁移，由于商业软件 VMware 开放的编程接口的限制，VMware 虚拟机到 KVM 的迁移有一些软肋：

• 一些 VMware 虚拟机的特性没有办法迁移到 KVM 虚拟机上。比如 VMware 虚拟机广泛使用的快照功能。
• 只能实现关闭虚拟机情况下的静态迁移，无法做到虚拟机不关机情况下的在线迁移。
• 一些特殊的 VMware 设备不能迁移到 KVM 虚拟机，于是采用了类似功能的硬件设备替代。比如 VMware Tools 中的虚拟驱动、VMware SVGA、VMware USB Controller 等。

总的来说，VMware 虚拟机到 KVM 的迁移不够成熟和自动化，迁移的过程需要手动干预。这要求迁移的操作人员具有相关的知识和经验。开源工具 virt-v2v 的出现简化了 VMware ESX/ESXi 上部分虚拟机的迁移，而且计划将来支持 VMware Workstation/Player 上虚拟机的自动迁移。反言之，自动化的迁移工具不就是用脚本语言把手动迁移的步骤和条件程序化么？掌握了手动迁移，才能了解虚拟机迁移更多的奥秘。

分析：

通过对主流虚拟化VMWARE，POWERVM平台的日常使用，积累了不是这方面的虚拟化迁移方面的问题。主要涉及到虚拟化平台后端存储更换，前端虚拟机的迁移，各虚拟平台直接的虚拟机或应用的迁移。
通常有以下解决方法用于参考：

1. Vmware平台自动的vmotion功能可以完成存储和虚拟机的在线更换与迁移
2. Vmware平台的p2v，有热迁移，冷迁移和导入方式等支持兼容系统的迁移、
3. PowerVM平台的迁移对硬件，san boot等方面有都有适当的要求，具体版本可参考官方手册。
4. Vmware迁移到KVM有virt-v2v等工具支持

四、聚焦经验与分享

数据迁移时间操作中的感受分享

本次活动当中广大社区会员针对数据迁移工作分享很多比较实用的技巧和迁移经验，从各个方面介绍了一下在迁移工作当中需要关注的点，能够更好的帮助大家在后期的迁移工作当中平滑进行。在这里着重分享几个会员的迁移经验和心得。

会员：study123

对于数据迁移实施，我个人觉得：在实施之前，再繁琐的准备都不算过分！就个人参与过的经验简单分享一下：

1. 环境调研要做充足，包括源数据库环境，版本，数据量大小，业务场景，操作系统版本，源数据库环境与目的数据库环境的差异等等
   在实际案例中遇到过多重很奇葩的情况，比如，迁移数据时，才发现客户的网速奇慢，传备份集只能达到3,5M的速率，整个迁移过程被传输占了大部分时间，没想到客户的数据中心的交换机那么差，源数据库和目的数据库是都在一个数据中心的。
2. 迁移方案准备，尽量优化细节，最好能在测试环境测试其可行性以及实际耗时后，才到生产环境实施。
   就碰到过实施时间安排的貌似很合理，结果上去第一步操作停库竟然等了好久。
3. 确保数据备份，回退可行，不能存在侥幸心理。有次迁移失败，紧急回退，发现源数据库竟然起不来了，深更半夜的又对源数据库折腾了将近一个小时。
4. 人员角色齐备，数据迁移一般是晚上实施，最好是A/B角一起参与，以免晚上精神不好，敲错指令。最好是主机工程师和存储工程师都在。曾经有一次，发现导入数据非常慢，后来发现是存储的问题。结果存储工程师不在现场，紧急call过来处理。
   重复一下：在实施之前，再繁琐的准备都不算过分！

会员:zhanghaiyang

数据的迁移，我觉的主要有三个点：
第一，数据量的大小
第二，是否影像业务 停机窗口时间
第三，迁移要是有风险 是不是还得备份

在实际的操作中，要根据实际硬件配置，软件环境来考虑迁移方案
我的经验来讲，还是软件迁移，比如数据库的asm镜像，操作系统的镜像，比较好用
底层的复制技术还是灾备或者备份用的比较多

会员：wangxuefeng

我在去年十一的时候，做过一次迁移，倒库备份出来，用了24小时多，具体我让别人操作的，然后，在新购置的服务器上安装操作系统，linux；然后，导入也花了很长时间，第二次，我9月30日过去了一趟增量备份，完成后，关停系统；并与10月2日，增量导入新设备，测试没问题，整体迁移了。其中，原来的刀片设备，作为完全备份设备，原封不动放在机房，以作为如果出现问题的马上还原。好像有点奢侈，不过，这样最安全了。
所以大数据，一定要有完全，有增量，这样安全。

会员：余静

我们去年做了几十套大系统迁移，各种方法都用了，简单说说
1、压缩（tar）+copy（scp）
2、ogg
3、dg
4、svc
5、镜像
前提，不管做什么方法考虑的问题
1、必须在迁移开始迁备份。
2、对业务影响范围充分了解。
3、风险考虑。
4、停机窗口。
5、操作步骤提前提前准备。
6、回退方案。
7、应急方案。（无法回退）

会员：董志卫

迁移的几点考虑：

1. 主要也是非常重要一点是梳理用户环境，制定比较有针对性的迁移方案。比如说可以线下迁移尽量要线下迁移，不要为凸显技术的高超，记住凡是都有风险，还有bug。
2. 技术辅助业务，支持业务。在充分测试前提下，梳理步骤，谨慎操作，运用适当的技术进行迁移。
3. 制定每一套的迁移不成功或回退方案，给自己多一种方案选择。
4. 报领导审批方案，提前协调窗口，切勿想当然直接就上，不要我以为没事，最终出大事。

会员：Laozhao

作为一个存储和备份工程师，参与了很多次的数据迁移，个人感觉有几个方面问题必须特别注意：
1、前期的调研工作必须充分，准备工作一定到位。
2、必须预留备份时间窗口
3、迁移就做迁移，不能去夹杂其他的升级或者变更。
4、方案一定要扎实，要全面；一定要要有回退方案或者保底方案。
5、有条件的一定要各方面的专家给予现场支持。

举一个迁移升级失败的例子：
更换存储和服务器：原环境：IBM小型机，HDS存储用HACMP 做的oracle双机（非RAC机构）
新环境：新IBM小型机（升级系统），新的HDS存储有POWERHA做oracle（版本不变）双机（非RAC机构），

迁移方案：新的服务器上按照原服务器的配置按照oracle配置powerha；用存储之之间的同步复制完成数据迁移；复制完成的数据卷添加到powerha后，启动，不停的抱IO 操作错误；但是能够启动数据库；但是做failover；数据库就死机；找了4个小时才发现powerha的卷要求和hacmp不一样，用户很生气；超出的时间，而且迁移也没有成果。幸好原环境没有破坏。
这个方案有几个主要的问题：
1、powerha当时刚出的新产品，大家对功能不是很熟悉就想用于生产，想做小白鼠；
2、迁移和升级混合一起做，加大排错难度。
3、前期准备工作不到位

分析：
广大的社区会员通过自身实际经验告诉我们数据迁移是一件繁琐，高危，但同时也是非常有成就感的一项工作，迁移工作涉及诸多知识点，风险意识，流程管理，备份，应急处理等诸多方面，对于完成一项具体的迁移工作，前期的准备工作准备的再繁琐，再充足都不算过分，切勿有侥幸心理。

五、总结：

通过聚焦存储，聚焦数据库，聚焦虚拟化以及聚焦迁移分析这几块内容的梳理与分析，可以清楚的认识到数据迁移工作对于广大的IT工作者有多么的重要。如何在面对每一次的备份需求，在符合公司流程的前提下，因地制宜指定合适的迁移方案，完善迁移的各种准备工作，严格谨慎的执行计划，取得一个美好的结果。这个是我们经常需要自问和探讨的问题，希望借本次活动在大家以后的迁移过程当中平滑完成。