作者：Sabari Radhakrishnan, Amazon Web Services（AWS）的合作伙伴解決方案架構師

譯者：戴俊, Amazon Web Services（AWS）的專業服務團隊SAP顧問 | 原文連結

您是否計劃將SAP應用程式遷移到SAP HANA平臺或使用SAP HANA啟動新的實施？ 如果是這樣，您可能會想知道Amazon Web Services（AWS）提供什麼選項來執行SAP HANA工作負載。 在這篇博文中，我想討論SAP HANA所需的核心基礎架構元件以及AWS提供的構建模組，以幫助您構建AWS上的SAP HANA虛擬裝置。 我希望這些資訊可以幫助您瞭解概念層面的部署選項。 這是我們將在AWS主題上釋出各種SAP的一系列博文中的第一篇，因此請經常回來看看。

如果您遵循SAP HANA定製資料中心整合（TDI）模式，記憶體，計算，儲存和網路是SAP HANA所需的四個關鍵基礎架構元件。 其中，記憶體是唯一取決於您的資料大小的變數。 計算，儲存和網路的要求是從記憶體大小預設或派生的。 例如，根據記憶體大小，SAP已經有了標準的CPU核數到記憶體比的要求，以確定您需要進行計算的CPU核心數量。 關於儲存，無論記憶體大小如何，您需要能夠滿足SAP HANA硬體配置檢查工具（HWCCT）指南中規定的不同塊大小和其他KPI的特定吞吐量要求。 最後，對於網路，特別是對於橫向擴充套件情況，不論記憶體大小，您都需要能夠在SAP HANA節點之間至少支援9.5 Gbps的網路吞吐量。

在過去的幾年中，AWS與SAP緊密合作，以驗證在AWS平臺上執行SAP HANA工作負載的計算和儲存配置。 我們如何實現這個目標的呢？ 答案是，AWS已經設計了具有不同記憶體大小的Amazon Elastic Compute Cloud（Amazon EC2）例項，以滿足SAP對SAP HANA的所有嚴格的效能要求，包括適用於計算的CPU核心到記憶體比例。 此外，Amazon Elastic Block Store（Amazon EBS）在許多情況下滿足了TDI模型的儲存KPI。 最後，EC2例項的網路頻寬滿足或超過了橫向擴充套件模式下節點間通訊的9.5 Gbps要求。

我們來仔細看看這些構建模組和配置選項。

記憶體和計算

AWS提供了幾種EC2例項型別來支援不同型別的工作負載。有兩個EC2例項系列非常適合SAP HANA工作負載：記憶體優化的R3和R4例項以及高記憶體X1例項。這些例項系列是針對記憶體中的工作負載（如SAP HANA）專門制定的。這些例項系列及其包含的例項型別為您提供了執行SAP HANA工作負載的各種計算選項。對於線上分析處理（OLAP）工作負載（例如，HANA上的SAP Business Warehouse，SAP BW / 4HANA，資料集市等），您可以垂直擴充套件，從244 GiB到2 TB，水平擴充套件一直到14 TB，並被SAP完全支援。還要注意，我們已經在AWS實驗室中成功測試了多達25個節點的部署或總共50 TB的RAM。對於線上交易處理（OLTP）工作負載（例如，HANA上的SAP Business Suite，SAP S4 / HANA，SAP CRM等），您現在可以從244 GiB垂直擴充套件到2 TB。隨著AWS繼續推出具有最新CPU代數的新例項型別，我們將與SAP密切合作，為SAP HANA工作負載的這些例項型別進行認證。通過SAP認證和支援的SAP HANA硬體目錄中的“認證IaaS平臺”頁面，檢視可用於SAP HANA工作負載的生產中的所有經過認證的AWS例項型別。在非生產工作負載的給定例項系列中，您可以隨時使用較小的例項大小，例如r3.2xlarge，r4.2xlarge等，以降低總體擁有成本（TCO）。請記住，這些是雲原生例項，使您可以靈活地將SAP HANA系統的記憶體空間從64GB無縫更改為2 TB，反之亦然，幾分鐘內即可實現SAP HANA實施的前所未有的靈活性。

以下圖表總結了我剛剛描述的記憶體和計算選項。

注 – 對於SAP Business One，所適用的SAP HANA的版本，以及可以使用其他例項和記憶體大小。 請參考關於這個話題的另一個博文。

儲存

對於SAP HANA的永續性塊儲存，AWS提供多種選項。對於您的效能敏感資料和日誌卷，以及針對SAP HANA備份的成本優化/高吞吐量磁性EBS卷（st1），我們有兩種支援SSD的EBS卷型別（gp2和io1）。

• 使用通用SSD（gp2）卷型別，您可以驅動高達每卷160 MB / s的吞吐量。為了實現TDI模型所需的最大吞吐量為400 MB / s，您必須為SAP HANA資料和日誌檔案分配三個卷。
• 配置的IOPS SSD（io1）卷提供每卷最多320 MB / s的吞吐量，因此您需要至少分兩個捲來實現所需的吞吐量。
• 通過吞吐量優化的硬碟（st1）卷，您可以通過大尺寸塊的順序讀寫實現高達500 MB / s的吞吐量，這使st1成為儲存SAP HANA備份的理想選擇。

一個關鍵點是每個EBS卷都會在其AWS可用區域內自動複製，以保護您免受故障，提供高可用性和耐久性。因此，您可以在作業系統級別配置RAID 0陣列，以獲得最佳效能，而不必擔心您的卷的額外保護（RAID 10或RAID 5）。

網路

網路效能是SAP HANA的另一個關鍵因素，尤其是橫向擴充套件系統。 每個EC2例項提供一定量的網路頻寬，而像X1這樣的一些最新例項系列可為您的SAP HANA需求提供高達20 Gbps的網路頻寬。 此外，許多例項為Amazon EBS儲存後端提供專用網路頻寬。 例如，最大的X1例項（x1.32xlarge）提供20 Gbps的網路頻寬和10 Gbps的專用儲存頻寬。 R4（r4.16xlarge）除了專用的12 Gbps儲存頻寬外還提供20 Gbps的網路頻寬。 以下簡要介紹了SAP認證例項的網路功能。

*網路和儲存流量共享相同的10 Gbps網路介面

作業系統（OS）

SAP支援在SUSE Linux Enterprise Server（SLES）或Red Hat Enterprise Linux（RHEL）上執行SAP HANA。 AWS都支援這兩種作業系統版本。 此外，您可以在AWS Marketplace中使用SAP HANA特定的SUSE和Red Hat映像來快速開始。 您還可以選擇攜帶自己的作業系統許可證。 請在未來的博文中，檢視有關SAP HANA在AWS上的作業系統選項的詳細資訊。

把以上內容搭建起來

您可能會問：“AWS提供與TDI類似的SAP HANA的這些構建模組非常好，但是如何將這些元件放在一起構建一個滿足SAP對AWS要求的系統？”AWS客戶幾年前就問了這個問題，這就是為什麼我們構建了AWS SAP HANA快速啟動。此快速啟動使用AWS CloudFormation模板（基礎架構作為程式碼infrastructure as code）和自定義指令碼來幫助配置AWS基礎架構元件，包括儲存和網路。快速啟動有助於設定SAP HANA安裝的作業系統先決條件，並且可以在攜帶自己的軟體和許可證時安裝SAP HANA軟體。快速啟動是可以在全球許多AWS地區使用的自助服務工具。在不到一小時的時間內，它們可以以一致，可預測和可重複的方式為您的SAP HANA系統提供基礎設施，無論是單節點還是橫向擴充套件系統。檢視在SAP RE：Invent 2016會議期間與SAP聯合提交的SAP HANA Quick Start的簡報。

我們強烈建議您使用AWS快速啟動為您的SAP HANA部署配置基礎架構。 但是，如果無法使用快速啟動（例如，因為要使用自己的作業系統映像），則可以手動配置SAP HANA環境，並將構建模組放在一起。 只需確保遵循快速入門指南中有關儲存和例項型別的建議。 為了具體目的，我們還在“ SAP HANA on AWS 手動部署指南”中的SAP HANA中提供了分步說明。 （手動部署指南很快將會更新，以包括最新作業系統版本的說明，包括RHEL。）

備份和恢復

以可靠的方式備份和恢復SAP HANA資料庫的能力對於保護業務資料至關重要。 您可以使用本機SAP HANA工具將資料庫備份到EBS卷，並最終將備份的檔案移動到Amazon Simple Storage Service（Amazon S3），以提高其耐用性。 Amazon S3是高度可擴充套件和耐用的物件儲存服務。 Amazon S3中的物件可以冗餘地儲存在一個區域內的多個設施中，並提供11個9的耐久性。 您還可以選擇使用與Amazon S3整合的企業級備份解決方案，如Commvault，EMC NetWorker，Veritas NetBackup和IBM Spectrum Protect（Tivoli Storage Manager）以及SAP HANA Backint介面。 這些合作伙伴解決方案可以幫助您將SAP HANA資料庫直接備份到Amazon S3，並使用企業級軟體管理備份和恢復。

高可用性（HA）和災難恢復（DR）
HA和DR是在SAP HANA上執行的關鍵業務應用程式的關鍵。 AWS提供了幾個構建模組，包括全球各個AWS區域和每個AWS區域內的多個可用區域，您可以根據RTO和RPO的要求設定HA和DR解決方案。 無論您是尋求基於成本優化的解決方案還是基於停機時間優化的解決方案，SAP HANA HA / DR架構都有一些獨特的選擇，請檢視SAP HANA HA/DR 指南，以瞭解有關這些更多資訊。 在未來的博文中，我們將深入探討這一主題。

系統遷移

在實際遷移的時候，您可以使用SAP Software Provisioning Manager（SWPM）和Software Update Manager（SUM）的Database Migration Option（DMO）等標準SAP工具集，或第三方遷移工具來把在任何資料庫上執行的SAP應用程式遷移到AWS上的SAP HANA。 SAP到AWS遷移過程與典型的本地遷移方案沒有太大的不同。 在本地場景中，您通常將源和目標系統駐留在同一資料中心。 當您遷移到AWS時，唯一的區別是您的目標系統駐留在AWS上，因此您可以將AWS視為自己的資料中心的擴充套件。 還有一些選項可用於在遷移過程中將匯出的資料從本地資料中心傳輸到AWS。 我建議您檢視 Migrating SAP HANA Systems to X1 Instances on AWS，以更好地瞭解您的選項。

其他注意事項包括操作，調整大小，縮放，與其他AWS服務（如Amazon CloudWatch）的整合，以及大資料解決方案。 我們將在未來的博文中詳細討論這些。 同時，我們也鼓勵您使用AWS SAP HANA快速入門來在AWS上使用SAP HANA。 要了解有關在AWS上執行SAP工作負載的更多資訊，請參閱AWS網站上列出的白皮書。

最後，如果您需要一個超出了目前可用規模的可擴充套件系統，請與我們聯絡。 我們很樂意與您討論您的要求，並與您一起實施。

– Sabari

譯者

戴俊，AWS中國專業服務團隊SAP諮詢顧問，在加入AWS之前，曾供職於SAP和EMC歷任SAP技術顧問及SAP解決方案工程師，在SAP系統架構設計與遷移方面有著豐富的經驗。現任職於AWS中國專業服務團隊，主要為客戶提供雲上SAP系統架構設計，SAP上雲遷移等諮詢服務。