情况：设置负载均衡器
目前，我们的数据中心有成对的所有服务器（运行 CentOS Linux）：每个服务器都有一个镜像服务器。我们目前不使用任何负载平衡，因此 serverA 获取所有流量，当它出现故障（硬件或软件）时，我们可以通过在 serverB 上配置 serverA IP 地址来快速切换到 serverB。我们正在使用 MySQL 主/主复制（尽管我们可以简单地使用主/从复制进行当前设置）和 rsync 来保持 vhost 文件同步（serverA 同步到 serverB）。
这对我们来说效果很好，但效率很低，因为我们有 50% 的硬件在机器出现故障之前什么都不做。我们正在考虑在服务器对之前放置负载均衡器，这样我们就可以将负载分摊到两台机器上，并为每个集群添加额外的服务器。
问题：共享文件存储
设置它可能只需要在每个服务器对前面放置一个负载平衡器，然后让它将流量分配到该对中的每个服务器。除了一件事：文件存储。当前 rsync 将更改从 serverA“推送”到 serverB，但不是相反。我们可以设置它，以便 rsync 也从 serverB 运行到 serverA，但问题是 rsync 永远不知道是创建还是删除存在于 serverA 但不在 serverB 上的文件。我查看了Unison，但该项目似乎已停止。
问题：基于软件的共享文件存储的最佳解决方案是什么？
So, I'm looking for a different solution. Please mind that I don't want to add more hardware (so no NAS/SAN solution). Also mind that we need a low amount of storage (below 500GB) per cluster and that …
我有一个场景，DRBD-heartbeat 设置有一个失败的节点但没有故障转移。发生的情况是主节点已锁定，但没有直接关闭（无法通过 ssh 或 nfs 挂载访问，但可以 ping 通）。期望的行为是检测到这一点并将故障转移到辅助节点，但似乎由于主节点没有完全关闭（从服务器到服务器有专用网络连接），心跳的检测机制没有启动在那，因此没有故障转移。
有没有人看到这个？是否需要配置一些东西才能拥有更强大的集群故障转移？DRBD 似乎在其他方面工作正常（当我重新启动旧主时必须重新同步），但没有良好的故障转移，它的使用是有限的。
nfs03 是此设置中的主服务器，nfs01 是辅助服务器。
比照
# Hearbeat Logging
logfacility daemon
udpport 694
ucast eth0 192.168.10.47
ucast eth0 192.168.10.42
# Cluster members
node nfs01.openair.com
node nfs03.openair.com
# Hearbeat communication timing.
# Sets the triggers and pulse time for swapping over.
keepalive 1
warntime 10
deadtime 30
initdead 120
#fail back automatically
auto_failback on
这是 haresources 文件：
nfs03.openair.com IPaddr::192.168.10.50/255.255.255.0/eth0 drbddisk::data Filesystem::/dev/drbd0::/data::ext4 nfs nfslock
我已经用 OCFS2 替换了在双主模式下运行的死节点。所有步骤都有效：
/proc/drbd
version: 8.3.13 (api:88/proto:86-96)
GIT-hash: 83ca112086600faacab2f157bc5a9324f7bd7f77 build by mockbuild@builder10.centos.org, 2012-05-07 11:56:36
1: cs:Connected ro:Primary/Primary ds:UpToDate/UpToDate C r-----
ns:81 nr:407832 dw:106657970 dr:266340 al:179 bm:6551 lo:0 pe:0 ua:0 ap:0 ep:1 wo:b oos:0
直到我尝试挂载卷：
mount -t ocfs2 /dev/drbd1 /data/webroot/
mount.ocfs2: Transport endpoint is not connected while mounting /dev/drbd1 on /data/webroot/. Check 'dmesg' for more information on this error.
/var/log/kern.log
kernel: (o2net,11427,1):o2net_connect_expired:1664 ERROR: no connection established with node 0 after 30.0 seconds, giving up and returning errors.
kernel: (mount.ocfs2,12037,1):dlm_request_join:1036 ERROR: status …我有两个网络服务器，每个网络服务器都附加了一个磁盘。该磁盘drbd在“双主”模式下使用(2:8.3.13-1.1ubuntu1) 在它们之间同步，并且在此之上我将ocfs2(1.6.4-1ubuntu1) 作为集群文件系统运行。节点在专用网络上进行通信192.168.3.0/24。在大多数情况下，这是稳定的，并且运行良好。
昨晚，似乎出现了网络中断。这导致了一个裂脑场景，其中 node01 留在Standalone和 中Primary，而 node02 留在WFConnection和 中primary。恢复是今天早上手动区分两个文件系统的过程，决定 node01 应该是权威的，将 node02 放入辅助drbdadm connect节点，然后在每个节点上发出命令。在此之后重新挂载文件系统，我们就可以备份并运行了。
我的问题是：这种类型的中断是否总是需要手动解决？或者有什么方法可以使这个过程自动化？我的理解是，drbd 应该在出现关于确定哪个节点应该成为主要和次要节点的脑裂的情况下变得聪明。似乎在这种情况下，一个简单的网络中断在主服务器中留下了，我的配置只是说“断开连接”。查看日志，我发现有趣的是，他们似乎都同意node02应该是 SyncSource，但在查看 rsync 日志时，它实际上node01是最新的更改。同样有趣的是关于node01“我将成为 SyncTarget，但我是主要的！”这一行。对我来说，看起来 drbd 试图解决这个问题，但由于某种原因失败了。
有没有更好的方法来做到这一点？
配置r0是这样的：
resource r0 {
meta-disk internal;
device /dev/drbd0;
disk /dev/xvda2;
syncer { rate 1000M; }
net {
#We're running ocfs2, so two primaries desirable.
allow-two-primaries;
after-sb-0pri discard-zero-changes;
after-sb-1pri discard-secondary;
after-sb-2pri disconnect;
} …有没有人有使用 DRBD（协议 C）同步 2 台 esxi 主机的部分数据存储以对选定来宾进行灾难恢复的经验？
我有 2-3 个来宾，它们应该能够在尽可能短的时间内从主机的硬件故障中恢复，但仍然需要人工干预并且不会丢失太多数据。
我想构建这样的东西：
2 台 esxi 主机上的每台 1 DRBD VM 同步其本地 SAS 存储（主要/次要、主动/被动）。
此镜像存储应一次仅通过 ISCSI 或 NFS 连接到 1 个 esxi 主机，并用于这些来宾使其 vmdks 同步到第二个“被动”esxi 主机。如果发生硬件故障，第二台 esxi 主机应连接 DRBD 存储以启动这些虚拟机（当然是手动完成的）。
我在网上找到了一些关于这样做的信息，但我没有找到任何信息是 vmdks 的一致性。
虽然这当然不是备份的替代品，但虚拟机管理程序的备份工具通常会确保来宾的文件系统和数据库在拍摄快照或备份之前处于停顿状态。
但是，通过这种连续同步，这是不可能的。这就是为什么我想知道这是否值得做。
如果 vmdks 本身由于硬件故障发生在错误的时间而损坏怎么办。我知道 DRBD 会丢弃不完整的写入，但这是否足以让 vmdk 保持一致（从 esxi 的角度来看，意味着“工作”，除了来宾文件系统一致性，当然不能以这种方式保证）？
我希望，在发生崩溃的情况下，在第二个 esxi 上出现的来宾可以表现得好像 VM 只是不正常地关闭了（在其他情况下这通常可能具有所有可能的缺点），但这真的是案件？vmdks 不会整体损坏吗？
非常感谢您的阅读和您的想法。
最大限度
disaster-recovery synchronization drbd hypervisor vmware-esxi
我的集群中有两个带有 drbd+pacemaker+corosync 的节点当第一个节点出现故障时，第二个节点会承担服务并且没问题，但是当我们必须进行故障回复（节点 1 重新联机）时，它会显示一些错误并且集群停止工作。
这是一个 CentOS 6 集群，内核为 2.6.32-504.12.2.el6.x86_64 和这些包：
kmod-drbd83-8.3.16-3、drbd83-utils-8.3.16-1、corosynclib-1.4.7-1、corosync-1.4.7-1、pacemaker-1.1.12-4、pacemaker-cluster-libs- 1.1.12-4、pacemaker-libs-1.1.12-4、pacemaker-cli-1.1.12-4。
Drbd 配置：
resource r0
{
startup {
wfc-timeout 30;
outdated-wfc-timeout 20;
degr-wfc-timeout 30;
}
net {
cram-hmac-alg sha1;
shared-secret sync_disk;
max-buffers 512;
sndbuf-size 0;
}
syncer {
rate 100M;
verify-alg sha1;
}
on XXX2 {
device minor 1;
disk /dev/sdb;
address xx.xx.xx.xx:7789;
meta-disk internal;
}
on XXX1 {
device minor 1;
disk /dev/sdb;
address xx.xx.xx.xx:7789;
meta-disk internal;
}
}
同步：
compatibility: whitetank
totem {
version: 2
secauth: …我正在考虑在 AWS (EC2) 基础设施上设置一个共享文件系统/文件服务器，以提供复制和相当轻松的故障转移。这个文件系统可能会承载数百万个大小为几兆的文件。将从多个客户端 VM 访问（读/写）这些文件。如果主文件服务器出现故障，我希望客户端能够在不丢失任何文件的情况下故障转移到副本文件服务器（即我希望复制是实时的）。我查看了几个选项：
有没有更好的解决方案？
我的 Debian 8.9 DRBD 8.4.3 设置不知何故进入了两个节点无法再通过网络连接的状态。他们应该复制单个资源r1，但紧接着drbdadm down r1; drbadm up r1在两个节点上他们/proc/drbd描述的情况如下：
在第一个节点上（连接状态为WFConnection或StandAlone）：
1: cs:WFConnection ro:Primary/Unknown ds:UpToDate/DUnknown C r-----
ns:0 nr:0 dw:0 dr:912 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:f oos:20
在第二个节点上：
1: cs:StandAlone ro:Secondary/Unknown ds:UpToDate/DUnknown r-----
ns:0 nr:0 dw:0 dr:0 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:f oos:48
两个节点可以通过 中引用的 IP 地址相互 ping 通/etc/drbd.d/r1.res，并netstat显示两者都在引用的端口上进行侦听。
我如何（进一步诊断和）摆脱这种情况，以便两个节点可以连接并再次通过 DRBD 进行复制？
顺便说一句，在更高的抽象层次上，这个问题目前通过systemctl start drbd永不退出表现出来，显然是因为它被卡在了 …
我有一个 DRBD 集群，其中一个节点关闭了几天。单节点运行良好，没有出现任何问题。当我打开它时，我遇到了一种情况，所有资源都停止了，一个 DRBD 卷是辅助卷，其他卷是主要卷，因为它似乎试图对刚刚打开的节点执行角色交换（ha1 处于活动状态，然后我打开 ha2）为了便于理解日志，在 08:06）
我的问题：
下面是我能想象到的所有可能有用的信息。
bash-5.1# cat /proc/drbd
version: 8.4.11 (api:1/proto:86-101)
srcversion: 60F610B702CC05315B04B50
0: cs:Connected ro:Secondary/Primary ds:UpToDate/UpToDate C r-----
ns:109798092 nr:90528 dw:373317496 dr:353811713 al:558387 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:f oos:0
1: cs:Connected ro:Primary/Secondary ds:UpToDate/UpToDate C r-----
ns:415010252 nr:188601628 dw:1396698240 dr:1032339078 al:1387347 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:f oos:0
2: cs:Connected ro:Primary/Secondary ds:UpToDate/UpToDate C r-----
ns:27957772 nr:21354732 dw:97210572 dr:100798651 al:5283 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:f oos:0
集群状态最终为
bash-5.1# …我已经通读了http://www.drbd.org/users-guide/ch-internals.html#s-meta-data-size提供的文档来建立 DRBD 元大小，但我正在努力关联实际磁盘大小和文件系统大小。
有没有一种方法可以检索扇区中的文件系统大小（以及块设备），以获得元数据的正确值。