使用多站點設定從網站故障中復原
2023 年 12 月 18 日，由 Alexander Schwartz 和 Kamesh Akella 撰寫
對於客戶身份和存取管理 (CIAM) 系統而言，高可用性至關重要，因為它是所有客戶登入系統的單一入口點。對於 Keycloak 23，有一個新的和更新的高可用性指南，描述了多站點設定。該指南提供詳細的說明和針對雲端基礎架構的藍圖，經過文件記錄、測試，並且可以隨時試用。
繼續閱讀以了解新內容，並深入了解此設定如何進行評估、測試和改進。最後，我們將展望何時這個功能不再是預覽功能。
改進的文件和新的藍圖
最近對 Keycloak 多站點設定的更新標誌著一個重要的里程碑。Keycloak 23 包含一份關於在多站點配置中設定 Keycloak 的明確的指南，其中包括雲端設定的藍圖。
本文件的高階主題為：
多站點設定的驗證
在我們發布上述指南之前，我們致力於開發工具，這些工具使我們能夠進行實驗，並針對效能、可擴展性和混沌測試我們的解決方案獲得可重現的結果。
使用這些工具，我們先測試了單站點設定，一旦該設定運作良好，也測試了多站點設定。
所有這些工具都以開放原始碼的形式提供，我們邀請您檢閱它們，向我們提供回饋，並在您的環境中使用它們來執行您自己的效能基準和回歸測試
- 資料集提供者
-
將其安裝到測試環境中的 Keycloak 伺服器中，並建立執行效能基準所需的盡可能多的使用者、客戶端、群組等。Keycloak 會在其內部快取中快取大量資訊，資料庫也會快取大量資訊，因此只有在資料庫中有適當數量的資料時，您才能發現某些問題。
- 基準
-
此處包含可用於驗證流程和 Keycloak 管理 REST 端點的現成可用情境。如果它還不符合您的需求，請將其用作程式庫，以根據現有和自訂步驟建立您自己的 Gatling 情境。這些測試以 JAR 和 Shell 指令碼封裝的形式部署，因此您只需要在負載執行器上安裝 Java 即可開始使用。
- 專用 EC2 負載驅動程式
-
使用這些 Ansible 劇本來啟動一組 EC2 實例，以對 Keycloak 測試安裝產生負載，並彙總結果。
- 在 AWS 上自動安裝 OpenShift
-
基於 Amazon Web Services 上的 Red Hat OpenShift Service (ROSA)，使用這些指令碼來佈建一個預先配置監控、記錄和實用 Operator 的實例，準備好部署 Keycloak。
- 自動 Aurora 安裝
-
設定不同變體的 Aurora (區域性或全域性)，並將其連線到 ROSA 環境。
- 適用於 Minikube 或 OpenShift 的明確 Keycloak 部署
-
這將部署 Keycloak 以及其他監控和偵錯工具，以便我們在需要時查看指標、記錄和追蹤。
- 指令碼化的 AWS Route 53 負載平衡器
-
為活動-被動設定設定 Route 53，將負載分散到不同 OpenShift 叢集中的兩個 Keycloak 部署。
- 指令碼化的多可用區部署
-
每個工作日，我們都會使用 GitHub 動作、效能測試套件從頭開始建立新的多可用區設定，並記錄結果。這樣，我們可以在發生功能和效能回歸時立即捕獲。
感謝社群中所有已試用這些工具、發現錯誤並提交改進想法的人！
Keycloak 對每個人都變得更好
使用上面列出的工具時，我們能夠重現幾種 Keycloak 需要改進的情況。以下是 Keycloak 23 中適用於單站點和多站點設定的改進項目：
- 非阻塞活性探測
-
當 Keycloak 在高負載下執行時，請求可能會在 Keycloak 實例中排隊。排隊的請求越多，回覆請求所需的時間就越長。在先前的版本中，活性探測 (
/health/live) 的請求也會排隊，探測最終會逾時，然後 Kubernetes 會重新啟動 Pod。在最新版本的 Keycloak 中，探測已重新實作為非阻塞，因此它不會排隊，因此不會逾時，而且 Pod 不會在高負載下重新啟動。 - 負載卸載
-
當請求如上所述排隊時，呼叫者將無法及時收到回應，而且 Pod 最終可能會耗盡記憶體或網路連線等資源。建議的做法是在實例無法及時處理請求時盡早放棄請求，這稱為負載卸載。Keycloak 23 現在支援新的選項
http-max-queued-requests，可以限制並行阻塞請求的數量。當超出數量時，Keycloak 會立即傳回回應503 伺服器無法使用。這有兩個好處：呼叫者會立即收到回應，並且可以稍後重試，而且資源會在伺服器端立即釋放。 - 防止 realm 和客戶端的快取暴衝
-
當新的 Keycloak 實例啟動或重新啟動時，其快取是空的。如果在高負載下，並行請求抵達 Keycloak 節點上相同的 realm 或相同的客戶端，則先前版本的 Keycloak 會在每個並行請求中從資料庫載入資料。這導致資料庫連線使用量激增和初始回應延遲。當快取或快取中的 realm 條目遭到逐出時，例如，因為它被修改時，也會發生同樣的情況。最新版本的 Keycloak 可防止這種情況發生，以便每個 Keycloak 實例僅會從資料庫擷取一次資料，然後所有其他並行請求都會使用此資料，而不會再次查詢資料庫 (請參閱 #21521 和 #22988、#24202)。
- 將 JGroup 執行緒的數量與 Quarkus 執行緒的數量對齊
-
在叢集中執行的 Keycloak 實例越多，並行處理的請求越多，JGroups 執行緒集區的負載就越高。JGroups 執行緒集區確保 Keycloak 內嵌 Infinispan 的平穩通訊，如果其容量超出，可能會導致內部 Infinispan 通訊逾時。高可用性文件現在包含關於如何設定 Quarkus 執行緒集區以不超過 JGroup 執行緒集區的文件。
- 改進的 Infinispan 指標
-
內嵌的 Infinispan 提供改進的指標，可讓您監控叢集。Keycloak 指標端點公開的指標現在僅包含目前節點的 Infinispan 指標，因此如果另一個 Pod 目前正在啟動或關閉，它們將不會被封鎖 (ISPN-15042 和 ISPN-15072)。這樣您可以在這些關鍵時刻更好地了解您的叢集。這些指標現在可以將快取名稱公開為標籤，因此可以透過將
<metrics names-as-tags="true" />新增至 Infinispan XML 配置中，更簡單地在儀表板中繪製它們。其他指標可用於站點之間的延遲。 - 可靠的 Infinispan 操作
-
我們徹底測試了 Infinispan 及其通訊層 JGroups，並且能夠修復狀態傳輸停滯 (ISPN-14982) 或初始狀態傳輸失敗的情況。即使負載平衡器有多個 IP 位址，多站點設定中使用的 Gossip 路由器現在也能正常運作 (JGRP-2722、JGRP-2721、infinispan-operator#1857 和 infinispan-operator#1856)。
藍圖或指令碼是否可以在生產環境中使用？
作為我們所做測試的一部分，我們優化了 Keycloak，這些優化已內建於 Keycloak 中。它們可供使用，無需額外配置，除非 JGroup 執行緒集區配置除外。雖然 Kubernetes 上 Keycloak 的配置可能與生產環境非常匹配，但我們預期每個組織的資料庫、網路、負載平衡器和安全性強化都會有所不同，因此您需要根據自己的需求進行調整。
這就是我們選擇以文字形式記錄藍圖的原因，因此您可以了解我們所做的選擇，以及為什麼在一個設定中配置不同的方面，而其他方面則使用其預設設定。
我們在 Keycloak Benchmark 專案中用於自動設定的指令碼側重於高可用性，並將其與易於從工程角度進行偵錯和分析的配置混合在一起。生產就緒設定不會有該功能，因此我們不建議按原樣使用這些指令碼。儘管如此，它們可以作為您自己自動化的起點。
閱讀指南並試試看！
目前，我們正在執行活動/被動設定的最終測試，並致力於自動化更多測試。我們也正在尋求社群在此關於多站點設定的 GitHub 討論中提供回饋：您喜歡這裡看到的東西嗎？是否有遺漏什麼？您的回饋至關重要！
一旦我們的測試完成，並收到社群的回饋，我們計畫將其作為一項完全支援的功能。這對社群來說是一個絕佳的機會，可以參與此設定、在您的環境中嘗試，並分享您的發現。讓我們一起建立一個更強大、更具韌性的 Keycloak！