分散式儲存和一致性模型

當單片系統達到它們的極限時，它們開始被擴充套件的分散式系統所取代。這一趨勢始於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