23. DRBD内部原理
本章提供了一些有关DRBD内部算法和结构的背景信息。它适用于希望获得有关DRBD的一定程度背景知识的感兴趣的用户。它没有深入探讨DRBD的内部工作原理,无法为DRBD开发人员提供参考。为此,请参考出版物中列出的论文,当然也请参考DRBD源代码中的注释。
23.1。DRBD元数据
DRBD将有关其保存的数据的各种信息存储在专用区域中。该元数据包括:
该元数据可以存储在内部或外部。使用哪种方法可以根据每个资源进行配置。
23.1.1。内部元数据
配置资源以使用内部元数据意味着DRBD将其元数据存储在与实际生产数据相同的物理低层设备上。它是通过在设备末端预留一个区域来存储元数据的特定目的来实现的。
优点
由于元数据与实际数据有着千丝万缕的联系,因此在硬盘发生故障时,管理员无需采取任何特殊措施。元数据与实际数据一起丢失,并且也一起恢复。
坏处
如果低层设备是单个物理硬盘(与RAID集相反),则内部元数据可能会对写入吞吐量产生负面影响。应用程序执行写请求可能会触发DRBD中元数据的更新。如果元数据存储在硬盘的同一磁盘上,则写操作可能会导致硬盘的写/读头发生两次额外的移动。
如果您打算将内部元数据与已经具有要保留的数据的现有低层设备一起使用,则必须考虑DRBD元数据所需的空间。 否则,在创建DRBD资源时,新创建的元数据将覆盖低级设备末端的数据,从而有可能破坏该过程中的现有文件。 |
为了避免这种情况,您必须执行以下操作之一:
- 放大下层设备。只要您在相应的卷组中有可用空间,任何逻辑卷管理工具(例如LVM)都可以做到这一点。硬件存储解决方案也可能支持它。
- 将现有文件系统收缩到较低级别的设备上。您的文件系统可能支持也可能不支持。
- 如果两者都不可行,请改用 外部元数据。
要估计必须扩大下层设备或缩小文件系统的数量,请参阅估计元数据大小。
23.1.2。外部元数据
外部元数据仅存储在与保存生产数据不同的单独的专用块设备上。
优点
对于某些写操作,使用外部元数据会产生稍微改善的延迟行为。
坏处
元数据与实际生产数据没有千丝万缕的联系。这意味着在硬件故障仅破坏生产数据(而不破坏DRBD元数据)的情况下,需要进行人工干预,以实现从尚存节点到随后替换的磁盘的完整数据同步。
如果满足以下所有条件,则使用外部元数据也是唯一可行的选择:
- 您正在使用DRBD复制现有设备,该设备已经包含要保留的数据,并且
- 现有设备不支持扩展,并且
- 设备上的现有文件系统不支持收缩。
要估算专用于保存设备元数据的块设备的所需大小,请参阅估算元数据大小。
外部元数据至少需要1MB的设备大小。 |
23.1.3。估算元数据大小
您可以使用以下公式计算DRBD元数据的确切空间要求:
图18.计算DRBD元数据大小(精确)
C s是扇区中数据设备的大小, N是对等体的数量。
您可以通过发出blockdev --getsize64 <device>; 检索设备大小(以字节为单位)。要转换为MB,请除以1048576(= 2 20或1024 2)。 |
实际上,您可以使用下面给出的合理的近似值。请注意,在此公式中,单位是兆字节,而不是扇区:
图19.估计DRBD元数据大小(大约)
23.2。代标识符
DRBD使用世代标识符 (GI)来识别复制数据的“世代”。
这是DRBD的内部机制,用于
- 确定两个节点是否实际上是同一集群的成员(而不是偶然连接的两个节点),
- 确定后台重新同步的方向(如有必要),
- 确定是否需要完全重新同步或部分重新同步是否足够,
- 识别脑裂。
23.2.1。数据生成
在以下每种情况下,DRBD都标志着新数据生成的开始:
- 初始设备完全同步,
- 断开资源切换到主要角色,
- 主要角色中的资源断开连接。
因此,我们可以总结出,只要资源处于Connected 连接状态,并且两个节点的磁盘状态均为UpToDate,则两个节点上的当前数据生成是相同的。反之亦然。请注意,当前实现使用最低位来编码节点的角色(主要/次要)。因此,即使不同节点上的最低位可能被认为具有相同的数据生成,也可能有所不同。
每个新的数据生成都由一个8字节的通用唯一标识符(UUID)标识。
23.2.2。代标识符元组
DRBD在本地资源元数据中保留了有关当前和历史数据生成的一些信息:
当前的UUID
从本地节点的角度来看,这是当前数据生成的生成标识符。当资源已 连接并完全同步时,节点之间的当前UUID相同。
位图UUID
这是该磁盘位图(每个远程主机)用来跟踪更改的生成的UUID。与磁盘同步位图本身一样,此标识符仅在远程主机断开连接时才相关。
历史UUID
这些是当前代之前的数据生成的标识符,大小确定为每个(可能)远程主机有一个插槽。
这些项统称为生成标识符元组,或简称为“ GI元组 ”。
23.2.3。代标识符如何更改
开始生成新数据
当处于主要角色的节点失去与对等方的连接(通过网络故障或手动干预)时,DRBD将以以下方式修改其本地生成标识符:
图20. GI元组在新数据生成开始时的更改
- 主数据库为新数据生成创建一个新的UUID。这将成为主节点的 新的当前UUID。
- 现在,先前的当前UUID是指位图跟踪更改所依据的世代,因此它成为主节点的新位图UUID。
- 在辅助节点上,GI元组保持不变。
完成重新同步
当重新同步结束时,同步目标将采用同步源中的整个GI元组。
同步源保持相同的设置,并且不会生成新的UUID。
23.2.4。DRBD如何使用世代标识符
当节点之间建立连接时,两个节点交换它们当前可用的世代标识符,并据此进行。存在许多可能的结果:
两个节点上的当前UUID空
本地节点检测到其当前UUID和对等方的当前UUID均为空。对于没有启动初始完全同步的新配置资源,这是正常情况。没有同步发生;它必须手动启动。
当前UUID在一个节点上为空
本地节点检测到对等方的当前UUID为空,而对等方的当前UUID不为空。对于刚开始初始化初始完全同步且已选择本地节点作为初始同步源的新配置资源,这是正常情况。现在,DRBD将磁盘同步位图中的所有位设置为1(意味着它认为整个设备不同步),并开始作为同步源进行同步。在相反的情况下(本地当前UUID为空,对等方为非空),DRBD执行相同的步骤,不同之处在于本地节点成为同步目标。
相等的当前UUID
本地节点检测到其当前UUID和对等方的当前UUID非空且相等。这是资源的正常情况,该资源在处于辅助角色时进入断开模式,并且在断开连接时未在任何一个节点上升级。没有同步发生,因为没有必要。
位图UUID与对等方当前的UUID匹配
本地节点检测到其位图UUID与对等方的当前UUID相匹配,并且对等方的位图UUID为空。这是辅助节点故障后的正常现象,是预期的情况,本地节点处于主要角色。这意味着在此期间,对等方永远不会成为主要对象,并且始终基于相同的数据生成来工作。DRBD现在启动正常的后台重新同步,而本地节点将成为同步源。相反,如果本地节点检测到其位图UUID为空,并且对等节点的位图与本地节点的当前UUID匹配,这是本地节点故障后的正常现象和预期事件。再次,DRBD现在启动正常的后台重新同步,而本地节点成为同步目标。
当前的UUID与对等方的历史UUID相匹配
本地节点检测到其当前UUID与对等方的历史UUID之一匹配。这意味着,尽管两个数据集共享一个共同的祖先,并且对等节点具有最新数据,但保留在对等节点的位图中的信息已过时且无法使用。因此,正常的同步将是不够的。DRBD现在将整个设备标记为不同步,并启动完整的后台重新同步,而本地节点将成为同步目标。在相反的情况下(本地节点的历史UUID之一与对等方的当前UUID匹配),DRBD执行相同的步骤,不同之处在于本地节点成为同步源。
位图UUID匹配,当前UUID不匹配
本地节点检测到其当前UUID与对等方的当前UUID不同,并且位图UUID匹配。这是裂脑,但是数据世代具有相同的父代。这意味着DRBD会调用裂脑自动恢复策略(如果已配置)。否则,DRBD会断开连接并等待手动裂脑解决。
当前或位图的UUID都不匹配
本地节点检测到其当前UUID与对等方的当前UUID不同,并且位图UUID 不匹配。这是与祖先世代无关的分裂大脑,因此自动恢复策略(即使配置)也没有意义。DRBD断开连接并等待手动拆分大脑。
没有UUID匹配
最后,如果DRBD甚至在两个节点的GI元组中都检测不到单个匹配元素,则会记录有关不相关数据的警告并断开连接。这是DRBD的预防措施,可防止意外连接两个以前从未听说过的群集节点。
23.3。活动日志
23.3.1。目的
在写操作期间,DRBD将写操作转发到本地支持块设备,但也通过网络发送数据块。出于所有实际目的,这两个动作同时发生。随机时序行为可能会导致写操作已完成但尚未通过网络进行传输的情况,反之亦然。
如果此时活动节点发生故障并且正在启动故障转移,则该数据块在节点之间不同步-在崩溃之前已将其写入故障节点,但复制尚未完成。因此,当节点最终恢复时,必须在后续同步期间将该块从数据集中删除。否则,崩溃的节点将在幸存节点之前“一个写一个”,这将违反复制存储的“全有或全无”原则。这是一个不仅仅限于DRBD的问题,实际上,该问题实际上存在于所有复制的存储配置中。因此,许多其他存储解决方案(就像版本0.7之前的DRBD一样)要求在活动节点发生故障之后,数据在恢复后必须完全同步。
从版本0.7开始,DRBD的方法便有所不同。存储在元数据区域中的活动日志(AL)跟踪“最近”写入过的那些块。通俗地讲,这些区域称为热点。
如果对发生故障时处于活动模式的临时故障节点进行了同步,则只需要同步AL中突出显示的那些热区(加上当前活动对等体上位图中标记的任何块),而不是整个节点设备。这将大大减少活动节点崩溃后的同步时间。
23.3.2。活动范围
活动日志具有可配置的参数,即活动范围的数量。在主崩溃后,每个活动范围都将4MiB添加到重传的数据量中。必须将此参数理解为以下两个方面的折衷:
许多活动范围
保留较大的活动日志可提高写入吞吐量。每次激活新扩展区时,都会将旧扩展区重置为非活动状态。这种转变需要对元数据区域进行写操作。如果活动范围的数量很大,则旧的活动范围很少被交换掉,从而减少了元数据的写操作,从而提高了性能。
活动范围很少
保留较小的活动日志可减少活动节点故障和后续恢复后的同步时间。
23.3.3。选择合适的活动日志大小
范围数量的考虑应基于给定同步速率下的所需同步时间。活动范围的数量可以如下计算:
图21.根据同步速率和目标同步时间计算活动范围
R是同步速率,单位为MiB / s。t sync是目标同步时间,以秒为单位。E是活动范围的结果数。
作为示例,假设集群具有一个I / O子系统,该子系统的吞吐速率为200 MiByte / s,配置为同步速率(R)为60 MiByte / s,并且我们希望保持目标同步时间(t在4分钟或240秒处同步):
图22.基于同步速率和目标同步时间的活动范围计算(示例)
最后,DRBD 9即使在辅助节点上也需要保持AL,因为它们的数据可能用于同步其他辅助节点。
23.4。快速同步位图
快速同步位图是DRBD在每个资源每个对等点基础上使用的内部数据结构,用于跟踪块处于同步状态(在两个节点上相同)或不同步。仅在资源处于断开连接模式时才有意义。
在快速同步位图中,一位代表4 KB的磁盘上数据块。如果该位被清除,则意味着相应的块仍与对等节点同步。这意味着自断开连接以来尚未写入该块。相反,如果该位置1,则意味着该块已被修改,并且只要连接再次可用就需要重新同步。
由于DRBD在断开连接的设备上检测到写入I / O,并因此开始在快速同步位图中设置位,因此它在RAM中进行设置,从而避免了昂贵的同步元数据I / O操作。仅当相应的块变冷(即,从“ 活动日志”中过期 )时,DRBD才对快速同步位图的磁盘表示形式进行适当的修改。同样,如果在断开连接的同时碰巧在其余节点上手动关闭了资源,则DRBD会将完整的快速同步位图刷新 到持久性存储中。
当对等节点恢复或重新建立连接时,DRBD组合来自两个节点的位图信息,以确定它必须重新同步的 总数据集。同时,DRBD 检查世代标识符以确定同步的 方向。
然后,充当同步源的节点将同意的块发送到对等节点,并在同步目标确认修改后清除位图中的同步位。如果现在重新同步被中断(例如,由于另一个网络中断),然后重新开始,它将在中断的地方继续进行-当然,与此同时修改的所有其他块都将添加到重新同步数据集中。
重新同步也可以通过drbdadm pause-sync和 drbdadm resume-sync命令暂停并手动恢复。但是,您不应该轻率地这样做-中断重新同步会使辅助节点的磁盘 不一致的时间长于必要的时间。 |
23.5。对等防护界面
DRBD具有定义的接口,用于在复制链接中断的情况下屏蔽[ 17 ]对等节点。drbd-peer-outdater与Heartbeat捆绑在一起的 帮助程序是此接口的参考实现。但是,您可以轻松实现自己的对等击剑帮助程序。
防护助手仅在以下情况下被调用
- fence-peer在资源(或common) handlers部分中定义了一个处理程序,并且
- fencing资源的选项设置为 resource-only或resource-and-stonith,然后
- 复制链接被中断足够长的时间,以至于DRBD [ 18 ]检测到网络故障。
指定为fence-peer处理程序的程序或脚本在调用时具有DRBD_RESOURCE和DRBD_PEER环境变量可用。它们分别包含受影响的DRBD资源的名称和对等方的主机名。
任何对等的击剑帮助程序(或脚本)都必须返回以下退出代码之一:
退出码 | 意义 |
3 | 对等方的磁盘状态已经不一致。 |
4 | 对等方的磁盘状态已成功设置为“ 已过时”(或首先已过时)。 |
5 | 与对等节点的连接失败,无法访问对等节点。 |
6 | 对等方拒绝过时,因为受影响的资源是主要角色。 |
7 | 对等节点已成功从群集中隔离。除非fencing为resource-and-stonith受影响的资源设置为,否则这永远不会发生。 |
表1. fence-peer处理程序退出代码 |