分享方式:


Azure Cosmos DB for MongoDB V 核心中的可靠性

適用於: MongoDB 虛擬核心

本文包含有關 Azure Cosmos DB for MongoDB V 核心透過可用性區域跨區域災害復原和商務持續性所獲得區域復原能力的詳細資訊。

有關 Azure 可靠性的結構概觀,請參閱 Azure 可靠性

可用性區域支援

Azure 可用性區域是每個 Azure 區域內至少三個實體獨立的資料中心群組。 每個區域內的資料中心都配備了獨立的電源、冷卻系統和網路基礎結構。 在本機區域失敗的案例中,可用性區域的設計在於,當一個區域受影響時,讓其餘兩個區域支援區域服務、容量和高可用性。

這類失敗的範圍可從軟體和硬體故障,擴及到如地震、淹水和火災的事件。 透過 Azure 服務的備援和邏輯隔離,實現對失敗的容錯。 如需深入了解 Azure 的可用性區域,請參閱區域和可用性區域

已啟用 Azure 可用性區域的服務旨在提供正確程度的可靠性和彈性。 您可以透過兩種方式加以設定。 它們可以是區域備援,具有跨區域自動複寫功能,或者是區域性的,將執行個體釘選在特定區域。 兩種方法可以結合使用。 如需深入了解區域和區域備援結構,請參閱使用可用性區域和區域的建議

若要取得可用性區域支援,您必須啟用高可用性 (HA)。

HA 會藉由維護叢集中每個分區的待命複本,來避免資料庫停機。 如果分區關閉,Azure Cosmos DB for MongoDB 虛擬核心會將失敗分區的連入連線切換至其待命複本。

在支援可用性區域的區域中啟用 HA 時,會在與主要分區不同的可用性區域中佈建 HA 複本分區。 除非主要分區失敗,否則 HA 複本不會接收來自用戶端的要求。

如果未啟用 HA,每個分區都會有本身的本地備援儲存體 (LRS),並具有 Azure 儲存體服務所維護的三個同步複本。 單一複本失敗時,Azure 儲存體服務會偵測到失敗,並以透明的方式重新建立相關資料。 針對 LRS 儲存體持久性,請參閱備援選項摘要。 不過,在發生區域失敗時,您會有大規模停機時間和可能遺失資料的風險。

建立已啟用可用性區域的資源

若要啟用可用性區域,您必須在建立叢集時啟用高可用性 (HA),或是在 Azure 入口網站中現有叢集的調整區段啟用

跨區域災害復原和商務持續性

災害復原 (DR)是指從重大影響事件中復原,例如自然災害或不成功的部署 (導致停機和資料遺失)。 無論原因為何,解決災害的最佳辦法是定義完善且經過測試的 DR 方案,以及主動支援 DR 的應用程式設計。 開始思考建立災害復原方案之前,請參閱設計災害復原策略的建議

Microsoft 在災害復原方面採取共同責任模型。 在共同責任模型中,Microsoft 確保基準基礎結構和平台服務可供使用。 此時,許多 Azure 服務不會自動複寫資料,或從失敗區域回復為交叉複寫到另一個已啟用的區域。 您需要為這些服務制定適合工作負載的災害復原方案。 大多數在 Azure 平台即服務 (PaaS) 供應項目執行的服務,皆提供支援災害復原的功能和指導,您可以使用支援快速復原的特定服務功能來開發災害復原方案。

Azure Cosmos DB for MongoDB 虛擬核心不提供內建的自動容錯移轉或災害復原。 隨著解決方案的擴展,高可用性規劃是關鍵的一步。

單一區域地理位置的災害復原

為了充分發揮您的執行時間,請事先規劃以維護商務持續性,並使用 Azure Cosmos DB for MongoDB 虛擬核心做好災害復原的準備。

雖然 Azure 服務的設計目的是將運行時間最大化,但仍可能發生非計劃性的服務中斷。 災害復原計劃可確保您已安排相應策略來處理區域服務中斷。

Azure Cosmos DB for MongoDB 虛擬核心會自動地定期備份您的資料。 自動備份的進行不會影響資料庫作業的效能或可用性。 所有備份都是在背景自動執行,並與來源資料分開儲存於儲存體服務中。 不小心刪除或修改資源,且稍後需要原始版本時,這些自動備份就可派上用場。

根據叢集目前為使用中或最近遭刪除,自動備份會以各種間隔進行保留。

保留期限
使用中叢集 35
遭刪除叢集 7

高可用性設計

應針對執行生產工作負載的關鍵 Azure Cosmos DB for MongoDB 虛擬核心叢集啟用高可用性 (HA)。 在啟用 HA 的叢集中,每個分區都會充當主分區,並在另一個可用性區域中配置一個熱待命分區。 主要和次要分區之間的復寫會預設為同步。 在收到資料庫回應之前,對資料庫的任何修改都會保留在主要分區和次要分區 (熱待命) 上。

此服務會維護叢集各主要分區和次要分區的健康情況檢查和活動訊號。 如果主要分區因為區域或區域中斷而無法使用,則次要分區會自動提升為新的主要分區,並為新的主要分區建置後續的次要分區。 此外,如果次要分區變成無法使用,服務會自動建立新的次要分區,其中包含來自主要分區的完整資料複本。

如果服務觸發從主要分區到次要分區的容錯移轉,連線將在幕後無縫路由到新的主分區。

主要分區和次要分區之間的同步複寫可確保發生容錯移轉時不會遺失資料。

下一步