Kafka多資料中心部署災備三要素

AI前線導讀： 想象一下，災難性破壞——比如災難性硬體故障、軟體故障、停電、拒絕服務攻擊或其他一些事件——導致一個裝有Apache Kafka叢集的資料中心完全失效。不過，另一個資料中心的Kafka繼續在執行中，它已經擁有原始資料中心的資料副本，這些資料是從具有相同名稱的主題上覆制過來的。客戶端應用程式從故障叢集切換到正在執行的叢集，並根據在原始資料中心中停止的位置自動恢復在新資料中心的資料消費。企業最大限度地減少了災難導致的停機時間和資料丟失，並繼續執行它們的任務關鍵型應用程式。

更多幹貨內容請關注微信公眾號“AI前線”（ID：ai-front）

說到底，災難恢復計劃的目的就是要讓業務能夠持續運​​行，因為資料中心停機和資料丟失可能導致企業收入遭到損失，甚至完全停止運營。為了最大限度地減少災難導致的停機時間和資料丟失，企業應該要制定業務連續性計劃和災難恢復策略。

總的來說，你應該要採取三項措施來進行災難規劃：

• 設計多資料中心解決方案；

• 制定故障轉移和故障恢復手冊；

• 測試！測試！測試！

1.設計多資料中心解決方案

單個資料中心的Kafka通過叢集內資料複製提供訊息永續性。在進行資料複製時，為生產者設定acks = all選項可以帶來最強壯的可用保證，因為它可以確保叢集中的其他代理在首領代理向生產者做出確認之前接收到資料。

單資料中心設計可以提供針對代理故障的保護。如果客戶端應用程式正在通過某個代理連線到叢集，並且這個代理髮生了故障，則還會有另一個引導代理可以保證客戶端連線到叢集。但是，如果整個資料中心出現故障，那麼單個Kafka叢集就也很容易發生失效。

在設計多資料中心時，不是隻在單個資料中心中部署Kafka叢集，而是在兩個或更多資料中心部署，它們在地理位置上是分散的。它們可以在自有資料中心或在Confluent Cloud中。Confluent Replicator可在站點之間同步資料，當一個資料中心發生部分或全面故障時，應用程式可以轉移到其他資料中心。

為了幫助你設計多資料中心解決方案，我們釋出了白皮書“Disaster Recovery for Multi-Datacenter Apache Kafka Deployments”的更新版本。白皮書的最新版本介紹了多資料中心部署的設計和配置，包括多資料中心的設計、集中式schema管理和客戶端應用程式的開發。

它還詳細介紹了Confluent Replicator 5.0的新功能，包括：

• 防止主題的迴圈複製：在雙活（active-active）架構中雙向執行Replicator，它可以防止無限迴圈複製。否則的話，如果你不使用特殊主題命名模式，可能會導致無限迴圈複製，也就是將資料從cluster-1複製到cluster-2，然後再將cluster-2中的相同資料複製回cluster-1，然後再次從cluster-1複製到cluster-2。

• 時間戳保留：原始叢集在生成訊息時記錄的時間戳被傳到了目標叢集，這讓流式應用程式能夠基於原始時間戳進行操作。

• 消費者偏移量轉換：已提交的偏移量被複制到目標叢集，並對其進行轉換，讓偏移值對新叢集來說是有意義的。這樣消費者在切換到目標叢集后可以自動恢復消費訊息。

你的架構會因為你的業務需求的不同而有所不同，但你可以應用白皮書中提到的構建塊來增強災難恢復計劃。

2.制定故障轉移和故障恢復手冊

當災難發生時，你需要根據行動手冊準備好採取特定的行動。如何將客戶端應用程式轉移到新資料中心？如何啟用Confluent Schema Registry註冊新schema？你需要做些什麼才能讓消費者開始在新叢集中恢復資料消費？最重要的是，在原始資料中心恢復後，你如何切換回去？

白皮書中介紹了基本的多資料中心原則，解釋了在一個資料中心發生故障時應該怎麼辦，以及在原始資料中心恢復之後如何切換回去。你應該在你的實際部署當中應用這些原則。

如何進行手動或自動故障轉移取決於恢復時間目標（RTO），它是指完成故障轉移的時間點。理想情況下，災難發生後應該儘快將停機時間降至最低。RTO越是激進，你就越是需要自動化的工作流程，這取決服務發現機制和應用程式的故障轉移邏輯。

恢復點目標（RPO）是指應用程式可以使用已知資料恢復到的災難發生前的最近一個時間點。通常情況下，儘可能接近災難發生前的時間，以儘量減少資料丟失。特別是如果你利用Replicator 5.0提供的功能，它將極大簡化故障轉移和故障恢復的工作流程，並改善這些恢復時間。

3.測試！測試！測試！

使用白皮書中提到的構建塊來配置生產環境，然後模擬災難。遵循整個工作流程：關閉叢集，對應用程式進行故障轉移，確保它們能夠成功處理資料，然後進行故障恢復。

工作流程的每一個步驟都非常重要，主要是因為它可以確保多資料中心設計的穩健性，並可以滿足你的特定業務需求。每個部署都略有不同，為了滿足業務需求，客戶端應用程式的開發方式也略有不同，因此你需要確保一切正常。進行災難模擬的第二個原因是這樣可以測試你的故障恢復手冊，確保每個步驟都被記錄在手冊中。

為了幫助你進行測試，Confluent在GitHub儲存庫中提供了一個Docker配置檔案。免責宣告：這僅用於測試——不要將此Docker配置檔案用在生產環境中！

Docker提供了一個雙活多資料中心環境，利用了新的Replicator功能，例如通過起源標頭來防止主題迴圈複製，以及時間戳保留和消費者偏移量轉換。

要進行測試，請根據你的部署環境調整配置檔案，並執行客戶端應用程式。你還可以使用提供的示例客戶端應用程式來檢視它是如何在新資料中心中根據其在原始資料中心中停止的位置恢復資料消費的。然後，模擬故障轉移和故障回覆，測試手冊並驗證它的有效性。

總之，災難恢復計劃通常需要在多資料中心部署Kafka叢集，並且資料中心在地理位置上是分散的。採取以下三個步驟為災備做好準備：

• 設計多資料中心解決方案；

• 制定故障轉移和故障恢復手冊；

• 測試！測試！測試！

英文原文：

https://www.confluent.io/blog/3-ways-prepare-disaster-recovery-multi-datacenter-apache-kafka-deployments