最佳實務做法
架構
建議變更
PDF
SAP HANA主機使用備援10GbE或更快的網路基礎架構、連接至儲存控制器。SAP HANA主機與儲存控制器之間的資料通訊是以NFS傳輸協定為基礎。
如果交換器或網路介面卡（NIC）發生故障、建議使用備援交換基礎架構來提供容錯SAP HANA主機對儲存設備連線。交換器可能會將個別連接埠效能與連接埠通道集合起來、以便在主機層級顯示為單一邏輯實體。
不同機型FAS 的VMware系統產品系列可在儲存層混合搭配、以滿足成長和不同效能與容量需求。可附加至儲存系統的SAP HANA主機數量上限、是由SAP HANA效能要求和所使用的NetApp控制器模式所定義。所需的磁碟櫃數量僅取決於SAP HANA系統的容量和效能需求。下圖顯示八部SAP HANA主機連接至儲存高可用度（HA）配對的組態範例。
下圖顯示使用VMware vSphere做為虛擬化層的範例。
此架構可從兩個層面擴充：
-
如果儲存控制器提供足夠的效能來滿足目前的SAP關鍵效能指標（KPI）、則可將額外的SAP HANA主機和（或）儲存容量附加至現有儲存設備
-
新增更多儲存系統、並增加額外的儲存容量、以供額外的SAP HANA主機使用
下圖所示為將更多SAP HANA主機連接至儲存控制器的組態範例。在此範例中、需要更多磁碟櫃來滿足16台SAP HANA主機的容量和效能需求。視總處理量需求而定、必須新增額外的10GbE（或更快）連線至儲存控制器。
SAP HANA環境獨立於已部署FAS 的整個系統、也可藉由新增任何認證儲存控制器來擴充、以符合所需的節點密度（下圖）。
SAP HANA備份
所有NetApp儲存控制器上的支援功能軟體均內建備份機制、可在運作時備份SAP HANA資料庫、不會影響效能。ONTAP以儲存為基礎的NetApp Snapshot備份是完全受支援且整合的備份解決方案、適用於SAP HANA單一容器、以及具有單一租戶或多個租戶的SAP HANA多租戶資料庫容器（MDC）系統。
儲存型Snapshot備份是使用SnapCenter 適用於SAP HANA的NetApp功能區外掛程式來實作。這可讓使用者使用SAP HANA資料庫原生提供的介面、建立一致的儲存型Snapshot備份。此功能可將每個Snapshot備份登錄至SAP HANA備份目錄。SnapCenter因此SnapCenter 、在SAP HANA Studio和Cockpit中可以看到由NetApp執行的備份、您可以直接選擇這些備份來進行還原和還原作業。
NetApp SnapMirror技術可將在單一儲存系統上建立的Snapshot複本複製到SnapCenter 由他人控制的二線備份儲存系統。然後可以針對主要儲存設備上的每個備份集、以及次要儲存系統上的備份集、定義不同的備份保留原則。SAP HANA版的支援功能可自動管理保留Snapshot複製型資料備份與記錄備份、包括備份目錄的管理作業。SnapCenterSAP HANA的支援功能還可執行檔案型備份、執行SAP HANA資料庫的區塊完整性檢查。SnapCenter
資料庫記錄可以使用NFS掛載直接備份到次要儲存設備、如下圖所示。
相較於傳統的檔案型備份、以儲存為基礎的Snapshot備份可提供顯著優勢。這些優勢包括但不限於：
-
快速備份（幾分鐘）
-
由於儲存層的還原時間快得多（幾分鐘）、而且備份頻率更高、因此能縮短恢復時間目標（RTO）
-
在備份與還原作業期間、SAP HANA資料庫主機、網路或儲存設備的效能不會降低
-
根據區塊變更、將具空間效益且具頻寬效益的複寫至二線儲存設備
如需SAP HANA備份與還原解決方案的詳細資訊、請SnapCenter 參閱 "TR-4614：SAP HANA備份與還原SnapCenter 功能（含功能）"。
SAP HANA災難恢復
SAP HANA災難恢復可透過SAP HANA系統複寫在資料庫層上執行、也可透過儲存複寫技術在儲存層上執行。下節概述以儲存複寫為基礎的災難恢復解決方案。
如需SAP HANA災難恢復解決方案的詳細資訊、請參閱 "TR-4646：SAP HANA災難恢復與儲存複寫"。
以SnapMirror為基礎的儲存複寫
下圖顯示三站台災難恢復解決方案、使用同步SnapMirror複寫至本機災難恢復資料中心、並使用非同步SnapMirror將資料複寫至遠端災難恢復資料中心。
使用同步SnapMirror進行資料複寫可提供歸零的RPO。一線與本機災難恢復資料中心之間的距離限制在100公里左右。
主要與本機災難恢復站台的故障防護、是透過非同步SnapMirror將資料複寫至第三個遠端災難恢復資料中心來執行。RPO取決於複寫更新的頻率及傳輸速度。理論上、距離是無限的、但限制取決於必須傳輸的資料量、以及資料中心之間可用的連線。一般RPO值介於30分鐘到多小時之間。
這兩種複寫方法的RTO主要取決於在災難恢復站台啟動HANA資料庫並將資料載入記憶體所需的時間。假設資料的讀取處理量為1000Mbps、載入1TB的資料大約需要18分鐘。
災難恢復站台的伺服器可在正常運作期間作為開發/測試系統使用。發生災難時、開發/測試系統必須關閉、並以災難恢復正式作業伺服器的形式啟動。
這兩種複寫方法都能讓您執行災難恢復工作流程測試、而不會影響RPO和RTO。FlexClone磁碟區是在儲存設備上建立、並附加至災難恢復測試伺服器。
同步複寫提供StrictSync模式。如果由於任何原因而無法完成對二線儲存設備的寫入、則應用程式I/O會失敗、因此可確保一線與二線儲存系統完全相同。只有在SnapMirror關係恢復為不同步狀態後、應用程式I/O才會繼續進行主要作業。如果主儲存設備故障、在容錯移轉後、可在二線儲存設備上恢復應用程式I/O、而不會遺失資料。在StrictSync模式中、RPO永遠為零。
儲存複寫功能以MetroCluster 功能為基礎
下圖顯示解決方案的高階概觀。每個站台的儲存叢集都提供本機高可用度、並用於正式作業工作負載。每個站台的資料會同步複寫到另一個位置、如果發生災難容錯移轉、就可以使用。
