我正在研究在AWS（EC2）基础架构上设置共享文件系统/文件服务器，该服务器提供复制和相当轻松的故障转移。 这个文件系统可能会承载数百万个大小只有几百万的文件。 这些文件将被从几个客户端虚拟机访问（读/写）。 如果主文件服务器失败，我希望客户端能够故障转移到副本文件服务器，而不会丢失任何文件（即我想复制实时）。 我看了几个选项： 使用S3和s3fs。 我担心在数千个文件上执行操作时（例如，当复制/移动文件时），每个请求的延迟都会有问题。 我也听到一些报告，让我质疑s3fs的稳定性 – 不知道是否仍然如此。 在EC2实例上安装NFS服务器，使用drbd在两个实例之间复制块。 缺点： 在过去，我遇到了drbd的可靠性问题，特别是高延迟链接 如果主NFS服务器出现故障，则它将取下客户端，要求系统pipe理员进行干预和/或重新启动以使其重新连接到辅助服务器。 没有自动故障切换。 有没有更好的解决scheme？
首先，我不是Linux专家，我一直在跟随教程，并一直在谷歌的帮助下，这工作到现在为止罚款，但目前我坚持一个问题。 我正在使用CentOS 6.5和DRBD 8.4.4版。 我有两个运行起搏器的节点，到目前为止一切正常，我build立了DRBD，我可以手动将一个节点设置为主节点，并安装DRBD资源，这样也可以工作。 现在我创build了一个起搏器资源来控制DRBD，但是它并没有促使两个节点中的任何一个节点掌握这个节点，这也阻止了它的安装。 个人电脑状态如下所示： Cluster name: hydroC Last updated: Wed Jun 25 14:19:49 2014 Last change: Wed Jun 25 14:02:25 2014 via crm_resource on hynode1 Stack: cman Current DC: hynode1 – partition with quorum Version: 1.1.10-14.el6_5.3-368c726 2 Nodes configured 4 Resources configured Online: [ hynode1 hynode2 ] Full list of resources: ClusterIP […]
情况：build立一个负载均衡器 目前我们所有的服务器（运行CentOS Linux）在我们的数据中心都是成对的：每台服务器都有一台镜像服务器。 目前我们没有采用任何负载均衡，所以serverA获取所有stream量，当发生故障时（硬件或软件），我们可以通过在serverB上configurationserverA IP地址来快速切换到serverB。 我们正在使用MySQL主/主复制（尽pipe我们可以简单地使用主/从复制进行当前设置）和rsync保持同步的vhost文件（serverA同步到serverB）。 这对我们来说工作的很好，但是效率很低，因为我们有50％的硬件在机器出现故障之前什么也不做。 我们正考虑在服务器对之前安装负载平衡器，这样我们就可以将负载分配到两台机器，并为每个群集添加额外的服务器。 问题：共享文件存储 设置它可能不会比将负载均衡器放在每个服务器对前面，然后将stream量分配给每个服务器对中的每个服务器。 除了一件事：文件存储。 目前rsync“推”从serverA到serverB的变化，但不是相反。 我们可以设置它，使rsync也从serverB运行到serverA，但问题是，rsync永远不知道是否创build或删除serverA上存在的文件，而不是serverB上的文件。 我看着Unison ，但是这个项目似乎已经停止了。 问题：基于软件的共享文件存储的最佳解决scheme是什么？ 所以，我正在寻找一个不同的解决scheme。 请注意，我不想添加更多的硬件（所以没有NAS / SAN解决scheme）。 另外请注意，我们需要每个群集less量的存储（低于500GB），并且所有服务器都在同一个本地networking上。 我们有一个体面的备份解决scheme（备份每3小时运行一次）。 我一直在看DRBD ，这似乎很适合我们的情况，但我没有经验。 DRBD是我们走的路吗？ 请分享您与这个和其他类似的解决scheme的经验。 任何想到的陷阱？ 我在正确的轨道上？ 请赐教:)
我用OCFS2replace了一个以双主模式运行的死节点。 所有的步骤工作： /proc/drbd version: 8.3.13 (api:88/proto:86-96) GIT-hash: 83ca112086600faacab2f157bc5a9324f7bd7f77 build by [email protected], 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 […]
我有一个服务器，通过NFS导出主目录。 它们位于软件RAID1（/ dev / sdb和/ dev / sdc）上，操作系统位于/ dev / sda上。 我注意到，由top和sar报告的%iowait相对较高（与其他服务器相比）。 这个值的范围在5-10％之间，其他服务器（比这个负载更多）与0-1％相同。 当%iowait达到12％以上的值时，所谓的用户体验下降。 然后我们遇到延迟。 我在日志中没有任何驱动器错误。 我想避免使用反复试验方法来使用硬盘。 如何找出哪个设备（/ dev / sda，/ dev / sdb或/ dev / sdc）是瓶颈？ 谢谢！ 编辑：我使用Ubuntu 9.10，已经安装了iostat 。 我对NFS相关的问题不感兴趣，但更多的是如何find哪个设备减慢系统。 NFS没有加载，我有32个线程可用，结果 grep th /proc/net/rpc/nfsd th 32 0 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 编辑2：这是iostat -x 1输出的一部分（我希望我没有违反这里的一些规则）： avg-cpu: %user %nice […]
是否有人使用DRBD（协议C）同步部分2个esxi主机的数据存储以便选定的guest虚拟机进行灾难恢复？ 我有2-3位客人可以在尽可能短的时间内从主机的硬件故障中恢复，但仍然需要人工干预，而且不会丢失太多的数据。 我想build立这样的事情： 1台同步SAS本地存储（主/从，主动/被动）的esxi主机上的每个DRBD VM。 这个镜像存储应该只通过ISCSI或者NFS连接到一个esxi主机上，并且用于这些guest虚拟机使他们的vmdks同步到第二个被动的esxi主机。 在发生硬件故障的情况下，第二台esxi主机应该连接DRBD存储，以启动这些虚拟机（当然手动完成）。 我已经find了关于在networking上做这个的一些信息，但是我没有find任何信息是vmdks的一致性。 虽然这当然不能代替备份，但是pipe理程序的备份工具通常会确保客户的文件系统和数据库在进行快照或备份之前处于停顿状态。 有了这个连续同步，这是不可能的。 这就是为什么我怀疑这是否值得去做的原因。 如果由于发生硬件故障而导致vmdks本身受损，该怎么办？ 我知道DRBD丢弃了不完整的写入，但这足以保证一致（esxi的观点，除了来宾文件系统的一致性，这当然不能保证这种方式的意义“工作”）vmdk？ 我希望在发生崩溃的时候，第二个esxi上的一个客户可能会像虚拟机不正常closures一样（在其他情况下可能会有所有可能的缺陷），但是真的是这样案件？ 整个vmdks不能被破坏吗？ 非常感谢您的阅读和您的想法。 马克斯
我想在两个节点上的drbd8顶部共享文件系统。 服务器运行Ubuntu 9.10。 我GOOGLE了很多，但无法find一个明确的趋势什么networking社区喜欢。 目前看来OCFS2更多用了。 哪个文件系统更可靠，更快？ GFS2或OCFS2？ Linux社区是更多地走向GFS2或OCFS2？ 哪两个更好的支持Ubuntu 9.10？ 有更好的（或更常见的）select吗？
我看到DRBD的性能比用户手册说的要大得多。 我正在使用DRBD 8.3.7（Fedora 13 RPMs）。 我已经设置了DRBDtesting，并测量了没有DRBD的磁盘和networking的吞吐量： dd if=/dev/zero of=/data.tmp bs=512M count=1 oflag=direct 536870912 bytes (537 MB) copied, 4.62985 s, 116 MB/s /是我正在testing的磁盘上的逻辑卷，安装时没有DRBD iperf的： [ 4] 0.0-10.0 sec 1.10 GBytes 941 Mbits/sec 根据吞吐量开销的预期 ，瓶颈将是较慢的，networking或磁盘和DRBD应该有3％的开销。 在我的情况下，networking和I / O似乎相当匹配。 这听起来像我应该能够达到100 MB /秒左右。 所以，用原始的drbd设备，我得到了 dd if=/dev/zero of=/dev/drbd2 bs=512M count=1 oflag=direct 536870912 bytes (537 MB) copied, 6.61362 s, 81.2 MB/s […]
这是我的drbdconfiguration resource mysql { protocol C; floating 10.100.101.1:7788 { device /dev/drbd0; disk /dev/VolGroup00/LogVol02; meta-disk internal; } floating 10.100.101.2:7788 { device /dev/drbd0; disk /dev/VolGroup01/LogVol02; meta-disk internal; } } 两个节点上的LVM上的磁盘设置为50G，我在两个节点+ 4G（现在总共54G）上增加了LVM， 但是当我尝试运行 [root@db1 ~]# resize2fs /dev/VolGroup00/LogVol02 resize2fs 1.39 (29-May-2006) resize2fs: Device or resource busy while trying to open /dev/VolGroup00/LogVol02 Couldn't find valid filesystem superblock. [root@db1 ~]# 它说我不能。 […]
我已经在2个节点上build立了DRBD，并且在昨天开始使用它。 大约一个小时后，它重新分区了50％。 又过了12个小时，达到了79％，移动速度非常缓慢。 以下是cat / proc / drbd显示的内容： 1: cs:SyncTarget ro:Primary/Secondary ds:Inconsistent/UpToDate C r—– ns:464931976 nr:191087032 dw:656013660 dr:214780588 al:100703 bm:21100 lo:7 pe:0 ua:0 ap:7 ep:1 wo:f oos:92241852 [==============>…..] sync'ed: 79.2% (90076/431396)M finish: 76:13:38 speed: 332 (8,680) want: 19,480 K/sec 我查看了networkingstream量，并且在1G接口上使用了1M到20M。 在这一切正在进行的时候，试图运行iperf，我得到了930M的阅读。 试图调整同步率到10M，50M，500M无济于事。 调整包的大小，但没有运气。 现在，从状态中可以看出，我的主要节点是不一致的。 所以我假设操作系统在重新同步的时候本质上是一个辅助节点。 但是由于吞吐量如此之低，我不明白为什么同步不会更快。 任何想法，我可以尝试下一个？ 预计完成76小时是不是我期待的:(特别是不知道原因，所以来了一个停机，我不知道如何使arrays快速一致。 谢谢！ 编辑：我尝试在净节以下设置无济于事： sndbuf-size 512k; max-buffers 20480; max-epoch-size […]