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 下來，真的是不便宜，所以要在大蘋果生活還真的是不容易呢...。
2010年7月30日 星期五
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 要高。
訂閱：
文章 (Atom)