03 Drbd注意事项
对现有资源的配置文件进行修改,两个对等节点要保持一致,然后执行 drbdadm adjust <resource> 在两个节点上都要执行;
(验证算法:MD5、SHA-1、CRC-32C) 此特性针对在复制过程中由于网络传输原因导致的数据不一致。 DRBD对每个要复制的块生成一个校验和(摘要信息),用来对peer端数据进行完整性校验,如果接收到的块的校验和与source端的校验和不一致,将会要求重传。
resource <resource>
net {
data-integrity-alg <algorithm>;
}
...
}
(这个对性能还是有很大影响的)
如果我们不在传输过程中对数据进行校验,我们仍然可以采用在线设备验证的方式,原理同上,我们可以采用定时任务周期性的对数据进行验证。默认情况下在线设备验证是未启用的,可以在配置文件/etc/drbd.conf添加。
它通过验证源对每个底层的设备某一资源的块存储设备一次计算出加密摘要,传输到对等节点,对摘要对应的本地副本块进行验证,若不匹配,则进行标识并进行重新同步,在线验证过程中不会阻塞资源的复制,不会造成系统的中断;
操作方式:配置文件中修改,也可以配置到common区块,对所有资源都适用
resource <resource> {
net{
verify-alg <algorithm> # 例如:verify-alg sha1;
}
}
验证命令:
drbdadm verify <resource>
在验证运行时,如果出现out-of-sync 块,那需要在验证完毕之后使用:
drbdadm disconnect <resource>
drbdadm connect <resource>
这个方式用的还是少,不过可以配置为每周,或者每个月进行一次校验;
总的来说还是适合就好,大致取决于磁盘的转速和网卡的IO,后台带宽被占满影响复制,影响程序; 比较好的大小是,可用带宽和磁盘IO较小值的30% 。
可以根据网络带宽或网络资源状况配置同步速率以及使用临时速率,可变速率等。同步速率设置的超过网络的最大可用带宽也是没有任何意义的。
根据经验同步速率比较合理的是可用带宽的 30%。
计算公式: MIN(I/O子系统,网络I/O)*0.3
假定一个 I/O 子系统能支持 180MB/s 的吞吐量, 而千兆网络可支持 110MB/s,
此时网络带宽会成为瓶颈,可以计算出,同步速率:110*0.3=33MB/s
假定一个 I/O 子系统能支持 80MB/s 的吞吐量,而千兆网络可支持 110MB/s,
此时磁盘I/O会成为瓶颈,可以计算出,同步速率:80*0.3=24MB/s
请注意,同步的速率是 bytes 字节,而不是 bits/s。
固定的同步速率:
resource <resource>
disk {
sync-rate 40M;
}
临时调整速率:
在预期维护之后加快同步这样的时候可能会用到:
drbdadm disk-options --resync-rate=200M <resource>
若要恢复到原先的同步速率: drbdadm adjust <resource> 在两个node执行
resource <resouce>{
disk {
on-io-error <strategy>;
}
}
磁盘出现IO错误时候,我们应该采用何种策略呢?
DRBD提供三种策略,分别是: detach 、 pass_on 、 call-local-io-error。
- detach:分离,这是默认和推荐的选项。如果在节点上发生底层的磁盘 I/O 错误,它会将设备运行在 diskless 无盘模式下。所有的对节点的读写将会从对端节点进行,这种情况下虽然性能有所下降,但是仍然可以提供服务,很明显在高可用的情况下,这个策略使我们的首选。
- pass_on : drbd 会将错误报告到上层,即文件系统,但是往往会被忽略;
- local-io-error :调用本地磁盘IO处理程序中定义的命令;需要 local-io-error 定义处理错误的命令;
只要磁盘控制器支持DRBD刷写磁盘即可(大部分还是支持的), 在含有BBC的RAID环境中,可以禁用DRBD磁盘刷写功能来获得更高的性能;
resource <resource>
disk {
disk-flushes no;
...
}
handlers { split-brain "/usr/lib/drbd/notify-split-brain.sh root"; ... }
大部分情况下还是手动来修复:
after-sb-0pri:裂脑已经被探测到,但是现在没有节点处于主角色,对于这个选项,drbd有以下关键字:
- disconnect:不需要自动恢复,仅仅是调用裂脑处理程序的脚本(如果配置了),断开连接并出在断开模式。
- discard-younger-primary:放弃和回滚最后成为主的上面所做的修改。
- discard-least-changes:放弃和回滚,变动比较少的主机上的修改。
- discard-zero-changes:如果任何节点都没有发生任何变化,仅仅申请在一个节点上做出继续修改即可。
after-sb-1pri:裂脑已经被探测到,现有有一个节点处于主角色,对于这个选项,drbd有以下关键字:
- disconnect:和after-sb-0pri一样,调用裂脑处理程序的脚本(如果配置了),断开连接并出在断开模式。
- consensus:和after-sb-0pri中同样的修复策略。如果利用这些策略裂脑危害能选择,那就能自动解决。否则,同样断开指定的动作。
- call-pri-lost-after-sb:和after-sb-0pri中同样的修复策略。如果利用这些策略裂脑危害能选择,就在受危害的节点上调用pri-lost-after-sb程序。这个程序必须确认在handlers中配置,并考虑到从集群中移除该节点。
- discard-secondary:不管哪个主机只要处于次角色,都是裂脑的危害者。
after-sb-2pri:在两个节点都处于主角色时,裂脑被发现。次选项使用和after-sb-1pri同样的关键字,丢弃次节点并达成共识
过期数据不是不一致性数据,只是说secondary不再与priamry同步数据了, secondary相当于是一个snapshot,这时候如果发生切换,那么可想而知,数据的一致性就会出现问题,我们需要通过某些策略来防止这种情况的发生:当出现过期数据的时候, drbd的连接状态将会由connect变为Wfconnection,这时候Pacemaker不会允许过期数据的节点提升为primary。
对于一些网络状态不好的情况,如果我们采用协议C进行复制,那么数据复制延时将会很严重,这时候我们可以采用暂停复制的策略,这样当网络状况不好的时候, primary端将会暂停复制,primary和secondary将会处于链式的不同步状态,当带宽变为可用的时候,复制将会继续进行。
当遇到我们的drbd resource设备容量不够的时候,而且我们的底层设备支持在线增大容量的时候(比如使用lvm的情况下),我们可以先增大底层设备的大小,然后再通过drbdadm resize resource_name来实现对resource的扩容。但是这里有一点需要注意的就是只有在单primary模式下可以这样做,而且需要先在所有节点上都增大底层设备的容量。然后仅在primary节点上执行resize命令。在执行了resize命令后,将触发一次当前primary节点到其他所有secondary节点的re-synchronization。
如果我们在drbd非工作状态下对底层设备进行了扩容,然后再启动drbd,将不需要执行resize命令(当然前提是在配置文件中没有对disk参数项指定大小),drbd自己会知道已经增大了容量。
在进行底层设备的增容操作的时候千万不要修改到原设备上面的数据,尤其是drbd的meta信息,否则有可能毁掉所有数据。
容量收缩比扩容操作要危险得多,因为该操作更容易造成数据丢失。在收缩resource的容量之前,必须先收缩drbd设备之上的容量,也就是文件系统的大小。如果上层文件系统不支持收缩,那么resource也没办法收缩容量。
如果在配置drbd的时候将meta信息配置成internal的,那么在进行容量收缩的时候,千万别只计算自身数据所需要的空间大小,还要将drbd的meta信息所需要的空间大小加上。
当文件系统收缩好以后,就可以在线通过以下命令来重设resource的大小:drbdadm — –size=***G resize resource_name。在收缩的resource的大小之后,你就可以自行收缩释放底层设备空间(如果支持的话)。
如果打算停机状态下收缩容量,可以通过以下步骤进行:
a、在线收缩文件系统
b、停用drbd的resource:drbdadm down resourcec_name
c、导出drbd的metadata信息(在所有节点都需要进行):drbdadm dump-md resource_name > /path_you_want_to_save/file_name
d、在所有节点收缩底层设备
e、更改上面dump出来的meta信息的la-size-sect项到收缩后的大小(是换算成sector的数量后的数值)
f、如果使用的是internal来配置meta-data信息,则需要重新创建meta-data:drbdadm create-md resource_name
g、将之前导出并修改好的meta信息重新导入drbd(摘录自linbit官方网站的一段导入代码):
drbdmeta_cmd=$(drbdadm -d dump-md test-disk)
${drbdmeta_cmd/dump-md/restore-md} /path_you_want_to_save/file_name
h、启动resource:drbdadm up resource_name
1、detach resource
如果在resource的disk配置项中配置了on_io_error为pass_on的话,那么drbd在遇到磁盘损坏后不会自己detach底层设备。也就是说需要我们手动执行detach的命令(drbdadm detach resource_name),然后再查看当前各节点的ds信息。可以通过cat /proc/drbd来查看,也可以通过专有命令来查看:drbdadm dstat resource_name。当发现损坏的那方已经是Diskless后,即可。如果我们没有配置on_io_error或者配置成detach的话,那么上面的操作将会由自动进行。
另外,如果磁盘损坏的节点是当前主节点,那么我们需要进行节点切换的操作后再进行上面的操作。
2、更换磁盘
当detach了resource之后,就是更换磁盘了。如果我们使用的是internal的meta-data,那么在换好磁盘后,只需要重新创建mata-data(drbdadm create-md resource_name),再将resource attach上(drbdadm attach resource_name),然后drbd就会马上开始从当前primary节点到本节点的re-synchronisation。数据同步的实时状况可以通过 /proc/drbd文件的内容获得。
不过,如果我们使用的不是internal的meta-data保存方式,也就是说我们的meta-data是保存在resource之外的地方的。那么我们在完成上面的操作(重建meta-data)之后,还需要进行一项操作来触发re-synchnorisation,所需命令为:drbdadm invalidate resource_name 。
1、secondary节点
如果是secondary接待你crash,那么primary将临时性的与secondary断开连接,cs状态应该会变成WFConnection,也就是等待连接的状态。这时候primary会继续对外提供服务,并在meta-data里面记录下从失去secondary连接后所有变化过的block的信息。当secondary重新启动并连接上primary后,primary –> secondary的re-synchnorisation会自动开始。不过在re-synchnorisation过程中,primary和secondary的数据是不一致状态的。也就是说,如果这个时候primary节点也crash了的话,secondary是没办法切换成primary的。也就是说,如果没有其他备份的话,将丢失所有数据。
2、primary节点
一般情况下,primary的crash和secondary的crash所带来的影响对drbd来说基本上是差不多的。唯一的区别就是需要多操作一步将secondary节点switch成primary节点先对外提供服务。这个switch的过程drbd自己是不会完成的,需要我们人为干预进行一些操作才能完成。当crash的原primary节点修复并重新启动连接到现在的primary后,会以secondary存在,并开始re-synchnorisation这段时间变化的数据。
在primary节点crash的情况下,drbd可以保证同步到原secondary的数据的一致性,这样就避免了当primary节点crash之后,secondary因为数据的不一致性而无法wcitch成primary或者即使切换成primary后因为不一致的数据无法提供正常的服务的问题。
3、节点永久性损坏(需要更换机器或重新安装相关软件的情况)
当某一个节点因为硬件(或软件)的问题,导致某一节点已经无法再轻易修复并提供服务,也就是说我们所面对的是需要更换主机(或从OS层开始重新安装)的问题。在遇到这样的问题后,我们所需要做的是重新提供一台和原节点差不多的机器,重新开始安装os,安装相关软件,从现有整提供服务的节点上copy出drbd的配置文件(/etc/drbd.conf),创建meta-data信息,然后启动drbd服务,以一个secondary的身份连接到现有的primary上面,后面就会自动开始re-synchnorisation。
resource data {
protocol C;
handlers {
split-brain "/usr/lib/drbd/notify-split-brain.sh root";
local-io-error "/usr/lib/drbd/notify-io-error.sh; /usr/lib/drbd/notify-emergency-shutdown.sh; echo o > /proc/sysrq-trigger ; halt -f";
}
startup {
wfc-timeout 0;
degr-wfc-timeout 120;
}
disk {
on-io-error detach;
}
net {
cram-hmac-alg sha1;
after-sb-0pri discard-zero-changes;
after-sb-1pri discard-secondary;
after-sb-2pri disconnect;
max-buffers 8000;
max-epoch-size 8000;
sndbuf-size 0;
}
syncer {
rate 90M;
al-extents 257;
}
on BGP-LF-1MS2232{
device /dev/drbd0;
disk /dev/sda4;
address 192.168.1.104:7788;
meta-disk internal;
}
on BGP-LF-1MS2233{
device /dev/drbd0;
disk /dev/sda4;
address 192.168.1.105:7788;
meta-disk internal;
}
}
drbdadm create-md all|RESOURCE...
drbdadm up|down all|RESOURCE...
drbdadm primary|secondary all|RESOURCE...
drbdadm connect|disconnect all|RESOURCE...
drbdadm attach|detach all|RESOURCE...
drbdadm status [all|RESOURCE...]
drbdadm sh-dev all|RESOURCE... #查看资源对应的drbd设备
drbdadm adjust all|RESOURCE... # 重载配置文件
https://manpages.ubuntu.com/manpages/jammy/en/man8/drbdadm-9.0.8.html
其他命令
root@worker04:~# drbdadm hidden-commands
These additional commands might be useful for writing
nifty shell scripts around drbdadm:
new-resource sh-md-idx
proxy-down sh-minor
proxy-up sh-mod-parms
sh-dev sh-nop
sh-ip sh-resource
sh-ll-dev sh-resources
sh-lr-of sh-udev
sh-md-dev
These commands are used by the kernel part of DRBD to
invoke user mode helper programs:
after-resync-target out-of-sync
before-resync-source pri-lost
before-resync-target pri-lost-after-sb
disconnected pri-on-incon-degr
fence-peer quorum-lost
initial-split-brain split-brain
local-io-error unfence-peer
These commands ought to be used by experts and developers:
check-resize resume-io
del-minor set-gi
new-current-uuid suspend-io
new-minor