步入中老年的信息系统如何迁移改造讨论精选

前言：作为系统运维人员，我们被快速发展的技术推着不得不想尽各种省钱的办法来维持这套陈旧系统的寿命。
虽然对技术人员来说，整体升级是最简单，有效的改造方式，但企业也的确会有人员，资金，业务连续性的因素而迫使技术人员不得不把整体改造进行分割，逐步迁移，切换，而这种在陈旧系统上所做的改造，迁移也就增加了很多的风险。
陈旧的设备往往每一次重启都伴随着风险，过低的系统，应用版本与新硬件之间存在着严重的兼容问题，老旧的业务缺少技术支持，没有明确的技术文档,有些系统干脆已经没有人能够进行调试配置了，这些都是陈旧系统做局部改造时面临的问题。
本次活动的主旨就是和大家共同讨论陈旧的企业信息话如何升级，如何避免升级带来的各种风险，选择合理的架构来进行企业信息化的升级改造。让大家了解老旧的信息系统如何改造，如何做到对系统影响最小，投资最少。本次活动主要包含：陈旧系统架构分析，虚拟化架构选择，系统架构迁移手段，新旧系统迁移注意等几方面

1: 原存储如何升级改造？

某制造企业客户想构建数据中心双活，目前想先实现存储双活，两个数据中心同城以后会建立异地灾备
目前是多台小型机链接好几个存储，在一个数据中心，切采用的是传统的磁带备份模式，目前数据中心在工厂内部，准备租个机房构建同城灾备，目前都是两台小型机一个存储构建成一个双机系统运行不同业务系统，包含erp系统。现在客户购买了一套存储容量够五年之内用，想把数据在线迁移到新存储上，且新旧存储同时对外服务， 如何实现存储双活？有什么可用的方案？且在实施中不能中断业务?
两种情况考虑，1.存储数据如何无缝迁移？ 2.存储如何实现双活？

对于第一个问题：
新旧存储都提供服务，这个比较模糊，是业务级别的服务还是说存储级别的功能服务？如果是小型机实现的双机系统，那么我理解这个同时提供服务应该不是业务级别的同时提供，因为双机机制决定了一个时刻点只能有一个服务器在提供对外业务。所谓的同时服务我理解为一份数据能被两个存储同时提供给服务器而已。
另外既然是两台小型机实现的双机系统，那么应该是用到LVM存储卷管理了。那么迁移的方式可以是LVM镜像迁移方式：
前提条件，做个备份。
1）新的存储并入既有SAN环境。
2）按照既有卷配置，将新存储配置并划分卷给主机。
3）在LVM层面创建镜像并且找业务不繁忙的时间进行卷的镜像同步。
4）拆除镜像（旧的存储镜像）。

至于第二个问题，存储如何实现双活？
那么要看你准备用的存储双活架构是什么？是基于存储层做虚拟化之后来实现存储级别的双镜像？还是说基于主机层的存储卷管理层实现跨中心的LVM镜像？还是说靠传统的存储复制实现两中心的存储数据同步？而且你的双中心之间是什么样的一个网络架构？SAN环境是一个大环境还是说两个隔离的逻辑环境仅仅靠双中心的波分设备实现传输等等？

2：讨论话题：旧系统如何迁移到虚拟化？

我们是钢铁行业，在生产环境中有很多陈旧而昂贵的工业控制系统，大多系统被绑架与国外的工控厂家中，我接触到的一个例子就是，霍尼韦尔系统，装在一台老旧的DELL服务上。据称霍尼韦尔的专家过来调试这东西在全部顺利的情况下大约需要3天，系统运行到现在，已经有10年以上了。想要购买新设备来重新搭建，厂商报的价格6位数以上，还不包括工程师出门开始计算的费用。在这种情况下，我们开始尝试对系统进行虚拟化，我们现有的虚拟化平台是VMWARE。采用vmware p2v对老系统进行转化。尝试过两台终端进行转化，其中一台成功了。另外一台由于系统太老。在p2V的转换中代理服务无法顺利的安装到目标物理机中而导致失败。
虽然这种尝试并不顺利，但至少算是一种折中的解决办法。可以通过对陈旧系统的虚拟化迁移来解决老系统与新硬件之间的兼容问题。对于vmware平台我们主要采用过一下两种方式进行虚拟化迁移。

1.p2v
优点：通过网络，在线对旧系统进行虚拟化迁移，不需要中断业务，
缺点：需要在目标机中安装代理插件，需要网络健康，目标机共享可以访问，有管理员权限，目标机需要健康，有时候一些无法服务无法启动，一些策略被修改而导致代理插件无法顺利安装。

2.通过对原有GHOST备份的虚拟化转换生成新的虚拟化系统。
以下是具体的方法
用ghost直接将gho转成vmdk
将ghost32, gho文件放到同一目录, cmd里进入对应目录，输入以下命令
ghost32 -clone,mode=restore,src=example.gho,dst=example.vmdk -batch -sure
example替换为对应文件名，很快就转好了。vm不能直接打开转好的vmdk文件，于是我们创建虚拟空白硬盘，建好后编辑，移除自带的硬盘，添加一个硬盘，注意要选择已存在硬盘，然后选择vmdk的路径，保存就可以开机了。
另：将vmdk文件转为gho
命令如下：
ghost32 -clone,mode=create,src=example.vmdk,dst=example.gho -batch -sure
反复操作你会发现vmdk转出来的gho文件会偏大。
优点：通过转换提前备份好的GHO文件，成功率高，转换过程稳定，不依赖网络。
缺点：需要停机进行系统GHOST备份，有些服务器RAID卡，GHOST无法识别导致无法备份。
旧系统跑在X86/Power上，各自都有各个的解决方案

1 X86使用P2V工具迁移到虚拟化平台。P2V对windows成功率还高点，Lin就弱了
大部分迁移的工作量其实还是数据这块，旧系统架构决定了迁移的难度和复杂度。
2 Power平台迁移到虚拟化，其实相对简单，操作系统可以有多重方式备份恢复
共享存储数据也有很多工具，利用AIX或者存储本身技术实现数据的迁移工作。

3：核心系统如何在线迁移不影响应用和数据

客户原来有2台power5 570 的机器跑的是核心应用，oracle双机，且运行多年？当时购买费用挺贵，也不舍得浪费就一直运行，现由于机器设备太旧，部件也陆续出现故障，为了不影响应用？如果在线把应用数据迁移到新的power8 服务器上，从架构层如何考虑？迁移时重要一点是业务不能停，怎么实现？有何注意事项

1 可以考虑使用lpm方案，但是需要考虑很多前置条件
2 既然是rac，可以通过增删节点实现，不过这个风险和实施难度更大
3 数据很好在线迁移到新的存储，关键业务不能停有难度

个人一些建议
1、首先这个难度挺大的，操作系统和数据库版本、数据库真实数据量多大、停机窗口等很多环节需要确定下。
2、需要考虑在新机器上安装老版本操作系统，通过老机器用oracle DG同步到新机器。
3、新机器上做操作系统升级和数据库升级操作。
4、验证业务一致性有没问题后正式迁移。

一定要先搭环境测试没问题，后做正式迁移，记住迁移前还得做数据库全备。
个人建议，如果是核心系统的吧，建议还是不要动之前的系统和服务器。这是最重要的原则，你要是动了，在上面先改造，再进行迁移的话，风险太大，搞出问题来就无法挽救。
涉及到这种核心系统的迁移，我认为可以考虑在外面搭建新的核心服务器，再进行迁移和切换的方式来做，切换时一定要停！停机窗口一定需要有的，但是这个窗口可以尽量缩短。因为数据都在存储上，迁移无非就是rootvg的迁移，这个很好办，克隆，备份恢复，存储复制都是一种办法。
这样做最大的好处就是风险最小化，有回退余地。停机时间窗口找监管部门报备即可。

4：VMware层面，日志及数据库虚拟机的备份

现在很多单位新上业务时，会尽量选择X86平台。针对数据库虚拟机或者日志较大的虚拟机的备份，有没有一个成熟的方案？如果通过LAN备份，由于前期没有规划备份网络，走业务网络必然对业务有一定的影响。第二个问题是如果上VMware虚拟化平台，vmware不建议搭建oracle rac集群，单点的话，物理机故障时，必然对业务有影响，大家对这块有没有好的方案？
ORACLE RAC可以很好的在VM 平台上运行的非常稳定.尽量使用双ESXI放两个RAC节点.ORACLE的卷都使用RDM磁盘.
备份这一块.基本上两种方式.1 种就是网络备份.你说怕影响业务.那可以使用SAN备份.
SAN备份架构一般就是把DATASTORE 也同时mapping给备份主机.然后由备份软件发起备份业务.然后通过VSAN网络直接写入备份目标.比较带库等.
这个速度快.尽量非业务时间备份.要不会影响存储IO.
另外还有一种技术就是离线备份.两个存储LUN做MIRROR.业务LUN是不备份的.备份的时候从MIRROR LUN来读数据.这个是完全可以的.架构可以参考上面的SAN架构.
优点是不影响业务系统IO.随时备份.速度快.就是成本高

5：有些老程序必须运行在XP系统上，而现在的最新主板已经不支持XP系统了，大家有啥好办法？

我们的做法是在win7或者win10下安装虚拟机装XP系统，然后在虚拟机中安装老程序。大家有其他好办法吗？
我们现在面对的也是这样的问题。基本上的解决办法就是两条路，
1，想要维持现状，那就做桌面虚拟化，总体来说现在的桌面虚拟化技术都还不错。算是一种合理的解决方案。但终究会有一天虚拟化也无法支撑这么老的业务
2，升级程序，大面积的改造。
建议是两步并行。桌面虚拟化解决目前问题，软件规划升级。做长远规划。

致谢
__
非常感谢 AIX 专家俱乐部活动方，你们精心的组织，成就了这一场分享。感谢参与同仁，这种互动的讨论方式，让彼此受益颇多。