單一 Azure 區域中的 SAP HANA 可用性
本文描述一個 Azure 區域內 SAP HANA 的幾種可用性案例。 Azure 有許多分散在世界各地的區域。 如需 Azure 區域的清單，請參閱 Azure 區域。 為了讓您能夠在單一 Azure 區域內的 VM 上部署 SAP HANA，Microsoft 提供了含一個 HANA 執行個體的單一 VM 部署。 如需提升可用性，您可以部署含兩個 HANA 執行個體的兩個 VM，方法是使用 FD=1 的彈性擴展集、可用性區域，或使用 HANA 系統複寫來獲得可用性的可用性設定組。
提供可用性區域的 Azure 區域包含多個資料中心，每個資料中心都有自己的電源、冷卻和網路基礎結構。 在單一 Azure 區域內提供不同區域的目的，是要讓您可跨兩個或三個可用的可用性區域來部署應用程式。 透過跨區域分散應用程式部署，任何影響特定 Azure 可用性區域基礎結構的電源或網路問題都不會完全中斷應用程式在 Azure 區域內的功能。 雖然容量可能會有所減少，例如可能失去某個區域中的 VM，但其餘區域中的 VM 將繼續運作而不會中斷。 若要在跨越不同區域的個別 VM 中設定兩個 HANA 執行個體，您可以選擇使用 FD=1 的彈性擴展集或可用性區域部署選項來部署 VM。
如需提升區域內的可用性，建議您使用可用性設定組來部署兩個 VM，其中含有兩個 HANA 執行個體。 Azure 可用性設定組是一種邏輯群組功能，其確保您在可用性設定組內設定的 VM 資源若是部署在 Azure 資料中心內，則不會因為失敗而對彼此造成影響。 Azure 可確保您在可用性設定組中所放置的 VM，會橫跨多部實體伺服器、計算機架、儲存體單位和網路交換器來執行。 在某些 Azure 文件中，這個設定是指不同更新網域和容錯網域中的配置。 這些配置通常在 Azure 資料中心內。 假設電源和網路問題會影響您要部署的資料中心，則您在一個 Azure 區域中的所有容量都會受到影響。
配置代表 Azure 可用性區域的資料中心，是在服務 (部署在不同區域) 之間傳遞可接受網路延遲與在資料中心之間有一定距離的折衷辦法。 最理想的情況是，此區域內所有可用性區域的電力、網路供應與基礎結構，都不會受到自然災害的影響。 不過，從歷史上的重大自然災害看來，可用性區域不一定能永遠提供您想要在單一區域內獲得的可用性。 例如 2017 年 9 月 20 日侵襲波多黎各島嶼的瑪莉亞 (Maria) 颶風。 這個颶風至少造成島上方圓 90 英里內的地區幾乎完全停電。
單一 VM 案例
在單一 VM 案例中，您會建立 Azure 虛擬機器來取得 SAP HANA 執行個體。 您要使用 Azure 進階儲存體來主控作業系統磁碟及您所有的資料磁碟。 Azure 99.9% 的執行時間 SLA 及其他 Azure 元件的 SLA，足以實現您要提供給客戶的可用性 SLA。 在此案例中，您不需要針對執行 DBMS 層的 VM 使用 Azure 可用性設定組。 在此案例中，您會依賴兩個不同的功能：
- Azure VM 自動重新啟動 (也稱為 Azure 服務修復)
- SAP HANA 自動重新啟動
Azure VM 自動重新啟動 (又稱服務修復) 是 Azure 中的功能，可在兩個層級上運作：
- Azure 伺服器主機會檢查伺服器主機上所裝載 VM 的健康情況。
- Azure 網狀架構控制器會監視伺服器主機的健康情況和可用性。
健康情況檢查功能會針對裝載在 Azure 伺服器主機上的每個 VM，監視其健康情況。 如果 VM 處於狀況不良狀態，Azure 主機代理程式 (會檢查 VM 的健康情況) 可能會起始 VM 重新開機。 網狀架構控制器會檢查許多可指出主機硬體問題的不同參數，藉此檢查主機的健康情況。 其也會透過網路來檢查主機的協助工具。 指示主機的問題可能會導致下列事件：
- 如果主機發出健全狀態不良訊號，則會觸發主機重新開機及主機上所執行的 VM 重新啟動。
- 如果成功重新開機後，主機不是處於健全狀態，系統就會開始將 VM 從原本所在但現在狀況不良的節點中，重新部署到狀況良好的主機伺服器上。 在此情況下，原始主機會標示為狀況不良。 它無法再用來部署，直到加以清除或取代為止。
- 如果狀態不良的主機在重新開機程序中發生問題，則會觸發 VM 在狀態良好的主機上立即重新啟動。
透過主機和 Azure 所提供的 VM 監視，遭遇主機問題的 Azure VM 會在狀況良好的 Azure 主機上自動重新啟動。
重要
Azure 服務修復不會將客體 OS 處於核心異常狀態的 Linux VM 重新啟動。 在常用的 Linux 發行版本中，預設設定不會自動重新啟動 Linux 核心處於異常狀態的 VM 或伺服器。 相反地，預設設定會讓作業系統維持在核心異常的狀態，以便連結核心偵錯來進行分析。 Azure 會接受該行為，不會自動重新啟動客體作業系統處於這類狀態的 VM。 假設這種情況非常罕見。 您也可以覆寫此預設行為，以啟用重新啟動 VM 的功能。 若要變更預設行為，在 /etc/sysctl.conf 中啟用 'kernel.panic' 參數。 您針對此參數設定的時間是以秒為單位。 常見的建議值約需要等候 20-30 秒，才會透過此參數觸發重新開機。 如需詳細資訊，請參閱 sysctl.conf。
您在此案例中依賴的第二個功能，就是在重新啟動的 VM 上執行的 HANA 服務會在 VM 重新開機後自動啟動。 您可以透過各種 HANA 服務的看門狗服務來設定 HANA 服務自動重新啟動。
您可藉由將冷容錯移轉的節點新增至 SAP HANA 設定，來改善這個單一 VM 的案例。 在 SAP HANA 文件中，此設定稱為主機自動容錯移轉。 此設定在伺服器硬體受到限制的內部部署情況下可能有意義，並且您可以將單一伺服器節點專門用作一組生產主機的主機自動容錯移轉節點。 但在 Azure 中，Azure 的基礎結構會提供狀態良好的目標伺服器來成功重新啟動 VM，因此，部署 SAP HANA 主機自動容錯移轉就毫無意義。 由於 Azure 服務的修復功能，因此我們沒有參考架構可用來預測 HANA 主機自動容錯移轉的待命節點。
Azure 中的 SAP HANA 延展組態特殊案例
在下列文件中可以找到以待命節點或 HANA 系統複寫為基礎的高可用性架構。 在待命節點或 HANA 系統複寫高可用性未用於 SAP HANA 擴增設定的情況下，一旦 VM 可以再次運作，您就可以依賴 Azure VM 的服務修復功能，以及 SAP HANA 執行個體的自動重新啟動功能。
- RedHat Enterprise Linux
- SUSE Linux Enterprise Server
兩種不同 VM 的可用性案例
若要確保特定區域內 HANA 系統的可用性，您可以選擇跨區域的可用性區域或在區域內設定兩個 VM。 若要實現此目標，您可以使用彈性擴展集、可用性區域或可用性設定組部署選項來設定 VM。 Azure 中的基底設定看起來會像這樣：
為了說明不同的 SAP HANA 可用性案例，我們會省略圖表中的幾個圖層。 下圖只會顯示描述了 VM、主機、可用性設定組及 Azure 區域的幾層。 本節所說明的案例中不會用到 Azure 虛擬網路執行個體、資源群組及訂用帳戶。
將備份複寫到第二個虛擬機器
最基本的設定之一是使用備份。 特別是，您可以將交易記錄備份從某個 VM 送到另一個 Azure VM。 您可以選擇 Azure 儲存體類型。 在此設定中，您負責撰寫指令碼將第一個 VM 上所進行的排程備份複製到第二個 VM。 如果您需要使用第二個 VM 的執行個體，您必須將完整備份、增量/差異備份與交易記錄備份還原為所需的時間點。
此架構如下所示：
此設定不太適合用來實現絕佳的復原點目標 (RPO) 和復原時間目標 (RTO) 時間。 特別是 RTO 時間會因為需使用複製的備份來完整還原整個資料庫而受到影響。 不過，此設定適合用來復原不小心從主要執行個體上刪除的資料。 透過此設定，您可以隨時還原至特定時間點、擷取資料，以及將已刪除的資料匯入至您的主要執行個體。 因此，將備份複製方法與其他高可用性功能結合是很合理的行為。
在複製備份時，您可以使用比 SAP HANA 執行個體執行所在的主要 VM 還要小的 VM。 請注意，您可以將更少量的 VHD 連結至較小的 VM。 如需個別 VM 類型限制的相關資訊，請參閱 Azure 中的 Linux 虛擬機器大小。
不含自動容錯移轉的 SAP HANA 系統複寫
本節所述案例會使用 SAP HANA 系統複寫。 如需 SAP 文件，請參閱系統複寫。 沒有自動容錯移轉的案例，對於一個 Azure 區域內的設定並不常見。 組態上若沒有自動容錯移轉 (雖然可避免安裝 Pacemaker)，會造成您必須手動進行監視和容錯移轉。 由於這也是費時費力，大部分的客戶還是會依賴 Azure 服務修復。 在某些邊緣案例中，這種設定可能對失敗情況有所幫助。 或者，在某些案例中，客戶可以實現更大的效率。
不具有自動容錯移轉和資料預先載入的 SAP HANA 系統複寫
在此案例中，您會使用 SAP HANA 系統複寫來同步移動資料，以實現值為 0 的 RPO。 另一方面，您有夠長的 RTO，因此不需要容錯移轉或預先將資料載入 HANA 執行個體快取。 在此情況下，您可以採取下列動作讓您的設定更具經濟效益：
- 在第二個 VM 中執行另一個 SAP HANA 執行個體。 第二個 VM 中的 SAP HANA 執行個體會耗用虛擬機器的大部分記憶體。 如果容錯移轉至第二個 VM，您需要關閉已將資料完全載入第二個 VM 的執行中 SAP HANA 執行個體，以便複寫資料可以載入到第二個 VM 中的目標 HANA 執行個體快取。
- 在第二個 VM 上使用較小的 VM 大小。 如果發生容錯移轉，您必須再執行一個步驟，才能進行手動容錯移轉。 在此步驟中，您可以將 VM 的大小調整為來源 VM 的大小。
該案例將如下所示：
注意
即使不在 HANA 系統複寫目標中使用資料預先載入，也至少需要 64 GB 的記憶體。 除了 64 GB 外，您還要有足夠記憶體以保存目標執行個體記憶體中的資料列存放區資料。
不具有自動容錯移轉但具有資料預先載入的 SAP HANA 系統複寫
在此案例中，複寫到第二 VM 中 HANA 執行個體的資料會預先載入。 這會讓未預先載入資料的兩個優點消失。 在此情況下，您無法在第二個 VM 上執行另一個 SAP HANA 系統。 您也不能使用較小的 VM 大小。 因此，客戶很少會實作此案例。
具有自動容錯移轉的 SAP HANA 系統複寫
在一個 Azure 區域內標準且最常見的可用性設定中，兩個執行 Linux 與 HA 套件的 Azure VM 定義了一個容錯移轉叢集。 HA Linux 叢集是基於使用 SLES 或 RHEL 的 Pacemaker 架構，以 fencing device SLES 或 RHEL 為例。
如果從 SAP HANA 的角度來看，所使用的複寫模式已同步處理，且自動容錯移轉也已設定。 在第二個 VM 中，SAP HANA 執行個體會作為熱待命節點。 待命節點會接收與主要 SAP HANA 執行個體同步的變更記錄資料流。 HANA 主要節點上的應用程式認可交易後，主要 HANA 節點會等候向應用程式確認該認可，直到次要 SAP HANA 節點確認接收到認可記錄為止。 SAP HANA 提供兩種同步複寫模式。 如需詳細資料以及這兩種同步複寫模式差異的說明，請參閱 SAP 的SAP HANA 系統複寫的複寫模式一文。
整體組態如下所示：
您可以選擇此解決方案，因為其可讓您實現 RPO = 0 和低 RTO。 透過 SAP HANA 用戶端使用虛擬 IP 位址來連線至 HANA 系統複寫組態的方式，設定 SAP HANA 用戶端連線。 藉由這類組態，在發生容錯移轉至第二個節點的情形時，就不需要重新設定應用程式。 在此解決方案中，主要和次要 VM 的 Azure VM SKU 必須相同。
下一步
如需在 Azure 中設定這些設定的逐步指引，請參閱：
如需跨 Azure 區域的 SAP HANA 可用性詳細資訊，請參閱：