corosync-qdevice使用


难度 中等

qdevice要用途是让群集能够承受大于标准仲裁规则所允许的节点故障数量。在分布式一致性协议中,基于多数派quorum的协议解决脑裂等问题,因而当集群存活节点挂死超过一半时,集群将无法对外提供服务。qdevice提供仲裁机制,使集群在多数节点挂掉后仍然能提供服务。典型的如双节点集群发生网络分区后,qdevice可以使其中一台机器继续提供服务,进而保证高可用。

QDevice 和 QNetd 会参与仲裁决定。在仲裁方 corosync-qnetd 的协助下,corosync-qdevice 会提供一个可配置的投票数,以使群集可以承受大于标准仲裁规则所允许的节点故障数量。我们强烈建议为双节点群集部署 corosync-qnetd 和 corosync-qdevice,但对于所含节点数为偶数的群集,一般也建议使用 QNetd 和 QDevice。

基本组件

corosync

corosync提供分布式一致性协议和配置。

qnetd

qnetd提供与qdevice通信的网络服务器。

qdevice

每个群集节点上与 Corosync 一起运行的 systemd 服务(守护程序)。这是 corosync-qnetd 的客户端。其主要用途是让群集能够承受大于标准仲裁规则所允许的节点故障数量。

QDevice 可以与不同的仲裁方配合工作,但目前仅支持与 QNetd 配合工作。

编译运行

编译

qdevice依赖corosync,在编译qdevice前应先编译corosync。

  • 下载源码

    git clone https://github.com/corosync/corosync-qdevice.git
  • 编译

    cd corosync-qdevice
    ./autogen.sh
    ./configure
    make -j 8
    sudo make install

    若编译时找不到libcorosync_common库,则需要导出pkgconfig文件路径到PKG_CONFIG_PATH,如:

    export PKG_CONFIG_PATH="/home/ha/code/corosync/pkgconfig"

    编译完成后会生成corosync-qnetd和corosync-qdevice。

    ha@ha-virtual-machine:~/code/corosync-qdevice$ ls install
    bin  etc  sbin  share  var
    ha@ha-virtual-machine:~/code/corosync-qdevice$ ls install/bin/
    corosync-qnetd  corosync-qnetd-certutil  corosync-qnetd-tool
    ha@ha-virtual-machine:~/code/corosync-qdevice$ ls install/sbin/
    corosync-qdevice  corosync-qdevice-net-certutil  corosync-qdevice-tool
    ha@ha-virtual-machine:~/code/corosync-qdevice$ ls install/etc/
    corosync  init.d
    ha@ha-virtual-machine:~/code/corosync-qdevice$ ls install/etc/corosync/
    qdevice  qnetd

运行

corosync-qnetd可以独立运行,同时corosync-qdevice在启动时候需要连接qnetd,因而需先启动corosync-qnetd。

一般我们使用非root用户运行,运行配置步骤如下:

  1. 先创建非root用户;

    groupadd -r coroqnetd
    useradd -r -g coroqnetd -d / -s /sbin/nologin -c "User for corosync-qnetd" coroqnetd
    chown -R coroqnetd:coroqnetd /etc/corosync/qnetd /var/run/corosync-qnetd
  2. 在/etc/corosync/qnetd/下创建corosync-qnetd.sysconfig写下如下内容

    # Corosync Qdevice Network daemon init script configuration file
    
    # COROSYNC_QNETD_OPTIONS specifies options passed to corosync-qnetd command
    # (default is no options).
    # See "man corosync-qnetd" for detailed descriptions of the options.
    COROSYNC_QNETD_OPTIONS=""
    
    # COROSYNC_QNETD_RUNAS specifies user under which qnetd daemon should be running
    # (not set or empty is default and means "user who executes init script")
    # Make sure to set correct owner of directories /etc/corosync/qnetd and
    # /var/run/corosync-qnetd
    # This has no effect if systemd unit is used (you have to change unit file)
    COROSYNC_QNETD_RUNAS="coroqnetd"
  3. 运行qnetd

    /etc/init.d/corosync-qnetd start

双节点qnet与三节点corosync的区别

  1. qnet主要作为第三方仲裁,配合qdevice来提供投票仲裁服务,不属于集群内节点,不承担任何集群节点功能;
  2. QDevice 支持多种不同的算法,而这些算法决定着如何分配投票的行为,如:
    • FFSplit (“fifty-fifty split”) 为默认算法,用于所含节点数为偶数的群集。如果群集分裂为两个相似的部分,此算法会根据启发检查结果和其他因素为其中一个部分提供一个投票
    • LMS (“last man standing”) 允许仅剩的那个节点看到 QNetd 服务器以获取投票。因此此算法适用于只有一个活动节点应保留法定票数的群集
  3. 启用qdevice加qnet后,corosync里的last_man_standing 选项(即动态修改quorum)与其不兼容,但qdevice如上描述可以选择LMS算法来进行投票;
  4. qnet一般需要独立于主集群,不要与 corosync 环或者环位于同一个网络网段,一般不在现有集群节点中运行制裁设备;
  5. 多个集群可以共用一个qnet仲裁服务,且不同的集群可以配置不同投票算法;

corosync1.0版本没有投票机制,需要使用corosync-qdevice来配合投票仲裁,corosync2.0版本通过votequorum提供投票机制。

votequorum与corosync-qdevice

votequorum和corosync-qdevice都是投票仲裁机制。

votequorum不需要引入第三方仲裁,直接作为一个服务集成到corosync中。votequorum通过为集群中的每个系统分配一定数量的选票,并确保只有当多数票出现时,才允许进行集群操作。

corosync-qdevice需要引入第三方仲裁qnet,除运行corosync服务、corosync-qdevice服务外,还需要在一台非集群节点运行corosync-qnetd服务。在仲裁方 corosync-qnetd 的协助下,corosync-qdevice 会提供一个可配置的投票数,以使群集可以承受大于标准仲裁规则所允许的节点故障数量。这里的标准仲裁规则是指当集群节点数超过一般挂死时集群将不可用。

双节点场景

对于双节点场景来说,

  • votequorum通过在corosync.conf中配置two_node来解决双节点场景的高可用问题,且这样配置后只能处理两个节点的情况,当有第三个节点加入时,two_node配置自动失效
  • 而corosync-qdevice通过在corosync.conf的device配置模块中配置algorithm: ffsplit来解决

文章作者: growdu
版权声明: 本博客所有文章除特別声明外,均采用 CC BY 4.0 许可协议。转载请注明来源 growdu !
  目录
分类导航
随笔3 AI29 计算机基础13 算法1 博客搭建7 ChatGPT2 集群63 计算机通信1 数据库59 数据库深入93 数据库93 Docker11 DPDK26 编辑工具4 Elasticsearch4 FAQ1 Go Web1 hometown2 编程语言16 人生11 网络9 Linux38 OPC1 openGauss4 页面12 PostgreSQL54 程序员自我修养1 协议11 stock1 存储5 成长之路1 工具20 视频作品1 VPP18 Vue13 Web1 代码示例11 BenchmarkSQL1 PostgreSQL 源码修炼之路14
最热文章
1
PostgreSQL 逻辑复制全链路:以一个真实事务为例,从 `INSERT` 到 `apply` 的源码级旅程
数据库🔥 2162
2
PostgreSQL 逻辑复制 Stream 执行逻辑源码级拆解:从 reorderbuffer 触发到订阅端落盘回放
数据库🔥 1765
3
PostgreSQL 行锁机制源码级深度拆解:4 种锁模式 + xmax + MultiXact 的完整链路
数据库🔥 1656
4
PostgreSQL reorderbuffer.c 函数级源码全集:5615 行 / 95 个函数的逐函数解析
数据库深入🔥 1650
5
PostgreSQL 目录快照源码级深度拆解:系统表读取的 MVCC 真相与失效机制
数据库🔥 1604
6
13 逻辑复制深入
数据库深入🔥 1570
7
0 Postgresql存储、索引及系统优化、主备切换
PostgreSQL🔥 1495
8
PostgreSQL 读一行数据源码级深度拆解:MVCC 在每个环节的落点
数据库🔥 1464
9
PostgreSQL WAL 记录类型完全指南:21 个 RMGR × 80+ 种记录的源码级拆解
数据库🔥 1431
10
一文读懂openguass dcf网络模块
集群🔥 1420
11
PostgreSQL 元数据存储机制:从磁盘文件到内存缓存,`pg_class` 撑起的整个系统表体系
数据库🔥 1411
12
openGauss 并行解码设计原理深度拆解:reader + 多 worker + CSN 三层架构的源码级剖析
数据库深入🔥 1344
13
逻辑复制源码分析
数据库深入🔥 1327
14
PostgreSQL 逻辑复制:catalog 改动、可见性判定与 xmin/xmax 推进全景
数据库深入🔥 1317
15
自托管服务全家桶:从原文方案到可复制实操手册
人生🔥 1278
16
PostgreSQL CREATE_REPLICATION_SLOT 端到端源码分析:从 SQL 到 snapbuild 状态机的完整链路(每个函数每个参数)
数据库深入🔥 1277
17
PostgreSQL syscache 模块源码深度拆解:CatCache 数据结构、LRU 哈希表、cache invalidation 全链路
数据库深入🔥 1216
18
PostgreSQL 18 内核数据结构全景:RangeVar 与 20+ 个核心数据结构源码级拆解
数据库🔥 1158
19
PostgreSQL 逻辑复制里 `RUNNING_XACTS` 写入机制与快照 `xmin / xmax / xip` 的演化:源码级深度拆解
数据库🔥 1119
20
PostgreSQL 分区表:从一行 `PARTITION BY` 到路由热路径的全链路拆解
数据库🔥 1094