2010年8月27日 星期五

第十六回 個人經驗:幾家 Storage 遇過最常見的幾個問題,以EMC 和 IBM 為例

EMC 這家儲存設備廠商所製造的各個型號的 Storage ,在效能和穩定度上的水準一直是不錯的,平台支援度也挺完整的,不過就我常遇到的 CX 等級的機器,其實是有一些問題存在,不過這些問題其實也是個瑕不掩瑜的問題。

首先無論在哪個 Storage 平台都一樣,在安裝之前,請務必參考該 Storage 提供的 Checklist 仔細核對你要使用的平台的作業系統版本及對應的 MultiPath 驅動程式的版本和必須安裝的 Patch 及平台配合需調整的參數,才能在使用時,將問題降到最低。

狀況一:Storage 陷入不明的 Busy 狀態,造成 CPU Load 增加,因為全部都在 I/O Wait 狀態,Application Hang 住,之前就是平台驗證未做好,相對的參數也沒對應好,有過到類似的狀況。後來將 Patch Level 更新後,就沒發生過類似狀況。

另外第二點,既然是 Multipath 的狀態下,請注意你的路徑安裝的方式及 Storage 提供的 MultiPath 使用方式,EMC 的 CLARiiON 及 Symmetrix 的 MultiPath 使用方法是不太一樣的,就如同 IBM 在 DS4 和 DS8 的 MultiPath 亦是不同,所以在 Zoning 和接線方式是要注意的,以免你的 Path 亂掉造成 Storage Controller 誤判而將控制權自行更動。

狀況二:在 IBM DS4 系列曾遇到安裝的工程師在調整 SAN Switch 設定時,接光纖線接錯,造成某張光纖卡故障時,Controller 誤判一直在做切換動作,剛好所屬的 LUN 是在 Cluster 架構下,使得所有同時 Access 到該組 LUN 的 Server 的路徑一起也被切換,使得 I/O 一直不停的 Busy 。因為為了處理這個問題我曾不小心將某全球雙 A 品牌之一的 Mail Server 關閉了半個小時後才回復。

狀況三:在 EMC CX 比較常見,在Disk 被Access 的狀態下,如果突然所有線路直接被拔除,不是瞬斷馬上恢復那種,是真的實體線路連接斷線時,CX 的 Powerpath 下所屬的那個 Path 的 Disk 有非常大的機會會被 Controller Lock 住,此時會有一種狀況,該 Disk 就算線路己經連接回來,你仍然無法使用該 Disk ,有時在 Navigator 下面就可以看到該磁碟的狀況是有些異常的,通常將該 Disk Unassign 再 Assign 後會回復正常,但少數狀況可能需要將目地端主機設備重開,這個問題我在 AIX 上面連接 EMC CX 時經常遇到。

CLARiiON系列的MetaLun在很多場合真的是非常好的一項特性,尤其是原本就有 LVM 架構下的 AIX ,更是強大,幾乎可以不需花費什麼風險就任意的將一個 Disk 放大,不像 DS4 系列號稱可以如此,但是卻是必須要連續空間才有辦法如此使用。

另外 CLARiiON 的前五顆 DISK ,預設是放置 Flare Code OS 用的,這五顆 Disk 內置了整座 CX 的設定及作業系統,系統預設當這五顆 Disk 其中有一顆發生損壞時,是非常危急的一件事,預設第一件事就是要通知所有的人,所以當這五顆 Disk 其中有一顆發生損壞時,就會將 Write Cache 關閉,Write Cache 一關閉,所有接續在本座 CX 儲存設備的系統主機的效能馬上就會陷入無比的低落。

狀況四:EMC CX 系列的前五顆硬碟,只要損壞其中一顆,預設 Controller 的 Write Cache 就會被關閉,此時在使用這個子儲存系統的主機都會發現效能變差,當然在尚未修復前可以透過設定將 Write Cache 再度啟動,讓系統效能恢復,不過 Flare Code OS 所屬的 Disk 故障務必儘速報修將之修復,以免發生遺憾的事情。

狀況五:非常類似 EMC 狀況三的情形,在其他家 Storage 也是會發生的,在 IBM 過去的 ESS 系列,也就是 SHARK 和 DS8000 上面使用 SDD 時會有類似情形,就是當有個 LUN 原本是屬於某個系統存取時,忽然該系統被關閉,緊急改用另一個作業系統接手,而你又未將 LUN 設定在這兩個作業系統都可存取,僅是後來才變更設定,該 LUN 就會被第一個 Access 的作業系統鎖住。在 DS8000 和 ESS 下的 SDD 有個工具叫 lquerypr 可以將這個 Lock 解除。相對的其他廠商也會有類似的工具可以處理類似的問題。

2010年8月16日 星期一

第十五回 某製造業的 HA 問題

去年底時,有位同事去某製造業 implement HA ,結果一直不順,後來我就過去看,因為狀況真的很怪異。

問題在 HA 設定上都可以順利完成,但在切換演練時會發生兩個問題,一個問題是切換過去後 Application 的 Applet 畫面會出不來,另外一個問題更嚴重,如果我是用 HA 裏的 Move Resource 整個切換過去後,約5~8分鐘的時間,整個系統就會被踢回來。

第一次去看時,我順道帶了一台 Gigabit Ethernet Switch 過去,將網路問題簡單化,只是這兩個問題有時是偶發,有時又不會發生,所以真的很難抓。後來在一次切換成功,等了快半小時以上沒有任何異常的狀態下,我們決定只能先將系統留置在 Standby 端,觀察一個晚上看看。

第二次去看時,發現系統己經自己回到 Master 端在運作,我回去有做了功課,因為做這類 HA 的工作,一開始最好將網路環境的 SPANNING TREE 和 ARP Proxy 關閉,這個原本一開始就跟客戶確認過了,但又再次請教客戶,這些協定有沒有被開啟,但是對口的客戶並不是網管,當天網管也不在公司,無法回答我們。當天又測了好幾次,狀況是一樣的。只好暫時歇兵。

後來不得己請了原廠出馬,看他們在測試的樣子,小弟覺得那個程序確實有值得我學習的地方,但是方法就不說了,老實講,也是亂測一通,把所有可能和不可能的方法都列在白板上,做完失敗就畫掉,交叉分析。其實有些程序在手冊及原理上根本就不存在,這樣也是被列出來測試。最後原廠將整個設定打掉重做,系統忽然就穩定了。因此大家以為從此可以安居樂業了,就快樂的回家。

不過這次穩定的時間確實比較久,大概過了快三天,老現象又發生,後來大家一直在 Review 所有的設定重新檢查,最後客戶發現一件事,為何在 Application 的 Web Server 的設定只有一台主機,此時負責的顧問也注意到了,將兩部主機的設定全加進設定裏後,第一個 Applet 出不來的問題解決了。重覆試了好幾次,都是正常的。但是第二個問題依然是存在,我們又回頭去請教網管,確認是不是不能設的設定有確認過真的沒設。

後來真的確認了,ARP Proxy 被打開了,造成系統切換至 Standby 後我的 ARP Table 不一致,隔沒多久,網路就斷線,然後整個系統就會被踢回 Master 端。

所以在做一些設定時,雖然己經將所需環境及設定告知客戶了,還是得再三確認過才行,這次這個問題,花了快兩週的時間解決。每天許多人都熬到很晚,因為有時又不會發生,根本找不到解釋的原因。所幸 ARP Proxy 關閉了以後,這件事就真的解決了。

2010年8月13日 星期五

聽我在放屁 CASE3 我的證照之路

最近的很多廣告,都是某某電腦在推畢業前考取某某證照之後工作有多好找。或考取某某證照以後在哪上班....對於在 IT 業打滾了很多年之後的我來說,實在也是非常諷剌的事情。

老實說,小弟手上的三張證照,MCSE、OCP、SAP都不是我學生時代去考的,MCSE 2000年時當初找最便宜的教育訓練中心也要二萬多,OCP 要 10 萬,SAP 要 3X萬,一個學生哪來那麼多錢上課,而且還要考試,MCSE 當初7科也要二萬多,OCP 五科,單科好像五仟,SAP Basis 我是不知道,因為是含在教育訓練的費用內的。所以以當初我自己花錢去報 SCJP 時,發現那時暑假期間好多學生跑來上課考證照,一時覺得現在的家長和學生真的很辛苦,這類專業證照的上課動則一、兩萬,有些大學生在畢業後會不會走這行都還不知道,就得讓他來上課,當時最熱門的課程就是 MCSE和CCNA。

而我的這幾張證照都是進了公司後,因為有專案配合,或是公司有政策需要,才去考的,而為何在 2004 年後我就不再去考任何證照了呢? 因為我想在 IT 業打滾,之後除非我是去考 PMP 這類管理性質證照,如果還有在做相同的工作的話,同類型證照只要有當初那張就夠了,至於需不需要每年為了昇級一直在考試,被原廠騙錢。除非是配合政策,但這類配合政策取得的證照有時根本就不重要,如某些硬體廠商或軟體廠商每幾年就會要合作夥伴花錢去考一些證照,要有一定的數量才能有販售產品的資格,或取得某些標案。像這類型的有時我就只是配合著去考,所以我手上也有兩、三張硬體維護工程師的證照,但是有效期只有二年。這種證照對我而言,也沒什麼價值可言,現在是 2010 年,我手上有三張五到八年前的Intel 平台的原廠硬體工程師認證執照,當時的機器是 PIII 架構,請問現在哪家公司會認你這張證照。

就算你很行,在大學畢業之前,你就考取了二、三十張不同領域的證照,前一陣子新聞就常報導這類學生,我只想問一句,你畢業後想做什麼,是逼不得己有什麼工作就做什麼還是依自己的專業、興趣去找工作。而且二、三十張,你專精的領域在哪? 抱歉,應該沒有老闆相信你是什麼都會的。

就我之前有去面試的經驗而言,很抱歉,有些公司跟我說,我們不需要同時會管 Oracle 、AIX 、SAP 、Storage 的人,甚至告訴我,你應該自已先想清楚,你自己要走哪條路,而這些公司,還是國內上市櫃公司排名前一百大的。意思是表示,這些公司他並不需要跳樑小丑,可能也不需要高手,因為再強的高手還是得依賴原廠或合作廠商,也許他們分工非常的細密,只需要懂單一產品的人就可以了。

至於有關 IT 證照取得,現在對岸有太多的資源可取得,就算你不知道門路,網路上還有流傳 Braindump 的試題,只要找幾個想要一起考同類型考試的朋友,在網路上都可以買到題目,花個幾天背一背就能過了。所以有些考試才會有你沒去上相關課程就算考過也不會發給證照這種規定。

基於 Braindump 這種東西其實也有他的價值,必竟花我的錢是錢,花公司的錢也是錢,總不可能光靠唸熟去考試就一定會過吧,而且考一門也不便宜。事先了解考試題目的內容也是不錯,只是這些 Braindump 就真的很強,不知是跟考試中心合作洩題,還是真有人能把題目背下來(不過有些連圖片都有,我就不相信是背下來的),只要在一定時間內,題目命中率可說是 100%。

老實說我的 MCSE 和 OCP 都是透過 Braindump 考上的,當初 MCSE 的唸法就是一週讀一本考題,然後就上場考,不過微軟的題目比較長,我每題都花了時間去唸完並理解,不是只背答案,因為當時的考試經驗也不多,七科就花了七週去考,後來的 OCP 更誇張,當初的教育訓練中心直接提供試題,那五科考試,我看我們平均一科都只需花 20分鐘就可以考完,OCP 就這樣輕輕鬆鬆入手。至於 SAP 我是真的把原廠上課的四本教材每天拿來複習,翻到都快爛掉,抱著心驚膽顫的心情去考,考完仍是沒把握,因為 SAP 的考試比較不一樣,考完要一個月左右才會有結果,不會當場告知你有沒有通過。一直到拿到成績通知那天我才放鬆下來。

整體比較起來,我是覺得微軟題目的變動好像比較多也比較靈活,當初如果只是呆呆的背題目去考,我大概沒辦法順利在七週內通過,OCP 當時就比較死板,題目也很短,當然現在的 OCP 考試我是不知道。

至於我唯一自費上課和考試,而且沒考過的 SCJP ,雖然我也是沒看考題,只有看教材,但是程式設計可能跟我比較不合,我後來只差一題結果沒通過,後來也沒再去考了。我覺得 SCJP 考試的內容有點過份,根本就是把人的腦袋當編譯器和執行緒在考,直接扔段程式,問你哪裏錯,或著是執行的結果是什麼。而且大多數都是廻圈的題目,我考試過程中在腦袋裏不斷的執行那些廻圈轉到頭都暈了。後來就這樣敗下陣來。

而其他跟原廠硬體有關的考試,其實只要大概的唸一下當年度最新的技術手冊和安裝手冊就可以了,反正幾年後這張證照就沒用了。只要通過就可以了。

後來我在工作之餘又跑回去唸大學資管時,因為大部份的大學最流行的就是叫你去考 MCSE ,CCNA,SCJP ,所以很多教授上課時都會 Push 你去考試,尤其是我網路的老師,老是上課就一直 CCNA、CCNA、CCNA,唸到我都煩了,當然我不是說 CCNA 沒有用,是因為我沒有要做網路這塊,我只需要有基本功就好了,再多考張證照只是浪費錢而己。

所以當時那門課在第二學期的學分期末考時,我考完實作了離場時,教授就跟我說:「同學,看你設定很熟喔,要不要去考個 CCNA ?」當時心裏只想反正我都過了期末考,一時忘記直接在全班同學面前凸老師:「不用了,我考那個沒有用。」後來每個同學出來都跟我說,你也講的太大聲了,全班都聽到了,這樣教授很沒面子耶。我才驚覺,對喔,其實我當時只是把心裏的想法說出來,也沒想那麼多,只是聽了兩個學期的CCNA實在很煩,一直在說考取 CCNA ,可以往電信業發展啊,前途有多好啊什麼的。每次上課都在說。感覺好像在上洗腦課程,而且其實我也沒那麼熟,學校考試的內容頂多只是基本的 Route 設定而己。我還是把我工作上該做好的事情搞定就好了。

屁了這麼多,最後下個結論吧,其實現在這個社會大家都很忙,互相不認識,社會新鮮人在初入社會時又沒什麼工作經驗,證照是個快速讓公司對你直接有專業的形象的證明,但以現在大學畢業的工資可能平均在 28000 ~ 32000 之間,你在學期間一次拿到許多張證照只是讓你的實力在面試時被模糊掉了,搞不好還會讓一些公司覺得請不起你。

不如選定一、兩種基本入門又負擔的起,或者是管理類的證照 (個人覺得 PMP 和ITIL 可以去考,但是千萬別在沒什麼實務經驗的狀態下拿這些理論跟你的老闆屁,那就真的太白目了,他打滾了多少年要你來教嗎? ) ,基本上大公司看的可能還是在校成績和社團領導經驗,其他的證照在清楚你要走的路之後再慢慢取得,幾年後累積了一定實力之後,你才會發現,有哪些證照根本就不重要,你累積的工作經驗和你執行專案的結果才是人家要看的東西。

後記:之後我才得到 01 論壇上面網友的更新,PMP 實際上需要實務經驗才能取得,ITIL 目前 V3 版本價錢也是天價,己經跟之前 V2 是完全不一樣的世界了。所以大家還是量力而為,基本上要投資自己,語文能力的訓練一定是不會錯的。

2010年8月10日 星期二

第十四回 200X年 SAP 效能低落的一次經驗....

在 200X 年,因為公司外包了某物流業的 SAP Basis 的工作,我就是當時的 Basis ,當時的 UNIX 主機在我們公司代管,客戶端是透過企業內的 Intranet 連線至我們機房的 SAP 主機,其中有一家關係企業一直在報 Call ,說經常發生 SAP GUI 連線時,整個畫面 Hang 住不動,但又不是當機,只要隔一陣子就會再恢復。這可造成 HR 和 FI 人員不少困擾。

因為其他點的關係企業並沒有類似的問題,而且有問題的這家關係企業跟其他關係企業也處在同一棟大樓內,所以我直接排除是我主機的問題,只能懷疑是網路的問題造成的。

因為安控的關係,這幾家關係企業的網路只有在進到我機房時才會串在一起,而且彼此之間是無法 Router 的。而負責網路的也是同一家廠商,所以我先做了一個簡單的實驗。

將我機房的 FTP Port 防火牆開啟,然後我到客戶端以 FTP 上傳數個大小不等的檔案到我的主機端,就開始發現連線到我機房的網路不是很穩定,有時會 Hang 住不動,因此我將 SAP Router 透過 Internet 連線的 Port 啟動,透過客戶的 Internet 連線到我機房,然後暫時將幾個重要 User 設定為透過 SAP Router 連線,決定先觀察一週看看。

結果這一週以來,透過 SAP Router 連線的 User 的使用體驗是前所未有的順暢,反而是走 Intranet 的人一直在開罵。這時確實證實了一定是網路的問題,因此就找齊客戶的 MIS ,我和網路廠商的人出來開會討論,我將我測試的結果報告完畢後,網路廠商拿了一張流量圖,告訴我們,該客戶的網路流量一直非常正常,並沒有滿載的狀況,所以問題應該也不在他們那邊,他們會回去檢查看看是不是有問題,小弟當時想說真是睜眼說瞎話,我在這邊測了一個多星期時,你們在哪? 有了結果和證據了,開會時還說這種廢話。

因為我也不是客戶的 MIS ,客戶不發難,我也無話可說,只好就暫時離場,讓他們回公司去確認,就這樣過了快3 個月,開了快3次的會,每次的結果就是帶網路流量圖來,OOXX ,你也換一套吧,每個月開會都用這招也太沒梗了。然後同樣說客戶使用的流量一直沒滿載,問我們主機端有沒有什麼問題,我說有問題其他關係企業早就把我 K的滿頭包了,還需要等你們來問嗎? 這次的會議又沒有結論。

一直到隔了快幾個月後,客戶忽然都沒有再問過這個問題,我才去電問說,現在網路正常了嗎? 客戶才跟我說:「網路廠商後來發現是 core 上面對他們公司的那個 Port 有問題,流量到某個程度時就會 Hang 住,但是連線並不會中斷,後來換掉就沒問題了」

我當時心裏想說,那你們為何也不告訴我,我這幾個月的冤情要找誰討,每次開會就把問題指到我這裏來。解決了還要我來問才肯說。不過可以高興的是終於找到原因,而且不是我管理不當造成的。我還真是個容易滿足的人啊....

2010年8月9日 星期一

第十三回 Oracle 10g 的 BlockRecover

在剛剛某海運公司的問題處理過後,同樣該公司關係企業打來說他們的資料庫因為 Filesystem 一直有問題造成 HA 切換會失敗,所以在週六他們有請硬體廠商來做 FSCK ,當天做完沒問題,一直到過了星期天和今天星期一一整個上午後,Oracle 在某些 DML 會出現錯誤訊息,表示發生 Block Corruption 。原本我還在處理 RMAN 問題時,就己經把 Paper 整理給客戶請他們先試試看,可是一直到接近 16:00 時,客戶又打來問說我們能不能過去看看,反正也在附近,所以我和同事就開車過去了。此時心裏還在盤算著說,其實 Block Recover 我也只聽說過,有這個概念,實做還是沒做過的,而且怎這麼巧,最近翻的一本書裏才有說明類似的狀況,馬上就被我遇到。

到客戶端後,首先坐在電腦前,我先看了一下 v$database_block_corruption 這個 view 的內容,並沒有東西,因為在 FSCK 之後,Oracle 還能被啟動,而且 Application 也正常的運作,只是針對某些 Block 做 Access 時會出現 Block Corruption 的錯誤,同時在 FSCK 之後,當天的 RMAN 備份和今天的備份都失敗了。而且這個 view 只有在備份過程或者是你在下 backup validate database 時,才會去掃描整個資料庫,做 block 確認的動作,我如果不知道這個東西,以往可能會用 dbv 這個工具來掃。我先檢查 alert log ,發現確實有幾個 Block 在 Access 時被標記出來,首先針對這幾個 block 先以 blockrecover 指令測試看看是否有效,還原了兩個 block 之後,我決定使用 RMAN 的 backup validate database 整個全部掃描一次,預估需要 20 分鐘左右後,再去確認 v$database_block_corruption ,結果裏面有約 18 個 block 被標記出來。

有標記出來後就簡單了,只要使用 blockrecover corruption list , RMAN 就會參考這個 view 的內容去做 block recover ,又花了約半小時將資料庫還原後,我決定再將 Oracle database 備份一次,原因有二,一是確認資料庫可以整個被 RMAN 備份下來,二是在還原資料庫上線前,先確保這兩天的資料仍有被備份,所以將 Backup 送出去後,客戶也很客氣的邀我們先去用餐,約 40 分鐘後回來,資料庫確實的有被備份完成,將 Application 啟動後,我們就等待客戶測試,同時,雖然我 對 Solaris 並沒有很熟,還是無聊的下了 dmesg 看了一下,發現該 Filesystem 好像還是有問題,可能是有遺失的 inode ,因為客戶剛也有問到他有些檔案在 fsck 後不見了要怎麼比對找出來,個人覺得比對的工程龐大且無法準確,因此跟客戶解釋,如果每週對 ERP 都有做備份,無妨將 ERP 的整個 Home Directory 還原回來,包證 ERP 能像一週前一樣健康,不足的部份,貴公司的同仁一定有資料能查出這星期做了哪些變更再去調整即可,不然用比對方式再還原,可能你系統隨時會有未爆彈發生。在客戶檢查了約半小時後,大致上沒問題,我們才準備驅車回到台北。

第十二回 RMAN 在NBU 下備份效能時低落

今天和同事約好要去之前曾去美國出差過的某海運公司,原因是 NBU 透過 RMAN 備份時的效能有點奇怪,問題就是每次開始備份時,明明 Schedule 已經啟動了,而且 NBU 下的 Device 都閒置著,但是 RMAN 就是沒有動作, NBU 的狀態也沒有 LOG 表示有動作,必須要在過了 10~40分鐘不等的狀態下,才會將磁帶 Volume 掛載到磁帶館中,並開始做備份寫入動作。

因為同時間同一台資料庫下的同一個 Instance 也有 Archive Log 備份的工作剛正常結束,只有接之在後面的 Full Database Backup Schedule 有這個問題,所以把 RMAN 的 Scripts 整個叫出來看,其實也很一般就是正常的 RMAN Scripts 而己。

只不過這台資料庫主機內存在了兩個資料庫,其中一個備份的啟動是正常的,馬上可以取得備份的資源就開始做備份,只有我描述過那個資料庫會有問題,而這個資料庫的大小約 2.2TB ,剛開始我懷疑是因為這個資料庫比較大,所以在需要寫入前會有一些處理時間,但最短10分鐘,最長40分鐘,實在是太離譜了,別說是客戶,連我都無法接受,所以我花了一些時間查看這台資料庫在備份的時候到底在做什麼事,因為這台其實是 Product 的 Standby Database ,也就是 Database 的 Target 端,所以這台設備唯一的 Loading 就是傳輸 Archive Log 和 Apply Log 而己,特別對照了需要執行到 40 分鐘的那幾天有什麼特別的交易,看起來也沒有。

最後我比較了同一台資料庫下,兩個 Instance 登入到 RMAN 的方式,其中有問題的資料庫是使用 Catalog DB ,而沒有問題的那台則是 Nocatalog Mode 下面執行的。

所以我試著寫了一個備份該資料庫最小單一檔案的 RMAN Scripts 測試,分別使用 Catalog 和 Nocatalog Mode 去備,同樣的一個 20MB 的檔案,在Catalog Mode 之下,光 RMAN 在 Allocate Channel 指令送出去後,就沒有下文了,一直等到快 10 分鐘後,才有下一個作業被呼叫,且連備份完成後 Release Channel 的動作也是慢到無法接受;而在 Nocatalog Mode 之下處理時,則是一 Allocate Channel 後就開始備份,所以我想起了多年前那家書局 Catalog 久未維護所造成的問題,因此我就跟客戶先解釋一下可能發生的原因,然後詢問了上次整理 Catalog DB 的時間,客戶說並不是很清楚,只記得以前有重整過。

所以這下原因找到了,一樣就是 Catalog 未整理的狀態下,不只 Restore 時的效果非常差,連備份都會受到影響,雖然重整 Catalog DB 沒什麼了不起的,我還是決定先判定原因,待下次大家有機會開個會坐下討論時,再說明一次這件事後再來做處理,以免以後大家又忘記了。

最後因為該公司另一家關係企業的資料庫發生問題,我們要趕過去看,所以就先走了。這件事就這樣處理完畢。