在本次會議中，我們將分享如何通過 AWS 的最佳實踐，説明企業業務以高效方式實現線下資料中心遷移到 AWS 雲上環境。分享經驗包括遷移戰略，遷移方法，遷移規劃和遷移執行。 同時，我們還將分享一些相關的遷移工具，用於加速遷移過程和降低業務停機時間和風險。 最後，我們將提供結構化的參考遷移路線圖作為AWS雲上的大規模遷移的指引。

1. © 2017, Amazon Web Services, Inc. or its Affiliates. All rights reserved.
陳進坤 | Tan Chin Khoon
首席諮詢顧問
AWS 專業服務
如何規劃與執行大型資料中心
遷移和案例分享

2. 分享摘要：
 AWS：分享我們的經驗和方法論，幫助企業實現快速的大規模
上雲遷移
 聽眾：了解AWS已成功交付予全球各地數百家大型企業客戶已
被驗證的遷移模式，方法和工具。
 目標：加速遷移，降低風險，更快地實現業務價值

3. 2017 vs 2016 雲計算受益分析
 前三被關注的受益 – 更快的訪問基礎設施，可伸縮性和高可用性
 亮點：最大的改進是高可用性增加4％
 更快的上市時間是業務考慮重要性的一個關鍵驅動
信息来源: RightScale 2017 State of Cloud Report
更高的可伸縮性
更快地訪問基礎設施建設
高可用性
更快走向市場
高效的IT技術人員
業務連續性
高性能
成本節約
地域覆盖
轉移資本支出到運營成本

4. 雲計算階段性成熟度的5大挑戰
位置 雲計算初學階段 雲計算探索階段 雲計算成熟階段
#1 安全 (32%) 缺乏專業知識(28%) 管理開銷 (24%)
#2 建設私有雲 (28%) 管理開銷(27%) 合規 (22%)
#3 管理開銷 (25%) 安全 (27%) 缺乏專業知識 (21%)
#4 缺乏專業知識 (25%) 合規 (25%) 安全 (19%)
#5 合規 (25%) 管理多个雲 (24%) 合規 (19%)
總體評論：
 缺乏專業知識是接下來各個階段採用雲計算的關鍵挑戰。
 雲計算初學階段更加關注架構建設。
 雲計算探索階段對交付可預測的結果感興趣。
 雲計算成熟階段變得更加專注於優化。
 雲計算的轉型和採用是一個信念之旅！
信息来源：RightScale 2017 State of Cloud Report
5
增加複雜性，缺乏敏
捷性和擴展性!?

5. 雲遷移的關鍵驅動
Source: Datacenter Dynamic
”通過多方面的業務彈性戰
略考慮，我們認為自己運行
數據中心是不恰當的
“Zynga的CEO馬克·平卡斯
在上週的電話會議上說 ”我
們打算讓AWS替我們這樣
做“。– GeekWire
該公司週三表示，將關閉
其數據中心然後將計算的
工作負載轉移回AWS，這
為此將削減1億美元成本
– The Wall Street Journal
Zynga放棄資料中心，返回到AWS

6. Condé Nast：拆除傳統資料中心
媒體和出版業
http://aws.amazon.com/solutions/case-studies/conde-nast/
通過將全部系統遷移到AWS，CondéNast 實現如下:
 降低了40％的成本
 提高30-40％的運營效率
 提高業務靈活和敏捷性
在短短3個月， Condé Nast成功遷移以下到AWS雲 :
 約500台服務器
 大概1 PB的數據
 關鍵應用如人事，法務，銷售等等的系統
 將近100餘個數據庫服務器
Condé Nast現在可以更快地創建內容，同時提高創新能
力，生產力，敏捷性，靈活性以及縮短新產品上市時間。

7. AWS遷移策略

8. 發現和采集現有資料中心數據
操作系统版本分析
資源使用率
（CPU，RAM，IOPS，网络））
+ 合適和複雜度 + 雲成熟度 + 業務和服務承諾
多維視野項目範圍
+ 軟件版本分析 + 依賴關係分析 +
业务应用程序
交换机
服务器和数据库
虚拟环境
其他业务服务的依赖关系链接

9. AWS應用发现工具 (App. Discovery Service)
資料中心自動化應用程序發現
 部署代理在源主机：
 支持Windows & Linux
 針對VMware的環境，支持無代理
 抓取系統資源清冊，性能和依存關係
 捕獲的數據安全存放在AWS
 通過API訪問發現系統信息
 導入到CSV或XML
 可以導入協力廠商遷移或可視化工具
發現代理
發現數據庫
AWS Application
Discovery Service
客戶資料中心
加密數據傳遞
互聯網

10. 遷移規劃
測試及整合
執行IT項目組
合評估
重新託管
平臺重構
應用重構
維持現狀
重新購置
A
B
C
規劃 構建
雲就緒
重新策劃
不合適
應用淘汰

11. 應用發現
/評估/優先級
使用遷移工具
重構平台
過渡
生產
保留/不動
重新設計應用
/基礎設施架構
應用程序
代碼開發
購買COTS
/ SaaS的許可
測試
雲遷移模式
修改底
層基礎結構
全面
ALM/SDLC
手工配置
手工部署
手動安裝
退役/
確定遷移路徑
自动
手工安裝
與設置
整合
沒有必然路徑，遷移到雲中可以有許多路徑

12. 應用程序轉換模式
模式標籤 遷移模式 模式描述 场景事例
維持現狀
 不支持的操作系统和应用程序
 没有的业务理由和价值的传统应用程序
 未解決的物理依賴;
 大型機/ AS400;
 非x86 UNIX應用程序.
應用淘汰
 由于并购导致的重复资源
 即将退役的现有资源
 現有退役計劃範圍;
 UNIX，AIX，SCO;
 集群主機用於DR，備用HA主機.
重新託管
 遷移到目標雲的應用程序設置沒有變化
 最小化應用程序佈局更改
 需要進行存儲遷移（不需要轉換）
 UAT - 某些級別的應用程序測試
 物理到虚拟化：V2V，P2V;
 RHEL 5以上版本;
 Win 2008以上版本.
 SAP/Oracle EBS/DB
平臺重構
 操作系統和/或數據庫的升級到目標雲
 需要進行存儲遷移（不需要轉換）
 某些級別的應用程序更改
 應用程序重新安裝在目標上
 UAT強烈推薦
 W2K3到2012年; Win 2008以下版本;
 RHEL5以下版本; Oracle 8到11;
 AIX到Linux (SAP/EBS/DB);
 所有集群（MS集群，DR）;
 MS SQL迁移到RDS.
重新購置
 通过SaaS产品或COTS产品替换应用程序
 购买云兼容许可证
 沒有基礎架構遷移
 CRM到Salesforce.com，HRMS到
Workday
應用重構
 操作系統和/或數據庫移植
 中間件和應用程序更改為雲服務產品
 數據轉換; 數據庫轉換到MySQL，Amazon Aurora
 需要UAT
 Oracle到SQL; SQL到Amazon Aurora
 中間件，IBM產品
遷移複雜性
R2
R1
R3
R4
R6
R5
高
低

13. 組合評分樣本 – 合適度，複雜性，優先級

14. 全面基礎架構平台規劃參考

15. 企业基础与平台服务对照
EC2
Kinesis Lambda DynamoEMR
RDS
SDK CLI AutoScale CF
S3 Redshift Glacier
DX/VGW VPC NACL SG IAM
CloudTrail S3 SNS AWS Config
EC2 EBS PIOPS GP2
KMS HSM SOC1 TDE
ELB SQS
Beanstalk
SGW
EFS
CloudWatch
隔离的网络
审计/监控
文件共享/ NAS/ NFS
数据安全分类
数据存档/数据仓库
实时分析
自动化
典型的企业应用程序

16. 迁移方法和最佳实践

17. 識別遷移應用程序：
 單獨無其它應用程式的依賴關係很容易遷移
 基於SOA與松耦合集成的應用是很好的候選應用
 緊密集成的應用程式需要更多的規劃
 短期絕佳的機會
– 開發/測試應用程式，自炊式的Web應用程式（LAMP堆疊），社交媒體行銷活動產品，培訓環
境，售前演示門戶網站，軟體下載，試用應用程式
 當心場景：
– 32位，非Linux/ Windows的組播傳送（Oracle RAC的），用戶端/伺服器應用程式，專有的系統
（Exadata，Netezza），大量的檔案伺服器，垂直行業應用軟體/應用

18. 基本最佳實踐考慮：
 計算：服務器/虛擬機器，包括RAM，CPU，作業系統，
和開機磁片容量 – 計算，記憶體或硬碟容量密集型考慮
(Amazon EC2)
 存儲對應到事務型，公享，備份，歸檔和日誌/檔案系統/應用
(Amazon EBS, EFS，Amazon Glacier, and Amazon S3)
 資料傳輸出去網絡
 根據安全和性能穩定性要求，確定互聯網或私人網路絡聯接
(AWS Direct Connect and VPN)
 資源所在區域 – 考慮用戶地理位置分佈

19. 工作負載最佳實踐考慮：
 針對每個工作負載提供高可用性
(ELB, Route53)
 針對每個工作負載提供橫向擴展
(ELB, Route53, Auto Scaling, CloudFront)
 針對每個工作負載提供災難恢複
(Multi-AZs)
 針對每個工作負載提供所需IOPS
(General Purpose SSD, Provision IOPS, Magnetic)
 所有計算實例需相應監控和審計
(Security Group, CloudWatch, CloudTrail, Trusted Advisor)
 針對每個工作負載不能支援EBS快照，需提供備份
 最佳協力廠商供應商的封裝應用IDS / IPS，WAF，管理，
監視，日誌記錄等

20. AWS遷移計劃和執行

21.  展開研討會
 明確定義目標基礎設施環
境的架構
 基礎架構設計和審查
 選擇自動遷移工具來支援
相關應用程式部署
資料中心遷移設計與規劃流程
遷移執行計畫
一個定義明確以構建良好的基礎服務的目標環境是關鍵加速上雲遷移的成功因素。
解決方案設計
 確認遷移切割方法
 定義遷移計劃和里程碑
 估計遷移工作量
 建立性能驗證和驗收標
準
 建立遷移檢查清單並執
行計劃
遷移計劃
 開展遷移試點 - 初步試運
行
 完善的自動化工具，流程
和最後衝刺
 確認假設和遷移清單
細化步驟

22. 資料中心遷移執行過程
 準備目標環境的
未來狀態
 部署核心基礎架
構的服務
 設置中央安全管
制 - 帳戶，政策，
安全證書，及許
可權
創建AWS環境
 準備內部基礎設
施遷移準備就緒
 根據優先順序序
列報告，獲取所
有相關的應用程
式的輪廓和鏡像
準備內部就緒
 部署相關應用程
式在目標環境中
 針對AWS資源進
行優化
部署到AWS
 確定資料移轉方
法
 採用並行上傳模
式加速資料傳輸
 測試資料的一致
性
遷移數據

23. AWS及合作伙伴和工具

24. 遷移工具的方法 - 伺服器
主機克隆
 Racemi
 Veeam Backup
 ARCserve UDP
 生產環境
 非關鍵工作負載
 允許停機
線上遷移
資料移轉
 AWS SMS
 CloudEndure
 ATADATA
 生產環境
 關鍵工作負載
 低RTO和RPO
 AWS DMS
 Attunity
 Oracle Golden Gate
 資料庫
 資料倉庫
 關鍵工作負載

25. AWS伺服器遷移工具
Server Migration Services （SMS）
• 支持VMware VM遷移。 （支持其
他虛擬管理程式即將推出）
• 無代理VM遷移
• 捕獲對本地虛擬機進行的增量更改
並自動轉移到AWS
• 同時遷移一組虛擬機並協調多
個遷移
• 采用AWS管理主控台和API /
CLI訪問
• 從Amazon Machine Images
（AMI）啟動EC2實例
Source: on-premises server AWS Server Migration Service Target: Amazon Machine Image

26. 迁移方法 - 数据库
里程碑 数据迁移 数据复制
详细活动
 建立数据迁移
脚本
 进行数据迁移
 展开检测从源
迁移到目标数
据库
 迁移其它数据
到目标数据库
 异步模式
 同步模式
表迁移
 从源数据库迁
移表结构到目
标数据库
 从源数据库迁
移用户帐户和
权限到目标数
据库
 日志传送
预储程序和其他数
据库对象迁移
 从源数据库迁
移预储程序，
函数和其他数
据库对象到目
标数据库
 根据测试计划，
测试已被迁移
的数据库结构

27. AWS 資料庫遷移工具
DMS （Database Migration Services)
VPN
RDS 資料庫
來源資料庫
1. 創建RDS資料庫
2. 創建DMS實例
3. 將DMS連接到源和目標
4. 啟用源附加日誌
5. 在目標資料庫創建和載入資料表
DMS實例

28. AWS Direct
Connect
解决方案提供
商(Aspera,
Riverbed,
Tsunami,
Ctera)
通过互联网上
传到S3
AWS Import
Export
小时
天数
GBs
数据的传送速率
数据的数量
大规模数据迁移方法 - 存储
TBs

29. TCO/資源規劃 遷移/整合工具
驗證工具
優化(性能/成本)
發現工具 服務管理
发现 设计 迁移 整合 验证 运维 优化
建議遷移工具
雲管理服務
監控
持續集成/持續部署
分析 设计 转换 运行 改进

30. AWS大規模資料中心遷移總結

31. 戰略
平臺評估 基礎架構 遷移規劃 基礎部署 健康檢查
成果交付
 資料獲取.
 平臺調研和發現：
 應用分析
 網路結構
 業務連續性
 基礎服務
 安全符合性/策略
 雲下成本分析
 計算服務
 存儲服務
 網路服務
 安全架構
 備份，恢復和歸檔
 監控和運營
 帳戶管理
 負載分析 :
 適合度
 複雜度
 優先級
 總體擁有成本分析
 系統切換方法
 風險評估.
 開發和制定FAT /
UAT測試方案.
 制定遷移準備清單.
 編制遷移工作分解結
構（WBS）
 遷移準備就緒檢查.
 部署基礎設施
 應用遷移
 問題事項記錄
 執行FAT/UAT.
 系統微調和優化
 用戶培訓.
 雲架構設計報告。  系統遷移方法.
 定義遷移順序
 風險因素和規避.
 FAT / UAT測試程式
 遷移防呆計畫.
 實現期望的雲架構
 設定檔和文檔
 經驗總結.
 官方培訓和認證
AWS批量遷移服務路線圖
 檢查實項發現：
 性能
 安全
 可用性
 成本優化
 差距分析
 執行整治.
週期：~4 – 8周* 週期：~2 – 4周* 週期：~2 – 4周* 週期：4 - 8周*
 各項推薦和建議
 各項整治.規劃
 服務執行報告
週期：~2周*
設計 Transition過渡 運營
*注：實際實施時間將根據客戶環境的複雜程度而有所不同。

32. 企業雲上遷移總結
整體遷移評估（業務，安全，平臺，人員，流程，運維，成熟度）
制定詳細的遷移規劃（設計，部署，測試，運營，改進，推廣）
採用AWS最佳技術實踐設計（計算，存儲，網路，安全，監控）
關注80%短期絕佳的機會（松耦合，新系統，研發測試，邊緣應用）
採用自動化遷移和部署工具

33. 非常感謝！