Wave Spread...

Linux 运维手册之 GlusterFS 分布式文件系统

分类:Linux 评论: 0

GlusterFS 是一个可扩展的,分布式文件系统,可以将多个服务器的磁盘聚合为一个命名空间中统一管理。

相对于其他文件存储方案,优点:


安装与部署

部署最简易的 Gluster 集群仅需两台机器,官方推荐配置为(2 颗 CPU、4GB 内存、千兆网卡) ,不同发行版的安装方式略有不同,本文以 CentOS 7 x86_64 版本为例。

配置仓库

# yum install centos-release-gluster

小贴士:官方仓库默认包含于 Extras 仓库内,默认安装为 LTM 长期维护版。

环境准备

最简集群需要两台机器,本文以三台为例进行搭建(为什么使用三台后面会提到),每台机器包含两块硬盘,一块为系统安装盘,另一块为将来的分布式存储盘。

虽然可以将 Gluster Volume 与 System Volume 合一使用,但是强烈建议不要使用此方案。

节点号 IP 主机名
NODE01 10.0.0.11 gluster01
NODE02 10.0.0.12 gluster02
NODE03 10.0.0.13 gluster03

磁盘处理

# ll /dev/sd*
brw-rw---- 1 root disk 8,  0 Nov 22 01:05 /dev/sda
brw-rw---- 1 root disk 8,  1 Nov 22 01:05 /dev/sda1
brw-rw---- 1 root disk 8,  2 Nov 22 01:05 /dev/sda2
brw-rw---- 1 root disk 8, 16 Nov 22 01:05 /dev/sdb

将第二块磁盘建立分区

# fdisk /dev/sdb
Welcome to fdisk (util-linux 2.23.2).

Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.

Device does not contain a recognized partition table
Building a new DOS disklabel with disk identifier 0x11abb1e2.

Command (m for help): n
Partition type:
   p   primary (0 primary, 0 extended, 4 free)
   e   extended
Select (default p): p
Partition number (1-4, default 1): 
First sector (2048-10485759, default 2048): 
Using default value 2048
Last sector, +sectors or +size{K,M,G} (2048-10485759, default 10485759): 
Using default value 10485759
Partition 1 of type Linux and of size 5 GiB is set

Command (m for help): w
The partition table has been altered!

Calling ioctl() to re-read partition table.
Syncing disks.

格式化为 XFS 并设置挂载

# mkfs.xfs -i size=512 /dev/sdb1
# mkdir -p /bricks/brick1
# vi /etc/fstab

添加如下一行

/dev/sdb1 /bricks/brick1 xfs defaults 1 2

重新加载分区表并挂载

# mount -a && mount

检查分区

# df -h
Filesystem               Size  Used Avail Use% Mounted on
/dev/mapper/centos-root   17G  2.0G   16G  12% /
devtmpfs                 476M     0  476M   0% /dev
tmpfs                    488M     0  488M   0% /dev/shm
tmpfs                    488M  7.6M  480M   2% /run
tmpfs                    488M     0  488M   0% /sys/fs/cgroup
/dev/sda1               1014M  130M  885M  13% /boot
tmpfs                     98M     0   98M   0% /run/user/0
/dev/sdb1                 20G   33M   20G   1% /bricks/brick1

额外:在 CentOS 6 中格式化与使用 XFS 分区需额外安装

# yum install xfsprogs

安装服务

# yum install -y glusterfs-server

配置服务

配置服务自启动

# systemctl enable glusterd
# systemctl start glusterd

配置资源池

1) 在节点1上信任节点2与节点3

# gluster peer probe gluster02
# gluster peer probe gluster03

2) 若添加错误,使用命令删除节点即可

# gluster peer detach NODE-NAME

3) 可使用如下命令查看全部已添加节点(看不到自身)

# gluster peer status

配置 Volume 卷

在 GlusterFS 中有多种配置卷的模式

词条解释:

说明:文件将会被分配器分配至任一节点中存放。

优点:可以缩放 Volume 卷的大小,且磁盘的大小无需一致。
缺点:无冗余性,任一节点损坏将导致数据丢失,必须依靠底层硬件来提供冗余性如 RAID1。

说明:文件将被存放至每个节点一份,高度冗余性。

优点:高度冗余,任意节点损坏,文件都可从其他节点处获取。
缺点:与 RAID1 一致,空间的利用率低。且每个 Volume 需容量相同。

说明:文件将会被分布式得复制为多份(视 Volume 数量而定),且brick的数量必须是副本数的倍数。且按照相邻的brick的顺序,作为彼此的副本。

优点:兼顾空间与冗余。
缺点:磁盘数量需为副本数的倍数,需要的节点数较多。

说明:考虑将大型文件存储在单brick中,多客户端经常同时访问,将导致单brick上的负载过大,从而降低性能。在条带卷模式中,数据在将其分成不同的“块”后存储在brick中。因此,大文件将被分成较小的块(等于卷中的brick数),每个块存储在一brick中。现在可以分配负载,并且可以更快地获取文件,但不提供数据冗余。

优点:性能极高,对大文件的存储来说极为优秀。
缺点:不提供数据冗余。

说明:与条带卷类似,不同在于条带可以分布在更多数据的brick上,brick的数量必须是条带的倍数。

优点:兼顾性能和分布式
缺点:依然依赖硬件提供数据冗余

注:条带化有个最小限制:128KB。即当文件大小小于这个值时,不进行分隔。其他储存单元中,存在同名文件,但是大小为0。

由以上内容可知,副本数就是文件在逻辑卷中实际存放的数量,只要副本数不为一即可提供数据冗余。砖块数(brick)即为节点数,必须为副本数的整数倍。

创建逻辑卷 Volume 存放路径

# mkdir /bricks/brick1/gv0

创建逻辑卷 Volume

# gluster volume create gv0 replica 3 gluster{01,02,03}:/bricks/brick1/gv0

启动逻辑卷 Volume

# gluster volume start gv0

查看逻辑卷 Volume 状态

# gluster volume info

测试服务

# mount -t glusterfs gluster03:/gv0 /mnt
# for i in `seq -w 1 100`; do cp -rp /var/log/messages /mnt/copy-test-$i; done

在挂载客户端上检查

# ls -lA /mnt | wc -l

每个节点上操作都能看到测试产生的文件。

# ls -lA /bricks/brick1/gv0

访问限制

若开启了防火墙,请放行 Gluster 服务(默认监听 TCP/24007),但添加 Volume 时会监听额外的新端口,可使用

# gluster volume status

查看全部逻辑卷的状态及监听端口。

架构优化及问题

数据冗余与性能

俗话说鱼和熊掌不可兼得,数据冗余与性能也是相斥的,因此需要找到一个冗余与性能的平衡。

脑裂问题

Q:在什么场景会出现脑裂的情况呢?
A:比如说目前副本数为 2,分别存放在 Node1 和 Node2 上,写完副本后要通知所有其他的节点写入操作已经完成,其他的节点记录下另外节点副本已经写入完毕,如果这时 Node1 和 Node2 之间的网断了,Node1 就无法通知 Node2,那么 Node2 这边就觉得,我已经写完了,Node1 没给我通信,Node1 有问题;相应地 Node2 也没法给 Node1 报告说我写完了,Node1 也同样认为我写完了而对方有问题,而他们各自连接的客户端连接正常的,都会返回正确的信息给客户端,这样读写看似是正常进行的,但这个文件再次被访问到的时候,Node1 和 Node2 查看日志,都发现自身正常对方有问题,都尝试用自己的内容去恢复对方的内容,这时就出现脑裂了。脑裂的文件访问会出现问题,一般是input/output error这样的问题。

相关链接

参考链接

回复