分布式存儲和一致性模型
當單片系統達到它們的極限時，它們開始被擴展的分布式系統所取代。這一趨勢始于20年前的計算領域，當時大型機被服務器群所取代。然后進入了存儲領域(數據庫、文件系統)。在數據庫世界中，關系與NoSQL的爭論已經激烈了一段時間。
今天，我想和大家談談分布式數據存儲平臺和一致性模型。在規劃存儲基礎設施時，這是一個非常重要的需求。
讓我們從一些基礎知識開始。在分布式系統中，假設單個節點會失效。系統必須對節點故障具有彈性。因此，為了冗余，數據必須跨多個節點進行復制。
在這種情況下，讓我們問以下問題:“如果我在一個節點上執行寫入(或更新)操作，我是否總是能看到所有節點上更新的數據?”
這似乎是一個無關痛癢的問題。每個人都會給出肯定的回答。“咄,當然!”。但不要這么快。
這在分布式系統中實際上是一個很難解決的問題，特別是在保持性能的時候。做出這種保證的系統被稱為“嚴格一致”。然而，許多系統采取了簡單的方法，只提供最終的一致性。
最終一致性vs嚴格一致性
讓我們定義最終一致性和嚴格一致性。
最終一致性
下面的視頻演示了最終一致性的過程。
過程總結
- 從客戶機寫到節點1
- 從節點1向客戶端確認
- 最終寫入通過集群傳播到節點2
觀察
- System finally return latest write:通過添加單詞“finally”來削弱一致性條件
- 如果節點失敗可能導致數據丟失:添加“假設沒有永久故障”的條件。
嚴格的一致性
下面的視頻演示了嚴格一致性的過程。
過程總結
- 從客戶機寫到節點1
- 寫入通過集群傳播，從節點1傳播到節點2
- 從節點2到節點1的內部確認
- 從節點1向客戶端確認
觀察
- 系統總是返回最新的寫操作:對于任何傳入的寫操作，一旦客戶端確認了寫操作，從任何節點讀取的更新值都是可見的。
- 有保證的數據彈性:對于任何傳入的寫操作，一旦向客戶端確認了寫操作，更新就會受到冗余節點故障的保護。
系統并不總是使用嚴格的一致性
顯然，嚴格的一致性更好，因為可以保證用戶總是看到最新的數據，并且數據在寫入時就受到保護。下圖比較了兩種一致性模型。
嚴格與最終一致性
為什么不總是使用嚴格的一致性?
主要是因為實現嚴格的一致性會顯著影響性能。具體來說，延遲和吞吐量將會受到影響。影響的程度取決于具體情況。
嚴格的一致性并不總是必需的，在某些用例中最終的一致性可能就足夠了。例如，在購物車中，假設添加了一個項目，但數據中心失敗了。對客戶來說，再次添加該項目并不是一種災難。在這種情況下，最終的一致性就足夠了。
然而，你不希望你的銀行賬戶剛剛存入的錢發生這種情況。因為節點失敗而導致資金消失是不可接受的。財務交易要求嚴格的一致性。
為什么企業存儲需要嚴格的一致性
在企業存儲中，存在最終一致性是正確模型的情況，例如跨站點復制的例子。但在絕大多數情況下，嚴格的一致性是必需的。讓我們看幾個需要嚴格一致性的例子。
擴展文件存儲
碰巧有一種主要的擴展文件存儲系統只提供最終的一致性。數據只寫入一個節點(NVRAM上)并被確認。一個企業客戶曾經向我解釋說，在負載過重的情況下，一個節點可能會被標記為脫機。實際上，它是關閉的，導致客戶端在幾秒鐘前成功編寫的文件出現“文件未找到”錯誤。這對它們的應用程序造成了嚴重破壞。
從備份中即時恢復
下一代擴展備份解決方案提供了從備份中即時恢復VM。這樣的解決方案從備份系統上的備份映像副本引導虛擬機。備份系統在恢復期間充當主存儲，直到可以使用storage vMotion將數據移動回原始數據存儲為止。好處很明顯:你可以盡快恢復業務。
然而，許多擴展備份解決方案只提供寫操作的最終一致性。因此，如果恢復節點上發生故障，應用程序就會失敗，系統就會丟失生產VM的實時數據。
數據保護
嚴格的一致性保證用戶總是能看到最新的數據，并且數據一旦寫入就受到保護。由于嚴格的一致性，即使基礎設施出現故障，也能保證應用程序可用性/正常運行時間和沒有數據丟失。
在設計備份環境時，應當首先考慮向外擴展文件存儲和從備份中立即恢復的這些事項。
VM環境中的一致性模型
VMware vSphere和VMware Cloud Foundation等基礎架構需要數據彈性和高可用性。對于這樣的環境，嚴格一致性和最終一致性意味著什么?
對于任何使用傳統或現代數據保護和恢復解決方案的組織來說，一致性模型都存在風險和問題。不幸的是，人們對這個話題的認識和理解非常缺乏。
供應商提供傳統和現代的數據保護和恢復解決方案。它們提供VM或數據的快速恢復，并具有一種稱為即時恢復的特性。其目標是最小化停機時間，即恢復時間目標(RTO)。
但是，根據供應商和客戶的基礎設施的不同，恢復工作流和實現是不同的。
數據保護
可以執行一系列恢復功能(手動或自動)來恢復VMware vSphere等環境。通常，數據保護和恢復解決方案(存儲VM或數據的副本)提供某種形式的存儲抽象。vSphere將為此提供額外的計算資源。
數據恢復
在恢復VM之后，必須將它遷移回主存儲平臺。在vSphere中，存儲vMotion用于在網絡上遷移數據。可以在幾分鐘內恢復并實例化一個VM。
然而，如果這意味著要在網絡中移動數百gb，那么在幾分鐘內恢復是不可能的。根據在網絡中傳輸的大小和容量不同，這個過程可能需要很長時間才能完成。低時間將取決于網絡帶寬、接口飽和等。
數據保護和恢復的最終一致性
本視頻演示了vMotion使用最終一致性恢復vSphere環境的過程。
過程總結
- 準備VM并將其作為NFS卷在本地存儲抽象上恢復。在最終一致性模型的基礎上，從單個節點對vSphere進行了抽象。
- 從數據保護和恢復集群中的一個節點掛載NFS存儲抽象。VM在vSphere上被實例化和訪問。讀和寫I/O被定向到存儲在單個節點的存儲抽象(NFS)上的VM。
- 此時正在創建的新數據不受保護。它不分布在數據保護和恢復集群中的其他節點上。
- SvMotion開始將VM遷移回主存儲平臺。這可能需要很長時間，具體取決于環境。
- 如果數據保護和恢復集群中的某個節點在恢復到vSphere時發生故障，將會發生以下情況:
- vSphere無法訪問存儲抽象(NFS)
- VM不再可用或不可訪問
- SvMotion失敗
- 任何新創建的數據都可能丟失
當您依賴數據保護和恢復解決方案作為保險策略時，這是不可接受的結果。其結果——取決于失敗的程度——可能會讓一家公司倒閉，或者至少會讓某些人丟掉工作。
數據保護和恢復嚴格一致
本視頻演示了使用vMotion使用嚴格的一致性恢復vSphere環境的過程。
以下步驟是企業應該期待的。這是他們應該從數據保護和恢復解決方案中要求的。
- 在本地準備VM并將其恢復到一個存儲抽象上，該存儲抽象以NFS卷的形式呈現給vSphere。在嚴格一致性模型的基礎上給出了該抽象。
- 自動將存儲抽象從一個來自Cohesity集群的虛擬IP呈現并掛載到vSphere (NFS)。VM在vSphere上被實例化和訪問。讀和寫I/O被定向到存儲在存儲抽象(NFS)上的VM, NFS來自Cohesity集群的虛擬IP。
- 創建的新數據被分發到Cohesity集群中的其他節點并得到確認。
- SvMotion啟動VM遷移回主存儲平臺——這可能需要很長時間。
- 如果Cohesity集群中的一個節點發生故障，提供給vSphere的存儲抽象(NFS)仍然可用。由于使用了虛擬ip和嚴格的一致性，SvMotion將持續到完成為止，這共同降低了數據丟失的風險。
上面描述的步驟產生了企業希望利用即時恢復等特性時，從數據保護和恢復解決方案中得到的預期結果和需求。
本視頻總結了上面的信息，并演示了嚴格問題與最終一致性的對比。它將帶您一步一步地經歷兩個場景。第一個示例是關于Oracle RMAN備份的，下一個示例是執行VMware的即時恢復。
本文：http://jiagoushi.pro/node/1386
