Exadata升级方案制定

作者简介

石云华,现就职于北京海天起点,oracle技术二线专家成员,Exadata部门负责人。拥有十余年电信、保险、税务行业核心系统ORACLE数据库运维经验,持有11gOCM、Exadata、Goldengate等证书。擅长于oracle/goldengate/exadata方面的故障诊断及疑难问题处理。

我们知道Exadata中包括的组件非常多,但真正可能会影响到数据库正常运行或业务系统正常运行的组件主要包括计算节点、存储节点 和 Infiniband交换机。所以在后期的运维过程中,我们主要只会考虑计算节点、存储节点 和 Infiniband交换机这三个组件的软件版本升级。

滚动升级与非滚动升级

选择”滚动升级”,还是选择”非滚动升级”主要是由两大因素决定的:1、业务的停机时间;2、系统的重要性。

下面,我们来了解各自的运行原理及各自的优缺点。

非滚动升级

如下图1.1所示,为存储节点”非滚动升级”的示意图。停止Exadata上所有计算节点的数据库和GI集群服务,关闭所有存储节点的CELLSRV服务,以root用户在计算节点上发起patchmgr工具,并行地同时升级所有的存储节点上的软件。

图1.1非滚动升级

非滚动升级的优缺点:

优点:

(1)、执行一次,所有节点都会升级。

(2)、整个升级过程花费的时间相对较短。

缺点:

(1)、业务需要中断的时间较长。

(2)、升级风险最大。

滚动升级

如下图1.2所示,为存储节点”滚动升级”的示意图。当所有的存储节点准备就绪,会串行地一台一台地升级存储节点上的软件。在升级每一台存储节点时,会先将该存储节点上的griddisk offline, 打完patch后,再将该存储节点上的griddisk online操作。

图1.2 滚动升级

滚动升级的优缺点:

优点:

(1)、执行一次,所有节点都会升级。

(2)、升级风险较小。

(3)、无需停业务或最短的业务停止时间。

缺点:

(1)、整个升级过程花费的时间相对较长,且不可预知,主要取决于打完patch后数据同步的时间。

串行式非滚动升级

如下图1.3所示,为存储节点”串行式非滚动升级”的示意图。停止Exadata上所有计算节点的数据库和GI集群服务,关闭所有存储节点的CELLSRV服务,以root用户在计算节点上发起patchmgr工具,串行地升级所有的存储节点上的软件。

注意:

非滚动升级时,每次升级的节点个数是由配置文件决定的,默认是将所有的节点都写入配置文件,而串行式非滚动升级时,每次只升级一个节点,节点升级成功后,再修改配置文件,升级下一台节点,反复以上步骤,直到所有节点升级完成。

图1.3 串行式非滚动升级

串行式非滚动升级的优缺点:

优点:

(1)、升级风险最小。

缺点:

(1)、整个升级过程花费的时间相对较长。

(2)、业务停止时间太长。

(3)、需要多次修改配置文件,并多次执行。

收集信息

在制定详细的升级方案之前,我们必须先收集一些相关的信息,然后根据收集的这些信息来制定最终的升级方案。这些信息主要包括以下几点:

(1).升级目标。

(2).升级前和升级后的软件版本。

(3).允许的业务中断时间。

(4).patch自带的readme文档。

(5).patch对应的概要文档。

(6).GI 和DB 当前的版本和补丁信息。

(7).数据库是否有容灾和备份。

下面,我来一一解释以上几点信息在升级方案制定过程中的重要性。

(1)、升级目标:

也即客户最终是需要升级Exadata中的哪个组件,是存储软件的版本?数据库版本?infiniband交换机软件的版本?还是所有的组件都要进行升级?

有时,客户仅仅是为了解决数据库运行中所遭遇的一些BUG,这时,我们只需要单独升级数据库的BP补丁就可以解决问题,但有些问题,可能需要数据库的patchset。例如:从11.2.0.3版本升级到11.2.0.4版本。

有时,客户仅仅是为了解决存储软件中的一些BUG。例如:曾经遇到过的一个案例,其中一台infiniband交换机hang死,但另外一台infiniband交换机软件无法接管工作,最终SR确认是infiniband交换机的bug,需要将infiniband交换机软件版本升级至2.1.6-2及以上版本才能解决。像这种情况,我们则只考虑升级存储软件版本和infiniband交换机软件版本。

(2)、升级前和升级后的软件版本:

升级前和升级后的软件版本基于上就决定了升级路线和升级工具的选择。例如:计算节点升级,有bootstrap.sh工具,也有dbnodeupdate.sh工具;infiniband交换机升级,有spsh工具,有patchmgr工具。不同的版本,对应的升级工具也不尽相同。升级前和升级后的软件版本的选择,直接决定了升级方案中的命令细节部分。

软件升级时,该选择什么样的软件版本?对于这个问题,其实无法统一而论。如果是遭遇某个BUG而选择升级的情况,这种情况比较明确,升级到BUG被修复的版本即可;但如果是软件的周期性升级,应该升级到什么版本呢?这种情况是比较难以回答的,也没有个固定的答案。

个人建议:

存储软件版本升级到较新的版本比较合适。这主要基于两点:(1).因为新的存储软件版本解决了硬件固件中的一些BUG,越是新的版本,BUG相对越少。(2).新的存储软件版本带来的一些新特性更利于上面运行的数据库更高效地运行。

(3)、允许的业务中断时间:

申请的业务中断时间就直接决定了整个升级方案是选择”滚动升级”,还是”非滚动升级”。

如果申请的业务中断时间非常短或不允许业务中断的情况,则基本上就决定了只能选择”滚动升级”。

如果申请的业务中断时间足够长,例如:十一假期、 春节假期,我们则可以选择”非滚动升级”,也可以选择”停机地滚动升级”,所谓”停机地滚动升级”,即停机的情况下,一个节点一个节点地串行升级,而不是常规的停机并行升级(”非滚动升级”)。

如果申请的业务中断时间比较长,但又不足以执行”停机地滚动升级”时,我们可能会选择”滚动升级”和”非滚动升级”的方式。

总之,停止的时间越长,可选择的升级方法也越多样,方案的选择主要是基于数据安全至上的原则。

(4)、patch自带的readme文档:

patch自带的readme文档包括了该具体patch的详细介绍,及详细的安装步骤,有些readme文档中还会记录该patch中修复了哪些BUG等等。

(5)、patch对应的概要文档:

我们知道,计算节点和存储节点的升级包是完全不同的,如下图1.4所示:

存储软件12.1.2.3.3版本所对应的概要文档号为 2181366.1,该patch的概要文档记录了以下几点:

(1)、对数据库软件版本的依赖关系。

(2)、该patch的升级介质和刷机介质。

(3)、该patch对应的存储软件版本当前存在的一些问题及解决办法。

(4)、存储软件从以前的版本升级到当前版本的过程中存在的一些问题及解决办法。


图1.4 patch对应的概要文档

对于升级而言,patch对应的概要文档的第四部分内容非常重要,即存储软件从以前的版本升级到当前版本的过程中存在的一些问题及解决办法。这部分内容直接影响了升级过程中的一些步骤。

例如:下图1.5是从patch (12.1.2.3.3)对应的概要文档中摘取的升级过程中存在的问题。


图1.5 升级过程中存在的问题

从图5.14可以看出,如果打算使用”非滚动升级”的方式来升级存储节点,则在升级的过程中有可能会遇到升级超时的故障。解决办法是在停止数据库和GI集群,正式升级存储软件之前,手动地将存储节点上的griddisk置于inactive状态。

升级过程中,由于存储上述这个故障,故在制定升级方案时,必须在升级前增加一个步骤,手工地将存储节点上的griddisk置于inactive状态。

3、运行exachk

在进行Exadata组件升级之前,强烈建议先收集一次exachk报告。主要关注exachk报告中两大部分内容。

关注一:

如下图1.6所示,将exachk报告中状态为”FAIL”或”WARNING”的部分全部仔细检查一遍,由其需要关注是否出现了硬件层面的故障。在升级之前,务必解决掉所有的硬件问题。


图1.6 exachk报告中状态为”FAIL”或”WARNING”的部分

关注二:

如下图1.7所示,查看exachk报告中的”Maximum Availability Architecture (MAA) Scorecard”部分。这部分记录了当前Exadata环境正经受哪些严重的BUG,同时,也记录了当前的软件版本,并推荐升级至某个具体的版本。


图1.7 exachk报告

“Maximum Availability Architecture (MAA) Scorecard”部分

存储软件版本详解

在计算节点或存储节点运行命令:# imageinfo -ver,可以获取当前存储软件版本。例如下图1.8所示:


图1.8 存储软件版本格式

在绝大部分情况下,知悉存储软件的版本号已经足够,但在制定升级方案时,除了知悉存储软件的版本号,还需要知悉该存储软件版本的日期代码。因为升级前与升级后的软件版本号和日期代码需要满足一定的条件:

1、升级后的软件版本号必须高于升级前的软件版本号。

2、升级后的软件日期代码必须高于升级前的软件日期代码。

例如:升级前的存储软件版本为12.1.1.1.2.150411, 则如果打算将存储软件版本升级到12.1.2.1.2.150617版本是可行的;但如果打算将存储软件版本升级到12.1.2.1.1.150316版本是不允许的。

方案制定

升级模式选择

所谓升级模式的选择,也即是”滚动升级”,还是”非滚动升级”,还是两者相结合的方式。前面收集的信息基本上就可以决定了升级模式。

如果允许的业务停机时间非常短,则就只能进行”滚动升级”;如果允许的业务停机时间非常长,就需要关注业务系统的重要性,如果业务系统的重要性非常高,则建议进行”滚动升级”;如果业务系统的重要性不高或是测试系统,则建议进行”非滚动升级”。

组件升级顺序

就”滚动升级”而言,各组件间的升级前后顺序没有特别的要求,计算节点可先于存储节点升级,同样,存储节点也可先于计算节点升级。

如下图1.9所示,先升级的计算节点,再升级的存储节点,最后升级的Infiniband交换机。

图1.9 升级顺序之一

就”非滚动升级”而言,推荐的升级顺序为:

(1). 存储节点

(2). Infiniband交换机

(3). 计算节点

因为这种升级顺序避免了再次关闭和启动GI和数据库,节省了整个停机时间。注意:这仅仅是推荐的升级顺序,并不是一定强制要求执照这样的顺序来进行升级。

未经允许不得转载:Oracle一体机用户组 » Exadata升级方案制定

相关推荐