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

本文涉及的产品
容器镜像服务 ACR,镜像仓库100个 不限时长
简介: Longhorn,企业级云原生容器分布式存储 - 高可用

数据局部性



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

相关实践学习
通过Ingress进行灰度发布
本场景您将运行一个简单的应用,部署一个新的应用用于新的发布,并通过Ingress能力实现灰度发布。
容器应用与集群管理
欢迎来到《容器应用与集群管理》课程,本课程是“云原生容器Clouder认证“系列中的第二阶段。课程将向您介绍与容器集群相关的概念和技术,这些概念和技术可以帮助您了解阿里云容器服务ACK/ACK Serverless的使用。同时,本课程也会向您介绍可以采取的工具、方法和可操作步骤,以帮助您了解如何基于容器服务ACK Serverless构建和管理企业级应用。 学习完本课程后,您将能够: 掌握容器集群、容器编排的基本概念 掌握Kubernetes的基础概念及核心思想 掌握阿里云容器服务ACK/ACK Serverless概念及使用方法 基于容器服务ACK Serverless搭建和管理企业级网站应用
相关文章
|
6月前
|
NoSQL Redis
基于Redis的高可用分布式锁——RedLock
这篇文章介绍了基于Redis的高可用分布式锁RedLock的概念、工作流程、获取和释放锁的方法,以及RedLock相比单机锁在高可用性上的优势,同时指出了其在某些特殊场景下的不足,并提到了ZooKeeper作为另一种实现分布式锁的方案。
164 2
基于Redis的高可用分布式锁——RedLock
|
2月前
|
运维 Kubernetes 调度
阿里云容器服务 ACK One 分布式云容器企业落地实践
阿里云容器服务ACK提供强大的产品能力,支持弹性、调度、可观测、成本治理和安全合规。针对拥有IDC或三方资源的企业,ACK One分布式云容器平台能够有效解决资源管理、多云多集群管理及边缘计算等挑战,实现云上云下统一管理,提升业务效率与稳定性。
|
5月前
|
运维 Kubernetes 调度
阿里云容器服务 ACK One 分布式云容器企业落地实践
3年前的云栖大会,我们发布分布式云容器平台ACK One,随着3年的发展,很高兴看到ACK One在混合云,分布式云领域帮助到越来越多的客户,今天给大家汇报下ACK One 3年来的发展演进,以及如何帮助客户解决分布式领域多云多集群管理的挑战。
阿里云容器服务 ACK One 分布式云容器企业落地实践
|
4月前
|
消息中间件 中间件 数据库
NServiceBus:打造企业级服务总线的利器——深度解析这一面向消息中间件如何革新分布式应用开发与提升系统可靠性
【10月更文挑战第9天】NServiceBus 是一个面向消息的中间件,专为构建分布式应用程序设计,特别适用于企业级服务总线(ESB)。它通过消息队列实现服务间的解耦,提高系统的可扩展性和容错性。在 .NET 生态中,NServiceBus 提供了强大的功能,支持多种传输方式如 RabbitMQ 和 Azure Service Bus。通过异步消息传递模式,各组件可以独立运作,即使某部分出现故障也不会影响整体系统。 示例代码展示了如何使用 NServiceBus 发送和接收消息,简化了系统的设计和维护。
88 3
|
5月前
|
人工智能 Kubernetes Cloud Native
深度对话 解锁阿里云分布式云原生技术落地新姿势
深度对话 解锁阿里云分布式云原生技术落地新姿势
深度对话 解锁阿里云分布式云原生技术落地新姿势
|
5月前
|
存储
cephFS高可用分布式文件系统部署指南
关于如何部署高可用的cephFS分布式文件系统,包括集群的搭建、验证高可用性以及实现两主一从架构的详细指南。
213 9
|
6月前
|
运维 安全 Cloud Native
核心系统转型问题之保障云原生分布式转型中的基础设施和应用层面如何解决
核心系统转型问题之保障云原生分布式转型中的基础设施和应用层面如何解决
|
6月前
|
监控 Cloud Native 容灾
核心系统转型问题之API网关在云原生分布式核心系统中的功能如何解决
核心系统转型问题之API网关在云原生分布式核心系统中的功能如何解决
|
6月前
|
运维 Cloud Native 安全
核心系统转型问题之确保核心系统云原生分布式转型的安全可靠性如何解决
核心系统转型问题之确保核心系统云原生分布式转型的安全可靠性如何解决
|
6月前
|
Cloud Native 关系型数据库 分布式数据库
什么是云原生数据库PolarDB分布式版
本文介绍什么是云原生数据库PolarDB分布式版,也称为PolarDB分布式版,本手册中简称为PolarDB-X。
131 0