關於作者
孫琦，萬博智雲CTO(萬國數據(NASDAQ:GDS)合資子公司)，阿里雲解決方案領域MVP，Ceph中國社區聯合創始人，AWS Certified DevOps Professional。曾先後就職億陽信通、摩托羅拉、瞬聯軟件等國內外知名企業。2013年開始創業，從事私有云領域研發工作，2016年帶領團隊開發雲原生遷移產品HyperMotion，該產品在江蘇農信、國家電網、海通證券等諸多項目得到廣泛應用。2018年成功組織Ceph全球首次峰會，並幫助多家國內知名企業加入Linux Foundation旗下的Ceph基金會。
關於萬博智雲
萬博智雲信息科技（上海）有限公司成立於上海，是國內領先的雲技術和數字化架構服務商。萬博智雲專注於為企業提供中立/專業的雲諮詢、雲產品、雲服務；致力成為企業 IT運營、數字化發展可信耐的雲服務商。公司秉持以產品驅動服務，以科技提升企業商業價值的理念，持續提供豐富的雲化產品、解決方案、專業諮詢服務，並聯合生態體系助力企業在數字化時代全速發展。
萬博智雲核心研發團隊組建於2013年5月，2013年到2016年期間團隊致力於開發基於OpenStack私有云產品，2016年後團隊轉型全力開發雲市場細分領域產品——雲遷移。2017年完成了沭陽農商行私有云平臺建設及業務系統上雲項目，該項目獲得銀監會四類科技成果獎，第二屆優秀雲計算開源案例二等獎；2018年完成江蘇農信省聯社專有云平臺建設，同時利用雲遷移產品完成1200多套業務系統批量上雲，該項目獲得銀監會二類科技成果獎，第三屆優秀雲計算開源案例二等獎；同年，完成國家電網27個省近20000臺VMware虛擬機批量上雲遷移；2019年完成海通證券雲管平臺與雲遷移產品整合，該項目也是國內首個將雲管平臺整合到雲管平臺提供自助式遷移服務的項目；2020年完成前海股權VMware虛擬機批量遷移至阿里雲項目。
結緣雲遷移
2011年開始，我一直從事OpenStack在企業私有云應用的研發工作。從2011年一直到2018年，是開源社區最為活躍的時間段，各個公司將自己的主要精力全部投入到OpenStack各個模塊的優化中。當時建設私有云平臺所提供的服務往往是全方位的，從系統集成、安裝實施再到後面的運行維護和定製化開發，基本上就是一整套全棧式解決方案，甚至有時候雲平臺之上的業務系統出問題，客戶也會來找你。這對於任何尚處於初創型規模的OpenStack公司往往是個巨大的挑戰。
2016年的時候，我們為一家農商行客戶建設私有云，經過反覆的前期驗證，最終在2016年底拿下了該項目。當時除了建設雲平臺的需求外，還有一項作為驗收標準的需求是將用戶原有運行在各種物理機的業務系統平穩的遷移到新的雲平臺上，遷移過程不能對現有業務產生任何影響。最後還要將舊的硬件進行必要升級後，重新加入到新的雲平臺。
回想起當時雲平臺的建設過程，架構上並不複雜，就是一個典型的OpenStack使用硬件存儲再加上VLAN的簡單模式。在實際的項目實施中，從硬件到貨到上架安裝，再到雲平臺部署完成，前前後後的時間大約在三週左右。但是由於用戶對於熱遷移和資源回收的需求，整個項目實際耗時竟然長達半年之久。由於客戶所處的位置不直通高鐵，我們的工程師從北京出發，要不就是坐一夜的綠皮火車，要不就先高鐵到徐州再轉長途車的方式。無論哪種方式，路上的時間至少要8個小時以上。從方案驗證到最終實施完畢，團隊內全體成員總共出差次數超過50次以上，最終的實施成本極高。當我們嘗試覆盤整個過程時，耗時最久的其實就是解決各種遷移過程中產生的問題。
挫折中前行
這個客戶的業務系統屬於典型的老舊型業務系統，運行在物理機加上硬件存儲陣列上，有少量的虛擬化環境，操作系統也是五花八門，最多的是SUSE 11，還有Windows 2003，CentOS等，數據庫有DB2，Oracle，還有少量的MySQL。
由於是銀行系統，所以對於業務連續性有非常強烈的訴求，在遷移上對我們提出了以下幾點要求：
第一，風險控制。在任何行業中，穩定、可靠是當仁不讓的第一原則，對於關乎民生的金融行業更是如此。所以在實際雲平臺建設過程中，原有業務系統上雲時往往受到的阻力最大。究其原因就是在上雲過程中沒有一套完整的、科學的方法論及工具讓用戶打消對上雲的顧慮。所以在向雲遷移過程中，系統必須是可驗證、可回退的。在正式切換到雲平臺之前，需要讓業務系統在雲平臺之上得到充分的驗證；在切換到雲平臺後，如果一旦發生失敗，要馬上能夠回退到原有系統，繼續提供服務。保障在雲遷移過程中，風險降到最低。
第二、保障業務連續性。農商行不同於傳統的四大行或者城商行，在IT建設上往往有很大的自主權，除了核心交易系統外，其他的業務系統均運行在本地系統上，所以對本地運維能力提出比較高的要求。在遷移過程中，本地業務系統的連續性非常重要，一旦中斷銀行就無法開門做生意了。同時，根據銀監會印發的相關規定：在業務服務時段導致業務無法正常開展達半個小時(含)以上，屬於重大運營中斷事件。所以基本上遷移的切換時間窗口，只能在晚間進行，但是晚上銀行又會有數據下發、跑批等程序的運行，所以留給遷移的時間窗口非常有限，所以必須採用一種近似於熱遷移的效果來滿足客戶的需求。
第三，減少人為干預，保障遷移的可靠性。由於很多系統屬於服務廠商開發，部分應用時間久遠，甚至很多服務廠商已經不存在了，所以遷移過程中儘量減少對應用廠商的依賴很關鍵，比如重裝、重新配置都會導致應用無法運行。同時，在遷移過程中，由於步驟非常複雜，人為操作過多非常容易產生錯誤。
在這個過程中，我們走了非常多的彎路，比如從最早採用冷遷移方式的Clonezilla，耗時24個小時才能遷移完一臺主機；再比如調研了各種開源的p2v和v2v工具，沒有一個好用的；再比如為了解決UEFI啟動的問題，修改nova代碼，但是加載後發現一臺服務器啟動過程黑屏了半個小時之久，為了這一個系統我們往返於北京和客戶多達五次。這些困難促使我們不得不停下來思考，為什麼一個看似簡單的遷移，最終卻成為影響項目進度和成本的關鍵因素呢？
從項目中來，在項目中成長
為了解決在項目中遇到的問題，我們嘗試了各種手段，最終我們發現災備領域的數據讀取技術加上雲原生的方式是最佳的組合方案。使用災備的塊級別差量複製技術能夠充分保障業務連續性，而最大程度利用雲平臺原生接口和資源能夠實現”兩點之間直線最短“的效果，保障遷移的可靠性，大幅度降低人為介入而帶來的不確定性，最後二者疊加的效果最終滿足了風險可控的終極目標。
通過2016和2017年近兩年的磨練，一個面向OpenStack的熱遷移產品具備了初步產品雛形。在緊接著到來的2018年我們迎來了又一次大考，這一次我們面對著是江蘇省農信的專有云平臺的大規模遷移，我們需要將該省內全部62家二級法人的業務系統遷移上雲。很快我們中標的興奮就淹沒在新的困難面前。在之前的項目中，我們的所有遷移行為都是在本地數據中心完成的，至少所有的網絡基本都是千兆的。但是在這個項目中，省端和各個二級法人之間的連接變成了以10Mbps的專線，並且這還是最好的情況，還有更糟糕的只有2Mbps。省端與二級法人的專線連接主要用於省端的數據下發，所以用於遷移的數據傳輸只能在特定時間段進行，同時不能將全部的帶寬佔滿，以防影響業務。但是，每個二級法人的用戶數據量很大，大約在30TB - 50TB左右，如果完全依賴網絡傳輸，理論上需要傳上一年多的時間。所以完全依賴於網絡傳輸是不可能的，我們需要的是一種硬件加網絡的組合方案，由硬件保存全量數據，通過運輸方式到省端，將全量數據切換至雲端後，再通過網絡傳輸增量，這樣形成的效果仍然是熱遷移，但是遷移的速度明顯提高。
在解決了大規模數據傳輸後，我們緊接著遇到的問題就是先遷哪個，後遷哪個？我們都知道應用系統是存在一定的依賴關係的，所以在遷移前必須要梳理清楚應用系統的拓撲結構，同時還要對遷移後的網絡、應用配置等變更做出預先分析，保障萬無一失。這個過程其實就是在眾多遷移方法論中提到的調研分析階段。在這個過程中，我們也在實踐中積累了自己的遷移調研方法和實施方案，對我們後來的項目起到了很大的幫助作用。同時我們也意識到，遷移絕對不是一個工具就解決的問題，而是一個重度的諮詢過程，遷移工具只不過解決了最後一公里的問題。
從2018年初開始，我們和用戶方組成的江蘇省農信業務專家組，深入每個地市，嚴格遵照調研、評審、實施、切換進行科學的上雲。從基本的系統信息採集、整理到業務系統上下聯分析，繪製拓撲圖，安全性等進行全面評估，之後根據調研的結論整理實施方案、進度，實施方案中要將一切在遷移後的變更提前進行整理，確保遷移過程中萬無一失。通過輔助物理設備進行全量數據拷貝，運輸到省端後進行切換上雲，最終在合適的時間點完成增量及業務切換過程。在2018年下半年，平均一週就可以有三家農商行的業務系統實現全面上雲。
在這個項目中，我們的產品得到了極大的錘鍊，經受了大規模遷移的考驗。通過專有云的建設和業務系統遷移，3年共為江蘇農信節省IT投資5.6億元。截止2018年9月30日，總共完成54家二級法人共1200多套系統遷移。同時，雲平臺的從最初的15個節點增長到了130多個節點，存儲從0.2PB增長至3PB。
從一朵雲到一片雲
時間到了2019年，我們產品的雲原生的理念逐步得到了更多客戶的認可，同時這種基於雲原生構建的高度自動化的效果正好填補了雲遷移這個市場空白。甚至某些老牌的災備廠商把我們當成遷移競爭對手，直接在軟文中進行”詆譭“，不過這一切恰好證明了我們產品所蘊含的巨大價值。
但是隻能支持單雲的遷移已經無法滿足市場上越來越多的雲遷移需求，所以在2019年上半年，我們準備全面支持更多的公有云和專有云平臺。我們首先選擇了國內的最大的公有云提供商——阿里雲。阿里雲在最近10年已經成長為中國雲計算領域的標杆，擁有極高的市場佔有率，同時提供了最廣泛的API接口支持，為合作伙伴提供最大程度的賦能。由於阿里雲與OpenStack在一些機制上存在差異，我們通過近3個月的調研和開發，終於突破了阿里雲的熱遷移。接下來，我們對雲平臺的支持範圍不斷擴大，又用了四個月左右時間，覆蓋了國內絕大多數的公有云、專有云和私有云平臺，成為了名副其實的多雲遷移。
打造極致的用戶體驗
很多企業級產品留給人的第一印象就是專業且複雜，不培訓你兩天你都不會用。在雲遷移領域也是如此，很多雲遷移產品都是由傳統災備廠商對原有災備軟件進行簡單改造後的產物，界面複雜不說，操作還極其繁瑣，遷移一臺主機下來，十幾個、二十幾個步驟那是基本配置。所以在我們對產品進行迭代時，希望用To C的思維打造To B的產品。
在初始階段，用戶只要根據嚮導配置源端和目標端的信息後，就可以進入遷移流程。我們將遷移流程分成了三個簡單的步驟：選擇主機、同步數據和開始遷移。通過高度自動化的流程和對雲原生API及資源的巧妙利用，初級的Linux工程師基本上幾分鐘就能完全上手。同時由於自動化程度高，在批量遷移時優勢非常明顯。
由於之前一直從事的是私有云領域的產品研發，導致我們的研發團隊在產品開發中存在一種慣性。為了滿足私有化部署的需要，我們往往需要將安裝包做成無網絡依賴的ISO格式。這直接導致的後果就是用戶在試用我們的產品時往往需要先花很長一段時間去下載我們的安裝介質，之後是安裝，最後才能試用。這個一來一回的過程，往往就是一天的時間被浪費了。這一點在公有云遷移時，會讓人覺得更加繁瑣，所以在2019年下半年，我們決定將我們的產品SaaS化，讓用戶更快速的體驗我們的產品而非將時間浪費在安裝的環節上。由於人力資源的限制，研發團隊和運維團隊都受到了極大的挑戰。研發團隊需要開發新的模塊以支持運營、多租戶等SaaS需求，同時還要對原有的通訊模式進行改造，避免雙向通訊的發生；而實施團隊需要兼顧私有項目和線上運維，這就要求平臺穩定、高可靠、易運維，所以對雲原生的應用就變得尤為關鍵。我們利用阿里雲的Kubernetes容器服務和各種雲原生組件完成了SaaS化的改造，在沒有增加任何人力的情況下，在2020年初完成SaaS的全面上線。
在巨人肩膀上一起成長
2019年初，AWS斥資2.5億美金收購了以色列災備初創公司CloudEndure，雖然這家公司以災備公司名義被收購，但主要業務卻是提供向AWS的遷移服務。我們的產品在設計理念和用戶體驗上與CloudEndure非常相似，同時我們的產品可以支持國內眾多的不同的雲廠商。
AWS對CloudEndure的收購給了我們非常大的信心，讓我們堅定了走雲原生遷移、災備產品的思路。我們發現這個市場在國內基本上屬於空白階段，雖然傳統災備廠商的工具可以靠堆人解決項目上的問題，但是真正讓用戶自助式的遷移平臺才能讓用戶自主分配在雲端的負載，讓雲資源得到更快速的消耗，最終讓雲廠商獲益。
於是一個大膽的想法在腦海中形成，能不能把我們的遷移軟件以雲原生服務的方式集成在公有云平臺中呢？經過幾番周折，我們開始與阿里雲進行接觸。非常感謝阿里雲的陳緒博士幫我打開了和阿里雲團隊的合作大門，在2019年與阿里雲對接完成後，我們首先迎來了就是阿里雲ECS團隊的考驗，在對產品充分測試後，我們在杭州與阿里雲生態合作伙伴團隊、投資部門進行了會面，這次會面徹底打開了我們與阿里雲的合作大門。
2019年底，我被評為阿里雲解決方案領域MVP，進一步促進了我們與阿里雲之間的合作。2020年初，阿里雲控制檯上的應用工具市場吸引了我的目光。這種與阿里雲深度整合的方式，對於雲原生遷移、災備是絕佳的棲息之地。通過阿里雲MVP運營團隊的引薦，我們成功的和阿里雲應用工具市場團隊進行了對接，同時在2月底決定上架阿里雲應用工具市場。
上架阿里雲應用工具市場的過程絕非一帆順利，阿里雲對此有嚴格的安全性要求，上線前必須要通過阿里雲安全部門的嚴格審查。為此，我們做了一些架構上的調整和安全性的加固。最終經過近3個月的努力，終於將我們的平臺與2020年7月10日晚8點正式上線。上架後的遷移平臺，與阿里雲的用戶體驗保持完全一致。用戶使用時毫無違和感。
緊接著通過MVP運營團隊與阿里雲Apsara Stack團隊取得了聯繫，開始對接Apsara Stack專有云，截止到8月初已經徹底實現了對Apsara Stack自動化遷移的全面支持。
結語
2020年4月，國家提出了新基建的發展目標，首當其衝的就是信息基礎設施，而云計算作為新基建的底座，重要性不言而喻。2020年初的疫情，讓全社會意識到”雲上社會“的重要性，可以預見的一點是，全面雲化的時代正在到來。
通過與阿里雲的全面合作，為我們的產品帶來了頂級流量入口，獲取客戶信任的時間更短。未來，我們也會將我們的產品打造成基於雲原生的備份、容災產品，為更多的雲客戶提供完美的用戶體驗。歡迎各位有志之士加入我們的團隊，也歡迎有需求的客戶加入我們的遷移群參與討論（關注微信公眾號後回覆”支持“）。
