[[418057]]

本文轉(zhuǎn)載自微信公眾號(hào)「黑客下午茶」，作者為少。轉(zhuǎn)載本文請(qǐng)聯(lián)系黑客下午茶公眾號(hào)。

系列

Longhorn 是什么?

目錄

• 1. 設(shè)計(jì)
  • 1.1. Longhorn Manager 和 Longhorn Engine
  • 1.2. 基于微服務(wù)的設(shè)計(jì)的優(yōu)勢(shì)
  • 1.3. CSI Driver
  • 1.4. CSI Plugin
  • 1.5. Longhorn UI
• 2. Longhorn 卷和主存儲(chǔ)
  • 2.4.1. 快照的工作原理
  • 2.4.2. 定期快照
  • 2.4.3. 刪除快照
  • 2.4.4. 存儲(chǔ)快照
  • 2.4.5. 崩潰一致性
  • 2.3.1. 副本讀寫操作的工作原理
  • 2.3.2. 如何添加新副本
  • 2.3.3. 如何重建有故障的副本
  • 2.1. 精簡(jiǎn)配置和卷大小
  • 2.2. 在維護(hù)模式下恢復(fù)卷
  • 2.3. 副本
  • 2.4. 快照
• 3. 備份和輔助存儲(chǔ)
  • 3.1. 備份的工作原理
  • 3.2. 定期備份
  • 3.3. 災(zāi)難恢復(fù)卷
  • 3.4. 備份存儲(chǔ)更新間隔、RTO 和 RPO
• 附錄：持久性存儲(chǔ)在 Kubernetes 中的工作原理
  • 現(xiàn)有存儲(chǔ)配置
  • 動(dòng)態(tài)存儲(chǔ)配置
  • Kubernetes 工作負(fù)載如何使用新的和現(xiàn)有的持久存儲(chǔ)
  • 具有持久存儲(chǔ)的 Kubernetes Workloads 的水平擴(kuò)展

1. 設(shè)計(jì)

Longhorn 設(shè)計(jì)有兩層：數(shù)據(jù)平面(data plane)和控制平面(control plane)。Longhorn Engine 是存儲(chǔ)控制器對(duì)應(yīng)數(shù)據(jù)平面，Longhorn Manager 對(duì)應(yīng)控制平面。

1.1. Longhorn Manager 和 Longhorn Engine

Longhorn Manager Pod 作為 Kubernetes DaemonSet 在 Longhorn 集群中的每個(gè)節(jié)點(diǎn)上運(yùn)行。它負(fù)責(zé)在 Kubernetes 集群中創(chuàng)建和管理卷，并處理來自 UI 或 Kubernetes 卷插件的 API 調(diào)用。它遵循 Kubernetes controller pattern，有時(shí)也稱為 operator pattern。

Longhorn Manager 與 Kubernetes API 服務(wù)器通信以創(chuàng)建新的 Longhorn 卷 CRD。然后 Longhorn Manager 觀察 API 服務(wù)器的響應(yīng)，當(dāng)看到 Kubernetes API 服務(wù)器創(chuàng)建了一個(gè)新的 Longhorn volume CRD 時(shí)，Longhorn Manager 就創(chuàng)建了一個(gè)新的卷。

當(dāng) Longhorn Manager 被要求創(chuàng)建一個(gè)卷時(shí)，它會(huì)在該卷所連接的節(jié)點(diǎn)上創(chuàng)建一個(gè) Longhorn Engine 實(shí)例，并在每個(gè)將放置副本的節(jié)點(diǎn)上創(chuàng)建一個(gè)副本。副本應(yīng)放置在不同的主機(jī)上以確保最大的可用性。

副本的多條數(shù)據(jù)路徑確保了 Longhorn 卷的高可用性。即使某個(gè)副本或引擎出現(xiàn)問題，問題也不會(huì)影響所有副本或 Pod 對(duì)卷的訪問。Pod 仍將正常運(yùn)行。

Longhorn Engine 始終在與使用 Longhorn volume 的 Pod 相同的節(jié)點(diǎn)中運(yùn)行。它跨存儲(chǔ)在多個(gè)節(jié)點(diǎn)上的多個(gè)副本同步復(fù)制卷。

引擎(Engine)和副本(replicas)使用 Kubernetes 進(jìn)行編排。

在下圖中，

• Longhorn volumes 有三個(gè)實(shí)例。
• 每個(gè)卷都有一個(gè)專用控制器，稱為 Longhorn Engine 并作為 Linux 進(jìn)程運(yùn)行。
• 每個(gè) Longhorn 卷有兩個(gè)副本(replica)，每個(gè)副本是一個(gè) Linux 進(jìn)程。
• 圖中的箭頭表示卷(volume)、控制器實(shí)例(controller instance)、副本實(shí)例(replica instances)和磁盤之間的讀/寫數(shù)據(jù)流。
• 通過為每個(gè)卷創(chuàng)建單獨(dú)的 Longhorn Engine，如果一個(gè)控制器出現(xiàn)故障，其他卷的功能不會(huì)受到影響。

圖 1. 卷、Longhorn 引擎、副本實(shí)例和磁盤之間的讀/寫數(shù)據(jù)流

1.2. 基于微服務(wù)的設(shè)計(jì)的優(yōu)勢(shì)

在 Longhorn 中，每個(gè) Engine 只需要服務(wù)一個(gè)卷，簡(jiǎn)化了存儲(chǔ)控制器的設(shè)計(jì)。由于控制器軟件的故障域與單個(gè)卷隔離，因此控制器崩潰只會(huì)影響一個(gè)卷。

Longhorn Engine 足夠簡(jiǎn)單和輕便，因此我們可以創(chuàng)建多達(dá) 100,000 個(gè)獨(dú)立的引擎。 Kubernetes 調(diào)度這些獨(dú)立的引擎，從一組共享的磁盤中提取資源，并與 Longhorn 合作形成一個(gè)彈性的分布式塊存儲(chǔ)系統(tǒng)。

因?yàn)槊總€(gè)卷都有自己的控制器，所以每個(gè)卷的控制器和副本實(shí)例也可以升級(jí)，而不會(huì)導(dǎo)致 IO 操作明顯中斷。

Longhorn 可以創(chuàng)建一個(gè)長時(shí)間運(yùn)行的作業(yè)(long-running job)來協(xié)調(diào)所有實(shí)時(shí)卷的升級(jí)，而不會(huì)中斷系統(tǒng)的持續(xù)運(yùn)行。為確保升級(jí)不會(huì)導(dǎo)致不可預(yù)見的問題，Longhorn 可以選擇升級(jí)一小部分卷，并在升級(jí)過程中出現(xiàn)問題時(shí)回滾到舊版本。

1.3. CSI Driver

Longhorn CSI driver 獲取塊設(shè)備(block device)，對(duì)其進(jìn)行格式化，然后將其掛載到節(jié)點(diǎn)上。然后 kubelet 將設(shè)備綁定掛載到 Kubernetes Pod 中。這允許 Pod 訪問 Longhorn volume。

所需的 Kubernetes CSI 驅(qū)動(dòng)程序鏡像將由 longhorn driver deployer 自動(dòng)部署。

1.4. CSI Plugin

Longhorn 通過 CSI Plugin 在 Kubernetes 中進(jìn)行管理。這允許輕松安裝 Longhorn 插件。

Kubernetes CSI plugin 調(diào)用 Longhorn 創(chuàng)建卷，為 Kubernetes 工作負(fù)載創(chuàng)建持久數(shù)據(jù)(persistent data)。 CSI plugin 使您能夠創(chuàng)建(create)、刪除(delete)、附加(attach)、分離(detach)、掛載(mount)卷，并對(duì)卷進(jìn)行快照。Longhorn 提供的所有其他功能都是通過 Longhorn UI 實(shí)現(xiàn)的。

Kubernetes 集群內(nèi)部使用 CSI interface 與 Longhorn CSI plugin 進(jìn)行通信。Longhorn CSI plugin 使用 Longhorn API 與 Longhorn Manager 通信。

Longhorn 確實(shí)利用了 iSCSI，因此可能需要對(duì)節(jié)點(diǎn)進(jìn)行額外配置。這可能包括根據(jù)發(fā)行版安裝 open-iscsi 或 iscsiadm。

1.5. Longhorn UI

Longhorn UI 通過 Longhorn API 與 Longhorn Manager 進(jìn)行交互，并作為 Kubernetes 的補(bǔ)充。通過 Longhorn 界面可以管理快照(snapshots)、備份(backups)、節(jié)點(diǎn)(nodes)和磁盤(disks)。

此外，集群工作節(jié)點(diǎn)的空間使用情況由 Longhorn UI 收集和說明。有關(guān)詳細(xì)信息，請(qǐng)參見此處。

2. Longhorn 卷和主存儲(chǔ)

創(chuàng)建 volume 時(shí)，Longhorn Manager 將為每個(gè) volume 創(chuàng)建 Longhorn Engine 微服務(wù)和副本作為微服務(wù)。這些微服務(wù)一起構(gòu)成了一個(gè) Longhorn volume。每個(gè)復(fù)制副本應(yīng)放置在不同的節(jié)點(diǎn)或不同的磁盤上。

Longhorn Manager 創(chuàng)建 Longhorn Engine 后，它將連接到副本(replicas)。引擎在 Pod 運(yùn)行的節(jié)點(diǎn)上暴露塊設(shè)備(block device)。

kubectl 支持創(chuàng)建 Longhorn 卷。

2.1. 精簡(jiǎn)配置和卷大小

Longhorn 是一個(gè)精簡(jiǎn)配置(thin-provisioned)的存儲(chǔ)系統(tǒng)。這意味著 Longhorn volume 只會(huì)占用它目前需要的空間。例如，如果您分配了 20 GB 的卷，但只使用了其中的 1 GB，則磁盤上的實(shí)際數(shù)據(jù)大小將為 1 GB。您可以在 UI 的卷詳細(xì)信息中查看實(shí)際數(shù)據(jù)大小。

如果您從卷中刪除了內(nèi)容，則 Longhorn 卷本身的大小不會(huì)縮小。例如，如果您創(chuàng)建了一個(gè) 20 GB 的卷，使用了 10 GB，然后刪除了 9 GB 的內(nèi)容，則磁盤上的實(shí)際大小仍然是 10 GB 而不是 1 GB。發(fā)生這種情況是因?yàn)?Longhorn 在塊級(jí)別(block level)而不是文件系統(tǒng)級(jí)別(filesystem level)上運(yùn)行， 因此 Longhorn 不知道內(nèi)容是否已被用戶刪除。該信息主要保存在文件系統(tǒng)級(jí)別。

2.2. 在維護(hù)模式下恢復(fù)卷

從 Longhorn UI 附加卷時(shí)，會(huì)有一個(gè)維護(hù)模式復(fù)選框。它主要用于從快照恢復(fù)卷。

該選項(xiàng)將導(dǎo)致在不啟用前端(塊設(shè)備或 iSCSI)的情況下附加卷，以確保在附加卷時(shí)沒有人可以訪問卷數(shù)據(jù)。

v0.6.0 之后，快照恢復(fù)操作要求卷處于維護(hù)模式。這是因?yàn)槿绻趻燧d或使用卷時(shí)修改了塊設(shè)備的內(nèi)容，則會(huì)導(dǎo)致文件系統(tǒng)損壞。

檢查卷狀態(tài)而不必?fù)?dān)心數(shù)據(jù)被意外訪問也很有用。

2.3. 副本

每個(gè)副本都包含 Longhorn 卷的一系列快照?？煺站拖耒R像(image)的一層，最舊的快照用作基礎(chǔ)層，較新的快照在頂部。如果數(shù)據(jù)覆蓋舊快照中的數(shù)據(jù)，則數(shù)據(jù)僅包含在新快照中。一系列快照一起顯示了數(shù)據(jù)的當(dāng)前狀態(tài)。

對(duì)于每個(gè) Longhorn 卷，該卷的多個(gè)副本應(yīng)該在 Kubernetes 集群中運(yùn)行，每個(gè)副本位于單獨(dú)的節(jié)點(diǎn)上。所有副本都被同等對(duì)待，Longhorn Engine 始終運(yùn)行在與 pod 相同的節(jié)點(diǎn)上，pod 也是卷的消費(fèi)者。通過這種方式，我們可以確保即使 Pod 宕機(jī)，引擎也可以被轉(zhuǎn)移到另一個(gè) Pod，您的服務(wù)將不會(huì)中斷。

默認(rèn)的副本數(shù)(replica count)可以在 settings 中更改。當(dāng)附加一個(gè)卷時(shí)，可以在 UI 中更改卷的副本計(jì)數(shù)。

如果當(dāng)前運(yùn)行良好的副本計(jì)數(shù)小于指定的副本計(jì)數(shù)，Longhorn 將開始重新生成新的副本。

如果當(dāng)前正常的副本計(jì)數(shù)大于指定的副本計(jì)數(shù)，Longhorn 將不執(zhí)行任何操作。在這種情況下，如果副本失敗或被刪除，Longhorn 將不會(huì)開始重新構(gòu)建新的副本，除非健康的副本計(jì)數(shù)低于指定的副本計(jì)數(shù)。

Longhorn 副本使用支持精簡(jiǎn)配置的 Linux sparse files 構(gòu)建。

2.3.1. 副本讀寫操作的工作原理

從卷的副本讀取數(shù)據(jù)時(shí)，如果可以在實(shí)時(shí)數(shù)據(jù)中找到數(shù)據(jù)，則使用該數(shù)據(jù)。如果沒有，將讀取最新的快照。如果在最新的快照中找不到數(shù)據(jù)，則讀取次早的快照，依此類推，直到讀取最舊的快照。

在創(chuàng)建快照時(shí)，會(huì)創(chuàng)建一個(gè)差異(differencing)磁盤。隨著快照數(shù)量的增加，差異磁盤鏈(也稱為快照鏈)可能會(huì)變得很長。因此，為了提高讀取性能，Longhorn 維護(hù)了一個(gè)讀取索引，該索引記錄哪個(gè)差異磁盤為每個(gè) 4K 存儲(chǔ)塊保存有效數(shù)據(jù)。

在下圖中，卷有八個(gè)塊。讀取索引(read index)有八個(gè)條目，并且在讀取操作發(fā)生時(shí)被惰性填充。

寫操作重置讀索引，使其指向?qū)崟r(shí)數(shù)據(jù)。實(shí)時(shí)數(shù)據(jù)由某些索引上的數(shù)據(jù)和其他索引上的空白空間組成。

除了讀取索引之外，我們目前沒有維護(hù)額外的元數(shù)據(jù)來指示使用了哪些塊。

圖 2. 讀取索引如何跟蹤保存最新數(shù)據(jù)的快照

上圖用顏色編碼(color-coded)，根據(jù)讀取索引顯示哪些塊包含最新的數(shù)據(jù)，最新數(shù)據(jù)的來源也列在下表中：

Read Index	Source of the latest data
0	最新快照
1	實(shí)時(shí)數(shù)據(jù)
2	最舊的快照
3	最舊的快照
4	最舊的快照
5	實(shí)時(shí)數(shù)據(jù)
6	實(shí)時(shí)數(shù)據(jù)
7	實(shí)時(shí)數(shù)據(jù)

請(qǐng)注意，如上圖綠色箭頭所示，讀取索引的 Index 5 之前指向第二個(gè)最舊的快照作為最近數(shù)據(jù)的來源，然后在 4K 塊時(shí)更改為指向?qū)崟r(shí)數(shù)據(jù) Index 5 的存儲(chǔ)被實(shí)時(shí)數(shù)據(jù)覆蓋。

讀取索引保存在內(nèi)存中，每個(gè) 4K 塊消耗一個(gè)字節(jié)。字節(jié)大小的讀取索引意味著您可以為每個(gè)卷創(chuàng)建多達(dá) 254 個(gè)快照。

讀取索引為每個(gè)副本消耗一定數(shù)量的內(nèi)存數(shù)據(jù)結(jié)構(gòu)。例如，一個(gè) 1 TB 的卷消耗 256 MB 的內(nèi)存讀取索引。

2.3.2 如何添加新副本

添加新副本時(shí)，現(xiàn)有副本將同步到新副本。第一個(gè)副本是通過從實(shí)時(shí)數(shù)據(jù)中獲取新快照來創(chuàng)建的。

以下步驟顯示了 Longhorn 如何添加新副本的更詳細(xì)細(xì)分：

1. Longhorn Engine 暫停。
2. 假設(shè)副本中的快照鏈由實(shí)時(shí)數(shù)據(jù)和快照組成。創(chuàng)建新副本后，實(shí)時(shí)數(shù)據(jù)將成為最新(第二個(gè))快照，并創(chuàng)建新的空白版本的實(shí)時(shí)數(shù)據(jù)。
3. 新副本以 WO(只寫)模式創(chuàng)建。
4. Longhorn Engine 取消暫停。
5. 所有快照均已同步。
6. 新副本設(shè)置為 RW(讀寫)模式。

2.3.3. 如何重建有故障的副本

Longhorn 將始終嘗試為每個(gè)卷維護(hù)至少給定數(shù)量的健康副本。

當(dāng)控制器在其副本之一中檢測(cè)到故障時(shí)，它會(huì)將副本標(biāo)記為處于錯(cuò)誤狀態(tài)(error state)。Longhorn Manager 負(fù)責(zé)啟動(dòng)和協(xié)調(diào)重建故障副本的過程。

為了重建故障副本，Longhorn Manager 創(chuàng)建一個(gè)空白副本并調(diào)用 Longhorn Engine 將空白副本添加到卷的副本集中。

為了添加空白副本，Engine 執(zhí)行以下操作：

• 暫停所有讀取和寫入操作。
• 以 WO(只寫)模式添加空白副本。
• 創(chuàng)建所有現(xiàn)有副本的快照，現(xiàn)在它的頭部有一個(gè)空白的差異磁盤(differencing disk)。
• 取消暫停所有讀取寫入操作。只有寫操作會(huì)被分派到新添加的副本。
• 啟動(dòng)后臺(tái)進(jìn)程以將除最近的差異磁盤之外的所有磁盤從良好副本同步到空白副本。
• 同步完成后，所有副本現(xiàn)在都擁有一致的數(shù)據(jù)，卷管理器將新副本設(shè)置為 RW (讀寫)模式。

最后，Longhorn Manager 調(diào)用 Longhorn Engine 從其副本集中移除故障副本。

2.4. 快照

快照功能使卷能夠恢復(fù)到歷史中的某個(gè)點(diǎn)。輔助存儲(chǔ)中的備份也可以從快照構(gòu)建。

從快照還原卷時(shí)，它會(huì)反映創(chuàng)建快照時(shí)卷的狀態(tài)。

快照功能也是 Longhorn 重建過程的一部分。每次 Longhorn 檢測(cè)到一個(gè)副本宕機(jī)時(shí)，它會(huì)自動(dòng)創(chuàng)建(系統(tǒng))快照并開始在另一個(gè)節(jié)點(diǎn)上重建它。

2.4.1. 快照的工作原理

快照就像鏡像(image)的一層，最舊的快照用作基礎(chǔ)層，較新的快照在頂部。如果數(shù)據(jù)覆蓋舊快照中的數(shù)據(jù)，則數(shù)據(jù)僅包含在新快照中。一系列快照一起顯示了數(shù)據(jù)的當(dāng)前狀態(tài)。

快照在創(chuàng)建后無法更改，除非快照被刪除，在這種情況下，其更改會(huì)與下一個(gè)最近的快照合并。新數(shù)據(jù)始終寫入實(shí)時(shí)版本。新快照始終從實(shí)時(shí)數(shù)據(jù)創(chuàng)建。

要?jiǎng)?chuàng)建新快照，實(shí)時(shí)數(shù)據(jù)將成為最新的快照。然后創(chuàng)建一個(gè)新的空白版本的實(shí)時(shí)數(shù)據(jù)，取代舊的實(shí)時(shí)數(shù)據(jù)。

2.4.2. 定期快照

為了減少快照占用的空間，用戶可以安排一個(gè)定期快照(recurring snapshot)或備份(backup)，保留多個(gè)快照，這將自動(dòng)按計(jì)劃創(chuàng)建一個(gè)新的快照/備份，然后清理任何過多的快照/備份。

2.4.3. 刪除快照

不需要的快照可以通過界面手動(dòng)刪除。當(dāng)系統(tǒng)生成的快照被觸發(fā)刪除時(shí)，系統(tǒng)會(huì)自動(dòng)將其標(biāo)記為刪除。

在 Longhorn 中，不能刪除最新的快照。這是因?yàn)闊o論何時(shí)刪除快照，Longhorn 都會(huì)將其內(nèi)容與下一個(gè)快照合并，以便下一個(gè)和以后的快照保留正確的內(nèi)容。

但 Longhorn 無法對(duì)最新快照?qǐng)?zhí)行此操作，因?yàn)闆]有更多最近的快照可以與已刪除的快照合并。最新快照的下一個(gè)“快照”是實(shí)時(shí)卷(volume-head)，此時(shí)用戶正在讀/寫，因此不會(huì)發(fā)生合并過程。

相反，最新的快照將被標(biāo)記為已刪除，并且在可能的情況下，將在下次對(duì)其進(jìn)行清理。

要清理最新快照，可以創(chuàng)建一個(gè)新快照，然后刪除以前的“最新”快照。

2.4.4. 存儲(chǔ)快照

快照存儲(chǔ)在本地，作為卷的每個(gè)副本的一部分。它們存儲(chǔ)在 Kubernetes 集群中節(jié)點(diǎn)的磁盤上?？煺张c主機(jī)物理磁盤上的卷數(shù)據(jù)存儲(chǔ)在同一位置。

2.4.5. 崩潰一致性

Longhorn 是崩潰一致(crash-consistent)的塊存儲(chǔ)解決方案。

操作系統(tǒng)在寫入塊層(block layer)之前將內(nèi)容保留在緩存中是正常的。這意味著如果所有副本都關(guān)閉，那么 Longhorn 可能不包含關(guān)閉前立即發(fā)生的更改，因?yàn)閮?nèi)容保存在操作系統(tǒng)級(jí)緩存中，尚未傳輸?shù)?Longhorn 系統(tǒng)。

此問題類似于臺(tái)式計(jì)算機(jī)因停電而關(guān)閉時(shí)可能發(fā)生的問題。恢復(fù)供電后，您可能會(huì)發(fā)現(xiàn)硬盤驅(qū)動(dòng)器中有一些損壞的文件。

要在任何給定時(shí)刻強(qiáng)制將數(shù)據(jù)寫入塊層(block layer)，可以在節(jié)點(diǎn)上手動(dòng)運(yùn)行同步命令，或者可以卸載磁盤。在任一情況下，操作系統(tǒng)都會(huì)將內(nèi)容從緩存寫入塊層(block layer)。

Longhorn 在創(chuàng)建快照之前自動(dòng)運(yùn)行同步命令。

3. 備份和輔助存儲(chǔ)

備份是備份存儲(chǔ)(backupstore)中的一個(gè)對(duì)象，它是 Kubernetes 集群外部的 NFS 或 S3 兼容對(duì)象存儲(chǔ)。備份提供了一種二級(jí)(secondary)存儲(chǔ)形式，因此即使您的 Kubernetes 集群變得不可用，您的數(shù)據(jù)仍然可以被檢索。

由于卷復(fù)制(volume replication)是同步的，而且由于網(wǎng)絡(luò)延遲(network latency)，很難進(jìn)行跨地域復(fù)制。備份存儲(chǔ)(backupstore)也用作解決此問題的媒介。

在 Longhorn 設(shè)置中配置備份目標(biāo)后，Longhorn 可以連接到備份存儲(chǔ)并在 Longhorn UI 中向您顯示現(xiàn)有備份列表。

如果 Longhorn 在第二個(gè) Kubernetes 集群中運(yùn)行，它還可以將災(zāi)難恢復(fù)卷同步到二級(jí)存儲(chǔ)(secondary storage)中的備份， 以便您的數(shù)據(jù)可以在第二個(gè) Kubernetes 集群中更快地恢復(fù)。

3.1. 備份的工作原理

使用一個(gè)快照作為源創(chuàng)建備份，以便它反映創(chuàng)建快照時(shí)卷數(shù)據(jù)的狀態(tài)。

與快照相比，備份可以被認(rèn)為是一系列快照的扁平化版本。與將分層鏡像(layered image)轉(zhuǎn)換為平面鏡像(flat image)時(shí)信息丟失的方式類似，當(dāng)一系列快照轉(zhuǎn)換為備份時(shí)，數(shù)據(jù)也會(huì)丟失。在這兩種轉(zhuǎn)換中，任何被覆蓋的數(shù)據(jù)都將丟失。

由于備份不包含快照，因此它們不包含卷數(shù)據(jù)更改的歷史記錄。從備份還原卷后，該卷最初包含一個(gè)快照。此快照是原始鏈中所有快照的合并版本，它反映了創(chuàng)建備份時(shí)卷的實(shí)時(shí)數(shù)據(jù)。

雖然快照可以達(dá)到 TB(terabytes)，但備份由 2 MB 文件組成。

同一原始卷的每個(gè)新備份都是增量的，檢測(cè)并在快照之間傳輸更改的塊。這是一項(xiàng)相對(duì)容易的任務(wù)， 因?yàn)槊總€(gè)快照都是一個(gè)差異(differencing)文件，并且只存儲(chǔ)上一個(gè)快照的更改。

為了避免存儲(chǔ)大量的小存儲(chǔ)塊，Longhorn 使用 2 MB 塊執(zhí)行備份操作。這意味著，如果 2MB 邊界中的任何 4K 塊發(fā)生更改，Longhorn 將備份整個(gè) 2MB 塊。這提供了可管理性和效率之間的正確平衡。

圖 3. 二級(jí)存儲(chǔ)中的備份與主存儲(chǔ)中的快照之間的關(guān)系

上圖描述了如何從 Longhorn 中的快照創(chuàng)建備份：

• 圖表的主存儲(chǔ)一側(cè)顯示了 Kubernetes 集群中 Longhorn 卷的一個(gè)副本。副本由四個(gè)快照鏈組成。按照從新到舊的順序，快照是 Live Data、snap3、snap2 和 snap1。
• 圖表的二級(jí)存儲(chǔ)側(cè)顯示了外部對(duì)象存儲(chǔ)服務(wù)(如 S3)中的兩個(gè)備份。
• 在二級(jí)存儲(chǔ)中，backup-from-snap2 的顏色編碼顯示它包括來自 snap1 的藍(lán)色變化和來自 snap2 的綠色變化。

snap2 中的任何更改都沒有覆蓋 snap1 中的數(shù)據(jù)，因此 snap1 和 snap2 中的更改都包含在 backup-from-snap2 中。

• 名為 backup-from-snap3 的備份反映了創(chuàng)建 snap3 時(shí)卷數(shù)據(jù)的狀態(tài)。顏色編碼和箭頭表示 backup-from-snap3 包含來自 snap3 的所有深紅色更改，但僅包含來自 snap2 的綠色更改之一。

這是因?yàn)?snap3 中的一項(xiàng)紅色更改覆蓋了 snap2 中的一項(xiàng)綠色更改。這說明了備份如何不包括更改的完整歷史記錄，因?yàn)樗鼈儗⒖煺张c其之前的快照混為一談。

• 每個(gè)備份維護(hù)自己的一組 2 MB 塊。每個(gè) 2 MB 塊僅備份一次。兩個(gè)備份共享一個(gè)綠色塊和一個(gè)藍(lán)色塊。

當(dāng)備份從二級(jí)存儲(chǔ)中刪除時(shí)，Longhorn 不會(huì)刪除它使用的所有塊。相反，它會(huì)定期執(zhí)行垃圾收集以清除輔助存儲(chǔ)中未使用的塊。

屬于同一卷的所有備份的 2 MB 塊存儲(chǔ)在一個(gè)公共目錄下，因此可以跨多個(gè)備份共享。

為了節(jié)省空間，備份之間沒有變化的 2 MB 塊可以重復(fù)用于在二級(jí)存儲(chǔ)中共享相同備份卷的多個(gè)備份。由于校驗(yàn)(checksums)和用于尋址 2 MB 塊，因此我們對(duì)同一卷中的 2 MB 塊實(shí)現(xiàn)了某種程度的重復(fù)數(shù)據(jù)刪除。

卷級(jí)元數(shù)據(jù)(Volume-level metadata)存儲(chǔ)在 volume.cfg 中。每個(gè)備份的元數(shù)據(jù)文件(例如 snap2.cfg)相對(duì)較小， 因?yàn)樗鼈儍H包含備份中所有 2 MB 塊的offsets和checksums。

壓縮每個(gè) 2 MB 塊(.blk 文件)。

3.2. 定期備份

可以使用定期快照(recurring snapshot)和備份功能來安排備份操作，但也可以根據(jù)需要進(jìn)行。

建議為您的卷安排定期備份。如果備份存儲(chǔ)(backupstore)不可用，建議改為安排定期快照。

創(chuàng)建備份涉及通過網(wǎng)絡(luò)復(fù)制數(shù)據(jù)，因此需要時(shí)間。

3.3. 災(zāi)難恢復(fù)卷

災(zāi)難恢復(fù) (DR) 卷是一種特殊卷，可在整個(gè)主集群出現(xiàn)故障時(shí)將數(shù)據(jù)存儲(chǔ)在備份集群中。DR 卷用于提高 Longhorn 卷的彈性。

由于 DR 卷的主要用途是從備份中恢復(fù)數(shù)據(jù)，因此此類卷在激活之前不支持以下操作：

• 創(chuàng)建、刪除和恢復(fù)快照
• 創(chuàng)建備份
• 創(chuàng)建持久卷
• 創(chuàng)建持久卷聲明

可以從備份存儲(chǔ)中的卷備份創(chuàng)建 DR 卷。創(chuàng)建 DR 卷后，Longhorn 將監(jiān)控其原始備份卷并從最新備份增量恢復(fù)。備份卷是備份存儲(chǔ)中包含同一卷的多個(gè)備份的對(duì)象。

如果主集群中的原始卷宕機(jī)，可以立即激活備份集群中的 DR 卷，這樣可以大大減少將數(shù)據(jù)從備份存儲(chǔ)恢復(fù)到備份集群中的卷所需的時(shí)間。

當(dāng) DR 卷被激活時(shí)，Longhorn 將檢查原始卷的最后備份。如果該備份尚未恢復(fù)，則將開始恢復(fù)，并且激活操作將失敗。用戶需要等待恢復(fù)完成后再重試。

如果存在任何 DR 卷，則無法更新 Longhorn 設(shè)置中的備份目標(biāo)。

DR 卷被激活后，它會(huì)變成一個(gè)普通的 Longhorn 卷并且不能被停用。

3.4. 備份存儲(chǔ)更新間隔、RTO 和 RPO

通常增量恢復(fù)由定期備份存儲(chǔ)更新觸發(fā)。用戶可以在設(shè)置(Setting)-通用(General)-備份(Backupstore)存儲(chǔ)輪詢間隔中設(shè)置備份存儲(chǔ)更新間隔。

請(qǐng)注意，此間隔可能會(huì)影響恢復(fù)時(shí)間目標(biāo) (RTO)。如果時(shí)間過長，容災(zāi)卷恢復(fù)的數(shù)據(jù)量可能比較大，時(shí)間會(huì)比較長。

至于恢復(fù)點(diǎn)目標(biāo) (RPO)，它由備份卷的定期備份計(jì)劃確定。如果正常卷 A 的定期備份計(jì)劃每小時(shí)創(chuàng)建一個(gè)備份，則 RPO 為一小時(shí)。您可以在此處查看如何在 Longhorn 中設(shè)置定期備份。

以下分析假設(shè)該卷每小時(shí)創(chuàng)建一個(gè)備份，并且從一個(gè)備份中增量恢復(fù)數(shù)據(jù)需要五分鐘：

如果 Backupstore 輪詢間隔為 30 分鐘，則自上次恢復(fù)以來最多有一個(gè)備份數(shù)據(jù)?；謴?fù)一份備份的時(shí)間為五分鐘，因此 RTO 為五分鐘。

如果 Backupstore 輪詢間隔為 12 小時(shí)，則自上次恢復(fù)以來最多有 12 個(gè)數(shù)據(jù)備份。恢復(fù)備份的時(shí)間為 5 * 12 = 60 分鐘，因此 RTO 為 60 分鐘。

附錄：持久性存儲(chǔ)在 Kubernetes 中的工作原理

要了解 Kubernetes 中的持久存儲(chǔ)，重要的是要了解 Volumes、PersistentVolumes、PersistentVolumeClaims 和 StorageClasses，以及它們?nèi)绾螀f(xié)同工作。

Kubernetes Volume 的一個(gè)重要屬性是它與它所屬的 Pod 具有相同的生命周期。如果 Pod 不見了，Volume 就會(huì)丟失。相比之下，PersistentVolume 繼續(xù)存在于系統(tǒng)中，直到用戶將其刪除。卷也可用于在同一個(gè) Pod 內(nèi)的容器之間共享數(shù)據(jù)，但這不是主要用例，因?yàn)橛脩敉ǔＣ總€(gè) Pod 只有一個(gè)容器。

PersistentVolume (PV) 是 Kubernetes 集群中的一塊持久存儲(chǔ)， 而 PersistentVolumeClaim (PVC) 是一個(gè)存儲(chǔ)請(qǐng)求。 StorageClasses 允許根據(jù)需要為工作負(fù)載動(dòng)態(tài)配置新存儲(chǔ)。

Kubernetes 工作負(fù)載如何使用新的和現(xiàn)有的持久存儲(chǔ)

從廣義上講，在 Kubernetes 中使用持久化存儲(chǔ)主要有兩種方式：

• 使用現(xiàn)有的持久卷
• 動(dòng)態(tài)配置新的持久卷

現(xiàn)有存儲(chǔ)配置

要使用現(xiàn)有 PV，您的應(yīng)用程序需要使用綁定到 PV 的 PVC，并且 PV 應(yīng)包含 PVC 所需的最少資源。

換句話說，在 Kubernetes 中設(shè)置現(xiàn)有存儲(chǔ)的典型工作流程如下：

• 在您有權(quán)訪問的物理或虛擬存儲(chǔ)的意義上設(shè)置持久存儲(chǔ)卷。
• 添加引用持久存儲(chǔ)的 PV。
• 添加引用 PV 的 PVC。
• 在您的工作負(fù)載中將 PVC 掛載為卷。

當(dāng) PVC 請(qǐng)求一塊存儲(chǔ)時(shí)，Kubernetes API 服務(wù)器將嘗試將該 PVC 與預(yù)先分配的 PV 匹配，因?yàn)槠ヅ涞木砜捎?。如果可以找到匹配?xiàng)，則 PVC 將綁定到 PV，并且用戶將開始使用該預(yù)先分配的存儲(chǔ)塊。

如果不存在匹配的卷，則 PersistentVolumeClaims 將無限期地保持未綁定狀態(tài)。例如，配置了許多 50 Gi PV 的集群與請(qǐng)求 100 Gi 的 PVC 不匹配。將 100 Gi PV 添加到集群后，可以綁定 PVC。

換句話說，您可以創(chuàng)建無限的 PVC，但只有當(dāng) Kubernetes 主節(jié)點(diǎn)可以找到足夠的 PV 且至少具有 PVC 所需的磁盤空間量時(shí)，它們才會(huì)綁定到 PV。

動(dòng)態(tài)存儲(chǔ)配置

對(duì)于動(dòng)態(tài)存儲(chǔ)配置，您的應(yīng)用程序需要使用綁定到 StorageClass 的 PVC。 StorageClass 包含提供新持久卷的授權(quán)。

在 Kubernetes 中動(dòng)態(tài)配置新存儲(chǔ)的整個(gè)工作流程涉及一個(gè) StorageClass 資源：

1. 添加 StorageClass 并將其配置為從您有權(quán)訪問的存儲(chǔ)中自動(dòng)配置新存儲(chǔ)。
2. 添加引用 StorageClass 的 PVC。
3. 將 PVC 掛載為工作負(fù)載的卷。

Kubernetes 集群管理員可以使用 Kubernetes StorageClass 來描述他們提供的存儲(chǔ)“類(“classes”)”。 StorageClasses 可以有不同的容量限制、不同的 IOPS 或供應(yīng)商支持的任何其他參數(shù)。存儲(chǔ)供應(yīng)商特定的 provisioner 與 StorageClass 一起使用，以按照 StorageClass 對(duì)象中設(shè)置的參數(shù)自動(dòng)分配 PV。此外，provisioner 現(xiàn)在能夠?yàn)橛脩魪?qiáng)制執(zhí)行資源配額和權(quán)限要求。在這種設(shè)計(jì)中，管理員可以從預(yù)測(cè) PV 需求和分配 PV 的不必要工作中解放出來。

當(dāng)使用 StorageClass 時(shí)，Kubernetes 管理員不負(fù)責(zé)分配每一塊存儲(chǔ)。管理員只需要授予用戶訪問某個(gè)存儲(chǔ)池的權(quán)限，并決定用戶的配額即可。然后用戶可以從存儲(chǔ)池中挖掘出所需的存儲(chǔ)部分。

也可以使用 StorageClass，而不需要在 Kubernetes 中顯式創(chuàng)建 StorageClass 對(duì)象。由于 StorageClass 也是一個(gè)用于匹配帶有 PV 的 PVC 的字段，因此可以使用自定義存儲(chǔ)類名稱手動(dòng)創(chuàng)建 PV， 然后可以創(chuàng)建一個(gè)要求帶有該 StorageClass 名稱的 PV 的 PVC。然后，Kubernetes 可以使用指定的 StorageClass 名稱將 PVC 綁定到 PV，即使 StorageClass 對(duì)象并不作為 Kubernetes 資源存在。

Longhorn 引入了一個(gè) Longhorn StorageClass，這樣 Kubernetes 工作負(fù)載就可以根據(jù)需要?jiǎng)澐殖志眯源鎯?chǔ)。

具有持久存儲(chǔ)的 Kubernetes Workloads 的水平擴(kuò)展

VolumeClaimTemplate 是一個(gè) StatefulSet spec 屬性，它為塊存儲(chǔ)解決方案提供了一種方法來水平擴(kuò)展 Kubernetes 工作負(fù)載。

此屬性可用于為由 StatefulSet 創(chuàng)建的 pod 創(chuàng)建匹配的 pv 和 pvc。

這些 PVC 是使用 StorageClass 創(chuàng)建的，因此可以在 StatefulSet 擴(kuò)展時(shí)自動(dòng)設(shè)置它們。

當(dāng) StatefulSet 縮小時(shí)，額外的 PV/PVC 會(huì)保留在集群中，當(dāng) StatefulSet 再次放大時(shí)，它們會(huì)被重用。

VolumeClaimTemplate 對(duì)于 EBS 和 Longhorn 等塊存儲(chǔ)解決方案很重要。因?yàn)檫@些解決方案本質(zhì)上是 ReadWriteOnce，所以它們不能在 Pod 之間共享。

如果您有多個(gè) Pod 運(yùn)行持久性數(shù)據(jù)(persistent storage)，那么部署(Deployment)不能很好地與持久性存儲(chǔ)(persistent storage)配合使用。對(duì)于多個(gè) pod，應(yīng)該使用 StatefulSet。