华锐藏经阁操作系统秘籍第三卷--RHEL操作系统内核升级操作方案
RHEL操作系统内核升级操作方案
1 引言
正如上一期《Linux操作系统系列系列文章__RHEL操作系统生命周期》所说，Red Hat公司对RHEL（Red Hat Enterprise Linux）只会提供有限的支持，其生命周期最多延长至10年。随着RHEL的不断迭代发展，旧版本的RHEL总有被淘汰的一天。即使为了保证业务的稳健运行，而不作过多变更，等到服务器设备老化淘汰的一天，也不得不面对这种选择：是尝试在新的服务器上部署新版本的RHEL？还是保持使用旧版本的RHEL？
一般情况下，每一代的服务器都有一定的供货期。设备厂商会有自己的产品迭代周期，一般在上一代产品的供货期结束之前，会发布新一代的服务器。新一代服务器搭载最新的硬件工艺和技术，确保对最新操作系统的兼容性，同时，逐渐放弃对过于老旧或市场占有率较少的操作系统的支持。过了这一段供货期，厂商不会再生产和供应上一代的设备，代理商也没有货。这种情况下，代理商会推荐客户选购新一代服务器。
基于以上分析，RHEL可能会因以下原因不得不升级：
1） RHEL发现了严重的内核Bug，且应用用到了与该Bug相关的操作系统模块；
2） RHEL使用的是主版本生命周期的早期版本，当前版本经过多轮迭代，性能、功能及其他特性更稳定，希望更新到更新的RHEL版本；
3） 新一代硬件不再支持旧版的RHEL版本。
其中原因1）、3）是不得不升，2）也是很多RHEL使用者升级的原因。
2 升级规则
在分析升级方案之前，首先要做好内核版本升级规划，明确当前使用或兼容的Red Hat Enterprise Linux内核版本和目标升级的内核版本号。
Red Hat对RHEL的内核版本有清晰的规划。对于一个内核版本号，前面三位是一个Red Hat Enterprise Linux主版本所使用的Linux内核版本号，相同主版本的RHEL这三位一致。第四位是子版本号，每半年发布的一个新的子版本会对这一位版本号进行升级更新。通过内核版本的前4位可以确定一个RHEL的版本号。第5位和第6位是内核补丁版本号，一般情况下，每隔1-2个月会发布一个新的内核补丁版本为客户解决前面的安全漏洞和优先级较高的功能问题，同时改动会比较小。内核补丁的升级旨在解决问题的基础上，尽量减小对现有系统的影响。
图2-1 Red Hat Enterprise Linux内核版本号说明
在一个RHEL版本的生命周期内，Red Hat会及时跟进解决已发布的安全漏洞和功能问题，如: Red Hat在2019年6月14日发布了RHEL 8的4.18.0-80.4.2.el8内核版本的升级包，升级到这个版本能够解决在此之前的全部RHEL 8内核安全漏洞。在同一个RHEL 版本中，内核安全漏洞补丁是累积的，可以直接升级到该RHEL版本的最新内核来解决所有安全漏洞。
图2-2 部分Red Hat Enterprise Linux版本及发布日期
但实际的生产环境和业务环境的内核升级场景是多样化的，归结起来，升级均依赖于Red Hat现有提供和发布的软件包。根据RHEL的相关软件包发布情况，升级可以分为以下三种场景：
（1） 跨RHEL主版本升级(如：RHEL 6 升级到RHEL7)；
（2） 跨RHEL子版本升级(如：RHEL7.2升级到RHEL7.4)；
（3） 在同一个子版本中的内核升级(如：RHEL7.5的3.10.0-862.el7升级到3.10.0.862.9.1.el7)。
3 跨Red Hat Enterprise Linux主版本升级
RHEL不支持RHEL 4, RHEL 5和RHEL 6之间跨主版本升级。如果强制升级，会替换所有的软件和服务，导致全部的系统配置和自定义设置丢失，而且无法保证升级后能否正常稳定运行。因此强烈建议通过全新安装的方式进行跨主版本升级。
Red Hat已在《Red Hat Enterprise Linux 7 Migration Planning Guide》[1]中声明，目前升级到RHEL 7 ，只有一条受支持的跨主版本升级路径：即从最新版本的RHEL 6升级到最新版本的Red Hat Enterprise Linux 7。从RHEL 7升级到RHEL 8的路径类似，但升级操作不一样，在此以升级RHEL 6为例。
3.1 升级前准备
如果出于研究的性质，或者现实的业务复杂的情况导致无法避免要直接通过主版本升级到RHEL 7，那么在做升级之前，先要确认操作系统环境具备升级的条件，同时做好升级的应急恢复方案。
（1） 确认当前操作系统为x86_64或ARM架构的RHEL 6操作系统。
# cat /etc/redhat-release
Red Hat Enterprise Linux Server release 6.6 (Santiago)
# arch
x86_64
（2） 订阅Red Hat更新，并将Red Hat Enterprise Linux 6的软件包都升到最新版本。
# subscription-manager register --username redhat_login_username --password redhat_password
# yum -y upgrade
#reboot
（3） 系统内只能包含以下软件包组，如果有其他包组，应先删除，待升级完成后再重新部署上去。注意，被删除的软件相关配置全部均会丢失，要做好备份和恢复策略。
a. Minimal
b. Base
c. Web Server
d. DHCP Server
e. NFS File Server
f. Print Server
g. CIFS file server
# yum grouplist
Loaded plugins: langpacks, product-id, search-disabled-repos, subscription-manager
This system is registered with an entitlement server, but is not receiving updates. You can use subscription-manager to assign subscriptions.
Installed Groups:
Minimal
System Management
E-mail server
Web Server
...
#yum groupinfo E-main server
# yum groupremove packagegroup E-mail server
（4） 整个操作系统进行克隆和备份，在克隆的副本上面进行RHEL7的升级测试，这样就能够在不影响业务生产环境的情况下，模拟和测试操作系统升级。
3.2 升级操作
跨RHEL主版本升级属于高危操作，必须现在克隆环境中进行升级验证，确保无误情况下，做好系统备份再实施升级。
（1） 安装和运行preupgrade。根据preupgrade运行输出，分析每一项目的检查结果是否为PASS或者FIXED。如果检查不通过，应停止后续的升级操作，或者安排计划解决不通过的项目直到preupgrade检查完全通过。
# subscription-manager repos --enable rhel-6-server-extras-rpms
# subscription-manager repos --enable rhel-6-server-optional-rpms
# yum -y install preupgrade-assistant preupgrade-assistant-ui preupgrade-assistant-contents
# preupg -y
（2） 安装redhat-upgrade-tool工具进行Red Hat Enterprise Linux 7 升级。在preupgrade的检查通过的前提下，才能进行此升级操作。需注意的是，升级操作执行后，不管成功与否，环境无法回退，所以一再强调，必须在克隆系统上面执行升级测试，避免升级出现异常导致无法挽回的损失。
# yum -y install redhat-upgrade-tool
# yum -y install yum-utils
# yum-config-manager --disable
# redhat-upgrade-tool --iso /home/rhel-server-XXX-x86_64.iso
#reboot
3.3 升级后检查
在上述步骤升级完了之后，确保新版本的RHEL 7能够正常重启。启动之后，先需检查当前操作系统版本是否为升级的目标版本。
# uname -r
3.10.0-693.el7.x86_64
# cat /etc/redhat-release
Red Hat Enterprise Linux Server release 7.4 (Maipo)
如果升级后，RHEL 7基本可用，则操作系统完成升级。接下来需要将前面删除的软件包重新部署，并且恢复业务环境。升级实际上分为两个部分，一个是RHEL 6升级到RHEL7，另一个是要验证业务软件对升级后环境的兼容性。整个过程没有出现问题情况下，才能将该升级应用到生产环境上。
4 跨Red Hat Enterprise Linux子版本升级
Red Hat对于跨RHEL子版本的升级，已经做得比较成熟，但不可避免的，依旧存在升级失败的风险。
Red Hat在RHEL生命周期内，每隔约半年时间发布一个新的RHEL子版本，解决上一个子版本中优先级较高，影响较大的安全问题和功能问题，同时加入了新的硬件支持。即升级后新的子版本能够运行在原来子版本的运行设备上，但是两个子版本之间的改动较大，需要评估升级前后的影响。
4.1 升级前准备
升级子版本之前，在确保业务软件对目标子版本的兼容的同时，还要做好完备的升级方案。子版本对RHEL会产生较大的变更，因此同样需要做好升级的应急恢复方案。
特别要注意的一点，跨子版本的升级会导致内核的版本变更。额外购置的设备配件或者特殊的设备，如果依赖于厂商的驱动。则在子版本升级后，系统跟原来一样能够识别该设备，但无法正常启用，需要向厂商获取该RHEL子版本的驱动包进行安装和启用设备。
（1）确认当前RHEL子版本与目标升级版本在同一个主版本内。
# cat /etc/redhat-release
Red Hat Enterprise Linux Server release 7.4 (Maipo)
（2）对整个操作系统进行克隆和备份，在克隆的副本上面进行RHEL目标子版本的升级测试，这样就能够在不影响业务生产环境的情况下，模拟和测试操作系统升级。
4.2 升级操作
跨RHEL子版本的升级会将Yum源内涉及的所有软件包进行覆盖升级，可能会导致相关软件的配置丢失。在升级之后，需要仔细排查，进行恢复和配置。不在Yum源范围内的软件包，在升级之后，根据它对其他软件包和库的依赖情况，评估是否需要升级。但可以明确的是，在升级前后，整个操作系统的动态链接库版本，主要的软件包版本均会升级到与目标子版本配套。
（1）将升级目标子版本的镜像配置升级所需的Yum源。
# mkdir /cdrom
#mount /home/rhel-server-XXX-x86_64.iso /cdrom
#vim /etc/yum.repos.d/update.repo
[CDROM]
name=isofile
baseurl=file:///mnt
enabled=1
gpgcheck=0
gpgkey=file:///mnt/RPM-GPG-KEY-redhat-release
# yum clean
#yum make cache
（2）通过Yum实施升级。
# yum -y update
#reboot
4.3 升级后检查
在上述步骤升级完了之后，确保新的Red Hat Enterprise Linux子版本系统能够正常重启。启动之后，先需检查当前操作系统版本是否为升级的目标版本。
# uname -r
3.10.0-957.el7.x86_64
# cat /etc/redhat-release
Red Hat Enterprise Linux Server release 7.6 (Maipo)
新的子版本升级之后，检查Red Hat Enterprise Linux正常重启后基本可用，然后相应配件的驱动进行安装。升级不仅仅是系统版本的升级，同样也要在升级后的环境中验证业务软件的功能和运行情况，评估该升级应用到生产环境的可行性。
5 在同一个子版本中的内核升级
在一个RHEL子版本的生命周期内, Red Hat每隔1-2个月会发布其内核的补丁，在其中合入内核相关的安全和功能补丁，并在内核软件包的Changelog中详细说明漏洞编号以及解决实现方案。
对于安全要求较高的业务场景，客户会紧跟安全漏洞的解决情况，需要及时在生产环境中更新升级内核，满足安全扫描的要求。安全扫描同时会对其他功能软件漏洞进行扫描，在此不对其进行过多赘述。内核的升级不同于其他软件包的一点是，内核的升级风险相对高一些，升级出现差错可能直接导致系统不可用。
5.1 升级前准备
内在同一个子版本内的内核升级，内核升级策略为在原有的RHEL系统上部署新版本的内核，涉及软件包范围较小，均为内核相关的软件包，但需要理清依赖关系，以及确保升级完全。通常情况下，如果上层业务软件依赖内核接口，新内核没有部署完全情况下，业务软件可能会同时调用新旧内核的内核接口库，无法评估给软件的稳健运行埋下多少隐患。
内核相关的软件包如下：
图5-1 内核软件包说明
（1） 确认当前操作系统为x86_64或arm架构的RHEL 6操作系统。
# uname -r
3.10.0-957.el7.x86_64
（2）检查生产环境中，使用的内核软件包列表，根据实际使用情况，下载对应的版本的内核软件包。
# rpm -qa |egrep "kernel-|linux-firmware-|kernel-debug-|kernel-devel-|kernel-debug-devel-|kernel-doc-|kernel-abi-whitelists-|kernel-headers-|kernel-tools-|kernel-tools-libs-|^perf-"
5.2 升级操作
同一个版本中的内核补丁的升级，影响范围较小，升级操作简单。如果出现升级失败的情况，可以回滚和恢复到原来的RHEL内核版本。因此在升级操作的时候，可以评估软件业务的运行情况，分析是否有必要进行操作系统克隆和软件备份。如果对内核接口依赖较小，可不需要对业务程序进行备份，直接升级RHEL内核补丁。
在升级内核补丁过程中，内核版本会发生变化。对于特殊的设备配件，一般不会有对应内核补丁版本的驱动软件包，需要向厂商获取驱动的源码包在升级后的新内核版本操作系统基础上进行编译和安装。
（1）升级内核补丁版本。将内核软件包统一上传到kernel_update目录进行批量升级。
# mkdir -p /home/kernel_update
# Upload kernel packages to /home/kernel_update
# rpm -ivh --force /home/kernel_update/* --nodeps
# reboot
5.3 升级后检查
升级完成后，检查当前RHEL是否为目标内核版本，确认无误则升级成功。内核升级完成后，需及时对设备配件的驱动包进行编译安装和验证业务软件的兼容性。
# uname -r
3.10.0-957.21.3.el7.x86_64
内核补丁版本的升级实质上是在原来的RHEL上新增部署一个内核。在新版本验证出现问题的时候，可以很便捷的切换到原内核版本和业务生产环境的恢复。
（1）查询系统开机启动项，选取原内核版本的启动项并设置为默认值。
# grep -rn "^menuentry" /boot/grub2/grub.cfg
# grub2-set-default "Red Hat Enterprise Linux Server (3.10.0-957.el7.x86_64) 7.6 (Maipo)"
# reboot
6 总结
目前应用最广的是同一个子版本内的内核升级。这种升级方法，操作简单，对系统改动较小，并且有完备的故障恢复方案。如果涉及到操作系统的主版本/子版本升级，操作难度较大，而且难以评估升级后的系统是否存在潜在的隐患，所以一般不会直接在原环境的基础上进行升级。这种情况下，软件厂商会推荐直接采购一批新的硬件并部署新版本的RHEL，在此上面通过测试之后，逐步迁移业务应用和数据。这是比较保守和安全的做法，前提是软件开发商能够提供兼容性的说明和报告。
新的内核能够解决存在的问题，新的RHEL版本能够支持新的技术和硬件，作为使用者，应紧跟RHEL的迭代更新，在保障业务安全运行的前提下，规划RHEL的升级周期和计划，紧跟和适配最前沿的技术。
参考文献：
[1] Red Hat Enterprise Linux Life Cycle site. https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/migration_planning_guide/chap-red_hat_enterprise_linux-migration_planning_guide-upgrading
RHEL操作系统内核升级操作方案
1 引言
正如上一期《Linux操作系统系列系列文章__RHEL操作系统生命周期》所说，Red Hat公司对RHEL（Red Hat Enterprise Linux）只会提供有限的支持，其生命周期最多延长至10年。随着RHEL的不断迭代发展，旧版本的RHEL总有被淘汰的一天。即使为了保证业务的稳健运行，而不作过多变更，等到服务器设备老化淘汰的一天，也不得不面对这种选择：是尝试在新的服务器上部署新版本的RHEL？还是保持使用旧版本的RHEL？
一般情况下，每一代的服务器都有一定的供货期。设备厂商会有自己的产品迭代周期，一般在上一代产品的供货期结束之前，会发布新一代的服务器。新一代服务器搭载最新的硬件工艺和技术，确保对最新操作系统的兼容性，同时，逐渐放弃对过于老旧或市场占有率较少的操作系统的支持。过了这一段供货期，厂商不会再生产和供应上一代的设备，代理商也没有货。这种情况下，代理商会推荐客户选购新一代服务器。
基于以上分析，RHEL可能会因以下原因不得不升级：
1） RHEL发现了严重的内核Bug，且应用用到了与该Bug相关的操作系统模块；
2） RHEL使用的是主版本生命周期的早期版本，当前版本经过多轮迭代，性能、功能及其他特性更稳定，希望更新到更新的RHEL版本；
3） 新一代硬件不再支持旧版的RHEL版本。
其中原因1）、3）是不得不升，2）也是很多RHEL使用者升级的原因。
2 升级规则
在分析升级方案之前，首先要做好内核版本升级规划，明确当前使用或兼容的Red Hat Enterprise Linux内核版本和目标升级的内核版本号。
Red Hat对RHEL的内核版本有清晰的规划。对于一个内核版本号，前面三位是一个Red Hat Enterprise Linux主版本所使用的Linux内核版本号，相同主版本的RHEL这三位一致。第四位是子版本号，每半年发布的一个新的子版本会对这一位版本号进行升级更新。通过内核版本的前4位可以确定一个RHEL的版本号。第5位和第6位是内核补丁版本号，一般情况下，每隔1-2个月会发布一个新的内核补丁版本为客户解决前面的安全漏洞和优先级较高的功能问题，同时改动会比较小。内核补丁的升级旨在解决问题的基础上，尽量减小对现有系统的影响。
图2-1 Red Hat Enterprise Linux内核版本号说明
在一个RHEL版本的生命周期内，Red Hat会及时跟进解决已发布的安全漏洞和功能问题，如: Red Hat在2019年6月14日发布了RHEL 8的4.18.0-80.4.2.el8内核版本的升级包，升级到这个版本能够解决在此之前的全部RHEL 8内核安全漏洞。在同一个RHEL 版本中，内核安全漏洞补丁是累积的，可以直接升级到该RHEL版本的最新内核来解决所有安全漏洞。
图2-2 部分Red Hat Enterprise Linux版本及发布日期
但实际的生产环境和业务环境的内核升级场景是多样化的，归结起来，升级均依赖于Red Hat现有提供和发布的软件包。根据RHEL的相关软件包发布情况，升级可以分为以下三种场景：
（1） 跨RHEL主版本升级(如：RHEL 6 升级到RHEL7)；
（2） 跨RHEL子版本升级(如：RHEL7.2升级到RHEL7.4)；
（3） 在同一个子版本中的内核升级(如：RHEL7.5的3.10.0-862.el7升级到3.10.0.862.9.1.el7)。
3 跨Red Hat Enterprise Linux主版本升级
RHEL不支持RHEL 4, RHEL 5和RHEL 6之间跨主版本升级。如果强制升级，会替换所有的软件和服务，导致全部的系统配置和自定义设置丢失，而且无法保证升级后能否正常稳定运行。因此强烈建议通过全新安装的方式进行跨主版本升级。
Red Hat已在《Red Hat Enterprise Linux 7 Migration Planning Guide》[1]中声明，目前升级到RHEL 7 ，只有一条受支持的跨主版本升级路径：即从最新版本的RHEL 6升级到最新版本的Red Hat Enterprise Linux 7。从RHEL 7升级到RHEL 8的路径类似，但升级操作不一样，在此以升级RHEL 6为例。
3.1 升级前准备
如果出于研究的性质，或者现实的业务复杂的情况导致无法避免要直接通过主版本升级到RHEL 7，那么在做升级之前，先要确认操作系统环境具备升级的条件，同时做好升级的应急恢复方案。
（1） 确认当前操作系统为x86_64或ARM架构的RHEL 6操作系统。
# cat /etc/redhat-release
Red Hat Enterprise Linux Server release 6.6 (Santiago)
# arch
x86_64
（2） 订阅Red Hat更新，并将Red Hat Enterprise Linux 6的软件包都升到最新版本。
# subscription-manager register --username redhat_login_username --password redhat_password
# yum -y upgrade
#reboot
（3） 系统内只能包含以下软件包组，如果有其他包组，应先删除，待升级完成后再重新部署上去。注意，被删除的软件相关配置全部均会丢失，要做好备份和恢复策略。
a. Minimal
b. Base
c. Web Server
d. DHCP Server
e. NFS File Server
f. Print Server
g. CIFS file server
# yum grouplist
Loaded plugins: langpacks, product-id, search-disabled-repos, subscription-manager
This system is registered with an entitlement server, but is not receiving updates. You can use subscription-manager to assign subscriptions.
Installed Groups:
Minimal
System Management
E-mail server
Web Server
...
#yum groupinfo E-main server
# yum groupremove packagegroup E-mail server
（4） 整个操作系统进行克隆和备份，在克隆的副本上面进行RHEL7的升级测试，这样就能够在不影响业务生产环境的情况下，模拟和测试操作系统升级。
3.2 升级操作
跨RHEL主版本升级属于高危操作，必须现在克隆环境中进行升级验证，确保无误情况下，做好系统备份再实施升级。
（1） 安装和运行preupgrade。根据preupgrade运行输出，分析每一项目的检查结果是否为PASS或者FIXED。如果检查不通过，应停止后续的升级操作，或者安排计划解决不通过的项目直到preupgrade检查完全通过。
# subscription-manager repos --enable rhel-6-server-extras-rpms
# subscription-manager repos --enable rhel-6-server-optional-rpms
# yum -y install preupgrade-assistant preupgrade-assistant-ui preupgrade-assistant-contents
# preupg -y
（2） 安装redhat-upgrade-tool工具进行Red Hat Enterprise Linux 7 升级。在preupgrade的检查通过的前提下，才能进行此升级操作。需注意的是，升级操作执行后，不管成功与否，环境无法回退，所以一再强调，必须在克隆系统上面执行升级测试，避免升级出现异常导致无法挽回的损失。
# yum -y install redhat-upgrade-tool
# yum -y install yum-utils
# yum-config-manager --disable
# redhat-upgrade-tool --iso /home/rhel-server-XXX-x86_64.iso
#reboot
3.3 升级后检查
在上述步骤升级完了之后，确保新版本的RHEL 7能够正常重启。启动之后，先需检查当前操作系统版本是否为升级的目标版本。
# uname -r
3.10.0-693.el7.x86_64
# cat /etc/redhat-release
Red Hat Enterprise Linux Server release 7.4 (Maipo)
如果升级后，RHEL 7基本可用，则操作系统完成升级。接下来需要将前面删除的软件包重新部署，并且恢复业务环境。升级实际上分为两个部分，一个是RHEL 6升级到RHEL7，另一个是要验证业务软件对升级后环境的兼容性。整个过程没有出现问题情况下，才能将该升级应用到生产环境上。
4 跨Red Hat Enterprise Linux子版本升级
Red Hat对于跨RHEL子版本的升级，已经做得比较成熟，但不可避免的，依旧存在升级失败的风险。
Red Hat在RHEL生命周期内，每隔约半年时间发布一个新的RHEL子版本，解决上一个子版本中优先级较高，影响较大的安全问题和功能问题，同时加入了新的硬件支持。即升级后新的子版本能够运行在原来子版本的运行设备上，但是两个子版本之间的改动较大，需要评估升级前后的影响。
4.1 升级前准备
升级子版本之前，在确保业务软件对目标子版本的兼容的同时，还要做好完备的升级方案。子版本对RHEL会产生较大的变更，因此同样需要做好升级的应急恢复方案。
特别要注意的一点，跨子版本的升级会导致内核的版本变更。额外购置的设备配件或者特殊的设备，如果依赖于厂商的驱动。则在子版本升级后，系统跟原来一样能够识别该设备，但无法正常启用，需要向厂商获取该RHEL子版本的驱动包进行安装和启用设备。
（1）确认当前RHEL子版本与目标升级版本在同一个主版本内。
# cat /etc/redhat-release
Red Hat Enterprise Linux Server release 7.4 (Maipo)
（2）对整个操作系统进行克隆和备份，在克隆的副本上面进行RHEL目标子版本的升级测试，这样就能够在不影响业务生产环境的情况下，模拟和测试操作系统升级。
4.2 升级操作
跨RHEL子版本的升级会将Yum源内涉及的所有软件包进行覆盖升级，可能会导致相关软件的配置丢失。在升级之后，需要仔细排查，进行恢复和配置。不在Yum源范围内的软件包，在升级之后，根据它对其他软件包和库的依赖情况，评估是否需要升级。但可以明确的是，在升级前后，整个操作系统的动态链接库版本，主要的软件包版本均会升级到与目标子版本配套。
（1）将升级目标子版本的镜像配置升级所需的Yum源。
# mkdir /cdrom
#mount /home/rhel-server-XXX-x86_64.iso /cdrom
#vim /etc/yum.repos.d/update.repo
[CDROM]
name=isofile
baseurl=file:///mnt
enabled=1
gpgcheck=0
gpgkey=file:///mnt/RPM-GPG-KEY-redhat-release
# yum clean
#yum make cache
（2）通过Yum实施升级。
# yum -y update
#reboot
4.3 升级后检查
在上述步骤升级完了之后，确保新的Red Hat Enterprise Linux子版本系统能够正常重启。启动之后，先需检查当前操作系统版本是否为升级的目标版本。
# uname -r
3.10.0-957.el7.x86_64
# cat /etc/redhat-release
Red Hat Enterprise Linux Server release 7.6 (Maipo)
新的子版本升级之后，检查Red Hat Enterprise Linux正常重启后基本可用，然后相应配件的驱动进行安装。升级不仅仅是系统版本的升级，同样也要在升级后的环境中验证业务软件的功能和运行情况，评估该升级应用到生产环境的可行性。
5 在同一个子版本中的内核升级
在一个RHEL子版本的生命周期内, Red Hat每隔1-2个月会发布其内核的补丁，在其中合入内核相关的安全和功能补丁，并在内核软件包的Changelog中详细说明漏洞编号以及解决实现方案。
对于安全要求较高的业务场景，客户会紧跟安全漏洞的解决情况，需要及时在生产环境中更新升级内核，满足安全扫描的要求。安全扫描同时会对其他功能软件漏洞进行扫描，在此不对其进行过多赘述。内核的升级不同于其他软件包的一点是，内核的升级风险相对高一些，升级出现差错可能直接导致系统不可用。
5.1 升级前准备
内在同一个子版本内的内核升级，内核升级策略为在原有的RHEL系统上部署新版本的内核，涉及软件包范围较小，均为内核相关的软件包，但需要理清依赖关系，以及确保升级完全。通常情况下，如果上层业务软件依赖内核接口，新内核没有部署完全情况下，业务软件可能会同时调用新旧内核的内核接口库，无法评估给软件的稳健运行埋下多少隐患。
内核相关的软件包如下：
图5-1 内核软件包说明
（1） 确认当前操作系统为x86_64或arm架构的RHEL 6操作系统。
# uname -r
3.10.0-957.el7.x86_64
（2）检查生产环境中，使用的内核软件包列表，根据实际使用情况，下载对应的版本的内核软件包。
# rpm -qa |egrep "kernel-|linux-firmware-|kernel-debug-|kernel-devel-|kernel-debug-devel-|kernel-doc-|kernel-abi-whitelists-|kernel-headers-|kernel-tools-|kernel-tools-libs-|^perf-"
5.2 升级操作
同一个版本中的内核补丁的升级，影响范围较小，升级操作简单。如果出现升级失败的情况，可以回滚和恢复到原来的RHEL内核版本。因此在升级操作的时候，可以评估软件业务的运行情况，分析是否有必要进行操作系统克隆和软件备份。如果对内核接口依赖较小，可不需要对业务程序进行备份，直接升级RHEL内核补丁。
在升级内核补丁过程中，内核版本会发生变化。对于特殊的设备配件，一般不会有对应内核补丁版本的驱动软件包，需要向厂商获取驱动的源码包在升级后的新内核版本操作系统基础上进行编译和安装。
（1）升级内核补丁版本。将内核软件包统一上传到kernel_update目录进行批量升级。
# mkdir -p /home/kernel_update
# Upload kernel packages to /home/kernel_update
# rpm -ivh --force /home/kernel_update/* --nodeps
# reboot
5.3 升级后检查
升级完成后，检查当前RHEL是否为目标内核版本，确认无误则升级成功。内核升级完成后，需及时对设备配件的驱动包进行编译安装和验证业务软件的兼容性。
# uname -r
3.10.0-957.21.3.el7.x86_64
内核补丁版本的升级实质上是在原来的RHEL上新增部署一个内核。在新版本验证出现问题的时候，可以很便捷的切换到原内核版本和业务生产环境的恢复。
（1）查询系统开机启动项，选取原内核版本的启动项并设置为默认值。
# grep -rn "^menuentry" /boot/grub2/grub.cfg
# grub2-set-default "Red Hat Enterprise Linux Server (3.10.0-957.el7.x86_64) 7.6 (Maipo)"
# reboot
6 总结
目前应用最广的是同一个子版本内的内核升级。这种升级方法，操作简单，对系统改动较小，并且有完备的故障恢复方案。如果涉及到操作系统的主版本/子版本升级，操作难度较大，而且难以评估升级后的系统是否存在潜在的隐患，所以一般不会直接在原环境的基础上进行升级。这种情况下，软件厂商会推荐直接采购一批新的硬件并部署新版本的RHEL，在此上面通过测试之后，逐步迁移业务应用和数据。这是比较保守和安全的做法，前提是软件开发商能够提供兼容性的说明和报告。
新的内核能够解决存在的问题，新的RHEL版本能够支持新的技术和硬件，作为使用者，应紧跟RHEL的迭代更新，在保障业务安全运行的前提下，规划RHEL的升级周期和计划，紧跟和适配最前沿的技术。
参考文献：
[1] Red Hat Enterprise Linux Life Cycle site. https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/migration_planning_guide/chap-red_hat_enterprise_linux-migration_planning_guide-upgrading
个子版本内的内核升级。这种升级方法，操作简单，对系统改动较小，并且有完备的故障恢复方案。如果涉及到操作系统的主版本/子版本升级，操作难度较大，而且难以评估升级后的系统是否存在潜在的隐患，所以一般不会直接在原环境的基础上进行升级。这种情况下，软件厂商会推荐直接采购一批新的硬件并部署新版本的RHEL，在此上面通过测试之后，逐步迁移业务应用和数据。这是比较保守和安全的做法，前提是软件开发商能够提供兼容性的说明和报告。
新的内核能够解决存在的问题，新的RHEL版本能够支持新的技术和硬件，作为使用者，应紧跟RHEL的迭代更新，在保障业务安全运行的前提下，规划RHEL的升级周期和计划，紧跟和适配最前沿的技术。
参考文献：
[1] Red Hat Enterprise Linux Life Cycle site. https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/migration_planning_guide/chap-red_hat_enterprise_linux-migration_planning_guide-upgrading