|
本文档采用自动化机器翻译技术翻译。 尽管我们力求提供准确的译文，但不对翻译内容的完整性、准确性或可靠性作出任何保证。 若出现任何内容不一致情况，请以原始 英文 版本为准，且原始英文版本为权威文本。 |
体系结构和概念
1.设计
设计有两个层：数据平面和控制平面。Longhorn Engine 是一个对应于数据平面的存储控制器，而 Longhorn Manager 对应于控制平面。
1.1.Longhorn Manager 和 Longhorn Engine
Longhorn Manager Pod 作为 Kubernetes DaemonSet 在 SUSE Storage 集群中的每个节点上运行。它在 Kubernetes 集群中创建和管理卷，并处理来自 SUSE Storage UI 或 Longhorn CSI 插件的 API 调用。它遵循 Kubernetes 控制器模式，有时称为操作员模式。
Longhorn Manager 与 Kubernetes API 服务器通信，以创建新的 SUSE Storage 卷 CR。然后，Longhorn Manager 监视 API 服务器的响应，当它看到 Kubernetes API 服务器创建了新的 SUSE Storage 卷 CR 时，Longhorn Manager 创建一个新卷。
当请求 Longhorn Manager 创建卷时，它会在卷附加的节点上创建一个 Longhorn Engine 实例，并在每个将放置副本的节点上创建一个副本。副本应放置在不同的主机上，以确保最大可用性。
多个副本的数据路径确保 Longhorn 卷的高可用性。如果副本或 Longhorn Engine 出现问题，它不会影响所有副本或 Pod 对卷的访问。Pod 将继续正常运行。对于具有 N 副本数量的给定卷，Longhorn 卷最多可以容忍 N-1 个副本故障。这是因为至少需要一个健康的副本才能使卷保持操作状态。
Longhorn Engine 始终在使用 SUSE Storage 卷的 Pod 所在的同一节点上运行。它同步地将卷复制到存储在多个节点上的多个副本中。
Longhorn Engine 和副本通过 Kubernetes 进行编排。
在下图中，
-
有三个实例，每个实例都有 SUSE Storage 卷。
-
每个卷都有一个专用控制器，称为 Longhorn Engine。对于 V1 卷，Longhorn Engine 作为 Linux 进程运行，而对于 V2 卷，它作为 SPDK RAID 块设备 (bdev) 运作。
-
每个 SUSE Storage 卷有两个副本。在 V1 中，副本作为 Linux 进程运行，而在 V2 中，它们作为 SPDK 逻辑卷 bdev 实现。
-
图中的箭头表示卷、控制器实例、副本实例和磁盘之间的读/写数据流。
-
通过为每个卷创建一个单独的 Longhorn Engine，如果一个控制器故障，其他卷的功能不会受到影响。
图 1。卷、Longhorn Engine、副本实例和磁盘之间的读/写数据流
1.2.基于微服务的设计优势
每个 Longhorn Engine 只需服务一个卷，从而简化了存储控制器的设计。由于控制器软件的故障域被隔离到单个卷，因此控制器崩溃只会影响一个卷。
Longhorn Engine 简单且轻量，使我们能够创建数千个独立的 Longhorn Engine。Kubernetes 调度这些独立的 Longhorn Engine，从共享的磁盘组中提取资源，并与 SUSE Storage 一起构建出一个弹性的分布式块存储系统。
由于每个卷都有自己的控制器，因此每个卷的控制器和副本实例也可以在不明显中断 IO 操作的情况下进行升级。
SUSE Storage 可以创建一个长期运行的作业，以协调所有活动卷的升级，而不会干扰系统的持续操作。为了确保升级不会导致意外问题，SUSE Storage 可以选择升级一小部分卷，并在升级过程中如果出现问题则回滚到旧版本。
1.3.CSI 驱动程序
Longhorn CSI 驱动程序获取块设备，对其进行格式化，并将其挂载到节点上。然后 kubelet 在 Kubernetes Pod 内部绑定挂载该设备。这使得 Pod 可以访问 SUSE Storage 卷。
所需的 Kubernetes CSI 驱动程序镜像将由 Longhorn 驱动程序部署者自动部署。 要在隔离环境中安装 SUSE Storage，请参考 本节。
1.4.CSI 插件
SUSE Storage 通过 CSI 插件. 在 Kubernetes 中进行管理。这使得插件的安装变得简单。
Kubernetes CSI 插件调用 SUSE Storage 来创建卷，以为 Kubernetes 工作负载创建持久数据。CSI 插件使您能够创建、删除、附加、分离、挂载卷，并对卷进行快照。SUSE Storage 提供的所有其他功能都通过 UI 实现。
Kubernetes 集群内部使用 CSI 接口与 Longhorn CSI 插件进行通信。而 Longhorn CSI 插件使用 Longhorn API 与 Longhorn Manager 进行通信。
对于 v1 卷，SUSE Storage 使用 iSCSI，这可能需要在您的节点上进行额外配置：
-
根据 Linux 发行套件，您需要安装
open-iscsi或iscsiadm。
相比之下，v2 卷有不同的先决条件，具体取决于配置：
-
像`vfio_pci`和`uio_pci_generic`这样的内核模块是必需的。
-
对于 NVMe-TCP 前端，
nvme_tcp模块是必需的。
1.5.用户界面
用户界面通过 Longhorn API 与 Longhorn Manager 交互，并作为 Kubernetes 的补充。通过用户界面，您可以管理快照、备份、节点和磁盘。
此外，集群工作节点的空间使用情况由用户界面收集并展示。有关详细信息，请参见这里。
2.卷和主存储
在创建卷时，Longhorn Manager 会创建 Longhorn Engine 微服务以及每个卷的副本作为微服务。这些微服务共同形成一个SUSE Storage卷。每个副本应放置在不同的节点或不同的磁盘上。
在 Longhorn Manager 创建 Longhorn Engine 后，它会连接到副本。Longhorn Engine 在 Pod 运行的同一节点上暴露一个块设备。
可以使用kubectl创建一个SUSE Storage卷。
2.1.精简配置和卷大小
SUSE Storage是一个精简配置的存储系统。这意味着SUSE Storage卷只会占用它当前所需的空间。例如，如果您分配了一个 20 GB 的卷，但只使用了 1 GB，则磁盘上的实际数据大小将为 1 GB。您可以在用户界面的卷详细信息中查看实际数据大小。
如果您从卷中删除了内容，SUSE Storage卷本身的大小无法缩小。例如，如果您创建一个20 GB的卷，使用了10 GB，然后删除了9 GB的内容，磁盘上的实际大小仍然是10 GB，而不是1 GB。这是因为SUSE Storage在块级别上操作，而不是文件系统级别，因此SUSE Storage不知道内容是否已被用户删除。该信息主要保留在文件系统级别。
有关卷大小相关概念的更多介绍，请参见此doc以获取更多详细信息。
2.2.在维护模式下还原卷
当从用户界面附加卷时，有一个复选框用于维护模式。它主要用于从快照还原卷。
该选项将导致在不启用前端（块设备或iSCSI）的情况下附加卷，以确保在附加卷时没有人可以访问卷数据。
在v0.6.0之后，快照还原操作要求卷处于维护模式。这是因为如果在卷挂载或使用时修改块设备的内容，将导致文件系统损坏。
它还可以在不担心数据意外被访问的情况下检查卷状态。
2.3.复本
每个副本包含一个SUSE Storage卷的快照链。快照就像图像的一层，最旧的快照用作基础层，而较新的快照在上面。只有在覆盖旧快照中的数据时，数据才会包含在新的快照中。一起，快照链显示数据的当前状态。
对于每个SUSE Storage卷，多个卷副本应在Kubernetes集群中运行，每个副本在单独的节点上。所有副本都被视为相同，Longhorn Engine 始终在与Pod相同的节点上运行，而Pod也是卷的消费者。通过这种方式，我们确保即使Pod宕机，引擎也可以移动到另一个Pod，您的服务将继续不受干扰。
默认副本数量可以在settings.中更改。当卷附加时，卷的副本数量可以在用户界面中更改。
如果当前健康副本数量少于指定副本数量，SUSE Storage 将开始重建新的副本。
如果当前健康副本数量多于指定副本数量，副本自动平衡和数据本地性将被禁用，SUSE Storage 将不执行任何操作。在这种情况下，如果一个副本失败或被删除，SUSE Storage 将不会开始重建新的副本，除非健康副本数量低于指定副本数量。如果设置了副本自动平衡或数据本地性，SUSE Storage 可能会删除其中一个副本。
SUSE Storage 副本是使用 Linux 稀疏文件, 构建的，支持精简配置。
2.3.1.副本的读写操作是如何工作的
当从卷的副本中读取数据时，如果可以在实时数据中找到该数据，则使用该数据。如果没有，则读取最新的快照。如果在最新的快照中未找到数据，则读取下一个较旧的快照，依此类推，直到读取到最旧的快照。
当您拍摄快照时，会创建一个 差异 磁盘。随着快照数量的增加，差异磁盘链（也称为快照链）可能会变得相当长。为了提高读取性能，SUSE Storage 因此维护一个读取索引，记录每个 4K 存储块的有效数据所在的差异磁盘。
在下图中，卷有八个块。读取索引有八个条目，并在读取操作进行时懒惰地填充。
写入操作重置读取索引，使其指向实时数据。实时数据由某些索引中的数据和其他索引中的空白空间组成。
在读取索引之外，我们目前不维护额外的元数据来指示哪些块被使用。
图 2。读取索引如何跟踪哪个快照持有最新数据
上面的图表使用颜色编码显示哪些块包含根据读取索引的最新数据，最新数据的来源也列在下面的表格中：
| 读取索引 | 最新数据的来源 |
|---|---|
0 |
最新快照 |
1 |
实时数据 |
2 |
最旧快照 |
3 |
最旧快照 |
4 |
最旧快照 |
5 |
实时数据 |
6 |
实时数据 |
7 |
实时数据 |
请注意，如上图中的绿色箭头所示，读取索引的索引5之前指向第二旧的快照作为最新数据的来源，然后在索引5的4K存储块被实时数据覆盖时，它改变为指向实时数据。
读取索引保存在内存中，每个4K块消耗一个字节。字节大小的读取索引意味着每个卷可以拍摄多达254个快照。
每个副本的读取索引在内存中消耗一定量的数据结构。例如，一个1 TB的卷消耗256 MB的内存读取索引。
2.3.2 如何添加新副本
当添加新副本时，现有副本会与新副本同步。第一个副本是通过从实时数据中拍摄新快照创建的。
以下步骤详细说明了SUSE Storage如何添加新副本：
-
Longhorn Engine被暂停。
-
假设副本中的快照链由实时数据和一个快照组成。当新副本被创建时，实时数据成为最新的（第二个）快照，并创建一个新的空白版本的实时数据。
-
新副本以WO（只写）模式创建。
-
Longhorn Engine恢复运行。
-
所有快照都已同步。
-
新的副本已设置为RW（读写）模式。
2.3.3.故障副本的重建方式
SUSE Storage 将始终尝试为每个卷维护至少给定数量的健康副本。
当控制器检测到其副本中的故障时，它会将该副本标记为错误状态。Longhorn Manager负责启动和协调重建故障副本的过程。
为了重建故障副本，Longhorn Manager创建一个空白副本，并调用Longhorn Engine将空白副本添加到卷的副本集中。
为了添加空白副本，引擎执行以下操作：
-
暂停所有读写操作。
-
以WO（只写）模式添加空白副本。
-
对所有现有副本进行快照，现在它们的头部将有一个空白的差异磁盘。
-
恢复所有读写操作。只有写操作将被分派到新添加的副本。
-
启动一个后台进程，将良好副本中除最新差异磁盘之外的所有差异磁盘同步到空白副本。
-
同步完成后，所有副本现在都有一致的数据，卷管理器将新副本设置为RW（读写）模式。
最后，Longhorn Manager 调用 Longhorn Engine 将故障副本从其副本集中移除。
2.4.快照
快照功能使卷能够恢复到历史上的某个时点。次级存储中的备份也可以从快照中构建。
当卷从快照中恢复时，它反映了快照创建时卷的状态。
快照功能也是 SUSE Storage 重建过程的一部分。每当SUSE Storage检测到副本宕机时，它将自动拍摄一个（系统）快照，并开始在另一个节点上重建它。
2.4.1.快照的工作原理
快照就像图像的一层，最旧的快照用作基础层，而较新的快照在上面。只有在覆盖旧快照中的数据时，数据才会包含在新的快照中。一起，快照链显示数据的当前状态。有关如何从副本读取数据的更详细说明，请参阅关于副本的读/写操作的部分。
快照在创建后不能更改，除非删除快照，在这种情况下，其更改将与下一个最近的快照合并。新数据始终写入实时版本。新快照始终从实时数据创建。
要创建一个新的快照，实时数据将成为最新的快照。然后创建一个新的空白版本的实时数据，取代旧的实时数据。
2.4.3.删除快照
不需要的快照可以通过用户界面手动删除。如果触发了任何快照的删除，任何系统生成的快照将自动标记为待删除。
最新的快照无法被删除。这是因为每当删除一个快照时，SUSE Storage将其内容与下一个快照合并，以便下一个及后续快照保留正确的内容。
但是SUSE Storage无法对最新的快照执行此操作，因为没有更近期的快照可以与被删除的快照合并。最新快照的下一个"`snapshot`"是实时卷（卷头），此时用户正在读/写，因此合并过程无法进行。
相反，最新的快照将被标记为已删除，并将在下次可能时进行清理。
要清理最新的快照，可以创建一个新的快照，然后删除之前的“最新”快照。
2.4.5.崩溃一致性
SUSE Storage是一个崩溃一致的块存储解决方案。
操作系统在写入块层之前将内容保留在缓存中是正常的。这意味着如果所有副本都宕机，则SUSE Storage可能不包含在关机前立即发生的更改，因为内容保留在操作系统级别的缓存中，尚未传输到SUSE Storage系统。
这个问题类似于如果您的台式计算机因停电而关机时可能发生的问题。恢复电源后，您可能会发现硬盘中有一些损坏的文件。
为了强制在任何给定时刻将数据写入块层，可以在节点上手动运行sync命令，或者卸载磁盘。在这两种情况下，操作系统都会将缓存中的内容写入块层。
SUSE Storage在创建快照之前会自动运行sync命令。
3.备份和二级存储
备份是备份存储中的一个对象，它是一个位于Kubernetes集群外部、兼容NFS或S3的对象存储。备份提供了一种二级存储形式，因此即使您的Kubernetes集群不可用，您的数据仍然可以被检索。
由于卷复制是同步的，并且由于网络延迟，跨区域复制很困难。备份存储也用作解决此问题的媒介。
当在用户界面上配置备份目标（备份和恢复 → 备份目标）时，SUSE Storage可以连接到备份存储，并在*备份*屏幕上显示现有备份的列表。
如果SUSE Storage在第二个Kubernetes集群中运行，它还可以将灾难恢复卷同步到二级存储中的备份，以便在第二个Kubernetes集群中更快地恢复您的数据。
3.1.备份的工作原理
备份是使用一个快照作为源创建的，因此它反映了快照创建时卷数据的状态。备份存储在集群外的远程位置。
与快照相比，备份可以被视为一系列快照的扁平化版本。就像将分层图像转换为平面图像时会丢失信息一样，将一系列快照转换为备份时也会丢失数据。在这两种转换中，任何被覆盖的数据都会丢失。
由于备份不包含快照，因此它们不包含对卷数据的更改历史。从备份恢复卷后，卷最初包含一个快照。该快照是原始链中所有快照的合并版本，反映了备份创建时卷的实时数据。
虽然快照可以达到数百GB，但备份由2 MB的文件组成。
同一原始卷的每个新备份都是增量的，检测并传输快照之间更改的块。这是一项相对简单的任务，因为每个快照都是一个 differencing文件，仅存储自上一个快照以来的更改。这一设计还意味着，如果没有块发生变化并且进行了备份，则备份存储中的该备份将显示为0字节。然而，如果您从该备份恢复，它仍将包含完整的卷数据，因为它将恢复备份存储中已存在的必要块，这些块是备份所需的。
为了避免存储大量小块存储，SUSE Storage使用2 MB块执行备份操作。这意味着如果在2 MB边界内的任何4K块发生变化，SUSE Storage将备份整个2 MB块。这在可管理性和效率之间提供了正确的平衡。
图 3。次级存储中的备份与主存储中的快照之间的关系
上图描述了如何从快照创建备份：
-
图表的主存储侧显示Kubernetes集群中SUSE Storage卷的一个副本。副本由四个快照的链条组成。按时间顺序从最新到最旧，快照依次为实时数据、snap3、snap2和snap1。
-
图表的二级存储部分显示了两个备份，存储在外部对象存储服务中，例如S3。
-
在二级存储中，备份-from-snap2的颜色编码显示它包含了来自snap1的蓝色更改和来自snap2的绿色更改。来自snap2的更改没有覆盖snap1中的数据，因此来自snap1和snap2的更改都包含在备份-from-snap2中。
-
名为备份-from-snap3的备份反映了在创建snap3时卷数据的状态。颜色编码和箭头表明备份-from-snap3包含了来自snap3的所有深红色更改，但仅包含来自snap2的一个绿色更改。这是因为snap3中的一个红色更改覆盖了snap2中的一个绿色更改。这说明备份不包括完整的更改历史，因为它们将快照与之前的快照混淆在一起。
-
每个备份维护自己的一组2 MB块。每个2 MB块仅备份一次。这两个备份共享一个绿色块和一个蓝色块。
当从二级存储中删除备份时，SUSE Storage并不会删除它使用的所有块。相反，它定期执行垃圾回收，以清理二级存储中未使用的块。
属于同一卷的所有备份的2 MB块存储在同一个目录下，因此可以在多个备份之间共享。
为了节省空间，在备份之间没有更改的2 MB块可以在共享同一备份卷的多个备份中重复使用。由于使用校验和来处理2 MB块，我们在同一卷的2 MB块中实现了一定程度的去重。
每个2 MB块（.blk文件）都是压缩的。
3.3.灾难恢复卷
灾难恢复（DR）卷是一个特殊卷，用于在整个主集群出现故障时在备份集群中存储数据。DR 卷用于提高 SUSE Storage 卷的弹性。
由于 DR 卷的主要目的是从备份中恢复数据，因此在激活之前，该类型的卷不支持以下操作：
-
创建、删除和还原快照
-
创建备份
-
创建持久卷
-
创建持久卷声明
可以从备份存储中的卷备份创建 DR 卷。在创建 DR 卷后，SUSE Storage 将监控其原始备份卷并从最新备份中增量恢复。备份卷是备份存储中的一个对象，包含同一卷的多个备份。
如果主集群中的原始卷出现故障，DR 卷可以立即在备份集群中激活，从而减少将数据从备份存储恢复到备份集群中的卷所需的时间。
当 DR 卷被激活时，SUSE Storage 将检查原始卷的最后备份。如果该备份尚未恢复，则将开始恢复，激活操作将失败。用户需要等待恢复完成后再重试。
如果存在任何 DR 卷，则设置中的备份目标无法更新。
在激活 DR 卷后，它变成一个正常的 SUSE Storage 卷，并且无法被停用。
3.4.备份存储更新间隔、RTO 和 RPO
增量恢复通常由定期的备份存储更新触发。您可以在备份目标设置屏幕上设置更新间隔 (备份和恢复 → 备份目标)。
请注意，这个间隔可能会影响恢复时间目标 (RTO)。如果间隔过长，灾难恢复卷需要恢复的数据量可能会很大，这将需要很长时间。
至于恢复点目标 (RPO)，它由备份卷的定期备份调度决定。如果正常卷 A 的定期备份调度每小时创建一个备份，那么 RPO 为一小时。您可以在这里查看如何在 SUSE Storage 中设置定期备份。
以下分析假设该卷每小时创建一个备份，并且从一个备份增量恢复数据需要五分钟：
-
如果备份存储轮询间隔为 30 分钟，则自上次恢复以来最多会有一个备份的数据。恢复一个备份的时间为五分钟，因此 RTO 将为五分钟。
-
如果备份存储轮询间隔为 12 小时，则自上次恢复以来最多会有 12 个备份的数据。恢复这些备份的时间为 5 * 12 = 60 分钟，因此 RTO 将为 60 分钟。
附录：Kubernetes 中持久存储的工作原理
要理解 Kubernetes 中的持久存储，重要的是要理解卷、持久卷、持久卷声明和存储类，以及它们如何协同工作。
Kubernetes 卷的一个重要属性是它与所属 Pod 具有相同的生命周期。如果 Pod 消失，卷将丢失。相比之下，持久卷在用户删除之前会继续存在于系统中。卷也可以用于在同一 Pod 内的容器之间共享数据，但这并不是主要用例，因为用户通常每个 Pod 只有一个容器。
一个 持久卷 (PV) 是 Kubernetes 集群中的一块持久存储，而 持久卷声明 (PVC) 是对存储的请求。 存储类 允许根据需要动态提供新的存储以供工作负载使用。
现有存储的配置
要使用现有的 PV，您的应用程序需要使用与 PV 绑定的 PVC，并且 PV 应包括 PVC 所需的最小资源。
换句话说，在 Kubernetes 中设置现有存储的典型工作流程如下：
-
设置持久存储卷，指您可以访问的物理或虚拟存储。
-
添加一个引用持久存储的 PV。
-
添加一个引用 PV 的 PVC。
-
将 PVC 挂载为工作负载中的一个卷。
当 PVC 请求一块存储时，Kubernetes API 服务器会尝试将该 PVC 与可用的预分配 PV 匹配。如果找到匹配，PVC 将与 PV 绑定，用户将开始使用该预分配的存储。
如果不存在匹配的卷，持久卷声明将无限期保持未绑定状态。例如，配置了许多 50 Gi PV 的集群将无法与请求 100 Gi 的 PVC 匹配。在集群中添加 100 Gi PV 后，PVC 可以被绑定。
换句话说，您可以创建无限的 PVC，但它们只会与 PV 绑定，如果 Kubernetes 主控能够找到至少满足 PVC 所需磁盘空间的足够 PV。
动态存储提供
对于动态提供存储，您的应用程序需要使用绑定到 StorageClass 的 PVC。StorageClass 包含授权以提供新的持久卷。
在 Kubernetes 中动态提供新存储的整体工作流程涉及一个 StorageClass 资源：
-
添加一个 StorageClass，并将其配置为自动从您可以访问的存储中提供新的存储。
-
添加一个引用 StorageClass 的 PVC。
-
将 PVC 挂载为您的工作负载的卷。
Kubernetes 集群管理员可以使用 Kubernetes StorageClass 来描述他们提供的存储 “classes”。StorageClass 可以具有不同的容量限制、不同的 IOPS 或任何其他供应者支持的参数。存储供应商特定的供应者与 StorageClass 一起使用，以根据 StorageClass 对象中设置的参数自动分配 PV。此外，供应者现在能够强制执行用户的资源配额和权限要求。在此设计中，管理员不再需要预测 PV 的需求并进行分配。
当使用 StorageClass 时，Kubernetes 管理员不需要为每个存储卷进行分配。管理员只需授予用户访问某个存储池的权限，并决定用户的配额。然后用户可以从存储池中划分出所需的存储块。
StorageClass 也可以在 Kubernetes 中不显式创建 StorageClass 对象的情况下使用。由于 StorageClass 也是用于将 PVC 与 PV 匹配的字段，因此可以手动创建具有自定义 StorageClass 名称的 PV，然后可以创建请求该 StorageClass 名称的 PV 的 PVC。Kubernetes 然后可以将您的 PVC 绑定到具有指定 StorageClass 名称的 PV，即使 StorageClass 对象不存在作为 Kubernetes 资源。
SUSE Storage 引入了一个 StorageClass，以便您的 Kubernetes 工作负载可以根据需要划分出持久存储的部分。
Kubernetes 工作负载的水平扩展与持久存储
VolumeClaimTemplate 是 StatefulSet 规格属性，它为块存储解决方案提供了一种水平扩展 Kubernetes 工作负载的方法。
此属性可用于为由 StatefulSet 创建的 Pods 创建匹配的 PV 和 PVC。
这些 PVC 是使用 StorageClass 创建的，因此在 StatefulSet 扩展时可以自动设置。
当 StatefulSet 缩减时，多余的 PV/PVC 会保留在集群中，并在 StatefulSet 再次扩展时被重用。
VolumeClaimTemplate 对于像 EBS 和 SUSE Storage 这样的块存储解决方案非常重要。因为这些解决方案本质上是 ReadWriteOnce,，所以它们不能在 Pods 之间共享。
如果您有多个 Pod 运行持久数据，部署与持久存储的兼容性较差。对于多个 Pod，应使用 StatefulSet。