聽我在放屁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。

第八回 某外商公司的備份還原演練

小弟公司服務的範圍其實相當廣，還包含了異地異機還原演練這種服務，記得去年接了一家外商公司的 Case ，就是將該公司平常一直在外送的備援磁帶做還原演練。

理想值是這樣的，該公司每天都會將公司重要主機的備份再另行複製一份透過快遞送到異地的保險箱，隔天再去取回來使用，總共有三組這種磁帶在輪替，輪替的時間可能己經兩年多了，從未有過演練。

這次我們將磁帶一拿到後，就先回復備份用主機之資料庫，因為備援中心的同事將資料庫倒回來後，一直覺得有問題請我過去支援，我檢查了一下後發現有些怪怪的地方後就跟客戶連絡，我想去直接看目前備份用的系統主機做檢察，這才發現一件事。

原有的備份系統可能大約在上線一年半後，就己經發生放置 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的。

第六回 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 備走而己。

第五回 某物流業資料庫備份問題

這次是今年發生的事，因為專案的關係，我們協助某物流業建立備份程序，在這個客戶環境中，存在了一個將近 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 又小速度又快的特性了，可能為了要維持資料庫本身的一致性，而拖垮資料庫系統的效能。