在 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月10日 星期二
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 要高。
訂閱：
文章 (Atom)