也许至少每个人早晚对搜寻高性能软件定义的存储感到困惑的人早就听说过DRBD ，甚至可能对此有所了解。
的确，在Ceph和GlusterFS的流行程度达到顶峰的情况下，它们在原理上相当不错，而且最重要的是开箱即用，每个人都对它一点儿忘了。 而且，以前的版本不支持复制到两个以上的节点，因此，经常会遇到裂脑问题，这显然并没有增加它的流行性。
该解决方案实际上并不是什么新事物，但是很有竞争力。 在相对较低的成本给CPU和RAM，DRBD提供在块设备真正快速和安全的同步。 在这整个过程中，LINBIT-DRBD开发人员不会停滞不前，并不断对其进行完善。 从DRBD9版本开始， 它不再只是网络镜像，而是更多。
首先，为多台服务器创建单个分布式块设备的想法已逐渐淡出背景，现在LINBIT试图提供用于编排和管理在LVM和ZFS分区之上创建的群集中的许多drbd设备的工具。
例如，DRBD9最多支持32个副本，RDMA，无盘节点，并且新的编排工具使您可以使用快照，在线迁移等。
尽管DRBD9具有与Proxmox ， Kubernetes ， OpenStack和OpenNebula集成的工具，但目前它们处于过渡模式，当新工具尚未在任何地方得到支持时，旧工具将很快被弃用 。 这些是DRBDmanage和Linstor 。
我将利用这一时刻来不深入介绍每个细节，而是更详细地研究DRBD9本身的配置和工作原理。 即使仅仅是因为Linstor控制器的容错配置意味着将其安装在这些设备之一上，您仍然必须弄清楚它。
在本文中，我想向您介绍DRBD9及其在没有第三方插件的情况下在Proxmox中使用的可能性。
DRBD管理和Linstor
首先，值得一提的是有关DRBDmanage的内容 ，它在Proxmox中的集成非常好。 LINBIT为Proxmox提供了现成的DRBDmanage插件，使您可以直接从Proxmox界面使用其所有功能。
它看起来确实很棒，但不幸的是有一些缺点。
- 首先，标记的卷名称， LVM组或ZFS池必须命名为
drbdpool 。 - 每个节点不能使用多个池
- 根据解决方案的具体情况， 控制器卷只能在常规LVM上，而不能在其他情况下使用
- 周期性的dbus故障， DRBDmanage密切使用它来与节点进行交互。
结果，LINBIT决定用一个简单的应用程序替换所有复杂的DRBDmanage逻辑，该应用程序使用常规的tcp连接与节点进行通信，并且在那里工作时没有任何魔术。 于是就有了林斯托 。
Linstor确实工作得很好。 不幸的是，开发人员选择Java作为编写Linstor服务器的主要语言，但不要让这吓到您，因为Linstor本身仅处理在节点上分发 DRBD 配置和切片 LVM / ZFS分区。
两种解决方案都是免费的，并根据免费的GPL3许可进行分发。
您可以在Proxmox 官方Wiki上阅读有关它们的每个信息以及有关为Proxmox设置上述插件的信息。
故障转移NFS服务器
不幸的是，在撰写本文时， Linstor仅与Kubernetes集成。 但是到了今年年底，预计其他Proxmox ， OpenNebula ， OpenStack系统的驱动程序将被使用。
但是到目前为止，还没有现成的解决方案，但是我们不喜欢旧的一种方法。 让我们尝试使用旧的方式DRBD9来组织对共享分区的NFS访问 。
尽管如此，决定同样不会没有优势，因为NFS-服务器将允许你组织从多台服务器存储文件系统竞争性接入 ，而不需要与DLM复杂的集群文件系统，如OCFS和GFS2。
在这种情况下，只需将容器与Proxmox界面中的NFS服务器一起迁移，就可以切换主要 / 辅助节点的角色。
您还可以在此文件系统中存储任何文件，以及虚拟磁盘和备份。
如果您使用Kubernetes，则可以为PersistentVolumes安排ReadWriteMany访问。
Proxmox和LXC容器
现在的问题是：为什么选择Proxmox？
原则上，要构建这样的方案，我们可以使用Kubernetes以及带有集群管理器的常规方案。 但是Proxmox提供了现成的，非常多功能的，同时简单直观的界面，几乎可以满足您的所有需求。 它是现成的，具有集群功能，并支持基于softdog的防护机制。 并且当使用LXC容器时，它允许您在切换时实现最小的超时。
最终的解决方案将不会有单点故障 。
实际上，我们将主要使用Proxmox作为集群管理器 ，在这里我们可以将单独的LXC容器视为在经典HA集群中运行的服务，只是区别在于根系统也随容器一起提供。 也就是说，您不需要在每个服务器上分别安装多个服务实例，而只能在容器内执行一次。
如果您曾经使用过群集管理器软件并为应用程序提供了HA ，您将理解我的意思。
一般方案
我们的解决方案将类似于数据库的标准复制方案。
- 我们有三个节点
- 每个节点都有一个分布式drbd设备 。
- 该设备具有常规文件系统（ ext4 ）
- 只有一台服务器可以成为主服务器
- LXC容器中的NFS服务器在向导上启动。
- 所有节点都严格通过NFS访问设备。
- 如果有必要，该向导可以移动到另一个节点，与NFS-服务器一起
DRBD9具有一项非常酷的功能，可大大简化所有操作：
当drbd设备安装在某个节点上时，它会自动变为“ 主要” 。 如果该设备被标记为Primary ，则任何尝试将其安装在另一个节点上都将导致访问错误。 这样可确保阻止并保证防止同时访问设备。
为什么所有这些都大大简化了？ 因为当容器启动时， Proxmox会自动在该节点上挂载该设备并将其变为主设备；而当容器停止时，相反，它将对其进行卸载，然后该设备再次变为辅助设备。
因此，我们不再需要担心切换主要 / 次要设备，Proxmox会自动进行切换，万岁！
DRBD设置
好了，我们已经找到了这个主意，现在让我们继续实施。
默认情况下， Linux内核提供了 drbd的第八个版本 ，不幸的是它不适合我们，我们需要安装模块的第九个版本。
连接LINBIT存储库并安装所需的一切：
wget -O- https://packages.linbit.com/package-signing-pubkey.asc | apt-key add - echo "deb http://packages.linbit.com/proxmox/ proxmox-5 drbd-9.0" \ > /etc/apt/sources.list.d/linbit.list apt-get update && apt-get -y install pve-headers drbd-dkms drbd-utils drbdtop
pve-headers -必要的内核头文件的模块组装drbd-dkms -DKMS格式的内核模块drbd-utils基本的DRBD管理实用程序drbdtop是仅用于DRBD的交互式工具，如top
安装模块后，我们将检查是否一切正常：
如果在命令的输出中看到第八个版本 ，则出了点问题，并且树内内核模块已加载。 检查dkms status找出原因。
我们拥有的每个节点都将在常规分区之上运行相同的drbd设备 。 首先，我们需要为每个节点上的drbd准备本节。
这样的分区可以是任何块设备 ，可以是lvm，zvol，磁盘分区或整个磁盘。 在本文中，我将使用单独的nvme磁盘，并在drbd下使用一个分区： /dev/nvme1n1p1
值得注意的是，设备名称有时会更改，因此最好立即养成对设备使用恒定符号链接的习惯。
查找符号链接/dev/nvme1n1p1可以如下：
我们在所有三个节点上描述我们的资源：
建议使用单独的网络进行drbd同步。
现在为drbd创建元数据并运行它：
在所有三个节点上重复这些步骤，并检查状态：
现在，我们的不一致磁盘位于所有三个节点上，这是因为drbd不知道应将哪个磁盘作为原始磁盘。 我们必须将其中一个标记为“ 主要”，以便其状态与其他节点同步：
drbdadm primary --force nfs1 drbdadm secondary nfs1
此后， 同步将立即开始：
我们不必等待它完成，我们可以并行执行其他步骤。 它们可以在任何节点上执行，而不管其在DRBD中本地磁盘的当前状态如何。 所有请求将自动重定向到状态为UpToDate的设备。
不要忘记在节点上激活drbd服务的自动运行 ：
systemctl enable drbd.service
配置LXC容器
我们将省略由三个节点组成的Proxmox集群的配置部分，该部分在官方Wiki中有充分描述
如前所述，我们的NFS服务器将在LXC容器中工作 。 我们将继续在设备上的容器/dev/drbd100 ，我们刚刚创建的。
首先，我们需要在其上创建一个文件系统 ：
mkfs -t ext4 -O mmp -E mmp_update_interval=5 /dev/drbd100
默认情况下， Proxmox在文件系统级别包括多重安装保护 ，原则上我们可以不用它，因为 默认情况下，DRBD具有其自身的保护，它仅禁止该设备使用第二个主要对象，但谨慎并不会伤害我们。
现在下载Ubuntu模板：
# wget http://download.proxmox.com/images/system/ubuntu-16.04-standard_16.04-1_amd64.tar.gz -P /var/lib/vz/template/cache/
并从中创建我们的容器：
pct create 101 local:vztmpl/ubuntu-16.04-standard_16.04-1_amd64.tar.gz \ --hostname=nfs1 \ --net0=name=eth0,bridge=vmbr0,gw=192.168.1.1,ip=192.168.1.11/24 \ --rootfs=volume=/dev/drbd100,shared=1
在此命令中，我们指示容器的根系统将位于设备/dev/drbd100并添加参数shared=1以允许容器在节点之间迁移 。
如果出现问题，您可以随时通过Proxmox界面或在/etc/pve/lxc/101.conf容器/etc/pve/lxc/101.conf中对其进行/etc/pve/lxc/101.conf
Proxmox将解压缩模板并为我们准备容器根系统 。 之后，我们可以启动我们的容器：
pct start 101
配置NFS服务器。
默认情况下，Proxmox 不允许 NFS服务器在容器中运行，但是有多种方法可以启用它。
其中之一就是添加lxc.apparmor.profile: unconfined到我们容器的/etc/pve/lxc/100.conf 。
或者我们可以持续为所有容器启用NFS ，为此，我们需要更新所有节点上LXC的标准模板，将以下行添加到/etc/apparmor.d/lxc/lxc-default-cgns ：
mount fstype=nfs, mount fstype=nfs4, mount fstype=nfsd, mount fstype=rpc_pipefs,
更改之后，重新启动容器：
pct shutdown 101 pct start 101
现在让我们登录它：
pct exec 101 bash
安装更新和NFS服务器 ：
apt-get update apt-get -y upgrade apt-get -y install nfs-kernel-server
创建一个导出 ：
echo '/data *(rw,no_root_squash,no_subtree_check)' >> /etc/exports mkdir /data exportfs -a
HA设置
在撰写本文时，proxmox HA-manager有一个错误 ，该错误不允许HA容器成功完成其工作，因此，未被完全杀死的nfs服务器的内核空间进程会阻止drbd设备离开Secondary 。 如果您已经遇到这种情况，则不要惊慌，只需在启动容器的节点上执行killall -9 nfsd ，然后drbd设备应“释放”，它将转到Secondary 。
要修复此错误，请在所有节点上运行以下命令：
sed -i 's/forceStop => 1,/forceStop => 0,/' /usr/share/perl5/PVE/HA/Resources/PVECT.pm systemctl restart pve-ha-lrm.service
现在我们可以去HA-经理 kofiguratsii。 让我们为设备创建一个单独的HA组：
ha-manager groupadd nfs1 --nodes pve1,pve2,pve3 --nofailback=1 --restricted=1
我们的资源将仅在为此组指定的节点上工作。 将我们的容器添加到该组：
ha-manager add ct:101 --group=nfs1 --max_relocate=3 --max_restart=3
仅此而已。 简单吧？
生成的nfs球可以立即连接到Proxmox，以存储和运行其他虚拟机和容器。
建议和调优
广播电视
如上文所述，始终建议使用单独的网络进行复制。 强烈建议使用10 Gb网络适配器 ，否则会遇到端口速度问题。
如果复制似乎足够慢，请尝试使用DRBD的某些选项。 这是配置，我认为这是我的10G网络的最佳配置：
# cat /etc/drbd.d/global_common.conf global { usage-count yes; udev-always-use-vnr; } common { handlers { } startup { } options { } disk { c-fill-target 10M; c-max-rate 720M; c-plan-ahead 10; c-min-rate 20M; } net { max-buffers 36k; sndbuf-size 1024k; rcvbuf-size 2048k; } }
您可以从官方DRBD文档中获取有关每个参数的更多信息。
NFS服务器
为了加快NFS服务器的操作，可能有助于增加NFS服务器正在运行的实例总数。 默认情况下-8 ，就我个人而言，它帮助我将此数字增加到64 。
为此，请在/etc/default/nfs-kernel-server更新RPCNFSDCOUNT=64参数。
并重新启动守护程序：
systemctl restart nfs-utils systemctl restart nfs-server
NFSv3和NFSv4
知道NFSv3和NFSv4之间的区别吗？
- NFSv3是无状态协议；通常，它可以更好地容忍故障并恢复得更快。
- NFSv4是一种有状态协议 ，它运行速度更快，并且可以绑定到某些tcp端口，但是由于存在状态，因此它对故障更加敏感。 它还具有使用Kerberos和许多其他有趣功能使用身份验证的能力。
但是，当您运行showmount -e nfs_server ，将使用NFSv3协议。 Proxmox还使用NFSv3。 NFSv3也通常用于组织网络启动计算机。
通常，如果没有特别的理由要使用NFSv4，请尝试使用NFSv3，因为由于缺少状态而使NFSv3对于任何失败的痛苦都较小。
您可以通过为mount命令指定-o vers=3参数来使用NFSv3来安装球：
mount -o vers=3 nfs_server:/share /mnt
如果需要，通常可以为服务器禁用NFSv4，为此，请在--no-nfs-version 4变量中添加--no-nfs-version 4选项，然后重新启动服务器，例如：
RPCNFSDCOUNT="64 --no-nfs-version 4"
iSCSI和LVM
同样，可以在容器内部配置常规的tgt守护程序 ，iSCSI将为I / O操作产生更高的性能，并且由于tgt服务器完全在用户空间中工作，因此容器可以更平稳地工作。
通常，使用LVM将导出的LUN切成许多片段。 但是，有几个细微差别需要考虑，例如：如何提供LVM 锁以在多个主机上共享导出的组。
也许我将在下一篇文章中描述这些细微差别。