主页 / server / 问题 / 934488
Accepted
LetMeSOThat4U
Asked: 2018-10-09 04:42:47 +0800 CST

KVM+DRBD 在两台主动-被动服务器之间复制，手动切换

  • 772

我需要在主动-被动模式下构建 2 节点集群（类似？）解决方案，即一台服务器处于活动状态，而另一台服务器处于被动（备用）状态，不断从活动中复制数据。基于 KVM 的虚拟机将在活动节点上运行。

如果主动节点由于任何原因不可用，我想手动切换到第二个节点（成为主动节点和另一个被动节点）。

我看过这个教程：https ://www.alteeve.com/w/AN!Cluster_Tutorial_2#Technologies_We_Will_Use

但是，我没有足够的勇气相信全自动故障转移并构建复杂的东西并相信它可以正常运行。脑裂情况的风险太大，复杂性以某种方式失败，数据损坏等，而我的最大停机时间要求并不严重到需要立即自动故障转移。

我无法找到有关如何构建这种配置的信息。如果您已经这样做了，请在答案中分享信息/HOWTO。

或者也许可以使用 Linux 节点构建高度可靠的自动故障转移？Linux 高可用性的问题在于，就像 8 年前一样，人们似乎对这个概念产生了浓厚的兴趣，而且许多教程现在已经很老了。这表明 HA 在实践中可能存在实质性问题，一些/许多系统管理员干脆放弃了它。

如果可能，请分享如何构建它的信息以及您在生产中运行集群的经验。

linux

5 个回答

  1. 为什么不使用经过数千名用户检查并证明其可靠性的东西呢？您可以使用例如 StarWind VSAN Free 部署免费的 Hyper-V 服务器，并毫无问题地获得真正的 HA。查看本手册：https ://www.starwindsoftware.com/resource-library/starwind-virtual-san-hyperconverged-2-node-scenario-with-hyper-v-server-2016

    • 6
  2. Best Answer

    我的安装与您描述的设置非常相似：通过 DRBD 主动/被动具有备用副本的 KVM 服务器。为了使系统尽可能简单（并避免任何自动脑裂，即：由于我的客户弄乱了集群网络），我还放弃了自动集群故障转移。

    该系统已有 5 年以上的历史，从未给我带来任何问题。我的音量设置如下：

    • 用于 VM 存储的专用 RAID 卷；
    • 一个包含 QEMU/KVM 配置文件的小覆盖卷；
    • 更大的虚拟磁盘卷；
    • 管理整个专用阵列块设备的 DRBD 资源。

    我写了一些 shell 脚本来帮助我在故障转移的情况下。你可以在这里找到它们

    请注意，该系统的架构旨在实现最高性能，即使以牺牲快速快照和基于文件（而不是基于卷）的虚拟磁盘等功能为代价。

    现在重建一个类似的主动/被动设置，我会非常倾向于使用 ZFS 和通过send/recv. 它不是实时的、基于块的复制，但对于 90% 以上的情况来说已经足够了。

    如果真的需要实时复制，我会在 ZVOL + XFS 之上使用 DRBD；事实上，我非常满意地在我的实验室测试了这样的设置 + 自动起搏器开关。lvmthin如果无法使用 3rdy 部分模块（就像 ZoL 一样），我会在卷 + XFS之上使用 DRBD 资源。

    • 4

  3. 您可以完全设置 DRBD 并以纯手动方式使用它。这个过程根本不应该是复杂的。您只需手动执行 Pacemaker 或 Rgmanager 集群的操作即可。本质上：

    • 停止活动节点上的虚拟机
    • 在活动节点上降级 DRBD
    • 在对等节点上提升 DRBD
    • 在对等节点上启动 VM

    自然，这将要求两个节点都安装了正确的包，并且两个节点上都存在 VM 的配置和定义。

    我可以保证 Linux HA 堆栈（corosync 和起搏器）仍在积极开发和支持。许多指南很旧，该软件已经存在 10 年了。如果做得好，就不会出现重大问题或问题。它没有被抛弃，但它不再是“新奇的、令人兴奋的”。

    • 3

  4. 主动/被动集群仍然在许多地方大量使用，并在生产中运行。请在下面找到我们的生产设置，它工作正常，您可以让它在手动模式下运行 ( orchestrate=start)，或启用自动故障转移 ( orchestrate=ha)。我们使用 zfs 从 zfs 发送/接收和 zfs 快照中受益，但如果您更喜欢同步复制，也可以使用 drbd。

    先决条件：

    • 2 个节点（在我的设置中 2 个物理节点 400 公里距离）
    • 内部磁盘
    • 每个节点上 1 个 zfs 池
    • 拉伸 vlan（在我的设置中，我们在 OVH 托管服务提供商处使用“vrack”）

    脚步 ：

    • 在两个节点上安装 opensvc 代理 ( https://repo.opensvc.com )
    • 形成 opensvc 集群（需要 3 个命令，在https://www.opensvc.com的截屏视频中有描述）
    • 在两个节点之间创建根 ssh 信任
    • 为每个 kvm 来宾创建 1 个 opensvc 服务 [下面的服务配置文件]

    root@node1:~$ svcmgr -s win1 打印配置

    [DEFAULT]
env = PRD
nodes = node1.acme.com node2.acme.com
id = 7a10881d-e5d5-4817-a8fe-e7a2004c5520
orchestrate = start

[fs#1]
mnt_opt = rw,xattr,acl
mnt = /srv/{svcname}
dev = data/{svcname}
type = zfs

[container#0]
type = kvm
name = {svcname}
guestos = windows
shared = true

[sync#1]
src = data/{svcname}
dst = data/{svcname}
type = zfs
target = nodes
recursive = true
schedule = @12h

    一些解释：

    • 服务名为“win1”，{svcname}服务配置文件中的每个都是指向实际服务名称 (win1) 的引用
    • 服务启动执行以下操作：
      • data/win1在挂载点上挂载zfs 数据集/srv/win1
      • 启动 kvm 容器win1
    • ressourcesync#1用于声明一个异步 zfs 数据集复制到从节点（node1 上的 data/win1 发送到 node2 上的 data/win1），示例中每 12 小时一次（zfs 发送/接收由 opensvc 代理管理）
    • opensvc 代理也是处理 kvm qemu config 复制，并在服务重定位到从节点时定义它

    一些管理命令：

    • svcmgr -s win1 start启动服务
    • svcmgr -s win1 stop停止服务
    • svcmgr -s win1 stop --rid container#0在配置文件中停止容器引用 container#0
    • svcmgr -s win1 switch将服务重定位到另一个节点
    • svcmgr -s win1 sync update触发增量 zfs 数据集副本
    • svcmgr -s win1 sync full触发完整的 zfs 数据集副本

    我管理的一些服务还需要定期（每天/每周/每月）保留 zfs 快照，在这种情况下，我将以下配置片段添加到服务配置文件中，然后 opensvc 代理完成这项工作。

    [sync#1sd]
type = zfssnap
dataset = data/{svcname}
schedule = 23:00-23:59@61
keep = 7
name = daily
recursive = true
sync_max_delay = 1d

[sync#1sw]
type = zfssnap
dataset = data/{svcname}
schedule = 23:00-23:59@61 sun
keep = 4
name = weekly
recursive = true
sync_max_delay = 7d

[sync#1sm]
type = zfssnap
dataset = data/{svcname}
schedule = 23:00-23:59@61 * *:first
keep = 6
name = monthly
recursive = true
sync_max_delay = 31d

    根据要求，我还添加了一个 lvm/drbd/kvm 配置：

    drbd 资源配置/etc/drbd.d/kvmdrbd.res：

    resource kvmdrbd {
    device /dev/drbd10;
    disk /dev/drbdvg/drbdlv;
    on node1 {
        address 1.2.3.4:12345;
        meta-disk internal;
    }
    on node2 {
        address 4.3.2.1:12345;
        meta-disk internal;
    }
}

    opensvc 服务配置文件/etc/opensvc/kvmdrbd.conf：

    root@node1# svcmgr -s kvmdrbd print config
[DEFAULT]
env = PRD
nodes = node1.acme.com node2.acme.com
id = 7a10881d-f4d3-1234-a2cd-e7a2018c4321
orchestrate = start

[disk#1]
type = lvm
vgname = {env.drbdvgname}
standby = true

[disk#2]
type = drbd
standby = true
shared = true
res = {svcname}

[fs#0]
mnt = {env.basedir}/{svcname}
type = ext4
dev = /dev/{env.drbddev}
shared = true

[container#0]
type = kvm
name = {svcname}
shared = true

[sync#i0]
schedule = @1440

[env]
basedir = /srv
drbddev = drbd10
drbdvgname = drbdvg

    一些解释：

    • 在我的设置中，我使用 drbd 复制 lvm lv。我在 drbd 块设备上创建了一个文件系统。在这个文件系统中，我为每个要呈现给 kvm 来宾的磁盘创建 1 个平面文件。
    • disk#1: 是承载大逻辑卷的 lvm vg。应至少为 5GB。
    • disk#2: 是 drbd 资源名称指向的 drbd 磁盘。如果 opensvc 服务被命名为“foo”，你应该有 /etc/drbd.d/foo.res。或者更改服务配置文件中的 disk#2.res 参数。
    • fs#0: 为 kvm 来宾托管所有磁盘文件的主文件系统
    • container#0：kvm 来宾，与示例中的 opensvc 服务同名。代理必须能够 dns 解析 kvm 来宾，在接受启动服务之前进行 ping 检查（如果 ping 应答，则 kvm 来宾已经在某个地方运行，启动它不是一个好主意。确保双启动保护通过 opensvc 代理）
    • standby = true: 表示当服务在另一个节点上运行时，此资源必须保持运行状态。在我们的示例中，需要保持 drbd 正常运行
    • shared = true：https ://docs.opensvc.com/latest/agent.service.provisioning.html#shared-resources
    • 2

  5. 我目前正在使用一个非常相似的系统。2 台服务器，一台活动服务器，一台备份服务器，它们都在其中运行了一些虚拟机。正在复制数据库，并且文件服务器与 rsync 保持同步（但只有一种方式）。在紧急情况下，正在为辅助服务器提供服务。有使用 Pacemaker 和 Corosync 的想法，但由于这必须是 100%，我没有勇气尝试。我的想法是 NginX 监视服务器。可以这样做，因为我正在使用 web 应用程序，但在你的情况下，我不知道你是否可以使用它。DRBD 对我来说是一团糟。以前的服务器正在使用它，虽然它看起来很有效，但感觉就像我在尝试解剖人体。

    看看这个，它可能对你有帮助：http: //jensd.be/156/linux/building-a-high-available-failover-cluster-with-pacemaker-corosync-pcs

    看起来并不难，其实在小环境下我已经尝试过并且工作了。易学、易制作、易维护。实际上，我认为这就是您要寻找的。

    • 0

相关问题