Day 24 - 混合雲架構
[TOC]
混和雲架構
我們先說說看混和雲的存在必要。
天下合久必分,分久必合。
全部的服務上公有雲,不就結束了?
但是實際情況是,有些資料真的不能上雲,也因為一些法規讓資料可能無法保存在國外。
再來是搬遷成本,企業累積 10 年以上的資訊系統要在一朝一夕全部上雲是不可能的。
混和雲具備彈性,讓你有需要的時候在來使用雲端資料,也可以跟本地伺服器現有的資料與服務做溝通。
這裡書上提到了,混和雲的三個階段:
網路穩定 -> 資料同步 -> 應用程式同步
Multi-Site 解決方案
有沒有想過當流量來了,公有雲的應用程式跟各個服務都不會壞掉嗎?
我想這個答案應該沒有人能保證,如果服務失效造成的商業損失,第一是損失估計難以估計,第二是就算估算出來了跟公有雲打官司勞財傷民又浪費時間,還不一定能拿到賠償。
與其這樣公司不如也準備一個機房,除了讓公有雲壞掉的時候能不讓公司服務掛掉增加可用性,在平常的時候做分流分擔雲端的運算。
Multi-Site 會遇到的挑戰如下:
- 本地應用倒入雲端
- 資料同步傳輸
- 網路傳輸穩定與安全
這幾項 AWS 都有對應的服務可以解決。
Direct Connect
首先需要確保 網路品質 有這幾種: 傳輸穩定、封包安全。AWS 與本地 ISP 廠商推出了 Direct Connect。
可以將本地機房與 ISP 業者拉一條專線,然後由 ISP 將此專線的流量直接上雲,其簡易的流程如下:
可以確保重要資料直接輸入 AWS 或是從 AWS 傳出,繞過 ISP 且同時避免網路壅塞。
Storage Gateway
確保網路品質後,接下來就是確保 資料同步 。通常公司一定會有 NFS 系統,透過 Storage Gateway 可以在本地環境模擬一個 NFS,當資料存到這個模擬的 NFS 就會透過 Storage Gateway 同步資料到雲端。
有以下三種閘道:
- File Gateway
- 將檔案上傳至 S3。
- Volume Gateway
- 將檔案自動上傳到 EBS 的 Volume 或 Snapshot。
- Tape Gateway
- 將檔案自動上傳至 Glacier。
FSx
通常公司都有已經現有的文件系統,Amazon FSx 讓您可以在四種廣泛使用的文件系統進行選擇:
- NetApp ONTAP
- OpenZFS
- Windows File Server
- Lustre。
通常基於您對給定文件系統的熟悉程度,或將文件系統的功能集、性能配置文件和數據管理功能與應用程式匹配。
若你的應用程式牽扯到一些特定文件系統的功能或函式庫,這時候你就應該使用 FSx ,可以保持應用程序的兼容性而不改變管理數據的方式。
VM Import/Export
可以將本地機房跟 EC2 的 Instance 做交換或同步。
可以匯入 VMware ESX 或 Workstation、Microsoft Hyper-V 以及 Citrix Xen 虛擬化格式的 Windows 與 Linux VM。匯出可以使用 AWS CLI 作為工具來匯入到 AWS 雲端。
也可以將 EC2 執行個體匯出為 VMware ESX、Microsoft Hyper-V 或 Citrix Xen 格式。