.jpg)
Amazon GuardDuty 安全監控資安服務
2021-11-05
自疫情爆發以來，在疫情的影響下，提前布局產業數位轉型、上雲已成為各家企業相繼關注的焦點，在眾多雲端服務當中，Amazon Web Services ( AWS ) 仍然是各家企業的首選，隨著企業主使用愈來愈多 AWS 雲端服務，建立複雜的雲端架構來達到各家企業的業務目標，資訊安全的相關建構變得愈發重要。 AWS 致力於維護資訊安全，提供多元的資安服務供企業選擇。但資安要做到層層把關，密不透風的保護是相當不容易的事情，如果能夠偵測威脅來自哪裡、針對偵測到的威脅做妥善處理，對症下藥的持續監控方式是比較實際的做法。 在 AWS 眾多服務中，有一項資安服務能夠持續安全監控企業的雲端環境，偵測雲端環境中未經授權危害資安的威脅，此項服務名為 Amazon GuardDuty。 GuardDuty 可分析和處理多個 AWS 資料來源（VPC Flow Logs、AWS CloudTrail Management Events、CloudTrail S3 Data Events 和 DNS Logs）中的多重事件，無需部署或維護軟、硬體即可使用。GuardDuty 利用威脅情報源（例如:惡意 IP 的列表）和機器學習以識別 AWS 環境中未經授權危害資安的活動。 GuardDuty 本身會自動創建一個基於時間日期的文件夾架構，並藉由 Lambda 重新組織排列文件夾架構。此排列方式是 GuardDuty 針對偵測監控而組織的排列結果 (Finding Type)。重新組織後，將視圖傳送至 QuickSight，使用者能更輕鬆的將想關注的監控結果視覺化。 企業只要在選定的區域開啟 GuardDuty，就可將 GuardDuty 監控結果提取至 Amazon Simple Storage Service (Amazon S3) 中，使用 Lambda 重組 S3文件夾結構，並透過 Glue 和 Athena 將嵌套的 JSON 結構轉換並產出相對應的列表與資料，最後透過 QuickSight 分析並將結果視覺化，同時可下載分析結果。此架構流程提供易執行且高效率的解決方案，可用於分析 GuardDuty 的監控結果，廣泛地展示處理和視覺化多元類型複雜的 JSON 日誌。 (GuardDuty Finding Type 內容樣貌) (視覺化範例) 當企業長期使用 AWS 的雲端服務，資訊安全的維護變得愈來愈重要，藉由使用 GuardDuty 加強 AWS 的雲端服務資安層級，建立一項持續安全監控的服務以識別雲端環境中未經授權的危害資安的惡意活動，並透過分析好的內容判斷和識別潛在的資安威脅，進而達到對症下藥的資訊安全防護措施。 身為企業的雲端數位長，CKmates 的使命是與企業並肩前行，企業只要專注於創造商業價值，將雲端服務託管於CKmates，以實現系統整合性和資安防護同時並進，企業得以持續成長、穩固前行。 白皮書下載：AWS GuardDuty 雲端環境持續安全監控服務
為什麼企業需要雲端託管服務 (Cloud Managed Service) ?
2021-10-07
今年在疫情的推波助瀾下，加速數位轉型儼然成為企業在 IT 投資上的優先，在眾家業者當中，Amazon Web Services ( AWS ) 依舊穩坐雲端市場的領先地位，隨著 AWS 的採用率不斷提高，世界各地的企業都在重新定義他們的數位轉型之路。 在數位轉型的路上，全球企業啟動以雲為中心的數位基礎架構，採用以雲為中心的策略改變了企業內部文化與 IT。起初企業擔心內部是否將受到不可預測的影響，但透過新世代雲端託管服務 (Managed Service Provider, MSP)，企業在服務上雲後，透過專業顧問服務進行即時監控、優化整體成本支出，企業、員工更了解雲的價值，使其專注於業務重大發展、解決疑慮。 圖：Apps Associates 針對 MSP 對 IT 決策者的調查結果。 根據 App Associates 針對300位以上的 IT 決策者進行調查，發現超過86%的 IT 決策者表示期待 MSP 對企業 IT 環境有更佳保護及期待透過 MSP 服務讓企業與 IT 人員更專注於重大發展，非基礎設施。 MSP 服務解決您面臨的挑戰 對於許多客戶來說，尤其是醫療保健、金融服務、生命科學和政府部門而言，AWS 上的作業和應用程序的安全性和合規性是其最關注的事情，這些行業都有自己的安全協議和政策，隨著時間的推移而變化，安全及自動化是 MSP 實踐中關鍵的項目，根據客戶需求量身建置 AWS 架構並遵照 Well-Architected 設計，以符合 AWS 安全最佳實踐。 MSP 服務應有明確的維護、安全、監控、報告的 SLA 約定，該 SLA 反應出企業對 MSP 的期望，回應時間、性能和安全規範也應包含在服務協議中。 在節省成本的同時實現數位轉型 MSP 夥伴所提供的服務不僅僅是維護企業的系統或服務穩定運行，更應有 24/7/365 持續地網路監控、故障排除與主動管理，為企業把關系統告警，以確保業務連續性。MSP 亦定期提供任何優化性能、架構、安全或節省成本的建議。企業通常考慮採用 Amazon EC2 預留實例 (RI) 或 Savings Plans 來節省雲端成本，同時提供客戶資源使用建議，消除不必要的成本或所需資源。 企業需要一個 MSP 合作夥伴，為 IT 管理導航、指路，透過持續地網路監控、故障排除與主動管理，提供企業穩定的營運系統。CKmates 擁有24/7/365的 NoC 團隊、技術團隊更是擁有100+以上的 AWS 專業級/專家級認證，為許多客戶提供MSP 服務。 CKmates 的使命始終是與企業並肩而行，成為企業的雲端數位長，企業只要專注創造商業價值，將雲端託管予 CKmates，以實現系統高可用及資安合規，企業得穩固前行。
.jpg)
【雲端遷移專欄 VI】剖析AWS原生遷移工具 MGN & SMS & VM Import/Export
2021-09-02
如何更快速達成您的業務目標，數位轉型、敏捷、創新是所有產業都不陌生的話題。然而，管理複雜的應用程式和工作產品組合，並非易事，故快速行動和實現價值的能力是關鍵的成功因素。而透過 AWS 雲端服務，不僅提升技術與組織效能，更能讓企業運用最新數位服務，提升效益。 在用戶決定遷移至 AWS 雲端後，如何安全並輕鬆地將工作負載遷移到 AWS，並減少遷移停機時間，是企業最關心的問題。AWS 提供 3 種免費託管遷移工具 : AWS Application Migration Service (MGN)、AWS Server Migration Service (SMS) 和 VM Import/Export。 MGN 和 SMS 是 AWS 託管服務，因此可以完全從 AWS 控制台內集中操作，而無需使用外部帳戶或其他帳戶。 VM Import/Export 是 AWS 的指令型工具， 熟悉的專業人士可極度利用其強大功能。 基於以上三種 AWS 遷移工具 ， 客戶往往難以選擇哪種服務最適合他們的遷移情境。因此本篇將著重於解析這三種服務的差異性，協助您做選擇，實現快速且安全的遷移至雲端。 ■ 要遷移什麼類型的基礎設施？ 2021 年 5 月 18 日 AWS 正式宣布推出 AWS Application Migration Service (MGN)，遷移前企業應先考慮原基礎架構， MGN 是基於併購 CloudEndure 的整合服務，只要計劃遷移的目標可在 AWS EC2 支援的 x86 操作系統上運行即可使用 MGN。這包括實體伺服器、P2V、VMware、Hyper-V 和其他雲提供商等。 （圖1－AWS MGN (CloudEndure) 遷移，是一種 Agent 代理遷移服務， 可將本地硬體、虛擬的伺服器遷移至 AWS 執行） AWS Server Migration Service (SMS) 支援從 VMware、Hyper-V 或 Microsoft Azure 遷移 VM 虛擬機。 AWS SMS 目前不支援實體基礎設施或除了 Microsoft Azure 之外的其他公有雲。 （圖2－AWS SMS 遷移，是一種 Agentless 使用 Connector 的遷移服務，可將虛擬伺服器遷移至 AWS 執行） 如果您要遷移的資料量龐大或傳輸頻寬不能符合轉換到雲端的時程期限，則可考慮使用 VM Import，先將 VM 拷貝至移動硬碟，再另尋高速傳輸上傳使用 VM Import 至 S3。 （圖3－AWS VM Import/Export） ■ 需要 Agent 代理還是 Agentless 無代理解決方案？ AWS MGN 遷移要求您在每台來源 Server 或虛擬機上單獨安裝 Agent。Agent 僅將任何 Block 的更新，寫入並同步到Replication Server。Agent 需要使用 MGN 用戶控制台在 TCP 端口 443 與 TCP 端口 1500 進行出口訪問。 （圖4－AWS MGN Agent installation on each server） AWS SMS 使用 SMS Agentless Connector 不同於 MGN Agent，這是一個預配置的 FreeBSD 虛擬機，在遷移開始之前， 將其安裝在來源中的虛擬化環境管理程序上 (如 vSphere vCenter， HyperV console)。SMS Connector 負責 Snapshot，將它們發送到 AWS SMS，並將它們轉換為 Amazon 系統映像 (AMI)。 （圖5－AWS SMS Connector installed on vCenter） 在某些情況下，如果您無法滿足某些 MGN Agent 要求, 則 AWS SMS 更適合。 例如： ● 可能無法在源計算機上擁有管理員訪問權限來安裝 Agent 代理 ● 可能只是更喜歡較少操作設定的 Agentless 解決方案 ● 企業資安風險考量 ■ 多久需要複製一次源環境？ ● AWS MGN 利用持續的 Block level 複寫，是以分鐘為單位的複製排程。 ● AWS SMS 利用增量、基於 Snapshot 的複寫，是以小時為單位的複製排程。 ● 由於 AWS SMS 使用基於 Snapshot 的複製，後續 Snapshot 是增量拍攝的，與 MGN 不同，不需要暫存區來接收複製數據。AWS SMS 與 AWS MGN 都能夠恢復失敗的複製作業。 ■ 加密 AWS MGN 支持靜態和傳輸中的加密。對傳輸中的加密，MGN 使用 AES-256 加密來源環境中的代理和複製服務器之間的複製流量。流量使用 TCP 端口 1500 傳遞。靜態加密，MGN 提供在暫存區存儲加密卷的選項，您可以選擇默認加密密鑰或自定義 KMS CMK 密鑰。 （圖6－MGN (CloudEndure) volume 加密） AWS SMS 在區域中創建一個 Amazon S3 存儲桶，啟用 Server endpoint 加密和 Storage bucket policy 以在 7 天後刪除存儲桶中的任何項目。配置複製作業時，您可以選擇啟用 AMI 默認 CMK 加密。TLS 1.2 在傳輸過程中對複製的 Server volume 進行加密。 ■ 準備您的環境 建議您在準備環境時採用下列最佳做法，讓遷移後的啟動作業順暢。 ◆ 帳戶設定：確保只有執行移轉的人員可以控制移轉，包括執行、監視及維護移轉 ◆ 停用電子郵件通知：停用所有移轉通知電子郵件，避免收到有關移轉、失敗、進度等測試電子郵件 ◆ 主機環境預備：關閉 Firewal，相依關係設定等 ■ 需要什麼設定來啟動目標環境？ 在許多情況下，客戶運行 Discovery 發現工具（如 Migration Evaluator 又稱 TSO Logic）來收集有關本地數據中心的信息，如服務器利用率、依賴關係或總擁有成本 (TCO) 估計，並推薦 Amazon EC2 實例類型和配置。AWS MGN 和 AWS SMS 都以不同的方式包含這些功能。 AWS MGN 使用 Blueprint 藍圖設置用於創建目標機器。使用 Blueprint，您可以自定義 EC2 屬性，例如：機器類型、啟動類型、子網、安全組、私有或公共 IP、磁盤類型等。 AWS MGN 也支持使用 BluePrint 大量設置程序腳本，然後使用該配置啟動目標機器。 （圖7－MGN Launch 設定） AWS SMS 支持類似的功能，遷移是通過將單個 Server 複製為 Amazon 系統映像 (AMI) 來完成的，並生成 CloudFormation 模板以協調方式啟動它們。SMS 為應用程序設置生成一個 CloudFormation 模板，您可以下載、編輯和用於以後啟動。 （圖8－SMS Replication Dashboard） 如果您需要導入 Discovery 工具來設置啟動目標機器，那麼 MGN 是正確的工具。如果您需要生成遷移環境是可重用 CloudFormation 模板，那麼 SMS 是正確的工具。 ■ 災難恢復 (DR) 雖然 AWS MGN 不是為 DR 災難恢復目的而設計的，但當決定遷移整個工作負載，可採用 MGN 進行 Disaster Recovery，MGN DR 亦支持 AWS 內的區域到區域災難恢復。 如使用 MGN DR， 則按每台源服務器以小時計費，收費與配置的存儲容量無關。每部伺服器每小時 0.028 USD，或預估的每部伺服器每月 20 USD。 銓鍇國際 CKmates 協助知名企業成功搬遷至 AWS 後疫情時代來臨，數位轉型成為企業面對多變環境的強力後盾，靠雲端加速轉型邁向全球佈局。銓鍇國際 CKmates 擁有多年實體機房維運與 AWS 雲端經驗，不僅成功為多家上市櫃公司完成雲端遷移、架構規劃、優化等服務，更始終致力於針對各產業之痛點提供最適切之解決方案。更於今年獲得 AWS Migration Competency 遷移能力認證，透過遷移上雲，使企業能夠更敏捷彈性的因應未來挑戰，而 CKmates 也將與企業並肩而行，成為企業的雲端數位長。 雲端遷移系列專欄 Why migrate to the AWS Cloud? 想要雲端遷移？資深雲端架構師親自傳授遷移心法 影響雲端遷移成功的關鍵因子：「評估策略」與「完善計畫」 善用 AWS 原生遷移工具 使雲端遷移事半功倍 使用 AWS Database Migration Service 快速協助異質資料庫遷移 剖析 AWS 原生遷移工具 MGN & SMS & VM Import/Export
【雲端遷移專欄V】使用AWS Database Migration Service快速協助異質資料庫遷移
2021-08-02
雲端遷移是項非常繁瑣的過程，如何降低資料遷移困難與複雜度是企業最關注的重點之一。 傳統資料庫遷移方法相當複雜且曠日廢時，經常需要暫停資料庫運作長達數天甚至是數週，在這段遷移工作執行時對資料庫的操作都必須禁止，導致遷移工作需要耗費大量的時間與資源。 同質資料庫的轉移（例如 MySQL to MySQL）就需要消耗一定的時間成本，若為異質資料庫的轉移，對各種資料型態、索引、結構敘述資料及函數進行全人工的轉換，從而增加更多時間與資源的耗損。如果在遷移過程中有人工疏失，很有可能會導致前功盡棄，實在是所費不貲。 為此，AWS 提供了 Database Migration Services（DMS）的資料庫自動化遷移服務，能夠以自動化的方式遷移至同質資料庫（例如 MySQL to MySQL）或至異質資料庫（例如 MySQL to DynamoDB），甚至提供當次遷移任務後持續進行資料的遷移，持續讓來源及目標遷移資料庫保持同步狀態。 AWS Database Migration Service (AWS DMS) Database Migration Services（DMS）異質資料庫遷移 演示之資料庫： 在地端：MySQL AWS 端：DynamoDB 在這裡我們可以看到，我們所演示的遷移來源資料庫是 MySQL 的 dms_source 資料表，此資料表所需之遷移筆數共為 85621 筆。 這裡我們也能看到在 AWS 雲端，我們已經建立好 AWS 端的 DynamoDB 資料表，準備執行 MySQL 至 DynamoDB 的異質資料表遷移任務。 在這邊我們只需要撰寫 MySQL 至 DynamoDB 的結構映射組態檔，就能夠執行異質資料庫的遷移轉換任務了！ 由於複寫的動作需要有複寫伺服器實例來執行，故我們需要在 AWS DMS 服務下建立新的複寫伺服器個體： 指明複寫伺服器名稱及執行實例的專用運算型別（例如：dms.t2.medium） 指明遷移任務的伺服器實例儲存容量、VPC、Multi-AZ 及公開性 在這個階段我們需要將來源資料庫及目的資料庫之相關資訊，設定於 AWS DMS 之端點設定上，之後方能設定最後的遷移任務細節。 設定遷移的來源（MySQL）及目的（DynamoDB）資料庫端點資訊 AWS DMS 之遷移任務組態如複寫伺服器、來源端點、目標端點及同步設定 在此可以設定在遷移任務後，是否持續同步來源及目的資料庫的資料 任務建立完畢並開始執行，將開始等待遷移任務進行映射及載入 AWS DMS 任務完全載入成功且沒有發生錯誤 載入時間總計 514 秒（8 分 34 秒），平均一筆紀錄遷移時間為 6ms 可以看到所有資料列皆已被遷移至 DynamoDB 的 employees 資料表上，若是有更大型的資料或需要縮短遷移的時間，則可以考慮： 使用更強的運算型別 使用更大的實例儲存空間 使用 Direct Connect 專線，強化在地端與雲端的資料傳輸品質 定價部分為： 運算實例型別 實例儲存空間 GB 數 跨 Region 或 On-Prem 至 AWS 之資料傳輸費用 除了工具，您更需要透過合作夥伴進行完整遷移任務 AWS DMS 的自動化遷移能力，幫助我們大量降低遷移各種資料庫上雲時所需的時間與精神，減少人為介入所造成的影響同時也能夠直接使用 AWS 已經為我們考慮到的各種遷移功能。 CKmates 具有豐富的遷移經驗，我們也活用 AWS DMS 工具降低遷移的風險與時間成本，協助許多客戶成功遷移上雲。 從評估企業雲端準備程度、盤點營運系統、規劃遷移項目、遷移策略及順序等，規劃出完善的架構並執行遷移，搬遷完成後進行維運與優化等，CKmates 皆具有完整的遷移方法與知識。 遷移上雲後，享受各種雲端優勢，讓您能夠去除繁雜的 IT 維運及設施運作，專注於跟企業價值有關係的核心業務上，提升企業競爭力。 雲端遷移系列專欄 Why migrate to the AWS Cloud? 想要雲端遷移？資深雲端架構師親自傳授遷移心法 影響雲端遷移成功的關鍵因子：「評估策略」與「完善計畫」 善用 AWS 原生遷移工具 使雲端遷移事半功倍 使用 AWS Database Migration Service 快速協助異質資料庫遷移 剖析 AWS 原生遷移工具 MGN & SMS & VM Import/Export
既生瑜，何生亮，Amazon FSx File Gateway為何而生
2021-07-02
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 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 讀取體驗及讀寫測試 這次測試環境的架構圖，FSx 位於 ca-central-1，而 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 讀取 120MB 的 csv 檔 (耗時23.3s) （動圖二） 動圖三為 FSx File Gateway 讀取 120MB 的 csv 檔 (耗時1.8s)，比 FSx 快了約21.5s。 （動圖三） 動圖四，FSx 讀取 600MB 的 csv 檔 (耗時106.8s) （動圖四） 動圖五，FSx File Gateway 讀取 600MB 的 csv 檔 (耗時8.5s)，和 FSx 的讀取時間差異十分巨大，足足差了約1分38秒。 （動圖五） （表一，讀取時間總整） 從以上的測試中可以體驗到兩者檔案讀取時間的差異，尤其在讀取容量較大的檔案時 FSx File Gateway 具有明顯優勢。 在接下來的測試資料中你可以看到 FSx File Gateway 與 FSx 在讀寫兩方面輸送量以及延遲時間的表現差異性，此次測試的使用工具為 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 95% 的寫入延遲<=223.544ms，而 FSx 95% 的寫入延遲<=857.319ms，FSx 甚至有少數的寫入延遲會高於 1583ms。 （圖五） ◆ 讀取測試 表三為 DISKSPD 測出的讀取詳細數據，因為 FSx File Gateway 有快取功能，所以數據分成了 Initial Read 以及 Subsequent Read 兩部分。 （表三） 圖六為讀取表現的比較圖，圖中分別比較了初次讀取 (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 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 初次讀取與隨後讀取的延遲表現整合成一張圖，可以明顯的看出它在隨後讀取所提供的超低延遲特性。 （圖九） 總結 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
【SAP on AWS專欄 III】SAP Business One on AWS 實現業務敏捷
2021-06-02
中小型企業現在可以在 Amazon Web Services (AWS) 雲端享受 SAP Business One 的所有優勢。尤其是 SAP 已測試並認證了 SAP Business One, version for SAP HANA 可在 AWS 上進行正式環境部署。 SAP Business One 是一套 SAP 面向中小企業的 ERP 軟體產品，其價格合理、功能齊全、操作簡便，是一套適合中小企業目前業務需求及未來成長需要的 ERP 管理軟體。目前，SAP Business One 支援50種本地化版本 (Localization)、28種使用者介面語言，可被廣泛地應用在170個以上的國家，且目前在全球已有超過70,000家企業使用。 AWS 與 SAP 自2008年開始合作，已擁有超過10年以上的經驗；且從2011年以來，AWS 受到 SAP 的認證，支援 SAP 的各種應用程式。包含大型企業的數百間客戶，目前全球已有5000家以上的客戶在 AWS 上運行 SAP 相關架構/系統，且這數字不斷地在成長。 ● SAP Business One on AWS 優勢 根據 AWS 與全球 SAP 客戶合作的結果，降低整體擁有成本(TCO)、快速且彈性、提高創新能力、遠端辦公，是客戶將 SAP 遷移雲端的主要因素。 降低整體擁有成本 (TCO) 與傳統的地端基礎架構相比，AWS 提供了可靠且安全、並經過 SAP 認證的雲端平台，使企業能夠快速部署 SAP 解決方案，並將運行 SAP 系統的整體擁有成本降低多達71%。 快速且彈性 透過 AWS，您可以快速輕鬆地部署基礎架構及建置 SAP Business One (支援 Version for MS SQL，或 Version for SAP HANA)。您不需要再猜測硬體架構容量的需求，可以因應系統環境變化來擴展或縮減資源，以滿足 SAP的 Sizing 需求。 提高創新能力 藉由 AWS 全託管服務，減少資料中心/機房維護的麻煩，可使企業更專注在研發創新上。 遠端工作 疫情來襲，企業營運不中斷，您除了可以享受 AWS 所帶來的高彈性、高可用性、隨用隨付等特性外，透過 Amazon Workspaces 隨時隨地在任何設備上處理 SAP Business one 重要工作。 ● 支援的軟體版本及部署模式 可依據您使用的版本來選擇下列其中之一的部署方式： ■ SAP Business One, version for MS SQL ◎ Single Deployment 並採用 Amazon Workspaces 遠端工作 ◎ Distributed Deployment 並採用 Amazon Workspaces 遠端工作 ◎ High Availability Deployment ■ SAP Business One, version for SAP HANA ◎ Single Deployment (without installing Browser Access and B1i) 採用 Amazon Workspaces ◎ Distributed Deployment (with installing Browser Access and B1i) 並採用 Amazon Workspaces ◎ High Availability Deployment (with installing Browser Access and B1i) 在 AWS 上進行 SAP 遷移與部署需要豐富經驗的合作夥伴進行完整的規劃以及執行，CKmates 為企業建置 AWS 基礎架構來執行 SAP Business One 並遵循 AWS 最佳實務、監控資料庫使用情況，以減輕人力管理負荷，CKmates 亦提供概念性驗證（POC）驗證滿足企業需求後進行 SAP 遷移與部署。 SAP on AWS 系列專欄 【SAP on AWS專欄 I】選擇 AWS 執行 SAP 加速創新及轉型 【SAP on AWS專欄 II】AWS Launch Wizard 加速 SAP 部署 【SAP on AWS專欄 III】SAP Business One on AWS 實現業務敏捷
【SAP on AWS專欄 II】AWS Launch Wizard 加速 SAP 部署
2021-05-03
AWS 從2008年開始協助全球許多 SAP 客戶將 SAP Workload 遷移到 AWS，歷經13年以上的時間與經驗， AWS 傾聽客戶的聲音並將其反饋融入至 AWS 平台，藉此改善 SAP on AWS 的體驗。在此期間許多客戶期望能更快速、更容易地部署他們的 SAP 環境。 於是，AWS 於2019年的 re:Invent 發佈了 AWS Launch Wizard 服務，一個可以讓 SAP 使用者透過精靈的步驟，選擇 EC2 執行個體、環境參數設置、軟體安裝選項的方式來部署 SAP HANA 或 SAP HANA-based NetWeaver 的系統在 AWS 上，使用 AWS Launch Wizard 無需額外費用，只需為其創建的資源付費。 ● AWS Launch Wizard 加速且輕鬆部署 SAP 節省環境部署的時間 經過 SA P認證的 Amazon EC2 執行個體：可依 CPU/Memory 或 SAPS 需求來選擇適合 SAP 系統的 EC2 AWS Launch Wizard 會根據所選擇的部署架構，為架構內不同角色的伺服器（如：ASCS、ERS、PAS、AAS、以及 HANA Database）適當地分配 Amazon EBS 儲存空間 依需求選擇是否安裝 SAP NetWeaver-based Application 或 SAP HANA Database；若選擇進行軟體安裝，整個環境部署只需花費二小時左右的時間即可完成 對於 SAP HANA 伺服器，可結合 AWS Backint Agent（免費）軟體的安裝，往後可以更容易透過 SAP HANA Cockpit、SAP HANA Studio、以及 SQL Command，進行 SAP HANA 資料庫的備份（至 Amazon S3）及還原（自 Amazon S3） 根據數千個 SAP on AWS 部署的最佳實踐，為 SAP 系統提供 AWS 服務的資源選擇和成本估算 ● 支援的部署模式及軟體版本 ■ SAP 軟體支援模式 ■ SAP 軟體支援版本 ■ 可根據需求（如：開發、測試、QA 或正式環境）選擇不同的部署架構 ■ 軟體安裝路徑設置 AWS Launch Wizard for SAP 重點發展歷程 Source: https://reurl.cc/WEnOM7 銓鍇國際 CKmates 協助您…… ✓ 進行遷移概念性驗證（Migration POC） ✓ 申請 AWS Credit 折抵 AWS 費用 ✓ 選擇 3 年的 RI （Reserved Instance）或 Saving Plan，享費用 1/3 的補助 看看更多 CKmates 客戶進行 SAP on AWS 的成功經驗： 大江生醫－透過 AWS 發揮 SAP HR 系統的優點 SAP on AWS 系列專欄 【SAP on AWS專欄 I】選擇 AWS 執行 SAP 加速創新及轉型 【SAP on AWS專欄 II】AWS Launch Wizard 加速 SAP 部署 【SAP on AWS專欄 III】SAP Business One on AWS 實現業務敏捷
【SAP on AWS專欄 I】選擇AWS執行SAP加速創新及轉型
2021-03-29
● SAP on AWS 時勢所趨！ 在全球，在台灣，愈來愈多的企業組織選擇將 SAP 工作負載遷移至雲端。這些在 AWS 雲端上執行 SAP 的公司，對於大幅節省 IT 成本，生產力、業務靈活性和營運彈性等方面都獲得提升，表現出很高的滿意度。 IDG 調查發現，企業組織在 AWS 上執行 SAP 的時間愈長，滿意度愈高。節省成本是促使遷移的主要動力，96%的客戶表示，整體擁有成本 (TCO) 有所降低，且平均總體節省了26%。 AWS 擁有超過12年執行 SAP 工作負載的經驗，累積超過5,000名的 AWS 客戶執行 SAP on AWS，其中有一半以上的客戶在 AWS 上部署以 SAP HANA 為基礎的解決方案。IDG 調查更發現，將近三分之二的客戶計劃將其它 SAP 解決方案遷移至 AWS。 SAP on AWS 所支援的解決方案： ● AWS for SAP 優勢 ■ 經驗 自2008年以來，AWS 透過協助數千個客戶遷移 SAP 工作負載而獲得了專業知識。此外，AWS 擁有30多個獲得 SAP 技能的合作夥伴，展示了他們的技術水準以及在 AWS 雲上使用 SAP 應用程式的成功經驗。 ■ 技術 AWS 擁有多達 480k 的 SAP Application Performance Standard（SAPS），是其他雲供應商認證的兩倍，及擴展能力的三倍。 ■ 服務範圍 AWS 是合規性認證和安全功能的領導者，擁有1,430個客戶驅動的服務和功能。 ■ 經 SAP 認證之執行個體 AWS 包含經過 SAP 認證的130多種執行個體類型。所有執行個體所支援的記憶體，從 4GiB 到 24TB，並支援S/4HANA 擴展至 48TB，支援 BW/4HANA 擴展至 100TB，並且有多項基於 Intel 最新硬體和技術的 SAP 認證選項。 ● 擴展服務應用 您可以使用 AWS 其它服務，整合 SAP 業務流程與大數據和分析，物聯網（IoT），Apps 和 API，DevOps 和機器學習來進行擴展，進而推動企業轉型。 整合類型： ■ Apps and APIs API 提供了敏捷，靈活，安全和可擴展層，用於整合各種企業應用程式，並為所有客戶的使用者界面和整合需求提供易於使用的服務。 ■ 物聯網 (IoT) 透過 AWS 提供的物聯網服務可幫助客戶收集數據並將其發送到雲端，載入和分析該資訊以及管理設備。 ■ 大數據和分析 透過大數據的管理及分析，整合 SAP 數據，能讓您更好的理解、洞察客戶的數據，進而分析客戶並找出更好的應對策略。 ■ DevOps DevOps 是文化理念，實踐和工具的結合，可以提高客戶應用程式交付的速度。 ● SAP on AWS 效益 ■ 降低營運成本，提高營運效益 當您在採購硬體設備時，不論其目地是正式、測試、或是開發環境，您需要預先付出IT資源及為了硬體 Sizing 能否滿足系統需求而傷透腦筋，如果購買時規格開的太高(貴)，是否曾擔心屆時實際用量不如預期而造成資源浪費？反之，如果規格開的太低(便宜)，是否擔心系統效能會受影響？ 藉由 AWS 的 Pay As You Go (按用量付費) 模式，讓您免去等待硬體設備到貨的時間，可以快速建立所需要的 AWS EC2 執行個體進行系統的安裝、測試、及部署；若是進行概念驗證 (POC)，完成後即可刪除 AWS 上的服務，可以避免資源或金錢的浪費。您只為需要的時候佈建資源，AWS 亦提供預留執行個體，最高可節省75%的雲端成本。 ■ 加速數位轉型 藉由 AWS 的數據分析、IoT、機器學習等新興技術與 SAP 環境相互整合，透過佈署，以低風險、快速、更具經濟效益的方式進行創新，並且從 SAP 環境衍生更多新商業價值。 將 SAP 工作負載佈建於 AWS 上，以提升營運效益及實現創新。 銓鍇國際 (CKmates) 為 AWS 長期認證的合作夥伴，亦取得 AWS 專業證照100+，擁有完整的架構師團隊，能夠協助客戶進行資料中心遷移，並特別重視資料遷移的安全性，藉由豐富的經驗，協助企業進行 SAP on AWS，成為客戶發展新商業價值的優秀夥伴。 看看更多 CKmates 客戶進行 SAP on AWS 的成功經驗： 大江生醫－在 CKmates 的協助下，我們得以大幅提升… ★ 活動快訊 CKmates 將在4月22號台北寒舍艾美酒店舉辦「SAP on AWS 應用論壇」，本次將探討 SAP on AWS 的雲端應用環境、SAP 於 AWS 的工作負載執行效應...等等相關議題，還有大陸工程公司分享其效益與心得！ 想知道更多有關 SAP on AWS 的相關訊息，請立即報名，千萬別錯過囉！
You can learn more details here