本节将介绍一些核心概念和术语，您需要熟悉这些概念和术语才能理解LINSTOR是如何工作和部署存储的。这一部分是以 “ground up” 的方式布置的。

虽然LINSTOR可以用来使DRBD的管理更加方便，但它通常与更高层次的软件栈集成。这种集成已经存在于Kubernetes、OpenStack、OpenNebula和Proxmox中。本指南中包含了在这些环境中部署LINSTOR的特定章节。

LINSTOR使用的南向驱动程序是LVM、thinLVM和ZFS。

LINSTOR以.rpm和.deb两种包分发：

有关这些软件包的更多详细信息，请参见上面的Installable Components部分。

LINSTOR不支持滚动升级，controller和satellites必须具有相同的版本，否则controller将丢弃具有 版本不匹配 的satellite。但这不是问题，因为satellite不会做任何动作，只要它没有连接到controller，DRBD就不会被任何方式中断。

如果您使用的是嵌入的H2数据库，并且升级了linstor-controller包，那么将在默认的 /var/lib/linstor 目录中创建数据库的自动备份文件。如果由于任何原因linstor-controller数据库迁移失败，则此文件是一个很好的还原点，建议将错误报告给Linbit并还原旧的数据库文件并降级到以前的controller版本。

如果使用任何外部数据库或etcd，建议手动备份当前数据库以获得还原点。

因此，首先升级controller主机上的 linstor-controller 和 linstor-client 包，然后重新启动 linstor-controler, controller应启动，其所有客户端应显示 OFFLINE（VERSION_MISMATCH）。之后，您可以继续升级所有卫星节点上的`linstor-satellite`, 并重新启动它们，在短时间重新连接后，它们都应再次显示 ONLINE，并且您的升级已完成。

LINSTOR也可用容器运行。基础镜像可以在LINBIT的容器registry仓库 drbd.io 中找到。

要访问这些镜像，首先必须登录registry（访问[email protected]获取凭据）：

此repo中可用的容器包括：

通过在浏览器中打开http://drbd.io，可以可用image的最新列表。确保通过 “http”访问主机，因为registry的image本身通过 “https”提供服务。

To load the kernel module, needed only for LINSTOR satellites, you’ll need to run a drbd9-$dist container in privileged mode. The kernel module containers either retrieve an official LINBIT package from a customer repository, use shipped packages, or they try to build the kernel modules from source. If you intend to build from source, you need to have the according kernel headers (e.g., kernel-devel) installed on the host. There are 4 ways to execute such a module load container:

从已分发代码生成的示例（基于RHEL）：

Example using a module shipped with the container, which is enabled by not bind-mounting /usr/src:

Example using a hash and a distribution (rarely used):

Example using an existing repo config (rarely used):

然后以守护进程的身份运行LINSTOR satellite容器, 也需具有特权：

要将LINSTOR控制器容器作为守护进程运行，请将主机上的端口 3370 、 3376 和 3377 映射到该容器：

要与容器化LINSTOR集群交互，可以使用通过包安装在系统上的LINSTOR客户端，也可以通过容器化LINSTOR客户端。要使用LINSTOR客户端容器，请执行以下操作：

从这里开始，您可以使用LINSTOR客户端初始化集群，并开始使用典型的LINSTOR模式创建资源。

要停止并删除守护的容器和映像，请执行以下操作：

我们假设在 所有 集群节点上已完成以下步骤：

在已安装linstor-controller的主机上启动并启用该服务：

如果您确定linstor控制器服务在安装时自动启用，则还可以使用以下命令：

无论何时运行LINSTOR命令行客户端，它都需要知道listor-controller的运行位置。如果不指定它，它将尝试访问本地运行的linstor-controller，该控制器侦听IP 127.0.0.1 端口是 3376 。这样，我们可以在与 linstor-controller 相同的主机上使用 linstor-client 。

应该输出一个空列表，而不是一条错误信息。

您可以在任何其他机器上使用 linstor 命令，但随后您需要告诉客户端如何找到linstor-controller。如下所示，可以将其指定为命令行选项、环境变量或全局文件：

或者，您可以创建 /etc/linstor/linstor-client.conf 文件，并按如下方式填充它。

如果配置了多个linstor控制器，只需在逗号分隔的列表中指定它们即可。linstor客户机会按照列出的顺序进行尝试。

下一步是将节点添加到LINSTOR集群。您需要提供：

使用 `linstor node list`时，将看到新节点标记为脱机。现在启动并启用该节点上的 linstor-satellite，以便服务在重新启动时也启动：

如果您确定该服务已默认启用并在重新启动时启动，则还可以使用 systemctl start linstor-satellite 。

大约10秒后，您将看到 linstor node list 中的状态变为联机。当然，在controller知道satellite节点的存在之前，satellite进程已经启动完毕。

StoragePools在LINSTOR上下文中用于标识存储。要对多个节点的存储池进行分组，只需在每个节点上使用相同的名称。例如，一种有效的方法是给所有的ssd取一个名字，给所有的hdd取另一个名字。

在每个提供存储的主机上，您需要创建LVM VG或ZFS zPool。使用一个LINSTOR存储池名称标识的VG和zPool在主机上可能有不同的VG或zPool名称，但请您自己考虑，是否在所有节点上使用相同的VG或zPool名称。

然后需要向LINSTOR注册：

要列出您可以使用的存储池，请执行以下操作：

或者使用短版本

如果存储池的VG/zPool出现任何问题，例如VG已被重命名或以某种方式变得无效，您可以使用以下命令删除LINSTOR中的存储池，前提是只有资源及其所有卷都位于所谓的 lost 存储池中。此功能自LINSTOR v0.9.13起可用。

或者使用短版本

如果由于附加的资源或快照（其中一些卷位于另一个仍在运行的存储池中）而阻止删除存储池，则会在相应list命令的 status 列中给出提示（例如 linstor resource list ) 手动删除丢失的存储池中的LINSTOR对象后，可以再次执行lost命令，以确保完全删除了存储池及其剩余对象。

资源组是资源定义的父对象，其中对资源组所做的所有属性更改都将由其资源定义的子级继承。资源组还存储自动放置规则的设置，并可以根据存储的规则生成资源定义。

简单地说，资源组就像模板，定义从它们创建的资源的特性。对这些伪模板的更改将应用于从资源组中创建的所有资源，并具有追溯性。

使用资源组部署资源的简单模式如下：

上述命令创建出一个名为 my_ssd_res 的资源，其中一个定义了双副本数的20GB卷将从名为 pool_ssd 的存储池的节点自动配置。

一个更有用的模式可能是创建一个资源组，其中的设置是您确定的最适合您的用例的。也许您必须对卷的一致性进行夜间联机验证，在这种情况下，您可以创建一个资源组，其中已经设置了您选择的 verify-alg ，以便从该组生成的资源预先配置为 verify-alg 集：

上述命令创建出20个10GiB资源，每个资源都预先配置了 crc32c 和 verify alg。

您可以通过在相应的 资源定义 或 卷定义 上设置选项来优化从资源组派生的单个资源或卷的设置。例如，如果上面示例中的 res11 被一个接收大量小的随机写入的、非常活跃的数据库使用，则可能需要增加该特定资源的 al-extents :

If you configure a setting in a resource-definition that is already configured on the resource-group it was spawned from, the value set in the resource-definition will override the value set on the parent resource-group. For example, if the same ‘res11’ was required to use the slower but more secure ‘sha256’ hash algorithm in its verifications, setting the ‘verify-alg’ on the resource-definition for ‘res11’ would override the value set on the resource-group:

在下面的场景中，我们假设目标是创建一个大小为 500 GB 的资源 备份，该资源在三个集群节点之间复制。

首先，我们创建一个新的资源定义：

其次，我们在该资源定义中创建一个新的卷定义：

如果要更改卷定义的大小，只需执行以下操作：

参数 0 是资源 backups 中的卷数。必须提供此参数，因为资源可以有多个卷，并且它们由所谓的卷号标识。这个数字可以通过列出卷定义来找到。

到目前为止，我们只在LINSTOR的数据库中创建了对象，没有在存储节点上创建一个LV。现在你可以选择将安置任务派发给LINSTOR，或者自己做。

通过使用 --drbd-diskless 选项而不是 --storage-pool ，可以在节点上拥有永久无盘drbd设备。这意味着资源将显示为块设备，并且可以在没有现有存储设备的情况下装载到文件系统。资源的数据通过网络在具有相同资源的其他节点上访问。

所谓的一致性组是DRBD的一个特性。由于LINSTOR的主要功能之一是使用DRBD管理存储集群，因此本用户指南中提到了这一点。 单个资源中的多个卷是一个一致性组。

这意味着一个资源的不同卷上的更改在其他Satellites上以相同的时间顺序复制。

因此，如果资源中的不同卷上有相互依赖的数据，也不必担心时间问题。

要在LINSTOR资源中部署多个卷，必须创建两个同名的卷定义。

这可以通过在将资源部署到节点之前将 StorPoolName 属性设置为卷定义来实现：

这里的 resource create 命令不需要 --storage-pool 选项。在这种情况下，LINSTOR使用 fallback 存储池。找到该存储池后，LINSTOR按以下顺序查询以下对象的属性：

如果这些对象都不包含 StorPoolName 属性，则controller将返回硬编码的 DfltStorPool 字符串作为存储池。

这还意味着，如果在部署资源之前忘记定义存储池，则会收到一条错误消息，即LINSTOR找不到名为 DfltStorPool 的存储池。

LINSTOR也可以在没有DRBD的情况下使用。没有DRBD，LINSTOR能够从LVM和ZFS支持的存储池中配置卷，并在LINSTOR集群中的各个节点上创建这些卷。

目前，LINSTOR支持创建LVM和ZFS卷，可以选择在这些卷上分层luk、DRBD和/或/NVMe-TCP的NVMe的某些组合。

例如，我们在LINSTOR集群中定义了一个Thin LVM支持的存储池，名为 thin-lvm:

我们可以使用LINSTOR在 linstor-d 上创建一个100GiB大小的精简LVM，使用以下命令：

你应该看到 linstor-d 上有一个新的瘦LVM。通过使用 --machine-readable 标志集列出LINSTOR资源，可以从LINSTOR提取设备路径：

如果要将DRBD放置在此卷上（这是LINSTOR中ZFS或LVM支持的卷的默认 --layer-list 选项），可以使用以下资源创建模式：

然后，您将看到有一个新的 Thin LVM被创建出来用于支撑 linstor-d 上的DRBD卷：

下表显示了哪个层可以后跟哪个子层：

LINSTOR可以在一台机器上处理多个网络接口卡（NICs），在LINSTOR中称为 netif。

其他NIC的创建方式如下：

NIC仅由IP地址标识，名称是任意的，与Linux使用的接口名称 无关 。可以将NIC分配给存储池，以便每当在这样的存储池中创建资源时，DRBD通信通过其指定的NIC路由。

FIXME 描述了如何通过特定的 netif 路由controller <-> 客户端通信。

LINSTOR可以处理drbd卷的透明加密。dm-crypt用于对存储设备中提供的存储进行加密。

使用加密的基本步骤：

LINSTOR提供各种命令来检查集群的状态。这些命令以 list- 前缀开头，并提供各种筛选和排序选项。--groupby 选项可用于按多个维度对输出进行分组和排序。

精简LVM和ZFS存储池支持快照。

DRBD选项是使用LINSTOR命令设置的。将忽略诸如 /etc/drbd.d/global_common.conf 文件中未由LINSTOR管理的配置。以下命令显示用法和可用选项：

例如，很容易为名为 backups 的资源设置DRBD协议：

LINSTOR可以在无盘和有盘之间转换资源。这是通过 resource toggle disk 命令实现的，该命令的语法类似于 resource create 。

例如，将磁盘添加到 alpha 上的无盘资源 backups：

再次删除此磁盘：

LINSTOR希望DRBD代理在相关连接所涉及的节点上运行。它目前不支持通过单独节点上的DRBD代理进行连接。

假设我们的集群由本地网络中的节点 alpha 和 bravo 以及远程站点上的节点 charlie 组成，每个节点都部署了名为 backups 的资源定义。然后，可以为 charlie 的连接启用DRBD Proxy，如下所示：

DRBD代理配置可以通过以下命令定制：

LINSTOR不会自动优化远程复制的DRBD配置，因此您可能需要设置一些配置选项，例如协议：

请与LINBIT联系以获得优化配置的帮助。

可以让LINSTOR与外部数据库提供程序（如Postgresql、MariaDB）一起工作，从版本1.1.0开始支持ETCD键值存储。

To use an external database there are a few additional steps to configure. You have to create a DB/Schema and user to use for linstor, and configure this in the /etc/linstor/linstor.toml.

To make LINSTOR’s administrative tasks more accessible and also available for web-frontends a REST-API has been created. The REST-API is embedded in the linstor-controller and since LINSTOR 0.9.13 configured via the linstor.toml configuration file.

如果您想使用REST-API，可以在以下链接中找到当前文档：https://app.swaggerhub.com/apis-docs/Linstor/Linstor/

Linstor uses SLF4J with Logback as binding. This gives Linstor the possibility to distinguish between the log levels ERROR, WARN, INFO, DEBUG and TRACE (in order of increasing verbosity). In the current linstor version (1.1.2) the user has the following four methods to control the logging level, ordered by priority (first has highest priority):

有关 logback.xml 的更多详细信息，请参见https://logback.qos.ch/manual/index.html[Logback Manual]。

如果没有使用上述任何配置方法，Linstor将默认为 INFO 日志级别。

可以让LINSTOR在controller和satellites连接之间使用SSL安全TCP连接。在不深入讨论java的SSL引擎如何工作的情况下，我们将向您提供使用java运行时环境中的 keytool 的命令行片段，介绍如何使用安全连接配置3节点设置。节点设置如下所示：

节点 alpha 只充当controller。节点 bravo 和节点 charlie 只充当卫星。

下面是生成这样一个密钥库设置的命令，当然你应该根据您的环境编辑值。

现在只需启动controller和satellites，并添加带有 --通信类型SSL 的节点。

LINSTOR在资源上自动配置仲裁策略 当仲裁可实现时 。这意味着，每当您有至少两个磁盘和一个或多个无磁盘资源分配，或三个或多个磁盘资源分配时，LINSTOR将自动为您的资源启用仲裁策略。

相反，当达到仲裁所需的资源分配少于最小值时，LINSTOR将自动禁用仲裁策略。

这是通过 DrbdOptions/auto-quorum 属性控制的，该属性可应用于 linstor-controller 、 resource-group 和 resource-definition 。 DrbdOptions/auto-quorum, 属性的接受值为 disabled 、 suspend io 和 io error 。

将 DrbdOptions/auto-quorum 属性设置为 disabled 将允许您手动或更细粒度地控制资源的仲裁策略（如果您愿意）。

例如，要手动设置名为 my_ssd_group 的 resource-group 的仲裁策略，可以使用以下命令：

您可能希望完全禁用DRBD的仲裁功能。要做到这一点，首先需要在适当的LINSTOR对象上禁用’DrbdOptions/auto-quorum’，然后相应地设置DRBD quorum特性。例如，使用以下命令完全禁用 my_ssd_group 的 resource-group 上的仲裁:

Kubernetes is a container orchestrator. Kubernetes defines the behavior of containers and related services via declarative specifications. In this guide, we’ll focus on using kubectl to manipulate .yaml files that define the specifications of Kubernetes objects.

Controller pod包括LINSTOR客户端，使得直接与LINSTOR交互变得容易。例如：

这应该只是调研问题和访问高级功能所必需的。常规操作（如创建卷）应通过Kubernetes integration实现。

operator 的 Helm chart中为您部署了LINSTOR CSI插件，因此如果您使用了该插件，可以跳过本节。

如果使用不同的方法集成LINSTOR，则需要安装LINSTOR CSI插件。部署CSI插件的说明可以在https://github.com/LINBIT/linstor-csi[project’s github]上找到。这将导致在kube-system命名空间中运行linstor-csi-controller StatefulSet 和linstor-csi-node DaemonSet。

一旦所有linstor-csi Pods 都启动并运行，我们就可以使用通常的Kubernetes工作流创建卷。

Configuring the behavior and properties of LINSTOR volumes deployed via Kubernetes is accomplished via the use of StorageClasses.

Here below is the simplest practical StorageClass that can be used to deploy volumes:

DRBD options can be set as well in the parameters section. Valid keys are defined in the LINSTOR REST-API (e.g., DrbdOptions/Net/allow-two-primaries: "yes").

我们可以使用以下命令创建 StorageClasses ：

现在，我们的存储类已经创建，我们现在可以创建一个 PersistentVolumeClaim ，它可以用来提供Kubernetes和LINSTOR都知道的卷：

我们可以使用以下命令创建 PersistentVolumeClaim ：

这将创建一个Kubernetes已知的 PersistentVolumeClaim ，它将绑定一个 PersistentVolume，另外LINSTOR现在将根据 listor-basic-storage-class 中定义的配置 StorageClass 创建这个卷。LINSTOR卷的名称将是一个UUID，前缀为 csi- 可以使用通常的 listor resource list 来观察此卷。一旦创建了该卷，我们就可以将其附加到一个pod。下面的 Pod 规范将生成一个Fedora容器，其中附加了忙等待的卷，因此在我们与它交互之前，它不会被取消调度 ：

我们可以使用以下命令创建 Pod ：

运行 kubectl describe pod fedora 可用于确认 Pod 调度和卷附加成功。

要删除卷，请确保没有pod正在使用它，然后通过 kubectl 删除 PersistentVolumeClaim 。例如，要删除我们刚刚创建的卷，请运行以下两个命令，注意在删除 PersistentVolumeClaim 之前必须取消调度该 Pod ：

Creating snapshots and creating new volumes from snapshots is done via the use of VolumeSnapshots, VolumeSnapshotClasses, and PVCs. First, add the optional CSI snapshotter to your cluster:

More detailed installation instructions can be found on the project site

Then we can create our VolumeSnapshotClass:

使用 kubectl 创建 VolumeSnapshotClass ：

现在，我们将为上面创建的卷创建卷快照。这是用 VolumeSnapshot 完成的：

使用 kubectl 创建 VolumeSnapshot ：

You can check that the snapshot creation was successful

最后，我们将使用 PVC 从快照创建一个新卷。

用 kubectl 创建 PVC ：

LINSTOR卷通常可以通过网络在本地和over the network来访问。

默认情况下，CSI插件将直接附加卷，如果碰巧将 Pod 调度到 kubelet 所在的底层存储上。但是，Pod 调度当前不考虑卷位置。如果需要本地连接的卷，可以使用replicasOnSame参数来限制底层存储的配置位置。

请参见localStoragePolicy以了解如何修改此默认行为。

Stork is a scheduler extender plugin for Kubernetes which allows a storage driver to give the Kubernetes scheduler hints about where to place a new pod so that it is optimally located for storage performance. You can learn more about the project on its GitHub page.

We are currently working with the maintainers behind Stork to have a LINSTOR driver shipped with it by default. In the meantime, you can use a custom-built Stork container by LINBIT which includes a LINSTOR driver, available on Docker Hub

一般来说，Kubernetes中LINSTOR卷的所有配置都应该通过 StorageClass 参数完成，如上面的基本示例中的 storagePool 所示。我们将在这里对所有可用的选项进行深入的处理。

proxmox VE是一个易于使用的、完整的服务器虚拟化环境，具有KVM、Linux容器和HA。

linstor-proxmox 是proxmox的一个Perl插件，它与LINSTOR结合，允许在多个proxmox VE节点上复制VM磁盘。这允许在几秒钟内实时迁移活动vm，而且不需要中央SAN，因为数据已经复制到多个节点。

If this is a fresh installation, skip this section and continue with Proxmox插件安装.

LINBIT为Proxmox VE用户提供了一个专用的公共仓库。这个存储库不仅包含Proxmox插件，还包含整个DRBD-SDS堆栈，包括DRBD SDS内核模块和用户空间实用程序。

DRBD9内核模块是作为dkms软件包（即 drbd-dkms ）安装的，因此，您必须先安装 pve-headers 软件包，然后才能从LINBIT的存储库中设置/安装软件包。 按照该顺序，确保内核模块将为您的内核正确构建。如果您不打算安装最新的Proxmox内核，则必须安装与当前运行的内核匹配的内核头文件（例如 pve-headers-$（uname -r））。如果您错过了这一步，那么仍然可以通过输入 apt install --reinstall drbd-dkms 命令， 针对当前内核重建dkms软件包（必须预先安装内核头文件）。

LINBIT’s repository can be enabled as follows, where “$PVERS” should be set to your Proxmox VE major version (e.g., “6”, not “6.1”):

对于本指南的其余部分，我们假设您已经按照初始化集群中的说明配置了LINSTOR集群。还要确保将每个节点设置为 “Combined” 节点。在一个节点上启动 “linstor-controller” ` ，在所有节点上启动 “linstor-satellite” 。从4.1.0版开始，使用插件的首选方法是通过LINSTOR资源组和每个资源组中的单个卷组。LINSTOR资源组在资源组中描述。必须在资源组上设置所有必需的LINSTOR配置（如冗余计数）。

最后一步是为Proxmox本身提供配置。这可以通过在 /etc/pve/storage.cfg 文件中添加一个条目来完成，其内容类似于以下内容。

“drbd” 条目是固定的，不允许修改它，因为它告诉Proxmox使用drbd作为存储后端。可以修改 “drbdstorage” 条目并将其用作友好名称，该名称将显示在PVE web GUI中以查找DRBD存储。 “content” 条目也是固定的，所以不要更改它。冗余（在资源组中指定）指定将在群集中存储多少数据副本。建议根据您的设置将其设置为2或3。数据可以从所有节点访问，即使其中一些节点没有数据的本地副本。例如，在5节点集群中，所有节点都可以访问数据的3个副本，无论它们存储在何处。 “controller” 参数必须设置为运行LINSTOR控制器服务的节点的IP。只能将一个节点设置为同时作为LINSTOR controller运行。如果该节点出现故障，请在另一个节点上启动LINSTOR controller，并将该值更改为其IP地址。有更优雅的方法来处理这个问题。有关更多信息，请参阅本章后面的 如何在ProxBox中设置高可用的LINSTOR controller 虚拟机 。

插件的最新版本允许定义多个不同的存储池。这样的配置如下：

现在，您应该可以通过Proxmox的web GUI创建vm，方法是选择 “drbdstorage” , 或者选择任何其他已定义的池作为存储位置。

Starting from version 5 of the plugin one can set the option “preferlocal yes”. If it is set, the plugin tries to create a diskful assignment on the node that issued the storage create command. With this option one can make sure the VM gets local storage if possible. Without that option LINSTOR might place the storage on nodes ‘B’ and ‘C’, while the VM is initially started on node ‘A’. This would still work as node ‘A’ then would get a diskless assignment, but having local storage might be preferred.

此时，您可以尝试实时迁移虚拟机 – 因为所有节点（甚至在无盘节点上）都可以访问所有数据 – 只需几秒钟。如果VM负载不足，并且有很多RAM一直被污染，那么整个过程可能需要更长的时间。但是在任何情况下，停机时间都应该是最少的，而且您不会看到任何中断。

对于本指南的其余部分，我们假设您安装了LINSTOR和Proxmox插件，如LINSTOR配置中所述。

基本思想是在一个由Proxmox及其HA特性控制的VM中执行LINSTOR控制器，其中存储驻留在由LINSTOR本身管理的DRBD上。

第一步是为VM分配存储空间：像往常一样创建一个VM，并在 “OS” 部分选择 “Do not use any media”。硬盘当然应该位于DRBD上（例如 “drbdstorage” ）。2GB的磁盘空间应该足够了，对于RAM，我们选择了1GB。这些是LINBIT为其客户提供的设备的最低要求（见下文）。如果您希望设置自己的控制器虚拟机，并且您有足够的可用硬件资源，则可以增加这些最小值。在下面的用例中，我们假设控制器VM是用ID 100创建的，但是如果这个VM是在以后创建的，换成一个不同的ID，就可以了。

LINBIT为其客户提供了一个设备，可用于填充创建的存储。为了让设备工作，我们首先创建一个 “Serial Port”。首先点击 \:Hardware” ，然后点击 “Add” ，最后点击 “Serial Port” :

如果一切正常，VM定义应该如下所示：

下一步是将VM设备复制到VM磁盘存储。这可以通过 qemu img 完成。

完成后，您可以启动VM并通过Proxmox VNC查看器连接到它。默认用户名和密码都是 “linbit” 。注意，我们保留了ssh服务器的默认配置，因此您将无法通过ssh和用户名/密码登录到VM。如果要启用该功能（和/或 “root” 登录），请在 /etc/ssh/sshd_config 中启用这些设置， 然后重新启动ssh服务。由于这个虚拟机是基于 “Ubuntu Bionic”, 您应该在 /etc/netplan/config.yaml 中更改网络设置（例如，静态IP）。之后，您应该能够通过ssh连接到VM：

在下一步中，将controller VM添加到现有集群：

在我们的测试集群中，Controller VM磁盘是在DRBD存储中创建的， 最初分配给一个主机（使用 linstor resource list 检查分配）。然后，我们使用 linstor resource create 命令为这个VM创建额外的资源分配给集群的其他节点。在由四个节点组成的实验环境中，我们将所有资源分配创建为磁盘分配，但无磁盘分配也很好。根据经验，将冗余计数保持在 “3” （通常没有意义），并将其余部分分配为无盘。

由于Controller VM的存储必须以某种方式在所有PVE主机上可用，因此我们必须确保在所有主机上启用 drbd.service （假定它在此阶段不受LINSTOR控制）：

默认情况下， linstor satellite 服务在启动时删除其所有资源文件（*.res）并重新生成它们。这与需要这些资源文件来启动控制器VM的 drbd 服务冲突。首先通过 drbd.service 调出资源，并确保调出控制器资源的 linstor satellite.service 不会删除相应的 res 文件。要进行必要的更改，需要通过 systemctl 为 linstor satellite.service 创建一个drop-in（不要直接编辑文件）。

当然，在 LS_KEEP_RES 变量中需要调整controller VM的名称。请注意，给定的值被解释为regex，因此不需要指定确切的名称。

别忘了重新启动 linstor satellite.service 。

在那之后，是时候进行最后的步骤了，即从现有的控制器（驻留在物理主机上）切换到VM中的新控制器。因此，让我们停止物理主机上的旧控制器服务，并将LINSTOR控制器数据库复制到VM主机：

最后，我们可以在VM中启用控制器：

要检查一切是否按预期工作，可以通过询问VM中的控制器来查询物理PVE主机上的群集节点： linstor—​controllers=10.43.7.254 node list。controller（只是一个controller，而不是 “Combined” 主机）显示为 “OFFLINE”， 但一切正常。这在未来可能会改变为更合理的方式。

As the last — but crucial — step, you need to add the “controllervm” option to /etc/pve/storage.cfg, and change the controller IP address to the IP address of the Controller VM:

请注意附加设置 “controllervm” 。这个设置非常重要，因为它告诉PVE以不同于DRBD存储中存储的其他VM的方式处理控制器VM。具体来说，它将指示PVE不要使用LINSTOR存储插件来处理控制器VM，而是使用其他方法。原因是，在这个阶段没有简单的LINSTOR后端。一旦控制器VM启动并运行（以及VM中相关的LINSTOR控制器服务），PVE主机将能够使用linstorage插件启动存储在DRBD存储中的其余虚拟机。请确保在 controllervm 设置中设置正确的VM ID。在本例中设置为 100 ，表示分配给控制器VM的ID。

非常重要的一点是，要确保控制器VM始终处于启动和运行状态，并且要定期备份它（主要是在修改LINSTOR集群时）。一旦VM消失，并且没有备份，LINSTOR集群必须从头开始重新创建。

为了防止意外删除VM，可以转到PVE GUI中VM的 “Options” 选项卡并启用 “Protection” 选项。但是，如果您意外地删除了VM，那么存储插件会忽略这些请求，因此VM磁盘不会从LINSTOR集群中删除。因此，可以使用与以前相同的ID重新创建VM（只需在PVE中重新创建VM配置文件并分配旧VM使用的相同DRBD存储设备）。这个插件只会返回 “OK” ，带有旧数据的旧VM可以再次使用。一般来说，注意不要删除控制器VM并相应地 “protect” 它。

目前，我们已经将控制器作为VM执行，但是我们应该确保VM的一个实例始终启动。为此，我们使用Proxmox的HA特性。点击虚拟机，然后点击 “More” ，然后点击 “Manage HA” 。我们为控制器VM设置以下参数：

只要您的Proxmox集群中有幸存的节点，一切都应该正常，并且如果承载控制器VM的节点关闭或丢失，Proxmox HA将确保controller在另一台主机上启动。显然，控制器VM的IP不应该更改。这取决于作为管理员的您，以确保是这样的情况（例如，设置一个静态IP，或始终通过桥接接口上的dhcp提供相同的IP）。

在此必须指出的是，如果要为LINSTOR集群使用专用网络，则必须确保为集群通信配置的网络接口在PVE主机上配置为网桥（即vmb1、vmbr2等）。如果将它们设置为直接接口（即eth0、eth1等），则您将无法设置控制器VM vNIC以与群集中的其余LINSTOR节点通信，因为您无法将直接网络接口分配给VM，而只能将桥接接口分配给VM。

此设置未完全处理的一个限制是所有群集节点重新启动后的群集完全中断（例如，常见电源故障）。不幸的是Proxmox在这方面非常有限。可以为VM启用 “HA Feature” ，还可以定义 “Start and Shutdown Order” 约束。但两者都是完全分离的。因此，在启动所有其他VM之前，很难/不可能保证controller VM将启动并运行。

可以通过在Proxmox插件中延迟VM启动来解决这个问题，直到控制器VM启动（即，如果要求插件启动控制器VM，它就会启动，否则它会等待并ping控制器）。虽然这是一个好主意，但在序列化的、非并发的VM启动/插件调用事件流中，这可能会严重失败，在controller VM启动之前，应该启动某些VM（然后被阻止）。这显然会导致僵局。

我们将与Proxmox讨论这些选项，但是我们认为当前的解决方案在大多数典型用例中都是有价值的。尤其是，与pacemaker配置的复杂性相比。我们将讨论一些用例，在这些用例中，人们可以预期不会同时关闭整个集群。即使是这样，当整个集群启动时，只有VMs的自动启动将不起作用。在这种情况下，管理员只需等到Proxmox HA服务启动控制器VM。之后，所有vm都可以在命令行上手动启动/或通过脚本批量启动。

OpenNebula是一个灵活的开源云管理平台，允许通过使用插件扩展其功能。

LINSTOR插件允许部署具有由DRBD支持并通过DRBD自己的传输协议连接到网络上的高可用映像的虚拟机。

为OpenNebula安装linstorage插件需要一个工作的OpenNebula集群以及一个工作的LINSTOR集群。

通过访问LINBIT的客户仓库，您可以使用

或

如果无法访问LINBIT准备的包，您需要返回阅读 Github page 上的说明。

可以按照指南中的说明安装和配置带有LINSTOR的DRBD集群，请参见初始化集群。

OpenNebula和DRBD集群可以相互独立，但以下情况除外：OpenNebula的前端和主机节点必须包含在这两个集群中。

主机节点不需要本地LINSTOR存储池，因为虚拟机映像是通过网络连接到它的。 ^[1]。

建议使用LINSTOR资源组配置您喜欢的部署，请参见OpenNebula资源组。不推荐使用以前的自动放置和部署节点模式, 因为已经过时了。

即使使用ssh系统数据存储和nfs共享系统数据存储，也支持实时迁移。

空闲空间的计算方式不同，这取决于资源是自动部署还是按节点部署。

对于每个节点放置的数据存储，将根据部署资源的所有节点中限制最严格的存储池报告可用空间。例如，总存储空间最小的节点的容量用于确定数据存储的总大小，而可用空间最小的节点用于确定数据存储中的剩余空间。

对于使用自动放置的数据存储，大小和剩余空间是根据LINSTOR报告的数据存储所使用的聚合存储池确定的。

Openstack包含各种各样的独立服务；与DRBD最相关的两个是Cinder和Nova。Cinder 是块存储服务，Nova 是计算节点服务，负责为虚拟机提供卷。

OpenStack的LINSTOR驱动程序管理DRBD/LINSTOR集群，并使它们在OpenStack环境中可用，特别是在Nova计算实例中。LINSTOR支持的Cinder卷将无缝地提供DRBD/LINSTOR的所有功能，同时允许OpenStack管理其所有部署和管理。驱动程序将允许OpenStack创建和删除持久LINSTOR卷，以及管理和部署卷快照和原始卷映像。

除了使用内核本机DRBD协议进行复制外，LINSTOR驱动程序还允许将iSCSI与LINSTOR集群一起使用，以提供最大的兼容性。有关这两个选项的更多信息，请参见选择传输协议。

在安装OpenStack驱动程序之前，必须完成DRBD和LINSTOR的初始安装和配置。集群中的每个LINSTOR节点也应该定义一个存储池。有关LINSTOR安装的详细信息，请参见here。

使用Cinder运行DRBD/LINSTOR有两种主要方法：

这些不是非此即彼的；您可以定义多个后端，其中一些使用iSCSI，另一些使用DRBD协议。

Docker 是一个以Linux容器的形式开发、发布和运行应用程序的平台。对于需要数据持久性的有状态应用程序，Docker支持使用持久 卷 和 卷驱动程序。

LINSTOR Docker Volume Plugin是一个卷驱动程序，它为docker容器提供来自linstor集群的持久卷。

To install the linstor-docker-volume plugin provided by LINBIT, you’ll need to have a working LINSTOR cluster. After that the plugin can be installed from the public docker hub.

As the plugin has to communicate to the LINSTOR controller via the LINSTOR python library, we must tell the plugin where to find the LINSTOR Controller node in its configuration file:

更广泛的例子如下：

下面是一些如何使用LINSTOR Docker Volume插件的示例。在下面我们期望一个由三个节点（alpha、bravo和charlie）组成的集群。

LINSTOR客户机包含一个子命令，可以生成一个迁移脚本，该脚本将现有DRBDManage节点和资源添加到LINSTOR集群。迁移可以在不停机的情况下完成。如果不打算迁移现有资源，请继续下一节。

首先要检查的是DRBDManage集群是否处于正常状态。如果 drbdmanage assignments 的输出看起来不错，那么可以通过 drbdmanage export ctrlvol>ctrlvol.json 导出现有的集群数据库。然后可以将其用作LINSTOR客户机的输入。客户端 不会 立即迁移您的资源，它只是生成一个shell脚本。因此，您可以多次运行迁移助手，并在实际执行之前检查/修改生成的shell脚本。迁移脚本生成通过 linstor dm-migrate ctrlvol.json dmmmigrate.sh 启动。脚本将提出几个问题，然后生成shell脚本。仔细阅读脚本后，可以关闭DRBDManage并重命名以下文件。如果不重命名它们，低级drbd实用程序将同时获取两种资源文件，一种来自DRBDManage，另一种来自LINSTOR。

显然，您需要在一个节点上启动linstor controller服务，并在所有节点上启动linstor satellites服务。

我们假设在 所有 集群节点上完成以下步骤：

注意，drbdmanage在必要时使用dbus激活来启动其服务器组件，不要手动启动服务器。

第一步是检查 drbdmanage （/etc/drbdmanaged.cfg）的配置文件，并使用配置中指定的名称创建一个LVM卷组。在下面的代码中，我们使用默认名称 drbdpool ，并假设卷组由 /dev/sda6 和 /dev/sda7 组成。创建卷组是必须在 每个 集群节点上执行的步骤：

第二步是初始化所谓的控制卷，然后使用它来冗余地存储集群配置。如果节点有多个接口，则必须指定DRBD用于与集群中其他节点通信的网络接口的IP地址，否则IP是可选的。此步骤只能在一个集群节点上执行。

我们建议使用’drbdpool’作为LVM卷组的名称，因为它是默认值，使您的管理工作更轻松。无论出于什么原因，如果您决定使用不同的名称，请确保在 /etc/drbdmanaged.cfg 中相应地设置了选项 drbdctrl vg 。配置将在集群配置中讨论。

将节点添加到集群很简单，需要一个带有两个参数的命令：

如果DNS配置正确，则 drbdmanage 的tab补全可以完成给定节点名的IP。

这里我们假设命令是在节点alpha上执行的。如果允许 root 用户通过 ssh 在 bravo 上以 root 身份执行命令，则节点 bravo 将自动加入集群。

如果无法使用公钥身份验证进行 ssh 访问， drbdmanage 将打印必须在节点 bravo 上执行的连接命令。您始终可以查询 drbdmanage 以输出特定节点的join命令：

Drbdmanage knows many configuration settings like the log-level or the storage plugin that should be used (i.e., LVM, ThinLV, ThinPool, ZPool, or ThinZpool). Executing drbdmanage modify-config starts an editor that is used to specify these settings. The configuration is split in several sections. If an option is specified in the [GLOBAL] section, this setting is used in the entire cluster. Additionally, it is possible to specify settings per node and per site. Node sections follow a syntax of [Node:nodename]. If an option is set globally and per node, the node setting overrules the global setting.

也可以将节点分组到 站点 。要使节点 alpha 成为站点 mysite 的一部分，必须在alpha的节点部分指定 site 选项：

然后还可以使用 [Site:] 部分指定每个站点的drbdmanage设置。假设您希望将 loglevel 选项一般设置为 INFO ，将站点 mysite 设置为 WARN ，并将节点alpha设置为要调试的站点 mysite 的一部分。这将导致以下配置：

通过执行不带任何选项的 drbdmanage modify-config ，可以编辑全局、每个站点和每个节点的设置。还可以为特定节点执行 modify-config 。在每个节点视图中，可以进一步设置每个节点的特定设置，如配置存储插件中讨论的存储插件。

存储插件是通过 modify-config 子命令设置的 每个 节点 设置。

假设您想为节点 bravo 使用 ThinLV 插件，在这里您想将 pool-name 选项设置为 mythinpool ：

在下面的场景中，我们假设目标是创建一个大小为 500 GB 的资源 备份 ，该资源在3个集群节点之间复制。首先，我们将展示如何在各个步骤中实现目标，然后展示如何在单个步骤中实现目标的捷径：

首先，我们创建一个新资源：

其次，我们在该资源中创建一个新卷：

如果我们在第一步中不使用 add resource ，那么 drbdmanage 将知道该资源不存在，并且它将创建该资源。

第三步是将资源部署到3个集群节点：

在本例中， drbdmanage 选择3个最符合所有要求的节点，这是默认情况下 drbdpool 卷组中可用空间最大的节点集。我们稍后将看到如何手动将资源分配给特定节点。

由于将新资源/卷部署到一组节点是一项非常常见的任务， drbdmanage 提供了以下捷径：

手动部署可以通过将资源分配给特定节点来实现。例如，如果决定将 backups 资源分配给 bravo 和 charlie ，则应执行以下步骤：

在下面的代码中，我们假设在所有部署了资源的节点上都使用了ThinLV插件，应该从中获取快照。有关如何配置存储插件的更多信息，请参阅集群配置。

Drbdmanage 提供各种命令来检查集群的状态。这些命令以 list- 前缀开头，并提供各种筛选和排序选项。 --groupby 选项可用于按多个维度对输出进行分组和排序。使用 --show 选项可以打开其他输出。以下是一些典型的例子：

目前，可以设置以下 drbdsetup 选项：

此外，还可以设置DRBD事件处理程序。

例如，在 common 部分和每个资源中都允许使用 net-options ，然后这些命令提供相应的开关。

为资源 backups 设置 max buffers 如下：

在common部分中设置此选项如下所示：

此外，对于每个可以指定的选项，总是有一个 --unset- 选项。因此，为资源 backups 设置 max buffers 如下：

可以使用 show options 子命令可视化当前设置的选项。

也支持为每个站点设置网络选项。假设 alpha 和 bravo 应该是站点 first 的一部分， charlie 和 delta 应该是站点 second 的一部分。此外，我们希望在两个站点中使用DRBD协议 C ，在站点 first 和 second 之间使用协议 A 。其设置如下：

The ‘–sites’ parameter follows a ‘from:to’ syntax, where currently ‘from’ and ‘to’ have a symmetric semantic. Setting an option from ‘first:second’ also sets this option from ‘second:first’.

可以在 common 部分和每个资源中设置DRBD事件处理程序：

重新平衡数据意味着移动一些工作分配，以便更好地利用可用资源。我们将讨论与manual workflow相同的示例。

给定的是一个示例策略，即数据需要在3个节点上可用，因此您的设置至少需要3个服务器。

现在，随着存储需求的增长，您将需要额外的服务器。不必同时购买3台以上的服务器，您可以在一个额外的节点上 重新平衡 数据。

首先，需要将新机器添加到集群；有关命令，请参见向集群添加节点。

下一步是添加分配：

现在您需要等待（初始）同步完成；您可以使用命令 drbdadm status（可选）和资源名称。

其中一个 仍有 数据的节点将显示如下状态

而目标节点的状态为 SyncTarget 。

当目标分配达到 UpToDate 状态时，此节点上的数据会有一个完整的附加副本；现在可以安全地从另一个节点删除该分配：

你移动了两个作业的一个 footnote：[或者三个，如果你数着等待 UpToDate 状态的话。], 简单的步骤！

了解drbdmanage子命令的最简单方法是阅读主手册页（man drbdmanage）。

在命令行中列出可用命令的一种快速方法是键入 drbdmanage list 。

有关子命令（例如列表节点）的更多信息可以通过三种方式检索：

在交互模式（drbdmanage interactive）下执行drbdmanage时，使用’help’子命令尤其有用。

drbdmanage最有用的特性之一是它丰富的tab 补全，它基本上可以用来完成drbdmanage所知道的每个对象（例如，节点名、IP地址、资源名等等）。在下面我们将展示一些可能的完工情况及其结果：

如果tab补全完成不正常，请尝试获取相应的文件：