高可用性和災害復原的最佳做法
Azure Managed Instance for Apache Cassandra 是純開放原始碼 Apache Cassandra 叢集的完全受控服務。 此服務也允許根據每個工作負載的特定需求來覆寫設定，視需要提供最大彈性和控制。
Apache Cassandra 是組建高度復原性應用程式的絕佳選擇，因為其分散式本質和無主機架構 – 資料庫中的任何節點都能提供與任何其他節點完全相同的功能 – 有助於 Cassandra 的強固性和復原能力。 本文提供如何優化高可用性以及如何處理災害復原的秘訣。
RPO 與 RTO
只要您符合下列條件，Apache Cassandra 的 RPO (復原點目標) 和 RTO (復原時間目標) 通常都很低 (接近零)：
- 具有跨區域複寫的多區域部署，以及複寫因數 3。
- 已啟用可用性區域 (在入口網站或透過 Azure CLI 建立叢集時選取選項)。
- 已在用戶端驅動程式中使用負載平衡原則設定應用程式層級容錯移轉，和/或已使用流量管理員/Azure Front Door 設定負載平衡層級容錯移轉。
RTO (發生中斷時的關閉時間長度) 會很低，因為叢集會同時跨可用性區域和跨區域進行復原，而且因為 Apache Cassandra 本身依預設是高度容錯的無主機系統 (所有節點都可以寫入)。 RPO (發生中斷時的資料遺失量) 會很低，因為所有節點與資料中心之間的資料都會同步，因此發生中斷時的資料遺失量會減至最少。
注意
理論上無法達到每個 Cap 定理都同時 RTO=0 和 RPO=0。 您必須評估一致性與可用性/最佳效能之間的權衡 - 這對於每個應用程式來說都不盡相同。 例如，若您的應用程式讀取頻繁，您最好處理跨區域寫入所增加的延遲，以避免資料遺失 (偏向一致性)。 若應用程式寫入頻繁，且延遲預算有限，則可能要接受在發生主要區域中斷時會遺失一些最近寫入的風險 (偏向可用性)。
可用性區域
Cassandra 的無主機架構從頭開始提供容錯功能，而 Azure Managed Instance for Apache Cassandra 則在所選區域中支援可用性區域，以增強基礎結構層級的復原能力。 假設複寫因數為 3，支援可用性區域可確保每個複本都位於不同的可用性區域中，進而防止區域性中斷影響您的資料庫/應用程式。 建議您儘可能啟用可用性區域。
多區域備援
Cassandra 的架構加上 Azure 可用性區域支援，可提供一些層級的容錯和復原能力。 不過，請務必考慮區域中斷對應用程式的影響。 強烈建議部署多區域叢集，以防止區域層級中斷。 雖然不常發生，但潛在的影響很嚴重。
對於業務持續性而言，僅僅使資料庫成為多區域是不夠的。 應用程式的其他部分也需要以相同的方式進行部署，可選擇進行分散式部署，或選擇使用足夠的容錯移轉機制。 如果您的使用者分散在多個地理位置，則資料庫的多區域資料中心部署具有減少延遲的額外優勢，因為叢集中所有資料中心的所有節點都可以從最接近的區域同時提供讀取和寫入。 不過，如果應用程式設定為「主動-主動」，請務必考量如何將 CAP 定理套用至複本 (節點) 之間的資料一致性，以及傳遞高可用性所需的權衡。
用 CAP 定理術語來說，Cassandra 預設是一個 AP (可用分割區容錯) 資料庫系統，具有高度可調一致性。 對於大部分的使用案例，建議您使用 local_quorum 進行讀取。
- 在主動-被動寫入中，需要在可靠性與效能之間進行權衡：對於可靠性，建議使用 QUORUM_EACH，但對於大多數使用者而言，LOCAL_QUORUM 或 QUORUM 是很好的折衷方案。 但請注意，在發生區域性中斷的情況下，LOCAL_QUORUM 中的某些寫入可能會遺失。
- 對於平行執行的應用程序，大多數情況下首選 QUORUM_EACH 寫入，以確保兩個資料中心之間的一致性。
- 如果您的目標是偏向一致性 (較低的 RPO)，而非延遲或可用性 (較低的 RTO)，則應反映在您的一致性設定和複寫因數中。 根據經驗，讀取所需的仲裁節點數加上寫入所需的仲裁節點數應大於複寫因數。 例如，若您的複寫因數為 3，並且在讀取時使用 quorum_one (一個節點)，則應在寫入時使用 quorum_all (三個節點)，讓總和 4 大於複寫因數 3。
注意
Azure 受控執行個體 for Apache Cassandra 的控制平面運算符只會部署在單一區域中（最初部署第一個數據中心時選取的區域）。 在總區域中斷的不太可能事件中，我們會認可 3 小時的復原時間，以便將控制平面故障轉移到另一個區域。 這不會影響 服務的可用性 SLA ，因為數據中心仍應繼續運作。 不過，在此期間，可能無法從入口網站或資源提供者工具變更資料庫組態。
複寫
建議您偶爾稽核 keyspaces 及其複寫設定，以確保已設定資料中心之間所需的複寫。 在開發初期階段，建議您使用 cqlsh 執行簡單的測試，測試一切是否如預期運作。 例如，在連線到某個資料中心時插入一個值，然後從另一個資料中心讀取該值。
特別是，在在現有資料中心已有資料的情況下設定第二個資料中心時，請務必判斷所有資料都已複寫，且系統已就緒。 建議您使用 nodetool netstats，透過 DBA 命令監視複寫進度。 替代方法是計算每個資料表中的列數，但請記住，對於巨量資料的大小，由於 Cassandra 的分散式本質，這只能提供粗略的估計。
平衡災害復原的成本
如果您的應用程式是「主動-被動」，通常仍建議您在每個區域中部署相同容量，以讓應用程式可以立即容錯移轉至次要區域中的「熱待命」資料中心。 這可確保發生區域中斷時，不會降低效能。 大部分的 Cassandra 用戶端驅動程式都提供可起始應用程式層級容錯移轉的選項。 依預設，假設區域中斷意味著應用程式也會關閉，在此情況下，容錯移轉應在負載平衡器層級進行。
不過，若要降低佈建第二個資料中心的成本，建議您在次要區域中部署較小的 SKU 和較少的節點。 發生中斷時，透過周全且立即可用的垂直和水平擴展，可以更輕鬆地在 Azure Managed Instance for Apache Cassandra 中進行擴展。 在應用程式容錯移轉至次要區域時，即可手動擴增和擴大次要資料中心中的節點。 在此情況下，您的次要資料中心可作為成本較低的暖待命。 採用這種方法必須與在發生中斷時將系統還原至滿載所需的時間進行平衡。 請務必測試及練習在區域遺失時會發生什麼狀況。
注意
擴大節點的速度比擴增快得多。在考量垂直和水平擴展之間的平衡，以及要部署在叢集中的節點數目時，請記住這一點。
備份排程
Azure Managed Instance for Apache Cassandra 會自動備份，但您可以挑選自己的每日備份排程。 建議您選擇負載較少的時間。 雖然備份已設定為僅耗用閑置 CPU，但在某些情況下可能會在 Cassandra 中觸發壓縮，進而導致 CPU 使用量增加。 Cassandra 可以隨時進行壓縮，取決於工作負載和選擇的壓縮策略。
重要
備份的目的純粹是為了減輕意外的資料遺失或資料損毀。 不建議使用備份作為災害復原策略。 備份不是異地備援，即使是，從備份復原資料庫也可能需要很長的時間。 因此，強烈建議您使用多區域部署，加上儘可能啟用可用性區域，以減輕災害案例的風險，以及能夠有效地從中復原。 這在無法涵蓋失敗區域的極少數情況下尤其重要，如果沒有多區域複寫，可能會遺失所有資料。
下一步
本文列出一些使用 Cassandra 來組建復原應用程式的最佳做法。