高可用性 (HA)
使用內建 Kubernetes 特性及 IBM® Blockchain Platform 元件部署策略，讓區塊鏈網路具有更高可用性，並在叢集裡發生故障時保護網路免於關閉。
目標對象: 本主題是針對負責在 Kubernetes 叢集上規劃及配置 IBM Blockchain 2.5.1 的架構設計師及系統管理者所設計。
高可用性是 IT 基礎架構中的一個核心原則，用於保持應用程式正常啟動並執行，即使網站局部或整體故障後也不例外。 高可用性的主要目的是消除 IT 基礎架構中的潛在故障點。 例如，您可以新增備援並設定失效接手機制，來準備好應對系統故障的情況。
您可以在 IT 基礎架構的不同層次以及在叢集的不同層中達成高可用性。 適合您的可用性層次取決於多個因素，例如您的業務需求、您與組織簽訂的「服務水準合約」以及備援成本。
在繼續之前，建議您檢閱 HA 的平台專用指引:
- 如果您是在 OpenShift Container Platform 上執行，則應該檢閱 OpenShift Container Platform 文件中的 HA 建議。
然後，您可以使用本主題來取得區塊鏈特定 HA 指引的詳細資料，以及上述平台特定主題的建議。
IBM Blockchain Platform 中潛在故障點的概觀
IBM Blockchain Platform 架構設計為確保可靠性、低延遲處理及服務執行時間上限。 不過，還是可能會故障。 IBM Blockchain Platform 提供數種方法，透過新增備援及 反親緣性 原則，將更多可用性新增至叢集。 反親緣性可確保在不同工作者節點中部署相同類型和組織的區塊鏈元件。 在區塊鏈網路中新增備援，即可避免故障或運作中斷。
為了儘可能提升高可用性，建議您透過在多個地區中的多個 Kubernetes 叢集中佈建對等節點和排序節點來建置備援。 當元件分散在多個地區中並且區塊鏈分類帳分散在這些元件上時，任何單一地區中的故障都不會影響交易的處理。 對於日常交易處理，CA 並不太重要。 所有使用者都已使用 CA 登錄和登記後，在下次需要這些服務之前，都不再需要該 CA。
對等節點考量
對等節點 HA 表示一律備用對等節點，即相同頻道上的每個組織都至少有兩個對等節點可用於處理來自用戶端應用程式的要求。 多個對等節點可以部署至一個工作者節點，也可分佈至多個工作者節點、多個區域，甚至是多個地區。 每次部署多個對等節點並將其加入相同頻道時，對等節點都會充當 HA 配對，因為頻道和資料會在頻道中的所有對等節點上自動同步。 根據設計，區塊鏈網路旨在讓多個組織在相同頻道上交易。 因此，常用部署模型是，對於任何給定頻道，每個組織都有備用對等節點分佈在多個組織帳戶叢集中，所有叢集相互之間同步資料。 每個組織都可以在任何地區內其自己的叢集中具有對等節點。
為了增強 HA 涵蓋面，您可以在多個地區行為支援多個叢集，並在所有叢集中部署對等節點。 不過，如果需要高效能，則在分散對等節點時必須謹慎，確保對等節點之間的延遲和頻寬足以達到效能目標。
通道上的 錨點對等節點 可協助進行專用資料、 八卦及服務探索運作所需的跨組織通訊。 如果頻道上只存在一個錨點對等節點，而該對等節點變為無法使用，則這些組織不再連接在一起，並且無法再進行跨組織 Gossip。 因此，當您為組織建立冗餘對等節點時，請務必同時新增冗餘 通道上的錨點對等節點 。
最後，您的對等節點備援策略需要將智慧型合約背書原則納入考量，以確保您一律有足夠的對等節點可滿足 背書原則 需求。 例如，如果背書原則需要特定數目的背書，則對等節點 HA 策略需要確保一律有該數目的對等節點可用。 或者，如果背書原則需要MAJORITY個對等節點來為交易背書，則您需要確保大部分對等節點一律可用，以便繼續處理交易。
排序服務考量
IBM Blockchain Platform 2.5.1 以 Hyperledger Fabric v1.4.9 及包含 Raft 排序服務的 v2.2.1 為建置基礎。 Raft 是基於 Raft 通訊協定實作的損毀容錯 (CFT) 排序服務。 根據設計，Raft 排序節點使用 Raft 型共識自動彼此同步資料。 在 IBM Blockchain Platform中，組織網路操作員可以選擇使用單一節點 Raft 型排序節點 (無 HA) ，或在單一地區或跨多個地區 (透過 Raft 自動配置為 HA) 中的五個排序節點。
憑證管理中心 (CA) 考量
因為 CA 節點會處理區塊鏈網路的使用者登錄及登記要求，所以它們通常不是高傳輸量節點。 不過，如果 HA 對 CA 策略很重要，則可以配置節點以達到最大可用性。 Kubernetes 包含內建的 HA，會在 CA 變為無法使用時立即重新啟動 Pod。 不過，如果您無法容忍 CA 的任何關閉時間，則可以選擇配置replica sets針對您的 CA。 抄本集是一項 Kubernetes 機制，用來保證 Pod 的可用性。 抄本集的使用能確保隨時都有 Pod 的多個抄本在執行中。 如果其中一個 CA 抄本變為無法使用，Kubernetes 會立即切換到另一個 CA 抄本，因此不會產生等待 CA 重新啟動的運作中斷時間。
HA 核對清單
下表包含計劃提高 HA 程度時要考慮的選項清單。
| 單一節點 | 具有多個節點的單一叢集 | 多區域 | 多個地區中的多個叢集 | |
|---|---|---|---|---|
| 備用對等節點 |  |
|
|
|
| 頻道上的備用錨點對等節點 | |
|
|
|
| 反親緣性 (對等節點) | |
|||
| 多區域 (對等節點) | |
|||
| Raft 排序服務 | |
|
|
|
| 排序節點 | |
+ 反親緣性 |
+ 反親緣性 |
|
| CA 抄本集 | |
|
||
| 反親緣性 (CA 抄本集) | |
|
||
| 開發或測試環境 | |
|
||
| 正式作業環境 | |
|
IBM Blockchain Platform 部署人員會嘗試將對等節點、排序節點及 CA 抄本集分散到不同的工作者節點，但無法保證會因為資源限制而發生。 您也可以使用 IBM Blockchain Platform API 或區塊鏈主控台，將對等節點或排序節點部署至特定區域，以確保它們在區域失敗時具有復原力。 如需相關資訊，請參閱 多區域 HA。
潛在故障點
IBM Blockchain Platform 提供數種方法，透過新增備援及使用反親緣性原則來增加網路的可用性。 請檢閱下列各圖，進一步瞭解潛在故障點及其消除方式。 您可以根據應用程式的重要程度、服務水準和成本來選取模型。 您通常可以實作備援來達到服務水準。 所有這些情境都必須權衡實作更大備援的成本。
單一地區 HA
元件故障。
單一區域叢集：
每次部署區塊鏈元件（例如，對等節點、排序節點或 CA）時，都會為工作者節點中的元件建立新的 Pod。 根據設計，容器和 Pod 的生存時間短，並且可能會非預期故障。 例如，如果元件中發生錯誤，則容器或 Pod 可能會損毀。 因此，為了讓節點具有高可用性，您必須確定節點有足夠的實例來處理工作負載，以及有額外實例可應對故障的情況。
對等節點：需要多少對等節點？ 在正式作業情境中，建議將相同組織的三個對等節點部署至每個頻道。 此配置容許一個對等節點關閉（例如，在維護週期期間），而仍然維持兩個高可用性對等節點。 因此，若要補償對等節點故障，並且達到最基本層次的 HA，只需在工作者節點上的一個頻道上將三個對等節點部署至每個組織，就可以達到對等節點備援。 請注意，您需要確定節點上有足夠的資源可用於支援這些元件。
排序服務：如上所述，依預設，HA 排序服務是以 Raft 為基礎，並且包含五個排序節點。 因為系統可以保持流失的節點（包括主導節點），所以只要大部分排序節點（稱為「額定」）還在，就能說 Raft「損毀容錯 (CFT)」。 換句話說，如果頻道中有五個節點，則可以遺失兩個節點（剩餘三個節點）。 從主控台部署排序服務時，請選擇五節點服務以達成 HA。
CA：您可以配置 CA 的抄本集，這些抄本集在上圖中用較暗的 CA 方框代表。 抄本集可保證 CA 節點停止運作時，CA 抄本會立即開始處理要求。 如果您計劃使用 CA 抄本集，則必須佈建 PostgreSQL 資料庫的實例。 如需 如何配置 CA 抄本集的相關資訊，請參閱這些指示。
此情境在單一工作者節點上使用備用對等節點、排序節點和 CA，這可保護不受元件故障的影響，但無法避免受到節點故障的影響。 因此，它僅適用於開發和測試目的。
工作者節點故障。
具有多個工作者節點和反親緣性的單一區域叢集：
工作者節點是在實體硬體上執行的 VM。 工作者節點故障包括電源、散熱或網路功能這類硬體中斷，以及 VM 本身的問題。 您可以在佈建叢集時設定多個工作者節點，以應對工作者節點故障。 區塊鏈元件分散至多個工作者節點時，可保護您不受工作者節點故障的影響。
對等節點 IBM Blockchain Platform 部署人員反親緣性原則會將備用對等節點 (即來自相同組織的對等節點) 配送至其叢集裡的工作者節點。
排序服務：只要部署 Raft 排序服務時，都會使用反親緣性原則並根據節點上的資源可用性，在叢集裡的工作者節點上自動分散五個排序節點。
CA：與對等節點和排序節點一樣，如果為 CA 選擇抄本集，則反親緣性原則會根據資源可用性，自動將 CA 抄本集分散至叢集裡的工作者節點。
此情境在單一叢集或區域中的多個工作者節點上使用備用對等節點、排序節點和 CA 抄本集，這可保護不受節點故障的影響，但無法避免受到叢集或區域故障的影響。 因此，建議不要用於正式作業。
多區域 HA
區域故障。
具有多個工作者節點和反親緣性的多區域叢集:
請將區域視為資料中心。 區域故障會影響所有實體運算主機和 NFS 儲存空間。 故障包括電源、散熱、網路功能或儲存空間中斷，以及洪水、地震和颶風這類自然災害。 若要保護不受區域故障的影響，必須在至少兩個不同區域中具有叢集，並由外部負載平衡器對叢集進行負載平衡。
如果您可以容忍區域中斷，則單一區域已足夠用於開發及測試環境。 因此，若要利用多個區域的 HA 優點，在佈建叢集時，請確定選取多個區域。 兩個區域優於一個區域，但建議使用三個區域來實現 HA，以提高任何一個區域故障時，另外兩個區域可以承擔該區域工作負載的可能性。 如果相同的組織和頻道的備用對等節點以及排序節點分佈在多個區域中，則任何一個區域中的故障都應該不會影響網路處理交易的能力，因為工作負載會切換到其他區域中的區塊鏈節點。
您可以使用 IBM Blockchain Platform 主控台來指定在其中建立 CA、對等節點或排序節點的區域。 當您部署 CA、對等節點或排序服務 (或單一排序節點) 時，請檢查標示為 選取部署區域 的「進階部署」選項，以查看目前為 Kubernetes 叢集配置的區域清單。
如果您要部署 CA、對等節點或排序服務，則可以選擇從叢集可用的區域清單中選取區域，或讓 Kubernetes 叢集透過保留選取預設值來為您做出決定。 對於五節點排序服務，依預設，這些節點將分散到多個區域，具體取決於每個區域中可用的相對空間。 您還可以透過取消選取已為您選擇區域的預設選項，然後將這些節點分散到您擁有的可用區域中，自行分散五節點的排序服務。 如果要部署備用節點（即，已經有一個對等節點後要部署另一個對等節點），則最佳作法是將此節點部署到其他區域中。 您可以透過開啟節點磚並在 節點位置下查看，來檢查其他節點已部署至哪個區域。 或者，您可以使用 API 將對等節點或排序節點部署至特定區域。 如需如何使用 API 來執行此作業的相關資訊，請參閱 在特定區域內建立節點。
只有在使用預設資料庫類型 SQLite 且叢集已配置多個區域時，才能使用 CA 區域選項。
其他 CA 考量: 如果您為 Kubernetes 叢集配置了多個區域，則當您建立具有 PostgreSQL 資料庫及抄本集的新 CA 時，反親緣性原則會確保在這些區域中自動配置 CA 抄本集。 抄本集在上圖中用較暗的 CA 方框代表。 其他區域中必須存在足夠的資源才能使用反親緣性原則。
具有多區域功能的儲存空間:
在部署任何節點之前，您還可以選擇將 Kubernetes 叢集配置為使用 具有多區域功能的儲存體 作為持續性儲存空間。 如果沒有具有多區域功能的儲存空間，則如果整個區域關閉，則該區域中的任何區塊鏈節點都無法自動在另一個區域中啟動，因為其相關聯的持續性儲存空間在失敗區域中無法使用。 配置具有多區域功能的儲存空間時，如果發生區域故障，則對等節點和排序節點可以在另一個區域中啟動，並保持其相關聯的儲存空間完整，以確保高可用性。 為了將此功能與 IBM Blockchain Platform搭配使用，您需要將叢集配置為使用 SDS (Portworx) 儲存體。 當您部署對等節點、排序服務或排序節點時，請選取標示為 選取部署區域 的進階部署選項，然後選取 跨所有區域。
此實務範例在多個工作者節點及多個區域之間使用備援對等節點、排序節點及 CA ，以防止區域故障，但無法防止發生不太可能的整個地區故障。
如果您選擇對 CA、對等節點或排序節點使用多區域配置，則您負責為每個區域配置儲存空間，並將節點親緣性設為區域。
多地區 HA
此情境提供可能的最高階 HA。
地區故障。
具有多個工作者節點和反親緣性的多地區叢集：
整個地區故障的可能性很低。 不過，若要考量此失敗，您可以在不同地區中設定多個叢集，其中每一個叢集都有自己的鏈結主控台。 如果整個地區失敗，則其他地區中的備援對等節點或排序節點可以為工作量提供服務。 若為正式作業環境，跨多個地區配置區塊鏈 對等節點 及 排序節點 可提供最大的可用 HA 涵蓋面。
此實務範例在多個區域中的多個工作者節點之間使用備援對等節點及排序節點，以提供最高程度的 HA。 如果備援需求值得投資，則這也是建議用於正式作業網路的方法。 這五個排序節點以 2-1-2 型樣分散在三個叢集中，這表示區域 1 中有兩個節點，區域 2 中有一個節點，區域 3 中有兩個節點。 此配置容許區域中的任何單一區域或所有排序節點關閉，同時仍在 Raft 叢集中維護節點的額定。
請參閱有關設定多地區 HA 部署的主題，以取得跨多個地區配置 IBM Blockchain Platform 對等節點 及 排序節點 的步驟。
災難回復 (DR)
災難回復最重要的步驟是在多個地區之間配置您的環境，如前一節所述。 多地區配置可確保您的環境可以處理資料中心或地區災難，而零停機或資料流失。 不過，這並不會防止資料毀損或意外刪除。 若要執行此動作，您可能也要執行定期備份。
建議您定期備份與每個已部署元件相關聯的儲存體。 因為分類帳是在所有對等節點和排序節點之間共用，所以定期備份相當重要。 例如，如果無意中將不正確的資料傳播到對等節點的分類帳，或者錯誤地刪除資料，則不正確的資料可能會傳播到其他一些對等節點的分類帳。 這需要從已建立的備份點還原所有對等節點的分類帳，以確保同步。 您可以根據回復需求來決定執行備份的頻率，但一般準則是採取每日備份。
所有節點都必須是 已停止 ，才能確保可靠備份。
| 儲存空間解決方案提供者 | 指引 |
|---|---|
| OpenShift Container Platform | 您可以利用 OpenShift 儲存器平台提供給 備份持續性磁區要求的功能。 |
| Portworx | 雖然 Snapshot 功能 可用於在不停止節點的情況下進行備份，但為了取得可靠備份，必須停止節點。 |
需要還原備份時，您必須在整個網路的每個元件上還原備份。
如果您是使用 CA 抄本集，且 PostgreSQL 資料庫位於 IBM Cloud中，則備份包括在服務中。 如需相關資訊，請參閱 管理備份 主題。 否則，您需要使用協力廠商 PostgreSQL 資料庫提供者根據 DR 需求來管理資料庫備份。
備份及回復
如需備份元件以及如何回復毀損元件或網路的相關資訊，請參閱 備份及還原元件和網路。