Longhorn，企業級雲原生容器分布式存儲 - 高可用

內容來源於官方 Longhorn 1.1.2 英文技術手冊。

系列

• Longhorn 是什么?
• Longhorn 企業級雲原生容器分布式存儲解決方案設計架構和概念
• Longhorn 企業級雲原生容器分布式存儲-部署篇
• Longhorn 企業級雲原生容器分布式存儲-券(Volume)和節點(Node)
• Longhorn，企業級雲原生容器分布式存儲-K8S 資源配置示例
• Longhorn，企業級雲原生容器分布式存儲 - 監控(Prometheus+AlertManager+Grafana)
• Longhorn，企業級雲原生容器分布式存儲 - 備份與恢復

目錄

• 數據局部性
  • 數據局部性設置
  • 如何為卷設置數據局部性
    • 更改默認全局設置
    • 使用 Longhorn UI 更改單個卷的數據位置
    • 使用 StorageClass 為單個卷設置數據局部性
• 意外分離后恢復卷
• 使用 Longhorn 處理節點故障
  • 當 Kubernetes 節點出現故障時會發生什么
  • 節點宕機時的 Longhorn Pod 刪除策略
    • 卷附件恢復策略
      • 卷附件恢復策略never （Kubernetes 默認）
      • 卷附件恢復策略 wait （Longhorn 默認）
      • 卷附件恢復策略 immediate
  • 當發生故障的 Kubernetes 節點恢復時會發生什么

數據局部性

數據局部性設置(data locality setting)旨在在以下情況下啟用：只要有可能，至少應在與使用該卷的 pod 相同的節點上調度 Longhorn 卷的一個副本。我們將擁有本地副本的特性稱為具有 data locality。

例如，當集群的網絡不好時，數據局部性(data locality)會很有用，因為擁有本地副本會增加卷的可用性。

數據局部性(data locality)對於分布式應用程序（例如數據庫）也很有用，其中在應用程序級別而不是卷級別實現高可用性。在這種情況下，每個 Pod 只需要一個卷，因此每個卷都應該與使用它的 Pod 調度在同一節點上。此外，卷調度的默認 Longhorn 行為可能會導致分布式應用程序出現問題。問題是，如果一個 Pod 有兩個副本，並且每個 Pod 副本都有一個卷，Longhorn 不知道這些卷具有相同的數據，不應調度在同一個節點上。因此 Longhorn 可以在同一節點上調度相同的副本，從而阻止它們為工作負載提供高可用性。

當數據局部性被禁用時，Longhorn 卷可以由集群中任何節點上的副本支持，並由運行在集群中任何節點上的 pod 訪問。

數據局部性設置

Longhorn 目前支持兩種 data locality 設置模式：

• disabled. 這是默認選項。在與附加卷（工作負載）相同的節點上可能有也可能沒有副本。

• best-effort. 此選項指示 Longhorn 嘗試將副本保留在與附加卷（工作負載）相同的節點上。Longhorn 不會停止該卷，即使它由於環境限制而無法將副本保留在附加卷（工作負載）的本地，例如：磁盤空間不足、磁盤標簽不兼容等。

如何為卷設置數據局部性

可以通過三種方式為 Longhorn 卷設置 data locality：

更改默認全局設置

您可以在 Longhorn UI 設置中更改 data locality 的全局默認設置。
全局設置僅用作默認值，類似於副本計數(replica count)。
它不會更改任何現有卷的設置。
當創建卷時未指定(data locality)，Longhorn 將使用全局默認設置來確定卷的 data locality。

使用 Longhorn UI 更改單個卷的數據位置

您可以使用 Longhorn UI 在創建卷時設置 data locality。
您還可以在 volume detail 頁面中更改卷創建后的 data locality setting。

使用 StorageClass 為單個卷設置數據局部性

Longhorn 還將 data locality setting 公開為 StorageClass 中的參數。
您可以使用指定的 data locality setting 創建 StorageClass，然后使用 StorageClass 創建 PVC。
例如，下面的 YAML 文件定義了一個 StorageClass，它告訴 Longhorn CSI driver 將 data locality 設置為 best-effort：

kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: hyper-converged
provisioner: driver.longhorn.io
allowVolumeExpansion: true
parameters:
  numberOfReplicas: "2"
  dataLocality: "best-effort"
  staleReplicaTimeout: "2880" # 48 hours in minutes
  fromBackup: ""

意外分離后恢復卷

當發生意外分離(unexpected detachment)時，可能發生在 Kubernetes upgrade、Docker reboot或網絡斷開連接期間，如果 pod 由控制器管理（例如：deployment、statefulset、daemonset 等），Longhorn 會自動刪除工作負載 pod。通過刪除 pod，它的控制器會重新啟動 pod，Kubernetes 處理卷重新附加(reattachment)和重新掛載(remount)。

如果您不希望 Longhorn 自動刪除 workload pod，您可以在 Longhorn UI 的設置 Automatically Delete Workload Pod when The Volume Is Detached Unexpectedly(卷意外分離時自動刪除工作負載 Pod) 中進行設置。

對於沒有控制器的 Pod，Longhorn 不會刪除它們，因為如果 Longhorn 刪除，則沒有人會重新啟動它們。
要恢復意外分離的卷，您必須手動刪除並重新創建沒有控制器的 pod。

使用 Longhorn 處理節點故障

當 Kubernetes 節點出現故障時會發生什么

本節旨在告知用戶節點故障(node failure)期間會發生什么以及恢復期間會發生什么。

一分鍾后，kubectl get nodes 將報告失敗節點的 NotReady。

大約五分鍾后，NotReady 節點上的所有 Pod 的狀態將更改為 Unknown 或 NodeLost。

StatefulSets 具有穩定的 identity，因此 Kubernetes 不會為用戶強制刪除 pod。
請參閱有關強制刪除 StatefulSet 的官方 Kubernetes 文檔。

Deployments 沒有穩定的 identity，但是對於 Read-Write-Once 類型的存儲，由於它不能同時附加到兩個節點，Kubernetes 創建的新 pod 將無法啟動，因為 RWO 卷仍連接到舊 pod，位於丟失的節點上。

在這兩種情況下，Kubernetes 都會自動驅逐丟失節點上的 pod（為 pod 設置刪除時間戳），然后嘗試用舊卷重新創建一個新的卷。
因為被驅逐的 pod 會卡在 Terminating 狀態，並且附加的卷不能被釋放/重用(released/reused)，如果沒有管理(admin)或存儲(storage)軟件的干預，新的 pod 將卡在 ContainerCreating 狀態。

節點宕機時的 Longhorn Pod 刪除策略

Longhorn 提供了一個選項來幫助用戶在宕機的節點上自動強制刪除 StatefulSet/Deployment 的終止 pod。
強制刪除后，Kubernetes 將分離 Longhorn 卷並在新節點上啟動替換 pod。

您可以在 Longhorn UI 或 Settings reference 的 Settings 選項卡中的 Pod Deletion Policy When Node is Down(節點宕機時的 Pod 刪除策略)中找到有關設置選項的更多詳細信息。

卷附件恢復策略

如果您決定強制刪除 pod（手動或在 Longhorn 的幫助下），Kubernetes 將需要大約 6 分鍾的時間來刪除與 Pod 關聯的 VolumeAttachment 對象，然后最終將卷與丟失的節點分離並允許它由新 pod 使用。

這 6 分鍾的時間段在 Kubernetes 中是硬編碼的：如果丟失節點上的 pod 被強制刪除，則相關卷將無法正確卸載。然后 Kubernetes 會等待這個固定的超時時間直接清理 VolumeAttachment 對象。

為了解決這個問題，我們提供了 3 種不同的卷附件恢復策略。

卷附件恢復策略never （Kubernetes 默認）

Longhorn 不會從故障節點恢復 Volume Attachment，這與 Kubernetes 的默認行為一致。
用戶需要強制刪除終止的 pod，此時 Longhorn 將從故障節點恢復 Volume Attachment。
然后允許掛起的替換 pod(replacement pod)在請求的卷可用的情況下正確啟動。

卷附件恢復策略 wait （Longhorn 默認）

Longhorn 將等待恢復 Volume Attachment，直到所有終止 pod(terminating pod)刪除寬限期過去。
由於此時需要節點 kubelet 刪除 Pod，並且 Pod 仍然可用，我們可以得出結論，故障節點 Kubelet 無法刪除 Pod。
此時 Longhorn 將從故障節點恢復 Volume Attachment。
然后允許掛起的替換 pod(replacement pod) 在請求的卷可用的情況下正確啟動。

卷附件恢復策略 immediate

只要有待處理的替換 Pod(replacement pod) 可用，Longhorn 就會從故障節點恢復 Volume Attachment。
然后允許掛起的替換 pod(replacement pod)在請求的卷可用的情況下正確啟動。

當發生故障的 Kubernetes 節點恢復時會發生什么

如果節點在故障后 5 到 6 分鍾內重新聯機，Kubernetes 將重新啟動 Pod、卸載(unmount)和重新安裝(re-mount)卷，而無需重新附加卷(re-attaching)和 VolumeAttachment 清理。

因為卷引擎(volume engines)會在節點宕機后關閉，所以這種直接重新安裝將不起作用，因為該設備不再存在於節點上。

在這種情況下，Longhorn 將分離並重新附加卷以恢復卷引擎，以便 pod 可以安全地重新掛載/重用卷(remount/reuse)。

如果節點在故障后 5-6 分鍾內沒有重新上線，Kubernetes 將嘗試基於 pod eviction 機制刪除所有無法訪問的 pod，這些 pod 將處於 Terminating 狀態。有關詳細信息，請參閱 pod eviction timeout。

然后，如果故障節點稍后恢復，Kubernetes 將重新啟動那些終止的 pod，分離卷(detach the volumes)，等待舊的 VolumeAttachment 清理，並重用重新附加和重新掛載(re-attach & re-mount)卷。通常這些步驟可能需要 1 ~ 7 分鍾。

在這種情況下，分離(detaching)和重新附加(re-attaching)操作已經包含在 Kubernetes 恢復過程中。因此不需要額外的操作，Longhorn 卷將在上述步驟后可用。

對於上述所有恢復場景，Longhorn 將通過 Kubernetes 的關聯(association)自動處理這些步驟。

公眾號：黑客下午茶