Exadata 存儲節點cell image

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. 停止所有ＤＢ節點的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"

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';

1ihj2015

發佈了133 篇原創文章 · 獲贊 1 · 訪問量 19萬+

私信關注