您的位置：首页 > 运维架构 > 网站架构

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

2021-08-25 22:31 1051 查看

内容来源于官方 

Longhorn 1.1.2
英文技术手册。

系列

目录

  • 数据局部性 数据局部性设置
  • 如何为卷设置数据局部性 更改默认全局设置
  • 使用 
    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
    )自动处理这些步骤。

    公众号：黑客下午茶
    内容来自用户分享和网络整理，不保证内容的准确性，如有侵权内容，可联系管理员处理 点击这里给我发消息
    标签： 
    相关文章推荐
    新的分享
    章节导航