十年網(wǎng)站開發(fā)經(jīng)驗 + 多家企業(yè)客戶 + 靠譜的建站團隊
量身定制 + 運營維護+專業(yè)推廣+無憂售后,網(wǎng)站問題一站解決
云的時代:
云時代已經(jīng)到來,在選擇云之后,企業(yè)首要的問題是選擇什么樣的方式遷移上云?這會影響企業(yè)的遷移周期和遷移后的業(yè)務服務品質(zhì),所以遷移時一定要按照一定的方法論和流程,而不是盲目的遷移。最基本的也要遵守這五個過程:計劃,設計,遷移,運營及優(yōu)化,在這套方法論里面您可以按您們的實際業(yè)務情況進行微調(diào)。
所有云廠商里面,AWS擁有最完善的遷移方法論。例如:CAF(采用云框架),LandingZone,Well-architected(良好的架構(gòu))和三天遷移培訓課程,這些能使您意識到使用云會是一種什么樣的模式,解決您在使用過程中的疑問。個人認為一個AWS初級用戶學習CAF的方法論更為關鍵,這樣可以讓您對云有更深次的使用體驗。

借鑒我們過往的經(jīng)驗,我們建議客戶在AWS上有小量的應用后,再來研讀Well-architected,Well-architected中的專業(yè)術語較多,建議可以進行初步的了解后,進行簡單的應用實踐,后期在實踐過程中不斷的鞏固知識點,以掌握該部分的精髓。當然也有縮短學習時間的方法,那就是選擇有經(jīng)驗的AWS Partner做一次詳細的講解以及陪您們一起上云實踐,他們會根據(jù)您企業(yè)的業(yè)務運行狀況告訴您們什么是最佳實踐。

實踐分享:
根據(jù)我們經(jīng)歷過大量遷移的實踐總結(jié),讓我們一起分享在遷移過程中,最為關鍵的兩個階段,分別是計劃和設計。它們是整個遷移中最為基礎的部分,就像一棟大樓的地基,如何詳細地做好這兩個階段的工作,我們一起來探討,希望能對您及您的企業(yè)有幫助。
1) 計劃:
建議在做計劃前,先做一個遷移優(yōu)先級列表,里面必須包含幾個核心的字段,例如:操作系統(tǒng)版本/實際數(shù)據(jù)量/應用提供商/業(yè)務依賴服務/技術復雜度/RTO/RPO等,這些是決定您選擇什么樣的遷移模式(平滑/替換/重構(gòu)),什么樣的遷移工具,因為它們會影響您遷移周期長短和效果(當然也有一些企業(yè)也有一些特別的指標,例如:兼容性(遷到其他云的可能性))。請把這個表填完整后,再做整體的遷移計劃,而不是在沒有任何依據(jù)的情況下做計劃。

按以上指標來看,也許你們會感覺操作系統(tǒng)版本并不重要,實際上非常重要,首先要清楚AWS支不支持這種AMI,如果AWS不提供,Marketplace和社區(qū)有沒有?(如果您對安全很注重,建議不要使用社區(qū)的AMI)您也可以選擇自己制作AMI(選擇Vmware方法制作),而我們的建議是采用AWS提供的AMI,這樣不管理是性能,穩(wěn)定性,功能和故障排查都會較為可靠。舉一個我們實踐過的通訊行業(yè)的案例:客戶在上AWS前,有對AMI進行簡單的功能測試,并沒有針對他們在On-premises修改內(nèi)核的CentOS的AMI進行性能測試。在實際遷移后進行性能測試時就發(fā)現(xiàn)各種故障,此時AWS的售后技術也無法解決。根據(jù)我們的經(jīng)驗建議您盡量采用AWS提供的AMI,如果對AMI確實有非常嚴格的要求,那么請做好所有必要的測試。應用提供商,這是對應用能不能遷移起到?jīng)Q定性的作用,例如:License,版本以及軟件提供商是否還存在?業(yè)務依賴服務,這個指標描述的是業(yè)務之間的數(shù)據(jù)交互,業(yè)務之間的緊耦合關系,它們之間有多少服務數(shù)據(jù)存在交互或者它們僅是其他業(yè)務的數(shù)據(jù)提供商,請注意“實際上有時其他業(yè)務只是依賴這個業(yè)務的數(shù)據(jù)庫的數(shù)據(jù),并不依賴于業(yè)務本身“,所以業(yè)務存不存在并無關系。RTO/RPO,這個指標會決定遷移成本,要保持業(yè)務不中斷,遷移成本就越貴。根據(jù)我們實踐過的經(jīng)驗,RTO/RPO更合適在容災和備份場景,在遷移場景我們更認為業(yè)務可中斷的時間更為關鍵,因為這是用來做數(shù)據(jù)同步和業(yè)務切換的時間,最重要的是:“請別認為自己的業(yè)務永遠不可中斷”(這樣造成遷移成本浪費,甚至不可遷移)。決定遷移時間的長短還有三個相關的因素分別是:數(shù)據(jù)同步技術、網(wǎng)絡帶寬與數(shù)據(jù)量大小。
把以上指標,還有客戶自己要求的指標,做相關評估與驗證(下一個階段的“設計”是此階段“計劃”最重要的驗證測試)才能決定業(yè)務遷移的優(yōu)先級、業(yè)務遷移的模式、業(yè)務遷移的工具、業(yè)務遷移的時間。

2) 設計:
擁有以上已完善的遷移優(yōu)先級列表后,此階段將進行架構(gòu)設計與驗證測試,以至確保遷移模式,遷移工具與遷移優(yōu)先選擇正確,這也說明設計與計劃是承上啟下的作用,并不是各自獨立。通過計劃階段的業(yè)務分析與評估,您已經(jīng)可以進行相應的架構(gòu)設計,同時進行相關驗證測試(在云的時代,這個非常重要),以便調(diào)整遷移的優(yōu)先級與遷移模式。在這此階段驗證的業(yè)務越多,遷移階段的風險就越小,時間就越短。例如我們的一個高新制造行業(yè)客戶,他們在上AWS前跟我們一起對現(xiàn)有在某云廠商的業(yè)務架構(gòu)進行詳細地評估與分析后,在采用替換遷移的模式下得出他們最關鍵的驗證測試是以EC2為基礎的K8S和網(wǎng)絡VPC,所以對這兩樣進行充分測試,例如: K8S的License有效期,K8S的Autoscaling,K8S分成不同業(yè)務組以及K8S的網(wǎng)絡測試,還有做一些關鍵業(yè)務遷移測試。由于設計階段充分測試使得正式遷移時節(jié)省兩周時間。如果有可能的話,建議采用與生產(chǎn)環(huán)境1:1的驗證測試環(huán)境,在驗證完成后,可以把資源Stop,這時只收取部分資源的費用例如:EBS、EIP、S3等。對于那些必須刪除的資源,可選擇先做備份為正式遷移做準備,還有可以使用Cloudformation做好模板,這樣可以減少正式遷移的準備工作。

實踐總結(jié):
很多企業(yè)都喜歡通過少量驗證或不驗證,就開始執(zhí)行遷移,在執(zhí)行過程中遇到各種各樣的問題,有些問題以致他們無法繼續(xù),必須從頭開始。從我們過往的經(jīng)驗來講,建議最好先把簡單的業(yè)務遷移上云,最好都是平滑遷移,最好在前兩個階段做好充分驗證測試準備。對一些確實無法中斷的業(yè)務(實際上DNS域名切換還是需要中斷幾分鐘的)設計好數(shù)據(jù)同步的方式(主要還是數(shù)據(jù)庫數(shù)據(jù)的同步,可以利用AWS DMS或?qū)iT針對數(shù)據(jù)庫實時同步的第三方軟件),這里的數(shù)據(jù)同步會存在一定延遲,要考慮業(yè)務可承受的時延范圍。一定記住和理解每個階段之間是存在嚴格的關聯(lián)關系。

遷移,運營,優(yōu)化這三個階段也非常關鍵,而在遷移的前兩個階段做好了充分準備,到遷移階段會相對輕松,只需注意風險評估和人員工作分配,運營和優(yōu)化屬于高級階段,對遷移后的業(yè)務在穩(wěn)定性,性能,安全,可用性和成本等方面進行逐步優(yōu)化。(此文章若有錯誤,請指正,謝謝?。?/p>
參考學習地址:
https://d0.awsstatic.com/whitepapers/AWS_CAF_Security_Perspective.pdf
https://aws.amazon.com/cn/architecture/well-architected/
【關于博思云為】
作為一家專業(yè)的云計算服務型企業(yè),博思云為專為客戶提供 AWS 上的運營服務:包括架構(gòu)咨詢服務、遷移服務、云安全集成服務、混合云管理服務、大數(shù)據(jù)服務以及 DevOps 服務。目前,博思云為在大數(shù)據(jù)、DevOps、架構(gòu)、數(shù)據(jù)庫以及操作系統(tǒng)等都已取得廠商認證,在上海、南京、杭州、武漢等地設有分公司。為創(chuàng)新服務模式、引領 IT 服務業(yè)的發(fā)展,博思云為將持續(xù)投入資源開展智能混合云管理平臺、圖數(shù)據(jù)庫的研發(fā)等。
另外有需要云服務器可以了解下創(chuàng)新互聯(lián)cdcxhl.cn,海內(nèi)外云服務器15元起步,三天無理由+7*72小時售后在線,公司持有idc許可證,提供“云服務器、裸金屬服務器、高防服務器、香港服務器、美國服務器、虛擬主機、免備案服務器”等云主機租用服務以及企業(yè)上云的綜合解決方案,具有“安全穩(wěn)定、簡單易用、服務可用性高、性價比高”等特點與優(yōu)勢,專為企業(yè)上云打造定制,能夠滿足用戶豐富、多元化的應用場景需求。