前面我们介绍过 rsync 有三种常用的使用方式,其中之一是 rsync 作为守护进程启动时,其默认监听在 873 端口,接收 rsync 客户端的请求。

在这种模式下,我们需要给 rsync 守护进程提供一个配置文件,告诉 rsync 提供哪些目录访问,允许哪些 IP 访问等。

Rsync 配置文件格式

rsync 配置文件由全局参数和一个或多个模块组成,全局参数写在文件头部,模块的定义则是由中括号开始,下方定义模块参数。

模块参数也可以定义在全局参数中,这表示给模块参数提供默认值。

配置示例

uid = nobody
gid = nobody
use chroot = yes
max connections = 4
syslog facility = local5
pid file = /var/run/rsyncd.pid

[ftp]
    path = /var/ftp/pub
    comment = whole ftp area

[www]
    path = /var/www
    comment = web file

- 阅读剩余部分 -

rsync 客户端基本用法

rsync 提供三种使用模式,本地、ssh、rsync daemon

本地

rsync [OPTION...] SRC... [DEST]

ssh

拉:

rsync [OPTION...] [USER@]HOST::SRC... [DEST]

推:

rsync [OPTION...] SRC... [USER@]HOST:DEST

rsync daemon

推:

rsync [OPTION...] [USER@]HOST::SRC... [DEST]
rsync [OPTION...] rsync://[USER@]HOST[:PORT]/SRC... [DEST]

拉:

rsync [OPTION...] SRC... [USER@]HOST::DEST
rsync [OPTION...] SRC... rsync://[USER@]HOST[:PORT]/DEST

仅使用一个SRC参数且没有DEST参数的用法时,将列出源文件而不是复制。

- 阅读剩余部分 -

Rsync(remote synchronize)是一个远程数据同步工具,它可以将一个目录的文件快速地同步到另一个目录,还可以通过网络快速同步多台主机间的文件。rsync 使用所谓的“rsync算法”来使本地和远程两个主机之间的文件达到同步,这个算法只传送两个文件的不同部分,而不是每次都整份传送,因此速度相当快。

Rsync 工作模式

一般而言,rsync 是 C/S 模型的一个软件,它既是客户端程序也是服务端程序。也就是说 rsync 需要启动一个守护进程(daemon)来接收客户端的请求,默认监听在 TCP 873 端口。

rsync 也支持独立使用以及配合 SSH 通道来传输数据,下面会有几种用法的详细说明。

Rsync 适用场景

  • rsync 在同步文件时需要非常频繁的计算文件的校验码,因此 rsync 会占用一定的 CPU 资源。

    如果不希望 Rsync 进行增量文件传输,则使用 --whole-file 参数显式指定为全量传输。

  • rsync 不适合对数据库文件进行实时同步

    像数据库文件这样的大文件,且是频繁访问的文件,如果使用rsync实时同步,发送端要计算、比较的数据块校验码非常多,cpu会长期居高不下,从而影响数据库提供服务的性能。另一方面,接收端每次都要从巨大的basis file(一般提供服务的数据库文件至少都几十G)中复制大部分相同的数据块重组新文件,这几乎相当于直接 cp了一个文件,它一定无法扛住巨大的io压力,再好的机器也扛不住。

    所以,对频繁改变的单个大文件只适合用rsync偶尔同步一次,也就是备份的功能,它不适合实时同步。像数据库文件,要实时同步应该使用数据库自带的replication功能。

  • 可以使用 rsync 对大量小文件进行实时同步
  • 由于rsync 是增量同步,所以对于接收端已经存在的和发送端相同的文件,发送端是不会发送的,这样就使得发送端和接收端都只需要处理少量的文件,由于文件小,所以无论是发送端的 CPU 还是接收端的 IO 都不是问题。

    但是,rsync 的实时同步功能是借助工具来实现的,如 inotify+rsync,sersync,所以这些工具要设置合理,否则实时同步一样效率低下,不过这不是 rsync 导致的效率低,而是这些工具配置的问题。

- 阅读剩余部分 -

Keepalived 是由 c 语言编写的一个路径选择软件,是 IPVS 的一个扩展性项目,为 IPVS 提供高可用性(故障转移)特性,它的高可用性是通过 VRRP 协议实现的,并实现了对负载均衡服务器池中的 real server 进行健康状态检测,当 real server 不可用时,自身实现了故障的隔离,这弥补了 IPVS 不能对 real server 服务器进行健康检测的不足,这也是 keepalived 运用最广泛的场景,当然 keepalived 不只限于实现 IPVS 的高可用。

Keepalived 软件架构

Keepalived 是一个模块化设计的软件,其有多个组件共同组成,每个组件各司其职共同完成 Keepalived 的各项功能。

Keepalived Software Design.gif

Checkers:对后端服务器节点(RS)进行健康状态监测和故障隔离,我们知道,LVS 本身是没有健康状态监测功能,keepalived 起初就是为 LVS 生成 IPVS 规则和增加健康状态检测功能而设计的。

VRRP Stack:这是 keepalived 实现 VRRP 功能的模块,VRRP 功能可以实现对前端调度器集群的故障切换(failover)。

SMTP:Checkers 和 VRRP Stack 都是对节点进行状态监测,不同的是监测前端调度器和监测后端RS,但是这两个模块都可以通过SMTP通知管理员故障信息的邮件。

System Call:Checkers 和 VRRP Stack 同样都可以调用系统内核功能完成故障隔离和故障切换。

IPVS wrapper:Checkers 通过监测后端 RS 的工作状态得出信息,IPVS wrapper 通过这些信息添加 IPVS 规则,内核中的 IPVS 则通过这些规则进行工作。

Netlink Reflector:在调度器发生故障切换的时候,该模块充当调用内核 NETLINK 的接口,完成虚拟 IP 的设置和切换。

Watch Dog:keepalived 的核心模块就是 Checkers 和 VRRP Stack,当这两个模块发生故障的时候怎么办呢,这时候 Watch Dog 就发生了作用,它是一个检测工具,周期性的去检测 Checkers 和 VRRP Stack 的运行状态,一旦 Checkers 和 VRRP Stack 发生故障,Watch Dog 就能够检测到并采取恢复措施(重启)。

- 阅读剩余部分 -

之前在介绍 Linux 文件系统的文章中,有提过 ZFS、Btrfs文件系统中,有内置快照的功能,也有提到过其快照的由 CoW 机制实现的。那么这篇文章将带领大家了解快照的原理。

快照技术分类

常见快照的类别有两类:

  • 全拷贝快照
  • 差分快照

全拷贝快照

拷贝快照是通过镜像技术来实现的,即其同时会写两个磁盘,我们可以理解为磁盘整列技术中的 RAID1。

下面通过一张原理图来介绍全拷贝快照的实现原理。

全拷贝快照.png

- 阅读剩余部分 -