IT运维无法躲避的宿命：升级和迁移

字数 7209阅读 6515评论 1赞 16

在IT运维工作中，我们经常会遇到各种问题和场景，最后要通过升级或迁移来解决，比如：
1. 为了解决软件缺陷、安全问题或者为了获取新功能进行软件升级，如系统或应用软件补丁升级。
2. 为了获取更改的硬件性能或可靠性进行的硬件扩容升级，如主机资源升级、存储扩容等。
3. 为更高的并行处理能力和灵活性进行的基于架构的升级，比如有单节点升级为集群架构。
4. 由于主机存储设备更新换代带来的系统迁移和数据迁移，同时也有可能因为兼容性问题带来的升级问题。
5. 由于底层基础架构的整合带来的P2V虚拟化迁移，比如基于x86环境的vmware或PowerVM的虚拟化迁移。

对于上面的各种情景，本文整理了一些升级和迁移相关的典型问题和相关案例供大家参考。
# 迁移及升级问题讨论
## 1.旧存储设备性能、容量和稳定性都跟不上了，新存储采购回来了，数据迁移如何做？
这种场景在我们的日常工作中遇到的比较多，非常具有代表性。不同的设备、环境及应用有着不同的应对方案。根据实施操作的对象来看，我们主要分以下三个场景来讨论。

（1）.基于操作系统的角度，这里主要是指利用操作系统本身的特性来做。比较典型的代表就是LVM（逻辑卷管理）。一般来讲主要步骤如下：
A.新的存储设备上架安装，做好连线并加电测试。
B.在SAN交换机上做好存储和主机的zone配置。
C.新存储划分同规格LUN映射给服务器。
D.服务器识别存储端的lun。
E.利用LVM逻辑卷镜像方式配置LV镜像，并启动同步。可根据业务负载，分批进行。
F.待LV同步完成并确认无误后，删除原存储的镜像。
G.将原存储的lun从操作系统的vg中删除，并删除设备。
H.原存储设备下线，完成迁移。
这种迁移方式的优点是，在线迁移，不需要停机窗口，而且直接使用系统内置的lvm功能即可，不需要额外的license费用，。缺点是受限于操作系统特性，如果操作系统不支持LVM特性，就无法采用了。
补充：如果存储层面采用了类似的第三方存储软件产品，如VxVM、GPFS等产品，也可以支持这种迁移方案。

（2）.基于虚拟化平台的角度。以VMware为例。
A.新的存储设备上架安装，做好连线并加电测试。
B.在SAN交换机上做好存储和主机的zone配置。
C. 新存储划分同规格LUN给到集群中所有ESXI上。
D. 利用Vmotion和storage Vmotion执行虚拟机和存储的迁移。
E. 待全部迁移完毕，并且稳定一段时间后，拆除旧存储LUN。
这种迁移方式直接通过vmware来实现，迁移之前需要查询官方文档，检查迁移的限制及版本之间的兼容性，并做好相关测试。
补充：这里仅讨论vmware平台，PowerVM平台的vios本质上就是aix，可以基于lvm来做。

（3）.基于应用软件本身特性来做。这里以oracle和db2为例
Oracle-ASM方式：
配置ASM冗余策略，利用ASM将新LUN加入到磁盘组的冗余组当中。
待数据同步完毕，并且稳定一段时间后，拆除旧存储。
重新配置ASM冗余策略。
A.新的存储设备上架安装，做好连线并加电测试。
B.在SAN交换机上做好存储和主机的zone配置。
C.新存储划分同规格LUN映射给服务器。
D.服务器识别存储端的lun，并配置为asmdisk或raw设备
E.将新的磁盘加入asmdiskgroup，再删除原有的磁盘成员。
F.asm会自动同步，通过查看v$asm_operation可监控进度。
G.同步完成后即可将设备删除，下线。
优点：可以在线做，不停止业务。
缺点：自动平衡，无法控制进度，一旦出现问题不好解决。
补充：oracle暂不支持asm冗余类型的转换，所以原生为external模式的asm磁盘组不能使用镜像的方式来做。
Oracle-other:
- 可以使用backupascopy的方式替换存储，停机时间较短。
- 可以采用dg物理备库的方式做。在线。
- 可以采用oraclegoldengate的方式来做。在线。
- 备份恢复或数据泵导入导出。停机时间长，取决于数据量。

DB2-storagegroup方式：
A.新的存储设备上架安装，做好连线并加电测试。
B.在SAN交换机上做好存储和主机的zone配置。
C.新存储划分同规格LUN映射给服务器。
D.服务器识别存储端的lun，配置对应的文件系统系统。
E.通过storagegroup增加删除path的方式替换存储。或者在新存储的文件系统上创建新的storagegroup，通过更好storagegroup的方式更换存储。
F.同步完成后即可将设备删除，下线。
优点：在线迁移。
缺点：db2存储组要求10.1或更高，需要设计好重平衡的时间。
补充：可以使用其他复制方案在线做，比如ogg、cdc、q复制等。也可以选择db2move或者重定向恢复等方式，停机时间依据数据量大小而定。

（4）.基于存储本身的角度来做。现在很多主流厂商的存储设备都自带存储虚拟化网关功能，或者提供迁移向导。可以在线的将原有存储数据迁移到新存储，以ibmv7000举例，执行如下步骤即可。
A. 新的v7000设备安装上架加电测试
B. 将v7000加入san环境中，重新设计zone信息，原有的存储和v7000做存储zone，v7000和主机做hostzone
C. 原存储的lun映射给v7000，v7000以image模式识别。
D. V7000将数据迁移到自身存储。
E.迁移完毕后，取消原存储的映射，原存储下线即可。
优点：停机时间极短，更改zone映射等。对应用透明，上层改动小
缺点：需要存储支持，需额外的license。
综上，迁移的方法有很多，但对于用户来说，具体情况具体分析。要选择最适合自己的方式，而不是片面的追求新技术。另外，所有的实施操作之前一定要做好备份，做好备份，做好备份，重要的事情说三遍。
## 2.新购买的存储无法兼容前端老旧系统，系统升级及迁移该如何设计规划？
又一个典型的场景，明明设计好的数据迁移，结果因为兼容性又带来了升级问题。一般情况下，在进行设备更换类型的数据迁移时，需要提前对新设备的兼容性做好确认工作，以免遇到兼容性问题导致迁移失败。一般的兼容性问题包含两个方面：
（1）.主机设备无法兼容新存储，比如新采购的v7000存储，主机还是最古老的rs6000小机。 就有可能遇到兼容性问题，或者虽然可以凑合使用，但是无法充分的发挥新设备的性能。这种情况其实还是建议升级前端主机的。
（2）. 主机设备上的操作系统无法兼容存储，比如新存储的多路径或存储代理等软件需要较高的操作系统版本支持。这时就需要规划操作系统的升级，以更好的满足存储的兼容要求。但是操作系统的升级又可能涉及到应用软件的兼容性。需要做好通盘规划。以免升级后，存储可以使用了，应用出现了异常。
除此之外还有一些特殊情况，比如应用软件已停止更新多年，只支持非常古老的系统，但更新的硬件设备又无法安装老系统。这时可以考虑通过虚拟化的方式实现。对于x86环境，可以使用vmware虚拟化，并做p2v迁移。对于Power平台，aix7.1支持versioned wpar功能，支持将5.2的aix迁移到7.1的wpar里面。这样就可以解决旧版操作系统和新设备之间的兼容性问题了。
## 3.上层应用升级更新后，新版应用不支持原来版本的数据库，如何规划升级？
一般整个业务系统的构成包含很多层面，从底层的存储系统、san网络、上层的主机、数据库、中间件等等都又涉及。有的时候看似简单的上层应用升级，却可以牵涉出大量的兼容性问题。比如新版本的应用对jdk的版本有要求，现有的application server又不支持新版的jdk。升级了新版中间件后呢，发现中间件和数据库的兼容性又有待确认。
这种升级场景实际上就是由上层应用倒逼的被动式升级了，已经到了不得不做的地步了。这种类型的升级还是建议按照传统模式的来，涉及应用的兼容性，其他需要做好测试和规划，一般包含如下步骤：
（1）在新的设备搭建一套新的环境，包括数据库、应用服务器。
（2）在新的环境中导入测试数据，前端从业务层进行相关可用性验证
（3）进行数据被备份迁入到测试环境的相关数据迁移时间实测评估
（4）进行数据库系统的升级测试，测试后再次进行应用验证
（5）停止生产系统的应用系统进行数据库升级，一般选择的停止窗口在业务低峰期，由于前期准备活动充分，基本系统停机时间约等于数据库升级时间。
（6）升级完成后进行应用层面的验证。
需要注意的是，升级之前一定做好数据备份并验证。准备好回退机制。
## 4.采购的新服务器设备不支持旧版操作系统，但因为停止更新的应用仅支持旧版os，应用迁移如何规划？
硬件产品对软件的支持都有兼容性要求，尤其是服务器产品。比如新采购的x86服务器，想再安装windows 2003或者windows 2000就比较困难了。但是因为应用的限制，又不能支持新版的操作系统。目前，虚拟化的架构应该是解决这种问题的一个很好的手段，而且技术成熟。维护简便，风险小。通过虚拟化平台的p2v迁移功能，可以将整个应用系统连同操作系统一起迁移到虚拟化平台上。
对于x86平台来说，vmware占据了大部分的企业级虚拟化市场份额。vmware虚拟化环境支持大多数主流操作系统，通过实施基于vmware的p2v迁移，我们可以原来的应用和操作系统一起迁移到虚拟化平台。并通过虚拟化平台做虚拟机级别的保护，使得应用同时得到性能和稳定性的收益。
至于Power平台，对于早期旧版本的aix系统，通过使用aix7.1内置的versioned wpar功能，可以将aix5.2/5.3版本的aix迁移到最新的Power8处理器平台，被迁移的aix版本最早支持到aix5.2 sp8。
但从长远来看，这终究这是一种治标不治本的手段。随着后续硬件的发展更新，将会拖着虚拟化的平台一起升级。最终可能还是会出现兼容的问题。根本的解决办法，还是在信息化上持续的投入，即使不保持实时系统最新。也尽量不要让软件和应用的的版本太落后。总的来说，升级是大势所趋。无论当下有怎样的困难，拖到最后也难免升级的命运。
## 5.原有的备份软件Network备份在带库的数据，如何迁移到新的、其他备份软件中，如TSM？
这种情况因为涉及到两种备份架构的变更，所以还是比较麻烦的，一般来讲有如下两种实现方式：
（1）.直接部署tsm环境，备份数据到新tsm系统。同时老的networker环境也不要删除，同时共存，只是将networker的备份调度都停了。等老network环境里的数据过期后，老磁带可以直接拿到新tsm环境中打标重用。
（2）. 利用 IBM Butterfly软件，直接迁移数据到新环境中。这个是ibm的一个服务，感兴趣可以找ibm咨询下。
## 6.单台存储设备有必要升级为双活吗？升级之后会不会影响到读写性能呢？
目前是单台V7000设备，出于安全考虑有了增加一台V7000做成双活的想法，请问升级之后会不会影响到读写性能。
关于是否要升级为双存储，主要是看自己的实际情况，如果对可用性有严苛的要求，肯定需要从架构上补齐短板，双存储确是可用增加可靠性。具体到存储高可用如何做呢，有两种实现方式：
（1）.可以基于主机做，如lvm mirror，基于主机lvm做的话还是需要调整一些东西的。以aix接双存储为例：
a. 创建vg的时候quorum应该为no
b. 硬盘hdisk的rw_timeout（每个读写操作超时的时长）和（发现丢包后多长时间通知主机的时长）参数的调整。
c. fscsix光纤卡设备的fc_err_recov参数，建议改为fast_fail默认为delay_fail ,故障时，可减少重路由时间
d. lv的读写策略，建议为chlv -d psxxxlv  即写所有，从主读取，保证读取速度

（2）.可以基于存储做，如vdm，在使用中实际是单读双写，性能会略有一点延迟，但不会太大。可以用工具压一下对比看看，如iorate工具，或者是oracle的orion工具。
# 案例分享
## 一、一次失败的aix系统升级以及挽救过程
原本是特别简单的一个case，数据库出现故障，经过数据库工程师分析是ibmaix的一个系统bug，需要升级aix补丁。
原计划的操作流程如下：
1. rootvg 拆镜像
2. 磁盘克隆（备份用，想着如果出了问题可以回退）
3. 升级aix，重启
4. 数据库启动并验证。

实际执行过程如下：
1. rootvg拆镜像，成功
2. 磁盘克隆，失败了。源盘出现了坏快，且无法修复，目标盘的克隆当然也就失败了。因为大意，系统还没备份。rootvg中主要安装了操作系统，安装了oracle数据库软件，其他的内容都在存储盘。
3. 万般无奈，重装aix，装在了好盘上，后来又调了一块盘做了镜像。重装了oracle数据库软件。
4. $ORACLE_BASE/admin/ORACLE_SID/ 目录下创建a/b/c/d/udump及pfile6个文件夹
5. $ORACLE/HOME/dbs目录下创建initSID.ora  内容为： spfile='/database/oradata/SID/spfile
6. 通过strings命令读取spfile和controlfile内容，检查数据文件、日志文件等路径。
7. 确认无误后启动数据库，最后有惊无险，把业务拉起来了。

教训：
重大操作前，一定要细致规划做好备份，有条件还要对备份进行验证。提前预估好维护时间窗口。
## 二、目录满了导致数据库升级hang住
一日，核心系统升级，几个点了升级脚本，开始等待。一般oracle数据库升级，也就增加一些字段，升级一些存储过程啥的，二十分钟左右。但是过了半小时还没好，已经到应急时间了，还有一小时不到就要拉起系统交易了。一边准备替代方案，一边开始找原因。
 1、查找升级目录下log，没有看出什么
 2、远程登录数据库，发现登陆不了，超时
 3、登录数据库操作系统，发现登录慢，登录 top下发现CPU，内存有点高但也只oracle几个自己进程
 4、df一看我看归档日志满了，赶快清理下目录，清理完后没几分钟，升级完成，编译一下，检查系统一切正常
   教训总结：
  1、升级中麻痹大意，没有及时注意情况；
  2、升级前没有及时关注目录使用率，导致后面出了状况；
建议：
 1、再熟悉的事也要当心，做好应急；
2、做事时要认真一点；
3、升级oracle比如跑的脚本内容过多，可以关闭归档（假如开了的话），升级完成无误后要立马开归档，再full backup下
## 三、一次无意的记录会话，挽救了我们自己
那是几年前，一月的一天我和两个同事给某电视台下属企业做aix系统升级,从5.2升级到5.3。
升级前：
做了数据库10.2.0.5（前期从10.2.0.4升级过来）、系统等各种备份，操作流程、应急预案也审查了几回，一切没问题。
升级中：
一切都很顺利。注意升级前升预升级，等跑了没事再commit。
有存储的，注意要不要升级多路径软件，尤其是aix大版本升级。
有数据库的，也要看看要升级的版本和现在的数据库版本有没有BUG、性能缺陷之类的。
升级后：
出事了，应用、开发、系统、数据库、网络、客服中心联测系统正常，准备收工走人。这时客户一运维经理说，你们把系统中之前备份的数据、老旧没有用清理一下。客户有要求，那还能说不吗，干呗。正好，同事之前传补丁的ftp程序还在，就删吧，当时心想，图形化有点危险的啊，应该没事。      
删着删着同事说：不好了，有个重要的配置文件被删了。 没过几分钟，客户那就有部门反应生产系统刷不了数据，查看不了产品了。
     那就恢复呗，要命的是恢复不了了。
1、smittymksysb备了系统，没备这个目录，恢复不了
2、其他地方还有备份不，没有
3、配置文件内容设置很多，有些老应用好多年经历了好多人，有的已经离职了，现在的人客户经理不敢保证100%  恢复
4、早晨6:00客服中心就要开始上线了，一旦出问题，会影响当天生产。
突然，我想起开始做之前，我上去做升级前检查好像cat了这个文件，还问了客户相关问题。赶快退出SecureCRT，查看保存的日志（因为我有个习惯，喜欢记录会话，方便写文档和回溯）。新建配置文件，把日志中之前cat的内容拷贝到创建的文件中，改好属性、权限。之后，重启应用，联测正常。
教训：
1、图形化用之慎之；
2、还是做好全面备份，不放过任何死角；
3、留痕很重要，有时能“救命”；
4、沟通很重要，和客户沟通足够透彻，因为客户的系统客户最熟悉
# 总结
经过上面典型问题的讨论以及相关案例的思考，关于升级和迁移了梳理以下几点：
1.不管升级还是迁移，规划很重要。
2.迁移的方式有很多种，适合自己的才是最好的。原则就是选择对业务系统影响最小的、变更最少的。优先推荐在线迁移。
3.升级操作一定要做好充分的测试。
4.一定要有备份，并且保证可恢复。
5.预留足够的操作窗口，包括回退机制。
6.必须要有实施计划，并保存所有的操作记录。

本文内容来自社区活动“IT运维无法躲避的宿命：升级和迁移”，内容产出包含赵海、bryan_sd、pysx0503、mmmsc5166、iceman1006、my979899、胡彦彬等会员，由会员王巧雷整理

升级 it运维

著作权归作者所有

如果觉得我的文章对您有用，请点赞。您的支持将鼓励我继续创作！