HACMP 5.x 完全手冊,第 4 部分：腳本設(shè)計和經(jīng)驗共享.docx

腳本部分HACMP 的作用在于關(guān)鍵時刻能根據(jù)發(fā)生的情況自動通過預(yù)先制定好的策略進行相應(yīng)的操作，如切換。使得用戶經(jīng)過短暫的中斷即可繼續(xù)使用服務(wù)。而對于用戶來說，“服務(wù)可用”才是 HACMP 切換成功的標(biāo)志，而這一點不光是 HACMP 配置本身，還大大倚賴于啟停腳本的可用性。自 IBM 的 HACMP5205 以后，趨于穩(wěn)定，BUG 很少。這使得 HACMP 切換不成功的主要原因集中在啟停腳本的問題上。而很多時候，腳本的問題是非常隱蔽和難以測試的，所以在編寫啟停腳本時需要考慮周全，系統(tǒng)上線后要仔細維護。通過多年的實踐，我們形成了自己的一套腳本編制方式，共享出來，供大家參考。回頁首腳本規(guī)劃啟停方式對于啟動腳本，完全放在后臺，不影響 HACMP 的切換。對于停止腳本，通過后臺啟動，前臺檢查的方式進行，并使用清理 VG 的進程，確保停止成功。由于啟停是由啟停各個部件啟動組成的，如 host1 的啟停就是啟停 tuxedo 和 xom 軟件組成，host2 的啟停就是有啟動 DB 和 listener 組成。我們把主機的啟動分割為多個部分，這樣綜合寫出共性的公用腳本程序，這樣雖然第一次編寫測試這些公用程序會花費大量的時間和精力，但最終將大大減輕管理員的重復(fù)工作，簡化了腳本的編寫，保證了腳本的質(zhì)量。文件存放目錄表目錄用途舉例/usr/sbin/cluster/app存放 HA 啟停腳本/usr/sbin/cluster/app/log存放啟停應(yīng)用的詳細 log/home/scripts/hostname存放應(yīng)用啟停腳本/home/scripts/host1/tmp存放啟停應(yīng)用的 log/tmp/ha_app.out文件命名表：以主機名為特征進行命名，這樣比較方便使用和區(qū)分。腳本命名規(guī)則舉例HA 啟動腳本start_hostnamestart_host1應(yīng)用啟動腳本start_hostname_appstart_host1_appHA 停止腳本stop_hostnamestop_host2應(yīng)用停止腳本stop_hostname_appstop_host2_app啟停應(yīng)用 log/tmp/ha_app.out啟動應(yīng)用詳細 logstart_hostname_appyyyymmddHHMMlogstart_host1_app200712241722.log停止應(yīng)用詳細 logstop_hostname_appyyyymmddHHMMlogstop_host1_app200712241722.log啟停跟蹤為了便于跟蹤和閱讀，應(yīng)用的啟停 log 不寫入 /tmp/hacmp.out，而是另行輸出到單獨的 log。一般情況下，管理員只需跟蹤 /tmp/ha_app.out 即可，一直等不到結(jié)束，再查看 /usr/sbin/cluster/app/log 下詳細 log。host2root/tail -f /tmp/ha_app.out!Starting- host2 at Tue Dec 18 11:17:51 BEIST 2007Waiting- DB testdb - start,Press any key to cancel.DB testdb is started!Waiting- listener testdb - start,Press any key to cancel. testdb - LISTENER is started!Waiting- listener testdb port 1521- start,Press any key to cancel.LISTENER testdb port 1521 is listening!start eai1d1 successful! at Tue Dec 18 11:20:43 BEIST 2007!host2root/cd /usr/sbin/cluster/apphost2root/more start_host2_app200712181117.log!Starting- eai1d1 at Mon Dec 24 16:06:35 BEIST 2007Mon Dec 24 16:06:35 BEIST 2007Waiting- DB eaiz1dev - start,Press any key to cancel.SQL*Plus: Release 10.2.0.2.0 - Production on Mon Dec 24 16:06:35 2007Copyright (c) 1982, 2005, Oracle. All Rights Reserved.Connected to an idle instance.SQL ORACLE instance started.Total System Global Area 1543503872 bytesFixed Size 2071488 bytesVariable Size 369099840 bytesDatabase Buffers 1157627904 bytesRedo Buffers 14704640 bytes.Database mounted.Database opened.SQL Disconnected from Oracle Database 10g Enterprise Edition Release 10.2.0.2.0 - 64bit Production編寫注意事項：值得注意的是，經(jīng)過測試和實際使用發(fā)現(xiàn)，由 HA 啟動腳本時，如有嵌套，相對目錄執(zhí)行程序?qū)⒉荒苌В仨殞懗山^對路徑。如下面的情況將導(dǎo)致錯誤：start_host1: nohup /home/scripts/host1/start_host1_app &start_host1_app: /home/scripts/comm/start_db.sh orarun testdb 1521start_db.sh: cd /home/scripts/commcheck_db_main.sh testdbcheck_db_main.sh not found需要改寫為start_db.sh: /home/scripts/comm/check_db_main.sh testdb回頁首啟動腳本由于 HACMP 的啟動和應(yīng)用的啟動可以分開，為避免應(yīng)用腳本的啟動不正常導(dǎo)致 HACMP 的報錯，建議將 HACMP 的啟動腳本簡化，將啟動應(yīng)用的部分放在另一個應(yīng)用啟動腳本里。基于規(guī)劃，start_host2_app 的啟動腳本使用了公用程序 start_db.sh 和 wait_db_start.sh，源代碼如下，供大家參考：start_db.sh代碼：#start_db.sh oracle_sid listener_nameORACLE_SID=$1sqlplus / as sysdba $SCRIPTS_PATH/$HA_LOGnohup /home/scripts/comm/tail_log.sh start_app $SCRIPTS_PATH/$HA_LOG !|started!|Waiting-|listening!|starting-|successful! successful! /tmp/ha_app.out &sleep 1nohup /home/scripts/$MACHINE/start_$MACHINE_app ha $HA_LOG &exit 0回頁首停止腳本由于必須保證應(yīng)用正常停止，才切換過去，所以停止腳本的正常結(jié)束才是 HACMP 停止應(yīng)用服務(wù)器成功的標(biāo)志。停止腳本需要設(shè)定一個等待時間的閥值，超過這個閥值，將進行異常中止腳本的運行。此外，為了防止停止時出現(xiàn)停不下來的現(xiàn)象，導(dǎo)致 HACMP 超時報 too long 廣播，需要注意以下停止腳本的編寫：1. 停止數(shù)據(jù)庫腳本停止數(shù)據(jù)庫之前，必須記得先清理掉遠程連接的用戶，這樣才能保證數(shù)據(jù)庫能在可預(yù)測的時間內(nèi)正常停止。如 oracle 數(shù)據(jù)庫停止之前，建議增加以下代碼：ps -ef|grep ora|grep $ORACLE_SID|grep LOCAL=NO|awk print kill -9 $2|sh如果數(shù)據(jù)庫超過一段時間仍停不下來，必須啟動異常停止腳本。2. 最后加上清理文件系統(tǒng)的腳本這一點很容易被忽略，因為有時即使應(yīng)用正常停止，以下原因都可能導(dǎo)致導(dǎo)致 HACMP 不能 umount 這個文件系統(tǒng) :o 有用戶登錄在該文件系統(tǒng)下；o 有其他程序使用了該文件系統(tǒng)下的庫文件；o 該文件系統(tǒng)與應(yīng)用無關(guān)，但正在被使用。結(jié)果均會最終導(dǎo)致 HACMP 停止不了該節(jié)點，切換失敗?；谶@個原因，我們編寫了 kill_vg_user.sh, 使用起來非常方便有效，都放在 /home/scripts/comm 下。現(xiàn)提供源代碼，供大家使用和指正。kill_vg_user.sh代碼 :#kill_vg_user.sh vg_name#kill_vg_user.sh erpapp_vgif $# -le 0 ;then echo no para, example:kill_vg_user.sh erpapp_vg exitfi#mainSCRIPTS_PATH=dirname $0df -k|awk print $7 |grep -v Mounted /tmp/fs_mounted.txtfor i in lsvg -l $1 |grep -vE N/A|vg|MOUNT|awk print $7do if grep -c $i /tmp/fs_mounted.txt -ge 1 ; then echo kill_fs_user.sh $i $SCRIPTS_PATH/kill_fs_user.sh $ifi done調(diào)用的kill_fs_user.sh代碼 :#kill_fs.sh fs_name#kill_fs.sh /oracleif df -k|grep $1|grep -v grep|awk print $7|grep -v 0-9a-zA-Z$1|grep -v $10-9a-zA-Z_-|wc -l -eq 1 ;then fuser -kcux $1fi實際使用stop_host1代碼：MACHINE=host1VGNAME=host1vgHA_LOG=log/stop_$MACHINE_appdate +%C%y%m%d%H%M.logSCRIPTS_PATH=dirname $0if $SCRIPTS_PATH = . ;then SCRIPTS_PATH=pwdficd $SCRIPTS_PATH$HA_LOG /home/scripts/comm/tail_log.sh stop_app $SCRIPTS_PATH/$HA_LOG !|stopped!|Waiting-|stopping-|successful! successful! /tmp/ha_app.out &sleep 1/home/scripts/$MACHINE/stop_$MACHINE_app ha $HA_LOG 2 &1#stop_host1/home/scripts/comm/kill_vg_user.sh $VGNAMEexit 0回頁首同步 HA 的腳本由于 HA 切換后，切換的時間有可能超過一天，而切換時很可能另一臺機器已無法開啟，不能拿到最新的 crontab 和后臺相關(guān)腳本，所以 crontab 和腳本最好能每天自動同步。編寫 sync_HA.sh在 host1 上編寫 sync_HA.sh的代碼：OMACHINE=host2rsh $OMACHINE cd /home/scripts;tar -cvf $OMACHINE_scripts.tar $OMACHINErcp $OMACHINE:/home/scripts/$OMACHINE_scripts.tar /home/scriptscd /home/scriptsrm -rf $OMACHINEtar -xvf $OMACHINE_scripts.tarrcp $OMACHINE:/var/spool/cron/crontabs/root /home/scripts/$OMACHINE/crontab_$OMACHINE 修改 Crontab 生效#sync crontab 0 0 * * * /home/script/sync_HA.sh /tmp/sync_HA.log 2&1同樣在 host2 上編寫，但注意 OMACHINE 修改為 host1?；仨撌捉?jīng)驗共享回頁首異常情況的人工干預(yù)本文沒有詳細描述 HACMP 異常情況的處理，這是因為每個系統(tǒng)每次異常可能情況都不一樣，而且一般來說，安裝 HACMP 的系統(tǒng)都是核心系統(tǒng)，給你留的時間會非常短，快速處理的要求更嚴格。所以，我們試圖找到一個辦法，來應(yīng)對 HACMP 本身異常 99% 的異常情況，而對于腳本和系統(tǒng)參數(shù)的不匹配，只能通過找出問題所在來處理。場景 1：host1 出現(xiàn)問題，但 HACMP 沒有切換成功，處于僵死狀態(tài)1. 快速強制停止 host1 機器運行host1:halt -q2. 確保應(yīng)用服務(wù)繼續(xù)在 host2 上使用手工啟動 host1_RG，smitty hacmp-System Management (C-SPOC)- HACMP Resource Group and Application Management -Bring a Resource Group Online選擇 host1_RG,host2 Bring a Resource Group OnlineType or select values in entry fields.Press Enter AFTER making all desired changes. Entry Fields Resource Group to Bring Online host1_RGNode on Which to Bring Resource Group Online host2即在 host2 上啟動 host1 的資源組。3. 檢查和確認應(yīng)用已可以訪問。如發(fā)現(xiàn)仍然不正常，請參考場景 2 的第 3 步。4. 檢查和修正問題。o host2: 強制停止 HACMP；o 重新啟動 host1，確認無硬件問題；o 檢查 HACMP 的環(huán)境，閱讀 /tmp/hacmp.out 等 log，看看能否找出問題所在；o 修正 HACMP 或其它部分o 確認無誤申請短暫停機時間，重起 HACMP 回原。場景 2：host1 出現(xiàn)問題，HACMP 切換過來，但處于僵死狀態(tài)由于此場景的起因有很多，3，4 點只能根據(jù)具體系統(tǒng)來細化，但還是強烈建議每個系統(tǒng)編制一份手工切換手冊，詳細列明 HACMP 不可用的情況下如何手工啟動應(yīng)用，以備緊急情況使用。1. 停止 host1 機器運行host1:halt -q2. host2 強制停止 HACMP3. 檢查和修正目前狀況HACMP 異常情況修正表序號目前狀況目前狀況修正備注1服務(wù) IP 地址無smitty tcpip 手工添加2vg 狀況未 varyonvaryonvg 手工執(zhí)行如果鎖住加 varyonvg -bu3fs 狀況未 mountmount 手工執(zhí)行如損壞，執(zhí)行 fsck -y4應(yīng)用程序狀況執(zhí)行異常強制停止，重起確認 1-3 ok 再做4. 手工修正目前狀況5. 檢查和修正問題a. 重新啟動 host1，確認無硬件問題；b. 檢查 HACMP 的環(huán)境，閱讀 /tmp/hacmp.out 等 log，看看能否找出問題所在；c. 修正 HACMP 或其它部分；d. 確認無誤申請短暫停機時間，重起 HACMP 回原。回頁首其它有用的經(jīng)驗HACMP 自動啟動的實現(xiàn)有的系統(tǒng)，希望開機就把 HACMP 自動啟動，也就不需要人工干預(yù)就啟動了應(yīng)用，這需要 clstart 時指明 :host1root/smitty clstart Start Cluster Services* Start now, on system restart or both restart Start Cluster Services on these nodes host1 BROADCAST message at startup? true Startup Cluster Information Daemon? false Reacquire resources after forced down ? false這樣，HACMP 會自動才 /etc/initab 里增加以下一行hacmp6000:2:wait:/usr/es/sbin/cluster/etc/rc.cluster -boot -b # Bring up ClusterStop Cluster Services這樣就實現(xiàn)了自動啟動 HACMP 和應(yīng)用。如果希望取消這種設(shè)定，需要運行 clstop:host1root/smitty clstopStop Cluster Services* Stop now, on system restart or both restart Stop Cluster Services on these nodes bgbcb04 BROADCAST cluster shutdown? true* Shutdown mode graceful可以看到 /etc/initab 里這一行消失了。HACMP 的 too long 報警廣播的修正在有些系統(tǒng)運行很長時間的情況下，有可能停止的時間會超出我們預(yù)期，如 oracle 數(shù)據(jù)庫的某些資源被交換到 Pagespace 里。缺省如果超過 180s，就會廣播報警，直至 HACMP 異常。這時你可以修正這個參數(shù)，以避免廣播出現(xiàn)。smitty hacmp-Extended Configuration -Extended Event Configuration -Change/Show Time Until Warning Max. Event-only Duration (in seconds) 360 Max. Resource Group Processing Time (in seconds) 360 Total time to process a Resource Group event 12 minutes and 0 seconds before a warning is displayed NOTE: Changes made to this panel must be propagated to the other nodes by Verifying and Synchronizing the cluster同樣，修改后需要 HACMP 同步。HACMP 的 DMS 問題的修正DMS（deadman switch) 是用來描述系統(tǒng) kernel extension 用的，它可以在系統(tǒng)崩潰前關(guān)閉系統(tǒng)，并產(chǎn)生 dump 文件，以供日后檢查使用。DMS 存在的目的是為了保護共享外置硬盤及數(shù)據(jù)，當(dāng)系統(tǒng)掛起時間長過一定限制時間時，DMS 會自動關(guān)閉該系統(tǒng)，由 HACMP 的備份節(jié)點接管系統(tǒng)，以保護數(shù)據(jù)和業(yè)務(wù)的正常進行，避免潛在的問題，特別是外置磁盤陣列。errpt 確認 DMS 的發(fā)生：LABEL: KERNEL_PANICIDENTIFIER: 225E3B63Date/Time: Thu Apr 25 21:26:16 Sequence Number: 609 Machine Id: 0040613A4C00 Node Id: localhostClass: SType: TEMPResource Name: PANICDescrptionSOFTWARE PROGRAM ABNORMALLY TERMINATEDRecommended Actions PERFORM PROBLEM DETERMINATION PROCEDURES Detail DataASSERT STRING PANIC STRINGDMS 起作用的原因主要有以下幾點： 某種應(yīng)用程序的優(yōu)先級大于 clstrmgr deamon , 導(dǎo)致 clstrmgr 無法正常重置 DMS 計數(shù)器； 在系統(tǒng)上存在大量 I/O 操作，導(dǎo)致 CPU 沒有時間相應(yīng) clstrmgr deamon； 內(nèi)存泄漏或溢出問題； 大量的系統(tǒng)錯誤日志活動。換句話說，當(dāng)以上情況出現(xiàn)時，HACMP 認為系統(tǒng)崩潰，會自動切換到另一臺節(jié)點機上去，這是我們想要的結(jié)果嗎？一般情況下，原有的缺省設(shè)置無需更改。但由于系統(tǒng)運行了較長時間后，負荷可突破原有設(shè)計（平均小于 45%），而且某些情況下會持續(xù) 100%，我們就不希望發(fā)生切換。如果發(fā)生了 DMS 造成的切換，我們先延長 HACMP 的確認的時間，即調(diào)整心跳線的診斷頻率：smitty hacmp-Extended Topology Configuration -Configure HACMP Network Modules - Change a Network Module using Predefined Values 選擇r232* Network Module Name rs232 Description RS232 Serial Protocol Failure Detection Rate Slow NOTE: Changes made to this panel must be propagated to the other nodes by Verifying and Synchronizing the cluster同樣，記得同步 HACMP。如果還是發(fā)生 DMS 導(dǎo)致的 HACMP 切換，排除異常后，只好禁用 DMS 了，這點 IBM 不推薦，因為有可能造成切換時數(shù)據(jù)丟失或損壞。修改 rc.cluster 文件增加 -D 參數(shù)：host1root/ vi /usr/es/sbin/cluster/etc/rc.cluster if $VERBOSE