Longhorn，企业级云原生容器分布式存储 – 高可用

内容来源于官方

Longhorn 1.1.2

英文技术手册。

系列

• Longhorn 是什么?
• Longhorn 企业级云原生容器分布式存储解决方案设计架构和概念
• Longhorn 企业级云原生容器分布式存储-部署篇
• Longhorn 企业级云原生容器分布式存储-券(Volume)和节点(Node)
• Longhorn，企业级云原生容器分布式存储-K8S 资源配置示例
• Longhorn，企业级云原生容器分布式存储 – 监控(Prometheus+AlertManager+Grafana)
• Longhorn，企业级云原生容器分布式存储 – 备份与恢复

目录

• 数据局部性数据局部性设置
• 如何为卷设置数据局部性更改默认全局设置
• 使用

  Longhorn UI

  更改单个卷的数据位置

• 使用

  StorageClass

  为单个卷设置数据局部性

Longhorn

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: StorageClassapiVersion: storage.k8s.io/v1metadata:name: hyper-convergedprovisioner: driver.longhorn.ioallowVolumeExpansion: trueparameters:numberOfReplicas: "2"dataLocality: "best-effort"staleReplicaTimeout: "2880" # 48 hours in minutesfromBackup: ""

意外分离后恢复卷

当发生意外分离(

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

)自动处理这些步骤。

公众号：黑客下午茶