共计 5785 个字符，预计需要花费 15 分钟才能阅读完成。
作者简介
吴硕，SUSE Senior Software Development Engineer，已为 Longhorn 我的项目工作近四年，是我的项目 maintainer 之一。
本文将介绍 Longhorn 的基本功能和架构，replica 和 backup 这两个最重要的个性以及应用案例，帮忙大家理解 Longhorn 的价值所在以及应用办法。
Longhorn 介绍
Longhorn 是一个轻量的、牢靠易用的、为 Kubernetes 设计的分布式存储系统，100% 开源，现已成为 CNCF 孵化我的项目。
Longhorn 作为存储系统，最重要、最根本的性能就是为 Kubernetes 的工作负载提供长久存储，咱们称为 Longhorn volume。它利用集群工作节点自身的存储设备实现存储，这种超聚合的形式是 Longhorn 的设计理念之一，也能够很好地和 SUSE 另外一个我的项目——Harvester 集成。
为了保障高可用性，Longhorn 首先反对跨节点或跨可用区（AZ）的数据复制，即 Replication。如果整个集群或者恰好 volume 的所有 replica 都忽然不可用，就须要将数据进一步备份 (backup) 到集群内部了。
Longhorn 反对将数据上传到 NFS 或者 S3 compatible 的存储计划。利用内部的备份数据，Longhorn 能够做集群级别的容灾复原。对于数据备份自身，用户不可能每次手动发动申请，所以 Longhorn 反对周期性的 backup 和 snapshot，这个性能个别称为 cron job 或者 recurring job。
对于 Longhorn 降级，咱们的要求是不可能影响用户或者曾经运行的 volume 读写，所以每次 Longhorn 版本升级都是无中断降级。
往年 Longhorn 面向 VM 推出了新性能 backing image。如果用户想要起数十个或者上百个 VM，为每个 VM 独自下载一份截然不同的 SLES 或 Ubuntu 等 image，是十分浪费时间和空间的。在这一场景下，客户只需下载一份 image 作为只读的底层文件，并让所有 VM 共用即可。
此外，Longhorn 还有更多扩大性能，在此就不一一赘述了。
Longhorn 提供了一套 GUI 界面，如下图。用户能够通过 GUI 查看整体存储情况，治理可用的节点及相应的磁盘空间。
最重要的还是 volume 相干界面。关上 Longhorn 具体界面能够看到 volume 状态、利用信息以及 snapshot 相干信息。
此外，还有 backup、recurring job、setting 等界面，绝大部分 Longhorn 自身相干配置都能够在 GUI 中实现。
对于更多 Longhorn 的性能和特点，大家能够自行依据官方网站的文档进行部署体验。如之前所说，Longhorn 的部署和应用非常简单间接。
Longhorn 的架构
整体架构和工作流程
当用户在 Kubernetes 创立一个新的利用（Pod）并须要持久性存储时，Kubernetes 就会通过 CSI(Container Storage Interface) API 向实现了这套接口的 Longhorn CSI Plugin 发送申请；而这个 Longhorn CSI Plugin 则利用 Longhorn API，去和两头的 Longhorn Manager 交互并实现申请。
Longhorn Manager 是负责将零碎形象成 Kubernetes 资源 (Custom Resource Definition) 并进行协调治理的组件。比方 volume 的创立和挂载（Attachment），就是 Longhron Manager 协调好相应的 Kuberntes 资源 (Custom Resource) 后，启动相应的过程来实现的。
一个 Longhorn Volume 是由一个 engine 与多个 replica 组成的。每一个 replica 都是 volume 数据的残缺复制体。Engine 负责连贯和管制这些 replica，并向 workload 提供 block device。
此外，Longhorn UI 也是通过 Longhorn API 实现所有的操作和性能。
Longhorn Volume 如何工作
假如有三个工作节点，每个节点都有相应的硬件，比方 CPU、Memory 和 SSD 磁盘。如前文提到，Replica 会间接利用同节点上的 SSD 来存储数据，而 engine 则负责连贯和管制 replica，并解决一些操作，volume 是对 engine 和所有 replica 的总结形象。
一个 volume 通常有多个 replica 散布在不同节点上，所以当一个节点宕掉时，其余节点上仍有完整可用的 replica。利用残余的完整 replica，咱们能够疾速重启 volume 并复原服务。如下图，节点 1 宕机后，节点 2 上的 repica 依然可用，因而咱们能够疾速在节点 3 上重启 engine 并复原 Pod A。因为节点 2 自身没有宕掉，其中的 Pod B 和 Pod C，及其相应 Volume 的性能不会受到影响，受影响的只有 Volume 的高可用水平。
此外，Volume/Engine 的架构图还反馈了两个事实。
其一，对于每一个节点来说，所有的 replica 都是由一个 Replica Instance Manager 治理的，engine 同理。这样能够保障一个节点上能够运行多个 engine 或 replica。而 Instance Manager 之中的 engine/replica 互不烦扰，独立运行。
其二，每一个 volume 的 engine，和其 workload/pod 始终运行在同一个节点上。Instance Manager 性能比较稳定简略，个别不会导致 engine 解体掉。所以个别 volume 或 engine 解体掉的的次要起因是所有 replica 同时解体，或以后节点忽然不可用。换句话说，engine 和 workload 的生命周期通常是雷同的，这样 Longhorn 防止了在多个节点启动多个 engine 来保障一个 volume 的高可用性。
对于更具体的细节，有趣味的读者能够拜访 Longhorn 文档。
应用案例 1
Longhorn 有何非用不可的理由？毕竟应用 Longhorn 意味着在存储栈上额定加了一层，性能不可避免地会受到影响。Longhorn 是保障 crash consistency 这种强一致性的，这种强一致性会导致额定的 latency 和写性能上的损失（不过读性能反而会有所增加）。
当用户应用私有云比方 AWS 时，他为什么不间接应用 EBS Volume，转而应用 Longhorn 呢？因为 EBS 有一个很重要的问题——它无奈跨可用区 (AZ) 做迁徙。
如下图，一个 EKS 在三个 zone 下面部署了工作节点，在 zone 1a 上的节点部署了一个 Pod 并应用了一个 EBS。当这个节点不可用导致 Pod 停掉时，想复原这个 Pod，用户就必须在其余两个 zone 节点上重新部署 Pod，并从新挂载之前的 EBS Volume。这个时候的问题是，EBS Volume 无奈跨区迁徙，所以间接应用 EBS Volume，是无奈解决这种状况的。
第二个痛点则是 AWS 的单个 instance 上能够挂载的 EBS Volume 是无限的，可能就十几个。在当初容器化的利用场景里，一个节点可能运行几十或者上百个容器 /pod，其中每个容器 /pod 可能须要几个持久性的存储（或者单个存储不须要太大），在这种状况下 EBS Volume 是远远不够用的。
其三，EBS Volume 的 attachment/detachment 绝对比较慢，大略是分钟级，不能完满实用 Pod 常常迁徙变动的情景。
如果应用 Longhorn，上述问题就不再是问题。首先，Longhorn volume 的 replica 是能够跨 AZ 来保障高可用性的。当 Zone 1a 节点挂掉时，Longhorn 能够马上在 zone 1b 上重启 engine 并间接连贯残余的 replica，这样 Pod 能够即刻复原服务。
另一方面，Longhorn 也通过了 scalability 测试——在 10 个节点的 cluster 挂载并应用 2000 个 Volume，即每个节点运行 200 个 Volume 是没有问题的。
最初 Longhorn Volume 的 attachment/detachment 相比 EBS Volume 十分快，通常 3～10 秒就够了。
应用案例 2
有时候单集群内的高可用是不太够用的。如上文提到，当集群宕机或者节点大规模掉线恰好导致 volume 的所有 replica 都不可用时，Longhorn 也须要确保尽快恢复服务。这时候咱们就须要 backup。Backup 是指将 Volume 数据备份到内部的存储空间，比方 NFS 或者 S3 相兼容的存储计划。
如下图，以后 Primary Cluster (主集群，正在提供服务的集群)内有服务正在应用 Longhorn volume，用户就能够把 Volume 数据备份到 Backup Target 这个内部存储中。而一旦有了 Backup Volume，用户能够设置一个 Disaster Recovery Cluster(DR Cluser，劫难复原集群, 当 Primary Cluster 挂掉时能够疾速切换到此集群以疾速复原服务)，连贯到同一个 Backup Target，并及时地将 Backup 复原到集群内的 DR volume 中备用。此时，Primary Cluster 内的 Volume 在被继续应用，会有新的数据写入。Longhorn 就会仅将新写入的数据持续备份到之前的 Backup Volume，这称之为 incremental backup (增量备份)。
一旦有新的数据被备份，DR Cluster 会检测到变动，将新的数据持续复原到之前的 DR Volume。这样即便存在提早，但 DR volume 的数据根本是相应的 Volume 保持一致的。稍后，如果 Primary Cluster 忽然宕机，用户就能够立刻启用 DR cluster 并激活 DR Volume，以达到疾速复原服务的目标。
RPO 和 RTO：掂量整个劫难复原速度 / 能力的指标
RPO（Recovery Point Objective）即复原点指标，指从上次备份到劫难产生中距离了多长时间，这个指标反映了（能容忍的）数据的失落量。该指标理论由 backup 距离决定，Backup 创立的距离有多久，RPO 就有多久。
RTO（Recovery Time Objective）即复原工夫指标，指从劫难产生到服务复原须要多少工夫。DR cluster 与 DR volume 的存在，就是为了尽可能地缩小这个工夫。如果没有 DR cluster 或者 DR Volume，劫难产生时，咱们想尽快恢复服务，就要把所有的 Backup Volume 一口气复原到新的 ctuster 中。对于企业来说大略是 PB 级的数据，短时间复原这么大的数据所须要的工夫十分长，可能几个小时，或者几天的工夫，这对于企业来说是不太能承受的。
然而假如有一个 DR cluster，因为它会周期性地主动拉取最新备份的数据到 DR Volume 里，只有检测拉取的距离正当，大部分状况下 DR Volume 里都是含有最新的数据的，或者跟相应的 Volume 只差了一个备份周期以内的数据，复原这部分数据可能仅需几分钟或者几十分钟。相比几个小时或者几天，复原工夫缩短了一个数量级，这就是为什么说 DR Cluster 和 DR Volume 能缩短 RTO。简而言之，通过配置 backup 和 restore 的距离，用户就能管制 RTO 和 RPO。
backup 是如何创立或者删除的，以及 backup 自身的构造
如下图，右边是 Volume 的构造。这里说一下，snapshot 实质是保留了某个时间段的历史数据，volume head 里则是最新写入的数据。所以读取 volume 中某段数据，就是从最新的 volume head 开始，查找这部分空间最近写入的数据（在 volume head 或者某个 snapshot 中）。
简而言之，咱们读取数据，包含备份时的数据读取，都是从右往左读。这时要为 snapshot2 创立 backup，首先要确定 snapshot2 这个点上 volume 的数据是什么样子的。以 snapshot2 为最左边或者最近的文件，从右往左看，能看到的数据是第一个 data block 在 snapshot1，前面两个 data block 是在 snapshot2。这样咱们找到了 backup 对应的 snapshot，理解了蕴含这些 snapshot 中的哪些 data block，剩下的就是把数据上传到 backup target 即可。
稍后，新的数据被写入了，咱们想要创立新的 backup，就先须要把以后的 volume head 变成 snapshot3 并基于 snapshot3 做 backup。这时候就从新从右往左看，也就是从 snapshot3，整个 Volume 就蕴含 5 个 data block。跟之前的 backup 相比，所差的数据就是 snapshot3 的数据。强调这个 delta 局部的起因是，之前 backup 过的数据是不须要从新上传的，也就是只须要备份新的数据，即 snapshot3 中的数据就能够。
backup deletion 也相似。比方咱们要删掉 snapshot 对应的 backup，就须要和前一个 backup 做比照。咱们发现，有几个 data block 是被前一个 backup 正在应用的，所以只能删掉那些孤立的、仅被以后 backup 所指的 data block，这样其余的 backup 不会被影响，这就是 deletion 的机制。当然这些 backup 相干操作都有一个文件锁来爱护，所以不须要放心 race condition 的问题。
最初，restore 也是相似的原理。如果是间接依据 snapshot2 的 backup 创立 DR volume，咱们发现三个 data block 后，间接把它们复原到对应的 DR Volume 里就能够。而如果是拉取最新的(incremental) backup 数据，则是比照上一个 restore 过的 backup，把新增的 data block 拉取下来即可。
backup 在服务器里是什么样子？咱们怎么管理文件呢？如下图，因为这个 backup volume 可能有很多的 backup，每个 backup 就有一个对应的元数据文件 snap.cfg，次要记录这些 backup 由哪些 data block 组成。剩下的就是 data block，可能是被一个或者多个 backup 援用。这就是对于 backup 和 restore 的全副根本介绍。