第十一回 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 下來，真的是不便宜，所以要在大蘋果生活還真的是不容易呢...。

聽我在放屁 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 環境，不過這就未實際參與建置。

當然以上所言，隨著科技的進步，一定會有成熟的一天，所以目前只能說就產品而言，仍然還是不成熟的。

第十回 我是系統工程師，我不是劉謙....

上週五時和另一台同事去某外商銀行操作設定 AS/400 在 Tivoli Storage Server 上的備份，在我完成沒多久後，我去檢查客戶目前 TSM 的備份狀況，結果發現客戶的磁帶機終於在上線一年多後，兩個 Driver 都己經髒了，無法再讀取和寫入任何一捲磁帶的資料，因此日常的備份己經五、六天沒備份了。這個問題我己經在幾個月前就提出警告，但是客戶都沒有處理，一直到今天。

因為Driver 髒了也不是什麼大不了的事，就放清潔帶進去清潔就好了，我馬上回報客戶，這時他才跑去問機房人員，機房的人說其實他們一直都有清潔帶，只是沒人問過而己，馬上就幫我放進磁帶館中，讓我準備設定。

誰知上週大概是全省各大銀行年中的稽核，很多銀行這時都有稽核人員會來，沒提出需求申請，就算我再急也不能連線進去設定，因此從約 17:30起，我就一直在等客戶申請，一直到19:00了還沒下文，這時我己經想離開了。

但是客戶說沒有弄好不是未來備份還是有問題，所以不讓我走，我的媽啊，有問題不讓我做事，也不讓我走，那是怎樣，要我變魔術讓大家見證奇跡發生嗎? 我又不是劉謙。 而且 IT 只會有靈異事件，從來不會有發生見證奇跡的時刻發生。

我只好說那你們申請那個單子可以直接讓我進機房嗎? 我不要連線 Console ，以免到時有問題，我又得說要進機房去看那台設備，你們又要再提一次申請單，起先客戶還一直有疑慮看起來好像不太肯讓我進去，說那個機櫃有多重要多重要，後來想了半天才去申請單上更改，重新找到相關人員簽名後，我終於可以開工了。不過有趣的是，我在機房的這段時間，根本就沒人陪我，那這麼龜毛的 Security 到底是搞什麼鬼，堅持了半天還不是放我一個人在裏面亂搞。

等到整個搞定己經快 21:00 了，不過是清個磁帶，20分鐘就能搞定，在這裏要一等再等，搞到人快抓狂。我看我還是來去學特異功能，看哪天能不能練成用念力控制電腦算了。

第九回 不用錢的最貴，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 要高。

聽我在放屁CASE 1 公司大小間，廠商絕對是給你大小眼

本篇不會說公司的抬頭，所以不用去猜測什麼....

公司大間小間買東西有沒有差，當然絕對有差，舉例來說....

國內的幾家龍頭指標公司，不用說哪家，只要是龍頭一定都很大，他們買機器其實可能都可以不用簽維護，砍的 discount 也可能比誰都深。為什麼呢? 因為是指標型的大客戶，死都得賣進去，絕對不能給敵對廠商有踩進去的機會。

所以嘍，在大型計算機市場其實是沒什麼市場價，公定價，和原則了，同一台機器，價錢可以差十幾倍，買了也不一定會簽維護，不簽，那過保後怎麼辦，放心.....我是指標型的大客戶，你說沒維護不來修是不是，好，OK，我明天找別家來，統統給你換掉，反正上面的應用程式都有廠商會想辦法，我才不管複不複雜，要花多少時間，明天市場上就會知道，某大型系統供應商在哪家客戶那被踢掉了，看你屌的起來屌不起來，天啊，多沒面子，搞不好業務還得走路，為什麼沒顧好。所以這種客戶忠誠度當然高，因為沒人踩的進去。

那同樣一台機器，我不是指標型客戶，可能年營業額不過幾千萬到幾億(這樣好像也很大嘛!!)，但是過保後機器壞掉，打電話報修，抱歉你這個沒有維護合約喔；沒維護，那per call 可以嗎? 可以啊，不過請線上簽約，匯款或刷卡付錢，馬上就有專人幫你處理，，好不容易刷了個幾萬塊過去，錢也給了，等了很久，生產線都停擺了，訂單也沒辦法敲，一直沒回應，好不容易來了通電話，那個對不起，今天派不出工，可能要明天喔，另外依照你目前的狀況，可能需要更換的料件要待料一週喔.......。

什麼.... 一週.....，這擺明就是要逞罰你不簽維護不是嗎? 可是庫房裏有沒有那個零件...我想在台灣一定有，就算台灣沒有，香港也有，日本也有，坐飛機二個小時就到了，但是你是 Per call ，你又不是維護客戶，也不是指標型客戶，什麼，你說你付了錢了，你刷那幾萬塊付機票錢都不夠，更何況零件費哩，而且我也打了電話告訴你處理的方式和時間了不是嗎。所以就慢慢等吧，你的ERP系統停擺，這個我也沒辦法，我們台灣庫房一線的零件都是為了有維護的客戶留的，不能為你 Per Call 的客戶維修供應喔。而且合約上只有說明多久內要回覆，沒有說多久內要處理完畢不是嗎? 我己經盡了合約上的義務了哦。

不過啊，上面那個定律也有不對的時候啊，當你的公司是被認定的指標型客戶時，有時也會被當肥羊宰殺的啊。同樣可能還是得看採購人員的能力和挑廠商的眼力嘍，不過也有可能跟某個東西的多寡有關係，這個就不能多說了。我只是小小工程師，那些事絕對不是我能介入的。

說真的，這個市場也是弱肉強食，上面那種情況啊，看過好多次了，也不知該說什麼，只能說做一行怨一行，離開一個坑，只是跳進另一個坑而己嘍。

小插曲 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 儲存設備移除後再重新安裝

小插曲 NBU 的有趣行為

在某人壽安裝 TS3100 的 Expansion時，客戶有要求要測試新機的速度，要做測試報告，因為之前第一個 System Draw 上面安裝的都是 LTO3，後來新機裝的是 LTO4，所以要測試，安裝了 Exp 和新的磁帶機之後， NBU 的廠商有前來將 Driver 設定進 NBU 之中，而我們在測試磁帶機時是使用標準的 OS 指令去操作，結果發生了一件事。

新的磁帶機在我們操作測試時，無論執行 tar 或 tapecopy 的操作狀況下，會不定時的莫明奇妙就掛點，測了好幾次都一樣，一直到後來我們才知道 NBU 在定時去 Polling 自己受管理的磁帶機，所以其他 Process 的操作會莫明的被中斷掉。

另外那個 Expansion 可不是好裝的，建議有機會安裝時要將整個機械手臂模組整組拿出來再重新置入，因為經常會前後齒輪定位差一格 (肉眼看不太出來) 造成手臂一直跑來跑去之後就吐 Error。