数据局部性
数据局部性设置(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)自动处理这些步骤。
