IT運維無法躲避升級和遷移，但與此相關的問題也常令人頭痛不已。本文整理了部分典型問題和典型案例供大家參考。
一、遷移及升級典型問題
1.舊存儲設備性能、容量和穩定性都跟不上了，新存儲採購回來了，數據遷移如何做？
這種場景在我們的日常工作中遇到的比較多，非常具有代表性。不同的設備、環境及應用有着不同的應對方案。根據實施操作的對象來看，我們主要分以下三個場景來討論。
（1）.基於操作系統的角度，這裏主要是指利用操作系統本身的特性來做。比較典型的代表就是LVM（邏輯卷管理）。一般來講主要步驟如下：
A.新的存儲設備上架安裝，做好連線並加電測試。
B.在SAN交換機上做好存儲和主機的zone配置。
C.新存儲劃分同規格LUN映射給服務器。
D.服務器識別存儲端的lun。
E.利用LVM邏輯卷鏡像方式配置LV鏡像，並啓動同步。可根據業務負載，分批進行。
F.待LV同步完成並確認無誤後，刪除原存儲的鏡像。
G.將原存儲的lun從操作系統的vg中刪除，並刪除設備。
H.原存儲設備下線，完成遷移。
這種遷移方式的優點是，在線遷移，不需要停機窗口，而且直接使用系統內置的lvm功能即可，不需要額外的license費用，。缺點是受限於操作系統特性，如果操作系統不支持LVM特性，就無法採用了。
補充：如果存儲層面採用了類似的第三方存儲軟件產品，如VxVM、GPFS等產品，也可以支持這種遷移方案。
（2）.基於虛擬化平臺的角度。以VMware爲例。
A.新的存儲設備上架安裝，做好連線並加電測試。
B.在SAN交換機上做好存儲和主機的zone配置。
C. 新存儲劃分同規格LUN給到集羣中所有ESXI上。
D. 利用Vmotion和storage Vmotion執行虛擬機和存儲的遷移。
E. 待全部遷移完畢，並且穩定一段時間後，拆除舊存儲LUN。
這種遷移方式直接通過vmware來實現，遷移之前需要查詢官方文檔，檢查遷移的限制及版本之間的兼容性，並做好相關測試。
補充：這裏僅討論vmware平臺，PowerVM平臺的vios本質上就是aix，可以基於lvm來做。
（3）.基於應用軟件本身特性來做。這裏以oracle和db2爲例
Oracle-ASM方式：
配置ASM冗餘策略，利用ASM將新LUN加入到磁盤組的冗餘組當中。
待數據同步完畢，並且穩定一段時間後，拆除舊存儲。
重新配置ASM冗餘策略。
A.新的存儲設備上架安裝，做好連線並加電測試。
B.在SAN交換機上做好存儲和主機的zone配置。
C.新存儲劃分同規格LUN映射給服務器。
D.服務器識別存儲端的lun，並配置爲asmdisk或raw設備
E.將新的磁盤加入asmdiskgroup，再刪除原有的磁盤成員。
F.asm會自動同步，通過查看v$asm_operation可監控進度。
G.同步完成後即可將設備刪除，下線。
優點：可以在線做，不停止業務。
缺點：自動平衡，無法控制進度，一旦出現問題不好解決。
補充：oracle暫不支持asm冗餘類型的轉換，所以原生爲external模式的asm磁盤組不能使用鏡像的方式來做。
Oracle-other：
- 可以使用backupascopy的方式替換存儲，停機時間較短。
- 可以採用dg物理備庫的方式做。在線。
- 可以採用oraclegoldengate的方式來做。在線。
- 備份恢復或數據泵導入導出。停機時間長，取決於數據量。
DB2-storagegroup方式：
A.新的存儲設備上架安裝，做好連線並加電測試。
B.在SAN交換機上做好存儲和主機的zone配置。
C.新存儲劃分同規格LUN映射給服務器。
D.服務器識別存儲端的lun，配置對應的文件系統系統。
E.通過storagegroup增加刪除path的方式替換存儲。或者在新存儲的文件系統上創建新的storagegroup，通過更好storagegroup的方式更換存儲。
F.同步完成後即可將設備刪除，下線。
優點：在線遷移。
缺點：db2存儲組要求10.1或更高，需要設計好重平衡的時間。
補充：可以使用其他複製方案在線做，比如ogg、cdc、q複製等。也可以選擇db2move或者重定向恢復等方式，停機時間依據數據量大小而定。
（4）.基於存儲本身的角度來做。現在很多主流廠商的存儲設備都自帶存儲虛擬化網關功能，或者提供遷移向導。可以在線的將原有存儲數據遷移到新存儲，以ibmv7000舉例，執行如下步驟即可。
A. 新的v7000設備安裝上架加電測試
B. 將v7000加入san環境中，重新設計zone信息，原有的存儲和v7000做存儲zone，v7000和主機做hostzone
C. 原存儲的lun映射給v7000，v7000以image模式識別。
D. V7000將數據遷移到自身存儲。
E.遷移完畢後，取消原存儲的映射，原存儲下線即可。
優點：停機時間極短，更改zone映射等。對應用透明，上層改動小
缺點：需要存儲支持，需額外的license。
綜上，遷移的方法有很多，但對於用戶來說，具體情況具體分析。要選擇最適合自己的方式，而不是片面的追求新技術。另外，所有的實施操作之前一定要做好備份，做好備份，做好備份，重要的事情說三遍。
2.新購買的存儲無法兼容前端老舊系統，系統升級及遷移該如何設計規劃？
又一個典型的場景，明明設計好的數據遷移，結果因爲兼容性又帶來了升級問題。一般情況下，在進行設備更換類型的數據遷移時，需要提前對新設備的兼容性做好確認工作，以免遇到兼容性問題導致遷移失敗。一般的兼容性問題包含兩個方面：
（1）. 主機設備無法兼容新存儲，比如新採購的v7000存儲，主機還是最古老的rs6000小機。 就有可能遇到兼容性問題，或者雖然可以湊合使用，但是無法充分的發揮新設備的性能。這種情況其實還是建議升級前端主機的。
（2）. 主機設備上的操作系統無法兼容存儲，比如新存儲的多路徑或存儲代理等軟件需要較高的操作系統版本支持。這時就需要規劃操作系統的升級，以更好的滿足存儲的兼容要求。但是操作系統的升級又可能涉及到應用軟件的兼容性。需要做好通盤規劃。以免升級後，存儲可以使用了，應用出現了異常。
除此之外還有一些特殊情況，比如應用軟件已停止更新多年，只支持非常古老的系統，但更新的硬件設備又無法安裝老系統。這時可以考慮通過虛擬化的方式實現。對於x86環境，可以使用vmware虛擬化，並做p2v遷移。對於Power平臺，aix7.1支持versioned wpar功能，支持將5.2的aix遷移到7.1的wpar裏面。這樣就可以解決舊版操作系統和新設備之間的兼容性問題了。
3.上層應用升級更新後，新版應用不支持原來版本的數據庫，如何規劃升級？
一般整個業務系統的構成包含很多層面，從底層的存儲系統、san網絡、上層的主機、數據庫、中間件等等都又涉及。有的時候看似簡單的上層應用升級，卻可以牽涉出大量的兼容性問題。比如新版本的應用對jdk的版本有要求，現有的application server又不支持新版的jdk。升級了新版中間件後呢，發現中間件和數據庫的兼容性又有待確認。
這種升級場景實際上就是由上層應用倒逼的被動式升級了，已經到了不得不做的地步了。這種類型的升級還是建議按照傳統模式的來，涉及應用的兼容性，其他需要做好測試和規劃，一般包含如下步驟：
（1）在新的設備搭建一套新的環境，包括數據庫、應用服務器。
（2）在新的環境中導入測試數據，前端從業務層進行相關可用性驗證
（3）進行數據被備份遷入到測試環境的相關數據遷移時間實測評估
（4）進行數據庫系統的升級測試，測試後再次進行應用驗證
（5）停止生產系統的應用系統進行數據庫升級，一般選擇的停止窗口在業務低峯期，由於前期準備活動充分，基本系統停機時間約等於數據庫升級時間。
（6）升級完成後進行應用層面的驗證。
需要注意的是，升級之前一定做好數據備份並驗證。準備好回退機制。
4.採購的新服務器設備不支持舊版操作系統，但因爲停止更新的應用僅支持舊版os，應用遷移如何規劃？
硬件產品對軟件的支持都有兼容性要求，尤其是服務器產品。比如新採購的x86服務器，想再安裝windows 2003或者windows 2000就比較困難了。但是因爲應用的限制，又不能支持新版的操作系統。目前，虛擬化的架構應該是解決這種問題的一個很好的手段，而且技術成熟。維護簡便，風險小。通過虛擬化平臺的p2v遷移功能，可以將整個應用系統連同操作系統一起遷移到虛擬化平臺上。
對於x86平臺來說，vmware佔據了大部分的企業級虛擬化市場份額。vmware虛擬化環境支持大多數主流操作系統，通過實施基於vmware的p2v遷移，我們可以原來的應用和操作系統一起遷移到虛擬化平臺。並通過虛擬化平臺做虛擬機級別的保護，使得應用同時得到性能和穩定性的收益。
至於Power平臺，對於早期舊版本的aix系統，通過使用aix7.1內置的versioned wpar功能，可以將aix5.2/5.3版本的aix遷移到最新的Power8處理器平臺，被遷移的aix版本最早支持到aix5.2 sp8。
但從長遠來看，這終究這是一種治標不治本的手段。隨着後續硬件的發展更新，將會拖着虛擬化的平臺一起升級。最終可能還是會出現兼容的問題。根本的解決辦法，還是在信息化上持續的投入，即使不保持實時系統最新，也儘量不要讓軟件和應用的的版本太落後。總的來說，升級是大勢所趨。無論當下有怎樣的困難，拖到最後也難免升級的命運。
5.原有的備份軟件Network備份在帶庫的數據，如何遷移到新的、其他備份軟件中，如TSM？
這種情況因爲涉及到兩種備份架構的變更，所以還是比較麻煩的，一般來講有如下兩種實現方式：
（1）. 直接部署tsm環境，備份數據到新tsm系統。同時老的networker環境也不要刪除，同時共存，只是將networker的備份調度都停了。等老network環境裏的數據過期後，老磁帶可以直接拿到新tsm環境中打標重用。
（2）. 利用 IBM Butterfly軟件，直接遷移數據到新環境中。這個是ibm的一個服務，感興趣可以找ibm諮詢下。
6.單臺存儲設備有必要升級爲雙活嗎？升級之後會不會影響到讀寫性能呢？
目前是單臺V7000設備，出於安全考慮有了增加一臺V7000做成雙活的想法，請問升級之後會不會影響到讀寫性能。
關於是否要升級爲雙存儲，主要是看自己的實際情況，如果對可用性有嚴苛的要求，肯定需要從架構上補齊短板，雙存儲確是可用增加可靠性。具體到存儲高可用如何做呢，有兩種實現方式：
（1）.可以基於主機做，如lvm mirror，基於主機lvm做的話還是需要調整一些東西的。以aix接雙存儲爲例：
a. 創建vg的時候quorum應該爲no
b. 硬盤hdisk的rw_timeout（每個讀寫操作超時的時長）和（發現丟包後多長時間通知主機的時長）參數的調整。
c. fscsix光纖卡設備的fc_err_recov參數，建議改爲fast_fail默認爲delay_fail ,故障時，可減少重路由時間
d. lv的讀寫策略，建議爲chlv -d psxxxlv 即寫所有，從主讀取，保證讀取速度
（2）.可以基於存儲做，如vdm，在使用中實際是單讀雙寫，性能會略有一點延遲，但不會太大。可以用工具壓一下對比看看，如iorate工具，或者是oracle的orion工具。
二、升級和遷移案例分享
案例一：一次失敗的aix系統升級以及挽救過程
原本是特別簡單的一個case，數據庫出現故障，經過數據庫工程師分析是ibmaix的一個系統bug，需要升級aix補丁。
原計劃的操作流程如下：
1. rootvg 拆鏡像
2. 磁盤克隆（備份用，想着如果出了問題可以回退）
3. 升級aix，重啓
4. 數據庫啓動並驗證。
實際執行過程如下：
1. rootvg拆鏡像，成功
2. 磁盤克隆，失敗了。源盤出現了壞快，且無法修復，目標盤的克隆當然也就失敗了。因爲大意，系統還沒備份。rootvg中主要安裝了操作系統，安裝了oracle數據庫軟件，其他的內容都在存儲盤。
3. 萬般無奈，重裝aix，裝在了好盤上，後來又調了一塊盤做了鏡像。重裝了oracle數據庫軟件。
4. $ORACLE_BASE/admin/ORACLE_SID/ 目錄下創建a/b/c/d/udump及pfile6個文件夾
5. $ORACLE/HOME/dbs目錄下創建initSID.ora 內容爲： spfile='/database/oradata/SID/spfile
6. 通過strings命令讀取spfile和controlfile內容，檢查數據文件、日誌文件等路徑。
7. 確認無誤後啓動數據庫，最後有驚無險，把業務拉起來了。
教訓：
重大操作前，一定要細緻規劃做好備份，有條件還要對備份進行驗證。提前預估好維護時間窗口。
案例二：目錄滿了導致數據庫升級hang住
一日，核心系統升級，幾個點了升級腳本，開始等待。一般oracle數據庫升級，也就增加一些字段，升級一些存儲過程啥的，二十分鐘左右。但是過了半小時還沒好，已經到應急時間了，還有一小時不到就要拉起系統交易了。一邊準備替代方案，一邊開始找原因。
1、查找升級目錄下log，沒有看出什麼
2、遠程登錄數據庫，發現登陸不了，超時
3、登錄數據庫操作系統，發現登錄慢，登錄 top下發現CPU，內存有點高但也只oracle幾個自己進程
4、df一看我看歸檔日誌滿了，趕快清理下目錄，清理完後沒幾分鐘，升級完成，編譯一下，檢查系統一切正常
教訓總結：
1、升級中麻痹大意，沒有及時注意情況；
2、升級前沒有及時關注目錄使用率，導致後面出了狀況；
建議：
1、再熟悉的事也要當心，做好應急；
2、做事時要認真一點；
3、升級oracle比如跑的腳本內容過多，可以關閉歸檔（假如開了的話），升級完成無誤後要立馬開歸檔，再full backup下
案例三：一次無意的記錄會話，挽救了我們自己
那是幾年前，一月的一天我和兩個同事給某電視臺下屬企業做aix系統升級,從5.2升級到5.3。
升級前：
做了數據庫10.2.0.5（前期從10.2.0.4升級過來）、系統等各種備份，操作流程、應急預案也審查了幾回，一切沒問題。
升級中：
一切都很順利。注意升級前升預升級，等跑了沒事再commit。
有存儲的，注意要不要升級多路徑軟件，尤其是aix大版本升級。
有數據庫的，也要看看要升級的版本和現在的數據庫版本有沒有BUG、性能缺陷之類的。
升級後：
出事了，應用、開發、系統、數據庫、網絡、客服中心聯測系統正常，準備收工走人。這時客戶一運維經理說，你們把系統中之前備份的數據、老舊沒有用清理一下。客戶有要求，那還能說不嗎，幹唄。正好，同事之前傳補丁的ftp程序還在，就刪吧，當時心想，圖形化有點危險的啊，應該沒事。
刪着刪着同事說：不好了，有個重要的配置文件被刪了。 沒過幾分鐘，客戶那就有部門反應生產系統刷不了數據，查看不了產品了。
那就恢復唄，要命的是恢復不了了。
1、smittymksysb備了系統，沒備這個目錄，恢復不了
2、其他地方還有備份不，沒有
3、配置文件內容設置很多，有些老應用好多年經歷了好多人，有的已經離職了，現在的人客戶經理不敢保證100% 恢復
4、早晨6:00客服中心就要開始上線了，一旦出問題，會影響當天生產。
突然，我想起開始做之前，我上去做升級前檢查好像cat了這個文件，還問了客戶相關問題。趕快退出SecureCRT，查看保存的日誌（因爲我有個習慣，喜歡記錄會話，方便寫文檔和回溯）。新建配置文件，把日誌中之前cat的內容拷貝到創建的文件中，改好屬性、權限。之後，重啓應用，聯測正常。
教訓：
1、圖形化用之慎之；
2、還是做好全面備份，不放過任何死角；
3、留痕很重要，有時能“救命”；
4、溝通很重要，和客戶溝通足夠透徹，因爲客戶的系統客戶最熟悉
三、總結
經過上面典型問題的討論以及相關案例的思考，關於升級和遷移了梳理以下幾點：
1.不管升級還是遷移，規劃很重要。
2.遷移的方式有很多種，適合自己的纔是最好的。原則就是選擇對業務系統影響最小的、變更最少的。優先推薦在線遷移。
3.升級操作一定要做好充分的測試。
4.一定要有備份，並且保證可恢復。
5.預留足夠的操作窗口，包括回退機制。
6.必須要有實施計劃，並保存所有的操作記錄。