如何確保我的用戶端 I/O 不會因為安全性修補程式而中斷?

1 分的閱讀內容
0

我想知道在安全性修補期間維持 MSK 叢集高可用性的一些最佳做法。

簡短描述

Amazon Managed Streaming for Apache Kafka (Amazon MSK) 使用滾動更新來維持高可用性,並在修補期間支援叢集 I/O。在此過程中,代理程式會逐一重新啟動,並且在目前重新啟動的代理程式的分區完全趕上 (同步) 之前,不會重新啟動下一個代理程式。在此更新程序期間,用戶端上看到暫時性中斷連線錯誤是正常的。

若要避免用戶端在安全性修補期間遭遇停機時間,請使用下列最佳做法讓叢集高度可用

解決方案

設定三個可用區域叢集

如果可用區域故障,則三可用區域叢集可防止任何停機時間。

Amazon MSK 設定 broker.rack 代理程式內容,以在可用區域層級實現容錯的機架感知複寫指派。這表示當您使用具有三個複寫因子 (RF) 的三個可用區域叢集時,三個磁碟分割區複本中的每一個都位於單獨的可用區域中。

**注意:**具有 RF-3 的雙可用區域叢集不允許三個分區複本中的每一個都位於單獨的可用區域中。Amazon MSK 不允許您在單一可用區域中建立叢集。

確定複寫因子為可用區域計數

當您在安全性修補期間重新啟動代理程式時,前導者無法使用。因此,其中一個追隨者複本會被選為新的前導者,以便叢集可以繼續為用戶端提供服務。

RF-1 可能會導致在滾動式更新期間無法使用分區,因為叢集沒有任何可升級為新前導者的複本。最小同步複本 (minISR) 為 1 的 RF-2 可能會導致資料遺失,即使產生者確認設定為「all」也是如此。 為了使寫入成功,一個 minISR 只需要前導者確認寫入。如果前導者複本的代理程式在確認後但在跟隨者複本趕上之前立即關閉,則會發生資料遺失。如需 min.insync.replicas 的詳細資訊,請參閱 Apache Kafka 文件

將最小 minISR 設定為最多 RF-1

當一個代理程式由於滾動更新而停止服務時,將 minISR 設定為 RF 的值可能會導致產生者故障。如果複本沒有傳送確認給產生者寫入,則產生者會引發異常。例如,如果 AZ 等於 3 且 RF 等於 3,則產生者會等待所有三個分區複本 (包括前導者) 確認訊息。當其中一個代理程式停止服務時,三個分區中只有兩個傳回確認,從而導致產生者異常。

這種情況假定產生者認可被設定為「all」。 當您將產生者認可設定為「all」時,只要至少有一個同步處理複本保持使用中狀態,記錄就不會遺失。如需產生者認可的詳細資訊,請參閱 Apache Kafka 文件

在用戶端連線字串中至少包括來自每個 AZ 的一個代理代理程式

用戶端使用單一代理程式的端點來啟動叢集的連線。在初始用戶端連線期間,代理程式會傳送中繼資料,其中包含用戶端必須存取的代理程式相關資訊。

當代理程式無法使用時,連線會失敗。例如,您在用戶端的連線字串中只有一個代理程式。在修補期間,當您重新啟動代理程式時,用戶端無法與叢集建立初始連線。

或者,您在用戶端連線字串中有多個代理程式。在此情況下,當用於建立連線的代理程式離線時,用戶端的連線字串允許容錯移轉。如需如何使用多個代理程式設定連線字串的詳細資訊,請參閱取得 Amazon MSK 叢集的啟動程式代理程式

允許重試

當您重新啟動代理程式時,該代理程式上的前導者分區無法使用。因此,Apache Kafka 將另一個代理程式上的複本分區提升為新的前導者。用戶端現在要求中繼資料更新以尋找新的前導者分區。在此變更期間,您的用戶端遇到暫時性錯誤是正常的。

依預設,用戶端已內建重試,以處理這些類型的暫時性錯誤。確認您的用戶端已設定為重試。如需設定重試的詳細資訊,請參閱 Apache Kafka 文件

AWS 官方
AWS 官方已更新 1 年前