1.前言

        將線下伺服器系統整體搬遷上雲是上雲客戶的一個常見需求。對於1-10臺少量級伺服器的遷移需求有很多上雲方案可以應對，然而上百臺量級伺服器的遷移上雲就是一個沒那麼簡單的工程問題。本文記錄了某平臺客戶使用遷雲工具將500臺伺服器系統批量遷移上阿里雲公有云平臺的案例，希望能給有類似需求的客戶提供一些批量遷雲方案作參考。

2.案例背景

        2018年6月，遷雲需求群裡有業務同學來諮詢，上來就開門見山：某客戶線下雲平臺需要整體遷移到阿里雲公有云平臺，有將近500臺伺服器系統需要遷移，因為數量大、應用多，重新部署的方式太麻煩基本不考慮，看有沒有其他的思路。繼續從業務同學那兒瞭解得知，包含這些需求：

        1.這些系統80%以上是虛擬機器，其餘是物理機，所以需要同時支援P2V和V2V場景；

        2.這些系統版本絕大部分是Linux，還有少量的Windows Server，都需要能遷移；

        3.希望能以製作映象的方式遷移，等需要用的時候再建立例項即可。

        而這些需求，剛好都在遷雲工具的功能支援之列。於是我們還是向業務同學推薦了使用遷雲工具的方案。

3.初次遷雲演練

        無論使用什麼遷移工具或方案進行系統遷移工作，提前進行基本的遷移演練是必不可少的過程。

        於是業務同學馬上聯絡了客戶，參照遷雲工具幫助文件快速熟悉了一下基本的使用方法之後，找了臺測試系統就開始上手做遷雲測試：

        1.先下載遷雲工具到待遷移系統；

        2.再簡單配置一下遷移源和目標映象資訊；

        3.然後執行遷雲工具等待即可。

        結果10分鐘左右就將一個帶資料盤的CentOS系統遷移到ECS公有云平臺生成了映象。接著使用該映象建立了一個按量例項，啟動後驗證了一下整體系統應用服務，結果基本正常，測試流程初步通過。

        對這個測試結果客戶表示基本滿足需求，同時希望儘快展開遷移任務。

4.批量遷雲實戰

        1臺系統的遷移還好說，然而對於500臺這麼大批量的系統，如何更加方便的遷移上雲呢？來看看客戶實際上是怎麼做的。

4.1.自動化批量運維工具

        一般來說，對於大批量的伺服器系統，都會配備自動化運維工具來統一管理。客戶的批量系統管理場景裡面，用的自動化運維工具是比較常用的Ansible。先簡單介紹一下：

        Ansible是一種很強大的自動化運維工具，實現了批量系統配置、批量程式部署、批量執行命令等功能。使用Ansible可以很方便的完成一些需要重複操作的工作，比如：向100臺伺服器拷貝同一個檔案，或者同時在100臺伺服器上安裝Apache服務並啟動。

        對於這次批量遷移任務，也可以使用類似Ansible這樣自動化批量運維工具來做。

4.2.遷雲工具命令列呼叫

        自動化運維工具的一個常用功能就是可以批量下發並執行指令碼，所以只要被執行的工具能夠支援在命令列中呼叫，理論上都能被批量的執行。

        而遷雲工具本身就是一個輕量綠色的客戶端工具程式，無需安裝或複雜配置即可使用。同時遷雲工具提供一系列的命令列引數，專為命令列呼叫場景做了很多支援。

        比如：–noenterkey 禁用互動，–nocheckversion 禁用提示版本更新，–progressfile 設定進度日誌檔案可以方便跟蹤等。

4.3.批量遷移任務指令碼

        瞭解了Ansible的功能之後，我們就知道用它來批量下發遷雲工具和執行遷移任務是很合適的。

        客戶根據實際遷移任務需要編寫了自動化批量遷移任務指令碼，主要做了以下幾個工作：

        1.批量下發遷雲工具到待遷移伺服器；

        2.批量配置遷雲工具，如目標映象名等資訊；

        3.批量執行遷雲工具，同時獲取遷移任務結果。

以下是相關指令碼示例：

#首先向所有伺服器傳送遷雲工具程式

ansible -f 6 -i host.file all -m copy -a "src=go2aliyun_client1.2.9.1_linux_x86_64.zip dest=/temp"

#然後解壓縮程式

ansible -f 6 -i host.file all -m shell -a "cd /temp && unzip go2aliyun_client1.2.9.1_linux_x86_64.zip"

 

#再執行修改配置檔案指令碼

ansible -f 6 -i host.file all -m shell -a "cd /temp/go2aliyun_client1.2.9.1_linux_x86_64 && ./config.sh"

sleep 120

# 配置檔案指令碼./config.sh工作是配置目標映象名，主要根據子網IP來配置。（其他配置如AK，區域、磁碟資訊等都是一致已配置好的）

#!/bin/bash

image_name=`ip a | grep inet | grep eth0 | grep brd | awk `{print $2}` | awk -F `/` `{print $1}`| awk -F `.` `{print "move_"$1"_"$2"_"$3"_"$4}``

sed -i "s/IMAGE_NANE/${image_name}/" user_config.json

 

#最後執行遷移腳，同時執行併發量是6個

ansible -f 6 -i host.file all -m shell -a "cd /temp/go2aliyun_client1.2.9.1_linux_x86_64 && chmod +x go2aliyun_client &&./go2aliyun_client --nocheckversion --noenterkey"

 

#獲取遷雲結果，從client_data中獲取生成的映象Id以及完成狀態

#判斷client_data裡的status自帶，如果是Finished則表示遷雲完成，同時image_id欄位就是最終生成的映象Id。

4.4.ECS資源額度申請

        批量遷移過程中需要建立對應數量的ECS資源，可能會超過使用者預設的ECS資源存量額度（Quota）上限，因此可以提前向阿里雲提出提高以下資源額度上限申請：

• 按量收費的ECS例項vCPU額度；
• 自定義映象額度。

4.5.初步遷雲實戰效果

        準備就緒之後，客戶就開始進行首批批量遷移任務。結果也比較順利，白天幾個小時陸陸續續遷移了近100臺系統。客戶側專門提供了200M的寬頻來做遷移，一臺資料量4GB左右的系統從資料傳輸到打快照製作映象平均15分鐘以內就能完成：

        初戰告捷，客戶有了更多的信心，準備加大遷移佇列，開始進行後續批次的遷移任務。

5.批量遷移過快引發的“血案”

        正所謂車技再厲害，也怕出意外。大批量遷雲肯定不會那麼的一帆風順，一些特殊情況可能會干擾正常遷雲的進行。這次批量遷移過程中也遇到了一個突然的問題考驗。

5.1.發現問題

        客戶第二批次遷移開始沒多久，遷雲移資料後臺開始報了大片遷移異常通知。看錯誤原因，發現都是一樣的訪問遷雲服務網路異常中斷導致遷雲失敗。排查遷雲服務端服務一切正常，但是客戶側telnet測試服務還是反覆報Connection closed by foreign host的錯誤。通過在阿里雲側和客戶側抓包發現兩側都收到了reset訊號，看不出來是哪邊的問題。因為客戶側IP和服務埠可以說是固定的，就有兩個懷疑：

        A.客戶側IP或服務埠被客戶側網路運營商出口限制了；

        B.或者被阿里雲側網路入口限制了；

5.2.排查問題

        在確認了遷雲服務端服務本身是正常的情況下，先讓客戶確認本地網路防火牆有無出口限制，反饋沒有；檢視阿里雲控制檯雲盾也沒有異常攔截記錄；同時也向阿里雲側網路同學諮詢有無網路入口方面的限制，反饋也沒有。接著也向客戶資料中心運營商確認了各層網路鏈路沒有IP或埠記錄或防火牆之類的限制。

        最後找到阿里雲側網路安全的同學諮詢，給出初步判斷可能是DDoS之類的攔截。安全同學跟進排查不久，就發現了跟客戶IP相關的攔截記錄，不過不是DDoS攔截。原因是客戶這次大批量遷移的過程中，批量遷移動態的建立和釋放了一定數量的中轉例項，又因為遷移速度很快，一般只有10多分鐘，中轉例項的生命週期很短，湊巧觸發了耿直的網路安全策略。這其實是一種“誤判”，批量遷移操作和遷雲工具都是沒有問題的。

5.3.解決問題

        這個問題可以說是因遷移速度過快而差點引發的“血案”，這是在眾多遷雲案例裡面第一次遇到的，結果也在掌控之中。雖然不是遷雲工具本身的原因，但卻是一次有意義的經驗教訓。

        安全同學在解除了對該客戶的相關攔截限制之後，客戶側網路異常問題就得到了徹底的解決，遷移任務又可以進行下去了，無論速度多快、彎道再多也不用擔心會翻車了。

        後來的遷移就一直順風順水沒出過問題了，在客戶側200M寬頻的加持下，遷雲工具跑得十分賣力而平穩。從問題當天中午得到解決到後面兩天時間就把剩下的200臺系統遷移完成，客戶的500臺伺服器系統已經如期全部遷移完成。

6.批量建立例項

        500臺伺服器批量遷移上雲之後，首先得到的是對應數量的自定義映象。客戶後續還要將這些映象建立成例項，同時有以下需求：

        1.建立按量收費的例項來做驗證，驗證完成後再升為包年包月的；

        2.保留跟原來系統相同的子網IP，因為涉及原業務相關；

        3.建立例項去購買頁面一個個操作是不可能的，需要有工具呼叫來做。

        這裡提供一個方案，就是可以使用阿里雲命令列工具呼叫OpenAPI配合指令碼來批量建立。

      阿里雲命令列工具是專為阿里雲OpenAPI打造的、用於管理阿里雲資源的工具。它可以呼叫OpenAPI來建立例項。主要步驟如下：

        1.下載阿里雲命令列工具並配置Access Id和Secret Key；

        2.呼叫建立例項的OpenAPI引數請參考CreateInstance文件說明。假設建立例項的目標區域是cn-qingdao，映象Id是m-xxxxxxxxx， VSwitch是vsw-xxxxxxx，子網IP是10.0.0.10，例項規格是ecs.n1.samll，呼叫如下即可：

        aliyun ecs CreateInstance --RegionId `cn-qingdao` --ImageId `m-xxxxxxxxx` --VSWitchId `vsw-xxxxxxx` --PrivateIP `10.0.0.10` --InstanceType `ecs.n1.samll`

        3.將遷雲工具所生成的映象Id資訊和對應的子網IP等資訊做成配置，然後編寫指令碼呼叫命令列工具來自動讀取進行批量執行建立例項。

        另外，批量例項建立並啟動之後，如果需要進行批量管理和配置，可以使用阿里雲自動化批量運維工具“雲助手”來做。

7.後記

        近期客戶開始進行批量建立例項並進行業務聯調，目前結果是：近500個伺服器映象已經全部建立例項並正常啟動，業務聯調良好。目前來看，客戶使用遷雲工具進行批量遷雲已經基本達到了當初的需求預期。因為使用了遷雲工具，也讓本次遷雲過程節省了很多人力物力時間成本。期間雖然也遇到一些問題，但跟總體遷雲結果對比看也是很值得的。

        隨著越來越多客戶的使用，遷雲工具一直在積累各種遷雲案例經驗。我們有遷雲資料表明，使用遷雲工具再配合我們遷雲服務支援，讓伺服器遷移上雲的成功率可以達到95%以上。如果有遷移上雲需求，歡迎聯絡諮詢我們，我們是專注致力於讓客戶更方便快捷地上雲的阿里雲ECS映象系統團隊。

                         上雲就上阿里雲！

 

 

遷雲實踐系列：

阿里雲遷雲工具最佳實踐指南

阿里雲遷雲工具遷移方案總結