Exadata 存储节点cell image升级

https://blog.csdn.net/itdba/article/details/43969075?utm_medium=distribute.pc_relevant_t0.none-task-blog-BlogCommendFromMachineLearnPai2-1.nonecase&depth_1-utm_source=distribute.pc_relevant_t0.none-task-blog-BlogCommendFromMachineLearnPai2-1.nonecase

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$as{m}_{d}iskgroupdg,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. 停止所有ＤＢ节点的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’;