简介
?
高可用架构指多个 Master 节点的主备多活架构。多个 Master 节点中只有一个会作为主（Leader）节点对外提供服务，其他的备（Standby）节点通过同步共享日志（Journal）来保持与主节点相同的文件系统状态。当主节点故障宕机后，会从当前的备节点中自动选择一个接替主节点继续对外提供服务，这样就消除了系统的单点故障，实现了整体高可用架构。目前 GooseFS 支持基于 Raft 日志和 Zookeeper 两种方式来实现主备节点状态的强一致性，在容器场景下，我们推荐基于 Raft 日志模式部署您的高可用架构。本文重点介绍基于 Raft 的高可用部署配置，并区分了顺序读和随机读两种不同场景。
基于 Raft 的高可用架构部署配置（顺序读场景）
在顺序读的场景下，您可以参考如下推荐配置，并将该配置项复制粘贴到 goosefs-site.properties 文件中，完成您的高可用架构配置：
goosefs.master.embedded.journal.addresses=<master1>:9202,<master2>:9202,<master3>:9202?goosefs.master.metastore=ROCKS# 主要是在不确定 rocksdb 是否修复的情况下使用goosefs.master.metastore.block=HEAP?# 根据内存大小而定goosefs.master.metastore.inode.cache.max.size=10000000?# rocksdb 数据存放的地方goosefs.master.metastore.dir=/meta-1/metastore?# 根目录的挂载路径，需要放在安全目录中，防止被误删除goosefs.master.mount.table.root.ufs=/meta-1/underFSStorage?# raft 日志存放的地方goosefs.master.journal.folder=/meta-1/journal?# 触发切主的超时时间，不易过小（jvm gc 会导致切主震荡），也不易过大（影响恢复可用性的时间）goosefs.master.embedded.journal.election.timeout=20s?# 在大数据量情况下，强烈建议关闭goosefs.master.startup.block.integrity.check.enabled=false?# 触发 checkpoint 的时机，不易过小（做checkpoint会很频繁，在做 checkpoint 期间不会参与选主），也不易过大（影响服务重启耗时），可根据checkpoint加载时间评估。goosefs.master.journal.checkpoint.period.entries=20000000?# acl 鉴权开关，根据场景定goosefs.security.authorization.permission.enabled=false?# 建议打开，不然会采用 hostname，而 hostname 可能相同。goosefs.network.ip.address.used=true?# Worker propertiesgoosefs.worker.tieredstore.levels=1goosefs.worker.tieredstore.level0.alias=HDDgoosefs.worker.tieredstore.level0.dirs.quota=7TB,7TBgoosefs.worker.tieredstore.level0.dirs.path=/data-1,/data-2?# worker 重启的超时时间，在大数量情况下，尽量调大。goosefs.worker.registry.get.timeout.ms=3600s?# 读取数据响应的超时时间，默认1hgoosefs.user.streaming.data.timeout=60s?# 写策略，默认是 LocalFirstPolicy，有可能导致数据不均衡goosefs.user.block.write.location.policy.class=com.qcloud.cos.goosefs.client.block.policy.RoundRobinPolicy?# 影响 distributedLoad 的速度,在不考虑影响在线读的情况下，建议设置为 cpu 数目 * 2，gosefs.job.worker.threadpool.size=50
基于 Raft 的高可用架构部署配置（随机读场景）
在随机读的场景下，您可以参考如下推荐配置，并将该配置项复制粘贴到 goosefs-site.properties 文件中，完成您的高可用架构配置：
goosefs.master.embedded.journal.addresses=<master1>:9202,<master2>:9202,<master3>:9202?goosefs.master.metastore=ROCKS# 主要是在不确定 rocksdb 是否修复的情况下使用goosefs.master.metastore.block=HEAP?# 根据内存大小而定goosefs.master.metastore.inode.cache.max.size=10000000?# rocksdb 数据存放的地方goosefs.master.metastore.dir=/meta-1/metastore?# 根目录的挂载路径，需要放在安全目录中，防止被误删除goosefs.master.mount.table.root.ufs=/meta-1/underFSStorage?# raft 日志存放的地方goosefs.master.journal.folder=/meta-1/journal?# 触发切主的超时时间，不易过小（jvm gc 会导致切主震荡），也不易过大（影响恢复可用性的时间）goosefs.master.embedded.journal.election.timeout=20s?# 在大数据量情况下，强烈建议关闭goosefs.master.startup.block.integrity.check.enabled=false?# 触发 checkpoint 的时机，不易过小（做 checkpoint 会很频繁，在做 checkpoint 期间不会参与选主），也不易过大（影响服务重启耗时），可根据checkpoint加载时间评估。goosefs.master.journal.checkpoint.period.entries=20000000?# acl 鉴权开关，根据场景定goosefs.security.authorization.permission.enabled=false?# 建议打开，不然会采用 hostname，而 hostname 可能相同。goosefs.network.ip.address.used=true?# Worker propertiesgoosefs.worker.tieredstore.levels=1goosefs.worker.tieredstore.level0.alias=HDDgoosefs.worker.tieredstore.level0.dirs.quota=7TB,7TBgoosefs.worker.tieredstore.level0.dirs.path=/data-1,/data-2?# worker 重启的超时时间，在大数量情况下，尽量调大。goosefs.worker.registry.get.timeout.ms=3600s?# 读取数据响应的超时时间，默认1hgoosefs.user.streaming.data.timeout=60s?# 写策略，默认是 LocalFirstPolicy，有可能导致数据不均衡goosefs.user.block.write.location.policy.class=com.qcloud.cos.goosefs.client.block.policy.RoundRobinPolicy?# 对于随机读情况，建议调小(默认为1MB)，防止读膨胀goosefs.user.streaming.reader.chunk.size.bytes=256KBgoosefs.user.local.reader.chunk.size.bytes=256KB?# 等待 worker 读流关闭的时间，在大量小文件读或者随机读情况，建议调小（默认5s），避免长尾导致的性能降低goosefs.user.streaming.reader.close.timeout=100ms
?
