專欄文章

Amazon FSx File Gateway為何而生

既生瑜,何生亮,Amazon FSx File Gateway為何而生

AWS 於近日推出了 Amazon FSx File Gateway 的服務,這種新型態的 File Gateway 經過網路最佳化以及快取技術,讓使用者或應用程式在存取 Amazon FSx 中的檔案時,就如同在使用本地端的 File Server 擁有極低的延遲,並且能節省地端和雲端間所需的頻寬,尤其當有很多使用者會直接使用共享資料夾中的資料時,快取所提供的優勢會更加明顯。

 

既生瑜,何生亮

◆ 舊有的 Amazon FSx 混合雲痛點

有些人心中可能會有疑問,若是混合雲想要使用 Windows File Server,之前 AWS 已經有推出 Amazon FSx for Windows File Server (簡稱:FSx),那麼將雲上的 FSx 透過 AWS Site-to-Site VPN 或者是 AWS Direct Connect 連接地端,不就能滿足需求了嗎?單純從架構上來看是滿足了需求,但實際情況會有痛點,或者說能再優化的地方,因此 AWS 才在 File Gateway 推出了新的服務-Amazon FSx File Gateway。

在之前沒有 Amazon FSx File Gateway 服務時,用戶使用混合雲搭配 FSx 的架構圖如圖一,地端和雲端的連接會使用 AWS Site-to-Site VPN 或者 AWS Direct Connect。

地端和雲端的連接使用AWS Site-to-Site VPN或者AWS Direct Connect

(圖一)

這個架構有兩個明顯需要解決的痛點,第一為地端和雲端間的頻寬會受限於 AWS Site-to-Site VPN 或者 AWS Site-to-Site 的頻寬容量,當有很多使用者時常讀寫相同的檔案時,這些流量都會需要在地端和雲端間往返;第二為延遲的問題,因為讀寫的檔案是在雲上的 FSx,若地端並非在 AWS 的區域 (region) 內時,讀寫檔案的延遲會非常的明顯。

 

◆ Amazon FSx File Gateway 的推出,終結客戶痛點

Amazon FSx File Gateway 的推出解決上述客戶使用混合雲時的痛點,它把雲上 Amazon FSx 組態及檔案結構等放到客戶本地的 Storage Gateway 上,客戶便可以直接在地端掛載 File Server,而其跟雲上的同步則完全由 AWS 處理,因此客戶可以享有雲上 Amazon FSx 全託管的優點,不需自己建立及維護 File Server,但又有極低的延遲以及節省的寬頻用量。

 

◆ Amazon FSx File Gateway 適合的使用場域

因 Amazon FSx File Gateway 的 File Gateway 使用了快取技術再加上其是位於地端,因此下述三種特性的公司特別適合使用 Amazon FSx File Gateway 當地端的 File Server。

1. 地端不在 AWS Region 內的公司:

以台灣為例,台灣不在 AWS Region 內,因此若使用混合雲搭配 Amazon FSx 會有延遲較高的問題,若使用 Amazon FSx File Gateway,不僅可以大幅降低延遲,也可以降低地端和雲端間所需的頻寬以及頻寬的使用量。

2. 頻寬使用量大的公司:

當有很多使用者或應用程式會大量的直接使用 Windows File Server 的資料時,Amazon FSx File Gateway 的快取不僅提供極低延遲的性能表現,也使你的流量不用一直在地端和雲端間往返,只需從地端 File Gateway 的快取進行讀寫即可,如此不僅可以節省使用的流量,也能讓你無須為了應付這些流量而架設較高容量的 AWS Direct Connect 或者是多條 AWS Site-to-Site VPN 以滿足流量需求,如此便能優化成本,減少開支。

3. 在不同地理位置有辦公室,需要使用同個 Windows File Server 的公司:

有些公司在各地有多個辦公室或者分公司,可能跨城市甚至是跨洲,若需要一個解決方案是各個地點的人員都能低延遲的使用同個 Windows File Server 中的檔案時,Amazon FSx File Gateway 可以滿足你的需求,透過在各地建立 File Gateway,這些 File Gateway 會從雲上的 Amazon FSx 共享同樣的 Windows File Server 儲存空間,如此就算是遠在地球兩端的分公司也能共享 File Server,並且享有極低的延遲。

 

另外 Amazon FSx File Gateway 可以搭配 AWS Backup 使用(如圖二),讓你可以將 File Server 中極為重要的資料備份到 AWS S3 做冗餘儲存,大幅降低資料遺失的可能性,使你無須再煩惱如何安全的保存珍貴資料,一切都交給 AWS 幫你透過 AWS Backup 完成。

Amazon FSx File Gateway可以搭配AWS Backup使用

(圖二)

 

Amazon FSx File Gateway 讀取體驗及讀寫測試

這次測試環境的架構圖,FSx 位於 ca-central-1,而 FSx File Gateway 與進行讀寫的 EC2 則位於 us-west-2,透過跨區域的架構凸顯 FSx File Gateway 所提供的優勢。

FSx File Gateway與進行讀寫的EC2則位於us-west-2,透過跨區域的架構凸顯FSx File Gateway所提供的優勢

(圖三)

 

◆ FSx File Gateway 讀取大檔時的優勢

  讀取延遲的部分以下面的影像做展示,讀取的資料分別是:

1. 10k Sales Records-約 10MB 的 csv 檔

2. 1m Sales Records-約 120MB 的 csv 檔

3. 5m Sales Records-約 600MB 的 csv 檔

 

動圖一為 FSx (上方視窗)與 FSx File Gateway (下方視窗) 讀取 10MB 的 csv 檔

FSx (上方視窗)與FSx File Gateway(下方視窗)讀取10MB的csv檔

(動圖一)

 

動圖二為 FSx 讀取 120MB 的 csv 檔 (耗時23.3s)

FSx讀取120MB的csv檔(耗時23.3s)

(動圖二)

 

動圖三為 FSx File Gateway 讀取 120MB 的 csv 檔 (耗時1.8s),比 FSx 快了約21.5s。

FSx File Gateway讀取120MB的csv檔(耗時1.8s),比FSx快了約21.5s

(動圖三)

 

動圖四,FSx 讀取 600MB 的 csv 檔 (耗時106.8s)

FSx讀取600MB的csv檔(耗時106.8s)

(動圖四)

 

動圖五,FSx File Gateway 讀取 600MB 的 csv 檔 (耗時8.5s),和 FSx 的讀取時間差異十分巨大,足足差了約1分38秒。

FSx File Gateway讀取600MB的csv檔(耗時8.5s),和FSx的讀取時間差異十分巨大,足足差了約1分38秒

(動圖五)

 

讀取時間總整
(表一,讀取時間總整)

從以上的測試中可以體驗到兩者檔案讀取時間的差異,尤其在讀取容量較大的檔案時 FSx File Gateway 具有明顯優勢。

在接下來的測試資料中你可以看到 FSx File Gateway 與 FSx 在讀寫兩方面輸送量以及延遲時間的表現差異性,此次測試的使用工具為 DISKSPD

 

◆ 寫入測試

表二為 DISKSPD 測出的寫入詳細數據

DISKSPD測出的寫入詳細數據

(表二)

 

以 FSx File Gateway 的 95th % tile 為例,其意思是在這次測試的數據中第 95 百分位數的 IO 延遲時間為 223.544ms,也就是有 95% 的 IO 延遲時間<=223.544ms。接下來會將上述的詳細數據以圖表呈現,使你容易比對兩者間的差異。

 

圖四為寫入表現的比較圖,圖中分別比較了寫入的輸送量以及平均延遲。

寫入輸送量 FSx 為 97.32 MiB/s,FSx File Gateway 為 261.32 MiB/s;寫入平均延遲 FSx 約為 329.512ms,FSx File Gateway 為 122.57ms。FSx File Gateway 的兩個數據與 FSx 的數據相比皆有亮眼的表現,不僅提供了兩倍多的輸送量,平均寫入延遲也比 FSx 低約 207ms。

FSx File Gateway的兩個數據與FSx的數據相比皆有亮眼的表現

(圖四)

 

圖五為各百分位數寫入延遲比較圖,FSx File Gateway 95% 的寫入延遲<=223.544ms,而 FSx 95% 的寫入延遲<=857.319ms,FSx 甚至有少數的寫入延遲會高於 1583ms。

各百分位數寫入延遲比較圖

(圖五)

 

◆ 讀取測試

表三為 DISKSPD 測出的讀取詳細數據,因為 FSx File Gateway 有快取功能,所以數據分成了 Initial Read 以及 Subsequent Read 兩部分。

DISKSPD測出的讀取詳細數據

(表三)

 

圖六為讀取表現的比較圖,圖中分別比較了初次讀取 (Initial Read) 與隨後讀取 (Subsequent Read的輸送量以及平均延遲。

 

初次讀取:

讀取輸送量 FSx 為 60.3 MiB/s, FSx File Gateway 為 260.93 MiB/s;讀取平均延遲 FSx 約為 530.991ms, FSx File Gateway 為 125.987ms。FSx File Gateway 的兩個數據與 FSx 的數據相比皆有亮眼的表現,平均讀取延遲比 FSx 低約405ms。

 

隨後讀取:

讀取輸送量 FSx 為 62.9 MiB/s, FSx File Gateway 為 701.32 MiB/s;讀取平均延遲 FSx 約為 506.556ms, FSx File Gateway 為 45.626ms。FSx File Gateway 的平均讀取延遲比 FSx 低約 460ms。從圖六也可以看出 FSx File Gateway 隨後讀取的效能表現不論是輸送量或者是延遲都比其初次讀取更加優異。

FSx File Gateway隨後讀取的效能表現不論是輸送量或者是延遲都比其初次讀取更加優異

(圖六)

 

圖七為各百分位數初次讀取延遲比較圖,FSx File Gateway 95% 的讀取延遲<=65.962ms,而 FSx 95% 的讀取延遲<=1737.684ms,兩者延遲的差距非常明顯,但 FSx File Gateway 少數發生 cache miss 時寫入延遲會變得比較高

各百分位數初次讀取延遲比較圖

(圖七)

 

圖八為各百分位數隨後讀取延遲比較圖,FSx File Gateway 95% 的讀取延遲<=59.1ms,而 FSx 95% 的讀取延遲<=1504.612ms。FSx 因為沒有快取的關係因此初次讀取與隨後讀取的延遲表現差不多,測試中延遲最高幾近7.4秒,但FSx File Gateway 在隨後讀取時 99.99% 的延遲時間<=109.846ms,延遲表現十分的傑出。

各百分位數隨後讀取延遲比較圖

(圖八)

 

圖九將 FSx File Gateway 初次讀取與隨後讀取的延遲表現整合成一張圖,可以明顯的看出它在隨後讀取所提供的超低延遲特性

FSx File Gateway初次讀取與隨後讀取的延遲表現

(圖九)

 

總結

Amazon FSx File Gateway 將雲上 Amazon FSx 延伸到你的地端,使你可以輕鬆使用原生的 Windows File Server,不用擔心如何佈建及維護,AWS 完全幫忙管理、自動的同步資料到雲上的 Amazon FSx For Windows File Server,因此你可以同時享受極低的延遲以及雲上的優勢。Amazon FSx File Gateway 的快取技術使你的流量不用一直經過 AWS Site-to-Site VPN 或者是 AWS Direct Connect,對於讀寫量大的客戶可以大幅的節省頻寬的使用以優化成本。

 

綜合上述的優點,若你的公司具有以下其中一種特性並在尋找 Windows File Server 的解決辦法,Amazon FSx File Gateway 是你絕佳的選擇。

1. 公司位於 AWS Region 之外

2. 公司對 File Server 的讀寫量大

3. 公司有多個辦公室需要共用 File Server

 

 

最新文章

加入 Line 好友 加入 Line 好友 歡迎來聊聊 寄信給我們 訂閱電子報
joinline