十年网站开发经验 + 多家企业客户 + 靠谱的建站团队
量身定制 + 运营维护+专业推广+无忧售后,网站问题一站解决
这篇文章主要介绍“GlusterFS客户端与服务器端仲裁机制实例分析”,在日常操作中,相信很多人在GlusterFS客户端与服务器端仲裁机制实例分析问题上存在疑惑,小编查阅了各式资料,整理出简单好用的操作方法,希望对大家解答”GlusterFS客户端与服务器端仲裁机制实例分析”的疑惑有所帮助!接下来,请跟着小编一起来学习吧!
成都创新互联公司公司2013年成立,是专业互联网技术服务公司,拥有项目成都网站建设、网站制作网站策划,项目实施与项目整合能力。我们以让每一个梦想脱颖而出为使命,1280元信州做网站,已为上家服务,为信州各地企业和个人服务,联系电话:18980820575
客户端仲裁只适用于副本卷,服务器仲裁适用于所有卷。
副本卷个数最好为奇数个,服务器端个数最好为不小于3的奇数。
客户端仲裁
客户端仲裁适用于fuse、gfapi、nfs。
客户端仲裁功能是在AFR中继器中实现,所以只要该中继器被加载,就能提供客户端仲裁功能。
仲裁检测自然由AFR中继器负责。
如果检查失败,客户端则无法写入,返回EROFS错误。
正在进行写操作会因为板块(brick)数未达到仲裁要求的数量而失败,并且FOP会返回EROFS错误,后续的写操作会返回相同的错误,所以,这种情形下的错误会立即返回,没有等待超时机制。
仲裁状态是由客户端看到的活跃的(active)板块(brick)数决定的。
具体的规则由quorum-type和quorum-count确定。
Option: cluster.quorum-type Default Value: none Description: If value is "fixed" only allow writes if quorum-count bricks are present. If value is "auto" only allow writes if more than half of bricks, or exactly half including the first, are present. 如果设置为“fixed”,只允许在quorum-count数量的板块(bricks)在线时写入。 如果设置为“auto”,只允许超过一半的板块在线时写入,或者只允许一半的板块在第一次写入后继续写入。 Option: cluster.quorum-count Default Value: (null) Description: If quorum-type is "fixed" only allow writes if this many bricks or present. Other quorum types will OVERWRITE this value. 如果quorum-type设置为“fixed”,只允许设置数量的板块(brick)在线时可以写入。 如果quorum-type设置为其他值,设置的quorum-count值无效,会被覆盖。 |
板块(brick)本身会一直存在,除非对应的进程挂了。
服务器端仲裁
服务器端仲裁是由glusterd进程执行,但判断的是glusterfsd进程。
启用服务器端仲裁:server-quorum-type=server
服务器端负责仲裁检测
Option: cluster.server-quorum-type Default Value: (null) Description: This feature is on the server-side i.e. in glusterd. Whenever the glusterd on a machine observes that the quorum is not met, it brings down the bricks to prevent data split-brains. When the network connections are brought back up and the quorum is restored the bricks in the volume are brought back up. 描述:这个功能在服务器端实现,也就是在glusterd进程中。当glusterd检测到服务器端未达到法定人数时,就会停掉brick防止数据裂脑。当网络恢复达到法定人数时,就会恢复对应的brick。 Option: cluster.server-quorum-ratio Default Value: (null) Description: Sets the quorum percentage for the trusted storage pool. |
仲裁成功的bricks可以继续写入,不成功的bricks会被设置成只读或者直接停掉,当再次仲裁成功上线后,会自动修复数据,因此可以防止裂脑,保证数据一致性性。
问题
客户端仲裁与服务器端仲裁那个好?
如果启用服务器端仲裁,当出现裂脑情况时,仍然可以将数据写入卷中。服务器端仲裁为了更有效的避免和卷配置冲突,仲裁成为不可写入节点时,禁止执行volume set、peer probe等命令。
如果要避免裂脑文件出现在卷中,最好使用客户端仲裁。
两种仲裁可以同时使用吗?有什么推荐配置?
以我个人愚见,客户端仲裁就足够,但客户端仲裁只能用于复制卷环境。当然,两个仲裁机制可以同时使用。服务器端仲裁会直接干掉brick,干掉的brick甚至还允许进行读访问。
到此,关于“GlusterFS客户端与服务器端仲裁机制实例分析”的学习就结束了,希望能够解决大家的疑惑。理论与实践的搭配能更好的帮助大家学习,快去试试吧!若想继续学习更多相关知识,请继续关注创新互联网站,小编会继续努力为大家带来更多实用的文章!