使用鏡映
鏡映可讓一個 Event Streams 服務實例中的訊息持續複製到第二個實例。 使用鏡映可以改善應用程式復原力，就像第一個服務實例變成無法使用一樣，應用程式可以重新連接至第二個實例並繼續其正常作業。
此特性是完全受管理服務的一部分，只能在使用 Event Streams 企業方案的服務實例之間使用。
鏡映的特性:
- 兩個 Event Streams 服務實例之間的鏡映主題、訊息資料及消費者群組偏移，可佈建在不同的 IBM Cloud 帳戶中。
- 99.99% 可用性的 SLA，與 Event Streams 服務一致。
- 可以使用 IBM Cloud® Monitoring來監視。
鏡映的限制:
- 單向: 在一對服務實例之間一次只能以一個方向鏡映資料。 這表示鏡映提供高可用性的「主動-被動」樣式，而不是「主動-主動」。
- 非同步: 訊息必須順利產生至來源實例，然後才能鏡映至目標實例。 這表示當故障發生時，由於複製滯後，目標群集可能沒有所有訊息到故障的確切點，而且有些訊息資料可能會遺失。
- 至少一次訊息耗用: 當消費者在實例之間移動時，可能需要重新處理已處理的訊息。
在開始鏡映之前，請考量下列要點:
若要啟用鏡映，請參閱鏡映設定手冊。
鏡映概觀
鏡映選取的主題發生在兩個叢集之間，而且是單向的，表示會以一個方向將資料從單一來源叢集鏡映至單一目標叢集。 每一個叢集都有鏡映別名。 在此文件中，A 用於來源叢集別名，而 B 用於目標叢集別名。 啟用鏡映時可以配置別名，例如，它們可以是 "us-south" 和 "us-east"。
來源叢集 (A) 中稱為 mytopic 的主題會在目標叢集 (B) 上顯示為 mytopic.A，指出它源自 A。 這種類型的主題稱為 遠端主題，因為它源自遠端 (來源) 叢集。 相反，任何由使用者直接在目標群集上建立的主題都稱為_本地主題_。
若要選擇鏡射哪些主題，可使用 鏡射使用者控制 設定正則表達模式。
鏡映會自動在來源與目標實例之間轉換消費者偏移。 在舊版 Event Streams中，消費者必須使用稱為 A.checkpoints.internal 的特殊主題 (其中 A 是來源叢集的別名)。 這已不再必要，不過鏡映處理程序會繼續建立及更新檢查點主題，以與現有應用程式舊版相容。 想要使用檢查點主題的應用程式可以使用 Kafka MirrorClient 來簡化對本主題所保留資料的存取
最後，因為命名遠端主題:
- 避免使用叢集別名作為 Kafka 資源名稱的一部分。
- 確保遠端主題名稱 (例如來源主題及來源叢集別名) 未超出 Kafka 主題的長度限制 (249 個字元)。 如果遠端主題名稱超出此限制，則不會鏡映主題的訊息。
容量規劃
在規劃容量時，必須同時考慮來源和目標服務實體的網路使用量和地理位置。
網路頻寬
鏡射選定主題所需的網路頻寬必須在來源和目標服務實體的頻寬預留中加以考慮。 例如，如果來源服務實體中的應用程式產生 10 MB/秒的訊息流量到鏡射的主題，則需要額外 10 MB/秒的傳出頻寬才能將這些訊息鏡射到目標實體中。 這必須與消費應用程式已使用的任何現有外送頻寬一起允許。 監視儀表板可用來判斷服務實例中的網路用量。 如需相關資訊，請參閱監視 Event Streams 度量值。
地理位置
與任何網路一樣，最大的可實現傳輸量是資料傳輸距離的一個因素（因為延遲增加和封包流失）。 這會影響來源與目標實體之間可達到的最大吞吐量。 將目標服務實體放置在儘可能靠近來源的地理位置。
下表提供了從容量為 150 MB/s 的來源實例進行鏡射時可達到的吞吐量指南。
| 地區 | 每個分割區傳輸量上限 | 總傳輸量上限 |
|---|---|---|
| 美國南部 <-> 美國東部 | 1.5 MB/s | 35 MB/s |
| eu-gb <-> eu-de | 2.5 MB/s | 35 MB/s |
| AU-SYD <-> JP-TOK | 0.4 MB/s | 12 MB/s |
| 同一區域內 eu-gb <-> eu-gb | 2.5 MB/s | 35 MB/s |
這些數字指出：
- 總傳輸量上限：所有選取主題中可鏡映的總 MB/s 上限。
- 每個分割區傳輸量上限：單一分割區內可鏡映的 MB/s 上限。 選取為來源主題配置的分割區數目，以確保每個分割區負載保持在此限制內。
超出限制會導致源實例和目標實例中的資料之間的滯後時間越來越長。 如果來源實例失敗，則具有較大的資料延遲可能會導致大量訊息資料遺失。 即使實例之間的延遲是零，因為鏡映是非同步的，您應該預期在來源實例失敗時可能會遺失部分資料。 監視儀表板可用來判斷每個主題的延遲。 如需相關資訊，請參閱監視鏡映。
可達成傳輸量的指引是使用跨 50 個主題分割區產生的 100K 訊息產生的。 如果工作量使用較小的訊息大小 (例如，在 1K下) 或較少的分割區，則鏡映可能無法達到這些傳輸量層次。
刪除冗餘目標主題
為了避免意外刪除目標實例中的資料，從來源中刪除主題時，並不會自動從目標實例中刪除主題。 刪除目標實例上的主題由使用者負責。 如果經常刪除並建立鏡映主題，則可以在目標叢集中耗用更多磁碟及分割區額度。 可以使用目標叢集中的監視儀表板來監視使用情形，請參閱 監視 Event Streams 度量值。 您可以使用 CLI、使用者介面或管理介面來刪除不再需要的主題。
鏡映的 IAM 存取原則
由於應用程式需要存取來源群集和目的地群集，因此必須在兩個群集上設定 IAM 存取政策，並使用政策所連結的服務 ID 的 API 金鑰。 我們可以使用 IAM 萬用字元特性使用萬用字元原則指派存取權，來簡化控制鏡映資源存取權的存取原則。
如果您是 IAM 存取原則的新手，請參閱 IBM Cloud IAM 如何運作 及 管理 Event Streams 實例的鑑別，以取得詳細資料。
在兩個群集上定義下列 IAM 存取政策，其中
A.checkpoints.internal。
| 資源類型 | 資源 ID | 角色 |
|---|---|---|
| 叢集 | 讀者 | |
| group | <resource_name>.* | 依應用程式的需求 |
| topic | <resource_name>.* | 依應用程式的需求 |
| txnid | <resource_name>.* | 依應用程式的需求 |
| 主題 (特定於檢查點主題) |
|
讀者 |
將精細存取原則授與個別應用程式。 例如，對於應用程式，僅使用僅授與「讀者」存取權。
對於鏡射使用者控制，您必須在目標群集上擁有下列權限。
| 資源類型 | 資源 ID | 角色 |
|---|---|---|
| 叢集 | 管理員 |
使用鏡像功能實現基於情境的限制和網路安全控制
鏡像遵循基於拉取的模式，由目標群集啟動連線從來源群集拉取資料。 鏡像中這種以拉取為基礎的模式可在來源群集強制執行網路控制，確保只有授權的目標群集才能存取來源群集的資料。
當啟用網路安全控制（例如：基於情境的限制 (CBR) 或 CSE 允許清單）時，透過新增服務端點允許清單到來源群集，其中包括目標群集的鏡射 pod IP，即可定義網路和安全身分層級的安全路徑。 此設定可在基礎架構層級強制執行細粒度存取控制，僅允許授權的鏡像端點 (目標群集) 從原始群集取得資料。
來源群集和目標群集之間共用的憑證，嚴格來說是用於鏡像程序，並不會允許存取任何 Event Streams 部署之間的任何其他資源。 這表示鏡像程序是隔離且安全的，可防止未經授權存取其他資源。
鏡像設定前必須啟用這些網路安全控制。 如果在設置鏡射後套用了基於上下文的限制，則在群集更新前不會啟動鏡射。
如果在鏡射後啟用 CBR：
- 提出 支援票單。
- 等到下一個群集更新週期 (至少 24 小時) 變更才會生效。
- 在您的 CBR 規則中包含您的鏡像節點位址。
- 停用和重新啟用目標群集中的鏡射。
在多個實體間共用群集時的注意事項
當多個實體 (例如不同的業務單位) 共用一個實體，並需要彼此隔離時，請遵循命名指引，以簡化鏡射群集的管理和作業。
使用下列範本來命名 Kafka 資源: <entity_prefix>
其中：
- <ENTITY_PREFIX> 是使用此主題的實體的前綴。
-
是一個可選字元，用來輕鬆分隔實體和資源名稱。 -
是 Kafka 資源的名稱。
例如，如果會計業務單位需要稱為發票的主題，您可以將它稱為 accounting.invoices。
必須調整必要的存取原則。 例如，對於會計業務單位，叢集 B 上需要下列原則：
| 資源類型 | 資源 ID | 角色 |
|---|---|---|
| 叢集 | 讀者 | |
| group | accounting.* | 依應用程式的需求 |
| topic | accounting.* | 依應用程式的需求 |
| txnid | accounting.* | 依應用程式的需求 |
| topic（請注意，這是檢查點主題特有的） | A.checkpoints.internal | 讀者 |
除了 B.checkpoints.internal 上的最後一個存取政策外，叢集 A 必須具有相同的存取政策。
鏡映使用者控制項
您可以使用 CLI 或 管理 REST API 來配置鏡映。 所有鏡映使用者控制項都是在目標叢集上執行。
設定主題選取
使用正則表達 (regex) 模式，根據來源群集上的主題名稱進行鏡射選擇。 仔細選擇來源叢集上的主題名稱，方法是考量 在多個實體之間共用叢集時的考量 區段中的建議。
有了結構良好的主題名稱，例如為屬於同一群組或應用程式的主題加入前綴，就可以輕鬆控制鏡像。 有了這樣的命名慣例，未來任何符合該模式的主題都會自動建立鏡像，而不需要進行更多變更。
主題選擇以一個或多個 regex 模式清單的形式提供。 如果主題符合清單中的任何型樣，則會選取該主題。
選取用於鏡映的主題的一些型樣範例：
| 範例型樣 | 說明 |
|---|---|
^topic1$ |
完整主題名稱。 這只符合名為 topic1 的單一主題。 |
^topic1$,^topic2$ |
符合完整主題名稱的型樣清單。 這會符合名稱為 topic1 和 topic2 的兩個主題。 |
^aaa.* |
符合字首。 這符合任何以 aaa 開頭的主題名稱。 |
^aaa.*,^bbb.* |
字首上的型樣相符清單。 這符合任何以 aaa 或 bbb 開頭的主題名稱。 |
^branch_[0-9]{3}_[a-z]*$ |
比對主題名稱的更複雜正規表示式型樣。 這符合任何以 branch_ 開頭的主題名稱，後面接著正好 3 個數字，後面接著 _，以及任意數目的小寫字母。 |
.* |
鏡映所有來源主題。 |
使用 CLI 時，型樣會以逗點區隔清單形式提供。 例如，下列指令將選取名稱字首為 accounting 或 hr 的所有主題。
ibmcloud es mirroring-topic-selection-set --select '^accounting.*,^hr.*'
下列指令顯示如何使用「管理 REST API」來進行相同的選擇。 型樣採用名為 "includes" 的 JSON 陣列形式。
curl -s -X POST -H "Content-Type: application/json" -H "Authorization: <bearer token>" <admin url>/admin/mirroring/topic-selection -d '{"includes":["^accounting.*", "^hr.*"]}'
更新主題選擇會取代目前的模式集。
若要移除選項，以便不鏡映任何主題，請搭配使用 --none 選項與 CLI，或搭配使用空型樣與「管理 REST API」，如下所示。
ibmcloud es mirroring-topic-selection-set --none
curl -s -X POST -H "Content-Type: application/json" -H "Authorization: <bearer token>" <admin url>/admin/mirroring/topic-selection -d '{"includes":[""]}'
若要選擇性停用鏡像功能，請重新套用主題選擇，並刪除要停用的圖案。 例如，當 topic1, topic2, topic3 目前正在進行鏡射時，下列指令會停用 topic2 的鏡射，但保留啟用其他兩個。
ibmcloud es mirroring-topic-selection-set --select '^topic1$,^topic3$'
curl -s -X POST -H "Content-Type: application/json" -H "Authorization: <bearer token>" <admin url>/admin/mirroring/topic-selection -d '{"includes":["^topic1$","^topic3$"]}'
擷取主題選取
您可以使用下列介面來擷取鏡映選項:
CLI：
ibmcloud es mirroring-topic-selection
REST API：
curl -s -X GET -H "Authorization: <bearer token>" <admin url>/admin/mirroring/topic-selection
擷取作用中主題
您可以使用下列介面來擷取正在主動鏡映的主題:
CLI：
ibmcloud es mirroring-active-topics
REST API：
curl -s -X GET -H "Authorization: <bearer token>" <admin url>/admin/mirroring/active-topics
建置鏡映感知應用程式
生產者
我們建議生產者只產生本端主題。 在實例之間切換生產者通常需要配置變更，以便生產者使用正確的端點及認證來連接。
消耗者
消費者應該同時訂閱/取用本端與遠端主題。 這可以使用一個萬用字元的訂閱來完成。 例如，若要從 accounting.invoice 和 accounting.invoice.<ALIAS> 中消費，請使用訂閱 accounting.invoice.*。
當您同時使用本端和遠端主題時，請檢查應用程式是否需要嚴格排序。 在這種情況下，遠端主題必須先完全消耗，然後才開始從本機主題消耗。 如此，即會依訊息產生順序來處理訊息。
消費者偏移
在兩個實例之間鏡映訊息資料時，有許多原因導致指派給來源實例中訊息的偏移可能不符合目標實例中使用的偏移。 例如：
- 刪除並重建來源實例中具有相同名稱的主題。
- 使用精簡清理原則來鏡映主題。
- 使用交易產生訊息。
訊息鏡映處理程序會追蹤來源實例中的哪些偏移與目標實例中的哪些偏移相等。 為了效率，只會追蹤少量相等偏移，並優先處理接近主題標題的位置。 為來源實例中的消費者群組確定偏移時，會將偏移轉換為目標實例中最接近的相等偏移，並為目標實例中的群組確定對應的偏移。 此轉換旨在確保切換至目標叢集的消費者不會跳過已鏡映的任何訊息。 不過，當消費者切換至目標實例可能會重新處理它在來源實例中已耗用的資料時，鏡映處理程序並不會追蹤每一個相等偏移。
撰寫透過確定偏移來追蹤消費者進度的應用程式時，請考量下列事項:
- 只有在目標實例中未主動使用對應的消費者群組時，才會鏡映消費者偏移。
- 當消費者移至目標實例時，預期會重新處理部分訊息資料。
- 當消費者移至目標實例時，主題標題的後面越後面，它可能需要重新耗用的資料就越多。
- 如果您想要將重新耗用的資料量減至最少，並且可以小心管理實例之間的切換應用程式，則建議的一組步驟來達到此目的:
- 停止對來源實例產生訊息。
- 請等待消費者趕上主題的標題。
- 確定此位置的偏移。
- 將消費者切換至目標實例。
監視鏡映
您可以使用IBM Cloud Monitoring來監視鏡像。 若要啟用監視，請參閱監視 Event Streams 度量值。 目標叢集上提供監視儀表板。
Event Streams 鏡映儀表板會公開下列度量值：
- 鏡映傳輸量：來自來源 Event Streams 實例的鏡映傳輸量的每秒位元組數。 這對於查看鏡像是否啟動以及容量規劃非常有用。
- 鏡映延遲：來自來源 Event Streams 實例的每一主題鏡映延遲（秒）。 這適用於判斷落後目標叢集上的主題多遠。
在延遲視窗內產生的資料可能還未出現在目標群集上，如果來源群集發生災難，這些資料仍有可能遺失。 不過，如果鏡映是最新的，則可以在兩個叢集保持性能良好時進行失效接手，而不會有任何資料流失。
瞭解使用鏡映的回復目標
在鏡映這類資料保護方案中，回復點目標 (RPO) 和回復時間目標 (RTO) 是重要參數。 您必須瞭解與這些目標相關的決策。
您可以使用鏡像儀表板中提供的鏡像延遲指標來監控復原點目標。 此度量顯示兩個叢集之間的延遲，因此您可以估計發生災難時資料流失的數量。 您有責任監控該值，並確保它符合您的 RPO。
回復時間目標由使用者完全控制，並由下列計時時間範圍組成：
- 使用者決定故障移轉的時間。
- 使用者將應用程式故障移除所需的時間。
測試
當您讓應用程式鏡映可察覺時，測試失效接手及回復。 完成 災難回復範例實務 中概述的步驟，並使用 監視 儀表板來確保所有步驟都如預期完成。
在來源群集上刪除和重新建立具有相同名稱的主題
刪除來源叢集上的主題時，並不會自動刪除目標叢集上的對應主題。 如果您隨後在來源叢集上重建主題，則來源叢集中新主題的資料會附加至目標叢集中現有主題的結尾。
Kafka Streams 和 Kafka Connect 的考量
Kafka Streams 和 Kafka Connect 根據具有特定名稱的內部主題來儲存狀態和配置。 鏡映這些主題時，會在目標叢集上重新命名它們。 因此，Kafka Streams 和 Kafka Connect 應用程式無法在群集之間進行故障移轉和故障回復。 當您規劃這類應用程式的災難回復時，請考量此情況。