IT运维无法躲避的宿命就是升级和迁徙 ，我们常常 会碰到 各种题目 和场景，末了 要通过升级或迁徙 来办理 。针对下面各种场景，本文整理了一些升级和迁徙 相干 的典范 题目 和相干 案例供各人 参考 ，妥妥干货，非常实用 。
1. 为了办理 软件缺陷、安全题目 大概 为了获取新功能举行 软件升级，如体系 或应用软件补丁升级。
2. 为了获取更改的硬件性能或可靠性举行 的硬件扩容升级 ，如主机资源升级 、存储扩容等。
3. 为更高的并行处理 惩罚 本领 和机动 性举行 的基于架构的升级，比如 有单节点升级为集群架构 。
4. 由于主机存储装备 更新换代带来的体系 迁徙 和数据迁徙 ，同时也有大概 由于 兼容性题目 带来的升级题目 。
5. 由于底层底子 架构的整合带来的P2V假造 化迁徙 ，比如 基于x86环境 的vmware或PowerVM的假造 化迁徙 。
本文内容来自社区活动 “IT运维无法躲避的宿命：升级和迁徙 ” ，贡献内容的有：赵海、bryan_sd、pysx0503 、mmmsc5166、iceman1006、my979899 、胡彦彬等；由王巧雷整理汇编 。
一、迁徙 及升级典范 题目 应对之策
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运维无法躲避的宿命：升级和迁徙 ”交换 活动 ，请点击阅读原文
也可以直接搜刮 公众号名称“AIX专家俱乐部 ”或微信号“AIXChina”关注
