如何升级Exadata 存储节点cell image

原文链接: http://www.dbaleet.org/how_to_upgrade_cell_image_of_exadata/

Exadata存储节点,即我们常说的cell节点,在Exadata中承担着双重作用:

一是提供存储的介质,所有的非二进制文件都存在在此;
二是提供大量的offloading的任务,计算节点(db 节点)通过smart scan等,把一部分任务“下沉”分布到cell节点。

而升级cell的image中主要是升级以下内容:

操作系统的信息:包括一些基本的rpm包,操作系统内核,
固件类信息:例如磁盘控制器的固件,ILOM的固件等;
驱动类信息:依赖于内核版本的infiniband驱动ofa;

升级Exadata的cell的image可以使用在线的方式进行也可以使用离线的方式进行,在线升级的好处是无需停止数据库服务,但是通常单个cell节点image升级的时间接近三个小时,如果一台满配的Exadata,升级完所有cell的image所需要花费的时间为14×3=52个小时,这还不包括检查,如果出现意外情况的troubleshooting的时间。实际上在线升级完一台满配的Exadata的cell image一般需要花费60个小时。另外就是在线升级的过程中,其它节点如果发生坏盘,那么就有可能会造成数据的丢失。为什么呢?因为在升级某一台cell的image的时候,并不做rebalance的动作,升级这个过程中,这台cell的所有盘都相当于是offline状态的,这台cell中所有盘中保存的信息,在其它所有cell节点有且仅有一份镜像。(这里说的是正常冗余的情况,如果是高冗余,则为两份)。如果这个时候其它cell中有一块盘发生了不测,则就有可能丢失数据,因为等这个cell的image升级完成以后,会自动同步Exadata的元数据和其它对应镜像的修改后的信息,如果坏的盘恰好是“某一块”,则悲剧就诞生了。当然,你也可以使用离线的方式进行升级。离线需要停止db节点上的集群和cell节点上所有节点的celld服务。但是它的好处在于,可以进行并行地进行cell image的升级,例如可以一次性的升级完所有的cell节点的image,时间也是接近三个小时。不管是四分之一配,半配,还是满配,通通只要三个小时。但是同样也存在风险,例如如果多台cell被刷坏了,操作系统起不来,这样也是比较危险的,但是这种情况相比坏盘概率小很多,可以说几乎和中彩票头奖的概率差不多,如果你不幸遇到这样的情况,请记得下次帮我去买张彩票。

在线升级cell的image往往需要较长的时间进行详细的规划,防止各种突发故障,这个并非三五百字可以讲完,所以我这里只写出离线升级cell image的方法:以下是为某客户Exadata cell image从11.2.2.4.2升级到11.2.3.2.1的全部过程:

升级前的准备工作

1.准备cell image的patch:

下载cell image的patch,patch号为14522699。使用root用户上传到eccel01节点的/opt/oracle.SupportTools/目录下。如果是使用ftp上传,需要注意使用二进制bin模式。

使用以下命令进行解压:

#unzip p14522699_112321_Linux-x86-64.zip

使用md5sum对解压后的文件进行md5码校验,以下五个文件的md5码应该为:

3a8f090e9410c80b0b3a27026472cd0 patch_11.2.3.2.1.130109/11.2.3.2.1.130109.iso
69d3bf2dfc6f650bd9f4f2413b084ae2 patch_11.2.3.2.1.130109/11.2.3.2.1.130109.patch.tar
f2d7a739d9b813f3ed1c38f25678b603 patch_11.2.3.2.1.130109/dcli
0a327e437d81be782e4765263cb61b22 patch_11.2.3.2.1.130109/dostep.sh
8ea5f9270dbaa1f6c8a94630ad150a58 patch_11.2.3.2.1.130109/patchmgr

如果不正确,则需要重新上传解压。

2.准备cell_group文件

检查/opt/oracle.SupportTools/onecomman/cell_group文件中的内容是否为:

dm01cel01
dm01cel02
dm01cel03

以上以实际的cell主机名代替。

3. 检查所有节点的cell.conf文件是否一致:

#/opt/oracle.cellos/ipconf -verify

4. 检查ssh是否支持patchmgr:

打开ssh的debug模式

#ssh -v -v ecdb02>ssh_client_debuglog.txt

按照提示输入密码

5. 配置SSH加密算法:

运行以下命令列举出当前SSH加密的算法

#ssh -v -v ecdb02>ssh_client_debuglog.txt
#sed -e '/SSH2_MSG_KEXINIT received/,/first_kex_follows/!d' \
ssh_client_debuglog.txt | grep \
'aes128-ctr\|aes192-ctr\|aes256-ctr\|arcfour'

返回结果不能为空,如果为空,表示当前ssh不支持必需的加密算法。那么在/etc/ssh/ssh_config加入这么一行

Ciphers aes128-ctr,aes192-ctr,aes256-ctr,arcfour

6. 建立SSH连通性:

使用如下命令验证,节点之间root的ssh连通性已经建立:

#dcli -g cell_group -l root 'hostname -i'

如果提示需要输入密码,则可以使用如下方式建立ssh的等效性:

先生成本机的密钥:

#ssh-keygen -t rsa

输入回车保持默认,这样会创建root用户的rsa密钥

使用如下命令将这个密钥推送到cell节点:

#dcli -g cell_group -l root -k

这个过程需要输入其它cell节点的密码。

7. 修改disk_repair_time:

修改 disk_repair_time到一个更长的时间,防止在升级的期间离线的节点的griddisk被强制drop。

SQL> select dg.name,a.value from v$asm_diskgroup dg, v$asm_attribute a \
where dg.group_number=a.group_number and a.name='disk_repair_time';

将其修改到一个较大的时间:

SQL> alter diskgroup diskgroup_name set attribute 'disk_repair_time'='36h';

这里diskgroup_name用实际的磁盘组的名称代替,同时需要对所有的磁盘组的disk_repair_time的属性进行修改

 

8. 检查所有griddisk的状态

确认所有的griddisk的状态为online。

#dcli -g /opt/oracle.SupportTools/onecommand/cell_group -l root cellcli -e 'list griddisk attributes name,asmmodestatus'

升级过程

1. 停止所有DB节点的crs:

dcli -g dbs_group -l root "/u01/app/11.2.0/grid/bin/crsctl stop crs -f"

完成以后使用如下方式进行验证:

dcli -g dbs_group -l root "ps -ef | grep grid"

 

2. 关闭所有的cell服务器上的cellsrv:

dcli -g cell_group -l root "cellcli -e alter cell shutdown services all"

3. 进入目录patch目录:

cd /opt/oracle.SupportTools/ patch_11.2.3.2.1.130109

4. 对之前使用patchmgr升级的残留信息进行清理:

#./patchmgr -cells /opt/oracle.SupportTools/onecommand/cell_group –cleanup

执行下面的检查命令,检查存储节点是否满足升级需求:

# ./patchmgr -cells . /opt/oracle.SupportTools/onecommand/cell_group -patch_check_prereq

5. 检查没有问题,运行下面的命令升级存储节点的image版本:

# ./patchmgr -cells /opt/oracle.SupportTools/onecommand/cell_group -patch

6. 在db01节点使用ilom对升级的进度进行监控整个过程:

使用cell的ilom地址登录,然后启动串口:

start /SP/console

如果需要停止,则先按住esc,然后输入:

stop /SP/console

注意升级的过程中会有多次ilom的中断,属于正常的情况。

 

升级后验证工作

1. 确认所有的cell都已经升级到11.2.3.1:

#dcli -g cell_group -l root 'imagehistory'

2. 确认kernel已经升级:

# dcli -g cell_group -l root “rpm -qa | grep kernel”

3. 确认ofa的版本已经升级:

#dcli -g cell_group -l root “rpm -qa | grep ofa”

4. 升级完成以后再一次进行清理:

#./patchmgr -cells /opt/oracle.SupportTools/onecommand/cell_group –cleanup

5. 取消ssh的信任关系(可选):

# dcli -g cell_group -l root --unkey

6. 启动CRS和数据库服务器上的其它所有agent:

# crsctl start cluster -all

6. 修改disk_repaire_time:

SQL> alter diskgroup diskgroup_name set attribute 'disk_repair_time'='3.6h';

以上

Comment

*

沪ICP备14014813号

沪公网安备 31010802001379号