EXADATA软件升级初体验

梁铭图 2019-08-27 20:46:00

作者介绍

梁铭图，新炬网络首席架构师，十多年数据库运维、数据库设计、数据治理以及系统规划建设经验，拥有Oracle OCM、Togaf企业架构师（鉴定级）、IBM CATE等认证，曾获dbaplus年度MVP以及华为云MVP等荣誉，并参与数据资产管理国家标准的编写工作。在数据库运维管理和架构设计、运维体系规划、数据资产管理方面有深入研究。

一、Exadata升级简介

Oracle EXADATA软件升级是一个相对复杂的工程，其中牵涉到image版本与硬件的匹配，image版本与oracle集群及oracle database软件的匹配，整个升级过程可能会对firmware，操作系统和部署于操作系统上的exadata相关软件进行同步升级，升级过程风险较高，需要提前做好完善的准备工作，避免升级失败对升级后的系统运行产生影响，进而造成业务运行上的损失。

本次以一套X7-2 3+2 exadata为例，介绍如何将exadata软件版本从18.1.13.0.0升级至19.2.11.0.0，主要介绍下升级过程。升级过程包括：存储节点的image升级，计算节点的image升级，infiniband交换机。

二、升级的操作流程

第一步，滚动方式升级exadata的3个存储节点的cell image到19.2.11。

第二步，滚动方式升级exadata的2个计算节点的db image到19.2.11。

第三步，滚动方式升级exadata的2台交换机InfiniBand的版本至2.2.14-1。

首先在oracle官方网站上下载升级工具和相关介质：

1、计算节点DB image升级使用的升级工具及介质

p21634633_193300_Linux-x86-64.zip

*升级工具dbnodeupdate*

p30753855_192000_Linux-x86-64.zip

（Database server bare metal / domU ULN exadata_dbserver_19.2.11.0.0_x86_64_base OL7 channel ISO image (19.2.11.0.0.200224)）

2、存储节点cell image升级和InfiniBand升级使用介质

p30886159_192000_Linux-x86-64.zip

（Storage server software (19.2.11.0.0.200224) and InfiniBand switch software (2.2.14-1)）

三、升级前的准备工作

1、准备各节点间的SSH互信关系

image升级过程均使用SSH将软件和命令传输至相应节点进行，故应建立操作节点与升级节点之间的互信关系，以便于升级进行。

本次升级过程以计算节点1作为主要操作节点，故应建立所有存储节点与计算节点1之间，所有infiniband交换机与计算节点1之间在root用户下的互信关系，因升级计算节点软件时2个计算节点互为操作节点，故应建立2个计算节点之间root用户下的互信关系。

互信关系建立示例如下：

首先在计算节点1 touch一个文件：cells_group，配置上3个存储节点的主机名（或者IP地址），另外touch一个文件：ibs_group，配置上2台IB交换机的主机名（或IP地址），touc一个文件：all_dbs_group，配置上2个计算节点的主机名。本例中各节点主机名假设为：cell01，cell02，cell03，iba0，ibb0，db01，db02。

执行下列命令，检查互信关系是否存在。如果不需要输入密码能够直接显示，则表示互信关系正常。

示例：

1）存储节点信任关系检查

# cat ~/cells_group

cell01

cell02

Cell03

# dcli -g ~/cells_group -l root "date"

[root@db01 ~]# dcli -g ~/cells_group -l root "date"

cell01: Mon Feb 10 11:02:55 CST 2020

cell02: Mon Feb 10 11:02:55 CST 2020

cell03: Mon Feb 10 11:02:55 CST 2020

2）计算节点信任关系检查

# cat ~/all_dbs_group

db01

db02

# dcli -g ~/all_dbs_group -l root "date"

[root@db01 ~]# dcli -g ~/all_dbs_group -l root "date"

db01: Mon Feb 10 11:03:36 CST 2020

db02: Mon Feb 10 11:03:36 CST 2020

3）ib交换机信任关系检查

# cat ~/ibs_group

iba0

ibb0

# dcli -g ~/ibs_group -l root "date"

[root@db01 ~]# dcli -g ~/ibs_group -l root "date"

iba0: Mon Feb 10 11:07:48 CST 2020

ibb0: Mon Feb 10 11:07:48 CST 2020

检查如果发现信任关系存在问题，可以使用使用如下命令，重建信任关系。

# ssh-keygen -t rsa

# dcli -k -g ~/cells_group -l root

(输入root密码)

# dcli -k -g ~/ibs_group -l root

(输入root密码)

# dcli -k -g ~/all_dbs_group -l root

(输入root密码)

2、清理计算节点后期安装的RPM包

一般情况下计算节点可能存在用户后期安装RPM包的情况，后期安装的RPM包往往因为升级过程中无法自动解决其依赖性关系而导致升级预检查失败，从而导致升级无法继续，故应提前删除用户定制的RPM包，待升级完成后再行安装。

备份各计算节点安装的RPM包情况：

# dcli -g ~/all_dbs_group -l root "rpm -q --all --last > /home/oracle/rpm_infobackup.txt"

3、检查计算节点和存储节点/目录情况，必要时进行清理，释放空间

检查计算节点和存储节点/ 目录情况：

# dcli -g ~/all_dbs_group -l root "df -h /"

# dcli -g ~/cells_group -l root "df -h /"

删除不必要的文件和日志内容，对/ 目录进行清理。

4、升级前Exachk检查

# cd /home/oracle/exachk

# export RAT_TIMEOUT=1200

# export RAT_ROOT_TIMEOUT=6000

# ./exachk -a

分析exachk报告，确保exadata一体机无影响升级的严重软硬件错误。

5、重启3个存储节点的ilom，重启2个计算节点ilom

重启方法如下：

# ssh cell01-ilom

->reset /SP

四、升级步骤

1、存储节点cell image升级

1）检查内核、硬件设备、网络配置信息

①检查操作系统的内核版本，所有存储节点之间版本应该一致

# dcli -g ~/cells_group -l root 'uname -a'

# dcli -g ~/cells_group -l root 'cat /etc/oracle-release'

②检查image版本，所有存储节点版本应该一致

# dcli -g ~/cells_group -l root 'imageinfo'

# dcli -g ~/cells_group -l root 'imagehistory'

③检查硬件设备，所有存储节点版本应该一致

# dcli -g ~/cells_group -l root 'dmidecode -s system-product-name'

④检查cell节点网络配置信息与cell.conf保持一致

# dcli -g ~/cells_group -l root /opt/oracle.cellos/ipconf -verify

2）检查磁盘组属性disk_repair_time及参数asm_power_limit配置

由于升级存储节点时会导致当前升级存储节点离线，不合理的disk_repair_time，asm_power_limit配置在升级时间过长时会导致存储节点或者磁盘被踢出磁盘组。

示例：

$ sqlplus / as sysasm

SQL*Plus: Release 12.1.0.2.0 Production on Thu Mar 23 10:44:54 2017

Connected to:

Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit Production

With the Real Application Clusters and Automatic Storage Management options

col ATTRIBUTE for a30

col VALUE for a20

set lines 222 pages 222

select dg.name as diskgroup, a.name as attribute, a.value

from v$asm_diskgroup dg, v$asm_attribute a

where dg.group_number=a.group_number

and (a.name like '%repair_time' or a.name = 'compatible.asm');

DISKGROUP ATTRIBUTE VALUE

------------------ ------------------------------ -----------------------------------------------

DATAC1 disk_repair_time 12.0h

DATAC1 failgroup_repair_time 24.0h

DATAC1 compatible.asm 18.0.0.0.0

RECOC1 disk_repair_time 12.0h

RECOC1 failgroup_repair_time 24.0h

RECOC1 compatible.asm 18.0.0.0.0

6 rows selected.

修改disk_repair_time，failgroup_repair_time均为24h：

alter diskgroup DISKGROU_NAME set attribute 'FAILGROUP_REPAIR_TIME'='24h';

alter diskgroup DISKGROU_NAME set attribute 'disk_repair_time '='24h';

修改asm_power_limit参数为32，以加速磁盘组数据rebalance操作，缩短存储节点升级完等待时间。

SQL> alter system set asm_power_limit=32 sid='*';

SQL> show parameter asm_power

检查确认磁盘组当前无rebalance操作。

SQL> select * from gv$asm_operation;

no rows selected

3）检查存储节点的服务及数据库集群状态

# dcli -g ~/cells_group -l root "cellcli -e list cell attributes msstatus,cellsrvstatus,rsstatus"

# dcli -g ~/all_dbs_group -l root "/u01/app/18.0.0.0/grid/bin/crsctl stat res -t "

4）存储节点的image升级

存储节点的升级为循环在线操作，不需要停止集群及oracle数据库，每次升级完成后重复前面的动作升级另一个存储节点，直至所有存储节点升级完成。

首先，在计算节点1上解压安装介质到/soft/patch/目录（此处不示范），此处解压后的目录为：/soft/patch/patch_19.2.11.0.0.200224 。

①清理之前patchmgr运行后的环境

# cd /soft/patch/patch_19.2.11.0.0.200224

# ./patchmgr -cells ~/cells_group -reset_force

# ./patchmgr -cells ~/cells_group -cleanup

②升级预安装检查

首先检查3台cell的服务均正常。

# dcli -g ~/cells_group -l root "cellcli -e list cell attributes msstatus,cellsrvstatus,rsstatus"

running running running

……

正常情况下每一行都显示为 running running running.

③确保cells_group文件中只有待升级存储节点的信息

# cat ~/cells_group

cell01

④执行升级预检查，预检查没有错误方可进行下一步

# cd /soft/patch/patch_19.2.11.0.0.200224

# ./patchmgr -cells ~/cells_group -patch_check_prereq -rolling

⑤关闭cell节点1的服务

# dcli -g ~/cells_group -l root "cellcli -e alter cell shutdown services all"

⑥检查cell节点1的服务

# dcli -g ~/cells_group -l root "cellcli -e list cell attributes msstatus,cellsrvstatus,rsstatus"

⑦开始升级

# screen

# cd /soft/patch/patch_19.2.11.0.0.200224

# ./patchmgr -cells ~/cells_group -patch -rolling

⑧观察升级日志

less -rf patchmgr.stdout

日志：“SUCCESS: DONE: Finalize patch and check final status on cells.”代表升级动作完成。

⑨升级完检查

# dcli -g cells_group -l root"cellcli -e list griddisk attributes name,asmmodestatus,asmdeactivationoutcome"

检查发现存储节点服务没有启动时，可能需要手工执行命令启动。

启动cellsrv服务

# dcli -g cells_group -l root "cellcli -e alter cell startup services all"

⑩检查确认IMAGE版本

# dcli -g ~/cells_group -l root 'imageinfo'

⑪升级完检查rebalance进度

# su - grid

$ sqlplus / as sysasm

SQL> select * from gv$asm_operation;

no rows selected

$ asmcmd

lsdg (确认无磁盘组需要rebalance)

确保 rebalance完成后方可进行下一步操作。

5）重复以上操作，只需每次更换cells_group文件中记录的cell节点信息即可，直至所有cell节点升级完成。

6）所有cell升级完后处理

清理patchmgr运行后的环境。

# cd /soft/patch/patch_19.2.11.0.0.200224

# ./patchmgr -cells ~/cells_group -cleanup

2、计算节点db image升级

首先到计算节点解压升级工具，此处解压完毕后目录为：/soft/patch/dbserver_patch_19.200224.

①禁用节点1集群自起，并关闭集群

禁止crs自动启动。

# /u01/app/18.0.0.0/grid/bin/crsctl disable crs

关闭集群。

# /u01/app/18.0.0.0/grid/bin/crsctl stop crs -f

停止exawatch。

# /opt/oracle.ExaWatcher/StopExaWatcher.sh

②取消NFS挂载并注释/etc/fstab中的NFS挂载目录

检查1节点nfs挂载的目录。

# umount /nfs_directory

添加“##”注释nfs自动挂载

③计算节点1升级预检测

在计算节点2操作。

cat ~/all_dbs_group

db01

# cd /soft/patch/dbserver_patch_19.200224

# ./patchmgr -dbnodes ~/all_dbs_group -precheck -iso_repo /soft/patch/p30753855_192000_Linux-x86-64.zip -target_version 19.2.11.0.0.200224 -log_dir auto

④计算节点1开始升级

在计算节点2操作。

升级前单独备份一次。

# cd /soft/patch/dbserver_patch_19.200224

./patchmgr -dbnodes ~/all_dbs_group -backup -iso_repo /soft/patch/p30753855_192000_Linux-x86-64.zip -target_version 19.2.11.0.0.200224 -log_dir auto

正式开始升级。

# cd /soft/patch/dbserver_patch_19.200224

# ./patchmgr -dbnodes ~/all_dbs_group -upgrade -nobackup -iso_repo /soft/patch/p30753855_192000_Linux-x86-64.zip -target_version 19.2.11.0.0.200224 -log_dir auto

当操作界面显示以下结果，表示升级完成。

Exadata post install steps completed with success

升级期间，可登入升级节点的ilom观察升级过程是否出现异常

ssh db01-ilom

-> start /SP/console

ESC 然后（退出

计算节点1升级后image检查

# imageinfo

# imagehistory

⑤升级完成后，需开启CRS自动启动，并取消注释nfs自动挂载，并检查集群及数据库状态

# /u01/app/18.0.0.0/grid/bin/crsctl enable crs

# vi /etc/fstab （取消注释）

# /u01/app/18.0.0.0/grid/bin/crsctl stat res -t

$ lsnrctl 检查监听状态

重复上述过程，对剩余计算节点进行升级操作。

最后，启动所有计算节点的Exawatch

# cat ~/all_dbs_group

db01

db02

计算节点1-2 启动ExaWatch

# dcli -g ~/all_dbs_group -l root "/opt/oracle.cellos/vldrun -script oswatcher "

# dcli -g ~/all_dbs_group -l root "ps -ef |grep -i ExaWatcher"

3、InfiniBand版本升级

1）升级预检测

在db01操作：

# cat ibs_group

iba0

ibb0

执行预检测，确保检测成功才能进行下一步升级操作

# cd /soft/patch/patch_19.2.11.0.0.200224

# ./patchmgr -ibswitches ~/ibs_group -upgrade -ibswitch_precheck

2）IB switcher 1开始升级

# cat ~/ibs_group

iba0

升级操作

# screen

# cd /soft/patch/patch_19.2.11.0.0.200224

# ./patchmgr -ibswitches ~/ibs_group -upgrade

提示：显示success表示升级成功，如果有Errors则需要修复后重新执行升级操作

3）检查IB状态

# dcli -g ~/ibs_group -l root showunhealthy

# dcli -g ~/ibs_group -l root version

4）IB switcher 2开始升级

# cat~/ibs_group

ibb0

升级操作

# screen

# cd /soft/patch/patch_19.2.11.0.0.200224

# ./patchmgr -ibswitches ~/ibs_group -upgrade

5）检查IB状态

# dcli -g ~/ibs_group -l root showunhealthy

# dcli -g ~/ibs_group -l root version

至此，exadata软件升级工作就完全完成了，升级完成后可使用exachk对exadata做一次全面性的健康检查。oracle提供的升级工具和升级方法已经十分成熟，升级过程中的大部分工作都可以自动完成，并对升级前的风险，升级工具也会提出预警和建议的处理方法，从而保证升级顺利完成。

EXADATA软件升级初体验

降本的Kubernetes何时成了“成本刺客”？

YouTube如何利用MySQL支撑24.9亿用户？

人肉运维100次后，年底出了P0级故障……

关于国产数据库我不得不说

分库分表，可能真的要退出历史舞台了！