高可用性NFS与DRBD +心跳
Ryan Babchishin - http://win2ix.ca
本文档描述了在研究和开发集群DRBD NFS解决方案期间收集的信息。 这个项目有两个目的：
- 适用于Media-X Inc.的HA NFS解决方案
- 开发Win2ix可用于未来项目的标准工具包和文档
操作系统
Win2ix的标准操作是Ubuntu 12.04，因此所有测试都是以此作为首选目标。
硬件
由于即将推出的Media-X项目，基于低成本和低功耗选择了计算机硬件。
使用了一组相同的集群系统：
- SuperMicro SuperServer 5015A-EHF-D525（默认设置）
- Intel（R）Atom（TM）CPU D525 1.80GHz CPU（双核，超线程）
- 4GB DDR3 RAM
- 2x750GB 2.5“天蝎黑色硬盘
- 3ware 9650 RAID-1控制卡，128MB RAM，无需电池备份
- 2x板上千兆以太网
分区和磁盘格式
磁盘按照Win2ix标准进行分区。
- sda1 - / - ext4 - 20GB
- sda2 - / tmp - ext4 - 6GB
- sda3 - / var - ext4 - 6GB
- sdb5 - swap - swap - 2GB
- sda6 - drbd - drbd - 716GB
联网
- eth0配置有一个（未使用的）192.168.0。[1 | 2]地址，用于通过系统之间的直接链路进行通信，没有交换机
粘接测试，见下文了解更多信息。
- eth0 MTU为9000
- eth1配置了两个系统上的SSH / NFS / etc ...访问的常规网络IP地址
粘接
虽然由于缺少额外的PCI-Esocket而未使用，但以太网绑定最初是测试的
使用粘接时的重要注意事项：
- 要在两个方向上获得真正的单一连接负载平衡，请使用带有NO SWITCH的绑定模式0（循环），或者找到支持它的交换机。 系统之间的直接连接工作良好。 交换机通常支持中继，LACP或其他一些思科变体。 他们很可能只通过单独的链接发送不同IP连接的流量。 对于使用单一连接的DRBD，这不会有帮助
- 通过像iperf这样的测试，确保您在双向连接设备上看到完整的吞吐量
示例工作/ etc / network / interfaces配置段：
iface bond0 inet static address 192.168.0.1 netmask 255.255.255.0 bond-mode 0 bond-miimon 100 bond-slaves eth0 eth1
内核调优
这些sysctl变化似乎有一个小的改进，所以我把它们完好无损。 这需要添加到/etc/sysctl.conf 。
# drbd tuning net.ipv4.tcp_no_metrics_save = 1 net.core.rmem_max = 33554432 net.core.wmem_max = 33554432 net.ipv4.tcp_rmem = 4096 87380 33554432 net.ipv4.tcp_wmem = 4096 87380 33554432 vm.dirty_ratio = 10 vm.dirty_background_ratio = 4
DRBD
DRBD是棘手的。 尽管开发人员希望你想，它并不总是表现良好。
DRBD性能
- 我们的测试RAID控制器没有电池，但是有128MB的RAM
- 如果不禁用DRBD，DRBD将刷新所有写入磁盘或使用障碍。 这对于一致性很重要，但是磁盘没有被这样使用，并且在大多数情况下它不会表现良好。
- 如果您禁用所有刷新或屏幕，不用md-flush，无磁盘刷新，无磁盘障碍，DRBD性能将几乎是本机磁盘的速度。 但是，这意味着如果DRBD设备崩溃，电源出现等，DRBD设备更容易发生腐败...
- 如果您使用no-md-flush来禁用元数据刷新，则性能是合理的（约80％本机），您仍然可以获得一些安全性。 元数据冲洗会使性能如此糟糕，因此使用DRBD没有任何意义。
- 如果您有电池支持的RAID控制器，请禁用所有冲洗和障碍。 您将获得本机性能，不必担心数据损坏
- 可变速率同步非常好，因为它不会影响DRBD性能，并且在免费时将使用所有带宽
- use-rle是在最新版本中启用的性能调整是默认的，所以我打开它
- 应该启用基本的调整，如缓冲区，扩展盘等。 他们有很好的文件。
- 协议C似乎与A和B几乎相同（基于基准）。 协议C提供最大的保护。
- 我们的测试系统硬盘驱动器的写入速度与1Gb以太网传输速度非常相似。 如果使用更快的磁盘/阵列，DRBD需要更快的链接或绑定才能跟上写入。
工作实例
工作性能良好的DRBD资源配置
resource r0 {
net {
#on-congestion pull-ahead;
#congestion-fill 1G;
#congestion-extents 3000;
#sndbuf-size 1024k;
sndbuf-size 0;
max-buffers 8000;
max-epoch-size 8000;
}
disk {
#no-disk-barrier;
#no-disk-flushes;
no-md-flushes;
}
syncer {
c-plan-ahead 20;
c-fill-target 50k;
c-min-rate 10M;
al-extents 3833;
rate 35M;
use-rle;
}
startup { become-primary-on nfs01 ; }
protocol C;
device minor 1;
meta-disk internal;
on nfs01 {
address 192.168.0.1:7801;
disk /dev/sda6;
}
on nfs02 {
address 192.168.0.2:7801;
disk /dev/sda6;
}
}
/ etc / fstab与此配置相关的部分：
# DRBD, mounted by heartbeat /dev/drbd1 /mnt ext4 noatime,noauto,nobarrier 0 0
- ' nobarrier'在性能上（在我的测试系统上）有很大的不同，并且仍然保持着文件系统的完整性
- “ noatime”通过在每个读取的文件上禁用访问时间更新来缩小性能差异
- ' noauto'停止启动脚本（mount -a）来安装它 - 心跳将管理这个
标杆
在打扰NFS或其他任何事情之前，确保DRBD运行良好是一个好主意。
基准工具
- 在整个系统中，在一个屏幕上观察CPU负载，IO负载，IO吞吐量，网络吞吐量等，在两个系统上运行，以查看发生了什么
- iptraf - 详细的网络信息，吞吐量等，如果你需要进一步挖掘
- bonnie ++ - 执行许多IO基准测试，给出了实际磁盘性能的好主意。 必须使用至少比物理RAM大2倍的数据集才能准确
- 邮戳 - 非常适合重载系统，执行许多小写/读/追加，目录创建等...有利于在一切正常情况下测试NFS性能。 给每个测试类型的操作/秒性能结果
- dd - 基本，初始基准 - 见dd部分
DD
您可以使用一些简单的测试来测试使用DD的存储设备的性能。 然而，其他工具应该稍后用于更准确的结果（现实世界）。 当我进行基准测试或尝试识别瓶颈时，我在单独的终端上运行在同一个系统上，而dd正在传输数据。
- 使用直接访问顺序写入文件系统（不适用于所有文件系统）
dd if=/dev/zero of=testfile bs=100M count=20 oflag=direct
- 使用常规访问顺序写入文件系统，并在退出之前进行刷新
dd if=/dev/zero of=testfile bs=100M count=20 conv=fsync
- 使用直接访问从文件系统顺序读取从文件系统顺序读取（不适用于所有文件系统）
dd if=testfile of=/dev/null bs=100M iflag=direct
- 使用常规访问从文件系统顺序读取。 在执行此操作之前删除系统缓存，或者您可能只是从缓存中读取该文件
dd if=testfile of=/dev/null bs=100M
- 删除系统缓存
sync
echo 3 > /proc/sys/vm/drop_caches
- 直接写入块设备，绕过文件系统。 这将破坏块设备上的数据
dd if=/dev/zero of=/dev/sdXX bs=100M count=20 oflag=direct
- 直接从块设备读取，绕过文件系统
dd if=/dev/sdXX of=/dev/null bs=100M count=20 oflag=direct
NFS服务器
唯一的配置是' / etc / exports' ：
/mnt 192.168.3.0/24(rw,async,no_subtree_check,fsid=0)
- ' 异步'我发现这个特定的设置通过异步而不是同步来表现得更好（50％）
- ' fsid = 0'是在HA解决方案中使用的好东西。 如果所有节点对相同的安装使用相同的ID＃（这是微不足道），故障转移后将会避免过时的句柄。
在使用NFSv4（在客户端和/或服务器端）上可能需要调整' /etc/idmapd.conf'以匹配您的域，
NFS客户端
在测试中，我选择使用此命令挂载NFS：
mount nfs:/mnt /testnfs -o rsize=32768,wsize=32768,hard,timeo=50,bg,actimeo=3,noatime,nodiratime
说明：
- rsize / wsize - 将读取和写入最大块大小设置为32k，适合客户数据的平均文件大小
- 硬进程访问NFS共享，当它不可用时阻止，除非用SIGKILL杀死
- noatime - 每次读取文件时，不要更新文件访问时间
- nodiratime - 像noatime，但目录
- bg - 在后台继续NFS挂载，而不是阻塞 - 主要是为了防止启动问题
- tcp - 没有指定，因为它是一个默认值 - 如果使用udp，数据可能在故障转移期间丢失，tcp将继续尝试
- 5秒钟后重试NFS请求（在10秒钟内指定）
聚类
心跳没有Pacemaker被选中。 Pacemaker似乎太复杂，难以管理所需要的。
心跳
这个测试设置，心跳有两个以太网连接在节点之间进行通信。 第一个是网络/子网/ lan连接，另一个是DRBD直接交叉链路。 拥有多个连接路径很重要，因此一个心跳节点不会与另一个心跳节点失去联系。 一旦发生这种情况，两者都不知道哪个是主，并且集群变得“ 分裂” 。
STONITH
STONITH = 拍摄头上的其他节点
STONITH是Heartbeat用于重新启动未响应的集群节点的功能。 这是非常重要的，因为心跳需要知道另一个节点不使用DRBD（或其他可腐败的资源）。 如果一个节点真的没有响应，另一个节点将使用STONITH重新启动它，它使用IPMI（在下面的示例中），然后接管资源。
当两个节点认为他们是主人（拥有资源）时，它被称为裂脑。 这可能会导致问题，有时会导致数据损坏。 与IPMI的STONITH可以防止这种情况。
工作实例
- 创建下面的配置文件
- 安装心跳（如果可能，从存储库）
- 启动logd
- 开始心跳
ha.cf文件定义了集群以及它的节点如何交互。
/etc/ha.d/ha.cf ：
# Give cluster 30 seconds to start initdead 30 # Keep alive packets every 1 second keepalive 1 # Misc settings traditional_compression off deadtime 10 deadping 10 warntime 5 # Nodes in cluster node nfs01 nfs02 # Use ipmi to check power status and reboot nodes stonith_host nfs01 external/ipmi nfs02 192.168.3.33 ADMIN somepwd lan stonith_host nfs02 external/ipmi nfs01 192.168.3.34 ADMIN somepwd lan # Use logd, configure /etc/logd.cf use_logd on # Don't move service back to preferred host when it comes up auto_failback off # If all systems are down, it's failure ping_group lan_ping 192.168.3.1 192.168.3.13 # Takover if pings (above) fail respawn hacluster /usr/lib/heartbeat/ipfail ##### Use unicast instead of default multicast so firewall rules are easier # nfs01 ucast eth0 192.168.3.32 ucast eth1 192.168.0.1 # nfs02 ucast eth0 192.168.3.31 ucast eth1 192.168.0.2
haresources文件描述了群集提供的资源。 它的格式是： [首选节点] [第一个服务] [第二个服务] ...服务按照它们被列出的顺序启动，并以相反的顺序停止。 如果可能，它们将在首选节点上启动。
/etc/ha.d/haresources ：
nfs01 drbddisk::r0 Filesystem::/dev/drbd1::/mnt::ext4 IPaddr2::192.168.3.30/24/eth0 nfs-kernel-server
logd.conf文件定义心跳记录。
/etc/logd.conf ：
debugfile /var/log/ha-debug logfile /var/log/ha-log syslogprefix linux-ha
测试失败
有许多测试可以执行。 尝试在拉电缆的同时ping起浮动IP地址，启动心跳消除，使用SIGKILL等杀死心跳...但是我最喜欢的测试是NFS服务，这是最重要的部分。 / var / log / ha-debug将有很多关于在测试期间做什么心跳的细节。
测试NFS故障转移
- 从另一个系统中，从集群安装NFS共享
- 使用rsync --progress -av开始将大文件（1-2 GB）复制到共享
- 当进度为20％-30％时，从主动节点拉出网线
- 由于NFS阻塞，Rsync将锁定（如预期）
- 5-10秒后，文件应继续传输，直到完成，没有错误
- 对原始文件和NFS共享文件进行md5校验和比较
- 这两个文件应该是一样的，如果没有的话，那就是腐败
- 通过从NFS读取再次尝试测试，而不是写入它
