专栏首页黑客下午茶Longhorn,企业级云原生容器分布式存储 - 高可用

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

内容来源于官方 Longhorn 1.1.2 英文技术手册

系列

目录

  • 数据局部性
    • 更改默认全局设置
    • 使用 Longhorn UI 更改单个卷的数据位置
    • 使用 StorageClass 为单个卷设置数据局部性
    • 数据局部性设置
    • 如何为卷设置数据局部性
  • 意外分离后恢复卷
  • 使用 Longhorn 处理节点故障
    • 卷附件恢复策略
    • 卷附件恢复策略never Kubernetes 默认)
    • 卷附件恢复策略 wait Longhorn 默认)
    • 卷附件恢复策略 immediate
    • Kubernetes 节点出现故障时会发生什么
    • 节点宕机时的 Longhorn Pod 删除策略
    • 当发生故障的 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 driverdata 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 由控制器管理(例如:deploymentstatefulsetdaemonset 等),Longhorn 会自动删除工作负载 pod。通过删除 pod,它的控制器会重新启动 podKubernetes 处理卷重新附加(reattachment)和重新挂载(remount)。

如果您不希望 Longhorn 自动删除 workload pod,您可以在 Longhorn UI 的设置 Automatically Delete Workload Pod when The Volume Is Detached Unexpectedly(卷意外分离时自动删除工作负载 Pod) 中进行设置。

对于没有控制器的 PodLonghorn 不会删除它们,因为如果 Longhorn 删除,则没有人会重新启动它们。要恢复意外分离的卷,您必须手动删除并重新创建没有控制器的 pod

使用 Longhorn 处理节点故障

当 Kubernetes 节点出现故障时会发生什么

本节旨在告知用户节点故障(node failure)期间会发生什么以及恢复期间会发生什么。

一分钟后,kubectl get nodes 将报告失败节点的 NotReady

大约五分钟后,NotReady 节点上的所有 Pod 的状态将更改为 UnknownNodeLost

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 节点恢复时会发生什么

如果节点在故障后 56 分钟内重新联机,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)自动处理这些步骤。

本文分享自微信公众号 - 黑客下午茶(hi-weishao),作者:为少

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2021-08-25

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • Longhorn,企业级云原生容器分布式存储 - 监控(Prometheus+AlertManager+Grafana)

    Longhorn 在 REST 端点 http://LONGHORN_MANAGER_IP:PORT/metrics 上以 Prometheus 文本格式原生公...

    为少
  • Longhorn 企业级云原生分布式容器存储-券(Volume)和节点(Node)

    在本教程中,您将学习如何创建与 Longhorn 卷对应的持久卷 (PV) 和持久卷声明 (PVC) 的 Kubernetes 持久存储资源。您将使用 kube...

    为少
  • Longhorn,企业级云原生容器分布式存储 - K8S 资源配置示例

    请注意,只有 ext4 文件系统支持在卷意外分离后(detached unexpectedly)自动重新挂载。

    为少
  • Longhorn,企业级云原生容器分布式存储 - 支持 ReadWriteMany (RWX) 工作负载(实验性功能)

    Longhorn 通过 NFSv4 服务器(share-manager)公开常规 Longhorn 卷,原生支持 RWX 工作负载。

    为少
  • Longhorn 云原生容器分布式存储 - Python Client

    目前,您可以使用 Longhorn UI 操作 Longhorn。同时,您可以使用 Python 访问 Longhorn API,如下所示。

    为少
  • Longhorn,企业级云原生容器分布式存储 - 定制部署默认设置

    您可以在部署 Longhorn 时自定义它的默认设置。例如,您可以在启动 Longhorn 之前指定 Create Default Disk With Node...

    为少
  • K8s原生存储持续进化,Longhorn 1.1迎来ARM支持

    当DevOps团队同时使用Rancher和Longhorn 1.1时,他们可以轻松管理位于任意位置的持久化数据卷,无论这些持久化数据卷位于云端、数据中心抑或边缘...

    CNCF
  • Longhorn云原生容器分布式存储-Air Gap安装

    Longhorn 可以通过使用 manifest file、Helm chart 或 Rancher UI 安装在 air gapped 环境中。

    为少
  • Longhorn 企业级云原生容器存储解决方案-部署篇

    安装 Longhorn 的 Kubernetes 集群中的每个节点都必须满足以下要求:

    为少
  • Longhorn,Kubernetes 云原生分布式块存储

    Longhorn 是用于 Kubernetes 的轻量级、可靠且功能强大的分布式块存储系统。

    为少
  • 使用Longhorn优雅地恢复正在运行中的容器应用

    鞠宏超,Rancher研发工程师。4年云计算领域经验,2018年加入Rancher Labs,先后参与了Longhorn产品研发,Rancher2.x产品研发,...

    CNCF
  • Longhorn项目

    说明:Longhorn是Kubernetes的分布式块存储系统。Longhorn轻便、可靠、强大。你可以使用kubectl apply命令或使用Helm cha...

    CNCF
  • Rancher大中华区技术总监带你6分钟了解Rancher 1.5

    摘要 Rancher容器管理平台1.5版已正式与大家见面了,此次分享将由Rancher Labs大中华区技术总监介绍Rancher的版本演进历史以及Ranche...

    IT大咖说
  • Longhorn 云原生分布式块存储解决方案设计架构和概念

    Longhorn 设计有两层:数据平面(data plane)和控制平面(control plane)。Longhorn Engine 是存储控制器对应数据平面...

    为少
  • Windows Vista已死,有事烧纸

    源 \ 36氪 编者按:从后来的很多反馈看来,Vista 都是一个超前于时代的操作系统。但这个操作系统在当年却遭遇了前所未有的失利——究竟为什么 Vista 会...

    顶级程序员
  • 云原生时代需要什么样的存储系统

    本文介绍了目前云原生环境下,支持有状态应用的几种典型存储方案的特点,并对市场主流的云原生存储产品实际测试性能进行对比。

    灵雀云
  • KubeSphere 社区大量全职开源职位诚邀您的加入!

    KubeSphere 团队是开源项目 KubeSphere(https://kubesphere.io)的核心维护成员。在 KubeSphere 团队,一切都是...

    LinuxSuRen
  • 声明性数据基础设施为数据驱动企业提供动力

    大数据、人工智能/ML和现代分析技术已经渗透到商业世界,成为企业战略的关键元素,以更好地服务客户、更快地创新和保持领先的竞争。数据是所有这些的核心。在本博客中,...

    CNCF
  • Longhorn 微服务化存储初探

    Longhorn 官方推荐的最小配置如下,如果数据并不算太重要可适当缩减和调整,具体请自行斟酌:

    CNCF

扫码关注云+社区

领取腾讯云代金券