小弟公司服務的範圍其實相當廣，還包含了異地異機還原演練這種服務，記得去年接了一家外商公司的 Case ，就是將該公司平常一直在外送的備援磁帶做還原演練。
理想值是這樣的，該公司每天都會將公司重要主機的備份再另行複製一份透過快遞送到異地的保險箱，隔天再去取回來使用，總共有三組這種磁帶在輪替，輪替的時間可能己經兩年多了，從未有過演練。
這次我們將磁帶一拿到後，就先回復備份用主機之資料庫，因為備援中心的同事將資料庫倒回來後，一直覺得有問題請我過去支援，我檢查了一下後發現有些怪怪的地方後就跟客戶連絡，我想去直接看目前備份用的系統主機做檢察，這才發現一件事。
原有的備份系統可能大約在上線一年半後，就己經發生放置 Copy 帶子的空間不足的問題，而因為原廠商設定的方法並沒去檢核每個步驟，造成每天備份的 Report 都是成功的，一直到我發現。雖然客戶還是一直質疑我說明明每天的 Report 都說備份是成功的，為何我說是失敗的呢? 只好開了一個會說明目前備份的內容和架構，並列出正常 Pool 和 Copy Pool 的備份空間並不同，客戶才相信我的說法。
所以意思就是說，其實己經不知道有多久時間了，每天從磁帶機拿出來請快遞送走，鎖到銀行保險箱的磁帶都是空的。我將客戶的現有備份系統備份的 Script 稍作了一些修改，並調整了帶子的數量，重新再執行了一次磁帶 Copy ，因為己許久沒執行過，這次執行可能會稍久，我看了程序有在跑就先離開了。
直到第二天確認完成後，磁帶再度送到驗證中心去，這次就確定內容物是有資料的，可以開始做還原演練了。
最後要提醒各位人客啊，備份不是備完了送走就好了，平常定時要演練一下啊，快遞公司和銀行應該感謝你們，白白給了他們每天送幾捲空白磁帶保存和運送的這筆生意機會。所以挨踢人這次又救了一家公司，如果等到哪天他們機房出了什麼事後才發現送到異地的磁帶是空白的不知老闆會有什麼表情。
2010年5月31日 星期一
第七回 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 備走而己。
訂閱：
文章 (Atom)