使用inotify通知接口，可以用来监控文件系统的各种变化情况，如文件存取、删除、移动、修改等。利用这一机制，可以非常方便地实现文件异动告警、增量备份，并针对目录或文件的变化及时作出响应。
将inotify机制与rsync工具相结合，可以实现触发式备份（实时同步），即只要原始位置的文档发生变化，则立即启动增量备份操作；否则处于静默等待状态。这样，就避免了按固定周期备份时存在的延迟性、周期过密等问题。
因为 inotify 通知机制由 Linux 内核提供，因此主要做本机监控，在触发式备份中应用时更适合上行同步。

1.4.配置远程登陆

1.4.1.修改rsync源服务器配置192.168.190.101


vim /etc/rsyncd.conf
read only = no                     #关闭只读 上行同步需要可以写
 
 
kill $(cat /var/run/rsyncd.pid)   #杀死进程等于关闭服务
rm -rf /var/run/rsyncd.pid         #要将服务的pid文件删除否则重启服务可能会起不来会报错
rsync --daemon                     #重启服务
netstat -anpt | grep rsync         #查看服务是否启动
chmod 777 /var/www/html/kgc        #给共享目录可读可写可执行权限

1.4.2.配置server 192.168.190.102


cat /proc/sys/fs/inotify/max_queued_events
cat /proc/sys/fs/inotify/max_user_instances 
cat /proc/sys/fs/inotify/max_user_watches 
 
vim /etc/sysctl.conf 
 
fs.inotify.max_queued_events = 32768
fs.inotify.max_user_instances = 1024
fs.inotify.max_user_watches = 1048576
 
sysctl -p


在Linux内核中，默认的inotify机制提供了三个调控参数：
max_queue_events（监控事件队列，默认值为16384）、
max_user_instances（最多监控实例数，默认值为128）、
max_user_watches（每个实例最多监控文件数，默认值为8192）。
当要监控的目录、文件数量较多或者变化较频繁时，建议加大这三个参数的值。

验证是否登录

再新建的窗口下输入


tar zxvf inotify-tools-3.14.tar.gz -C /opt
 
 
cd /opt/inotify-tools-3.14/
 
./configure
make -j 4 && make install


vim /opt/inotify.sh
#!/bin/bash
INOTIFY_CMD="inotifywait -mrq -e modify,create,move,delete,attrib /var/www/html/kgc"
RSYNC_CMD="rsync -azH --delete --password-file=/etc/server.pass /var/www/html/kgc kgc@192.168.190.101::ky35"
 
$INOTIFY_CMD | while read DIRECTORY EVENT FILE
 
do
    if [ $(pgrep rsync | wc -l) -le 0 ] ; then
          $RSYNC_CMD
    fi
done


cd /opt/
chmod +x inotify.sh 
./inotify.sh

验证

二、GFS

2.1.GlusterFS简介

1.GlusterFS 是一个开源的分布式文件系统。

2.由存储服务器、客户端以及NFS/Samba存储网关(可选，根据需要选择使用)组成。

3.没有元数据服务器组件，这有助于提升整个系统的性能、可靠性和稳定性。

传统的分布式文件系统大多通过元服务器来存储元数据，元数据包含存储节点上的目录信息、目录结构等。这样的设计在浏览目录时效率高，但是也存在一些缺陷，例如单点故障。一旦元数据服务器出现故障，即使节点具备再高的冗余性，整个存储系统也将崩溃。而GlusterFS 分布式文件系统是基于无元服务器的设计，数据横向扩展能力强，具备较高的可靠性及存储效率。

4.GlusterFs同时也是Scale-Out(横向扩展)存储解决方案Gluster的核心，在存储数据方面具有强大的横向扩展能力，通过扩展能够支持数PB存储容量和处理数千客户端。

5.GlusterFS支持借助TCP/IP或InfiniBandRDMA网络 (一种支持多并发链接的技术，具有高带宽、低时延、高扩展性的特点)将物理分散分布的存储资源汇聚在一起，统一提供存储服务，并使用统一全局命名空间来管理数据。

2.2.GlusterFS特点

扩展性和高性能
GlusterFS利用双重特性来提供高容量存储解决方案。

Scale-Out架构允许通过简单地增加存储节点的方式来提高存储容量和性能(磁盘、计算和I/O资源都可以独立增加)，支持10GbE和InfiniBand等高速网络互联。
Gluster弹性哈希(ElasticHash) 解决了GlusterFS对元数据服务器的依赖，改善了单点故障和性能瓶颈，真正实现了并行化数据访问。GlusterFS采用弹性哈希算法在存储池中可以智能地定位任意数据分片(将数据分片存储在不同节点上)，不需要查看索引或者向元数据服务器查询。

高可用性
GlusterFS可以对文件进行自动复制，如镜像或多次复制，从而确保数据总是可以访问，甚至是在硬件故障的情况下也能正常访问当数据出现不一致时，自我修复功能能够把数据恢复到正确的状态，数据的修复是以增量的方式在后台执行，几乎不会产生性能负载。
GlusterFS可以支持所有的存储，因为它没有设计自己的私有数据文件格式，而是采用操作系统中主流标准的磁盘文件系统(如EXT3、XFS等)来存储文件，因此数据可以使用传统访问磁盘的方式被访问。

全局统一命名空间
分布式存储中，将所有节点的命名空间整合为统一命名空间，将整个系统的所有节点的存储容量组

弹性卷管理
GlusterFs通过将数据储存在逻辑卷中，逻辑卷从逻辑存储池进行独立逻辑划分而得到。
逻辑存储池可以在线进行增加和移除，不会导致业务中断。逻辑卷可以根据需求在线增长和缩减，并可以在多个节点中实现负载均衡。
文件系统配置也可以实时在线进行更改并应用，从而可以适应工作负载条件变化或在线性能调优。

基于标准协议
Gluster存储服务支持NFS、CIFS、HTTP、FTP、SMB 及Gluster原生协议，完全与POSIX标准(可移植操作系统接口)兼容。
现有应用程序不需要做任何修改就可以对Gluster中的数据进行访问，也可以使用专用API进行访问。

2.3.GlusterFS术语

1.Brick（块存储服务器）实际存储用户数据的服务器

2.Volume（逻辑卷）本地文件系统的"分区"

3.FUSE用户空间的文件系统（类别EXT4），”这是一个伪文件系统“，用户端的交换模块

4.VFS（虚拟端口）内核态的虚拟文件系统，用户是提交请求给VFS 然后VFS交给FUSH，再交给

5.GFS客户端，最后由客户端交给远端的存储

6.Glusterd（服务）是运行再存储节点的进程（客户端运行的是gluster client）GFS使用过程中整个GFS之间的交换由Gluster client 和glusterd完成

2.4.模块化堆模式架构

GlusterFS 采用模块化、堆栈式的架构。
通过对模块进行各种组合，即可实现复杂的功能。例如 Replicate 模块可实现 RAID1，Stripe 模块可实现 RAID0，通过两者的组合可实现 RAID10 和 RAID01，同时获得更高的性能及可靠性。

2.5.GlusterFS 的工作流程

（1）客户端或应用程序通过 GlusterFS 的挂载点访问数据。
（2）linux系统内核通过 VFS API 收到请求并处理。
（3）VFS 将数据递交给 FUSE 内核文件系统，并向系统注册一个实际的文件系统 FUSE，而 FUSE 文件系统则是将数据通过 /dev/fuse 设备文件递交给了 GlusterFS client 端。可以将 FUSE 文件系统理解为一个代理。
（4）GlusterFS client 收到数据后，client 根据配置文件的配置对数据进行处理。
（5）经过 GlusterFS client 处理后，通过网络将数据传递至远端的 GlusterFS Server，并且将数据写入到服务器存储设备上。

2.6.弹性 HASH 算法

弹性 HASH 算法是 Davies-Meyer 算法的具体实现，通过 HASH 算法可以得到一个 32 位的整数范围的 hash 值，
假设逻辑卷中有 N 个存储单位 Brick，则 32 位的整数范围将被划分为 N 个连续的子空间，每个空间对应一个 Brick。
当用户或应用程序访问某一个命名空间时，通过对该命名空间计算 HASH 值，根据该 HASH 值所对应的 32 位整数空间定位数据所在的 Brick。

#弹性 HASH 算法的优点：
保证数据平均分布在每一个 Brick 中。
解决了对元数据服务器的依赖，进而解决了单点故障以及访问瓶颈。

2.7.GlusterFS的卷类型

2.7.1.分布式卷（Distribute volume）

文件通过 HASH 算法分布到所有 Brick Server 上，这种卷是 GlusterFS 的默认卷；以文件为单位根据 HASH 算法散列到不同的 Brick，其实只是扩大了磁盘空间，如果有一块磁盘损坏，数据也将丢失，属于文件级的 RAID0，不具有容错能力。
在该模式下，并没有对文件进行分块处理，文件直接存储在某个 Server 节点上。由于直接使用本地文件系统进行文件存储，所以存取效率并没有提高，反而会因为网络通信的原因而有所降低。

没有对文件进行分块处理

通过扩展文件属性保存HASH值

支持的底层文件系统有EXT3、EXT4、ZFS、XFS等

优点

文件分布在不同的服务器,不具备冗余性

更容易和廉价地扩展卷的大小

单点故障会造成数据丢失

依赖底层的数据保护

2.7.2.条带卷（Stripe volume）

类似 RAID0，文件被分成数据块并以轮询的方式分布到多个 Brick Server 上，文件存储以数据块为单位，支持大文件存储，文件越大，读取效率越高，但是不具备冗余性。

根据偏移量将文件分成N块(N个条带节点)，轮询的存储在每个Brick Server节点

存储大文件时，性能尤为突出

不具备冗余性，类似Raid0

条带卷特点

数据被分割成更小块分布到块服务器群中的不同条带区。

分布减少了负载且更小的文件加速了存取的速度。

没有数据冗余。

2.7.3.复制卷（Replica volume）

将文件同步到多个 Brick 上，使其具备多个文件副本，属于文件级 RAID 1，具有容错能力。因为数据分散在多个 Brick 中，所以读性能得到很大提升，但写性能下降。
复制卷具备冗余性，即使一个节点损坏，也不影响数据的正常使用。但因为要保存副本，所以磁盘利用率较低。

同一文件保存一份或多分副本

因为要保存副本，所以磁盘利用率较低

若多个节点上的存储空间不一致，将按照木桶效应取最低节点的容量作为该卷的总容量

复制卷特点：

卷中所有的服务器均保存一个完整的副本。

卷的副本数量可由客户创建的时候决定，但复制数必须等于卷中 Brick 所包含的存储服务器数。

至少由两个块服务器或更多服务器。

具备冗余性。

2.7.4.分布式条带卷（Distribute Stripe volume）

Brick Server 数量是条带数（数据块分布的 Brick 数量）的倍数，兼具分布式卷和条带卷的特点。主要用于大文件访问处理，创建一个分布式条带卷最少需要 4 台服务器。

兼顾分布式卷和条带卷的功能
主要用于大文件访问处理
至少最少需要 4 台服务器

分布式条带卷特点

Brick所包含的存储服务器数必须是条带数的倍数(>=2倍)

至少最少需要 4 台服务器

不具有冗余性能，能做高性能的分布式存储

2.7.5.分布式复制卷（Distribute Replica volume）

Brick Server 数量是镜像数（数据副本数量）的倍数，兼具分布式卷和复制卷的特点。主要用于需要冗余的情况下。

兼顾分布式卷和复制卷的功能
用于需要冗余的情况

三、总结

3.1.rsync的特点

能够镜像保存整个目录树和文件系统。

能够很容易作到保持原来文件的权限、时间、软硬连接等等。

无须特殊权限便可安装。

快速：第一次同步时 rsync 会复制所有内容，但在下一次只传输修改过的文件。rsync 在传输数据的过程当中能够实行压缩及解压缩操做，所以可使用更少的带宽。

安全：可使用scp、ssh等方式来传输文件，固然也能够经过直接的socket链接。
支持匿名传输，以方便进行网站镜象。

3.2.rsync的优势与不足

优势：

与传统的cp、tar备份方式相比，rsync具备安全性高、备份迅速、支持增量备份等优势，经过rsync

能够解决对实时性要求不高的数据备份需求，例如按期的备份文件服务器数据到远端服务器，对本

地磁盘按期作数据镜像等。

缺点：

随着应用系统规模的不断扩大，对数据的安全性和可靠性也提出的更好的要求，rsync在高端业务

系统中也逐渐暴露出了不少不足，首先，rsync同步数据时，须要扫描全部文件后进行比对，进行

差量传输。若是文件数量达到了百万甚至千万量级，扫描全部文件将是很是耗时的。并且正在发生

变化的每每是其中不多的一部分，这是很是低效的方式。其次，rsync不能实时的去监测、同步数

据，虽然它能够经过linux守护进程的方式进行触发同步，可是两次触发动做必定会有时间差，这样

就致使了服务端和客户端数据可能出现不一致，没法在应用故障时彻底的恢复数据。

3.3.rsync+inotify实时同步优点

一旦同步源出现变化，立即启动备份

只要同步源无变化，则不执行备份

3.4.GlusterFS 的工作流程

声明：本文内容由网友自发贡献，不代表【wpsshop博客】立场，版权归原作者所有，本站不承担相应法律责任。如您发现有侵权的内容，请联系我们。转载请注明出处：https://www.wpsshop.cn/w/小小林熬夜学编程/article/detail/430530

rsync+inotify实时同步 和 GFS分布式文件系统概述

一、rsync+inotify实时同步

1.1.实时同步的优点

1.2.Linux内核的inotify机制

1.3.发起端配置rsync+Inotify