1、爲何遷移上雲
目前仍是有很多的中小企業把本身的業務工做負載放置在本地數據中心,面對着日益增大的業務量,本地數據中心開始慢慢凸顯出一些弊端,難以知足企業新型業務的需求,而且購買以及更新設備都須要企業提早支出一大筆資金,不少中小企業難以承受其中的壓力,經過遷移上雲咱們能夠避免本地數據中心面臨的一些問題。docker
2、遷移規劃
當企業使用 AWS,能夠實現按需高效、安全地運行資源,只需短短几小時,就能使企業以遠勝從前的效率,敏捷地實現創新,再無需等待數月時間。那企業上雲,想更快更好地將原有服務作遷移,制定遷移計劃須要注意哪些問題?本篇文章將與你係統探討 AWS 遷移模式。後端
遷移流程
在衆多的遷移上雲案例中,你們慢慢總結出了一個相對標準的遷移流程,按照這些流程進行業務遷移,能夠提高咱們的遷移效率,以及少走一些彎路。tomcat
- 資源評估:須要對本地業務資源有一個總體的瞭解,列出一個業務清單,記錄環境中的物理和虛擬服務器。
- 發現和分析:對整理出來的資源進行分析,肯定是否適合上雲,以及雲中使用有相應的服務支持。
- 計劃和設計:若是知足上雲要求,咱們要制定遷移策略。
- 遷移,整合,驗證:進行遷移,驗證,以及業務切換。
- 運維和優化:利用雲中的服務對咱們的業務進行管理和優化。
遷移評估
在開始規劃以前設定雲遷移的優先級和目標,從而確保遷移更加成功。此外,自動雲遷移工具還可提供有關環境和依賴關係的看法,幫助制定雲遷移項目計劃。在企業計劃遷移階段,須要系統評估多方因素,其中包含業務因素、合規因素、安全因素、平臺因素及人員因素等,這些是遷移的基礎考量。安全
- 業務因素:須要考量全部主要利益相關方,是否都支持業務案例和對遷移的承諾,而且是否有資金能夠投入遷移工做;
- 合規因素:須要看企業是否有符合合規標準的應用程序;
- 安全因素:須要考慮到企業在數據保密性方面的主要挑戰,而且採起了哪些控制措施;
- 平臺因素:須要肯定一系列試點應用程序,而且獲得工做負載全部者的承諾;
- 人員因素:須要驗證企業的技能和能力,是否認義了運營的角色和責任。
藉助 AWS 的雲遷移評估工具 Application Discovery Service,它能夠自動識別在本地數據中心運行的應用程序、其相關依賴關係和性能配置文件,讓你可以制定本身的雲遷移計劃。服務器
運用此信息來映射服務器,從而呈現你的本地應用程序。這將有助於肯定服務器之間的依賴關係或通訊,讓你可以在雲遷移計劃中包含全部必備的應用程序組件,從而幫助下降風險,確保順利遷移。而後,按邏輯方式對服務器分組以呈現應用程序,並根據每一個應用程序的要求和遷移目標爲其選擇最佳的雲遷移策略。網絡
遷移策略
在肯定評估因素後,咱們展開討論計劃階段最重要的遷移模式問題,這對企業而言相當重要。對此,AWS 系統總結了 6R 遷移理論提供參考,包括:保留 (Retain)、停用 (Retire)、更換主機 (Rehost)、替換 (Replace)、更換平臺 (Replatform)、重構 (Refactor),不一樣的業務應用咱們能夠採用不一樣的遷移策略,企業根據應用的評估,選擇不一樣的遷移策略。架構
- Retain:有些應用不能馬上遷移,或者不容許遷移到雲中,咱們繼續留在本地數據中心
- Retire:在評估過程當中,發現一些再也不須要的業務,咱們能夠從數據中心刪除。
- Rehost:這種無代碼選項一般稱爲「直接遷移」,可以讓你快速將現有應用程序遷移到 AWS。每一個應用程序按「原樣」進行遷移,既發揮了雲的優點,又無需承擔更改代碼所帶來的風險或成本。
- Replace: 替換現有的應用。好比使用雲中的 SaaS 服務替換咱們的應用。
- Replatform:更改平臺做爲雲遷移的一部分,好比將 Windows 更換成 Amazon Linux。
- Refactor:對應用重構,而後遷移上雲,好比更改後端數據庫,中間件等,相對來講比較複雜。
在遷移過程當中咱們不僅用到一種遷移模式,即便在一個應用程序棧中,企業也可能會遇到 2~3 個 「R」,咱們要充分分析應用程序,進行組合搭配,以達到最低的成本和最高的價值。負載均衡
3、遷移服務及工具
在瞭解了遷移上雲的過程,以及遷移過程當中用到的一些策略以後,那麼咱們開始對本地中心的應用進行遷移上雲,咱們知道雲數據中心中最重要的三項基礎設施資源主要是計算、存儲、網絡,那咱們也主要以這三部分爲你們介紹一下各自的遷移方法,以及相關的注意事項。less
網絡遷移
本地數據中心的網絡通常是私有網絡,大部分是扁平化的網絡,一些業務規模比較大的企業,他們都有本身的網絡工程師來規劃相對複雜的網絡,網絡遷移的複雜程度主要取決於本地數據中心的網絡複雜程度,至於如何把本地網絡遷移到 AWS 中,咱們也須要根據不一樣的狀況去考量。
在 AWS 雲中,咱們是經過 VPC 來實現私有網絡建設的,VPC 的各項功能基本能夠知足企業網絡的各項需求,那咱們該如何去設計咱們的網絡呢?
- 徹底複製:應用程序裏面嵌入了服務器的私有 IP,總體遷移不去修改代碼,而且沒有計劃使用混合雲模式,針對這一部分,咱們能夠在 VPC 中創建一個和本地數據中心如出一轍的網絡,擁有相同的 IP 地址塊,可是須要注意,VPC 中的一些安全設定本地中心可能沒有,好比 NACL、Security group 等。
- 混合雲模式:有些企業部分應用遷移上雲,而且將來規劃混合雲的模式。針對這種狀況,咱們在 VPC 中設計的網絡,其 IP 地址塊與本地數據中心的 IP 地址塊不能重合,既然是從新規劃 IP 地址範圍,那咱們儘可能每一個子網的分配的 IP 數量多一些。
本地數據中心的網絡冗餘,高可用方案,須要精通高級網絡的工程師來進行配置和維護,網絡上雲以後,全部的這些都由 AWS 來進行維護,企業的維護人員具有簡單的網絡知識便可維護,下降了網絡管理的門檻,也爲企業節省開支。
工做負載遷移
咱們把支撐業務運行的一些資源稱之爲工做負載,咱們能夠把虛擬機、數據庫、應用等粗略的規劃在工做負載層面,下面咱們主要針對這幾部分來講一下遷移過程當中的狀況,這也是咱們整個遷移最重要的環節。
虛擬機遷移
將虛擬機轉移到雲端有助於避免會形成巨大財務壓力的更新週期。準備就緒後,咱們能夠經過兩種簡單方式使用直接原樣遷移策略進行遷移,咱們使用 Rehost 做爲咱們的遷移策略。
第一種:咱們可使用 AWS Server Migration Service (AWS SMS) 將虛擬機從本地或其餘雲平臺直接遷移到 AWS。AWS SMS 是一項免費的服務,它能夠幫咱們把本地虛擬機增量的複製爲可在 Amazon EC2 上部署的雲託管的 Amazon 系統映像 (AMI),整個複製過程,咱們只須要支付遷移期間所使用的 S3 存儲桶、EBS 卷和數據傳輸費用,以及所運行的 EC2 實例費用。
第二種:咱們也可使用 VMWare Cloud on AWS 解決方案將您的 VMware 虛擬機直接遷移到 AWS。 這意味着您現有的基於 VMware 的工做負載可從雲端的性能、規模和安全性中獲益,而無需在遷移時重寫。
- 注意事項
- 由於是總體的搬遷服務器,要考慮到帶寬是否知足,是否須要增長臨時帶寬。
- 複製過程當中有可能會用到臨時的一些磁盤,存儲方面是否足夠。
- 防火牆的替換,雲中沒有物理防火牆,能夠考慮使用 AWS 的安全組來替換。
- 價值體現
- 能夠享受更低廉的價格以及更先進的配置。
- 多區域節點選擇。
- 提升員工效率,由傳統 IT 運維轉移到業務上面。
數據庫服務遷移
本地數據中心的數據庫服務,通常都是在物理機或者虛擬機上面,由運維人員部署,針對數據庫的遷移,咱們主要有如下注意事項以及解決方案:
對於 Rehost 的遷移,咱們能夠很方便地使用 AWS SMS 工具來完成,不過其中可能會有數據延遲,由於數據並非實時同步的,因此我通常推薦你們使用雲中的數據庫,他具備咱們傳統自建數據庫沒有的一些優點。
AWS Database Migration Service (AWS DMS) 是一項雲服務,可輕鬆遷移關係數據庫、數據倉庫、NoSQL 數據庫及其餘類型的數據存儲。您可使用 AWS DMS 將數據遷移到 AWS 雲,在本地實例之間(經過 AWS 雲設置)進行遷移,或者在雲與本地設置的組合之間進行遷移,使用 DMS 服務,能夠保證咱們的源數據庫和目標數據庫數據實時同步,持續運行,使用這種模式,能夠保證咱們的數據庫遷移零宕機。
對於一部分用戶,他想在上雲以後換一種數據庫引擎,好比 Oracle 轉換成 Aurora MySQL,遇到這種狀況,咱們能夠藉助 AWS Schema Conversion Tool 這項服務來幫助咱們完成,在使用 SCT 的時候,比較消耗內存,提升內存性能能夠提升轉換速度,但會佔用臺式計算機的更多內存資源。
應用遷移
在實現應用遷移上雲的過程當中,通常會面臨已有業務系統改造和新建業務系統兩種場景。新建業務系統只須要按照應用上雲的標準要求進行架構設計、研發、編碼和測試便可,實現相對簡單。已有業務系統遷移上雲則須要對現有業務系統改造。
-
遷移策略:
- 對於 Rehost,使用 AWS SMS 服務能夠方便地遷移整個應用程序技術棧上雲,這種遷移相對來講比較簡單,遷移完成以後,修改一下後端數據庫信息,切換 DNS 服務便可上線。
- 對於 Refactor,這種狀況會花費比較多的工做量,他須要用戶重構應用程序代碼,使其能夠充分的去兼容雲原生的一些服務,好比 Lambda,API GateWay,Elastic Beanstalk 等一些服務,以提升咱們應用程序的性能和安全。
-
注意事項
- 是否有相關的應用程序路線圖
- 有哪些相關的成本與此應用程序有關係
- 有哪些改進選項可加強服務可用性
- 若是不改變這個應用程序,是否有相關風險
- 此應用是否與組織的技術目標互相一致
- 價值體現
- 可使用雲原生的一些服務
- 能夠藉助雲中 DepOps 工具加速應用程序的測試與發佈
- 運維開發人員不用再去管理應用環境的配置,專一於應用代碼的開發,提高效率
對於應用程序上雲,咱們通常是先在雲中徹底創建一套完整應用程序環境,等待程序測試無誤以後,經過修改 DNS 來完成應用上雲,應用穩定後,應用程序就能夠逐步的有計劃從本地中心移除。
容器遷移
隨着近些年容器的流行,愈來愈多的公司會有一些服務運行在容器平臺中。若是容器運行在單機上面,咱們通常直接使用 docker 命令運行,或者使用 docker-compose,對於運行在多機器上面的容器服務,咱們大部分使用的都是如今很流行的容器編排服務 kubernetes。
由於容器的特性,它能夠把整個程序運行環境打包到鏡像中,咱們不須要再單獨爲其配置運行環境,根據這方面特性,對運行在容器中的應用程序遷移上雲變得簡單了不少,用戶不須要對代碼進行任何更改便可完成遷移上雲。
那麼在 AWS 上面有哪些容器平臺供咱們選擇使用呢?相對於本地自建的容器平臺又有什麼優點?
在 AWS 雲平臺中,有兩個容器編排工具供咱們選擇,一個是 Amazon Elastic Container Service (ECS) 或 Amazon Elastic Kubernetes Service (EKS)。
- 若是應用程序是運行在單機上面的,在雲中最佳的選擇是 ECS,ECS 是一項高度可擴展的快速容器管理服務,它可輕鬆運行、中止和管理集羣上的 Docker 容器,ECS 與 Identity and Access Management (IAM)、Amazon Virtual Private Cloud (VPC) 和 Amazon Route 53 等 AWS 服務深度集成,並在安全性、可靠性和可用性方面進行了普遍的測試,以支持內部和客戶的任務關鍵型服務。
- 若是應用程序運行在 kubernetes 上的,在雲中的最佳選擇是 EKS,EKS 則是運行 Kubernetes 的最安全、可靠且可擴展的方式。EKS 提供的控制平面不只可擴展且高度可用,還能跨多個可用區運行,以消除單點故障。EKS 可運行上游 Kubernetes,而且經認證與 Kubernetes 一致,所以您能夠得到社區中開源工具的全部優點。
在 AWS 上運行容器時,您有兩個平臺能夠進行選擇。首先,您能夠選擇是否要管理服務器。若是您想要進行容器的無服務器計算,請選擇 AWS Fargate,若是您須要控制計算環境的安裝、配置和管理,則選 Amazon EC2。
Fargate 是客戶跨 ECS 和 EKS 在 AWS 上運行容器的首選方式。客戶喜歡 Fargate 是由於它提供容器的無服務器計算,此服務可以使他們專一於構建其應用程序。使用 Fargate,您無需預置和管理服務器,並且能夠爲每一個應用程序指定資源併爲其付費,並經過設計隔離應用程序來提升安全性。
- AWS 容器平臺優點
- 低成本:能夠選擇部分 spot 實例做爲底層資源節省費用。
- 企業就緒
- 彈性擴展:雲中 EKS 相比自建的 kubernetes 多 Cluster Autoscaler 特性,能夠根據負載擴展集羣中的服務器數量,ECS 中由 capacity providers 來提供底層計算資源彈性伸縮。
- 更可靠:ECS 和 EKS 的控制面板由 AWS 徹底託管,服務的可用性由 AWS 專業技術團隊維護。
- 網絡:使用 Amazon VPC CNI,使 container 或者 pod 具備 VPC IP,省去網絡封包,提高網絡性能。
- 負載均衡:經過使用 AWS ALB,可讓流量直達 container 或者 pod 的 IP,集羣能夠省去 原有 service 流量分發,提高轉發性能。
- 權限:能夠直接爲 container 或者 pod 賦予 IAM role 級別的權限,安全訪問 AWS 其餘服務。
那麼面對這麼多服務,咱們該如何選擇呢?
- 首先對於非分佈式的應用,也就是單個的容器服務,我推薦選擇 ECS + EC2 平臺,ECS 爲咱們簡化了容器設定,下降管理容器的門檻,用戶只須要按照容器運行的要求設置好 Task definitions 便可,若是您不想管理 EC2,那推薦選擇 EC2 + Fargate。
- 對於運行在 kubernetes 平臺的應用程序,首選推薦 EKS + EC2 平臺,也能夠啓動一部分 spot 實例混搭以節省費用,能夠把在本地 kubernetes 上使用的 yaml 文件直接在 EKS 上運行,不須要特別的修改,整個遷移相對來講更加簡單,相對於 ECS,管理 EKS 集羣須要運維人員更高的一些容器編排技能。對於一些訪問量波動比較大的應用程序,咱們能夠運行在 Fargate 平臺上面,彈性擴展底層硬件。
數據遷移
這裏所說的數據主要是靜態存放的數據,以及一些歸檔數據,須要把這些數據傳輸到 S3 中,數據遷移工具的選擇主要是考量數據量的大小,以及本地數據中心的帶寬大小,不一樣的組合用到的遷移工具也不盡相同。
- AWS DataSync 是一種數據傳輸服務,能夠簡化、自動執行和加快本地存儲與 Amazon S3 或 Amazon Elastic File System (Amazon EFS) 或 Amazon FSx for Windows File Server 之間的數據遷移。DataSync 使用本地代理鏈接到 NFS 文件系統,並快速遷移文件數據(比開源複製工具的速度快 10 倍),而無需編寫和管理腳本。DataSync 會執行完整的初始副本,增量傳輸以及對已傳輸數據的驗證。若是您有可用的網絡帶寬,那麼 DataSync 是遷移基於文件的數據的最簡單方法。
- AWS Transfer for SFTP (AWS SFTP) 是一項徹底託管的 AWS 服務,可以讓您經過安全文件傳輸協議 (SFTP) 將文件傳入和傳出 Amazon Simple Storage Service (Amazon S3) 存儲。SFTP 也稱爲安全外殼 (SSH) 文件傳輸協議。
- AWS Snow 系列能夠爲那些須要在嚴峻的非數據中心環境中運行操做、將大量數據遷出本地環境以及遇到缺少一致網絡鏈接的狀況的客戶提供幫助。Snow 系列由 AWS Snowcone、AWS Snowball 和 AWS Snowmobile 組成,能夠提供各類物理設備和容量點,其中大部分設備還內置有計算功能。這些服務使您可以在本地經濟高效地使用 AWS 雲的存儲和計算能力,從而有效地傳輸數據並加速遷移。
咱們能夠很簡單的經過數據庫和帶寬估算出數據上雲所消耗的時間,企業能夠根據本身所能承受的能力來選擇不一樣的工具,對於一些數據量比較小的,可使用 DataSync,SFTP,固然也可也使用 aws cli 把數據傳輸到 S3,而後對於數據量比較巨大的,經過網絡傳輸至關消耗時間的,咱們可使用 Snow 系列來傳輸數據。
4、優化
利用 AWS 安全管理服務來管理雲環境,從而管理和監控雲環境中的應用程序。開始在遷移期間使用這些服務,也能夠在遷移後繼續使用其中的部分服務來保證混合雲的一致體驗。
- 雲成本管理:AWS 帳單和成本管理是一項 Web 服務,藉助該服務提供的功能可幫助您監控成本並支付帳單。Amazon Web Services (AWS) 根據使用狀況向您的帳戶收取費用,可確保您只需按實際使用量付費。
- 使用 AWS 產品/服務節省費用:購買 AWS 的 RIs 還有 Savings Plans 服務,藉助 Compute Optimizer 的推薦調整虛擬機的大小,以實現利用率最高,價值最大化。
- 加快實現應用現代化:利用所節省的資源來增添更多雲功能,慢慢把雲中的工做負載遷移到無服務模式,實現應用的現代化。
5、安全與管理
AWS 很是注重客戶業務的安全性,AWS 具備衆多的安全服務來保障咱們的應用與數據安全,這裏只簡單介紹一下咱們經常使用的幾個服務。
- 業界領先的安全性:AWS Security Hub 向您提供 AWS 資源安全狀態的全面視圖。Security Hub 跨各 AWS 帳戶和服務收集安全數據,幫助您分析安全趨勢,肯定整個 AWS 環境中的安全問題並明確其優先級。
- 監視分析雲健康情況:利用 Amazon CloudWatch 跟蹤雲應用的運行情況和性能、基礎結構和數據。從各來源輕鬆收集數據,並得到豐富看法。
- 有效管理虛擬機:藉助 Systems Manager 能夠輕鬆批量管理衆多虛擬機,如命令批量執行,操做管理、應用程序管理、操做和更改、實例和節點。
6、客戶案例
筆者曾經在一家數據分析的公司任職,公司的主要業務是經過對手機 APP 數據進行分析。以前的業務所有在上海的數據中心,公司的應用程序主要是 Java 程序,數據庫有 MySQL和 Oracle,大數據處理平臺是經過多臺物理機自建的 Hadoop 集羣。
上雲以前,若是臨時接了一個項目,IDC 的資源難以及時有效的支持相應服務,公司須要硬件採購,(包括服務器,防火牆,交換機在內的相關基礎硬件),設備上架,網絡規劃,系統安裝及配置,以及大量的人工運維。整個週期須要至少半月到一個月左右。
經過一次培訓,瞭解到雲計算相關的特性,客戶開始對部分業務進行上雲評估,經過半月時間對本地數據中心的工做負載進行梳理並列出清單,根據AWS提供的遷移策略和最佳實踐逐步將業務遷移上雲。須要注意的是不少業務須要分步驟上雲,逐步去替代掉本地數據中心的業務,在上雲的過程當中,客戶對部分應用進行了優化和重構,使其更加適應雲原生的服務。
通過近一年多的 AWS 雲服務的使用,客戶充分體驗到雲服務的優點:
- 節省硬件部署時間消耗,提升服務上線時間:客戶沒必要再花大量的時間在硬件採購和上架以及系統安裝上;設備上線大大縮短了時間,由以前的數週縮短爲一小時之內。
- 簡化數據庫管理:咱們由本身部署的數據庫,所有切換爲雲中的數據庫,包括 RDS 還有非關係型數據庫,MySQL 咱們更是直接採用了 Amazon Aurora Serverless 數據庫,不在爲估算數據庫的配置而苦惱,它會根據業務的負載自動的擴容縮容,極大的減輕了咱們的維護壓力,DBA 人員沒必要再爲數據庫部署,高可用,備份,以及維護花費精力,這些工做只須要在雲中點擊記下就能夠完成,DBA 把工做技術在業務上面的優化,極大的爲咱們節省了人工成本,並提升了工做效率。
- 提升應用上線效率:上雲以前,咱們部署應用相對比較繁瑣,由於咱們是 Java 程序,每上線一個新程序,都須要去配置一個tomcat,由於端口不能夠公用,咱們須要修改每一個 tomcat 的配置更改端口,長此以往,tomcat 愈來愈大,很是不便於管理,咱們對部分應用重構以後上雲,對於一些功能簡單的應用,咱們部署在了 Lambda 上面,並經過 API Gateway 來觸發,沒必要再去關注底層服務器;另一部分應用直接部署在了 Elastic Beanstalk 上面,可由開發人員直接部署,沒必要再去爲環境搭建而花費時間,還有一部分應用放在了 ECS 上面,使用容器技術也極大提高了咱們的部署效率。
- 節省整體成本:上雲以後,對於成本的節省也很是顯著,咱們粗略估算,費用節省高達 40%,這主要歸功於雲計算的靈活性,彈性,以及低成本,沒必要提早預置一大批硬件花費大量金錢,對於長時間運行的一些服務,咱們購買了預留實例來節省成本。簡單拿咱們的大數據平臺來講,以前咱們是幾十臺服務器組成的集羣,集羣的利用率並不高,可是也不能沒有,上雲以後,咱們直接購買的 EMR 服務,咱們瞭解到 AWS 有一種叫作 spot 的實例,費用節省最高達 90%,咱們的大數據工做負載,基本 80% 的服務器所有是買的 spot 實例,分析完以後銷燬全部的實例,單單這一特性,爲咱們節省了很是大的成本。
雲中的優點還遠遠不止於此,好比在安全性方面,各類安全服務保障咱們的業務順利進行,以及咱們能夠第一時間使用最早進的服務,能夠很是方便地使用機器學習等其餘服務,它不但減輕了咱們的工做,也爲企業節省了巨大的費用。