跨 Azure 區域的 SAP HANA 可用性
本文說明跨不同 Azure 區域之 SAP HANA 可用性的相關案例。 由於 Azure 區域之間的距離，在多個 Azure 區域中設定 SAP HANA 可用性牽涉到特殊考慮。
為何要跨多個 Azure 區域部署
Azure 區域通常會以大距離分隔。 視地緣政治區域而定，Azure 區域之間的距離可能是數百英里，甚至數千英里，例如美國。 由於距離，部署在兩個不同 Azure 區域中的資產之間的網路流量會經歷顯著的網路往返延遲。 延遲相當重要，足以排除一般 SAP 工作負載下兩個 SAP HANA 實例之間的同步資料交換。
另一方面，組織通常會在主要資料中心和次要資料中心的位置之間有距離需求。 如果自然災害發生在更廣泛的地理位置，距離需求有助於提供可用性。 範例包括2017年9月和10月襲擊加勒比和佛羅里達的颶風。 您的組織可能至少有最小距離需求。 對於大部分的 Azure 客戶，最小距離定義需要您針對跨 Azure 區域 的可用性進行設計。 由於兩個 Azure 區域之間的距離太大而無法使用 HANA 同步複寫模式，因此 RTO 和 RPO 需求可能會強制您在一個區域中部署可用性設定，然後在第二個區域中補充其他部署。
在此案例中需要考慮的另一個層面是容錯移轉和用戶端重新導向。 假設兩個不同的 Azure 區域中 SAP HANA 實例之間的容錯移轉一律為手動容錯移轉。 由於 SAP HANA 系統複寫的複寫模式設定為非同步，因此主要 HANA 實例中認可的資料可能尚未設為次要 HANA 實例。 因此，自動容錯移轉不是複寫為非同步設定的選項。 即使使用手動控制的容錯移轉，就像在容錯移轉練習中一樣，您也需要採取措施，以確保主要端的所有認可資料都已移至次要實例，再手動移至其他 Azure 區域。
Azure 虛擬網絡使用不同的 IP 位址範圍。 IP 位址會部署在第二個 Azure 區域中。 因此，您需要變更 SAP HANA 用戶端設定，或者最好是建立步驟來變更名稱解析。 如此一來，用戶端會重新導向至新的次要月臺伺服器 IP 位址。 如需詳細資訊，請參閱接管 後的 SAP 文章 用戶端連線復原。
兩個 Azure 區域之間的簡單可用性
您可以選擇不要將任何可用性設定放在單一區域內，但在發生災害時仍需要提供工作負載。 這類情節的典型案例為非生產環境。 雖然系統關閉了半天，甚至一天都是可持續的，但您無法讓系統無法使用的情況持續 48 小時以上。 若要讓設定成本降低，請執行另一個在 VM 中更為重要的系統。 另一個系統可作為目的地。 您也可以將次要區域中的 VM 大小調整為較小，並選擇不要預先載入資料。 因為容錯移轉是手動的，而且需要更多步驟才能容錯移轉完整的應用程式堆疊，所以需要額外的時間來關閉 VM、調整大小，然後將其重新開機是可接受的。
如果您使用在單一 VM 中將 DR 目標與 QA 系統共用的案例，您需要將下列考量納入考慮：
- 有兩 種作業模式 搭配 delta_datashipping 和 logreplay，適用于這類案例
- 這兩種作業模式都有不同的記憶體需求，而不需要預先載入資料
- Delta_datashipping不需要比 logreplay 所需的預先載入選項還要少得多的記憶體。 請參閱 SAP 檔 如何執行 SAP HANA 系統複寫的第 4.3 章
- 沒有預先載入的 logreplay 作業模式的記憶體需求並不具決定性，而且取決於載入的資料行存放區結構。 在極端情況下，您可能需要主要執行個體的 50% 記憶體。 logreplay 作業模式的記憶體與您是否選擇預先載入的資料無關。
注意
在此設定中，您無法提供 RPO=0，因為您的 HANA 系統複寫模式是非同步。 如果您需要提供 RPO=0，此設定不是選擇的組態。
您可以在組態中所做的小變更可能是將資料設定為預先載入。 不過，由於容錯移轉的手動本質，以及應用層也需要移至第二個區域的事實，預先載入資料可能沒有意義。
在一個區域內和跨區域結合可用性
區域內和跨區域的可用性組合，可能是由這些因素所驅動：
- Azure 區域內 RPO=0 的需求。
- 組織不願意或能夠讓全球作業受到影響較大區域的重大自然災害影響。 這是過去幾年襲擊加勒比的一些颶風的情況。
- 法規，要求主要和次要月臺之間的距離明顯超出 Azure 可用性區域所能提供的內容。
在這些情況下，您可以使用 HANA 系統複寫來設定 SAP 呼叫 SAP HANA 多層式系統複寫組態 的內容。 架構看起來會像這樣：
SAP 引進 了具有 HANA 2.0 SPS3 的多目標系統複 寫。 多目標系統複寫在更新案例中帶來一些優點。 例如，當次要 HA 月臺關閉以進行維護或更新時，DR 月臺 （區域 2） 不會受到影響。 您可以在 SAP 說明入口網站 深入瞭解 HANA 多重目標系統複 寫。 具有多重目標複寫的可能架構看起來如下：
如果組織在第二個（DR） Azure 區域中有高可用性整備需求，則架構看起來會像這樣：
使用 logreplay 作為作業模式，此設定會在主要區域內提供 RPO=0，且 RTO 較低。 如果涉及移至第二個區域，此設定也會提供體面的 RPO。 第二個區域中的 RTO 時間取決於資料是否已預先載入。 許多客戶會使用次要區域中的 VM 來執行測試系統。 在該使用案例中，無法預先載入資料。
重要
不同層之間的作業模式必須是同質的。 您無法 使用 logreplay 作為第 1 層和第 2 層與第 2 層之間的作業模式，delta_datashipping提供第 3 層。 您只能選擇一個或另一個作業模式，這些模式需要對所有層保持一致。 由於delta_datashipping不適合提供 RPO=0，因此這類多層式設定的唯一合理作業模式會維持 logreplay。 如需作業模式和某些限制的詳細資訊，請參閱 SAP 文章 SAP HANA 系統複 寫的作業模式。
下一步
如需在 Azure 中設定這些設定的逐步指引，請參閱：