記得2004 還2005年左右，我還在管理某家委外的 SAP 時，因為 Interface (ERP 統稱所有要對外連接的介面叫 Interface) 的部份要透過 Oracle 建立幾個 View ，並且授予權限給能夠存取的子公司存取，還跟網路的防火牆有關，當時我只糊里糊塗的搞清楚哪些 Object 要建立 View，並給哪些人權限，相對應的 SQL 怎麼下，要給哪幾間子公司，就請客戶來開會了，不知各位知不知道當天客戶來了多少人，首先，對口端的連絡人，應該叫他 PM ，但是這種小小的需求我想應該不需要有 PM 吧，然後有一個 SA 跟著來，還有一個客戶那邊的網管，和一個 DBA ，另外來了兩個日本顧問，還有一個翻譯，總共7個人，說實在的我嚇到了，因為我們這邊，只有我一個人負責這些事情。
其實需求都很清楚，客戶那邊有些也有對應的 Specific 了，所以就開始討論細節和 Schedule ，我心裏一直 OS ，SQL 程式碼有了，該給的權限也有了，網路開哪個 Port 連哪個 IP 也知道，這幾件事，我只要二小時就搞定，因為機器統統都是我管的，你們來那麼多人，還要討論什麼 Schedule ，我直接就說，你們回到公司時我就會弄好。直接連過來就是了。
現在我心裏想一想，當時對方那麼多人，個個領的薪水都可能比我當時還高，他們負責的東西還沒我多，憑什麼領那麼多錢? 所以當時兩小時可完成的事情事實上我覺得應該這樣子拆，資料庫的部份因為授權還要請我委外的客戶端開放然後填單，所以工作天三天，網路也是再加三天，然後我處理的時間要二天，頂多文件申請填單可以平行處理，但怕相關人等不在無法授權還要再加個 Buffer ，所以至少要七個工作天。結果我兩個小時就做掉了，我幹麼那麼精實啊我。
雖然這只是一件小小的事情，但看看以日本人為借鏡的客戶端多麼的重視，來了七個人開會，而我們只找了一隻像我一樣的小貓出來叫囂說我二個小時就可以搞定了，搞不好人家還以為我們不專業，不重視他們的需求哩。
所以事情會的多其實也不是什麼重點，當初我直接就開放給客戶使用是因為沒事(雖然我也有經過授權同意，但沒Paper Work)，萬一發生了個什麼資料外洩還是規格不對，如果有填單跑程序，出事了，你也還找的到人揹，說是某人同意某人如何如何。不然就是你自己扛了，說實在的也不是官僚，無論在大小公司，有時多嚴謹點也不是什麼壞事啦。只是這其中的拿捏就看個人了，如果當時我喊七天可完成，結果兩天做掉，人家是感謝你，你直接說二小時就可做掉，那不是反而不給人家面子，我們來這麼多人是幹麼吃的不是嗎?
2010年10月25日 星期一
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 解除。相對的其他廠商也會有類似的工具可以處理類似的問題。
首先無論在哪個 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 關閉了以後，這件事就真的解決了。
問題在 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 是完全不一樣的世界了。所以大家還是量力而為，基本上要投資自己，語文能力的訓練一定是不會錯的。
老實說，小弟手上的三張證照，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 住，但是連線並不會中斷，後來換掉就沒問題了」
我當時心裏想說，那你們為何也不告訴我，我這幾個月的冤情要找誰討，每次開會就把問題指到我這裏來。解決了還要我來問才肯說。不過可以高興的是終於找到原因，而且不是我管理不當造成的。我還真是個容易滿足的人啊....
因為其他點的關係企業並沒有類似的問題，而且有問題的這家關係企業跟其他關係企業也處在同一棟大樓內，所以我直接排除是我主機的問題，只能懷疑是網路的問題造成的。
因為安控的關係，這幾家關係企業的網路只有在進到我機房時才會串在一起，而且彼此之間是無法 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 能像一週前一樣健康，不足的部份，貴公司的同仁一定有資料能查出這星期做了哪些變更再去調整即可，不然用比對方式再還原，可能你系統隨時會有未爆彈發生。在客戶檢查了約半小時後，大致上沒問題，我們才準備驅車回到台北。
到客戶端後，首先坐在電腦前，我先看了一下 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 沒什麼了不起的，我還是決定先判定原因，待下次大家有機會開個會坐下討論時，再說明一次這件事後再來做處理，以免以後大家又忘記了。
最後因為該公司另一家關係企業的資料庫發生問題，我們要趕過去看，所以就先走了。這件事就這樣處理完畢。
因為同時間同一台資料庫下的同一個 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 沒什麼了不起的，我還是決定先判定原因，待下次大家有機會開個會坐下討論時，再說明一次這件事後再來做處理，以免以後大家又忘記了。
最後因為該公司另一家關係企業的資料庫發生問題，我們要趕過去看，所以就先走了。這件事就這樣處理完畢。
2010年7月30日 星期五
第十一回 2004 年我去美國的那幾天
2004年10月，因為某海運公司買了當時全世界算起來算是數一數二的超級計算機，要將原來的 Oracle Single Instance 變為 RAC，所以去了一次美國紐約。
英文很爛，技術也算是還好的我，當時能夠被挑中飛去裝機，完全也是意外，連回來後英文老師期末考考英文自我介紹(那時還在唸二技的進修班)，在我背了一大堆我準備好的文稿之後，老師只用英文問我說，你去美國是幹麼，因為我英文真的很爛，所以答不出來，老師又問，你去美國只需要打電腦就好了嗎? 都不用說話嗎? 只好硬擠了幾個字出來，還好老師最後還是讓我過了。
當時這次的經驗也是挺特別的，當時 911 剛發生滿一年多，所以那時的海關仍然很嚴格，光在台灣辦簽證我就覺得超級麻煩，雖然我是去工作，但是客戶那邊不肯發給我們工作證明，所以我們不能辦工作簽證，只能用觀光簽證進去，去辦簽證時，美國在台協會問我要去哪裏，我只說了一句拉斯維加斯他就蓋章了，旁邊比我早面談看起來要去遊學的，因為英文很好就被問了一大堆，看來辦美國簽證時，就算你英文再好，也是裝死比較容易拿到。
又扯遠了，這次去美國安裝的主機，其實是備援台灣這邊的同樣架構的備援系統，這家海運公司租了兩條 T1 的海纜，透過 Oracle 的 Dataguard 技術，達成了資料庫遠端備援，但其實在系統仍在 Single Instance 測試時，以這家公司的規模和交易量，兩條 T1 的頻寬仍是不足以傳輸實際的交易量的，所以我們在 DataGuard 的傳輸處理上，有特別的動了一些手腳，將之改為手動的批次壓縮傳輸，以節省頻寬，將這隻手動程式排入 crontab 後，就可以定時自動化傳輸了，而且我們也將兩邊資料庫的交易配置成相差六個小時，以防止有人為錯誤誤刪資料時，還可以去備援端將資料趕緊的匯出再匯回，就算 Primary 端發生災難，備援端追回六小時的交易大約要 1 小時的時間，這樣子 RPO 跟 RTO 是客戶可認可的。所以後來就這樣子設計了。
裝機的過程所幸還挺順利的，只是因為時差跟台灣相差了快 16 小時，通常我們在工作時，台灣這邊的同事在睡覺，他們睡覺時就輪到我們工作，每天有重疊到的時間了不起也二、三個小時，把前一天的工作交接後，他們就去休息了。只是光 Dataguard 要使用的 source ，就是 Primary 端的 RMAN 備份檔，我記得好像快 500GB 以上吧，當時光傳檔就需要八個小時，因為一次建立失敗，只好又重傳一次，還好最後有建起來就是了。不過這家海運公司真的很精實啊。
我還在台灣寫工作計劃時，原本只寫週一到週五，結果客戶問，那你們六、日要做什麼，我差一點就說六、日休息啊，還好沒說出口，後來就更改計劃內容，把一整個星期填的滿滿的。所以我們是真的星期六、日都還在機房工作，就連最後一天要上飛機的當天，早上從旅館退房出來後，還是去機房做最後的工作，一直到上飛機的前幾個小時才離開機房去機場報到，後來這幾年看到鴻海經常被報導說他們出差都是下飛機就去工作了，一直工作到要上飛機前都還在做，說到底我們也是這樣子的啊。其實中間有個假日客戶還是有帶我們有抽空跑去紐約州的隔壁，維吉尼亞州去逛了一下，後來又往南開去了大西洋城的賭場參觀。體驗了一下美國真的是地大到可怕，高速公路也是又大又直，只是過路費我們四個人 Share 下來，真的是不便宜，所以要在大蘋果生活還真的是不容易呢...。
英文很爛，技術也算是還好的我，當時能夠被挑中飛去裝機，完全也是意外，連回來後英文老師期末考考英文自我介紹(那時還在唸二技的進修班)，在我背了一大堆我準備好的文稿之後，老師只用英文問我說，你去美國是幹麼，因為我英文真的很爛，所以答不出來，老師又問，你去美國只需要打電腦就好了嗎? 都不用說話嗎? 只好硬擠了幾個字出來，還好老師最後還是讓我過了。
當時這次的經驗也是挺特別的，當時 911 剛發生滿一年多，所以那時的海關仍然很嚴格，光在台灣辦簽證我就覺得超級麻煩，雖然我是去工作，但是客戶那邊不肯發給我們工作證明，所以我們不能辦工作簽證，只能用觀光簽證進去，去辦簽證時，美國在台協會問我要去哪裏，我只說了一句拉斯維加斯他就蓋章了，旁邊比我早面談看起來要去遊學的，因為英文很好就被問了一大堆，看來辦美國簽證時，就算你英文再好，也是裝死比較容易拿到。
又扯遠了，這次去美國安裝的主機，其實是備援台灣這邊的同樣架構的備援系統，這家海運公司租了兩條 T1 的海纜，透過 Oracle 的 Dataguard 技術，達成了資料庫遠端備援，但其實在系統仍在 Single Instance 測試時，以這家公司的規模和交易量，兩條 T1 的頻寬仍是不足以傳輸實際的交易量的，所以我們在 DataGuard 的傳輸處理上，有特別的動了一些手腳，將之改為手動的批次壓縮傳輸，以節省頻寬，將這隻手動程式排入 crontab 後，就可以定時自動化傳輸了，而且我們也將兩邊資料庫的交易配置成相差六個小時，以防止有人為錯誤誤刪資料時，還可以去備援端將資料趕緊的匯出再匯回，就算 Primary 端發生災難，備援端追回六小時的交易大約要 1 小時的時間，這樣子 RPO 跟 RTO 是客戶可認可的。所以後來就這樣子設計了。
裝機的過程所幸還挺順利的，只是因為時差跟台灣相差了快 16 小時，通常我們在工作時，台灣這邊的同事在睡覺，他們睡覺時就輪到我們工作，每天有重疊到的時間了不起也二、三個小時，把前一天的工作交接後，他們就去休息了。只是光 Dataguard 要使用的 source ，就是 Primary 端的 RMAN 備份檔，我記得好像快 500GB 以上吧，當時光傳檔就需要八個小時，因為一次建立失敗，只好又重傳一次，還好最後有建起來就是了。不過這家海運公司真的很精實啊。
我還在台灣寫工作計劃時，原本只寫週一到週五，結果客戶問，那你們六、日要做什麼，我差一點就說六、日休息啊，還好沒說出口，後來就更改計劃內容，把一整個星期填的滿滿的。所以我們是真的星期六、日都還在機房工作，就連最後一天要上飛機的當天，早上從旅館退房出來後，還是去機房做最後的工作，一直到上飛機的前幾個小時才離開機房去機場報到，後來這幾年看到鴻海經常被報導說他們出差都是下飛機就去工作了，一直工作到要上飛機前都還在做，說到底我們也是這樣子的啊。其實中間有個假日客戶還是有帶我們有抽空跑去紐約州的隔壁，維吉尼亞州去逛了一下，後來又往南開去了大西洋城的賭場參觀。體驗了一下美國真的是地大到可怕，高速公路也是又大又直，只是過路費我們四個人 Share 下來，真的是不便宜，所以要在大蘋果生活還真的是不容易呢...。
2010年7月20日 星期二
聽我在放屁 CASE2 我如果去了 User Site ，我絕不用 RAC ，也不想用 HA
RAC 是 Oracle Database 的一個特性，可以用來提昇高可靠度和系統延展性，在理論上這兩個指數提昇的話，系統管理人員應該是高枕無憂了才對，但是事情絕對不是你我想的那麼簡單。
基本上兩部主機之間要高速存取資料庫，且有辦法互換資料，依賴的就是兩部主機之間的網路，而 Storage 層級，只是個儲存媒介，所以當主機從一台變成二台或三台，這兩部或三部主機間的網路就會由原本的2或3條，變為 4 或 9條，更多的線路，更多的卡片，更複雜的架構，硬體成本不算好了，這些管理成本都會落在系統人員身上，而且元件愈多，反而單一元件出錯的可能性變高了，我這邊說的出錯不是硬體元件壞掉，如果是斷線或損壞，那是個小問題，因為備援機制啟動後，這些問題都能被接手掉，但是如果是壞一半，半壞不壞，時通時不通的，時快時慢你就頭大了。這些問題都可能造成 RAC 的不穩定，效能變差，動不動就當機，而且問題有時還不只來自於硬體。
所以 Oracle RAC 架構在維護時需要上的 Patch 和 Update 大概是 Single Instance 時的數倍，而且可能經常性的需要關切及更新。所以基本上這個東西除非我所待的那個地方的資料庫己經大到無法用目前世界最大的伺服器去支撐他的需求，不然我大概是不會用的。因為那所帶來的，就是未來不知原因的當機，可能來自於時間同步，網路限制，單一伺服器的問題，還有很多可能完全找不到原因的當機，反正就是忽然一個 Node 不見，不然就忽然 Hang 住。我相信目前我見過的 RAC 在高可靠度這點是不及格的。
至於 HA Solution ，雖然有 HA 可以在最短的時間內讓你因主機硬體損壞將服務切換到另一部主機，但是如果你有心架了 HA，卻從來不驗證，那你這個 HA 在建置完成半年至一年後，就有可能是不會運作的，尤其是當你特別有心，設置了另一部機器平常還真的沒在 Run 什麼服務，只為了接手 Product ，那這個從來沒被驗證過的機制，大概有 6 成的機率是不會動的，為了這個機制特別買的機器結果只是插著浪費電而已，每年還要繳給原廠保護費，多划不來。
另外在有 HA 機制存在時，如果 Product 發生了 Outstge ，如果順利的話，系統會在 5 分鐘內被重新啟動，但這只限於 Product 本身的硬體壞掉，還有其他狀況是無法避免的，如果沒有重新啟動，我通常會有2種選擇：
1. 直接設法略過 HA 的機制，將服務啟動，盡最快的速度恢復服務讓使用者使用，至於 HA 機制，可能就另外安排時間將之恢復。
2. 設法恢復 HA 機制，將服務由 HA 啟動，此時可能會面臨很多問題，所需花費的修復時間，要視 HA 機制設定完成後，系統變做了多少變更而定，或是因為發生故障原因而定，所要花費的時間可能是第一種選擇的數倍以上。
至於發生 Outage 的原因，可能來自於系統內部，如系統軟體 Bug、應用程式 Bug 、硬體、韌体或系統外部如網路環境、SAN 環境、機房環境、電源種種原因造成，尤其在很多狀況下，很多公司在做 HA 機制時，通常還是只會保護主機本身，網路就沒有那麼重要了，其實很多時間就網管人員而言是他們是最重要的一個部份，通常一個機房如果要做整體維修，就系統而言，網路人員是最辛苦的，因為他們在最底層，關機時是最後關的，開機時又要第一個開起來，等所有系統開機完成無誤，網管人員才能夠休息。
題外話扯遠了，還是回到主題，其實就 Single Instance 我有信心可以維持好一定的可靠度，因為單純，當老闆有心投資到 IT 想要做一些防護時，我會建議他將錢投資在異地備援及備份上面，而不必去考慮自動化的備援環境，理由有幾個：
1.不是自動化的環境，就會有標準 SOP 的產出，在每次的驗證去修改，將 SOP 愈修愈是完整，總而言之主旨是不變的，程序上的修改也不會太大，除非系統是整個架構被翻掉
2.投資在異地備援，資料和系統都會有一定程度的保護，不像部份 HA 機制，只能保護到主機的部份，資料是未受到保護的。如果是主要機房受到天災人禍攻擊，就一般的主機端備援HA機制而言，是沒有任何用處的。
3. 依賴 HA 自動接手的機制，雖然還是會有 SOP，但可能發生的例外會較自己手動切換多的太多 ，而省下的時間頂多是從 30 分鐘縮短至5分鐘，而且自動化的程式也是人寫的，出錯誤判的機率仍然是存在的，與其將之投資在系統主機這端，個人還是認為不如去補強網路的 HA 或是異地備援上會更有效率。
這些心得都是在接觸了大量的 HA 環境後產生的，目前我約建置了快50套的 HACMP 環境，10套的 MSCS 環境，手上曾經維護過的也有 RHCS 和 MC Service Guide 環境，不過這就未實際參與建置。
當然以上所言，隨著科技的進步，一定會有成熟的一天，所以目前只能說就產品而言，仍然還是不成熟的。
基本上兩部主機之間要高速存取資料庫，且有辦法互換資料，依賴的就是兩部主機之間的網路，而 Storage 層級，只是個儲存媒介，所以當主機從一台變成二台或三台，這兩部或三部主機間的網路就會由原本的2或3條，變為 4 或 9條，更多的線路，更多的卡片，更複雜的架構，硬體成本不算好了，這些管理成本都會落在系統人員身上，而且元件愈多，反而單一元件出錯的可能性變高了，我這邊說的出錯不是硬體元件壞掉，如果是斷線或損壞，那是個小問題，因為備援機制啟動後，這些問題都能被接手掉，但是如果是壞一半，半壞不壞，時通時不通的，時快時慢你就頭大了。這些問題都可能造成 RAC 的不穩定，效能變差，動不動就當機，而且問題有時還不只來自於硬體。
所以 Oracle RAC 架構在維護時需要上的 Patch 和 Update 大概是 Single Instance 時的數倍，而且可能經常性的需要關切及更新。所以基本上這個東西除非我所待的那個地方的資料庫己經大到無法用目前世界最大的伺服器去支撐他的需求，不然我大概是不會用的。因為那所帶來的，就是未來不知原因的當機，可能來自於時間同步，網路限制，單一伺服器的問題，還有很多可能完全找不到原因的當機，反正就是忽然一個 Node 不見，不然就忽然 Hang 住。我相信目前我見過的 RAC 在高可靠度這點是不及格的。
至於 HA Solution ，雖然有 HA 可以在最短的時間內讓你因主機硬體損壞將服務切換到另一部主機，但是如果你有心架了 HA，卻從來不驗證，那你這個 HA 在建置完成半年至一年後，就有可能是不會運作的，尤其是當你特別有心，設置了另一部機器平常還真的沒在 Run 什麼服務，只為了接手 Product ，那這個從來沒被驗證過的機制，大概有 6 成的機率是不會動的，為了這個機制特別買的機器結果只是插著浪費電而已，每年還要繳給原廠保護費，多划不來。
另外在有 HA 機制存在時，如果 Product 發生了 Outstge ，如果順利的話，系統會在 5 分鐘內被重新啟動，但這只限於 Product 本身的硬體壞掉，還有其他狀況是無法避免的，如果沒有重新啟動，我通常會有2種選擇：
1. 直接設法略過 HA 的機制，將服務啟動，盡最快的速度恢復服務讓使用者使用，至於 HA 機制，可能就另外安排時間將之恢復。
2. 設法恢復 HA 機制，將服務由 HA 啟動，此時可能會面臨很多問題，所需花費的修復時間，要視 HA 機制設定完成後，系統變做了多少變更而定，或是因為發生故障原因而定，所要花費的時間可能是第一種選擇的數倍以上。
至於發生 Outage 的原因，可能來自於系統內部，如系統軟體 Bug、應用程式 Bug 、硬體、韌体或系統外部如網路環境、SAN 環境、機房環境、電源種種原因造成，尤其在很多狀況下，很多公司在做 HA 機制時，通常還是只會保護主機本身，網路就沒有那麼重要了，其實很多時間就網管人員而言是他們是最重要的一個部份，通常一個機房如果要做整體維修，就系統而言，網路人員是最辛苦的，因為他們在最底層，關機時是最後關的，開機時又要第一個開起來，等所有系統開機完成無誤，網管人員才能夠休息。
題外話扯遠了，還是回到主題，其實就 Single Instance 我有信心可以維持好一定的可靠度，因為單純，當老闆有心投資到 IT 想要做一些防護時，我會建議他將錢投資在異地備援及備份上面，而不必去考慮自動化的備援環境，理由有幾個：
1.不是自動化的環境，就會有標準 SOP 的產出，在每次的驗證去修改，將 SOP 愈修愈是完整，總而言之主旨是不變的，程序上的修改也不會太大，除非系統是整個架構被翻掉
2.投資在異地備援，資料和系統都會有一定程度的保護，不像部份 HA 機制，只能保護到主機的部份，資料是未受到保護的。如果是主要機房受到天災人禍攻擊，就一般的主機端備援HA機制而言，是沒有任何用處的。
3. 依賴 HA 自動接手的機制，雖然還是會有 SOP，但可能發生的例外會較自己手動切換多的太多 ，而省下的時間頂多是從 30 分鐘縮短至5分鐘，而且自動化的程式也是人寫的，出錯誤判的機率仍然是存在的，與其將之投資在系統主機這端，個人還是認為不如去補強網路的 HA 或是異地備援上會更有效率。
這些心得都是在接觸了大量的 HA 環境後產生的，目前我約建置了快50套的 HACMP 環境，10套的 MSCS 環境，手上曾經維護過的也有 RHCS 和 MC Service Guide 環境，不過這就未實際參與建置。
當然以上所言，隨著科技的進步，一定會有成熟的一天，所以目前只能說就產品而言，仍然還是不成熟的。
2010年7月14日 星期三
第十回 我是系統工程師，我不是劉謙....
上週五時和另一台同事去某外商銀行操作設定 AS/400 在 Tivoli Storage Server 上的備份，在我完成沒多久後，我去檢查客戶目前 TSM 的備份狀況，結果發現客戶的磁帶機終於在上線一年多後，兩個 Driver 都己經髒了，無法再讀取和寫入任何一捲磁帶的資料，因此日常的備份己經五、六天沒備份了。這個問題我己經在幾個月前就提出警告，但是客戶都沒有處理，一直到今天。
因為Driver 髒了也不是什麼大不了的事，就放清潔帶進去清潔就好了，我馬上回報客戶，這時他才跑去問機房人員，機房的人說其實他們一直都有清潔帶，只是沒人問過而己，馬上就幫我放進磁帶館中，讓我準備設定。
誰知上週大概是全省各大銀行年中的稽核，很多銀行這時都有稽核人員會來，沒提出需求申請，就算我再急也不能連線進去設定，因此從約 17:30起，我就一直在等客戶申請，一直到19:00了還沒下文，這時我己經想離開了。
但是客戶說沒有弄好不是未來備份還是有問題，所以不讓我走，我的媽啊，有問題不讓我做事，也不讓我走，那是怎樣，要我變魔術讓大家見證奇跡發生嗎? 我又不是劉謙。 而且 IT 只會有靈異事件，從來不會有發生見證奇跡的時刻發生。
我只好說那你們申請那個單子可以直接讓我進機房嗎? 我不要連線 Console ，以免到時有問題，我又得說要進機房去看那台設備，你們又要再提一次申請單，起先客戶還一直有疑慮看起來好像不太肯讓我進去，說那個機櫃有多重要多重要，後來想了半天才去申請單上更改，重新找到相關人員簽名後，我終於可以開工了。不過有趣的是，我在機房的這段時間，根本就沒人陪我，那這麼龜毛的 Security 到底是搞什麼鬼，堅持了半天還不是放我一個人在裏面亂搞。
等到整個搞定己經快 21:00 了，不過是清個磁帶，20分鐘就能搞定，在這裏要一等再等，搞到人快抓狂。我看我還是來去學特異功能，看哪天能不能練成用念力控制電腦算了。
因為Driver 髒了也不是什麼大不了的事，就放清潔帶進去清潔就好了，我馬上回報客戶，這時他才跑去問機房人員，機房的人說其實他們一直都有清潔帶，只是沒人問過而己，馬上就幫我放進磁帶館中，讓我準備設定。
誰知上週大概是全省各大銀行年中的稽核，很多銀行這時都有稽核人員會來，沒提出需求申請，就算我再急也不能連線進去設定，因此從約 17:30起，我就一直在等客戶申請，一直到19:00了還沒下文，這時我己經想離開了。
但是客戶說沒有弄好不是未來備份還是有問題，所以不讓我走，我的媽啊，有問題不讓我做事，也不讓我走，那是怎樣，要我變魔術讓大家見證奇跡發生嗎? 我又不是劉謙。 而且 IT 只會有靈異事件，從來不會有發生見證奇跡的時刻發生。
我只好說那你們申請那個單子可以直接讓我進機房嗎? 我不要連線 Console ，以免到時有問題，我又得說要進機房去看那台設備，你們又要再提一次申請單，起先客戶還一直有疑慮看起來好像不太肯讓我進去，說那個機櫃有多重要多重要，後來想了半天才去申請單上更改，重新找到相關人員簽名後，我終於可以開工了。不過有趣的是，我在機房的這段時間，根本就沒人陪我，那這麼龜毛的 Security 到底是搞什麼鬼，堅持了半天還不是放我一個人在裏面亂搞。
等到整個搞定己經快 21:00 了，不過是清個磁帶，20分鐘就能搞定，在這裏要一等再等，搞到人快抓狂。我看我還是來去學特異功能，看哪天能不能練成用念力控制電腦算了。
2010年7月12日 星期一
第九回 不用錢的最貴，MYSQL 到底是怎樣的資料庫
上週去協助某物流公司幫忙建置上次有問題的MYSQL的 Replication ，之前客戶出了個題目，200GB 的資料必須在 30分鐘內 Copy 完成，我們自己在公司建了環境模擬的結果，以 1000BaseT 的狀態能夠全速跑的話，有這個可能能夠完成，而且緩衝時間有 2 個小時，因此就做了(原本我要求光複製資料就要三個小時)。
誰知時間己經被卡的夠緊了的狀態下，客戶當天還排了一個 SAN Switch 更改串接設定，還有其他廠商也會一起進行的工作。還好我 SAN Switch 更改設定的工作在 40分鐘內就完成了，所以就等 MYSQL 的 Application 能夠停機的時候。
原本我要預先檢查機器，這下子才發現客戶把 Replication Target 搬去別的位置，要等客戶弄完才能做確認機器的動作，我只好先等。等到真正能上工的時間，就是原訂的工作時間了，這時我才開始確認機器設備，才發現客戶將網路連在 100Mbps 的網路上，這時才要求網路修改，等到最後 Ready ，己經超過我要做事的時間一個小時，因此整個進度也 Delay 了一個小時。
反正整個過程就是相當不順就是了，後來因為種種問題，這次好不容易安排的三個小時停機時間就這樣浪費掉了，所以 MYSQL Replication 也沒建立起來，事實上，我也不願意這種事情發生，明明我要的時間是三個小時，硬是要壓縮我的工時，而且還有一堆外力來干擾。
最後資料庫不得己要啟動時，我卻一直啟動不了，此時心裏一陣冷風吹過，這個資料庫從來沒備份成功過，如果這下子壞了，今天只有我動過，我在 IT 產業的日子大概就這樣完結了，只好一直 Try ，改參數啊，看 Log 什麼都試，後來好不容易開了起來。這時凌晨4點多被我叫起床的經理也趕來了。還好我有將資料庫開起來，不然還不知怎麼辦哩.....
只是當應用程式要啟動 Access DB 時，一直有些靈異現象發生，就是 Table 會被 Lock 住，但過沒多久就自己解開了，一直到我去檢視 Redhat Cluster 的狀態時，才發現兩個 Node MYSQL 程式都在運作。
就我一般對資料庫的認識的話，同一檔案有程序在上面時，資料庫程式應該要做一些控制，不管是誰家的，誰知道 MYSQL 並不會，所以當兩台機器都可以存取到同一個磁區時，這個磁區內的檔案居然可以被兩台機器同時存取。
所以我一直開不起來，還有應用程式連線時的怪異現象，這時就得到解釋了，說實在的，如果你的 MYSQL 要用來做交易，又像我這個客戶一年連 30 分鐘都不肯讓我關機的話，還是多花點錢吧，用個 SQL Server 也好，不要因為要省成本，搞的到時你都沒備份，資料全毀時，你就知道什麼叫做不用錢的最貴了。
基本上 MYSQL 目前的 Online Backup 的 Solution 大概都是透過 LVM 的 Snapshoot 後，再將 image 備份下來，但是在這個客戶下，因為用了 Redhat Cluster ，要做 Snapshoot 的話，在 GFS 這種 Filesystem 也有困難，因此也是沒辦法做。另外因為目前 MYSQL 己經被 Oracle 收購了，因此 Oracle 在做異質性平台資料轉換用的工具 Oracle Golden Gate在未來也會支援 MYSQL ，這個報價可能比 MYSQL 本身還貴上天的工具，我想他的可靠性鐵定是比 MYSQL 自己的 Replication 要高。
誰知時間己經被卡的夠緊了的狀態下，客戶當天還排了一個 SAN Switch 更改串接設定，還有其他廠商也會一起進行的工作。還好我 SAN Switch 更改設定的工作在 40分鐘內就完成了，所以就等 MYSQL 的 Application 能夠停機的時候。
原本我要預先檢查機器，這下子才發現客戶把 Replication Target 搬去別的位置，要等客戶弄完才能做確認機器的動作，我只好先等。等到真正能上工的時間，就是原訂的工作時間了，這時我才開始確認機器設備，才發現客戶將網路連在 100Mbps 的網路上，這時才要求網路修改，等到最後 Ready ，己經超過我要做事的時間一個小時，因此整個進度也 Delay 了一個小時。
反正整個過程就是相當不順就是了，後來因為種種問題，這次好不容易安排的三個小時停機時間就這樣浪費掉了，所以 MYSQL Replication 也沒建立起來，事實上，我也不願意這種事情發生，明明我要的時間是三個小時，硬是要壓縮我的工時，而且還有一堆外力來干擾。
最後資料庫不得己要啟動時，我卻一直啟動不了，此時心裏一陣冷風吹過，這個資料庫從來沒備份成功過，如果這下子壞了，今天只有我動過，我在 IT 產業的日子大概就這樣完結了，只好一直 Try ，改參數啊，看 Log 什麼都試，後來好不容易開了起來。這時凌晨4點多被我叫起床的經理也趕來了。還好我有將資料庫開起來，不然還不知怎麼辦哩.....
只是當應用程式要啟動 Access DB 時，一直有些靈異現象發生，就是 Table 會被 Lock 住，但過沒多久就自己解開了，一直到我去檢視 Redhat Cluster 的狀態時，才發現兩個 Node MYSQL 程式都在運作。
就我一般對資料庫的認識的話，同一檔案有程序在上面時，資料庫程式應該要做一些控制，不管是誰家的，誰知道 MYSQL 並不會，所以當兩台機器都可以存取到同一個磁區時，這個磁區內的檔案居然可以被兩台機器同時存取。
所以我一直開不起來，還有應用程式連線時的怪異現象，這時就得到解釋了，說實在的，如果你的 MYSQL 要用來做交易，又像我這個客戶一年連 30 分鐘都不肯讓我關機的話，還是多花點錢吧，用個 SQL Server 也好，不要因為要省成本，搞的到時你都沒備份，資料全毀時，你就知道什麼叫做不用錢的最貴了。
基本上 MYSQL 目前的 Online Backup 的 Solution 大概都是透過 LVM 的 Snapshoot 後，再將 image 備份下來，但是在這個客戶下，因為用了 Redhat Cluster ，要做 Snapshoot 的話，在 GFS 這種 Filesystem 也有困難，因此也是沒辦法做。另外因為目前 MYSQL 己經被 Oracle 收購了，因此 Oracle 在做異質性平台資料轉換用的工具 Oracle Golden Gate在未來也會支援 MYSQL ，這個報價可能比 MYSQL 本身還貴上天的工具，我想他的可靠性鐵定是比 MYSQL 自己的 Replication 要高。
2010年6月24日 星期四
聽我在放屁CASE 1 公司大小間，廠商絕對是給你大小眼
本篇不會說公司的抬頭，所以不用去猜測什麼....
公司大間小間買東西有沒有差，當然絕對有差，舉例來說....
國內的幾家龍頭指標公司，不用說哪家，只要是龍頭一定都很大，他們買機器其實可能都可以不用簽維護，砍的 discount 也可能比誰都深。為什麼呢? 因為是指標型的大客戶，死都得賣進去，絕對不能給敵對廠商有踩進去的機會。
所以嘍，在大型計算機市場其實是沒什麼市場價，公定價，和原則了，同一台機器，價錢可以差十幾倍，買了也不一定會簽維護，不簽，那過保後怎麼辦，放心.....我是指標型的大客戶，你說沒維護不來修是不是，好，OK，我明天找別家來，統統給你換掉，反正上面的應用程式都有廠商會想辦法，我才不管複不複雜，要花多少時間，明天市場上就會知道，某大型系統供應商在哪家客戶那被踢掉了，看你屌的起來屌不起來，天啊，多沒面子，搞不好業務還得走路，為什麼沒顧好。所以這種客戶忠誠度當然高，因為沒人踩的進去。
那同樣一台機器，我不是指標型客戶，可能年營業額不過幾千萬到幾億(這樣好像也很大嘛!!)，但是過保後機器壞掉，打電話報修，抱歉你這個沒有維護合約喔；沒維護，那per call 可以嗎? 可以啊，不過請線上簽約，匯款或刷卡付錢，馬上就有專人幫你處理，，好不容易刷了個幾萬塊過去，錢也給了，等了很久，生產線都停擺了，訂單也沒辦法敲，一直沒回應，好不容易來了通電話，那個對不起，今天派不出工，可能要明天喔，另外依照你目前的狀況，可能需要更換的料件要待料一週喔.......。
什麼.... 一週.....，這擺明就是要逞罰你不簽維護不是嗎? 可是庫房裏有沒有那個零件...我想在台灣一定有，就算台灣沒有，香港也有，日本也有，坐飛機二個小時就到了，但是你是 Per call ，你又不是維護客戶，也不是指標型客戶，什麼，你說你付了錢了，你刷那幾萬塊付機票錢都不夠，更何況零件費哩，而且我也打了電話告訴你處理的方式和時間了不是嗎。所以就慢慢等吧，你的ERP系統停擺，這個我也沒辦法，我們台灣庫房一線的零件都是為了有維護的客戶留的，不能為你 Per Call 的客戶維修供應喔。而且合約上只有說明多久內要回覆，沒有說多久內要處理完畢不是嗎? 我己經盡了合約上的義務了哦。
不過啊，上面那個定律也有不對的時候啊，當你的公司是被認定的指標型客戶時，有時也會被當肥羊宰殺的啊。同樣可能還是得看採購人員的能力和挑廠商的眼力嘍，不過也有可能跟某個東西的多寡有關係，這個就不能多說了。我只是小小工程師，那些事絕對不是我能介入的。
說真的，這個市場也是弱肉強食，上面那種情況啊，看過好多次了，也不知該說什麼，只能說做一行怨一行，離開一個坑，只是跳進另一個坑而己嘍。
公司大間小間買東西有沒有差，當然絕對有差，舉例來說....
國內的幾家龍頭指標公司，不用說哪家，只要是龍頭一定都很大，他們買機器其實可能都可以不用簽維護，砍的 discount 也可能比誰都深。為什麼呢? 因為是指標型的大客戶，死都得賣進去，絕對不能給敵對廠商有踩進去的機會。
所以嘍，在大型計算機市場其實是沒什麼市場價，公定價，和原則了，同一台機器，價錢可以差十幾倍，買了也不一定會簽維護，不簽，那過保後怎麼辦，放心.....我是指標型的大客戶，你說沒維護不來修是不是，好，OK，我明天找別家來，統統給你換掉，反正上面的應用程式都有廠商會想辦法，我才不管複不複雜，要花多少時間，明天市場上就會知道，某大型系統供應商在哪家客戶那被踢掉了，看你屌的起來屌不起來，天啊，多沒面子，搞不好業務還得走路，為什麼沒顧好。所以這種客戶忠誠度當然高，因為沒人踩的進去。
那同樣一台機器，我不是指標型客戶，可能年營業額不過幾千萬到幾億(這樣好像也很大嘛!!)，但是過保後機器壞掉，打電話報修，抱歉你這個沒有維護合約喔；沒維護，那per call 可以嗎? 可以啊，不過請線上簽約，匯款或刷卡付錢，馬上就有專人幫你處理，，好不容易刷了個幾萬塊過去，錢也給了，等了很久，生產線都停擺了，訂單也沒辦法敲，一直沒回應，好不容易來了通電話，那個對不起，今天派不出工，可能要明天喔，另外依照你目前的狀況，可能需要更換的料件要待料一週喔.......。
什麼.... 一週.....，這擺明就是要逞罰你不簽維護不是嗎? 可是庫房裏有沒有那個零件...我想在台灣一定有，就算台灣沒有，香港也有，日本也有，坐飛機二個小時就到了，但是你是 Per call ，你又不是維護客戶，也不是指標型客戶，什麼，你說你付了錢了，你刷那幾萬塊付機票錢都不夠，更何況零件費哩，而且我也打了電話告訴你處理的方式和時間了不是嗎。所以就慢慢等吧，你的ERP系統停擺，這個我也沒辦法，我們台灣庫房一線的零件都是為了有維護的客戶留的，不能為你 Per Call 的客戶維修供應喔。而且合約上只有說明多久內要回覆，沒有說多久內要處理完畢不是嗎? 我己經盡了合約上的義務了哦。
不過啊，上面那個定律也有不對的時候啊，當你的公司是被認定的指標型客戶時，有時也會被當肥羊宰殺的啊。同樣可能還是得看採購人員的能力和挑廠商的眼力嘍，不過也有可能跟某個東西的多寡有關係，這個就不能多說了。我只是小小工程師，那些事絕對不是我能介入的。
說真的，這個市場也是弱肉強食，上面那種情況啊，看過好多次了，也不知該說什麼，只能說做一行怨一行，離開一個坑，只是跳進另一個坑而己嘍。
2010年6月17日 星期四
小插曲 USB 設定防寫
USB 輸出入埠大家都己經用的很習慣了，也非常方便，但是缺點就是只要你的電腦沒鎖，任何人都可以在你不在電腦旁時拿個隨身碟隨便 COPY 你電腦你的資料。
不過這個在 Windows 裏是有方法可以解決的。
開啟一空白文字檔案將下列文字複製
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\StorageDevicePolicies]
"WriteProtect"=dword:00000001
再貼回文字檔，存回副檔名為 .reg 的格式，點選該檔案兩下。將之匯入 Register 登錄表中。
接下來你的電腦只要插了 USB 隨身碟，就會變成唯讀，無法寫入資料。
變回來的方法只要將 WriteProtect 的 dword 的最後一個數字 1 變成 0 ，再重新匯入，就會還原，如下所示：
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\StorageDevicePolicies]
"WriteProtect"=dword:00000000
請記得，正在運行車的設備是無效的，所以更改後請將 USB 儲存設備移除後再重新安裝
不過這個在 Windows 裏是有方法可以解決的。
開啟一空白文字檔案將下列文字複製
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\StorageDevicePolicies]
"WriteProtect"=dword:00000001
再貼回文字檔，存回副檔名為 .reg 的格式，點選該檔案兩下。將之匯入 Register 登錄表中。
接下來你的電腦只要插了 USB 隨身碟，就會變成唯讀，無法寫入資料。
變回來的方法只要將 WriteProtect 的 dword 的最後一個數字 1 變成 0 ，再重新匯入，就會還原，如下所示：
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\StorageDevicePolicies]
"WriteProtect"=dword:00000000
請記得，正在運行車的設備是無效的，所以更改後請將 USB 儲存設備移除後再重新安裝
2010年6月1日 星期二
小插曲 NBU 的有趣行為
在某人壽安裝 TS3100 的 Expansion時，客戶有要求要測試新機的速度，要做測試報告，因為之前第一個 System Draw 上面安裝的都是 LTO3，後來新機裝的是 LTO4，所以要測試，安裝了 Exp 和新的磁帶機之後， NBU 的廠商有前來將 Driver 設定進 NBU 之中，而我們在測試磁帶機時是使用標準的 OS 指令去操作，結果發生了一件事。
新的磁帶機在我們操作測試時，無論執行 tar 或 tapecopy 的操作狀況下，會不定時的莫明奇妙就掛點，測了好幾次都一樣，一直到後來我們才知道 NBU 在定時去 Polling 自己受管理的磁帶機，所以其他 Process 的操作會莫明的被中斷掉。
另外那個 Expansion 可不是好裝的，建議有機會安裝時要將整個機械手臂模組整組拿出來再重新置入，因為經常會前後齒輪定位差一格 (肉眼看不太出來) 造成手臂一直跑來跑去之後就吐 Error。
新的磁帶機在我們操作測試時，無論執行 tar 或 tapecopy 的操作狀況下，會不定時的莫明奇妙就掛點，測了好幾次都一樣，一直到後來我們才知道 NBU 在定時去 Polling 自己受管理的磁帶機，所以其他 Process 的操作會莫明的被中斷掉。
另外那個 Expansion 可不是好裝的，建議有機會安裝時要將整個機械手臂模組整組拿出來再重新置入，因為經常會前後齒輪定位差一格 (肉眼看不太出來) 造成手臂一直跑來跑去之後就吐 Error。
2010年5月31日 星期一
第八回 某外商公司的備份還原演練
小弟公司服務的範圍其實相當廣，還包含了異地異機還原演練這種服務，記得去年接了一家外商公司的 Case ，就是將該公司平常一直在外送的備援磁帶做還原演練。
理想值是這樣的，該公司每天都會將公司重要主機的備份再另行複製一份透過快遞送到異地的保險箱，隔天再去取回來使用，總共有三組這種磁帶在輪替，輪替的時間可能己經兩年多了，從未有過演練。
這次我們將磁帶一拿到後，就先回復備份用主機之資料庫，因為備援中心的同事將資料庫倒回來後，一直覺得有問題請我過去支援，我檢查了一下後發現有些怪怪的地方後就跟客戶連絡，我想去直接看目前備份用的系統主機做檢察，這才發現一件事。
原有的備份系統可能大約在上線一年半後，就己經發生放置 Copy 帶子的空間不足的問題，而因為原廠商設定的方法並沒去檢核每個步驟，造成每天備份的 Report 都是成功的，一直到我發現。雖然客戶還是一直質疑我說明明每天的 Report 都說備份是成功的，為何我說是失敗的呢? 只好開了一個會說明目前備份的內容和架構，並列出正常 Pool 和 Copy Pool 的備份空間並不同，客戶才相信我的說法。
所以意思就是說，其實己經不知道有多久時間了，每天從磁帶機拿出來請快遞送走，鎖到銀行保險箱的磁帶都是空的。我將客戶的現有備份系統備份的 Script 稍作了一些修改，並調整了帶子的數量，重新再執行了一次磁帶 Copy ，因為己許久沒執行過，這次執行可能會稍久，我看了程序有在跑就先離開了。
直到第二天確認完成後，磁帶再度送到驗證中心去，這次就確定內容物是有資料的，可以開始做還原演練了。
最後要提醒各位人客啊，備份不是備完了送走就好了，平常定時要演練一下啊，快遞公司和銀行應該感謝你們，白白給了他們每天送幾捲空白磁帶保存和運送的這筆生意機會。所以挨踢人這次又救了一家公司，如果等到哪天他們機房出了什麼事後才發現送到異地的磁帶是空白的不知老闆會有什麼表情。
理想值是這樣的，該公司每天都會將公司重要主機的備份再另行複製一份透過快遞送到異地的保險箱，隔天再去取回來使用，總共有三組這種磁帶在輪替，輪替的時間可能己經兩年多了，從未有過演練。
這次我們將磁帶一拿到後，就先回復備份用主機之資料庫，因為備援中心的同事將資料庫倒回來後，一直覺得有問題請我過去支援，我檢查了一下後發現有些怪怪的地方後就跟客戶連絡，我想去直接看目前備份用的系統主機做檢察，這才發現一件事。
原有的備份系統可能大約在上線一年半後，就己經發生放置 Copy 帶子的空間不足的問題，而因為原廠商設定的方法並沒去檢核每個步驟，造成每天備份的 Report 都是成功的，一直到我發現。雖然客戶還是一直質疑我說明明每天的 Report 都說備份是成功的，為何我說是失敗的呢? 只好開了一個會說明目前備份的內容和架構，並列出正常 Pool 和 Copy Pool 的備份空間並不同，客戶才相信我的說法。
所以意思就是說，其實己經不知道有多久時間了，每天從磁帶機拿出來請快遞送走，鎖到銀行保險箱的磁帶都是空的。我將客戶的現有備份系統備份的 Script 稍作了一些修改，並調整了帶子的數量，重新再執行了一次磁帶 Copy ，因為己許久沒執行過，這次執行可能會稍久，我看了程序有在跑就先離開了。
直到第二天確認完成後，磁帶再度送到驗證中心去，這次就確定內容物是有資料的，可以開始做還原演練了。
最後要提醒各位人客啊，備份不是備完了送走就好了，平常定時要演練一下啊，快遞公司和銀行應該感謝你們，白白給了他們每天送幾捲空白磁帶保存和運送的這筆生意機會。所以挨踢人這次又救了一家公司，如果等到哪天他們機房出了什麼事後才發現送到異地的磁帶是空白的不知老闆會有什麼表情。
第七回 AIX 的記憶體配置
AIX 這套作業系統是 IBM 在自家的 UNIX 上使用的作業系統，也是由IBM 開發的，目前只有 BULL 和 IBM 的 Power 伺服器能夠使用 AIX 。 最新版本是 6.1 ，但隨著 Power 7 的上市， AIX 7 己經快出現了，小弟覺得 AIX 6.1 可能是有始以來最短命的一個版本。由過往歴史看來，過去的 4.3.2 和 5.1 都很短命，4.3.2 之後沒多久，4.3.3 就出了，5.1 馬上就5.2，沒多久又 5.3，目前看來 5.3 大概是 AIX 最命長的一個版本。
有關AIX 的記憶體配置一直有個奇怪的問題，就是無論你的記憶體裝了多少，系統配置時都會儘可能的讓作業系統拿來當成檔案系統 JFS/JFS2 操作的 Cache，而且會儘可能的把記憶體都吃光，這使得有些正常的使用者作業要用到記憶體時，系統就要去做記憶體分頁切換，而在 AIX 5.2 ML5 和 AIX 5.3 ML2之前，這個動作並沒有被最佳化過，意思就是平常記憶體可能都會被 File System Cache 佔用，但真正使用者要執行的程式要使用時，實體記憶體己經被佔用光了，所以系統就會大量的使用 VMM 上面定義的磁碟分頁的部份，如此一來，真正的效能就會被磁碟分頁這個動作整個拖住。造成效能非常的差。
在剛剛說的 AIX 5.2 ML5 和 AIX 5.3 ML2 之前，我們使用 VMO 中的 Min Perm 和 Max Perm 來限制 File System Cache ，讓系統可保有最小有 Min Perm 定義的百分比 Size 的 File Cache ，最大又只能使用 Max Perm 定義的 Cache ，這樣的話就能改善上述的一些狀況。
另外在搭配 Oracle 9i /10g 版本時，更可以在系統上去改動 v_pinshm=1 ，然後將 Oracle 的 Lock_SGA 啟動，讓 Oracle 的 SGA 部份啟動後就佔住記憶體，不會再接受系統操作去切換分頁位置，但是 v_pinshm=1 這個設定如果在記憶體較小的設備上(其實己經遇過幾次，說比較小，也不一定，有很大的系統還是當過)，經常造成系統當掉，每次原廠工程師把 Report 收回去一看就會說這個要關掉不能開，但 Oracle 明明有文件說這個開了效能才會上來。每次就為了這個參數在吵。
一直到 AIX 5.2 ML5 和 AIX 5.3 ML2 之後，有了一個新的參數叫 LRU_FILE_REPAGE ，系統預設是 1 ，建議是 0 (AIX 6 好像己經將這個參數拿掉，直接預設就是 0 ，就是叫你一定要設成 0 就對了啦，不過要我裝過 AIX6 時再來確認這件事) ，這個參數設定為 0 後，系統就會將記憶體優先配置給使用者使用，假設記憶體己經全部被 Filesystem Cache 部份佔掉了，當有使用者要使用時，Filesystem Cache 就會優先被釋放出來供使用者的應用程式使用。
有這個參數以後，在各種應用系統的記憶體問題效能就有比較大幅度的解決，起碼記憶體不會再莫明奇妙的一直被吃光，然後用到磁碟分頁去了，除非，你的記憶體是真的不夠的。但是記住一點，你在各種記憶體監控程序去檢視記憶體時，你仍然會發現記憶體的 Free Space 可能還是 2%~3%或者是更少，除非你的系統開起來都沒有任何運作。
另外 File System Cache 只有在有使用 JFS/JFS2 的狀態下，有執行 OS Level 的 檔案操作時會被使用到，比如說 copy 檔案， tar 檔案等等這些檔案的 I/O 行為，如果是像 Oracle 那種直接由 Block Level 或是說使用 RAW Device 是不會用到 File Cache的。
有關AIX 的記憶體配置一直有個奇怪的問題，就是無論你的記憶體裝了多少，系統配置時都會儘可能的讓作業系統拿來當成檔案系統 JFS/JFS2 操作的 Cache，而且會儘可能的把記憶體都吃光，這使得有些正常的使用者作業要用到記憶體時，系統就要去做記憶體分頁切換，而在 AIX 5.2 ML5 和 AIX 5.3 ML2之前，這個動作並沒有被最佳化過，意思就是平常記憶體可能都會被 File System Cache 佔用，但真正使用者要執行的程式要使用時，實體記憶體己經被佔用光了，所以系統就會大量的使用 VMM 上面定義的磁碟分頁的部份，如此一來，真正的效能就會被磁碟分頁這個動作整個拖住。造成效能非常的差。
在剛剛說的 AIX 5.2 ML5 和 AIX 5.3 ML2 之前，我們使用 VMO 中的 Min Perm 和 Max Perm 來限制 File System Cache ，讓系統可保有最小有 Min Perm 定義的百分比 Size 的 File Cache ，最大又只能使用 Max Perm 定義的 Cache ，這樣的話就能改善上述的一些狀況。
另外在搭配 Oracle 9i /10g 版本時，更可以在系統上去改動 v_pinshm=1 ，然後將 Oracle 的 Lock_SGA 啟動，讓 Oracle 的 SGA 部份啟動後就佔住記憶體，不會再接受系統操作去切換分頁位置，但是 v_pinshm=1 這個設定如果在記憶體較小的設備上(其實己經遇過幾次，說比較小，也不一定，有很大的系統還是當過)，經常造成系統當掉，每次原廠工程師把 Report 收回去一看就會說這個要關掉不能開，但 Oracle 明明有文件說這個開了效能才會上來。每次就為了這個參數在吵。
一直到 AIX 5.2 ML5 和 AIX 5.3 ML2 之後，有了一個新的參數叫 LRU_FILE_REPAGE ，系統預設是 1 ，建議是 0 (AIX 6 好像己經將這個參數拿掉，直接預設就是 0 ，就是叫你一定要設成 0 就對了啦，不過要我裝過 AIX6 時再來確認這件事) ，這個參數設定為 0 後，系統就會將記憶體優先配置給使用者使用，假設記憶體己經全部被 Filesystem Cache 部份佔掉了，當有使用者要使用時，Filesystem Cache 就會優先被釋放出來供使用者的應用程式使用。
有這個參數以後，在各種應用系統的記憶體問題效能就有比較大幅度的解決，起碼記憶體不會再莫明奇妙的一直被吃光，然後用到磁碟分頁去了，除非，你的記憶體是真的不夠的。但是記住一點，你在各種記憶體監控程序去檢視記憶體時，你仍然會發現記憶體的 Free Space 可能還是 2%~3%或者是更少，除非你的系統開起來都沒有任何運作。
另外 File System Cache 只有在有使用 JFS/JFS2 的狀態下，有執行 OS Level 的 檔案操作時會被使用到，比如說 copy 檔案， tar 檔案等等這些檔案的 I/O 行為，如果是像 Oracle 那種直接由 Block Level 或是說使用 RAW Device 是不會用到 File Cache的。
第六回 VMWARE 的 VCB 搭配備份軟體使用，以 TSM 為例
VMWare 搭配 VCB 再搭配 TSM 有幾種做法，一種是從 TSM Client 6.1 的設定裏面設定，看書上寫的好像要設定什麼 Proxy Node ，有點不太懂，所以我就沒有使用這個方法。
另外的話就是使用 VMWare 提供的 TSM Integragtion 的工具，我後來就是使用這個方法，因為看起來好像比較簡單一點，接下來就來說說大概的說法，首先去 VMWare 官方下載 VMware Consolidated Backup 這包工具，其實他是由 WSH 組成的，意思就是 VMWare 己經寫好一套方法，讓你可以用很簡單的指令去 Mount 來自 ESX 上面的 Filesystem ，無論是透過 LAN 或 SAN 。
http://www.vmware.com/support/vi3/doc/releasenotes_vcb103.html
記得除了這個工具，原有的 VCB Backup (又稱 VCB Proxy)的工具原本就必須要安裝，安裝方式和路徑就不再提了。
安裝完成後在 c:\Program Files\VMware\VMware Consolidated Backup Framework\config \ 下可以找到 config.js 這個設定檔，裏面重要的參數有
BACKUPROOT="E:\\mnt1";備份之 VMDK 檔放置路徑
HOST="VC Server IP address";備份之 ESX 主機或 VC 主機之TCP/IP 位置
USERNAME="tsmuser";備份之 ESX 主機或 VC 主機之使用者名稱
*PASSWORD="passw0rd";上列使用者之密碼，如使用Register 的方式註冊，不需提供此參數，但在 Register 裏面密碼仍然是明碼顯示
TRANSPORT_MODE="san";傳輸模式，預設為 SAN，我試過在 Gigabit Ethernet 的環境和 SAN 的速度差異應該近十倍，非常建議使用 SAN 的模式，前提是你的 VMESX 的 Guest Host 的 Lun 要在 SAN Disk 上面，但有用 VMWare ESX 的人應該都會有好幾台 ESX 做 VMotion ，這應該不是什麼問題。
VM_LOOKUP_METHOD="name";VM找尋方式，預設為 ipaddr ，目前設定為 name
首先你需要在 VC 上面建立一個 User ，必須有 VCB Backup 的權限，將使用者名稱及密碼設定在上述參數中。
設定完成後就可以透過 pre-command vcb 及 vmname 去備份你的 VM ，這隻程式會透過呼叫 VC 去觸發你的 ESX 完成 Snapshoot 的動作，然後用 vcbmount 把 VM 的 Image Copy 到你所設定的目錄上，再由 TSM 將該目錄完整的備份下來即可。
為此我寫了一個 Windows 的批次檔，目標是完成，檢查 e:\vmesx2.lst 裏面提供的 VM 清單，並觸發 vcbmounter 去備份清單中每個 VM Guest 的 Image 內容。另外在前面加了一段會將前一次備份的內容先行移轉到 e:\mnt2 去，如此確保在這台 VCB Server 上面會有最新的兩次備份內容(一份在 e:\mnt1，一份會在 e:\mnt2)，批次檔內容如下：
@echo off
REM TSM 環境變數設置
set DSM_CONFIG=C:\Program Files\Tivoli\TSM\baclient\dsm.opt
set DSM_DIR=C:\Program Files\Tivoli\TSM\baclient
set DSM_LOG=C:\Program Files\Tivoli\TSM\baclient
REM 備份前置部驟，刪除硬碟中前兩次備份資料，另將上次備份資料轉移至 e:\mnt2
for /f "delims==" %%i In (e:\vmesx2.lst) do rmdir e:\mnt2\%%i /s/q
for /f "delims==" %%i In (e:\vmesx2.lst) do move e:\mnt1\%%i e:\mnt2\%%i
REM 執行 VCB 程序，開始備份 e:\vmesx2.lst 中所列出之 Guest Host 之 VMDK 檔至 e:\mnt1
for /f "delims==" %%i In (e:\vmesx2.lst) do call pre-command vcb %%i
REM 執行 TSM備份 程序，開始備份 e:\vmesx2.lst 中所列出之 Guest Host 於 e:\mnt1 中對應之目錄
for /f "delims==" %%i In (e:\vmesx2.lst) do dsmc incr e:\mnt1\%%i -subdir=yes
REM 檢查 TSM備份結果，導出至 e:\tsmlog\vcb_backup_esx02.log
for /f "delims==" %%i In (e:\vmesx2.lst) do dsmc q backup e:\mnt1\%%i\* >> e:\tsmlog\vcb_backup_esx02.log
vmesx2.lst之內容如下：
XXX01-FullVM
XYZ01-FullVM
ABC01-FullVM
使用 VMware Consolidated Backup Framework 的規則就是你要備份 Snap Shoot 的VMDK Image 時，給的 VM Name 必須要加上 -FullVM 的關鍵字，他就會自動轉換為對應的 VcbMounter 指令。
原本我這個 Job 是 Work 的，但在客戶端，我遇到問題了。
因為客戶隨時會把 VM 移來移去，或者換名字換 IP ，甚至原本己在 SAN Disk 裏面的 VMDK 檔在客戶移動後變成在 Local Disk ，造成了幾個問題如下：
1.可能是客戶換網段，換名字，造成 VMTOOLS 好像有點問題，使用 VCBVMNAME 都 Scan 不到該 VM ，這時可能要移除 VMTOOLS ，再重新安裝，讓VCBVNMAME 至少要看的到這個 VM 才能進行備份，記住，從 VC 上看的到該 VM 仍然是不足夠的。
2.因為客戶會將 VMDK 從 SAN 的 Disk 移到 Local 的 Disk，造成我原本己設定成 SAN Disk 備份的屬性己可備份結果又變成不能備，針對這點用 pre-command 就無法隨時變來變去了，我寫 Windows Batch 的技巧還沒這麼出神入化，最後我決定告訴客戶，在你這個隨時會變化的環境，可能必須要自己手動備份才有辦法。
唉....花了大把心力幫客戶完成的方案結果無法使用，不過還是公佈個大概給大家瞧瞧。其實這個作法應該是用別的備份軟體也能做，不限於 TSM 吧。反正就是先把 VMDK 檔備份下來，再由 TSM 備走而己。
另外的話就是使用 VMWare 提供的 TSM Integragtion 的工具，我後來就是使用這個方法，因為看起來好像比較簡單一點，接下來就來說說大概的說法，首先去 VMWare 官方下載 VMware Consolidated Backup 這包工具，其實他是由 WSH 組成的，意思就是 VMWare 己經寫好一套方法，讓你可以用很簡單的指令去 Mount 來自 ESX 上面的 Filesystem ，無論是透過 LAN 或 SAN 。
http://www.vmware.com/support/vi3/doc/releasenotes_vcb103.html
記得除了這個工具，原有的 VCB Backup (又稱 VCB Proxy)的工具原本就必須要安裝，安裝方式和路徑就不再提了。
安裝完成後在 c:\Program Files\VMware\VMware Consolidated Backup Framework\config \ 下可以找到 config.js 這個設定檔，裏面重要的參數有
BACKUPROOT="E:\\mnt1";備份之 VMDK 檔放置路徑
HOST="VC Server IP address";備份之 ESX 主機或 VC 主機之TCP/IP 位置
USERNAME="tsmuser";備份之 ESX 主機或 VC 主機之使用者名稱
*PASSWORD="passw0rd";上列使用者之密碼，如使用Register 的方式註冊，不需提供此參數，但在 Register 裏面密碼仍然是明碼顯示
TRANSPORT_MODE="san";傳輸模式，預設為 SAN，我試過在 Gigabit Ethernet 的環境和 SAN 的速度差異應該近十倍，非常建議使用 SAN 的模式，前提是你的 VMESX 的 Guest Host 的 Lun 要在 SAN Disk 上面，但有用 VMWare ESX 的人應該都會有好幾台 ESX 做 VMotion ，這應該不是什麼問題。
VM_LOOKUP_METHOD="name";VM找尋方式，預設為 ipaddr ，目前設定為 name
首先你需要在 VC 上面建立一個 User ，必須有 VCB Backup 的權限，將使用者名稱及密碼設定在上述參數中。
設定完成後就可以透過 pre-command vcb 及 vmname 去備份你的 VM ，這隻程式會透過呼叫 VC 去觸發你的 ESX 完成 Snapshoot 的動作，然後用 vcbmount 把 VM 的 Image Copy 到你所設定的目錄上，再由 TSM 將該目錄完整的備份下來即可。
為此我寫了一個 Windows 的批次檔，目標是完成，檢查 e:\vmesx2.lst 裏面提供的 VM 清單，並觸發 vcbmounter 去備份清單中每個 VM Guest 的 Image 內容。另外在前面加了一段會將前一次備份的內容先行移轉到 e:\mnt2 去，如此確保在這台 VCB Server 上面會有最新的兩次備份內容(一份在 e:\mnt1，一份會在 e:\mnt2)，批次檔內容如下：
@echo off
REM TSM 環境變數設置
set DSM_CONFIG=C:\Program Files\Tivoli\TSM\baclient\dsm.opt
set DSM_DIR=C:\Program Files\Tivoli\TSM\baclient
set DSM_LOG=C:\Program Files\Tivoli\TSM\baclient
REM 備份前置部驟，刪除硬碟中前兩次備份資料，另將上次備份資料轉移至 e:\mnt2
for /f "delims==" %%i In (e:\vmesx2.lst) do rmdir e:\mnt2\%%i /s/q
for /f "delims==" %%i In (e:\vmesx2.lst) do move e:\mnt1\%%i e:\mnt2\%%i
REM 執行 VCB 程序，開始備份 e:\vmesx2.lst 中所列出之 Guest Host 之 VMDK 檔至 e:\mnt1
for /f "delims==" %%i In (e:\vmesx2.lst) do call pre-command vcb %%i
REM 執行 TSM備份 程序，開始備份 e:\vmesx2.lst 中所列出之 Guest Host 於 e:\mnt1 中對應之目錄
for /f "delims==" %%i In (e:\vmesx2.lst) do dsmc incr e:\mnt1\%%i -subdir=yes
REM 檢查 TSM備份結果，導出至 e:\tsmlog\vcb_backup_esx02.log
for /f "delims==" %%i In (e:\vmesx2.lst) do dsmc q backup e:\mnt1\%%i\* >> e:\tsmlog\vcb_backup_esx02.log
vmesx2.lst之內容如下：
XXX01-FullVM
XYZ01-FullVM
ABC01-FullVM
使用 VMware Consolidated Backup Framework 的規則就是你要備份 Snap Shoot 的VMDK Image 時，給的 VM Name 必須要加上 -FullVM 的關鍵字，他就會自動轉換為對應的 VcbMounter 指令。
原本我這個 Job 是 Work 的，但在客戶端，我遇到問題了。
因為客戶隨時會把 VM 移來移去，或者換名字換 IP ，甚至原本己在 SAN Disk 裏面的 VMDK 檔在客戶移動後變成在 Local Disk ，造成了幾個問題如下：
1.可能是客戶換網段，換名字，造成 VMTOOLS 好像有點問題，使用 VCBVMNAME 都 Scan 不到該 VM ，這時可能要移除 VMTOOLS ，再重新安裝，讓VCBVNMAME 至少要看的到這個 VM 才能進行備份，記住，從 VC 上看的到該 VM 仍然是不足夠的。
2.因為客戶會將 VMDK 從 SAN 的 Disk 移到 Local 的 Disk，造成我原本己設定成 SAN Disk 備份的屬性己可備份結果又變成不能備，針對這點用 pre-command 就無法隨時變來變去了，我寫 Windows Batch 的技巧還沒這麼出神入化，最後我決定告訴客戶，在你這個隨時會變化的環境，可能必須要自己手動備份才有辦法。
唉....花了大把心力幫客戶完成的方案結果無法使用，不過還是公佈個大概給大家瞧瞧。其實這個作法應該是用別的備份軟體也能做，不限於 TSM 吧。反正就是先把 VMDK 檔備份下來，再由 TSM 備走而己。
2010年4月24日 星期六
第五回 某物流業資料庫備份問題
這次是今年發生的事，因為專案的關係，我們協助某物流業建立備份程序，在這個客戶環境中，存在了一個將近 100G 的 MYSQL 資料庫。
原本 100G 的資料庫，無論是 MS 的 SQL ，或 Oracle Database ,Sybase , Informix 都不會有什麼問題，但是因為他是 MYSQL ，所以有一些限制存在，偏偏在事前我們並不知道這個限制，問題就是在使用 mysqldump 備份時，如果 table engine 是屬於 defulat 的 MYISAM 模式的話，會造成 table 在備份的過程中，發生 table lock ，所以任何有關 update , delete , insert 的 DML 將無法執行，在備份的 Script 排程下去後的當天凌晨，該客戶的 MYSQL 資料庫就這樣被 Lock 了一個小時無法運作。
在問題發生了之後，我們試過了各種方法，無論是用硬體 做 Disk snap，或 Linux 的LVM snap，在客戶的環境下運作都還是有問題，最後只能依造 MYSQL 的做法，建立一台 Replication Server ，但是這仍然是有問題的。
最主要還是在 MYSQL 架構上，MYISAM 下並沒有交易的機制，每一個 DML 就是一個獨立的交易，無法 Rollback ，所以如果正常執行下，Replication 機制是運作的，但是只要 Disk Crash ，File system Crash ，Power Outage 發生時，造成 Master 或 Slave 中任一 Database 有資料損壞，就會發生一件事，兩端的資料會原本的一致，變成有落差，而且如何去判別這些落差，哪些是你要的或不需要的，抱歉，DBA或系統管理人員並不是開發人員，不知道你程式怎麼執行的前提下，無法取得哪些資料是你不要的資訊。假設 Master 因為任何原因資料損壞修復後，Slave 端就會多出一些資料，而多了哪些資料，除非你把兩邊資料庫停下來做比較，不然無法得知。如果客戶無法忍受 RTO 太長而需要儘快的將資料庫啟動的話，是無法完成這件事的。
那假設把資料表轉換成另外一種 Engine Innodb 的話，看起來好像事情可以得到解決，因為有了 Transaction 機制，MYSQL 會記錄每一筆交易到 LOG 檔中，亦會將這些交易跟 Replication 用的 bin log 同步，所以 Replication 端會去讀取所有的交易記錄，不過我還是發現了問題，就是如果這回輪到 Slave 端斷電的話，一樣會不同步，只是還原的方法就比上面簡單多了。問題發生的原因跟上述的原因一樣，只是這次是發生在 Slave 端。
但是無論如何，Master 應該都會比 Slave 重要，個人覺得重要的資料庫還是需要開啟 Innodb 的，只是這樣就失去 Mysql 又小速度又快的特性了，可能為了要維持資料庫本身的一致性，而拖垮資料庫系統的效能。
原本 100G 的資料庫，無論是 MS 的 SQL ，或 Oracle Database ,Sybase , Informix 都不會有什麼問題，但是因為他是 MYSQL ，所以有一些限制存在，偏偏在事前我們並不知道這個限制，問題就是在使用 mysqldump 備份時，如果 table engine 是屬於 defulat 的 MYISAM 模式的話，會造成 table 在備份的過程中，發生 table lock ，所以任何有關 update , delete , insert 的 DML 將無法執行，在備份的 Script 排程下去後的當天凌晨，該客戶的 MYSQL 資料庫就這樣被 Lock 了一個小時無法運作。
在問題發生了之後，我們試過了各種方法，無論是用硬體 做 Disk snap，或 Linux 的LVM snap，在客戶的環境下運作都還是有問題，最後只能依造 MYSQL 的做法，建立一台 Replication Server ，但是這仍然是有問題的。
最主要還是在 MYSQL 架構上，MYISAM 下並沒有交易的機制，每一個 DML 就是一個獨立的交易，無法 Rollback ，所以如果正常執行下，Replication 機制是運作的，但是只要 Disk Crash ，File system Crash ，Power Outage 發生時，造成 Master 或 Slave 中任一 Database 有資料損壞，就會發生一件事，兩端的資料會原本的一致，變成有落差，而且如何去判別這些落差，哪些是你要的或不需要的，抱歉，DBA或系統管理人員並不是開發人員，不知道你程式怎麼執行的前提下，無法取得哪些資料是你不要的資訊。假設 Master 因為任何原因資料損壞修復後，Slave 端就會多出一些資料，而多了哪些資料，除非你把兩邊資料庫停下來做比較，不然無法得知。如果客戶無法忍受 RTO 太長而需要儘快的將資料庫啟動的話，是無法完成這件事的。
那假設把資料表轉換成另外一種 Engine Innodb 的話，看起來好像事情可以得到解決，因為有了 Transaction 機制，MYSQL 會記錄每一筆交易到 LOG 檔中，亦會將這些交易跟 Replication 用的 bin log 同步，所以 Replication 端會去讀取所有的交易記錄，不過我還是發現了問題，就是如果這回輪到 Slave 端斷電的話，一樣會不同步，只是還原的方法就比上面簡單多了。問題發生的原因跟上述的原因一樣，只是這次是發生在 Slave 端。
但是無論如何，Master 應該都會比 Slave 重要，個人覺得重要的資料庫還是需要開啟 Innodb 的，只是這樣就失去 Mysql 又小速度又快的特性了，可能為了要維持資料庫本身的一致性，而拖垮資料庫系統的效能。
訂閱：
文章 (Atom)