基礎架構和軟體可能會發生故障。這類失敗的原因和範圍要求 SAP 系統部署作業遵循特定原則，才能充分發揮 Google Cloud 基礎架構的優勢。結合基礎架構選項和具備韌性的 SAP 軟體部署架構，可確保資料完整性，並防範資料遺失或系統無法使用。
復原力和可靠性選項
您可以利用基礎架構和應用程式層的功能，部署彈性強且穩健的系統，以便吸收錯誤或允許從錯誤復原。為確保 Google Cloud上的 SAP 系統部署作業具備復原力和可靠性，建議您考慮下列選項：
- 平台復原能力： Google Cloud 我們在設計服務和產品時，會考量復原能力，並內建備援機制，以便達到我們發布的服務水準協議。當您依照 Google Cloud 指南和最佳做法部署 SAP 系統時，基礎平台機制可提高 SAP 系統的復原能力。這樣一來，即使發生故障或災難，您也能繼續進行業務作業。
- 高可用性 (HA)：使用支援 HA 的基礎架構和軟體設定，即可啟用自動系統復原功能，盡可能減少中斷時間。這項用途還可確保，在基礎結構或應用程式軟體部分發生故障時，您只需進行最少的介入作業。HA 可為系統元件提供備援機制，以防系統元件發生單一元件故障或效能降低的情況。
- 災難復原 (DR)：DR 可在災難發生時，協助恢復業務營運。災難復原作業包括將服務和應用程式移至實體隔離的次要位置，以便繼續執行作業。DR 系統可處理單一元件或服務失敗以外的情況，以減輕發生頻率較低但影響較大的事件。這類事件包括自然災害、電網中斷等區域性事件，以及火災或人為錯誤等局部事件。DR 規定包括：
- 資料複製：您可以使用軟體或儲存空間層級複製功能，確保資料會傳輸至次要位置，並盡可能減少資料損失。
- 備份：您可以使用與主要資料儲存空間分開儲存的備份，復原系統或資料庫。這可能包括使用在 Cloud Storage 中上傳的快照或備份，前提是快照或備份儲存在系統部署位置以外的區域。
由於這些選項互補，您可以結合各選項的部分內容，提高 SAP 部署作業的彈性。您選取的選項會影響部署作業的復原時間目標 (RTO) 和復原點目標 (RPO)。因此，您也需要評估這些選項對系統復原力和業務連續性造成的影響，並據此評估相關成本。建議您仔細考量所有可用選項，並根據您的災難復原目標實作。
以下說明 SAP 部署範例，以及不同高可用性和災難復原設定對其彈性和可靠性的影響。
範例情境
建議您在 Google Cloud上擴充 SAP S/4HANA 部署作業。下表列出可套用至此部署的 HA 和 DR 設定範例，以及這些設定對系統復原力和可靠度的影響，例如可用性、RTO 和 RPO。
| HA 或 DR 設定 | 復原力或可靠度維度 | 預期時間 |
|---|---|---|
HA 設定。請考量下列要點：
|
可用性 |
|
DR 設定，使用非同步 SAP HANA 系統複製功能，將資料複製至完全記憶體駐留的 DR 系統。請考量下列要點：
|
恢復時間 | 幾小時，可能包括 DNS 傳播至用戶端系統所需的時間。 |
| 復原點 | 上次非同步複製作業後經過的時間 (分鐘)。 | |
| DR 設定，使用備份與預先佈建的基礎架構 附註 1。請考慮使用 Backint 的系統，以便備份及復原。 | 恢復時間 | 從備份復原資料庫的時間 附註 2。 |
| 復原點 | 至 SAP HANA 記錄備份或快照的最後時間點。 | |
| 使用備份的 DR 設定，但未預先佈建基礎架構 附註 3。請考慮使用 Backint 的系統，以便備份及復原。 | 恢復時間 | 您可能需要花上幾天時間來佈建基礎架構 附註 4，並從備份檔案復原資料 附註 3。 |
| 復原點 | 至 SAP HANA 記錄備份或快照的最後時間點。 |
表格註解：
- 您可以預先保留必要資源，藉此部署 DR 解決方案，而無須預先佈建所需基礎架構。這樣一來，當您因主要位置發生災難而需要啟用異地備援解決方案時，就能確保有足夠的資源可用。詳情請參閱「選擇預留類型」。
- 復原作業的執行時間，很大程度上取決於所使用的備份解決方案和備份檔案大小。如要確定資料庫大小和變更率的確切預期時間，您必須評估所用備份解決方案的復原速度，例如 Backint 或 磁碟快照。
- 如果在部署異地備援解決方案時，未預先佈建或保留必要資源，可能會導致無法使用必要資源的情況。這可能會增加部署作業的復原時間，進而影響您的業務運作。
- 對於 X4 等無法隨選且需要訂購的機型，如果未事先預訂容量，可能需要等待數週的時間。
請將上表中的資訊視為補充資訊，搭配您根據業界規範所擬定的現有設計和災難復原計畫。如需更多資訊，請參閱下列資源：
彈性部署最佳化建議
下列各節將概略說明高可用性和災難復原設定，我們建議您在Google Cloud上部署彈性且可靠的 SAP 工作負載。
雖然我們強烈建議您針對負載 SAP 系統的實際運作作業導入這些最佳做法，但您也可以針對非實際運作作業的 SAP 系統導入這些最佳做法，因為系統長時間中斷可能會對業務運作造成不利影響。
如要瞭解最佳化建議，請參閱以下各節：
高可用性建議
- 在同一個區域內使用至少兩個不同的可用區來部署執行個體。
- 移除單點故障您可以新增額外資源，為發生故障時的錯誤服務或應用程式元件提供彈性和備援機制，以達到這項目標。
- 使用內建備援機制的區域服務。舉例來說，您可以使用 Filestore Regional (舊稱 Enterprise) 託管共用檔案，以及 Cloud Load Balancing 提供的負載平衡器。
- 使用自動容錯功能。自動化可減少在發生錯誤時需要人為介入的情況，並降低對業務運作的影響。例如，您可以使用 Pacemaker 等 Linux 叢集管理工具。
使用備援網路路徑。請務必在主要區域中建立備援連線。視連線需求而定，您可以選擇多種連線方式。詳情請參閱「Google Cloud 連線功能」。
如要讓連線至 Google Cloud區域的可用性達到 99.99%，建議您設定多個連線。詳情請參閱「為專屬互連網路建立 99.99% 的可用性」。
在 Compute Engine 資源上啟用即時遷移和自動重新啟動政策：
- 如要在 Google 啟動的維護事件期間讓運算執行個體保持線上，您可以使用即時遷移功能，方法是使用
MIGRATE(預設) 選項設定onHostMaintenance屬性。如果運算執行個體不支援即時遷移，請將automaticRestart屬性設為true(預設)。這樣一來，Google 就能重新啟動任何無法回應的執行個體。詳情請參閱「關於主機事件」。 - 對於不支援即時遷移或預定維護的運算執行個體，您可以使用進階維護控制項。詳情請參閱「為單一用戶群節點啟用進階維護控制項」。
- 如要在 Google 啟動的維護事件期間讓運算執行個體保持線上，您可以使用即時遷移功能，方法是使用
正式上線前，請在環境中測試備援機制。
- 為確保高可用性設定正確無誤，且運作正常，請務必測試會觸發一或多個元件終止的失敗情境。詳情請參閱「在 Google Cloud上測試 HA 叢集」。
- 如要評估 HA 設定，您可以使用工作負載管理工具。詳情請參閱「關於 Workload Manager 評估」。如要瞭解 Workload Manager 支援的 SAP 工作負載評估作業，請參閱 Workload Manager 適用於 SAP 的最佳做法。
災難復原建議
在主要區域以外的區域中代管 DR 解決方案。為避免 DR 解決方案受到與主要系統相同事件的影響，請確保這兩者位於不同的位置。
理想情況下，備援位置必須位於其他區域。不過，如果因資料居留地或主權問題，使用第二個區域不是一個好的選項，請與Google Cloud Sales 聯絡，討論其他可用的選項。
下圖顯示在 Google Cloud 上部署 SAP HANA 時，採用下列 HA 和 DR 預留的整體架構：
- 為了實現高可用性，主要系統有兩個節點，分別部署在同一區域的不同區域中。
- 為確保復原能力，主要系統和 DR 系統會在不同的地區代管，並以非同步複製方式運作。
確保備援位置有足夠的容量。
- 決定 DR 系統是否需要以與主要系統相同的容量或較低的容量運作。對於 SAP HANA 等資料庫，災難復原位置必須有足夠的資源，才能有效運作 SAP 工作負載。
- 此外，請事先檢查 DR 位置是否有必要的資源。為確保資源可用，您可以在 DR 位置佈建資源，或提前購買預留資源。購買預留空間有助於避免發生下列情況：在發生錯誤後，資源會分配給其他 Google Cloud客戶，導致資源無法使用。對於較大的運算執行個體類型 (例如 M2 或 X4) 而言，這一點尤為重要。如要瞭解預留項目的相關資訊，請參閱「選擇預留項目類型」。
為提高成本效率，DR 位置中的基礎架構可用於非實際工作環境工作負載，並在 DR 事件期間切換為提供實際工作環境工作負載。不過，這會導致復原時間增加。
驗證 DR 位置的連線能力。如同連往主要位置的備援網路路徑，您可以考慮新增其他備援選項，例如 Cloud VPN。
找出可用來識別災難的信號。這些信號有助於決定何時觸發 DR 解決方案。以下是這類信號的範例：
- 來自 Google Cloud service health 的 Google Cloud 服務健康狀態資訊。
- Cloud Monitoring 所回報的執行個體完全無法使用，如 Google Cloud 專案設定。
- Google Cloud 客戶服務團隊或Google Cloud 帳戶代表的通知，說明服務中斷情形和可能的解決時間。
- 由 SAP 系統的使用者或管理員判斷的資料庫邏輯損毀情形，無法透過 HA 機制解決。
定期測試 DR 解決方案。確保解決方案可在災難發生時運作。這可能會影響您的日常營運。如果作業允許，請考慮在主要和次要位置進行對稱作業，並每 3 到 6 個月輪流執行作業。
使用複製功能，以便在最佳復原點復原資料。複製功能可在 DR 網站上提供主要網站的近乎即時版本。視 SAP 工作負載的設計方式而定，您可以使用下列複寫選項：
- 資料庫層級複製，利用 SAP HANA 系統複製等機制，在主要和 DR 站點之間的邏輯層級複製資料。
- 儲存空間層級複製功能，可利用 PD 非同步複製等機制，在區塊儲存空間層級複製資料。可用的儲存空間層級複寫選項會因 SAP 工作負載使用的儲存空間選項而異。
請務必使用適當的工具 (例如 SAP HANA 主控台) 監控複製作業。這有助於在 DR 事件發生時，驗證 DR 解決方案在觸發前是否已完全複製 SAP 工作負載。
使用資料備份來提供時間點復原功能。
- 如要建立備援機制，請使用多個儲存位置來儲存備份。例如：
- 使用Google Cloud的 SAP 代理程式 Backint 功能建立備份時，請使用雙區域或多區域的值區位置。詳情請參閱「建立 Cloud Storage 值區」。
- 使用代理程式的磁碟快照功能建立備份時，請使用多區域或雙區域 Cloud Storage。如要瞭解 Cloud Storage 值區位置，請參閱「值區位置」。
- 使用增量或差異備份，其中可能會在 Google Cloud上儲存快照。
- 監控備份，確保備份能依照備份策略正確建立。如需完整的資料保護解決方案，建議您使用 Google Cloud的備份和災難復原服務。
- 定期測試備份，確保在發生災難時能復原備份，並查看復原系統或資料庫所需的時間。建議您每個備份週期 (通常為 28 天) 測試一次復原功能。
- 請像保護主要系統一樣保護備份，例如使用儲存空間保留設定和加密金鑰。
- 如要建立備援機制，請使用多個儲存位置來儲存備份。例如：
其他建議
- 評估高可用性和災難復原設定的成本，並考量這些設定對下列業務層面的影響：
- 營運和業務交易可能會中斷。
- 資料可能會遺失，導致銷售、客戶或供應商信心喪失，或違反法規。
- 每家商家都有不同的考量。如果您的特殊情況需要更客製化的解決方案，歡迎隨時與Google Cloud 銷售團隊聯絡。
後續步驟
- SAP HANA 高可用性規劃指南
- SAP HANA 災難復原規劃指南
- Google Cloud上的 SAP NetWeaver 高可用性規劃指南
- Google Cloud上的 SAP NetWeaver 災難復原規劃指南