Longhorn，企業(yè)級云原生容器分布式存儲 - 高可用

作者：為少 2021-08-26 00:23:14

存儲

存儲軟件

云原生

分布式 數(shù)據(jù)局部性設(shè)置(data locality setting)旨在在以下情況下啟用：只要有可能，至少應(yīng)在與使用該卷的 pod 相同的節(jié)點(diǎn)上調(diào)度 Longhorn 卷的一個副本。我們將擁有本地副本的特性稱為具有 data locality。

我們提供的服務(wù)有：成都網(wǎng)站設(shè)計(jì)、網(wǎng)站制作、外貿(mào)營銷網(wǎng)站建設(shè)、微信公眾號開發(fā)、網(wǎng)站優(yōu)化、網(wǎng)站認(rèn)證、嫩江ssl等。為上千余家企事業(yè)單位解決了網(wǎng)站和推廣的問題。提供周到的售前咨詢和貼心的售后服務(wù)，是有科學(xué)管理、有技術(shù)的嫩江網(wǎng)站制作公司

 [[419475]]

目錄

• 數(shù)據(jù)局部性
• 更改默認(rèn)全局設(shè)置
• 使用 Longhorn UI 更改單個卷的數(shù)據(jù)位置
• 使用 StorageClass 為單個卷設(shè)置數(shù)據(jù)局部性
• 數(shù)據(jù)局部性設(shè)置
• 如何為卷設(shè)置數(shù)據(jù)局部性
• 意外分離后恢復(fù)卷
• 使用 Longhorn 處理節(jié)點(diǎn)故障
  • 卷附件恢復(fù)策略
  • 卷附件恢復(fù)策略never (Kubernetes 默認(rèn))
  • 卷附件恢復(fù)策略 wait (Longhorn 默認(rèn))
  • 卷附件恢復(fù)策略 immediate
  • 當(dāng) Kubernetes 節(jié)點(diǎn)出現(xiàn)故障時會發(fā)生什么
  • 節(jié)點(diǎn)宕機(jī)時的 Longhorn Pod 刪除策略
  • 當(dāng)發(fā)生故障的 Kubernetes 節(jié)點(diǎn)恢復(fù)時會發(fā)生什么

數(shù)據(jù)局部性

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

例如，當(dāng)集群的網(wǎng)絡(luò)不好時，數(shù)據(jù)局部性(data locality)會很有用，因?yàn)閾碛斜镜馗北緯黾泳淼目捎眯浴?/p>

數(shù)據(jù)局部性(data locality)對于分布式應(yīng)用程序(例如數(shù)據(jù)庫)也很有用，其中在應(yīng)用程序級別而不是卷級別實(shí)現(xiàn)高可用性。在這種情況下，每個 Pod 只需要一個卷，因此每個卷都應(yīng)該與使用它的 Pod 調(diào)度在同一節(jié)點(diǎn)上。此外，卷調(diào)度的默認(rèn) Longhorn 行為可能會導(dǎo)致分布式應(yīng)用程序出現(xiàn)問題。問題是，如果一個 Pod 有兩個副本，并且每個 Pod 副本都有一個卷，Longhorn 不知道這些卷具有相同的數(shù)據(jù)，不應(yīng)調(diào)度在同一個節(jié)點(diǎn)上。因此 Longhorn 可以在同一節(jié)點(diǎn)上調(diào)度相同的副本，從而阻止它們?yōu)楣ぷ髫?fù)載提供高可用性。

當(dāng)數(shù)據(jù)局部性被禁用時，Longhorn 卷可以由集群中任何節(jié)點(diǎn)上的副本支持，并由運(yùn)行在集群中任何節(jié)點(diǎn)上的 pod 訪問。

數(shù)據(jù)局部性設(shè)置

Longhorn 目前支持兩種 data locality 設(shè)置模式：

• disabled. 這是默認(rèn)選項(xiàng)。在與附加卷(工作負(fù)載)相同的節(jié)點(diǎn)上可能有也可能沒有副本。
• best-effort. 此選項(xiàng)指示 Longhorn 嘗試將副本保留在與附加卷(工作負(fù)載)相同的節(jié)點(diǎn)上。Longhorn 不會停止該卷，即使它由于環(huán)境限制而無法將副本保留在附加卷(工作負(fù)載)的本地，例如：磁盤空間不足、磁盤標(biāo)簽不兼容等。

如何為卷設(shè)置數(shù)據(jù)局部性

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

更改默認(rèn)全局設(shè)置

您可以在 Longhorn UI 設(shè)置中更改 data locality 的全局默認(rèn)設(shè)置。全局設(shè)置僅用作默認(rèn)值，類似于副本計(jì)數(shù)(replica count)。它不會更改任何現(xiàn)有卷的設(shè)置。當(dāng)創(chuàng)建卷時未指定(data locality)，Longhorn 將使用全局默認(rèn)設(shè)置來確定卷的 data locality。

使用 Longhorn UI 更改單個卷的數(shù)據(jù)位置

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

使用 StorageClass 為單個卷設(shè)置數(shù)據(jù)局部性

Longhorn 還將 data locality setting 公開為 StorageClass 中的參數(shù)。您可以使用指定的 data locality setting 創(chuàng)建 StorageClass，然后使用 StorageClass 創(chuàng)建 PVC。例如，下面的 YAML 文件定義了一個 StorageClass，它告訴 Longhorn CSI driver 將 data locality 設(shè)置為 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: "" 
  
 
 

意外分離后恢復(fù)卷

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

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

對于沒有控制器的 Pod，Longhorn 不會刪除它們，因?yàn)槿绻?Longhorn 刪除，則沒有人會重新啟動它們。要恢復(fù)意外分離的卷，您必須手動刪除并重新創(chuàng)建沒有控制器的 pod。

使用 Longhorn 處理節(jié)點(diǎn)故障

當(dāng) Kubernetes 節(jié)點(diǎn)出現(xiàn)故障時會發(fā)生什么

本節(jié)旨在告知用戶節(jié)點(diǎn)故障(node failure)期間會發(fā)生什么以及恢復(fù)期間會發(fā)生什么。

一分鐘后，kubectl get nodes 將報(bào)告失敗節(jié)點(diǎn)的 NotReady。

大約五分鐘后，NotReady 節(jié)點(diǎn)上的所有 Pod 的狀態(tài)將更改為 Unknown 或 NodeLost。

StatefulSets 具有穩(wěn)定的 identity，因此 Kubernetes 不會為用戶強(qiáng)制刪除 pod。請參閱有關(guān)強(qiáng)制刪除 StatefulSet 的官方 Kubernetes 文檔。

Deployments 沒有穩(wěn)定的 identity，但是對于 Read-Write-Once 類型的存儲，由于它不能同時附加到兩個節(jié)點(diǎn)，Kubernetes 創(chuàng)建的新 pod 將無法啟動，因?yàn)?RWO 卷仍連接到舊 pod，位于丟失的節(jié)點(diǎn)上。

在這兩種情況下，Kubernetes 都會自動驅(qū)逐丟失節(jié)點(diǎn)上的 pod(為 pod 設(shè)置刪除時間戳)，然后嘗試用舊卷重新創(chuàng)建一個新的卷。因?yàn)楸或?qū)逐的 pod 會卡在 Terminating 狀態(tài)，并且附加的卷不能被釋放/重用(released/reused)，如果沒有管理(admin)或存儲(storage)軟件的干預(yù)，新的 pod 將卡在 ContainerCreating 狀態(tài)。

節(jié)點(diǎn)宕機(jī)時的 Longhorn Pod 刪除策略

Longhorn 提供了一個選項(xiàng)來幫助用戶在宕機(jī)的節(jié)點(diǎn)上自動強(qiáng)制刪除 StatefulSet/Deployment 的終止 pod。強(qiáng)制刪除后，Kubernetes 將分離 Longhorn 卷并在新節(jié)點(diǎn)上啟動替換 pod。

您可以在 Longhorn UI 或 Settings reference 的 Settings 選項(xiàng)卡中的 Pod Deletion Policy When Node is Down(節(jié)點(diǎn)宕機(jī)時的 Pod 刪除策略)中找到有關(guān)設(shè)置選項(xiàng)的更多詳細(xì)信息。

卷附件恢復(fù)策略

如果您決定強(qiáng)制刪除 pod(手動或在 Longhorn 的幫助下)，Kubernetes 將需要大約 6 分鐘的時間來刪除與 Pod 關(guān)聯(lián)的 VolumeAttachment 對象，然后最終將卷與丟失的節(jié)點(diǎn)分離并允許它由新 pod 使用。

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

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

卷附件恢復(fù)策略never (Kubernetes 默認(rèn))

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

卷附件恢復(fù)策略 wait (Longhorn 默認(rèn))

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

卷附件恢復(fù)策略 immediate

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

當(dāng)發(fā)生故障的 Kubernetes 節(jié)點(diǎn)恢復(fù)時會發(fā)生什么

如果節(jié)點(diǎn)在故障后 5 到 6 分鐘內(nèi)重新聯(lián)機(jī)，Kubernetes 將重新啟動 Pod、卸載(unmount)和重新安裝(re-mount)卷，而無需重新附加卷(re-attaching)和 VolumeAttachment 清理。

因?yàn)榫硪?volume engines)會在節(jié)點(diǎn)宕機(jī)后關(guān)閉，所以這種直接重新安裝將不起作用，因?yàn)樵撛O(shè)備不再存在于節(jié)點(diǎn)上。

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

如果節(jié)點(diǎn)在故障后 5-6 分鐘內(nèi)沒有重新上線，Kubernetes 將嘗試基于 pod eviction 機(jī)制刪除所有無法訪問的 pod，這些 pod 將處于 Terminating 狀態(tài)。有關(guān)詳細(xì)信息，請參閱 pod eviction timeout。

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

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

對于上述所有恢復(fù)場景，Longhorn 將通過 Kubernetes 的關(guān)聯(lián)(association)自動處理這些步驟。

網(wǎng)站標(biāo)題：Longhorn，企業(yè)級云原生容器分布式存儲-高可用
文章路徑：http://fisionsoft.com.cn/article/dhccdjj.html