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和storageVmotion实行假造机和存储的迁徙。
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支持versionedwpar功能，支持将5.2的aix迁徙到7.1的wpar内里。如许就可以办理旧版操纵体系和新装备之间的兼容性题目了。
3.上层应用升级更新后，新版应用不支持原来版本的数据库，怎样规划升级？
一样平常整个业务体系的构成包罗很多层面，从底层的存储体系、san网络、上层的主机、数据库、中心件等等都又涉及。有的时间看似简单的上层应用升级，却可以扳连出大量的兼容性题目。比如新版本的应用对jdk的版本有要求，现有的applicationserver又不支持新版的jdk。升级了新版中心件后呢，发现中心件和数据库的兼容性又有待确认。
这种升级场景实际上就是由上层应用倒逼的被动式升级了，已经到了不得不做的地步了。这种范例的升级还是发起按照传统模式的来，涉及应用的兼容性，其他必要做好测试和规划，一样平常包罗如下步调：
（1）在新的装备搭建一套新的环境，包罗数据库、应用服务器。
（2）在新的环境中导入测试数据，前端从业务层举行相干可用性验证
（3）举行数据被备份迁入到测试环境的相干数据迁徙时间实测评估
（4）举行数据库体系的升级测试，测试后再次举行应用验证
（5）克制生产体系的应用体系举行数据库升级，一样平常选择的克制窗口在业务低峰期，由于前期预备活动充实，根本体系停机时间约便是数据库升级时间。
（6）升级完成后举行应用层面的验证。
必要留意的是，升级之前肯定做好数据备份并验证。预备好回退机制。
4.采购的新服务器装备不支持旧版操纵体系，但由于克制更新的应用仅支持旧版os，应用迁徙怎样规划？
硬件产物对软件的支持都有兼容性要求，尤其是服务器产物。比如新采购的x86服务器，想再安装windows2003大概windows2000就比力困难了。但是由于应用的限定，又不能支持新版的操纵体系。如今，假造化的架构应该是办理这种题目的一个很好的本领，而且技能成熟。维护轻便，风险小。通过假造化平台的p2v迁徙功能，可以将整个应用体系连同操纵系同一起迁徙到假造化平台上。
对于x86平台来说，vmware占据了大部分的企业级假造化市场份额。vmware假造化环境支持大多数主流操纵体系，通过实行基于vmware的p2v迁徙，我们可以原来的应用和操纵系同一起迁徙到假造化平台。并通过假造化平台做假造机级别的掩护，使得应用同时得到性能和稳固性的收益。
至于Power平台，对于早期旧版本的aix体系，通过利用aix7.1内置的versionedwpar功能，可以将aix5.2/5.3版本的aix迁徙到最新的Power8处理惩罚器平台，被迁徙的aix版本最早支持到aix5.2sp8。
但从长远来看，这终究这是一种治标不治本的本领。随着后续硬件的发展更新，将会拖着假造化的平台一起升级。终极大概还是会出现兼容的题目。根本的办理办法，还是在信息化上连续的投入，纵然不保持及时体系最新。也只管不要让软件和应用的的版本太掉队。总的来说，升级是局面所趋。无论当下有怎样的困难，拖到末了也不免升级的运气。
5.原有的备份软件Network备份在带库的数据，怎样迁徙到新的、其他备份软件中，如TSM？
这种环境由于涉及到两种备份架构的变动，以是还是比力贫苦的，一样平常来讲有如下两种实现方式：
（1）.直接摆设tsm环境，备份数据到新tsm体系。同时老的networker环境也不要删除，同时共存，只是将networker的备份调治都停了。等老network环境里的数据逾期后，老磁带可以直接拿到新tsm环境中打标重用。
（2）.利用IBMButterfly软件，直接迁徙数据到新环境中。这个是ibm的一个服务，感爱好可以找ibm咨询下。
6.单台存储装备有须要升级为双活吗？升级之后会不会影响到读写性能呢？
如今是单台V7000装备，出于安全思量有了增长一台V7000做成双活的想法，叨教升级之后会不会影响到读写性能。
关于是否要升级为双存储，重要是看本身的实际环境，假如对可用性有严苛的要求，肯定必要从架构上补齐短板，双存储确是可用增长可靠性。具体到存储高可用怎样做呢，有两种实现方式：
（1）.可以基于主机做，如lvmmirror，基于主机lvm做的话还是必要调解一些东西的。以aix接双存储为例：
a.创建vg的时间quorum应该为no
b.硬盘hdisk的rw_timeout（每个读写操纵超时的时长）和（发现丢包后多长时间关照主机的时长）参数的调解。
c.fscsix光纤卡装备的fc_err_recov参数，发起改为fast_fail默以为delay_fail,故障时，可镌汰重路由时间
d.lv的读写战略，发起为chlv-dpsxxxlv即写全部，从主读取，包管读取速率
（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比如跑的脚本内容过多，可以关闭归档（假如开了的话），升级完成无误后要立马开归档，再fullbackup下
案例三、一次偶然的记录会话，救济了我们本身
那是几年前，一月的一天我和两个同事给某电视台部属企业做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”关注
CopyrightYourWebSite.SomeRightsReserved.
京ICP备2023016396号-1PoweredByESCLINK.
我要评论