Azure HDInsight 高可用性解決方案架構案例研究
Azure HDInsight 的複寫機制可以整合到高可用性解決方案架構中。 在本文中，Contoso Retail 的虛構案例研究可用來說明可能的高可用性災害復原方法、成本考慮及其對應的設計。
高可用性災害復原建議可以有許多排列和組合。 在審議每個選項的優缺點之後，將會達成這些解決方案。 本文只討論一個可能的解決方案。
客戶架構
下圖描述 Contoso Retail 主要架構。 此架構包含串流工作負載、批次工作負載、服務層、耗用量層、儲存層和版本控制。
串流工作負載
裝置和感測器會將數據產生至 HDInsight Kafka，其構成傳訊架構。 HDInsight Spark 取用者會從 Kafka 主題讀取。 Spark 會轉換傳入訊息，並將其寫入服務層上的 HDInsight HBase 叢集。
批次工作負載
執行Hive和 MapReduce 的 HDInsight Hadoop 叢集會從內部部署交易系統內嵌數據。 Hive 和 MapReduce 轉換的原始資料會儲存在 Azure Data Lake 儲存體 Gen2 所支援之 Data Lake 邏輯分割區的 Hive 數據表中。 儲存在Hive數據表中的數據也可供Spark SQL使用，它會在 HBase 中儲存策展數據以供服務之前進行批次轉換。
服務層
搭配 Apache Phoenix 的 HDInsight HBase 叢集可用來將數據服務至 Web 應用程式和視覺效果儀錶板。 HDInsight LLAP 叢集可用來滿足內部報告需求。
耗用量層
Azure API Apps 和 API 管理 層會回到公開的網頁。 Power BI 已滿足內部報告需求。
儲存體 層
邏輯分割的 Azure Data Lake 儲存體 Gen2 會作為企業數據湖使用。 HDInsight 中繼存放區是由 Azure SQL DB 所支援。
控制系統版本
整合至 Azure Pipelines 並裝載於 Azure 外部的版本控制系統。
客戶商務持續性需求
請務必判斷發生災害時所需的最低商務功能。
Contoso Retail 的商務持續性需求
- 我們必須受到保護，以免發生區域性失敗或區域服務健康情況問題。
- 我的客戶絕不能看到 404 錯誤。 必須一律提供公用內容。 （RTO = 0）
- 在一年中的大部分時間里，我們可以顯示已過時 5 小時的公用內容。 （RPO = 5 小時）
- 在假日季節，我們公開的內容必須一律是最新的。 （RPO = 0）
- 我的內部報告需求並不被視為商務持續性的關鍵。
- 將商務持續性成本優化。
建議的解決方案
下圖顯示 Contoso Retail 的高可用性災害復原架構。
Kafka 使用 主動 – 被動 復寫，將 Kafka 主題從主要區域鏡像到次要區域。 Kafka 複寫的替代方案可能是在這兩個區域中產生至 Kafka。
Hive 和 Spark 會在正常時間使用 作用中主要 – 隨選次要 複寫模型。 Hive 複寫程式會定期執行，並伴隨Hive Azure SQL 中繼存放區和Hive記憶體帳戶複寫。 Spark 記憶體帳戶會使用 ADF DistCP 定期復寫。 這些叢集的暫時性有助於將成本優化。 複寫會每隔 4 小時排程一次，以抵達符合五小時需求的 RPO。
HBase 複寫會在 正常時間使用領導者 – 追蹤器 模型，以確保無論區域為何，RPO 都一律提供數據。
如果主要區域中發生區域失敗，網頁和後端內容會從次要區域提供 5 小時，且有某種程度的過時。 如果 Azure 服務健康情況儀錶板未在五小時視窗中指出復原 ETA，Contoso Retail 會在次要區域中建立 Hive 和 Spark 轉換層，然後將所有上游數據源指向次要區域。 讓次要區域可寫入會導致包含複寫回到主要複寫的容錯回復程式。
在尖峰的購物季節，整個次要管道一律為作用中且正在執行。 Kafka 產生者對區域和 HBase 複寫都會從 Leader-Follower 變更為 Leader-Leader，以確保公開面向的內容一律是最新的。
不需要針對內部報告設計故障轉移解決方案，因為它對商務持續性並不重要。
下一步
若要深入瞭解本文所討論的專案，請參閱：